AIコーディングエージェントの請求額を押し上げているのは、モデルの賢さではなくコードベースの歩き方でした。静的解析で知られるSonarが、自社リポジトリでの実測値を公開しています。約800行の変更1件に積み上がった文脈は1億5,600万トークン。grepとファイル読みで集めた情報が会話に残り続け、後続のやり取りのたびに課金され直す構造が、具体的な数字とともに示されました。

エージェントの寄り道は毎ターン請求される

大規模言語モデルは、次の一手を考えるたびにそれまでの会話全体を入力として受け取り直します。プロンプトキャッシュが効くため再送分の単価は入力の1割程度まで下がりますが、ゼロにはなりません。つまりトークンの本当の値段は、その大きさではなく、大きさに生き残ったターン数を掛けた値になります。

600行のファイルを40ターン目に開いたエージェントは、600行分を1回払ったのではありません。600行分を残り470ターン分払ったことになります。ファイルを読むほど、そして会話が長引くほど、過去の読みすぎが利息のように効いてくるわけです。

800行の変更に積み上がった1億5,600万トークン

Sonarは自社の意味解析エンジンをAIエージェントと一緒に開発しており、その過程のログをすべて残しています。取り上げられたのは、約800行のバックエンド変更を含む1件のプルリクエストです。

このPRで消費された文脈は1億5,600万トークン。うちキャッシュ読み出しが1億5,280万トークンを占めました。コンテキストウィンドウのピークは45万9,000トークンに達し、費用は約41ドル(約6,400円)です。最終的な差分自体は、人間なら5分で読み終わる分量でした。

エージェントがやっていたのは、統合開発環境なら無料で答えてくれる「定義へ移動」に相当する作業です。呼び出し先を探すために次のようなコマンドを打ちます。

grep -rn "resolve_return_type"

返ってきたのは、Python、TypeScript、Java、Rust、C#、共通コアの各実装がまとめて並んだ一覧でした。正規表現には、この呼び出しがどれに束縛されるのかを判断する手立てがありません。そこでファイルを開いて広めに読み、戻り値を作る補助関数をまた探し、また開く。その読みはすべて会話に残ります。

1回の読みすぎが270万トークンに化ける

内訳の1例が具体的です。エージェントは67行の関数を理解したいだけでしたが、関数の始まりと終わりが分からないため618行のファイルを丸ごと読みました。6,472トークンを読み込んで、実際に使ったのは約700トークン分。その場で無駄になったのが約5,770トークンです。

この読みは42ターン目に会話へ入り、残り470ターンにわたって居座りました。掛け算すると5,770×470で約270万トークン。キャッシュ読み出しの単価は100万トークンあたり約0.2ドル(約31円)なので、この1回だけで約0.54ドル(約85円)になります。1件のPRで同種の読みすぎが約10回、加えて空振りに終わって条件を広げ直したgrepが何十回も走りました。

同じリポジトリの同等な18件のPRを平均すると、1件あたり約2億3,400万トークン、費用は約65ドル(約1万円)、中央値でも約52ドル(約8,000円)です。モデルとのやり取りは約700往復に及び、コンテキストウィンドウのピークは45万から97万5,000トークンの範囲に散らばりました。100万トークンの上限に触れると圧縮が走り、それまでの文脈は失われます。ばらつきの大きさは差分の量ではなく、コードベースをどれだけ歩き回らされたかを映しています。

※1ドル157円換算(2026年9月3日時点)

grepは文字列を見つけますが、意味は見つけません

金額よりも厄介なのが、もう1つの副作用です。正規表現は、こちらが思いついた綴りしか拾えません。インターフェース越しの呼び出し、別名を経由した参照、別の言語からの呼び出しは、検索語が違えばそのまま漏れます。

今回のPRは、C#側で実装済みだった呼び出し先の型解決をPythonへ移す作業でした。ところがC#側の関数名はresolve_type_nodeで、Python側のresolve_return_typeとは語が違います。片方を検索しても、もう片方は永遠に出てきません。見落とした呼び出し箇所はビルドの失敗として跳ね返り、継続的インテグレーションの再実行と手戻りを生み、そのたびに新しい文脈税が発生します。

テキスト検索をグラフ照会に置き換える

Sonar Vortexは、この探索そのものを差し替えようという製品です。エージェントの処理ループの内側に入り込み、ファイルシステムではなくコードベースのグラフに問い合わせて答えを返します。

グラフを作るのが、Sonarが自社開発した意味解析エンジンのSemSitterです。関数、メソッド、クラス、フィールド、引数をノードとして持ち、calls、references、returns、has-param、is-type、contains、extendsといった型付きの辺で関係を結んだ統合依存グラフ(UDG)を、変更のたびに即時更新します。

エージェントの問い方も変わります。「resolve_return_typeに言及しているファイルはどれか」ではなく、「この呼び出しが束縛される定義と、それを所有する型、戻り値、呼び出し元をくれ」と聞く。返ってくるのはメソッド本体1つと、残りに答える辺だけです。周囲のファイルは持ち込まず、条件を広げ直す必要もありません。先ほどの読みすぎは、グラフ照会なら約33万トークン相当、およそ9分の1で済んだ計算になります。

効きが大きいのは構造的な関係の先にある2種類の辺です。1つはコードと文書を結ぶdocumented_byで、ある関数に触れたときに設計文書の該当する1段落だけが出てきます。古い記事に引きずられがちな「文書を読ませると迷子になる」問題を逆から解く形です。もう1つは言語をまたぐsemantically_relatedで、名前の違う同等実装どうしをつなぎます。これがあれば、先ほどのC#とPythonの取り違えは辺をたどるだけの話になります。

既存のコーディング支援ツールに後から差し込む

Sonar VortexはMCP(Model Context Protocol)を軸に統合する設計で、Claude Code、Cursor、GitHub Copilot、Windsurf、Google Gemini CLI、OpenAI Codex CLIといった手元のツールへ後から差し込めます。判定に使うルールはSonarQubeの既存の品質プロファイルをそのまま流用するため、新しい規約を書き起こす必要はありません。コードを書く前に文脈と制約を注入し、書いている最中に検証する、という2つの役割を1つのループとして回します。

まとめ

大きなコードベースでAIコーディングエージェントが詰まる原因は、推論の質ではなく移動の仕方にあります。Sonarの実測では、約800行のPR1件で1億5,600万トークン、18件平均で1件あたり約65ドル(約1万円)が消え、コンテキストウィンドウは繰り返し100万トークンの上限に迫りました。しかも文字列検索では別言語の同等実装を取りこぼし、その分が手戻りとして跳ね返ります。探索をグラフ照会に置き換えるという発想は、エージェントに渡す情報を増やすのではなく減らす方向の最適化です。コードベースが大きいほど差が開く性質を持つため、社内でエージェントを常用している現場ほど請求書の内訳を一度見直す価値がありそうです。

※サムネイル画像はAI生成のイメージです