リポジトリ全読みAIレビューは8.7Mトークンで崩れる: 30万行の実測

ある夜、自分の OSS リポジトリに Claude Code を走らせて「全部読んで、この PR をレビューして」と頼みました。素直に読み始めた瞬間、トークンカウンタが跳ね上がり、最終的に 8.7M トークン に到達しました。返ってきたレビューは丁寧で、指摘は 6 項目、テスト命名から型定義まで一通り触れています。

優秀に見えました。

翌朝、読み直して気づきました。変更されたのは 1 ファイルだけなのに、指摘の大半が変更と関係ない場所の話で埋まっていた。本当に見るべきだったロジックバグは、6 項目目の末尾に 1 行だけ、しかも遠慮がちに書かれていて、私は最初に読んだとき完全に読み飛ばしていました。

これが「大きい文脈 = 良いレビュー」という直感の反例です。全部読ませると、AI は全部について語ります。私が知りたかったのは「その 1 行がどこに波及するか」だけでした。

以下、この破綻を実測レベルで分解します。

8.7M トークンの内訳

30 万行規模のコードベース(私の実測対象は Python + TypeScript、依存パッケージ込み)を丸読みさせると、トークンはこう積み上がります。

リポジトリ本体のソースコード: 約 240 万トークン
依存パッケージのソース(node_modules / site-packages 含む): 約 600 万トークン
README、ドキュメント、設定ファイル: 約 30 万トークン
合計: 約 870 万トークン

現代の主要 LLM の実効コンテキストウインドウは、公称値と体感値がずれます。Claude Sonnet 4.6 は 200K トークン、Opus は同等、GPT-5.3 は 400K の枠を持ちますが、いずれも 8.7M は入りません。仮に将来 1M や 10M のモデルが出て枠には入るようになっても、次の問題が残ります。

注意機構の分散です。

入力が長くなるほど、モデルは末尾の重要情報を取りこぼしやすくなる。middle-lost 現象として複数のベンチマーク論文が指摘している通りで、レビュー品質は入力サイズに対して単調増加しません。むしろ 100K を超えるあたりから、意味のある指摘密度は下がり始めます。金銭コストの話はもっと単純です。Sonnet の Input 単価で 8.7M トークンを 1 回舐めさせると、それだけで数十ドルが飛びます。1 日 10 レビュー、5 人チームで回すと、月換算で数万円から十数万円 の追加課金が発生します。1 人分ならまだしも、チーム全体で同じ無駄を繰り返した時点で、ペイラインは軽く飛びます。

「コミット倍速」時代のボトルネックは書くではなく読むに移っている

サイバーエージェントの Developers Blog に印象的な観測があります。Cursor / Claude Code / Codex 導入後、チームのコミット数が 約 2 倍 に増えたという報告です (CyberAgent Developers Blog)。

生産性が倍になったように見えて、記事の本題は別のところにあります。

「コミットが倍に増えた結果、レビュー側がボトルネックになった」

AI が書く速度は上がっても、人間のレビューキャパシティは変わらない。だから彼らはレビューフロー自体を再設計しました。人間レビュアーの責務を「設計判断・コンテキスト確認」に再配置し、それ以外を AI エージェントの並列レビューに寄せた。

つまり、生産性の真のボトルネックは「書く」ではなく「理解する」に移った。

そして理解の効率は、AI に何を渡すかで決まります。リポジトリ全部か、変更の影響範囲だけか。この二者択一を素通しにすると、全読みで 8.7M トークン燃やして重要な 1 行を見落とすパターンに戻ります。

「絞る」= grep ではない

「じゃあ絞ればいい」と言うのは簡単で、実装で刺さります。grep で関連ファイルを引いてくるだけでは、結局「キーワードで絞った全ファイル」になり、構造的な依存関係は捉えられません。

具体例で書きます。UserService クラスを 1 メソッド変更したとき、必要な情報はこうです。

UserService.py 本体
UserService を 呼んでいる 28 個のファイル(依存の逆方向)
UserService が 呼んでいる 内部関数 5 個(依存の順方向、変更影響を受ける可能性)
上記の呼び出し側で書かれている テスト 12 本

grep で UserService を検索すると、これに加えて「無関係なテストのコメントに書かれた UserService」「migration の DB カラム名 user_service_id」「README の目次にある UserService の説明」などが全部引っかかります。ノイズが 3 割、シグナルが 7 割。

