code-review-graphとは何か。AIに読ませる範囲を絞るMCP

Claude Code で大規模リポジトリを触ると、無関係なファイルまで読まれてコンテキストが枯渇しがち。

code-review-graph は Tree-sitter でコードをグラフ化し、MCP で「変更の影響範囲」だけを AI に渡します。

GitHub Trending 週次5位、2万1千スター超。

code-review-graphとは。Tree-sitterでコードをグラフ化するMCPサーバー

開発したのは Tirth Kanani さん（GitHub: tirth8205）。

2026年2月末に作成されて以降、5ヶ月弱で GitHub Trending の Python 週次5位に食い込むまで伸びています。

実装は Python 94%・TypeScript 6%、ライセンスは MIT。

やっていることを1行で言うと、「リポジトリ全体を Tree-sitter で構文解析してグラフ化し、AIには変更に関係する部分だけを渡す」。

これが MCP サーバーとして立ち上がるので、Claude Code や Cursor、Windsurf など主要な AI コーディング環境からそのまま呼び出せます。

GitHub - tirth8205/code-review-graph: Local-first code intelligence graph for MCP and CLI. Builds a persistent map of your codebase so AI coding tools read only what matters, with benchmarked context reductions on reviews and large-repo workflows.

Local-first code intelligence graph for MCP and CLI. Builds a persistent map of your codebase so AI coding tools read only what matters, with benchmarked context reductions on reviews and large-rep...

github.com

なお、名前がよく似た colbymchenry/codegraph（6万スター超、2026年7月時点）は全くの別ツールです。

検索で紛れやすいので注意してください。

なぜAIコーディングツールはコンテキストを読みすぎるのか

Claude Code や Cursor に大規模リポジトリで質問すると、関係ないファイルまで探索されて回答が薄まる、という経験ありませんか。

そしてコンテキストウィンドウが埋まってセッションを分割する羽目になる。

原因はシンプルで、AI 側に「どこが関係するか」の事前知識がないので、grep とファイル読み込みで手当たり次第に読むしかない。

数千ファイルのモノレポなら、無関係な UI コンポーネントや古い実装まで一緒に読み込まれます。

業務システムを何本か Claude Code で作っている実感でも、1回の PR レビューで数万〜十数万トークン消費するのは普通に起きます。

ここが「読ませすぎ問題」の根っこです。

MCPで「必要な部分だけ」渡す仕組み。blast radius分析

code-review-graph は、この課題を「事前にコードをグラフ化しておく」というアプローチで解きます。

まずリポジトリを Tree-sitter で AST 解析し、関数・クラス・import をノード、呼び出し・継承・テストカバレッジをエッジとしたグラフをローカル SQLite（.code-review-graph/）に構築します。

ファイル保存や git commit のたびに 200ms 未満でインクリメンタル更新されるので、開発中も常に最新の状態が保たれる。

変更したファイルを渡すと、そのファイルを呼んでいる箇所・依存している箇所・関連するテストという「blast radius（影響範囲）」だけをグラフから抽出して AI に渡します。

つまり AI 側は「変更の周辺で本当に必要な数十ファイル」だけを読めばよくなります。

処理はすべてローカルで完結し、外部にコードを送信しません（local-first と明言されています）。

GitHub Action 連携でも同じで、PR ごとに自動でリスクスコア付きコメントを投稿しつつ、コードは CI runner の外に出ません。

導入方法。pip installから3コマンドでMCP接続まで

Python 環境があれば、3コマンドで動きます。

pip install code-review-graph
code-review-graph install
code-review-graph build

install が MCP クライアント側の設定（Claude Code なら ~/.claude.json 等）を自動で書き換えてくれるので、手動で JSON をいじる必要はありません。

build を1回走らせるとリポジトリのグラフ構築が終わり、以降は保存のたびに差分更新されます。

対応クライアントは Claude Code、Cursor、Windsurf、Zed、Continue、Codex、Gemini CLI、GitHub Copilot、GitHub Copilot CLI など15以上。

MCP ツールは30個提供されていて、get_impact_radius_tool get_review_context_tool detect_changes_tool といった名前で並んでいます。

削減効果の数字を読み解く。6.8倍・49倍・82倍の違い

README・公式サイト・ベンチマークで複数の倍率が並んでいて、初見だと混乱します。

文脈ごとに整理するとこうなります。

つまり「毎回82倍削減される」わけではなく、Q&A 形式のベンチマークで中央値を取るとこの数字になる、が正確です。

日常的な PR レビューで実感するのは6.8倍〜8倍あたり。

大規模モノレポでたまに49倍を超える、というのが体感の落としどころ。

ここを混同すると期待値がズレます。

イメージしやすい実例は、27,700ファイルを超える Next.js モノレポで、レビュー対象を約15ファイルに絞り込んだケース。

全部を読ませたら約74万トークン級の処理が、15ファイル分に収まります。

導入前に確認したい3つのポイント

全プロジェクトに万能ではありません。

導入判断で見るべきは次の3点。

1つ目はプロジェクト規模。

数千ファイル以上のモノレポや、複数モジュールが絡む中〜大規模リポジトリで効きます。

逆に、単一ファイル数百行のスクリプト系や、機能追加が独立している小さめのリポジトリだと、グラフ構築のオーバーヘッドが勝ってしまうことがある。

dev.to の比較記事でも「小規模の単一ファイル変更ではオーバーヘッドが勝つ」と指摘されています。

2つ目は主要言語構成。

Tree-sitter は30以上の言語に対応していますが、code-review-graph 自体は Python フレームワーク（fastapi、flask、django など）で最も精度が出るチューニングです。

JavaScript や Go の非同期フロー検出には制限があるので、フロントエンド中心の SPA では期待値をやや下げたほうが安全です。

3つ目は成熟度。

急伸中のプロジェクトゆえ、GitHub の open issue は執筆時点で87件あります。

プロダクションの CI に組み込む前に、まず開発環境で1〜2週間試して挙動を確認するのが現実的な進め方です。

まとめ。コンテキスト管理の新しい選択肢として

大規模リポジトリで AI コーディングツールを使うと、遅かれ早かれ「読ませすぎ問題」にぶつかります。

code-review-graph はこれを、事前グラフ化 × blast radius 抽出という現実的な設計で解いた MCP サーバーです。

小規模プロジェクトには過剰でも、モノレポや業務システム開発では十分に投資対効果があります。

まずは開発用のリポジトリで pip install からの3コマンドを試して、Claude Code に get_impact_radius_tool を叩かせてみてください。

感触がはっきり変わります。

MCP 経由でリポジトリを扱う設計は、これからの AI コーディング環境の前提になっていく空気があります。

code-review-graph はその選択肢の中でも、いま最も勢いのある1本です。

• 公式リポジトリ: tirth8205/code-review-graph
• Claude Code MCP 公式ドキュメント: code.claude.com/docs/ja/mcp