【ITニュース解説】How to build an LLM wiki for a codebase with Claude Code (measured: 21 pages, 12 minutes, $6.96)

近年、大規模言語モデル（LLM）の進化は目覚ましく、ソフトウェア開発の現場にもその活用が広まっている。中でも注目されているのが、LLMを使ってコードベースの「Wiki」を構築し、運用するアプローチである。これは単なるコードの自動生成にとどまらず、開発プロジェクトにおける知識管理のあり方を大きく変える可能性を秘めている。

今回紹介する記事では、Claude CodeというLLMエージェントを利用して、実際のPythonライブラリ「Pallets/itsdangerous」のコードベースからWikiを作成する具体的な手順と、その効果が詳細に解説されている。システムエンジニアを目指す初心者にとって、これはLLMが開発現場でどのように役立つのか、その具体的なイメージを掴む良い機会になるだろう。

LLM Wikiとは、従来のAPIドキュメントやコード内のコメントとは異なる目的を持つ。APIドキュメントは「何をどう使うか」を説明するのに対し、LLM Wikiは「なぜそのように作られたのか」「どのような設計上の意思決定があったのか」「モジュール間はどのように連携しているのか」「私たちのアプリケーションではどう使うと決めたのか」といった、コードの「行間」に隠された、より深い情報を記録するものだ。これは、長年の開発によって蓄積された、明文化されていない知識（暗黙知）を形式知として引き出し、チーム全体で共有するための重要な手段となる。

このLLM Wikiが機能するための最も重要なルールは、「すべての主張は情報源を明記する」という点である。具体的には、コードの特定のファイルと行番号、変更履歴のエントリー、あるいは会話から得られた情報であることを示し、エージェントが情報源を特定できない場合は「情報源なし」と明記する。この厳格なルールは、LLMが時に事実とは異なる情報を生成してしまう「幻覚（Hallucination）」を防ぎ、Wikiの信頼性を保証するために不可欠である。

実際にLLM Wikiを構築する手順は以下の通りだ。まず、対象となるコードベースをクローンし、Claude Codeに専用のプラグインをインストールして開発環境を準備する。次に、エージェントに「この署名ライブラリのアーキテクチャと設計上の決定を捉えるWikiを初期化する」という指示を与える。するとエージェントはプロジェクト名や適切なカテゴリ（例えば「decisions/」や「architecture/」）を自動で設定し、Wikiの基本的な構造（ひな形）をコミットする。この初期設定の段階で、わずか40秒、5回のやり取りで完了し、費用も約0.68ドルと非常に効率的である。

ひな形が完成したら、いよいよコードベースからWikiを構築する。エージェントに対して「このコードベースからWikiを構築せよ。ソースはsrc/itsdangerous/.py、CHANGES.rst、docs/.rstである。wiki/architecture/にはモジュールごとのページと概要ページを、wiki/decisions/には変更履歴やコードから特定できる設計上の決定を、それぞれ日付と却下された代替案、情報源を明記して記述せよ」といった具体的な指示を与える。この指示に従い、エージェントはコードを解析し、9つのアーキテクチャページと12の決定ページ、合計21ページ、8,441ワードものWikiコンテンツを生成した。このプロセスは約8分弱で完了し、費用は約4.08ドルだった。驚くべきは、エージェントが指示の誤り（例えば、日付の誤り）を訂正したり、情報源が見つからないクレームを正直に「情報源なし」と明記したりする点である。これにより、Wikiの情報の正確性が保たれる。

Wikiが構築されたら、その価値はさらに高まる。例えば、「SECRET_KEYをローテーションした場合、古い鍵で署名されたトークンはまだ検証できるか、そのコストはどうか？」といった質問をエージェントに投げかけると、エージェントはWikiや必要に応じてソースコードを読み込み、詳細な回答を生成する。もしWikiにその情報が不足していれば、エージェントは自動的にソースコードから情報を抽出し、「Cost of rotation」といった新しいセクションをWikiに書き戻し、コミットする。これにより、一度調べられた情報はWikiに蓄積され、次の人が同じ質問をしたときに、より迅速かつ低コストで回答が得られるようになる。実際に、同じ質問を再度投げかけた場合、最初のクエリが約2分、1.12ドルかかったのに対し、2回目はわずか20秒、0.47ドルで完了し、Wikiが効率性向上に貢献していることが明確に示された。

また、開発チーム内で下された決定事項も、エージェントを通じて簡単にWikiに記録できる。例えば、「レビューの結果、SECRET_KEYリストには最大3つの鍵を保持し、30日ごとに最も古いものを削除することにした」といった決定を指示すると、エージェントは既存の関連ページにその決定を追記し、却下された選択肢や派生する疑問点まで記録する。

一連のプロセス全体にかかった時間は約11分40秒、総費用は約6.96ドルと、非常に短時間かつ低コストで実用的なWikiを構築できることが示された。

もちろん、この新しいアプローチにも課題は存在する。例えば、エージェントが意図せずリモートリポジトリにプッシュしようとした問題や、Gitのコミット履歴が不十分な「浅いクローン」では、過去の設計決定に関する情報源が見つからないケースがあった。これらの課題は、開発者側の適切な設定や、ツールキットの改善によって解決されていく見込みである。また、ユーザーが与えるプロンプトに誤った事実が含まれている場合でも、エージェントはそれを訂正する賢さを持つが、最終的なチェックは人間の目で行うことの重要性も指摘されている。

LLM Wikiは、特に次のような場面で大きな価値を発揮する。まず、コードベースに文書化されていない設計上の決定が多く、それらを繰り返し調査する開発者がいる場合だ。この事例では約1,200行のライブラリから12もの決定ページが生成されており、多くのコードベースが抱える暗黙知の量が示唆されている。次に、LLMエージェントを複数回利用するプロジェクトである。一度の質問でWikiに情報が追加されれば、次回の同じ質問のコストが大幅に削減されるため、繰り返しの利用でコストメリットが生まれる。そして、何よりも重要なのは「情報源の明記」という原則を徹底できる場合である。情報源なしに推測が混じったWikiは、かえって混乱を招き、ない方がましであるため、この原則は厳守すべきである。

このLLM Wikiは、一度きりのコードベースや、既存のドキュメントが「なぜ」という問いに十分に答えているコードベースには不向きかもしれない。しかし、複雑な歴史を持つコードベースや、新しいメンバーが加わる際の知識共有、あるいは開発チームが直面する設計上の意思決定を効率的に記録・共有する手段として、LLM Wikiはソフトウェア開発の生産性と品質を飛躍的に向上させる可能性を秘めていると言える。