Cloudflare AI Gateway の月次利用請求書が、モデルごとに合計 1 行へ変わった。入出力トークンの内訳が消えるので、請求書を機械で読んでコスト配分しているチームはパーサを見直す必要がある。
$0.16 2 行分がまとまった 1 行の請求額 changelog の例で、入力 40,000 tokens（$0.04）と出力 24,000 tokens（$0.12）の 2 行が anthropic/claude-haiku-4.5 の 1 行になった
Cloudflare AI Gateway の月次利用請求書から、入力トークンと出力トークンの内訳が消えた。請求書の明細をそのまま取り込んでモデル別・入出力別にコストを割り振っているチームは、列の構成が変わる。ダッシュボードで合計金額を見ているだけなら、明細の列は目に入らない。
月次の利用請求書は、毎月の初めに前月分の使用量に対して発行される。changelog の日付は 2026年9月1日。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 明細行 | 入力トークンと出力トークンで別 | モデルごとに 1 行 |
| 行に載る値 | トークン数、単価、金額 | 合計金額 |
| 対象 | 月次の利用請求書 | 月次の利用請求書（クレジット購入分は対象外） |
出典：Cloudflare Changelog「AI Gateway consolidates monthly usage invoice line items and standardizes model names」2026年9月1日
changelog に載っている例では、anthropic claude-haiku-4-5-20251001 Input Tokens が 40,000 tokens at $0.000001（$0.04）、Output Tokens が 24,000 tokens at $0.000005（$0.12）という 2 行だった。これが anthropic/claude-haiku-4.5 の $0.16 という 1 行になる。合計額は動かない。消えるのはトークン数と単価だ。
モデルごとの合計は請求書に残る。どのモデルにいくら払ったかは今までどおり請求書から読める。取れなくなるのは、その内側の入出力の比だ。
プリペイドのクレジットで支払っているなら、クレジット購入の請求書はこの変更の対象外と明記されている。変わるのは使用量の請求書の方だけだ。
もう一つの変更は名前の側にある。請求書とログの両方で、モデル名の表記が統一された。提供元ごとのバージョン接尾辞が付いていたモデル派生形は、provider/model という一貫した識別子になる。
# 変更前（請求書の明細に現れていた形）
anthropic claude-haiku-4-5-20251001 Input Tokens
anthropic claude-haiku-4-5-20251001 Output Tokens
# 変更後
anthropic/claude-haiku-4.5日付の接尾辞が落ち、バージョンがドット区切りになり、提供元とモデルがスラッシュで繋がる。changelog が挙げている例はこの 1 つで、全モデルの新旧対応表は載っていない。統一されるのは表記であって、課金の対象や単価が変わるという記述はない。
ログ側の表記がいつ切り替わるのか、過去のログが遡って書き換わるのかは、この changelog では触れられていない。
影響が出るとすれば モデル名を文字列で持っている箇所 だ。changelog は表記の統一を告知しているだけで、利用者側の処理がどうなるかは書いていない。以下は識別子が変わることからの推測になる。claude-haiku-4-5-20251001 のような日付付きの識別子で完全一致させている集計クエリやダッシュボードのフィルタは、新しい識別子を拾わない。ハイフン区切りで提供元とモデルを切り出しているパーサも、スラッシュが入れば結果が変わる。名前の変更が請求書とログの両方に及ぶとは書かれているので、確認する範囲は請求処理だけにとどまらない。
請求書を機械で読んでいる側は、行数と列の構成そのものが変わる。1 モデルにつき 2 行という前提で入出力の比率を出していた処理は、その比率を請求書からは作れなくなる。同じ粒度を別の場所から同じ精度で取れるかどうかは、changelog の記述だけでは判断できない。
請求書の写しに入力と出力の行が並ぶ前提でレポートを組んでいるなら、その行はもう来ない。渡す様式まで直す必要があるかどうかは、そのレポートの作り方しだいで、changelog には書かれていない。
月次の金額をモデル名で突き合わせているなら、識別子が切り替わる月をまたいだ比較で、同じモデルが別々の系列に割れる可能性がある。これは changelog に書かれている話ではなく、識別子が変わることからの推測だ。
請求書の明細行を機械で取り込んでいるなら、行数と列の構成が変わる。ログや自前の集計でモデル名を文字列一致か文字列分割で扱っているなら、拾う識別子が変わる。入出力別のトークン内訳を請求書から作っているなら、その元になる行がなくなる。
どれにも当てはまらないなら、この変更で手を動かす理由は見当たらない。当てはまるなら、モデル名を扱う箇所を新旧どちらの識別子でも通る形にしておくのが先だ。changelog は適用時期を「now」としか書いておらず、どの月の請求書が最初に新しい形式で届くかは明示されていない。
明細が短くなったのは行のまとめ方の話で、changelog には課金の対象や単価が変わるという記述はない。手当てが要るのは、行の構成が変わる明細の取り込みと、識別子が変わるモデル名の突き合わせの両方だ。