【設計】LLMを使ったソースコード→ナレッジ自動生成の仕組み

はじめに#

大規模なソースコードベースのナレッジを体系的に整理したい場合、手作業でドキュメントを書くのは非現実的です。本記事では、LLMを活用してソースコードから構造化されたナレッジドキュメントを自動生成するパイプラインの設計を解説します。

全体アーキテクチャ#

パイプラインは2つのステップで構成されます：

flowchart TD
    S[ソースコード] --> P1
    subgraph P1["Step 1: 関数単位の解析"]
        A1[AST で関数を抽出] --> A2[各関数を個別に LLM へ]
        A2 --> A3[説明・入出力・依存関係を JSON で保存]
    end
    P1 --> P2
    subgraph P2["Step 2: レイヤー別の統合"]
        B1[モジュール単位にグルーピング] --> B2[4 つのレイヤーに分類して生成]
    end
    P2 --> D1[要件定義書]
    P2 --> D2[仕様書]
    P2 --> D3[詳細設計書]
    P2 --> D4[解説ドキュメント]

Step 1: 関数単位の解析#

なぜ関数単位か#

ソースコード全体を一度にLLMに渡すと、コンテキスト上限に達したり、出力の焦点がぼやけます。関数単位に分割することで：

• LLMのコンテキストウィンドウに収まる
• 各関数の目的・入出力を正確に把握できる
• 並列処理で高速化できる

処理フロー#

1. ソースファイルをパースして関数を抽出（AST解析）
2. 各関数のコードをLLMに送り、構造化された説明を生成
3. 結果をJSONで保存（関数名、説明、引数、戻り値、依存関係など）

実行規模の例#

• 小規模アプリ: 数十ファイル・百数十関数 → 数分で完了
• 大規模アプリ: 数十ファイル・数百関数 → 十数分で完了

バッチ処理で並列実行することで、数百関数でも現実的な時間で処理できます。

Step 2: レイヤー別ドキュメント統合#

Step 1の関数解析結果を入力として、アプリケーション全体のナレッジを4つのレイヤーに分類・統合します。

4つのレイヤー#

統合の仕組み#

関数解析結果をまとめてLLMに渡し、各レイヤーのドキュメントをMarkdownで生成します。関数数が多い場合は、ファイル単位やモジュール単位でグルーピングしてから統合します。

生成結果の品質評価#

良かった点#

• 関数の入出力・依存関係は正確に抽出される
• レイヤー分けにより、読者の目的に応じた情報にアクセスしやすい
• RAGの検索ソースとして活用すると、具体的な質問に対して正確な回答が得られる

課題#

• LLMが一般知識で補完する場合がある — ソースにない情報が混入するリスク
• 関数数が多いアプリでは統合ステップのコンテキストが長くなり、品質が低下する傾向
• 生成コスト — 数百関数のアプリでは相応のAPIコストが発生する

RAGへの統合#

生成したドキュメントはレイヤーごとにAzure AI Searchのインデックスに登録し、RAGチャットボットの検索ソースとして活用できます。レイヤー別にインデックスを分けることで、質問の種類に応じた適切なコンテキストをLLMに提供できます。

Tips#

参考リンク#

• LLM活用における4つの設計パターン（別記事）
• Azure AI Searchでベクトル検索対応インデックスを作成・移行する方法（別記事）
• RAGチャットボットの検索精度をAPI経由でE2Eテストする方法（別記事）

まとめ#

• ソースコードからのナレッジ自動生成は、関数単位の解析 → レイヤー別統合の2段階で実現できる
• 4つのレイヤー（要件定義/仕様/設計/解説）に分けることで、読者の目的に応じた情報提供が可能
• 生成ドキュメントをRAGの検索ソースに統合することで、コードベースに対する質問応答システムを構築できる