AIエージェントのための「LLM Wiki」を自作した — 構成・OKF対応・MCP連携のすべて
複数のAIエージェントを長期間運用していると、ある問題に必ずぶつかる。「同じ失敗を、別のエージェントが何度も繰り返す」「うまくいった手順が、次回には誰も覚えていない」という知識の揮発だ。人間のチームならドキュメントやWikiで解決するこの問題を、AIエージェント運用の世界でどう解くか。その答えとして筆者が構築したのが、AIエージェント専用の運用知識ベース「LLM Wiki」である。本稿では、その設計思想・構成・標準フォーマット対応・そしてエージェントがどのように知識を参照するのかを、実際の運用事例とともに紹介する。
背景 — なぜ「エージェントのためのWiki」なのか
一般的なWikiは人間が読み書きすることを前提に作られている。しかしAIエージェントの運用知識は、性質が少し違う。スキルの定義、タスクの成功・失敗手順、実行した事例のログ、設計判断の記録といった情報が、日々大量に、しかも機械的に生成される。これらを人間が手作業で整理するのは現実的でない。
そこで目指したのは「AIエージェントと人間の双方が同じルールで読み書きできる知識ベース」だ。エージェントは自分の経験を構造化して書き込み、別のエージェントは過去の知見を検索して参照する。人間はいつでもその全体像をブラウザで眺められる。この相互運用性を成立させるために、明確なスキーマ（運用ルール）と、API（MCP）による標準化されたアクセス経路を最初から設計の中心に据えた。
Wiki全体の構成
LLM WikiはMkDocsベースの静的サイトとして構築し、コンテンツの実体はすべてMarkdownファイルで管理している。最大の特徴は、書き込み権限の異なる2つの領域を明確に分離している点だ。
docs/ 配下はAIエージェントが生成・更新できる整理済みの知識ページ群で、人間も自由に閲覧・編集できる。一方 raw/ 配下はエージェント実行ログ・レポート・障害報告・外部ドキュメントといった「生ソース」を置く領域で、こちらはリードオンリー扱いとし、エージェントは専用のアップロード経路からの投入のみが許される。直接編集や削除はできない。生データと整理済みナレッジを分けることで、「とりあえず投入する」入口と「精査して残す」出口を切り分けている。
docs/ の中はさらに用途別のカテゴリに分かれている。エージェント定義（agents）、能力単位のスキル定義（skills）、タスク手順を成功と失敗に分けて記録するプレイブック（playbooks/success・playbooks/failure）、ツールやAPIの情報（tools）、実行事例とポストモーテム（cases）、そして設計判断記録であるADR（decisions）だ。加えて、全体目次の index.md、運用ルールを定めた schema.md、変更履歴の log.md、自動生成されるタグ一覧 tags.md がルートに置かれている。
運用ルールも厳格に定めている。ファイル名はすべてケバブケースの英小文字で統一し、日本語やスペースは禁止。日付が必要なページは YYYY-MM-DD-<slug>.md、ADRは adr-001 のような連番とする。ページを更新したら最終確認日を当日に書き換え、重要な変更は log.md に一行追記する。そして特筆すべきは「失敗事例は削除しない」というルールだ。解決済みであっても失敗の記録は残す。教訓の蓄積こそがこのWikiの最大の価値だと位置づけているからだ。
テンプレートとOKF対応
カテゴリごとに必ず使うべきテンプレートを .templates/ に用意している。エージェント・スキル・成功手順・失敗手順・事例・設計判断それぞれに専用テンプレートがあり、「テンプレートを使わないページ作成」は禁止事項だ。たとえば失敗プレイブックのテンプレートには、症状・再現条件・時系列で試した対処（成否つき）・根本原因・教訓という欄が最初から組み込まれている。エージェントは穴埋めするだけで、後から再利用しやすい構造化された記録を残せる。
各ページの先頭には必ずYAML frontmatterを付与する。ここで採用しているのが、Google Cloudが提唱する Open Knowledge Format（OKF） だ。OKFはYAML frontmatterによるメタデータの標準化と、Markdownのリンクによるグラフ構造を組み合わせて、知識をAIと人間の双方が相互運用できる形にするための仕様である。
具体的には、ページ種別（type）・タイトル（title）・説明（description）・関連する外部リソース（resource）・タグ（tags）・最終確認日（last_verified）・更新日時（timestamp）といったフィールドを必須または標準項目として定義した。OKF導入にあたっては、既存ドキュメントを一括変換する大規模マイグレーションはあえて見送り、テンプレートと各ディレクトリの「顔」となるインデックスファイルを更新する方針を採った。こうすることで既存資産との互換性を保ちながら、今後追加・更新されるページを中心に段階的に標準フォーマットへ移行できる。互換性を壊さず標準化を進める、現実的な落としどころだ。
さらにページ本文では [[agent/xxx]] のようなウィキリンク記法でページ同士を相互参照する。失敗事例から関連する成功手順へ、事例からそれを担ったエージェント定義へとリンクが張られ、知識全体が一つのグラフを形成する。これがOKFの言う「Markdownのグラフ構造」であり、後述する検索・探索の精度を支えている。
AIエージェントはどうWikiを参照するか — MCPツールと活用事例
このWikiの心臓部が、MCP（Model Context Protocol）による標準化されたアクセス経路だ。エージェントはファイルシステムを直接触るのではなく、7つのMCPツールを通じてWikiを操作する。ページ一覧を取得する wiki_list、特定ページを読む wiki_read、BM25とベクトル検索を組み合わせたハイブリッド検索の wiki_search、生ソースを投入する wiki_upload、テンプレート一覧を取る wiki_templates、検索インデックスを再構築する wiki_reindex、ベクトル埋め込みを生成・更新する wiki_embed である。
これら個別のバックエンド（Wikiに加えてブログCMS・メタ検索エンジン・ナレッジグラフRAG）は、当初それぞれ別プロセスで動いており、呼び出しごとにコンテナが生成されたり、別のマシンから呼べなかったりという運用上の課題があった。そこでFastMCPを使い、複数のバックエンドを単一の常駐プロセスに集約し、HTTP（streamable-http）でLAN内のどのマシンからでも利用できる「MCPプロキシ」として再構築した。これにより、Wiki操作はすべてこの統一されたツール群を経由する運用が確立した。
実際の活用事例をいくつか挙げる。
第一に、生ソースを整理済みページへ変換するキュレーション・エージェントだ。従来は「対応するページがあればスキップ、なければ新規作成」という単純な二値判定で、結果として同じトピックのほぼ同内容のページが大量に重複していた。これを wiki_search で類似ページを検索し、類似度に応じて「新規作成（create）／更新（update）／追記（append）」の3アクションを自動で選び分ける設計へ改めた。同一トピックの知見が一つのページに集約され、更新履歴も追える。重複の氾濫という、知識ベースが必ず陥る病を検索で治療しているわけだ。
第二に、別系統のローカル・メモリ機能との自動同期だ。直接統合のためのAPIが存在しなかったため、毎日決まった時刻にメモリ側の日次ダイジェストを生成し、wiki_upload でWikiの生ソース領域へ自動投入するcronジョブを組んだ。並行運用しつつデータを整合させる構成だ。
第三に、記事執筆・SNS運用エージェントによる参照だ。ニュース収集・分析を担うエージェントが過去の事例やスキル定義を検索して文脈を補い、ブログ記事やSNS投稿を生成する。本稿そのものも、Wikiに蓄積された設計判断や事例をMCP経由で参照しながら構成している。
影響と今後
このLLM Wikiによって、AIエージェント運用は「やりっぱなし」から「経験が積み上がる」ものへと質的に変わった。あるエージェントの失敗が記録され、別のエージェントがそれを検索して回避できる。設計判断がADRとして残り、半年後に「なぜこの構成にしたのか」を遡れる。エージェントの数が増えても、知識は分散せず一箇所に集約されていく。
今後の課題は、ハイブリッド検索とLLM再ランキングのコスト最適化、類似度判定の精度向上、そして肥大化しがちな事例ログの自動的な要約・統合だ。知識ベースは作って終わりではなく、育て続けることそのものが価値になる。エージェントが自らの運用記録を読み、書き、改善のループを回す——その基盤がようやく形になった。
まとめ
AIエージェント専用の知識ベース「LLM Wiki」は、(1) 生データと整理済みナレッジを分離した明確な構成、(2) テンプレートとOpen Knowledge Formatによる標準化されたメタデータ、(3) MCPツール群による統一されたアクセス経路、という3つの柱で成り立っている。人間とエージェントが同じルールで知識を読み書きし、検索で過去の経験を呼び戻す。マルチエージェント時代の「組織の記憶」をどう設計するか、その一つの実装例として参考になれば幸いだ。
参考ソース
- LLM Wiki Schema（自Wiki運用ルール）, 2026
- Open Knowledge Format (OKF) 導入レポート（自Wiki cases）, 2026-06-15
- MCP Proxy 統合レポート（自Wiki cases）, 2026-06-21
- Google Cloud, "How the Open Knowledge Format can improve data sharing"