Litho (deepwiki-rs): C4モデルのアーキテクチャ文書をコードから生成するRust製CLI

コードベースの構造把握を、誰がいつ書くのかという問題

新しいメンバーがリポジトリに入るとき、最初に必要になるのは「どのモジュールが何に依存しているか」という地図だ。しかしこの地図は、書いた瞬間から古くなる。READMEの比較表では、手書き文書の側に「Outdated, incomplete, or missing documentation」「Manual updates that fall behind code changes」が並べられている。Lithoが狙うのはこの部分で、コードそのものを入力にして、C4モデル（Context、Container、Component、Code）の4階層に沿った文書を生成する。対象としてREADMEが挙げているのは開発チーム、オープンソースプロジェクト、エンタープライズの開発者、そして「Anyone who hates maintaining outdated docs」と表現されている層だ。つまり読み手として想定されているのは、コードを読めるが文書化の工数は割けないアーキテクトやテックリードである。

解析からC4文書までの流れと、外部ナレッジの注入

READMEによれば、Lithoはコードベースを解析し、コメント・構造・関係性を抽出したうえで、C4モデルの各階層に対応する文書を生成する。生成物はテンプレートシステムで差し替えられる。ここで特徴的なのが External Knowledge Integration で、PDF、Markdown、SQL などの外部文書をナレッジソースとしてマウントし、解析に重ね合わせる仕組みが用意されていると説明されている。コードだけでは読み取れない設計意図や運用ルールを、既存のドキュメントから補う発想だ。もう一つ、Database Documentation という項目も機能一覧に現れる。ただしREADMEの引用範囲はここで途切れているため、データベース文書が具体的にどのスキーマ情報を読み、どの形式で出力するのかは確認できない。テンプレートの差し替えについても、対応する設定キーやファイル配置は示されていない。生成の実体がLLM呼び出しである以上、出力の安定性はプロンプトとモデルに依存する。この点は後述する導入判断に効いてくる。

導入手順: crates.io からのインストールとAPIキー

LithoはRustで書かれ、crates.io に deepwiki-rs として公開されている。READMEのバッジは crates.io のバージョンとダウンロード数を指しており、配布チャネルがcrates.ioであることはここから読み取れる。Rustツールチェーンがある環境なら cargo install deepwiki-rs で入れる形が自然だが、READMEの引用範囲にはインストールコマンドそのものは含まれていないため、正確な引数は本文書では断定しない。設定については、トピックに claude、deepseek、mistral、openai、openrouter が並んでいることから、複数のLLMプロバイダを切り替えて使う設計だと推測できる。APIキーをどの環境変数や設定ファイルのキーで渡すのかは、引用された範囲では不明だ。CI/CDへの統合も機能として挙げられているが、提供されているGitHub ActionsのワークフローバッジはLitho自身のビルド状態を示すもので、利用側リポジトリに組み込むためのActionが公開されているかは分からない。導入前にリポジトリの docs/en と docs/zh を確認するのが早い。

LLM生成物をそのまま文書として扱うリスク

最大の制約は、生成がLLMに依存している点だ。同じコードベースでもモデルやプロバイダを変えれば記述が変わりうるし、解析結果に含まれない依存関係が文書側で補完されてしまう可能性も否定できない。生成物をそのまま正式な設計文書としてコミットする運用は、レビュー工程を挟まない限り危うい。もう一つの制約は言語対応の粒度で、READMEはRust、Python、Java、Go、C#、JavaScriptなどを挙げるが、各言語でどこまで解析できるか（型解決やマクロ展開まで踏み込むか）は示されていない。動的型付け言語やメタプログラミングを多用するコードでは、抽出できる関係性が粗くなる可能性がある。さらに、READMEの冒頭はLithoがTerrainへ発展したと告知しており、「Litho stays the fast, focused C4 doc generator」と位置づけ直している。活発な開発の中心がTerrain側に移っているなら、Lithoに固有の問題がどこまで修正され続けるかは読めない。最終pushが2026年8月、最新リリースが1.5.0（2026年4月）という並びは、停止とまでは言えないが、移行告知と合わせて見ておくべき材料だ。

Terrainという後継と、生成物の使い道の違い

代替として最初に挙がるのは、同じ作者によるTerrainだ。READMEの説明では、TerrainはLithoの上に成り立ち、ナレッジベースをコードと同期させ、対応言語とフレームワークを広げ、Claude Code、Codex、DeepSeek HarnessといったエージェントがACP経由で読める形にする。加えてLitho Bookを内蔵するとされている。違いは生成物の宛先にある。Lithoは人間のチームが読むC4文書を作ることに絞られ、Terrainはエージェントが読む「living map」として位置づけられている。人間向けの設計文書が欲しいだけならLithoの方が対象が明確で、余分な構成要素を抱え込まない。逆に、コーディングエージェントにコードベースの文脈を渡すことが主目的なら、Terrain側を評価する理由がある。もう一つの比較軸は手書きだ。C4モデルを手で維持する場合、図と本文の整合を人が保証できる代わりに、変更のたびに更新コストが発生する。Lithoはこのコストを実行時間に置き換えるが、出力の正しさを保証する仕組みは外部レビューに委ねられる。

ライセンスとメンテナンスの見通し

ライセンスはMITで、商用利用を含めて扱いやすい条件だ。ただし生成物にLLMプロバイダのAPIを介した出力が含まれる場合、その利用条件はLithoのMITライセンスとは別に、選んだプロバイダ側の規約に従う。ここは法務判断の領域なので、導入時に自組織のポリシーと突き合わせる必要がある。メンテナンス面では、リリース履歴が1.2.8（2026年2月）、1.3.0（2026年3月）、1.5.0（2026年4月）と続いており、この期間は継続的に更新されていたことが分かる。一方でTerrainへの移行告知があり、今後の修正がどちらに集中するかはREADMEからは判断できない。LithoをCIに組み込むなら、バージョンを固定して更新を手動で取り込む運用のほうが、生成文書の差分が予期せず膨らむ事態を避けやすい。

導入を決める前に確認すべきこと

向いているのは、C4モデルという共通の語彙でチームの設計文書を揃えたい組織、そしてコード変更のたびに文書を再生成する流れを既に持っているか、これから作れるチームだ。向かないのは、生成物を無レビューで正式文書として扱いたい場合や、動的型付け言語の依存関係を精密に図示したい場合である。導入前に確認したいのは3点。第一に、docs/en 配下のドキュメントで、自分の主要言語がどの程度解析されるか。第二に、APIキーを渡す設定キーと、プロバイダを切り替える記述方法。第三に、TerrainのリポジトリでLitho由来の問題がどう扱われているか。この3点が自組織の要件を満たすなら、1.5.0を固定バージョンとして試す価値はある。満たさないなら、READMEが示すとおりTerrain側から評価を始めたほうが遠回りにならない。

編集部の結論

既存コードベースのC4モデル文書をCIで継続生成したいチームには候補になる。一方、READMEが冒頭でTerrainへの移行を告知しているため、新規導入ではまずTerrain側の状況を確認し、Lithoに留まるなら1.5.0以降のリリースが続いているかをリポジトリで直接確認してから決めるべきだ。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. sopaco/deepwiki-rs on GitHub