前書き
コーディングエージェントに改修を依頼するたびに、「この修正はどこまで影響するんだろう」と、同じ調査を何度もやり直させた経験はないでしょうか
社内の仕様書や設計ドキュメントをベクトルDBに入れて、エージェントに検索させる構成を組んでいる方も多いと思います。
ドキュメントの中身自体は正しく引けるものの、同じ質問をするたびにベクトル検索の結果から答えを組み立て直すため、聞くたびに微妙に言い回しが変わったり、検索コストがじわじわ積み上がったりする——そんな感覚に心当たりはないでしょうか。
この課題を解決する考え方として、「 LLM Wiki 」というアプローチがあります。
本記事では、まず従来の検索型ツールが抱える限界を振り返り、次に「LLM Wiki」という考え方を整理し、最後に、OpenWikiという「LLM Wiki」に似た仕組みを持つライブラリーを動かすところまでを紹介します。
内容は2026年7月28日時点の情報です。OpenWikiは公開から日が浅く更新が速いツールなので、コマンドやバージョンは公式リポジトリで最新を確認してください。
エージェント指示ファイルとグラフRAGツールの限界
コードベースをコーディングエージェントに理解させる方法は、大きく2つに分けられます。
ひとつは、CLAUDE.md や AGENTS.md といったエージェント指示ファイルにルールを書いておくやり方です。
もうひとつは、Bedrock Knowledge Bases や GitNexus のようなサービス・ライブラリを使い、コードやドキュメントをナレッジ化して、検索用ツールとしてエージェントに渡すやり方です。
どちらも便利ですが、それぞれに課題があります。
-
ひとつめは、質問のたびにツールを叩き直すコストです
グラフ経由の情報取得は、クエリごとにグラフを辿って毎回組み立て直されます。10回目の答えが1回目より良くなるわけでもないのに、同じ探索コストを10回払い続ける——そんな構図になりがちです。 -
ふたつめは、
CLAUDE.mdのようなドキュメントは、自分で更新しない限り古くなっていく点です。実装が変わってもドキュメントは変わらないため、気づかないうちにエージェントへ嘘の情報を渡していた、ということが起こります
Anthropicの公式ブログではでは、コードベースがうまくエージェントに認識させてる企業に共通する運用パターンとして、次のような点が挙げられています。
-
CLAUDE.mdはフォルダごとに階層化し、簡潔に保つ - LSPを導入し、探索を正確にする
- 個人任せにせず、チームの責任者が標準を決める
さらに、AIモデルが新しくなるたびに、過去の制限を補うために書いた古い指示が、今度は新しいモデルの足を引っ張ることになります。そのため、3〜6ヶ月ごとの定期的な見直しが必要だとも書かれています。
結局のところ、指示ファイルを鮮度高く保つことや検索ツール自体が、組織的な運用コストとして重くのしかかってくるわけです
LLM Wikiの考え方
そもそもWikipediaのようなWikiは、誰かが情報を調べて整理し、ページにまとめておくことで、次に同じことを知りたい人はそのページを読むだけで済むようにする仕組みです。
「LLM Wiki」は、そのページを書いて整備する役目を人間ではなくエージェントに任せる、いわばエージェントたちが維持管理するWikiという考え方です。
考え方自体はシンプルで、
質問されたときではなく、データを取り込んだときに情報を作っておくというものです
RAGは質問のたびに生データから答えを組み立て直しますが、LLM Wikiはソースを読む作業を最初に一度だけ行い、その結果をMarkdownページとして残します。
ソースが変われば、そのページだけを更新すればいい。
構造は3層です。
- ソースドキュメント（記事・コードなど）
- Wiki（モデルが書くMarkdownファイル。要約とページ間リンクを持つ）
- スキーマファイル（
CLAUDE.mdやAGENTS.mdなど、Wikiの構造とやるべき作業をモデルに指示する）
2026年4月、Andrej Karpathy氏がGitHub Gistでこの手法を書き、「LLM Wiki」と名付けました。
その後、Cognition社の「DeepWiki」、LangChain社の「OpenWiki」などと、似た仕組みを持つツールが立て続けに出てきています。
| ツール | 開発元 | 特徴 |
|---|---|---|
| DeepWiki | Cognition | 公開GitHubリポジトリ向け。URLのgithub.comをdeepwiki.comに変えるだけで生成 |
| AutoWiki | Factory | CI/CDに組み込み、コード更新のたびに自動再生成 |
| OpenWiki | LangChain | OSS。コードだけでなくGmail/Notion/X等も取り込める「Personal Brain」機能 |
| GBrain | Garry Tan | Gitリポジトリ内のMarkdownだけで完結するシンプル版 |
限界もちゃんと書かれていて、ソース数が100件を超えるあたりから検索ツールとの併用が要るとのことです。
OpenWikiを試す
というわけで、実際にOpenWikiを手元のリポジトリに向けて動かしてみます。
OpenWikiはLangChain社が2026年7月1日に公開したOSSのCLIです。
GitHubリポジトリの作成は2026年6月22日、この記事を書いている時点の最新バージョンはv0.2.4、スター数は13,000超えとかなりのペースで伸びています。
コードベース用のCode modeと、Gmail・Notion・Xなどの個人データをまとめるPersonal modeの2モードがあり、今回はプロジェクトのコード理解が目的なのでCode modeを使います
インストールと初期化
npm install -g openwiki
# or
pnpm add -g openwiki
インストールが完了したら、openwikiを初期化したいプロジェクトに入り、下記のコマンドを使って初期化を行います。
openwiki --init
私の場合、一度別のプロジェクトに対して初期化を行っていたため、次に別のプロジェクトで実行した際に前回の設定が記憶されており、下記のようなインターフェースが表示されました。
% openwiki --init
╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ OpenWiki first-run setup │
│ Configure the model, wiki scope, and sources. │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
Detected from your command
✓ Run mode Code
✓ Wiki scope openwiki/
Set up
❯ Provider AWS Bedrock
✓ AWS credentials legacy Bedrock keys (take precedence)
✓ Region us-east-1
✓ Model us.anthropic.claude-sonnet-5
✓ LangSmith configured
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Prompt │
│ Choose a model provider. │
│ OpenAI (openai) default │
│ OpenAI (ChatGPT login) (openai-chatgpt) │
│ Anthropic (anthropic) │
│ GitHub Copilot (copilot) │
│ Gemini (AI Studio) (gemini) │
│ Gemini Enterprise (Vertex AI) (gemini-enterprise) │
│ OpenRouter (openrouter) │
│ OpenAI-compatible (openai-compatible) │
│ > AWS Bedrock (bedrock) │
│ Fireworks (fireworks) │
│ Baseten (baseten) │
│ Nebius Token Factory (nebius) │
│ NVIDIA NIM (nvidia) │
│ Use up/down arrows, then press Enter. │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
注意点として、今回はbedrockを使って初期化しましたが、bedrockを使用する場合、現状はAPIキーやSSOのアクセスキーが使用できません。
IAMユーザーを作成し、下記の権限もしくはAmazonBedrockFullAccessを付与したうえで、発行されたアクセスキーを使ってください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeModel",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:*::foundation-model/*",
"arn:aws:bedrock:{{<region>}}:{{<account-id>}}:inference-profile/*"
]
}
]
}
bedrockを使う場合、IAMユーザーのアクセスキー以外に、どのリージョン・どのモデルを使うかも入力する必要があります。
また、LangSmithにトレースを送るかどうかのオプションも出ますが、無料で使えるので有効にしておきましょう。
必要なのはLangSmithのAPIキーなので、Settingsから「API Keys」に入って作成し、貼り付けましょう。
その後、どんなプロンプトでWikiを初期化するか聞かれますが、最初はデフォルトの設定のままで問題ありません。
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Prompt │
│ Customize what this wiki should understand. │
│ Mode: Code │
│ Edit the brief below. Keep what is useful, delete what is not. │
│ │
│ Edit wiki brief │
│ ┌──────────────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ > A code wiki for this local repository. Prioritize a concise quickstart, architecture overview, │ │
│ │ source map, key workflows, domain concepts, operations/runbook notes, testing guidance, and │ │
│ │ integration points. Inspect git history to understand reasoning behind code changes and the │ │
│ │ progression of the repository. Keep pages grounded in the repository structure and recent code │ │
│ │ changes. Prefer practical navigation for engineers over generic summaries. │ │
│ └──────────────────────────────────────────────────────────────────────────────────────────────────┘ │
│ Press Enter to continue. │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
esc to go back
これで初期化のための選択肢はすべて終わりです。
次にセットアップの選択肢が出てきますが、Run OpenWiki now を選んで初期化すれば大丈夫です。
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Prompt │
│ Setup is complete. │
│ > Run OpenWiki now │
│ Open chat │
│ Run now writes the initial openwiki/ directory. Open chat skips the initial run. │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
esc to go back
その後、初期化が始まります。
LangSmithと連携していれば、ダッシュボードでトレース情報も確認できます。
今回使用したモデルはSonnet 5です。初期化だけで1.5ドルほどかかりました。
初期化完了後、主な変化は三つです。
1. エージェントの説明ファイル（CLAUDE.mdやAGENTS.md）に、OpenWikiを使うときの注意書きが追加されました。面白いのは、このプロジェクトではGitNexusも使っていたため、GitNexusに関する内容が構造化され、エージェントが迷いにくい構造になっていた点です。
<!-- OPENWIKI:START -->
## OpenWiki
This repository uses OpenWiki for recurring code documentation. Start with `openwiki/quickstart.md`, then follow its links to architecture, workflows, domain concepts, operations, integrations, testing guidance, and source maps.
The scheduled OpenWiki GitHub Actions workflow refreshes the repository wiki. Do not hand-edit generated OpenWiki pages unless explicitly asked; prefer updating source code/docs and letting OpenWiki regenerate.
<!-- OPENWIKI:END -->
<!-- GitNexus:START -->
...GitNexusの説明
<!-- GitNexus:END -->
2. GitHub Actionsのワークフローが作られ、コードベースの変更に合わせてWikiの更新を行ってくれます。
3. openwiki/ ディレクトリが作られ、Wikiページ本体がそこに書き出されます。
実際に手元のプロジェクトで初期化した結果、中身はこんな構成になっていました。
-
index.md— 全体のエントリポイント -
INSTRUCTIONS.md— Wikiに何を書かせるかのブリーフ -
quickstart.md— クイックスタートページ -
architecture/— アーキテクチャ概要や主要ワークフロー -
domain/— ドメイン知識 -
operations/— 運用・開発ガイド
architecture/・domain/・operations/のようなカテゴリディレクトリには、それぞれの中にもindex.mdがあります。これは配下のページへのリンクと一言説明をまとめた、いわば章ごとの目次です。
個々のページ（quickstart.mdなど）にはYAML frontmatterでtype・title・description・tagsが付与されており、機械的にも扱いやすい形になっています。
---
type: Quickstart
title: {project_name}クイックスタート
description: 説明
tags: [quickstart, overview, amplify, bedrock]
---
# {project_name}クイックスタート
## これは何か
......
また.last-update.jsonには最終更新日時・実行したコマンド・そのときのgitのHEAD・使用モデルが記録されていて、Wikiがどの時点のコードに基づいて書かれたものかを追跡できるようになっていました。
{
"updatedAt": "2026-07-28T01:30:33.244Z",
"command": "update",
"gitHead": "xxxx",
"model": "us.anthropic.claude-sonnet-5"
}
Wikiを最新の状態に保つには、下記のコマンドで更新をかけます、ただコスト発生するため、要注意です。
openwiki --update
Personal modeの内容
ここまで紹介したのはリポジトリのコードを対象にしたCode modeですが、OpenWikiにはもうひとつ、個人のデータを取り込んで~/.openwiki/wikiにまとめるPersonal modeがあります。
対応コネクタはGmail・Notion・X・Web Search（Tavily経由）・Hacker News・ローカルGitリポジトリで、同じ種類のコネクタを複数登録して並行運用することもできるとのことです。
openwiki personal --init
openwiki ingest all
初期化はopenwiki personal --init、更新はopenwiki personal --updateで行い、OAuthが必要なコネクタ（Gmail・Notion・Xなど）は事前にopenwiki auth <provider>で認証しておく必要があります。
全コネクタをまとめて取り込みたいときはopenwiki ingest all、特定のコネクタだけならopenwiki ingest web-searchのように名前を指定して実行します。
内部的には、まず認証情報つきのネットワーク呼び出しだけを済ませて生データを保存し、そのあとで合成用のエージェントがそのデータを読んでWikiページを書き直す、という2段構えの処理になっています。
クレデンシャルが必要な処理とLLMが動く処理を分けているのは、地味ですが安心できる設計です。
.openwikiignore で読ませたくないパスを除外
リポジトリ直下に.openwikiignoreを置くと、.gitignoreと同じ書き方（コメント・空行・*や**のglob・ディレクトリ指定・!による除外）で、Wikiに読ませたくないパスを指定できます。
secrets/
*.log
!logs/keep.log
指定したパスはファイルシステム探索の段階で除外され、生成されたページにも登場しません。
ただし完全な機密保持の仕組みではなく、テストやREADME、コミットメッセージ、既存Wikiなど他の手がかりから、モデルが除外領域の存在を推測して書いてしまう可能性はある、と明記されています。
テレメトリについて
OpenWikiはデフォルトで匿名の利用テレメトリを送信します。集められるのはコマンド（init/update）と成否、失敗時の大まかなエラー種別、initのときのモード・プロバイダー・設定したコネクタ名程度で、ファイルの中身やリポジトリ名、認証情報、プロンプト、モデルの出力、エラーメッセージ本文などは対象外とされています。
気になる場合は、環境変数OPENWIKI_TELEMETRY_DISABLED=1（または業界標準のDO_NOT_TRACK=1）で無効化できます。
--telemetry-file=<path>を付けて実行すると、実際に送られる内容をそのままファイルで確認することもできます。
最後に
実際に触ってみて一番腑に落ちたのは、ツールの便利さよりも「LLM Wiki」という考え方そのものでした。質問のたびに生データから答えを組み立て直すRAGと違い、データを取り込むタイミングで一度だけコストを払っておく。人間だとすぐ陳腐化するWikiのメンテナンスも、面倒くさがらないエージェントになら任せられる、というのが肝です。
まずは手元の小さいリポジトリで試してみるのが一番早いです。案外あっさり動きます