Coding Agent向けにソースコード構造解析を試す：Call Graph、CFG/DFG/PDG、Ansible、Provenanceの使い分け

Coding Agentに大きなrepositoryを読ませるとき、単純にsource fileを大量にcontextへ投入する方法には限界がある。

大きなmodelならかなり読めるが、それでも「どのfileから読むべきか」「どのfunctionが中心なのか」「値がどこから来ているのか」「複数repositoryをまたぐ処理は何なのか」を毎回sourceから探索するのは高コストである。特に小型のlocal LLMでは、repository全体をcontextへ入れる方法は現実的ではない。

そこで、sourceから決定論的に構造情報を抽出し、

Coding Agentが読むべきsourceを絞る
人間がarchitectureを理解する材料にする
refactoring前後の構造差を確認する
小型LLMにはboundedなcontextだけを渡す

という用途に使えないか、homeclusterのPython / Ansible中心のcodebaseでいくつかの解析方法を試した。

今回試したものは次の通りである。

Symbol Index
Call Graph
module / type / provenance
receiver method resolution
Control Flow Graph（CFG）
Data Flow Graph（DFG）
Program Dependence Graph（PDG）
Ansible domain graph
inventory provenance graph
cross-repository contract graph
bounded structural slice

結論から言うと、どれか1つが勝者というより、それぞれ違う層で有用だった。

さらに実際に作ってみると、すべてを同じ頻度で更新するより、

普段は軽量なstructural indexを継続的に最新化し、難しい調査やarchitecture reviewのときだけDeep解析を実行する

という二層構成が良さそうだと分かった。

この記事では、解析手法の一般論から入り、実際に試して分かったメリット・デメリット、Coding Agentへ任せる場合の設計、自動化で気を付ける点、他言語へ広げるときの考え方まで整理する。

ソースコード解析にはいくつかの「深さ」がある

「source codeを解析する」と言っても、何を知りたいかによって必要な解析は違う。

最も単純なのは、fileやsymbolを探すindexである。

repository
  |
  +-- module A
  |     +-- function foo
  |     +-- class Bar
  |
  +-- module B
        +-- function baz

ここから一段進むと、function同士の呼び出し関係を調べるCall Graphになる。

winds.from.oz 技術メモ

Tag: Python