あなたのAIコーディングエージェントの請求額が先月上昇したかもしれませんし、他の人たちも同様でしょう。人々が講じている対策（モデルの切り替え、プロンプトの調整、使用量の制限）はすべて、AI側の問題に対処するものです。Sonarによる制御された研究はコード側を調査し、構造的な品質がエージェントの運用コストに影響を与えることを発見しました。
なぜAIコーディングエージェントの請求額がこれほど高額なのか？
ある開発者のClaude Codeの月間請求額は、数週間にわたる集中的な使用の後、1,600ドルに達しました。400以上のエンジニアリング組織を対象としたDXに関する横断的研究によると、インライン補完とエージェントコーディングツールを併用しているチームでは、エンジニア1人あたり月に200ドルから600ドルを費やしていることが判明しました。
Uberは約5,000人のエンジニアにClaude Codeを展開し、4ヶ月以内に34億ドルの研究開発予算のうちAIツールに割り当てられた部分を使い果たしました。CTOのPraveen Neppalli Naga氏はThe Informationに対し、個々のエンジニアがトークンに月500ドルから2,000ドルを費やしていると述べました。Microsoftは5月、Experiences and Devices部門全体でClaude Codeのライセンス解約を開始しました。これは一部はコストによるものであり、一部は6月30日の会計年度終了前にGitHub Copilot CLIに統合するためのものでした。GitHub Copilot自体のトークンベースの課金への移行は、異なるプラットフォームでも同様のコスト動態を浮き彫りにし、開発者はエージェントを集中的に使用することで、個人あたりのコストが月額29ドルから750ドルに跳ね上がると予測しました。
FinOps Foundationの2026年報告書は、これがどれほど急速に普遍的な問題となったかを数値で示しています。2年前、AI支出を積極的に管理していた財務運用チームは31%でした。現在、その割合は98%に達しており、同財団はこれについて、AIが「新たな懸念事項から、わずか2年で日常的なFinOpsの範囲へと移行した」と説明しています。
Baiら（2026）は、スタンフォード大学デジタルエコノミーラボの研究者らとの共著で、エージェントのコーディングタスクが、単一のターンにおけるチャットインタラクションの約1,000倍のトークンを消費することを発見しました。エージェントはファイルを読み込み、編集を計画し、変更を実行し、結果を検証し、その都度完全な会話履歴を再送信するため、この比率は無駄ではなく、実際の作業量を反映したものです。各ターンにはそれ以前のすべてのターンが含まれるため、コストはセッションの長さに伴って複合的に増加し、入力トークンが総コストの大部分を占めます。
分岐制御フローを持つ400行のメソッドは名前だけでナビゲートできないため、エージェントは全体を読み込みます。暗号的な識別子も同様に徹底的な検索を余儀なくさせ、入り組んだモジュール境界は、エージェントが継ぎ目全体にわたって編集を確認するためにループバックすることを強います。これらはすべてよく知られた構造的な問題ですが、最近までAIのコストに反映されるかどうかは検証されていませんでした。
クリーンなコード、小さなフットプリント
変数を分離するために、Sonarの研究では、6組の一致したリポジトリペアを構築しました。各ペアは同じアプリケーションをビルドし、同じ依存関係の下で同じテストスイートを通過します。唯一の違いは内部にあります。コードの構成、命名規則、ネストの仕方、そしてSonarQubeがフラグを立てるような構造的な問題があるかどうかです。3組のペアはクリーンなコードベースから始まり、 意図的に劣化させられました。残りの3組は、もともと雑然としたコードベースから始まり、SonarQubeによる自動化を通じてクリーンアップされました。両方向のペアを構築することで、観察された効果がコードの構造状態に起因することを確認しました。6組全体で、研究者は33のコーディングタスクを作成し、各タスクを両側で10回ずつ実行し、合計660回の試行をClaude CodeとClaude Sonnet 4.6で行いました。
クリーンなコードで作業するエージェントは、入力トークンを7.1%少なく、出力トークンを8.5%少なく、推論コストを11.1%少なく使用しました。タスクの完了率については、合格率の差が1%未満であったため、変化は見られませんでした。
クリーンな側のエージェントは、すでに編集済みのファイルを再読み込みする頻度が約34%少なく、この傾向はすべてのリポジトリペアで一貫していました。トークンメトリクスはタスクごとに大きく変動しましたが、再訪問の減少は方向性において一貫していました。クリーンなコードでは、エージェントは編集内容をコミットして次に進みましたが、乱雑なコードでは、すでに触れた部分を再読み込みし、行動する前に長い時間をかけて方向性を定め、変更箇所を再訪問していました。
あるcommons-bcelタスクでは、乱雑なコード側では、JVMオペコードに対する数百行にわたるスイッチ文を用いて、オペコードのディスパッチを2つの並行メソッド内に保持していました。クリーンアップでは、これらを、約10個の命名済みヘルパー関数に委譲する数十行の簡潔なディスパッチャーに置き換えました。そのタスクのクリーンなバージョンで動作するエージェントは、入力トークンの使用量を35%削減し、ファイルのオープン数を25%減らし、会話ターンの完了数を32%削減しました。ファイルサイズはほとんど変わりませんでしたが（Utility.javaは両方のバリアントで本質的に同一でした）、エージェントは、フルスイッチをスキャンしてプッシュ処理ブランチを見つける代わりに、handleOpcodePush()をgrepできるようになりました。
すべてのクリーンアップが効果的だったわけではありません。あるgenieタスクでは、パイプラインはフォーカスとなる発射ロジックの周囲からヘルパーを抽出しましたが、元のロジックはそのまま残し、作業をより多くのメソッドに分散させたものの、コア部分の見つけやすさは向上しませんでした。エージェントは追加された処理範囲のため、入力トークンを8%多く使用しましたが、その他の指標は本質的に変わりませんでした。
マルチモジュールタスクでは最も明確な傾向が見られました。作業が2つ以上のモジュール境界を越えて変更を必要とする場合、クリーンな側のエージェントは入力トークンの使用量を10.7%削減し、ファイルの再訪問回数を50.8%削減しました。クリーンなシームでは境界を越えて処理を継続しましたが、乱雑なシームではループバックしました。認知ホットスポットタスク（単一の密集したメソッドまたはクラス内での作業）は、複雑さがより多くのファイルに再配分されるだけでなく排除されるため、結果としてトークン中立となりました。
コメント量の除去実験により、明らかな代替説明が検証されました。クリーンなバリアントと乱雑なバリアント間でコメントを均等化した後、クリーンな側の利点は維持されるか、あるいはさらに拡大しました。研究者らは、「コメントや抑制マーカーが、クリーンと乱雑なフットプリントの対比を左右するものではない」と結論付けましたが、正規化には広範囲にわたる手動介入が必要であり、タスクごとのばらつきが大きかったため、より強力な主張はできませんでした。
この研究はSonar自身によって行われ、1つのモデルと1つのハーネスを用いて、6つのリポジトリペア全体で実施されました。タスクごとのばらつきは大きく、個々のデルタは入力トークンで-47%から+44%の範囲にあり、27の非キャリブレーションタスクのうち、16は「クリーン」側を支持し、11は「乱雑」側を支持しました。この傾向はデータセット全体で維持されていますが、具体的なパーセンテージについては、さらなる研究によって変化する可能性があります。
節約がどこから生じるのか
SonarQubeの認知的複雑性メトリクス（ルールS3776）は、commons-bcelディスパッチャーのナビゲートにコストがかかった理由を正確に測定します。制御フローの密度が高いため、読者（人間または機械）は、名前付きのエントリポイントをターゲットにするのではなく、メソッド全体を解析せざるを得なくなるからです。S3776は、Java、Python、JavaScript、およびTypeScript全体において、重大度の高い保守性として分類され、デフォルトの閾値は15です。すでにカバレッジと重複を追跡しているチームは、プロジェクトレベルのメトリクスとして認知的複雑性密度を追加することができます。この研究のデータは、コードベースがエージェントにとってナビゲートするのにどれほどコストがかかるかを示す合理的な指標として機能することを示唆していますが、genieの反例はその限界を示しています。見つけやすい名前を作成せずに構造を追加する抽出は、状況を改善するどころか、悪化させるだけです。
命名も同様に機能し、論文におけるnormalize_queryと_xfm_q2の対比がその理由を示しています。予測可能な名前があれば、エージェントはすべてのファイルをスキャンするのではなく、ターゲットのルックアップを行うことが可能になります。Le et al. (2025)は関連研究においてその効果を定量化し、情報のない識別子の名前変更がGPT-4oの要約精度を87.3%から58.7%へと低下させ、名前だけでほぼ30パーセンテージポイントの差を生じさせたことを示しました。
明確なモジュール境界は、マルチモジュールトラックが最も強い信号を示した理由を説明しています。インターフェースが明確で、依存関係が自身に戻らない場合、エージェントは境界を越えて処理を継続でき、ループバックして確認する必要がありません。リファクタリングの時間が限られている場合、コメント量の除去実験は、ドキュメント化よりも構造に時間を割くべきであることを示唆しています。
複合的な問題
タスクごとの7％の節約は、単独では控えめに見えるかもしれませんが、エージェントは同じコードベースで何百回、何千回も実行されるため、その節約が蓄積されるかどうかが重要な問題となります。
Sonarの論文はその限界について、これを直接取り上げています： 「次に測定する価値のある保守性の指標は、[タスクごとの節約]が複合的に作用するかどうかです。つまり、コードベースにおけるエージェントの1年間の作業を通じて、タスクごとの節約が蓄積されるのか、それともコードベースがそれを相殺するように変化してしまうのか？」この研究は、固定されたコードベースにおける単一タスクのフットプリントを測定したものです。エージェントが数週間あるいは数ヶ月にわたり、同じリポジトリを繰り返し変更する際に何が起こるかを追跡したわけではありません。
SlopCodeBench (Orlanski et al., 2026)は逆のアプローチをとりました。エージェントが既存のコードをどのようにナビゲートするかを測定する代わりに、エージェントが進化する仕様に基づいて自身の過去の作業を拡張する際、コード品質に何が起こるかを追跡しました。エージェントが生成するコードは、より冗長で構造の乏しい出力へと流れていき、人間が維持するベースラインと比較して2.3倍の冗長性を示し、77%のケースで構造の劣化が進みました。プロンプトレベルでの介入により、初期の冗長性は約3分の1に削減されましたが、時間の経過に伴う劣化率を変えることはありませんでした。
どちらの研究も、両者を結びつけるような主張は行っていません。それらを結びつけるのは推論であり、そのように解釈されるべきです。しかし、論理は単純です。もし乱雑なコードがエージェントの作業コストを増加させるのであれば（Sonarの発見）、かつエージェントが連続する反復でコードを乱雑にする傾向があるならば（SlopCodeBenchの発見）、未検証のエージェント作業のコスト軌道は上向きに曲がるでしょう。各反復はコードベースをわずかに劣化させ、次の反復はその劣化に対処するためにより多くのコストを支払うことになります。
各エージェントの変更後に静的解析を実行することは、単にバグを検出したりスタイルを強制したりするだけではありません。それは、次のエージェントの実行を前回よりもコストのかかるものにしてしまう構造的なドリフトを防ぐのです。品質ゲートを一貫して適用することで、エージェントがコミットして前進できる範囲内にコードベースを維持し、ループバックすることなく前進できるようになります。
研究者たちはこれを研究における最も重要な未解決の問題と呼び、次のステップとして長期的なベンチマークを挙げています。今、意思決定を行うチームにとって、タスクごとの証拠は行動を起こすのに十分です。
同じ投資で、2つのリターン
コード品質は、常に開発者の生産性を通じてその価値を証明してきました。これにより、本番環境でのバグが減り、オンボーディングが迅速になり、複雑なロジックと格闘する時間が短縮されます。
新しい点は、この構造的な作業がAIインフラのコストも削減するということです。これはAIコストの最大の要因ではありませんが（モデルの選択やプロンプトのキャッシュの方が絶対的に重要です）、ツールの変更も新しいインフラも必要としません。SonarQubeで認知的複雑性に関する品質ゲートを適用しているチームは、すでにその作業を行っています。開発者のスピードアップにつながるのと同じリファクタリングが、次のエージェント実行のコストも削減するのです。
さらに詳しく
- コードのクリーンさはコーディングエージェントに影響を与えるか？、Sonarの完全な研究論文
- クリーンなコードベースはトークン使用量を削減する、Sonarの主な発見に関するブログ記事
- SlopCodeBench、エージェントのコード品質の劣化に関するベンチマーク
