Litho（deepwiki-rs）解説｜コードから設計ドキュメントを自動生成するRust製AIエンジン

Q: どうやってインストール・使用しますか？

前提はRust（1.70以降）とCargoです。最も簡単なのはcrates.io経由で、cargo install deepwiki-rsの1行で導入できます（ソースからのビルドも可能）。使い方はシンプルで、deepwiki-rs -p ./my-project -o ./docsのように対象プロジェクトと出力先を指定して実行すると、全ファイルを走査し、コード構造と関係を解析して、C4アーキテクチャドキュメントを生成します。出力言語は--target-language jaで日本語、enで英語を指定できます。AI解析を行うため、LLMプロバイダのAPIベースURLとAPIキー、使用モデル（効率重視モデルと高性能モデルを別々に指定可能）を設定します。前処理や調査の一部段階をスキップするオプションもあります。

Litho (deepwiki-rs): auto-generate architecture docs from code

litho deepwiki-rs documentation rust c4-model ai-docs codebase agent

2026.06.30 1分更新 2026.06.30

A AI Heartland · 編集部

Litho（deepwiki-rs）解説｜コードから設計ドキュメントを自動生成するRust製AIエンジン - AIツール日本語解説 | AI Heartland

Litho（deepwiki-rs）は、ソースコードを解析してC4モデル形式の設計ドキュメントを自動生成するRust製AIエンジン。前処理→調査→生成→検証の4段階パイプラインで、陳腐化しがちな手動ドキュメントを置き換える。C4の4階層、外部知識統合・DB ERD・CI連携、cargoでの導入と日本語出力対応、使いどころと注意点を解説する。

「ドキュメントを書け」と言われて、最後にREADME以上のものを書いたのはいつでしょうか。そして書いたとして、それは 今のコードと一致している でしょうか。設計ドキュメントは、書くのも大変なら、コード変更に追従させ続けるのはもっと大変です。気づけば中身は数か月前のまま、新メンバーは「ドキュメントは信用するな、コードを読め」と言われる——多くのチームが抱える、この“ドキュメント陳腐化”の慢性病。

その病に、AIで処方を出すのが Litho（sopaco/deepwiki-rs） です。掲げるのは「コードを、明快さへ（Turn code into clarity）」。ソースコードを解析し、C4モデル形式の設計ドキュメントを自動生成する Rust製のAIエンジンで、コードベースと常に同期したドキュメントを、数分で生み出します。本記事では、このLithoが何をどう生成し、どこで効くのかを整理します。

Lithoの要点：C4モデルで自動生成、多言語対応、cargo installの1行で導入 — Litho（deepwiki-rs）はコードからC4モデル形式の設計ドキュメントを自動生成するRust製AIエンジン。日本語出力にも対応する。

本サイトはAI関連OSSの解説に特化しているため、本稿では「このツールで結局、何ができる／何の手間が解ける／何の代わりになるのか」という視点で読み解きます。記述は公式READMEの記載に基づき、確定情報と一般的な解釈を区別します。

この記事のポイント

・Litho（deepwiki-rs）はコードからC4モデル形式の設計ドキュメントを自動生成するRust製AIエンジン。
・解く課題は「手動ドキュメントの陳腐化」。コードと常に同期したドキュメントを保つ。
・仕組みは4段階パイプライン（前処理→調査・分析→生成→検証・補修）。ReAct推論とキャッシュで効率化。
・外部知識統合（PDF/MD/SQL）・DBのERD生成・Git履歴分析・CI連携を備える。Rust/Python/Java/Go等に対応。
・cargo install の1行で導入、日本語出力に対応。MITライセンス。LLM APIキー・コスト・人手レビューは前提。

1. Litho（deepwiki-rs）とは — コードから設計書を自動生成

Lithoは、ソースコードを自動解析し、C4モデル形式の包括的なアーキテクチャドキュメント を生成するAI駆動エンジンです。READMEの言葉を借りれば「もう、コード変更に追いつけない手動ドキュメントはいらない。Lithoがドキュメントをコードベースと完璧に同期させ続ける」。生のコードを、コンテキスト図・コンテナ図・コンポーネント図・コードレベルのドキュメントを備えた、美しく構造化されたドキュメントへと変換します。

手動ドキュメントとLithoの対比：陳腐化・書式バラバラの手動から、常に最新・C4構造の自動生成へ — 陳腐化し書式もバラバラな手動ドキュメントを、Lithoはコードから常に最新・C4構造・図つきで自動生成する。