7 割拾えれば十分では、と思うかもしれませんが、レビューの精度はノイズに引きずられます。

つまり「絞る」の定義はこうです。

コードベースの構造的な依存関係に沿って、必要なノードだけを取り出す

これがコードベース・ナレッジグラフ(以下 KG)の出発点です。

Tree-sitter + KG で 8.7M を 2,400 に落とす

具体的な圧縮手段を書きます。

Tree-sitter で AST を抽出する: 関数・クラス・呼び出し・import をノードとエッジに変換する
グラフ DB に永続化する: Neo4j でも SQLite の recursive CTE でも構いません。私は SQLite で足りています
blast radius を BFS で計算する: 変更対象のノードから幅優先探索で N ホップ先まで辿り、レビューに必要なコンテキストを絞り込む
MCP 経由で AI に公開する: Claude Code / Cursor が必要なときだけこのグラフをクエリするようにする

これを組んだ結果、私の 30 万行リポジトリで、1 レビューあたりの入力トークンは 8.7M → 約 2,400 に落ちました。3,600 倍の圧縮です。

倍率だけ見ると胡散臭いですが、内訳を書くと納得できます。

変更対象の関数 + 呼び出し元 + 呼び出し先 + テスト: 約 1,800 トークン
直近の型定義 / スキーマの該当箇所のみ: 約 400 トークン
CLAUDE.md 抜粋(レビュー方針だけ): 約 200 トークン

「保険で読ませていた」93% を消しただけです。

指摘の密度は上がり、変更差分に対する的確なコメントが返ってきます。件の 1 行のロジックバグは、次に走らせたとき 1 項目目 で指摘されました。

「絞る」を実務に載せる 3 つの原則

道具の話は KG や MCP に寄りましたが、本質的なのはこの 3 原則です。ツールを変えても失われないので、頭に置いておくと役立ちます。

1. 影響範囲を静的に計算する: grep でも AST でも構いません。「この関数を触ったら何が壊れうるか」を機械的に列挙してから、その集合だけを渡す。人力で候補を思い浮かべると必ず抜けが出ます。

2. 依存の順方向と逆方向を区別する: 呼び出し元(逆方向)はレビューの文脈として必要、呼び出し先(順方向)は変更が波及する範囲。混ぜて渡すと、AI がどちらの視点で読めばよいか迷って、指摘の焦点がぶれます。私は KG のクエリ時にこの 2 つを別々のリストで返しています。

3. テストは blast radius に沿って選ぶ: 「全テストを渡す」が最も無駄です。変更対象を実行しているテストだけを、依存グラフから抜き出して渡す。テスト網羅率が下がるように見えて、レビュー時点では影響範囲外のテストは判断に寄与しません。

これができると、レビューのトークン量は「グラフの局所性の関数」になります。ローカルに閉じた変更なら 3,600 倍、アーキテクチャレベルの変更なら 1.5 倍程度、と圧縮率にレンジは出ますが、8.7M で全読みするより常に安く、常に速く、常に的確です。

まとめ: 大きい文脈は敗北条件

AI コードレビューを組むときの直感的な最適化は「もっと文脈を渡せば精度が上がるはず」です。この直感は、200K トークンあたりまでは正しく、それ以降は逆になります。8.7M トークンを渡した時点で、レビューの精度は 100K のときより 下がる。middle-lost で、注意が分散し、金銭コストだけが直線的に伸びます。「絞る」の答えは grep ではなく、コードベースの構造的な依存関係に沿って必要なノードだけを取り出すこと。Tree-sitter + KG + MCP は、それを機械的に組むための現状最良の手段です。全読みを卒業したあと、レビューの品質と速度は次のフェーズに入ります。

関連: ChatGPT Codex vs Claude Code: 6 タスクの実測比較では、この KG 経由レビューを両エージェントで走らせたときの挙動差にも触れています。

もっと深く知りたい方へ

この記事はコードベース・ナレッジグラフの入り口だけを扱っています。Tree-sitter による AST 抽出、blast radius の BFS 実装、MCP 経由での AI 統合まで通しで書いた本は Knowledge Graph 実践ガイド にまとめました。

harness 側からレビュー品質を上げる観点は Harness Code Review で扱っています。