Tree-sitter を使用してコードの構造図を作成し、変更されたファイルからその「爆発半径（影響範囲）」を追跡することで、AI は影響を受けるファイルのみを読み込みます。これにより、平均してトークン消費量を 8.2 倍削減できます。
最近、Claude Code や Cursor を使ったコードレビューで、トークン消費量が異常に多いという現象に気づきました。ほんの数行の小さな変更なのに、プロジェクト全体のファイルをすべて読み込んでいるのです。
最初は私の使い方に問題があるのかと思いました。しかし、すぐに理解しました。これが現在のあらゆる AI コーディングツールのデフォルトの挙動なのです。これらのツールにはコード構造の概念がなく、どのファイルが変更と関連し、どれが無関係かを理解していません。そのため、最も安全な戦略として「すべてを読み込む」ことを選んでいるのです。
これはまるで、台所の蛇口を直しただけなのに、配管業者が建物全体の配管図をすべて見直すようなものです。安全でしょうか？ええ。合理的でしょうか？いいえ。
今回ご紹介するcode-review-graph（スター数 9700）というプロジェクトは、まさにこの問題を解決するものです。私がこのプロジェクトの具体的な実装以上にその中核的な発想に注目したい理由は、それが見過ごされてきた事実、つまりAI コーディングツールのボトルネックはモデルの能力ではなく、入力される情報の質にあることを浮き彫りにしているからです。
「爆発半径」――この概念がプロジェクトの魂
code-review-graph が最初に行うのは、Tree-sitter を使ってコードベースを 1 つのグラフ（構造図）として解析することです。
全文検索でもなく、ベクトル埋め込みでもなく、真の意味での構造図です。各関数がノードとなり、各クラスがノードとなり、関数から関数への呼び出しがエッジ（辺）となり、クラスの継承関係もエッジとなります。インポート関係やテストのカバー範囲もすべてエッジとして表現され、コードベースは「誰が誰に依存しているか」という関係のネットワークへと変貌します。
ここで重要なのが、あるファイルを変更した際、ツールはコード全体を再分析するのではなく、そのファイルを出発点としてエッジをたどり、影響を受ける可能性のあるすべてのノードを追跡する点です。これらのノードこそが、その変更の「爆発半径（blast radius）」となります。
ユーティリティ関数を 1 つ変更しただけでも、グラフはそれを呼び出している 8 つのファイルと、そのうち 3 つにテストカバレッジがあり、5 つにないことを示します。AI が必要なのは、この 8 つのファイルを読み、テストカバレッジのギャップを確認することだけ。残りの数百のファイル？今回の変更とは無関係なので、1 トークンも消費する必要がありません。
率直に言って、このアプローチはあまり「AI 的」ではありません。本質的には静的解析であり、コンパイラ工学の授業で習うような古典的な技術です。しかし、この「古い道具で新しい問題を解決する」という発想には感銘を受けます。誰もがモデル性能やプロンプトの工夫にしのぎを削る中、モデルに与える情報そのものに問題があるのではないかと、一歩引いて考える人はほとんどいません。
実測データ：6 つのオープンソースプロジェクトで平均 8.2 倍の削減
これは適当に推測した数字ではありません。このプロジェクトにはベンチマーク機能が備わっており、6 つの実際のオープンソースリポジトリ（express、fastapi、flask、gin、httpx、nextjs）で 13 回のコミット評価を実施しました。
| プロジェクト | グラフ不使用（元のトークン数） | グラフ使用（グラフ適用後のトークン数） | 削減倍率 |
|---|---|---|---|
| flask | 44,751 | 4,252 | 9.1 倍 |
| gin | 21,972 | 1,153 | 16.4 倍 |
| fastapi | 4,944 | 614 | 8.1 倍 |
| nextjs | 9,882 | 1,249 | 8.0 倍 |
| httpx | 12,044 | 1,728 | 6.9 倍 |
| express | 693 | 983 | 0.7 倍 |
gin では16.4 倍もの削減に成功しました。元々 22,000 トークン読む必要があったコードが、今や 1,153 トークンで済むのです。
express の行だけ数値が増加していますが、著者も率直に認めています。単一ファイルの小さな変更の場合、グラフ固有の構造メタデータ（エッジ、ノードタイプ、レビュー指針など）が、元のファイルサイズを上回ってしまうためです。こうした正直な限界の説明があるからこそ、私はこのデータセットをより信頼できます。
さらに印象的だったのが、影響分析の再現率（Recall）が100%であった点です。つまり、グラフが追跡した「爆発半径」から、実際に影響を受けるファイルが漏れることは決してありません。一方、適合率（Precision）は 0.38 に留まり、若干の過剰報告は見られます。しかし、コードレビューという文脈では、バグを 1 つ見逃す方が、ファイルを数多く読み直すよりもはるかに深刻です。このトレードオフに対する判断は非常に明晰だと言えます。
技術的には驚くほど軽量
正直なところ、こうしたプロジェクトにはベクトルデータベースが必要か、あるいはコード理解のためのモデルを動作させる必要があると思っていました。しかし、その中核技術スタックは以下の通りです。
- Tree-sitter：AST（抽象構文木）を解析。19 言語および Jupyter notebooks をサポート
- SQLite：グラフはローカルの
.code-review-graph/ディレクトリ配下のファイルに保存 - SHA-256 ハッシュ：ファイルの変更を検知し、変更された部分のみを再解析
GPU も、クラウドサービスも、外部データベースも不要です。500 ファイル規模のプロジェクトでも初回構築は約 10 秒、その後の差分更新は 2 秒未満。2900 ファイル規模のプロジェクトでも、差分更新はやはり 2 秒未満で完了します。
このツールは MCP（Model Context Protocol）を介して AI ツールと連携しており、現在は Claude Code、Cursor、Windsurf、Codex、Zed などをサポートしています。インストールは以下の 2 行のコマンドのみです。
git clone https://github.com/tirth8205/code-review-graph.git
cd code-review-graph
python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"22 種類の MCP ツールと、5 つのワークフローテンプレート（レビュー、アーキテクチャ分析、デバッグ、新人向けオンボーディング、マージ前チェック）を備えています。スター数 9700 のプロジェクトとして、その機能カバレッジは非常に完成されていると言えるでしょう。
興味深いディテールとして、このツールはコミュニティ検出も可能です。Leiden アルゴリズムを用いてコードノードをクラスタリングし、どのモジュールの結合度が高く、どれがアイランド（孤立した存在）なのかを特定。アーキテクチャの概要や Markdown 形式の Wiki を自動生成します。もはや単なるコードレビューツールではなく、コードベースの「健康診断レポート生成ツール」とも言えるでしょう。
大胆な予測
code-review-graph を見て、より大きな問題に気づかされました。現在のすべての AI コーディングツールにおけるコンテキスト管理が、あまりに乱暴すぎるということです。
モデルはますます高性能になり、コンテキストウィンドウも巨大化していますが、「モデルに何を見せるべきで、何を見せるべきではないか」を真剣に考えた人はほとんどいません。コードベース全体を丸ごと放り込むことは、コスト（トークンは無料ではない）の浪費であるだけでなく、質の低下（「lost in the middle」効果。重要な情報が無関係なコードの海に埋もれてしまう現象）も招きます。
code-review-graph のアプローチは 1 つの兆候です。次世代の AI コーディングツールを巡る競争は、モデルの能力ではなく、「コンテキスト・エンジニアリング」の領域で繰り広げられるでしょう。いかに正確にモデルへ情報を供給できるかが、成果の明暗を分けます。
推奨記事
Anthropic "漏洩"Claude Mythos 最強モデルは実際にどこまで凄いのか？
Memento-Skills VS OpenClaw：モデルを変更せずに進化させることは可能か
Agent が記憶喪失になったら？Anthropic が教える確実な引継ぎ術