ここで読者が探している「①結局何ができる／②何を解決する／③何を代替する」に当てはめると——① ソースコードから、C4モデルに沿った設計ドキュメント（図つき）を自動生成できる。② 「ドキュメントがコードに追従できず陳腐化する」「書式・構造がバラバラ」「維持に膨大な工数がかかる」という手動ドキュメントの慢性課題を解消する。③ 手で書き、手で更新していた設計ドキュメント作成・保守の作業を、CIに組み込める自動生成で代替できる——という整理になります。

READMEが挙げる「Lithoを使う理由」は、現場の痛点をよく突いています。コード変更とドキュメントを自動同期（もう古びない）、手動作成・保守の数百時間を節約、新メンバーのオンボーディング改善、コードレビューの強化（明確なアーキテクチャの文脈を提供）、コンプライアンス要件への対応（監査可能な自動ドキュメント）、複数言語対応（Rust・Python・Java・Go・C#・JavaScript等）、プロフェッショナルなC4図の生成、CI/CDへの統合（コミットごとに自動生成）。対象は、あらゆる規模の開発チーム、OSSプロジェクト、エンタープライズ、そして「古びたドキュメントの保守が嫌いな、すべての人」です。

手動ドキュメントとLithoの違いを、READMEの「Before/After」に沿って一覧で整理すると、解く課題が鮮明になります。

観点	手動ドキュメント（Before）	Litho（After）
最新性	コード変更に追従できず陳腐化	コードから常に最新を自動生成
書式・構造	バラバラで一貫しない	C4モデルで一貫した構造
図	手描きで腐りやすい	Mermaid図を自動生成・再生成可
維持コスト	手作業で膨大な工数	CIで毎コミット自動更新
オンボーディング	理解しづらく時間がかかる	図つきで把握が速い

なお、Lithoは単体ツールではなく エコシステム を持ちます。生成したドキュメントを閲覧するためのRust製マークダウンリーダー「Litho Book」（Mermaid対応・全文検索・AIによる文書解釈）や、Mermaid図の構文エラーをAIで自動修正する「Mermaid Fixer」など、ドキュメント生成から閲覧・品質維持までを支える周辺ツールが揃っています。これらが連携することで、「生成→閲覧→図の品質保証」という、ドキュメント運用の一連の流れを1つのエコシステムでカバーできます。

2. C4モデルとは — 生成されるドキュメントの構造

Lithoを理解するには、出力フォーマットである C4モデル を押さえる必要があります。これは設計ドキュメントの“設計図”そのものだからです。

C4モデルの4階層：Context→Container→Component→Codeへ段階的に詳細化 — C4はシステムを文脈→コンテナ→コンポーネント→コードへ段階的に詳細化する手法。Lithoは各層をMermaid図つきで生成する。

C4モデルは、ソフトウェアアーキテクチャを 4つの階層 で記述する、広く使われる手法です。地図を「世界地図→国→都市→街路」とズームしていくように、システムを段階的に詳細化していきます。

・Context（コンテキスト）：最も俯瞰的な視点。システムが、外部のユーザーや他システムとどう関わるかという全体像を描く
・Container（コンテナ）：システムを構成する実行単位（Webアプリ・APIサービス・データベース・キュー等）を示す
・Component（コンポーネント）：各コンテナの内部を分解し、構成要素（モジュール・サービス）とその責務を描く
・Code（コード）：コンポーネントの実装レベルの詳細。クラスや関数の関係まで踏み込む

この4階層の利点は、読み手の関心に応じた粒度で全体を見られる ことです。経営層やプロダクトマネージャーはContext図でシステムの位置づけを掴み、アーキテクトはContainer/Component図で構造を把握し、開発者はCode図で実装を追う——同じシステムを、それぞれの視点で過不足なく理解できます。バラバラに書かれた設計メモと違い、C4は「どの粒度の話をしているか」が常に明確なので、コミュニケーションの齟齬が減ります。

Lithoの価値は、この C4の4階層を、人間が手で描く代わりに、コードから自動生成 してくれることにあります。しかも各図はMermaid（テキストベースの作図記法）で出力されるため、バージョン管理しやすく、コードと一緒にGitで追跡できます。手描きの図が「更新されずに腐る」のに対し、Lithoの図は「コードから再生成できる」——この差が、ドキュメントを生かし続けられるかどうかの分かれ目になります。

C4モデルを採用していること自体にも意味があります。設計ドキュメントの自動生成ツールは数あれど、出力が「整理されていない長文の羅列」では、結局読まれずに終わります。C4という確立された枠組みに沿って、粒度ごとに階層化して出力するからこそ、生成されたドキュメントが「実際に使える設計書」になる——この点が、単なるコード要約ツールとLithoを分けるところです。AIに任せる部分（コードの読解・推論）と、人間が積み上げてきた知見（C4という構造化手法）を組み合わせた設計だといえます。

3. 4段階パイプライン — コードを文書化する仕組み

Lithoが「コードから設計書」を実現する中身は、4段階の処理パイプライン です。ここがエンジンの心臓部なので、順に追いましょう。

Lithoの4段階パイプライン：前処理→調査・分析→文書生成→検証・補修 — Lithoは前処理→調査・分析→文書生成→検証・補修の4段階で動く。ReAct推論ループとキャッシュで効率化する。

① 前処理（Preprocessing）。Lithoはまずコードベース全体を走査し、ソースファイルを発見、メタデータを抽出し、プロジェクト構造を解析します。複数言語のファイルを横断的に発見し、ファイル構造を解析して主要コンポーネントを特定、コメントやドキュメント文字列・アノテーションを抽出し、モジュール間の依存関係を識別して、コードベースの包括的な表現 を構築します。

② 調査・分析（Research）。ここがAIの本領です。コード構造を分析して アーキテクチャの意図 を読み解きます。命名規則や構造からアーキテクチャ上の役割を推論し、コンポーネントの境界とサービスの責務を判定、依存関係とデータフローをマッピングし、潜在的なアーキテクチャの匂い（アンチパターン）も検出 します。各コンポーネントの文脈に応じたドキュメントを生成する、という知的な工程です。

③ ドキュメント生成（Generation）。分析した情報を、構造化されたドキュメント形式に組み立てます。C4モデル図を生成し、明確なナビゲーションを備えた階層的なドキュメント構造を作り、関連するコード例と説明を埋め込み、一貫したスタイルと書式を適用、関連するコンポーネントや図への相互参照を追加します。

④ 検証・補修（Verification）。最終段階で品質を担保します。図の構文と一貫性を検証し、ドキュメントのカバレッジの完全性をチェック、不足を特定して改善を提案、Mermaid Fixerと統合して全図が正しくレンダリングされることを保証 し、カバレッジの統計とレポートを生成、目次と索引を作成します。

この一連の流れを図にすると、各段階の連なりが見えてきます。

