はじめに
kiro Crew を触ってみたシリーズの続きです。
Kiro Crew には Memory という会話から自動で学習する機能がありますが、もう 1 つ「Knowledge Library（ナレッジライブラリ）」という機能があります。
こちらは自動蓄積ではなく、ユーザーが意図的にドキュメントを登録して、エージェントの参照知識を育てていく仕組みです。
別媒体の記事で Memory 機能の中身を調べましたが、今回はこの Knowledge Library を実際に触って、グラフビューの動きやチャットでの検索の様子を確認しました。
この記事で学べること
- Knowledge Library の基本的な仕組みと Memory との違い
- ソースの追加方法と対応ファイル形式
- ナレッジグラフの生成・統合の挙動
- チャットからナレッジを検索する流れ
- Ingestion Settings の設定項目と使いどころ
前提条件
- Kiro Crew 0.3.0 / macOS / 2026 年 8 月 25 日検証
Knowledge Library とは？
公式ドキュメントに詳しい説明があります。
簡単に書くと、メモリと違い、自身でエージェントに読ませたいドキュメントを格納しておく仕組みです。
プロジェクトドキュメント、API 仕様書、運用手順書などなどフォーマットが対応していればなんでも登録が可能です。
Memory との違い
| 項目 | Knowledge Library | Memory |
|---|---|---|
| 登録方法 | 手動（ファイル・フォルダ・URL） | 会話から自動蓄積 |
| 保持する内容 | 外部ドキュメント・リファレンス | 好み・履歴・学習した事実 |
| ユーザー操作 | 必要（ソース追加・確認） | 不要（自己学習） |
| 用途 | 参照資料置き場 | 対話学習 |
裏側の仕組み
ドキュメントを登録すると、チャンク分割 → インデックス化 → 埋め込みベクトルへの変換、という流れで処理されます。
埋め込みモデルは初回起動時に自動ダウンロード（約 610 MB）。完了するまではキーワード検索で凌ぐ仕組みになっています。
検索時にはエージェントが local_knowledge_search という MCP（Model Context Protocol）ツールを呼び出して、ベクトル類似度で関連チャンクを引っ張ってきます。
埋め込みが使えない状況ではキーワード検索に自動で切り替わります。
さらに Knowledge Library は、チャンクからエンティティ（人名・サービス名・概念など）や関係を抽出してナレッジグラフも構築します。
ナレッジグラフのメリット
普通の RAG（Retrieval-Augmented Generation）はベクトル検索で「似た文章の断片」を引っ張ってくる仕組みです。
一方ナレッジグラフは「A は B を使う」「B は C に属する」といった構造化された関係を保持します。
複数ホップ先のつながりを辿れるのがポイントで、たとえば「A と C の関係は？」と聞かれたとき、直接 A-C の記述がなくても A→B→C の経路で推論できます。
なお、チャンクごとに LLM を呼んでエンティティ抽出するのでコストがかかります。
グラフビューを試してみた
Knowledge Library の画面はタブ構成になっていて、リストビュー・グラフビュー・ソース・Settings の 4 つがあります。実際にソースを追加してグラフがどう生成されるか確認してみます。
ソースを追加する
「ソースを追加」モーダルを開くと、「ローカルファイル」と「ローカルフォルダー」の 2 つのボタンが表示されます。
公式ドキュメントには URL 追加（Adding a URL source）も記載されていますが、0.3.0 時点のソース追加モーダルには URL ボタンが表示されませんでした。バージョンやビルドにより UI に差がある可能性があります。
ネームスペースも指定できます（デフォルト値は「default」）。新しいネームスペース名を入力すれば作成も可能。
対応拡張子は以下のとおりです。ファイルサイズ上限は 50 MB のようです。
.c .cpp .csv .docx .go .h .htm .html .java .js .json .jsonl
.log .md .ndjson .org .pdf .py .rb .rs .sh .ts .txt .yaml .yml
1 ファイル登録してみる
技術用語の相互関連が多い内容にして、グラフの広がりを確認しやすくしました。生成 AI 開発の基本用語を関連づけた短いテキストです。
生成AIアプリケーション開発の基本構成
大規模言語モデル(LLM)は、生成AIアプリケーションの中核となる要素である。LLMはAmazon Bedrockのようなマネージドサービスを通じて利用されることが多い。Amazon BedrockはAWSが提供するサービスであり、Anthropic社のClaudeやその他のファウンデーションモデルを呼び出すためのAPIを提供する。
RAG(Retrieval-Augmented Generation)は、LLMの回答精度を高めるための代表的な手法である。RAGを実現するには、まずドキュメントをチャンク(小さな断片)に分割し、それぞれを埋め込み(エンベディング)と呼ばれるベクトルに変換する。生成された埋め込みはベクトルデータベースに保存される。ユーザーが質問すると、質問文も埋め込みに変換され、ベクトルデータベース内で類似度検索が行われる。検索で得られた関連情報はプロンプトに組み込まれ、LLMに渡される。
エージェント(Agent)は、LLMを使って自律的にタスクを遂行する仕組みである。エージェントはツール(Tool)を呼び出すことで、外部システムと連携できる。MCP(Model Context Protocol)は、エージェントとツールを接続するための標準プロトコルであり、KirocrewやClaude CodeなどのAIエージェントで採用されている。
Kirocrewはナレッジライブラリという機能を持ち、ユーザーが登録したドキュメントをチャンク化・埋め込み・インデックス化する。これはRAGの仕組みと同じ原理に基づいている。ナレッジライブラリに登録された情報は、エージェントがlocal_knowledge_searchというMCPツールを通じて検索する。
もりやまが開発しているlive_translateプロジェクトは、音声をMLX-Whisperで文字起こしし、AWS Translateで翻訳するCLIツールである。この構成もLLMやAWSサービスを組み合わせたアプリケーションの一例と言える。
登録するとステータスが「Syncing」になります。
しばらく待つと「Synced」に変わり、グラフビューが生成されました！ 16 ノード、11 エッジのグラフです。
LLM、Amazon Bedrock、RAG、MCP といったエンティティがノードとして抽出され、それぞれの関連がエッジで表現されています。
2 ファイル目を追加して統合を確認
次に、クラウド AI サービスの比較を書いたテキストを追加します。
クラウドAIサービスの比較
Amazon Bedrockは、Anthropic社のClaudeだけでなく、Meta社のLlamaやAmazon自社のNovaなど、複数のファウンデーションモデルを統一APIで呼び出せるサービスである。開発者はモデルを切り替える際にコードを大きく変更する必要がない。
Claudeは対話能力やコーディング支援能力に優れており、Claude Codeというコマンドラインツールを通じて開発者のワークフローに組み込むことができる。Claude CodeはMCP(Model Context Protocol)を利用して、外部ツールやサービスと連携する。
一方、Google CloudはVertex AIというサービスを提供しており、Google独自のモデルであるGeminiを利用できる。Vertex AIもAmazon Bedrockと同様に、複数のモデルを選択できる仕組みを持つ。
企業がAIサービスを選定する際は、コスト、レイテンシ、対応リージョン、セキュリティ要件などを比較検討する必要がある。
追加後のグラフは 23 ノード、19 エッジに増えました。
同じ名前のエンティティはファイルをまたいでも 1 つのノードに統合されており、「Amazon Bedrock」や「MCP」は両方のファイルに登場しますが、グラフ上では 1 つのノードにまとめられ、エッジが集約されています。
ノードにはタイプ（service / technology / concept / org）が付与されていて、凡例で色分け表示されます。
ノード選択とアイテムリンク
グラフビューでノードを選択すると、そのエンティティを含むアイテムへのリンクが表示されます。
リンクをクリックするとリストビューのアイテム詳細に遷移し、サマリー・エンティティ一覧・関連性・関連アイテム・コンテンツ全文が確認できます。
ただし、すべてのノードでリンクが表示されるわけではありませんでした。「Anthropic」ノードを選択すると「アイテムが見つかりません」と出ます。
エンティティとして抽出されていても、アイテムとの紐づけが存在しないケースがあるようです。今後のアップデートで挙動が変わるか気になるところですね。
チャットから Knowledge を検索する
実際にチャットで Knowledge Library の情報を引き出せるか試してみます。
「live_translate プロジェクトってなに？」と聞いたところ、最初はナレッジを検索せず「見つかりません」という反応でした。
「ナレッジ見てみて」と明示的に指示すると、local_knowledge_search MCP ツールが呼ばれて正しく回答してくれました。
推論の中身を覗くと、パラメータは query と limit の 2 つだけのシンプルな構成です。今回は limit: 5 で検索されていました。
公式ドキュメントには「This happens automatically when the agent determines it needs reference material」と書かれています。
ただ今回の検証では、明示的に指示しないと検索してくれませんでした。
確実に検索させたい場合は「ナレッジを検索して」「Knowledge Library で調べて」のように、ナレッジ参照を明示する指示を入れる必要がありそうです。
Ingestion Settings（取り込み設定）
最後に紹介のみですが、Settings タブの「Ingestion Settings」で、ナレッジの取り込み挙動をカスタマイズできます。
| 設定項目 | デフォルト値 | 説明 |
|---|---|---|
| Auto-add documents | オフ | エージェントが通常作業中に読んだドキュメントを自動追加するか |
| Auto-register project documents | オフ | プロジェクトのドキュメントを自動でソース登録するか |
| Auto-add saved artifacts | オン | 保存したアーティファクトをナレッジにミラー登録する |
| Per-source chunk limit | 150 | 1 ソースあたりの最大チャンク数（0 = 無制限） |
| Max sources | 50 | 自動検出ソースの上限（手動追加分はカウント外） |
| Embedding rate limit | 120/min | 埋め込みリクエストの毎分上限 |
| Extraction model | auto | チャンク抽出に使う LLM（デフォルトはチャットモデル） |
| Extraction pool size | 3 | 抽出処理の並列ワーカー数（変更時は再起動が必要） |
自動取り込み系（上 3 項目）とコスト・速度チューニング系（下 5 項目）で役割が分かれています。
まとめ
軽く触ってみて、以下のような理解をしました。
- Knowledge Library は「手動でドキュメントを登録して育てるナレッジストア」
- 登録するとチャンク分割 → 埋め込み → ナレッジグラフとして構造化される
- 同名エンティティはファイルをまたいでも統合される
- グラフビューでノードを選択するとアイテムリンクが表示されるが、エンティティによっては紐づけがなく表示されないケースもあった
- チャットからの検索は
local_knowledge_searchMCP ツール経由。明示的に指示したほうが確実 - URL 追加は公式ドキュメントに記載されているが、0.3.0 時点のソース追加モーダルには URL ボタンが表示されなかった
大規模なデータでの検証ではないので、ナレッジグラフの優位性の検証まではできていませんが、今後利用していきたいと思います！