6月27日、Eivind Kjosbakkenが「How to Build a Powerful LLM Knowledge Base」と題した記事を公開した。ナレッジベースへの情報投入を「手動でやっている限り必ず破綻する」という強い主張のもと、コーディングエージェントのログ活用を含む自動収集の仕組み化と、GrepベースおよびRAGベースという2つの活用アプローチを実践的に解説している。
ナレッジベース（知識基盤）は以前から存在する概念だが、LLMの登場によって質的に変わった。以前は人間が手動で検索していた情報を、今やLLM自身がRAG（Retrieval-Augmented Generation）などを使って自律的に取得できる。人間がナレッジベースを参照する判断を下す必要がなくなったのが最大の変化だとKjosbakkenは指摘する。
この変化はナレッジベースに対する要求水準を根本から変える。人間が能動的に引きに行く前提の設計では、多少の抜け漏れがあっても運用上許容されてきた。しかしLLMが自律的に参照する前提では、情報が欠けた時点でシステム全体の信頼性が崩れる。だからこそ、投入の自動化が「あると便利な機能」ではなく設計の核心になる、というのが記事全体の論旨だ。
情報収集の自動化が核心
記事の中でKjosbakkenが最も強調するのが、ナレッジベースへの情報投入を完全に自動化するという点だ。
You and other people will not be willing to spend more time manually putting things into knowledge bases. You need to figure out a way to automatically do this to have your knowledge base up to date.
手動でミーティングメモを貼り付けるような運用は必ず破綻する、というのが彼の主張だ。ナレッジベースの価値は「すべての情報が漏れなく蓄積されている」ことにあるため、抜け漏れが生じた時点で信頼性が崩れる。
具体的な自動化の手段として記事では以下を挙げている：
- ミーティングメモ: 毎日のcronジョブでナレッジベースに同期
- Linear等のプロジェクト管理ツール: 同様にcronジョブで全タスクの状態を同期
- Claude CodeやCodexなどのコーディングエージェントのログ: 作業内容や議論した内容を自動取り込み
- 社内の対面議論: 完全自動化は難しく、録音（要同意）か手動メモが現実的。ただし、対面議論の多くはその後コーディングエージェントで実装に移るため、そのログから間接的に取得できる場合も多い
コーディングエージェントのログをどう構造化するか
コーディングエージェントのログ取り込みは、自動化の中でも特に実践的な価値が高い。Claude CodeやOpenAI Codexといったエージェントは、実装の意思決定や却下した選択肢、エラーと対処の履歴といった「なぜそう作ったか」の文脈を会話ログとして残す。これを単純にテキストとして投入するだけでは検索精度が落ちるため、Kjosbakkenはセッション単位で日付・タスク名・結論をヘッダとして付与したMarkdown形式に整形してからナレッジベースに格納することを推奨している。cronジョブでエージェントのログディレクトリを監視し、新規セッションが完了するたびにこのフォーマットへ変換・投入するパイプラインを組むことで、人手を介さずに「実装の文脈」が蓄積されていく。
ナレッジベースの使い方：GrepかEmbeddingか
情報の活用方法として、記事では2つのアプローチを対比している。
Grepベースの推論
ナレッジベース全体の構造を説明するトップレベルのMarkdownファイルを用意し、常にLLMのコンテキストに含める方法。埋め込みベースの検索より正確な情報を取得できる反面、Markdownファイルが肥大化するにつれてトークン消費が問題になる。小規模なナレッジベースや、参照頻度が高くコンテキストに常駐させておく価値があるコア情報には向いているが、長期運用でドキュメント量が増えると維持コストが急増する点がトレードオフだ。
埋め込みベースの推論（RAG）
クエリのたびにベクトル検索を実行し、関連チャンクを取得するアプローチ。アクティブな検索操作が不要で、コンテキストウィンドウへの常時ロードが不要な点でスケーラビリティに優れる。Kjosbakkenは「おそらくこちらのほうが推論時の使い勝手はよい」としつつも、ユースケース次第と述べている。一方で、チャンクの分割粒度や埋め込みモデルの選択によって検索品質が大きく変わるため、精度の担保にはチューニングコストが伴うという実装上の注意点もある。コンテキストを超えた大規模なナレッジベースや、検索対象が多様なユースケースで真価を発揮する。
要点整理
| アプローチ | 精度 | トークン消費 | 主なトレードオフ | 向いているケース |
|---|---|---|---|---|
| Grepベース | 高い | 多い（常時ロード） | 規模拡大でコスト急増 | ナレッジベースがまだ小規模な段階 |
| 埋め込みベース（RAG） | 検索品質に依存 | 少ない | チューニングコストが必要 | 大規模・長期運用 |
Kjosbakkenはナレッジベースを「自社や個人だけが持つ固有のデータ」として位置づけており、今蓄積しなければ将来参照できなくなる情報が存在するという点を理由として挙げている。構築の完成度よりもまず「蓄積を始めること」を優先するよう促している。自動化パイプラインが完成してから動かすのではなく、cronジョブ一本でもいいからまず流し始め、後から精度を上げていく反復的なアプローチが現実的だとも述べている。
詳細はHow to Build a Powerful LLM Knowledge Baseを参照していただきたい。
