概要
https://qiita.com/YShiba92/items/dc73bab7a2db7ebb0257
詳細内容
## kiro-cli 設計の肝 ― agent / knowledge / context を混同すると、なぜ破綻するのか ―
https://qiita.com/YShiba92/items/dc73bab7a2db7ebb0257
AI開発の破綻を防ぐべく、kiro-cliの内部構造を「agent」「knowledge」「context」の3層に定義し、再利用可能な作業基盤の設計指針を提示する。
**Content Type**: ⚙️ Tools
**Language**: ja
**Scores**: Signal:5/5 | Depth:4/5 | Unique:4/5 | Practical:4/5 | Anti-Hype:4/5
**Main Journal**: 84/100 | **Annex Potential**: 83/100 | **Overall**: 84/100
**Topics**: [[kiro-cli, AIエージェント設計, 開発プロセス効率化, ナレッジマネジメント, プロンプトエンジニアリング]]
生成AIを活用したCLIツール「kiro-cli」の運用において、開発効率を最大化しつつプロジェクトを破綻させないための「設計思想」を深く掘り下げて解説する。著者は、AIに与える情報を「agent（エージェント）」「knowledge（ナレッジ）」「context（コンテキスト）」の3つのレイヤーに明確に構造化し、外部化することの重要性を説いている。
これらの要素を「なんとなく」で混同して使用すると、情報の再現性が失われ、作業の積み上げが不可能になる。例えば、プロジェクト共通のルール（agent）に一時的なタスク情報（context）を混ぜてしまうと、後のセッションでも不要な制約が残り続けるといった「破綻」が生じる。著者はこれを「PMがスーパーのレシートを抱えて会議に現れ、昨日のお昼のカレーについて指摘するようなカオスな状況」と比喩し、明確な使い分けの必要性を強調している。
各要素の具体的な役割は以下の通り定義されている。
1. **agent（エージェント）**: 「規律に厳しいプロジェクトマネージャー」に相当する。プロジェクト共通の動作ルール、セキュリティ権限、使用可能なツールの制限など、常に守るべき前提条件を定義する。変更頻度は極めて低く、セッションを跨いで永続する「土台」となる。
2. **knowledge（ナレッジ）**: 「物知りな司書」に相当する。仕様書、設計書、コードベース、過去のトラブルシューティング記録など、セマンティック検索（自然言語検索）が可能な蓄積情報を指す。大量の情報を永続化し、必要な時にだけ引き出すことができる図書館の役割を果たす。
3. **context（コンテキスト）**: 「現場の情報屋」に相当する。現在取り組んでいるタスクの詳細、特定のエラーログ、検討メモなど、その場限りの動的で一時的な情報を扱う。会話が終了すれば忘れられる「載せ替え可能な荷物」である。
本記事では、これらを混同することで発生する3つの典型的な破綻パターン（agentへの一時情報の詰め込み、knowledgeのcontext化による検索ノイズ、contextへの永続情報の重複投入）を指摘し、実務フェーズごとの正しい使い分けを具体的に提示している。例えば設計レビューフェーズでは、agentにレビュー手順、knowledgeに過去事例、contextに今回の設計書を配置することで、再現性の高い作業基盤を構築できる。
著者は、迷ったときの判断基準として「3回以上繰り返す情報はagentかknowledgeへ移行する」という極めて実戦的なルールを提示している。これにより、kiro-cliが単なる「属人化した便利ツール」から、チーム全体の生産性を支え、知識を資産化する「実務で破綻しない作業基盤」へと昇華される。AIとの協働をスケーラブルにするための、エンジニア必見の論理的フレームワークである。