はじめに

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

この記事でわかること

• ソースコード → ナレッジ自動生成の2段階パイプライン設計

• 関数単位の解析ステップ（Step 1）の仕組みと出力

• レイヤー別ドキュメント統合ステップ（Step 2）の仕組みと出力

• 生成結果の品質と課題

対象読者

• 社内ナレッジの自動化に興味がある方

• LLMを使ったコード解析・文書生成に取り組んでいる方

全体アーキテクチャ

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

ソースコード
    ↓
[Step 1: 関数単位の解析]
  各関数を個別にLLMで解析
  → 関数ごとの説明・入出力・依存関係を抽出
    ↓
[Step 2: レイヤー別ドキュメント統合]
  関数解析結果をアプリケーション単位で統合
  → 4つのレイヤーに分類してドキュメント生成
    ↓
要件定義書 / 仕様書 / 詳細設計書 / 解説ドキュメント

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

まとめ

• ソースコードからのナレッジ自動生成は、関数単位の解析 → レイヤー別統合の2段階で実現できる

• 4つのレイヤー（要件定義/仕様/設計/解説）に分けることで、読者の目的に応じた情報提供が可能

• 生成ドキュメントをRAGの検索ソースに統合することで、コードベースに対する質問応答システムを構築できる