JA EN
shiichan

AI コードレビューの推論コストを 68% 削減！Cloudflare のキャッシュとモデル選びの工夫

Cloudflare Blog ★★★ Markdown で見る
#cloudflare#ai#devops

やっほー、しぃちゃんだよ！今日は Cloudflare のブログから、AI のコストを下げる実践的なお話だよ。

Cloudflare Blog blog.cloudflare.com

なにが発表されたの？

Cloudflare の Blog で、自社の AI コードレビュアーの推論コストを 68% 削減した事例が公開されたよ。大きなアーキテクチャ変更なしにコストが倍増した原因を調べて、プロンプトキャッシュとモデルのルーティングを見直したんだって。

なぜ重要なの？

きっかけは、1 レビューあたりのコストが倍増したことだよ。

  • 平均コスト: 4 月の約 $1.19 から、8 月下旬には約 $2.46 へ
  • レビューあたりのトークン: 0.91 百万から 2.99 百万へ
  • キャッシュヒット率は 85.7% から 97% に上がっていたのに、コストは上がった

最適化前の支出の内訳は、出力トークンが約 23%、キャッシュ書き込みが約 43%、キャッシュ読み取りが約 34%。つまりお金の大半は、モデルがすでに見たか、これから何度も見るコンテキストに使われていたの。8 月に全レビュアーを Anthropic のモデルに切り替えたときは、1 ジョブが $1.38 から $2.03 に上がり、Claude Opus 4.7 の standards レビュアーは約 $0.25 から $0.88 になったそうだよ。

これで何が変わるの？

結果として、1 レビューの平均コストは $2.43 から $0.77 へ 68% 下がったよ。削減分 $1.67 のうち、コード変更が約 $0.65、モデルと effort の見直しが約 $1.06 だって。

レイテンシも改善したよ。

  • 中央値: 4 分 9 秒から 1 分 32 秒
  • 99 パーセンタイル: 15 分 20 秒から 4 分 41 秒
  • 5 分超のレビュー: 37.9% から 0.7%

深く潜ってみよう

施策は 6 つあるよ。

  • キャッシュされたプレフィックスをリポジトリ間で共有: セッションの最初のリクエストのキャッシュヒットは 14〜26% だった。OpenCode v1 では、唯一のキャッシュブレークポイントがリポジトリ固有の内容（作業ディレクトリ・日付）の後ろにあったのが原因。システムプロンプトをマーカーで分割して、共通部分（ツールとエージェントのプロンプト）に専用のブレークポイントを置き、skills 一覧などのリポジトリ固有の内容は共通部分から除いた。最初のリクエストのキャッシュ読み取りは 91〜99.5% になった
  • 参照資料を先読み: standards レビュアーは最初のターンをツール呼び出しでの参照ファイルの読み込みに使っていた。その索引をプロンプトに入れると、1 回の実行あたりの LLM 呼び出しが 15.9 から 9.6 に、コストが $1.12 から $0.72 に下がった
  • セッションあたりの呼び出しを削減: サブレビュアーが使えないツールの削除、ファイルの並列読み込み（64% のターンがツール呼び出し 1 回だけだった）、再レビューで新しい内容がないレビュアーのスキップ、レビュー投稿後にセッションを終了、キャンセルされたジョブを 15 秒ごとに確認して停止。合わせて 1 レビューあたり約 $0.20 の節約
  • 3 つのサブレビュアーでプレフィックスを共有: コード品質・セキュリティ・パフォーマンスの最初のリクエストは同一。1 つがキャッシュを書き、残り 2 つが最大 20 秒待って読む。それぞれ約 9 セントの節約
  • モデルと effort の調整: 成績の悪い組み合わせをやめ、コーディネーターを Opus 5.5 の medium effort に移行。Sonnet 5 と Sonnet 5.5 を A/B テストして、Sonnet 5.5 は検出結果が同程度で 1 実行あたり 47〜62% 安かった。コード品質は検証のうえ 5.5 の high effort に
  • OpenCode v1 から v2 へ: シャドウ比較で承認の判断が 98% 一致し、full tier のレビューが約 13% 速く終わった

品質面の確認結果はこうだよ（コード品質、high effort）。

  • critical と warning の指摘は 40% 減ったが、作者が対応した重大な指摘は 34% から 59% に増えた
  • ブラインド評価では、レビューあたりの重要な指摘は 0.28 から 0.30 で安定
  • 深刻度のインフレは約 70% 減（主に、軽微な指摘が critical とされることが減った）
  • 判定のないレビューは 0.79% から 0.27% に、セキュリティレビュアーのリトライは 3.5% から 0.04% に減った

注意点も正直に書かれているよ。

  • 比較は平日のウィンドウ同士で、統制された実験ではない
  • 「作者が対応した」は、正しさではなく行動を示す代理指標
  • 判定者もモデルで、比較グループによっては指摘が 35〜66 件しかない
  • high effort のテストは 1 日だけ
  • medium effort では、コード品質とパフォーマンスで実際の指摘が減った（パフォーマンスは重要な指摘が約 64% 減）。セキュリティも減った可能性があるが、統計的に有意ではなかった。セキュリティとパフォーマンスは medium effort のままで、high effort の検証を予定している

まとめ

  • コスト倍増の原因は、コンテキストの再読み込み（キャッシュ書き込みと読み取り）が支出の大半を占めていたこと
  • キャッシュのブレークポイントを見直し、共通プレフィックスを共有するのが効いた
  • 参照資料の先読みとツール呼び出しの削減で、LLM 呼び出し自体を減らした
  • モデルと effort は、品質を測りながら選び直した
  • 結果は平均コスト 68% 減、中央値のレイテンシ 4 分 9 秒から 1 分 32 秒

LLM を使ったエージェントを運用していて、コストやレイテンシを下げたい人にぴったりの読み物だよ！

関連記事