はじめに — 前回のおさらい
前回の第1部『Kiro Crew — AIエージェントを「チーム」として運用する新しいワークスタイル』では、Kiro Crew（Amazonが中心に開発するApache 2.0のOSS、自律型AIエージェント管理レイヤー）の全体像を紹介した。永続メモリ・スケジュール実行・サブエージェント並列処理・そしてローカルRAG(Knowledge Library)が組み込まれていることを紹介した。
今回は、第1部の末尾で予告していたKnowledge Libraryを、実データで検証してみたいと思う。
私はこれまで、社内の技術ナレッジをllm-wiki1という自前の仕組みで運用してきた。AWS移行やVMware周りのメモを、Obsidian互換のMarkdownで約60ページ。よくできているのだが、完全にセルフマネージドだ。HookやSteeringで自動化しているものの、ページを足すたびに索引（_index.md）を整備し、鮮度を保つためのメンテを自分で回し続けなければならない。
そこで今回、この自前llm-wikiを、Kiro Crew内蔵のRAGであるKnowledge Library（以下KB）でまるごと作り直してみた。結論から言うと——ちゃんと動いた。そして何より、KBは全自動だった。 ナレッジソースにファイルを放り込んでおけば、「ナレッジを参照して答えて」と付け加えるだけでKBを使った回答をしてくれる。さらに、ソースファイルが更新されると自動的にKBも追従してくれる。実に使い勝手の良い仕上がりだ。
——なのだが、結論から言うと、llm-wikiをそのままKB化するのは、正直あまりお勧めしない。「動く」のと「向いている」のは別の話だった。理由は順を追って説明していこうと思う。
補足: llm-wikiとは
ここで言う「llm-wiki」は、Andrej Karpathy氏が2026年4月に提唱したナレッジベースのパターン（karpathyのgist）を指す。RAGのように「毎クエリで生ドキュメントから検索する（retrieve-on-every-query）」のではなく、LLMエージェントが生ソースをクロスリンクされたMarkdown wikiに編纂し、新しい情報が来るたびに更新・矛盾チェックして維持し続ける（compile-once-and-keep-fresh）という考え方だ。raw/（不変の元ソース）→ wiki/（LLMが生成・維持するページ）の三層構成が基本。
私はこのアイデアをKiro Crewのスキル（SKILL.md）として実装し、検索フロー（_index.md→該当ページ）とコンパイルフロー（raw/→wiki/）を定義して使っている。本記事では、この自前実装を「llm-wiki方式」、KBに作り直したものを「KB方式」と呼ぶ。
llm-wikiとKBの違い
llm-wikiとKB、それぞれの運用イメージを一言で言うと——
| llm-wiki | Knowledge Library | |
|---|---|---|
| 管理 | セルフマネージド | マネージド |
| 登録 |
raw/に置いて「コンパイルして」と指示、wiki/を編纂 |
ファイルを放り込むだけ。あとは勝手にRAG化 |
| 索引の維持 |
_index.mdを自分で整備（cronで再生成して鮮度維持） |
不要。embedding＋グラフを自動構築 |
| 検索 | 文字索引→該当ファイル特定→全文読み | セマンティック検索で該当チャンクを直接 |
| 手間 | 自分で回し続ける必要がある | 放っておける |
KBのメリット
- マネージド。索引の維持を人間がやらなくていい
- セマンティック検索（意味で検索）ができる。表記ゆれや言い換えに強い
- データソースの更新を自動的に追ってくれる（後述のとおり、常にフレッシュ）
KBのデメリット
- Kiro Crew内でしか使えない（llm-wikiはただのMarkdownファイルなので、kiro ide / kiro cli / Obsidian / grep などどこからでも参照できる）
- 仕組みがごつい分、少しメモリを余計に食う（embeddingモデルで約700MB RAM程度）
llm-wikiとKBの動作比較 — 実は、llm-wikiの方が速くて安かった
「動く」ことは分かった。では性能はどうか。同じwikiに同じ10問を投げ、「ファイル直読み（llm-wiki方式）」と「KB検索」で引き比べてみた。結果は——この規模では、どの指標でもllm-wikiが上だった。
Hit率：llm-wiki 10/10、KB 9/10
Hit率は、llm-wiki 10/10（100%）に対しKB 9/10（90%）。llm-wikiは「索引→該当ファイル名を特定→そのファイルを読む」で、ファイル名がトピック名と一致する設計だから狙ったページに必ず届く。KBの1件のミスは、クエリ語（「リホスト」「ブロッキング」）がKB構築時に抽出されたエンティティと噛み合わず、該当ページが検索に返ってこなかったケースだった。
コスト・速度：llm-wikiが約36%安く、しかも速い
まっさらな新規スレッドを2本立て、同じ10問を同順で両方式に投げ、消費クレジット（turn_stats.credits＝入力・内部推論・出力を合算し課金単位に丸めた総消費）を実測した。
| 方式 | 10問の消費クレジット | 所要時間 |
|---|---|---|
| llm-wiki（ファイル直読み） | 2.64 | 85.5秒 |
| KB（セマンティック検索） | 4.28 | 120.0秒 |
llm-wikiが約36%安く、しかも速い。「チャンクだけ返すKBの方が入力は小さいから安いはず」という事前の読みは外れた。理由は、KBは毎回embeddingの計算とグラフ探索という"検索エンジンを回すコスト"を払っているから。入力に載る量は小さくても、その小ささを実現する裏側の処理が、「ファイルを読むだけ」のllm-wikiより重い。賢く探すには計算資源を使う——という当たり前が数字に出た。
（注：クレジットは丸めた総消費で生トークンそのものではなく、試行はN=1。ただ同一条件・同順で測っているので、この規模でllm-wiki＜KBという方向性は信頼できる。）
KBの方が性能が悪い……？
ここで素朴な疑問が湧く。セマンティック検索やグラフまで備えたKBが、ただファイルを読むだけのllm-wikiに、なぜ精度でもコストでも負けるのか。 KBの方が仕組みは高度なはずだ。
答えは「KBが劣っている」ではなかった。題材（llm-wiki）が、そもそもRAGを必要としない形に仕上がっていた——これが本質だった。次章で説明する。
なぜllm-wikiの方が使い勝手が良かったのか — RAGと「完成した答え」の相性
そもそもRAGとは（＝KBの正体）
冒頭で触れたとおり、KBはRAGの実装そのものだ。ここで改めてRAG自体をおさらいしておく。RAG（Retrieval-Augmented Generation）は、ざっくり言えば「大量の文書を機械が検索できるよう小さく刻んで索引化し、質問のたびに似ている断片を上位から拾ってLLMに渡す」仕組みだ。KBもまさにこれで、取り込み時に文書を約800トークンを目安にチャンク分割し（\n\n→\n→スペースの順で区切る再帰セパレータ方式・LightRAGスタイル、200トークンのオーバーラップ付き）、LLMでエンティティを抽出してグラフを張り、ローカルのembeddingモデルでベクトル化する。検索時はキーワード（FTS5）＋グラフ＋ベクトルの3-way RRFで、質問に近いチャンクを引く。つまりKBの挙動＝RAGの挙動だと思ってよい。
RAGが輝くのは、未整形で雑多な生文書の山を相手にするときだ。PDF、議事録、仕様書——人間が読む前提で書かれ、構造もバラバラな文書を、前処理なしで「意味で引ける」状態にしてくれる。これはとてもありがたい。
llm-wikiは「1ページ＝完結した答え」だった
ところが、私のllm-wikiはその真逆だった。llm-wikiの1ページは、wiki化する段階で「1つのトピックに1ページで答える」粒度に編纂済みで、関連はObsidianリンクで張られている。つまり1ページがそれ自体で完結した知識のまとまりになっている。ファイル読み込み＋スキルで引けば、1ページ丸ごと＝完全な文脈がそのまま手に入る。
これをKBに入れると、せっかく完結しているページが約800トークンで機械的にチャンク分割され、検索時には上位チャンクだけが返る。人間が作った「1ページ＝1つの完結した文脈」という編纂の成果を、チャンク境界とTop-N取得でわざわざ分断してしまうわけだ。すでに整形済みの知識には、RAGの機械的なチャンク分割はむしろ余計なお世話になる。だからHit率もコストも、素直にファイルを読むllm-wikiに軍配が上がった。
要するに、llm-wikiとRAGは優劣ではなく、得意な入力が違う。整形済みで完結した知識にはllm-wiki（そのまま読む）が向き、未整形で雑多な生文書にはRAG（刻んで意味で引く）が向く。今回はたまたま「整形済みの完成品」をRAGに通したので、噛み合わなかった——それだけの話だ。
では、KBの本領はどこか — 生の社内ドキュメントを"常にフレッシュ"に
裏を返せば、KBが本当に効くのは、llm-wikiのように手で編纂していない、生のままの文書群だ。ここがKB本来の使いどころで、そしてかなり気持ちいい。
やり方は簡単で、社内ドキュメントのフォルダをそのままナレッジソースに登録するだけ。PDFでもWordでもMarkdownでも、KBが勝手にRAG化して、中身を理解した上で回答してくれるようになる。前処理も、索引づくりも要らない。「この案件の設計方針は？」と聞けば、放り込んだ設計書や議事録を横断して答えが返ってくる。
しかもソースは継続的に更新チェックされる。フォルダにファイルを足したり直したりすれば、KBが自動で追従して取り込み直す。かつての企業内検索（オンプレのファイルサーバを丸ごとインデックスして全文検索、といった仕組み）を思い出すが、決定的に違うのは——あれが「該当ファイルを一覧で返す検索」だったのに対し、KBは中身を読んで理解した上で回答まで返してくれる点だ。常に最新のソースを土台に、探すのではなく答える。これがKB本来の使い方だった。
（なお開発元のドキュメントやツール定義を読むと、KBは「なんでも全部放り込む倉庫」ではなく「効く文書を厳選して蓄積するアーカイブ」として設計されている。実際、自動追加系の設定はすべてデフォルトで無効＝オプトインで、ツールの説明にも "a polluted library makes every future search worse"（散らかしたライブラリは以後の全検索を悪くする）と明記されている。生文書を放り込むにしても、"効くソース"を選んで入れるのが前提、というわけだ。）
余談: 自動登録は、まだ思ったほど働いてくれない
KBには、登録を明示せずともエージェントが仕事中に読んだ重要文書を自動でナレッジ化する機能（auto_add_documents）がある。「放り込むだけ」のさらに先、「放り込む操作すら要らない」全自動を期待して、これをtrueにし、数日ふつうに使ってみた。営業ネタの調査、CLIのアップデート確認、この記事の執筆——いつも通りの使い方だ。
数日後、登録件数を確認した。変化なし。自動追加は0件だった。
日常の「調べる・議論する」使い方では、エージェントが「これは将来も参照する価値がある（load-bearingだ）」と判断してKBに入れる契機が、そもそもあまり訪れないらしい。「この資料を覚えておいて」と明示的に促せば当然たまるが、意図せず自然に厳選蓄積されるという理想の動きは、現状まだ観測できていない。
ここは正直、まだ思った通りには動いてくれず、改善の余地がありそうな部分だ。裏を返せば「放っておいて勝手にノイズが膨れることはない」とも言えるが、全自動を謳うならもう一歩ほしい。使い方を変えながら、引き続き様子を見たい。
まとめ
自前で運用していたllm-wikiを、Kiro CrewのKnowledge Libraryで作り直してみた。ちゃんと動いたし、登録は全自動で快適だった。それでも結論は、llm-wikiをそのままKB化するのはお勧めしない——だ。
自分の第2の脳としてまとめた情報を必要な時に取り出すという用途ならllm-wiki。
社則やら手順書やら大前提として知っておくことを覚えさせたいならKB。
と言ったところ。
つまり両者は優劣ではなく、整形済みか未整形かで使う道具が違う。手で編み上げた完成品はllm-wikiのまま読ませ、雑多な生文書はKBに任せる——これが、作り直してみて分かった今の結論だ。
出典・参考: 本記事のKnowledge Libraryの内部動作（チャンク分割・エンティティ抽出グラフ・FTS5＋グラフ＋ベクトルの3-way RRF・graceful degradation）は、Kiro Crew公式ドキュメント Knowledge Library — How the Graph Works で裏どりしている。llm-wikiの出典は Andrej Karpathy氏のgist（LLM Knowledge Bases）。
（環境: Windows 11 / Python 3.12 / kiro-cli 2.20 / Kiro Crew 0.6.x。検証中、内蔵embeddingのメモリリーク issue #6216 に遭遇。長時間稼働では注意。）