flowchart TD SRC["ソースコード"] --> P1["① 前処理
走査・構造/依存抽出"] P1 --> P2["② 調査・分析
AIで役割/境界/データフロー推論"] P2 --> P3["③ 文書生成
概要/構成/ワークフロー＋C4図"] P3 --> P4["④ 検証・補修
Mermaid検証/完全性/品質レポート"] P4 --> OUT["高品質な設計ドキュメント"] P2 -.->|"ReAct推論ループ＋キャッシュ"| P2

注目すべきは、調査・分析の段階で ReAct推論ループ（推論と行動を交互に繰り返すエージェント的手法）と キャッシュ機構 を使っている点です。LLM呼び出しはコストと時間がかかるため、結果をキャッシュして再利用し、無駄なAPI呼び出しを避けます。さらに、複数の調査エージェント（System Context Researcher、Domain Module Detector、Workflow Researcher等）が並列に動き、それぞれの分析結果をメモリに蓄積していく——という、洗練されたマルチエージェント構成が、READMEのシーケンス図から読み取れます。Lithoは「AIにコードを読ませてドキュメントを吐かせる」単純なスクリプトではなく、専門エージェントを編成した分析パイプライン なのです。

4. 主要機能 — 外部知識統合・DBドキュメント・CI連携

Lithoの実用性を支えるのが、基本機能を超えた 先進機能 です。READMEが挙げる目玉を見ていきましょう。

Lithoの主要機能：C4図生成・外部知識統合・DBドキュメント・Git履歴分析・CI連携・多言語出力 — C4図生成に加え、外部知識統合・DBのERD自動生成・Git履歴分析・CI連携・多言語出力を備える。

① 外部知識統合（External Knowledge Integration）。コードだけでなく、外部ドキュメントを知識源としてマウント できます。対応形式はPDF（設計図・デザイン文書）、Markdown（技術文書・ADR）、SQL（DBスキーマ）、YAML/JSON（OpenAPI仕様・設定）、テキストなど。これらを architecture・database・api・deployment・adr・workflow といったカテゴリに整理し、特定のエージェントへ的を絞って届ける ことで、生成ドキュメントにビジネス文脈やアーキテクチャ判断を反映できます。コードからは読み取れない「なぜこう作ったか」を補えるのが強みです。

② データベースドキュメント（Database Documentation）。SQLプロジェクトやSQLファイルを自動解析し、ERD図（実体関連図）つきのデータベースドキュメント を生成します。テーブル（スキーマ・列・型・制約・主キー）、ビュー、ストアドプロシージャ、関数、リレーション（外部キー・暗黙の参照）、データフロー（ETL処理）まで網羅し、Mermaidの ER図で関係を可視化します。出力は 6.Database-Overview.md として、サマリ統計表や詳細スキーマとともに生成されます。

③ Git履歴分析・相互参照・CI連携。Git履歴を分析して アーキテクチャの進化を追跡 し、コード要素とドキュメントを相互参照、そして CI/CDパイプラインに統合してコミットごとに自動生成 できます。このCI連携こそが、「ドキュメントを腐らせない」決定打です。コードをpushするたびにドキュメントが再生成されれば、定義上、ドキュメントは常に最新になります。

これらを支える出力構造も整理されています。1. Project Overview（概要・コア機能・技術スタック）、2. Architecture Overview（全体構成・コアモジュール）、3. Workflow Overview（全体フロー）、4. Deep Dive/（技術トピック別の詳細）、5. Boundary-Interfaces（APIエンドポイント・外部連携）、6. Database-Overview（SQLプロジェクトのみ）——という、ナビゲートしやすい階層に出力されます。

5. セットアップと使い方 — cargo install と日本語出力

実際に使う流れを、READMEに沿って確認します。Rust製らしく、導入は驚くほど簡潔です。

前提は Rust（1.70以降）とCargo です。最も簡単なのはcrates.io経由で、1行で導入できます。

cargo install deepwiki-rs

ソースからビルドする場合は、リポジトリをクローンして cargo build --release すれば、target/release にバイナリができます。

使い方も直感的です。対象プロジェクトと出力先を指定して実行するだけ。

# 基本：プロジェクトを解析してドキュメントを生成
deepwiki-rs -p ./my-project -o ./docs

# 出力言語を日本語に指定
deepwiki-rs --target-language ja -p ./my-project

このコマンドは、./my-project の全ファイルを走査し、コード構造と関係を解析して、C4アーキテクチャドキュメントを生成 します。注目は --target-language ja で日本語出力に対応 している点です。英語（en）はもちろん、日本語の設計ドキュメントをそのまま生成できるため、日本語チームにとっての実用性は高いといえます。

AI解析を行うため、LLMプロバイダの設定 が必要です。APIベースURLとAPIキー、そして使用モデルを指定します。Lithoの賢いところは、効率重視モデル（model-efficient）と高性能モデル（model-powerful）を別々に指定できる 点です。

# 効率モデルと高性能モデルを同時指定（コストと品質のバランス）
deepwiki-rs -p ./src \
  --model-efficient GPT-5-mini \
  --model-poweruful GPT-5-Pro \
  --llm-api-base-url <your llm provider base-api> \
  --llm-api-key <your api key>

軽い処理は効率モデルで安く、重い分析は高性能モデルで丁寧に——という使い分けで、コストと品質のバランスを取れる わけです。さらに、前処理や調査の一部段階をスキップするオプション（--skip-preprocessing --skip-research）や、ReActモードを切ってツール呼び出しによる自動ファイル走査を抑えるオプションもあり、用途に応じて挙動を調整できます。外部知識を使う場合は litho.toml で知識源のパスやカテゴリ、チャンク戦略（semantic/paragraph/fixed）を設定し、deepwiki-rs sync-knowledge で同期します。

6. 何を代替するのか — 手動ドキュメントの終わり

最後に、Lithoをどう位置づけ、何に気をつけるべきかを整理します。

Lithoの向く使い方と注意点：初版生成・オンボ資料に向く一方、LLMコスト・人手レビュー・機微コードに注意 — 設計ドキュメントの初版生成やオンボ資料づくり、AIエージェント用の文脈整備に向く一方、LLMコスト・人手レビュー・機微コードの送信可否は要確認。

向くケース：設計ドキュメントの初版を高速に生成したい、新メンバー向けのオンボーディング資料を作りたい、AIエージェント（コーディングアシスタント等）に渡す文脈を整備したい、CIで設計ドキュメントを常時更新したい——こうした用途で、Lithoは大きな時間節約をもたらします。とくに「AIエージェント用の文脈整備」は、近年のAI開発で価値が高まっている用途です。コーディングエージェントは、対象コードベースの構造を理解した文脈があるほど精度が上がります。Lithoが生成する構造化ドキュメントは、READMEも「人間チームにもインテリジェントエージェントにも完璧に構造化された」と謳う通り、AIに読ませる文脈（AI-ready context） としても機能します。

注意すべき点 は3つです。第一に、LLM APIのキーとコスト。AI解析を行う以上、利用するLLMの料金がかかり、巨大なリポジトリほどトークン消費と処理時間が増えます。効率/高性能モデルの使い分けやキャッシュで抑えられますが、コスト意識は必要です。第二に、人手レビュー。AIが設計意図を推論するため、実態と異なる解釈が混じる可能性があり、公開前の確認が望まれます。第三に、機微コードの扱い。ソースを外部LLMに送信してよいかは情報管理上の判断が要り、社内のセルフホストLLMを指定する（base-urlを自前のプロバイダに向ける）などの対策を検討すべきです。

総じてLithoは、「ドキュメントは書いた瞬間から腐り始める」という、ソフトウェア開発の宿命に対する、AI時代の現実的な回答です。手動ドキュメントを完全になくす、というより、初版の生成と継続的な同期をAIに任せ、人間は重要な判断や補足（外部知識統合）に集中する——そんな役割分担が、Lithoの最も賢い使い方です。コードから明快さを取り出すこのRust製エンジンは、cargo install 1行で試せます。腐ったドキュメントに心当たりがあるなら、自分のリポジトリで一度走らせてみる価値があります。

まとめ：ドキュメントの陳腐化に、AIで終止符を打つ

Litho（deepwiki-rs）は、ソースコードを解析してC4モデル形式の設計ドキュメントを自動生成する、Rust製のAI駆動エンジンです。前処理→調査・分析→生成→検証の4段階パイプライン（ReAct推論＋キャッシュ＋マルチエージェント）で、コードからContext/Container/Component/Codeの4階層ドキュメントをMermaid図つきで生成。外部知識統合（PDF/MD/SQL）・DBのERD自動生成・Git履歴分析・CI連携を備え、cargo install 1行で導入でき、日本語出力にも対応します（MITライセンス）。AIエージェント用の文脈整備にも使え、一方でLLM APIコスト・人手レビュー・機微コードの送信可否は要確認。手動ドキュメントの陳腐化に心当たりがあるなら、初版生成と継続同期をAIに任せる新しい運用を、自分のリポジトリで試す価値があります。

まとめ

本記事では、Rust製のAIドキュメント生成エンジン Litho（deepwiki-rs） を、ドキュメント陳腐化への処方箋として読み解きました。

要点は3つです。第一に、LithoはソースコードからC4モデル形式の設計ドキュメント（図つき）を自動生成し、「手動ドキュメントがコードに追従できず腐る」という慢性課題を解くこと。第二に、その中身は前処理→調査・分析→生成→検証の4段階パイプラインで、ReAct推論とマルチエージェント・キャッシュにより、単なる要約を超えた構造的な分析を行うこと。第三に、外部知識統合・DBのERD生成・Git履歴分析・CI連携を備え、cargo install 1行・日本語出力対応で実用性が高い一方、LLMコスト・人手レビュー・機微コードの扱いには配慮が要ること。

ドキュメントは書いた瞬間から腐り始める——その宿命に、Lithoは「初版と同期をAIに任せる」という回答を出します。腐ったドキュメントに心当たりがあるなら、まず cargo install deepwiki-rs で、自分のコードベースを明快さへ変える体験を試してみてください。とりわけ、コーディングエージェントを使い始めたチームにとっては、Lithoが生み出す構造化ドキュメントが「AIに渡す文脈」としても効いてきます。人間のためのドキュメントと、AIのための文脈——その両方を1つの生成で賄えることが、これからの開発でLithoの価値をいっそう高めていくはずです。

参照ソース

・sopaco/deepwiki-rs（公式リポジトリ） — 本記事が解説した一次情報（README・パイプライン・機能）
・deepwiki-rs on crates.io（配布パッケージ） — インストール元・バージョン情報
・Litho Docs（公式ドキュメント） — CLIオプション・設定の詳細

よくある質問

Litho（deepwiki-rs）を一言でいうと？

ソースコードを解析して、C4モデル形式の包括的なアーキテクチャ（設計）ドキュメントを自動生成する、Rust製のAI駆動ドキュメント生成エンジンです。プロジェクト名はLitho、パッケージ名（crates.io）はdeepwiki-rsで、DeepWiki系の『リポジトリからWikiを生成する』ツールにあたります。コード変更に追従できず陳腐化しがちな手動ドキュメントの問題を解決し、コードベースと常に同期した、コンテキスト図・コンテナ図・コンポーネント図・コードレベルのドキュメントを自動で生成します。出力は人間チームにもAIエージェントにも適した構造で、日本語を含む多言語出力に対応します。ライセンスはMITです。

C4モデルとは何ですか？

C4モデルは、ソフトウェアアーキテクチャを4つの階層（レベル）で記述するドキュメンテーション手法です。(1) Context（コンテキスト図）：システムが外部のユーザーや他システムとどう関わるかという全体像。(2) Container（コンテナ図）：システムを構成する実行単位（アプリ・サービス・データベース等）。(3) Component（コンポーネント図）：各コンテナ内部の構成要素。(4) Code（コード図）：コンポーネントの実装レベルの詳細。上位から下位へと段階的に詳細化することで、経営層から開発者まで、それぞれの関心に応じた粒度で全体を俯瞰できます。Lithoはこの4階層を、Mermaid図つきでソースコードから自動生成します。

どういう仕組みで動くのですか？

Lithoは4段階の処理パイプラインで動きます。(1) 前処理（Preprocessing）：コードベース全体を走査し、ソースファイルの発見・構造解析・依存関係の抽出・コメントやドキュメント文字列の抽出を行い、コードの包括的な表現を構築します。(2) 調査・分析（Research）：AIがコード構造から設計意図を読み解き、コンポーネントの境界・責務・データフローを推論し、アーキテクチャの匂い（アンチパターン）も検出します。(3) ドキュメント生成（Generation）：概要・アーキテクチャ・ワークフロー・モジュール詳細などのドキュメントをC4図とともに生成します。(4) 検証・補修（Verification）：Mermaid構文の検証・ドキュメントの完全性チェック・図の自動修復・品質レポート生成を行います。内部ではReAct推論ループとキャッシュ機構で効率化しています。

どんな機能がありますか？

コア機能として、コードベース解析からのアーキテクチャドキュメント生成、C4モデル図（Context/Container/Component/Code）の自動作成、コードコメント・構造・関係の抽出、多言語対応、カスタマイズ可能なテンプレートがあります。先進機能としては、外部ドキュメント（PDF・Markdown・SQL等）を知識源としてマウントする『外部知識統合』、SQLプロジェクトのスキーマからERD図つきのデータベースドキュメントを生成する『データベースドキュメント』、Git履歴の分析によるアーキテクチャ進化の追跡、コード要素とドキュメントの相互参照、CI/CDパイプラインへの統合（コミットごとの自動生成）などがあります。Rust・Python・Java・Go・C#・JavaScriptなど複数言語に対応します。

どうやってインストール・使用しますか？

前提はRust（1.70以降）とCargoです。最も簡単なのはcrates.io経由で、cargo install deepwiki-rsの1行で導入できます（ソースからのビルドも可能）。使い方はシンプルで、deepwiki-rs -p ./my-project -o ./docsのように対象プロジェクトと出力先を指定して実行すると、全ファイルを走査し、コード構造と関係を解析して、C4アーキテクチャドキュメントを生成します。出力言語は--target-language jaで日本語、enで英語を指定できます。AI解析を行うため、LLMプロバイダのAPIベースURLとAPIキー、使用モデル（効率重視モデルと高性能モデルを別々に指定可能）を設定します。前処理や調査の一部段階をスキップするオプションもあります。

利用時の注意点はありますか？

第一に、LLM APIのキーとコストが前提である点です。AIによる解析・生成を行うため、利用するLLMプロバイダの料金がかかります。効率重視モデルと高性能モデルを使い分けることでコストを調整できますが、巨大なリポジトリほどトークン消費と処理時間が増えます。第二に、生成物は人手レビューを推奨する点です。AIが設計意図を推論するため、実態と異なる解釈が混じる可能性があり、公式ドキュメントとして公開する前には確認が望まれます。第三に、機微なコードを扱う場合、ソースを外部LLMに送信してよいかという情報管理の確認が必要です。社内のセルフホストLLMを指定するなどの対策を検討してください。これらを踏まえれば、設計ドキュメントの初版作成やオンボーディング資料づくりを大きく加速できます。