Cloudflareは、社内AIコードレビュー1件あたりの平均推論費を2.43ドルから0.77ドルへ、約68%削減したと2026年10月19日付の公式ブログで報告しました。比較対象は、最適化前のうち費用が最も高かった2週間の平均です。0.77ドルは、コード品質担当をhigh effortにする構成を前提とした値です。[1] 費用が下がる一方で、性能担当では重要な指摘が減ったという評価も公表されています。[12]

変更には、キャッシュ設計、不要な処理の削減、モデルと推論強度（effort）の見直しが含まれます。施策別の費用は、変更前後の平日日中の値を比較したもので、厳密な対照実験ではありません。68%の削減をキャッシュだけの効果とみなすことはできません。[1]

全体のヒット率より、最初の呼び出しを調べる

同社は、全体のキャッシュヒット率が2026年9月までに97%へ上昇したと報告しています。[2] 公表本文だけでは、その分母の詳細までは分かりません。別に調べた新規レビューセッションでは、担当別に、最初の呼び出しの14〜26%で過去のジョブが書き込んだ共通部分のキャッシュにヒットしていました。全体値と、初回リクエストがヒットした割合を分けて確認します。[3]

原因は入力の境界にありました。OpenCode v1は、共通の指示と作業ディレクトリ・日付を同じsystem blockに入れ、末尾にだけキャッシュ境界を置いていました。リポジトリごとに変わる情報が境界の前にあるため、共通部分を単独で再利用できませんでした。同社は共通指示の末尾でブロックを分け、可変情報を後ろへ移しました。ツール説明も一定に保ち、初回の再利用率が9割を超えたと報告しています。[3]

Anthropicの公式仕様によると、tools、system、messagesの順でキャッシュ境界までの入力が再利用の対象となり、そこまでの完全一致が条件です。[4] 配置の違いを概念的に示すと、次のとおりです。

配置入力の並びとキャッシュ境界
改修前固定のツール定義・共通指示 → 作業ディレクトリ・日付 → 境界
改修後固定のツール定義・共通指示 → 境界 → 作業ディレクトリ・日付

同じ変更を調べるコード品質・セキュリティ・性能の3担当でも、共通のツール・ルール・パッチを先に置き、担当固有の指示を後ろにそろえました。[5] 後続の2担当が先行担当のキャッシュを再利用できるように、先行担当の応答がストリーミングを開始するまで最大20秒待つ方式を採用したと報告しています。[6]

使われない往復と、止まらない処理を減らす

同社はキャッシュ以外の無駄も調べました。サブレビュー担当には、使えない最終コメント投稿ツールまで提示されていました。呼び出しを拒否された後にレビューを続けるため、余分な往復が発生していました。使えないツールを提示から外すことで、その往復とツール定義のトークンを減らしています。[7] 投稿後に誰も読まない要約を生成する追加ターンも停止しました。[8]

取り消した処理が実際に停止するかも確認しています。同社のGitLabのKubernetes実行環境では、調査対象のキャンセル済みジョブ446件のうち358件が、レビュー終了まで動き続けていました。ジョブ自身が15秒ごとに状態を確認し、キャンセルを検知したら停止する方式に変更しました。[9]

品質の変化は、担当ごとに読む

同社はSonnet 5.5のコード品質担当をmediumとhighに分けて比較しました。highは担当1実行の費用がmediumより61%高く、mediumで指摘行が次のpushで変わった件数はhighのおよそ4分の1でした。この比較を踏まえ、highを採用する判断をしました。[10] 性能とセキュリティはmediumのままで、以下の表は同社のfull-tierレビューに関する評価です。

担当と構成公表された品質評価
コード品質・high指摘行が次のpushで変わったcritical・warningの指摘は、1,000レビュー当たり145件から132件。同社は誤差範囲内と評価しています。指摘の正しさや真のバグ検出率の直接測定ではありません。[11, 13]
性能・mediumモデルによる盲検判定で、1レビュー当たりの重要な性能指摘数が約64%減少しました。highでの追加評価が課題とされています。[12]
セキュリティ・mediumモデル判定による重要なセキュリティ指摘数は約4分の1減少しましたが、統計的有意差は確認されていません。[12]

指摘行が変更されたことは、開発者の対応を示す指標ですが、指摘の正しさを証明するものではありません。モデルによる判定にも限界があり、これらの評価を全バグを数えた検出率と同一視することはできません。[13]

盲検評価の対象は、コード品質・セキュリティ・性能の3担当から抽出した657件の指摘です。各判定群は35〜66件で、報告では「now」の観測窓が1日だった点も、モデル判定の結果を一般化する上での制約として挙げています。[14]

自分の基盤では、費用と指摘の中身を並べて測る

以下は、この事例を踏まえた本記事の確認案です。

  1. 初回を切り出す。 セッション全体とは別に、最初の呼び出しのキャッシュ読み取り・書き込みを確認します。実際に送る共通部分のハッシュや境界を調べ、可変情報が混ざっていないか確かめます。対象モデルの最小prefix長やTTLも、公式仕様で確認します。
  2. 往復と停止を調べる。 使えないツールの失敗、利用されない完了後の処理、取り消した後も続く実行を、担当別の呼び出し履歴から探します。
  3. 品質も比較する。 モデルやeffortを変えるときは、費用だけでなく担当別の指摘内容も同じ基準で比べます。開発者の対応や別の判定とも照合し、指摘が減った理由が重複・誤指摘の削減なのか、重要な問題の取りこぼしなのかを確認します。