AI Gateway のカスタムコストがキャッシュトークン単価に対応、交渉済み価格をそのまま集計へ反映できる

要約

Cloudflare は 2026-09-09、AI Gateway のカスタムコスト機能でキャッシュトークンの単価を指定できるようにしました。cf-aig-custom-cost ヘッダーに per_cache_read_token（キャッシュ読み取り）と per_cache_write_token（キャッシュ書き込み）を追加します。

背景には、プロンプトキャッシュの普及があります。カスタムコストは、AI Gateway 上で「自社が実際に払っている単価」を宣言し、ダッシュボードのコスト集計に反映させる機能です。従来は per_token_in と per_token_out、つまり入力と出力の単価しか扱えませんでした。

ところが、主要プロバイダーはいずれもプロンプトキャッシュを提供しており、**キャッシュヒットしたトークンは通常の入力トークンより大幅に安く課金されます。**入力単価しか宣言できない状態では、キャッシュを効かせれば効かせるほど、**ゲートウェイ上の集計値が実際の請求額から乖離していきます。**しかも乖離の方向は「実際より高く見える」側です。コスト最適化を進めた結果、ダッシュボード上の数字が改善しない、という状態になります。

今回の対応で、その乖離が埋まります。挙動は3点です。(1) いずれかのキャッシュ単価を指定した時点で、キャッシュトークンの価格計算が有効になります。(2) 片方だけ指定して他方を省略した場合、省略した方は per_token_in の単価が使われます。(3) プロバイダーによって「キャッシュトークンを入力トークンに含めて報告する」ものと「別建てで報告する」ものがありますが、AI Gateway 側が二重計上を回避します。

ヘッダーの指定例は次の形です。

{
  "per_token_in": 0.000001,
  "per_token_out": 0.000002,
  "per_cache_read_token": 0.0000001,
  "per_cache_write_token": 0.0000005
}

何が変わったか

• cf-aig-custom-cost ヘッダーに per_cache_read_token / per_cache_write_token を指定できる
• いずれかのキャッシュ単価を指定すると、キャッシュトークンの価格計算が有効になる
• 省略した方のキャッシュ単価は per_token_in にフォールバックする
• プロバイダーごとのキャッシュトークン報告方式の違い（入力に含める / 別建て）を AI Gateway が吸収し、二重計上を防ぐ
• プロバイダーと交渉した個別のキャッシュ単価を、そのままコスト集計へ反映できる

業務インパクト（一般企業向け）

この更新は、AI のコストを「測れる状態」に保つための修正です。

生成AI の運用コストは、いま多くの組織で**「請求書を見るまで分からない」**という状態にあります。理由の1つは、複数プロバイダーを併用していることです。用途ごとに OpenAI と Anthropic と Google を使い分ける構成は珍しくありませんが、**課金体系も明細の粒度もそれぞれ違います。**AI Gateway のようなゲートウェイを挟むのは、この分散した数字を1か所に集めるためです。

**ゲートウェイの集計値が信用できなければ、挟む意味が半分失われます。**カスタムコストは、公表価格ではなく自社の実単価を宣言する機能なので、まさに「請求額と突き合わせられる数字」を作るためのものです。そこにキャッシュ単価が入っていなかったというのは、プロンプトキャッシュを使っている組織では集計が構造的にずれていたということです。

**ずれ方が厄介なのは、最適化の効果が見えなくなる方向だからです。**プロンプトキャッシュは、いま最も費用対効果の高いコスト削減手段の1つです。前日（2026-09-08）には OpenAI が Prompt Cache Diagnostics を GA にし、Anthropic がキャッシュヒット率の最大化を第一に置いたコスト削減ガイドを公開しています。業界全体がキャッシュ最適化へ向かっている中で、その成果を測る側が対応していなかったという構図でした。今回それが解消されます。

**実務としてやることは明確です。**AI Gateway でカスタムコストを設定している組織は、キャッシュ単価を追加する。これだけです。設定していない組織は、まずカスタムコストそのものの導入を検討してください。公表価格と実際の契約単価が違う場合、公表価格ベースの集計は最初から実額と合いません。

**注意点は、フォールバックの挙動です。片方だけ指定すると、省略した方は入力単価が使われます。キャッシュ読み取りは通常入力よりずっと安いのが普通なので、per_cache_read_token を書き忘れると、キャッシュヒット分が高く計上されます。**両方を明示的に書くのが安全です。「どちらか書けば有効になる」という仕様は、書き忘れに気づきにくい形をしています。

より広い論点として、コスト可視化の担当を決めているか、という話があります。AI の利用が部門に広がると、コストは分散し、誰も全体を見なくなります。ゲートウェイを入れるという判断は技術的な選択に見えますが、実際には「誰が全体のコストを見るか」を決めるための組織的な選択でもあります。集計の精度が上がった今回の更新は、その担当者にとって手元の数字の信頼度が上がったという意味を持ちます。

副業・個人活用視点

**個人開発でも、複数プロバイダーを束ねているなら効きます。**AI Gateway は無料枠でも使え、個人のプロダクトで OpenAI と Anthropic を用途別に呼び分けるといった構成は普通にあります。

**個人にとっての価値は、集計の正確さより「単価を意識する習慣」にあります。**カスタムコストを設定するという行為は、自分が実際にいくら払っているかを数字で宣言することです。これをやると、どの機能がコストを食っているかが可視化されます。趣味の開発なら気にしなくてよいのですが、プロダクトとして課金する、あるいはクライアントに納品するなら、原価が見えていないと値付けができません。

受託開発では、これは説明責任の材料になります。「LLM の利用料は月いくらです」と言うだけでは、クライアントは検証できません。ゲートウェイ上でプロバイダー別・用途別のコストが出せて、しかもキャッシュを効かせた分がきちんと安く計上されているなら、最適化の成果を数字で示せます。「キャッシュ設計を入れたので、月額がこれだけ下がりました」という報告は、そのまま次の仕事につながる種類の実績です。

**逆に、ここを詰めないと損をします。**プロンプトキャッシュを効かせる設計は手間がかかります。静的な部分を前に、変動する部分を後ろに置くという構成の作り込みが必要です。**その手間をかけたのに、成果が数字で見えなければ、単なる自己満足になります。**測れる状態を先に作ってから最適化に入る、という順序は、個人でも組織でも変わりません。

**設定作業自体は軽いものです。**ヘッダーに2つのフィールドを足すだけで、コード変更もほぼありません。すでにカスタムコストを使っているなら、今日中に足せる種類の更新です。使っていないなら、単価を1度調べて設定する作業が入りますが、それも数十分の話です。費用対効果としては、かなり分かりやすい部類に入ります。