TL;DR: tree-sitterでコールグラフを構築し、間接的な呼び出し関係を1クエリでAIエージェントに提示する、codegraphというコード知識グラフツールを実際に自社リポジトリへ導入し、過去最も往復の多かったレビュー事例で検証した。結果、コールグラフ問い合わせで検出できたのは4箇所中2箇所のみ。残り2箇所は、問題の中心となる関数を直接呼んでおらず、同じ判定条件を独立に再実装していた「呼び出し関係のない重複コード」だったため、コールグラフ上では2つがつながっておらず、この問い合わせ方法では検出できなかった。ツールの謳い文句(間接呼び出しの見落とし対策)と、自分たちの実際の障害モード(独立実装の重複)が噛み合っていなかった、という話。
あるMedium記事が、Andrej Karpathyの発言を引きながら、LLMに同じ調査を毎回やらせるな、構造を一度作って再利用させろ、という趣旨の話を紹介していた[source: Yanli Liu, "Andrej Karpathy's Fix for LLM Memory Works on Code Too", Medium, 2026-07]。この発想をコードベースに適用したツールがいくつか出てきている。その記事で紹介されていたのが、colbymchenry/codegraphというOSSツールだ(2026年7月29日確認。GitHub上では★約6.3万、最終pushは7月24日。2026年1月に作られたことを考えると、半年ほどでここまで伸びたことになる)。tree-sitterでコードをパースし、関数・呼び出し関係をグラフとしてSQLiteに永続化し、MCP経由でAIエージェントに公開する。エージェントは「この関数の呼び出し元は？」と聞かれるたびにgrepして複数ファイルを地道に読み直す代わりに、グラフに1回問い合わせるだけで済む、という触れ込みだ。今回試したのはこのcodegraphだけで、同じ記事で紹介されていた、レビュー特化の姉妹ツールの方は対象外にしている。
面白そうだったので、実際に自社の運用リポジトリに入れてみた。ただし「便利そう」で終わらせず、過去に実際コストがかかった場面で試すことにした。
使っている一番の理由と、実際に一番痛かった場面
自分たちは複数のAIエージェントを組み合わせた開発体制を敷いている。あるAIがコードを実装し、別のAIがそれをレビューする。レビューで指摘が出れば直し、また見てもらう。この往復の回数がそのまま運用コストになる。
社内の運用ルール文書には、ある修正が4箇所に分散した重複ロジックに触れてしまい、レビューが9ラウンドかかった事例が記録されている。ラウンドごとに「前のラウンドで直した箇所は良くなったが、別の重複箇所にはまだ古いロジックが残っている」という指摘が繰り返された。その時のレビュー運用は、diffで変更された箇所を起点にしか見ていなかった。まだ直っていない兄弟箇所を、事前に洗い出す手順を組み込んでいなかったのだ。
これはまさに、codegraphが解決すると謳っている問題に見えた——というのが、当時の自分の理解だった。「この関数を変更したら、他にどこへ影響するか」を1回のクエリで洗い出せるなら、実装する前に重複箇所を全部拾い出せるはずだ。9ラウンドかかった問題が、1ラウンドで済むかもしれない。ただし、この期待が実際に成り立つかどうかは、まだ検証していない仮説にすぎなかった。
実際に試してみた
インストール自体は数秒で終わった。自社リポジトリ(Pythonファイルが400強)をインデックス化するのにかかった時間も3秒程度で、思ったより軽かった。
9ラウンドかかった実例の、中心となる関数に対して「これを呼んでいるのはどこか」「これを変更したら何が影響を受けるか」という、いわゆる呼び出し元探索・影響範囲分析のクエリを投げてみた。結果は、4箇所のうち2箇所しか出てこなかった。見つかった2箇所は、いずれも中心関数を直接呼び出している箇所だった。
残りの2箇所を手作業で確認すると、理由がわかった。この2箇所は、問題の中心関数を呼び出してすらいなかった。同じ判定条件(「この記事は評価が低いから見送る」といった趣旨のフラグ)を、それぞれの場所で独立に再実装していたのだ。呼び出し関係が無い以上、コールグラフ上ではこの2箇所と中心関数はつながっていない。呼び出し元探索・影響範囲分析というクエリの性質上、中心関数との間に呼び出しパスが存在しない箇所は、そもそもこの問い合わせ方法では出てきようがない。
念のため、codegraph自体が備える自然言語での検索機能を使って「この判定条件をチェックしている箇所はどこか」というような聞き方も試したが、こちらは的外れなシンボルを大量に返すノイズの多い結果になった。狙った2箇所には辿り着かなかった。少なくとも今回試した2種類の問い合わせ方法では、という留保付きだが。
「間接呼び出し」と「独立した重複」は別の障害モードだった
ここが今回の一番の気づきだった。codegraphが解決しようとしているのは、「Aを呼んでいるのはBで、Bを呼んでいるのはCで、grepだとCまで辿り着くのに地道な多段階調査が要る」という間接呼び出しの見落としだ。grepでも根気よく追えば辿り着けなくはないが、手間もミスの余地も大きい。これは確かに実在する問題で、ツール側のデモでも実際にそういう例が示されている。
でも、自分たちが9ラウンドも払った代償は、それとは別の障害モードだったらしい。「同じことをする似たコードが、互いを一切呼ばずに複数箇所に存在する」という重複——これはコールグラフをどれだけ丁寧に辿っても出てこない。そこにあるのは呼び出しという"つながり"ではなく、単に似た意図を持つだけの、互いに無関係な別々のコード片でしかないからだ。
流行りのツールの説明を読んで「これで自分たちの問題も解決するはずだ」と思い込みかけたが、実際に自分たちの過去のインシデントに当てはめてみて初めて、両者が別物だと気づいた。今までやっていた対策——重複が疑われたらまずgrepで確認し、見つかったら関係するファイル全体をAIレビューに丸ごと読ませる——は、少なくとも今のところ、このツールを入れた後も置き換えられていない。
副次的に気づいたこと二つ
ツール自体の評価とは別に、導入作業そのものからも学びがあった。
ひとつは、インストーラーの「プレビュー機能」を過信しかけたこと。事前に設定ファイルへの書き込み内容を確認できるオプションがあったので、それで安全性を確認したつもりでいた。ところが実際にインストールを実行すると、プレビューには出てこなかった変更が他にも入っていた。エージェントへのプロンプト送信のたびに起動する自動フックと、エージェント向けの振る舞い指示を追記した新規ファイルだ。プレビューで見せてもらえた範囲と、実際に書き込まれる範囲が一致するとは限らない。確認したつもりで、実は確認できていない部分が残っていた。
もうひとつは、効果測定そのものへの副作用。導入したツールを「毎回許可を聞かれるのが煩わしいから」と自動許可リストに加えたところ、既存の利用状況ログ(どのツールがどれだけ呼ばれ、許可されたか)からこのツールの呼び出しが一切見えなくなることに後から気づいた。便利にしようとした操作が、そのまま「導入前後でどれだけ使われているか」を測る手段を自分で潰す結果になっていた。効果を測りたいツールほど、うっかり自動許可にしてしまう前に一度立ち止まった方がいいのかもしれない。
この先どう見ていくか
今回わかったのは「今回試した2種類の問い合わせ方法で、9ラウンド事例を防げたか」という狭い問いへの答えであって、「導入して日々の作業が楽になるか」というもっと広い効果はまだ測れていない。1週間ほど運用してみて、レビューの往復回数やコストに変化が出るかは別途確認するつもりでいる。ただし、対照群のない前後比較でしかない以上、多少の変化が出たところで、それが本当にこのツールのおかげなのか、他の要因なのかを見分けるのは簡単ではなさそうだ。
コールグラフを辿れば見つかる依存関係と、辿っても見つからない独立した重複。両方が同じ現場に混在しているなら、後者を見つける方法は、結局まだ人間(かAI)がgrepして目で確認するしかないのだろうか。それとも、呼び出し関係ではなく「意味的な類似度」でコードを比較する別のアプローチが、この隙間を埋めてくれるのだろうか。
参考リンク: