Cloudflare AI Gatewayで請求先の取り違えを防ぐ方法

Cloudflareでは、クライアントのモデルキーが欠けている場合、そのリクエストがCloudflare側のAI利用料として計上される前に止められるようになりました。2026年9月14日、Cloudflare AI Gatewayにプロバイダー認証情報を必須とする機能が加わり、該当するキーがないサードパーティー向けリクエストはUnified Billingへ回らず、HTTP 400で失敗するようになりました。

Cloudflare AI Gatewayで変わる「誰が支払うか」

AI Gatewayでは、1回のモデルリクエストに対して複数の認証経路を選べます。ここでいう認証情報とは、どのアカウントに料金を請求するかを上流のモデルプロバイダーへ伝えるキーです。

変更前の判定順は単純でした。まず、リクエストにプロバイダーキーが付いているかをCloudflareが確認します。なければ、ゲートウェイにdefaultエイリアスで保存されたBring Your Own Key（BYOK）を探します。どちらも見つからない場合は、Unified BillingのCloudflare管理認証情報を使い、Cloudflareのクレジット残高から利用分を差し引くことができました。

最後のフォールバックは、Cloudflareを支払者にしたい場合には便利です。しかし、本来はクライアント自身がOpenAI、Anthropic、Googleなどのプロバイダーキーを用意するリクエストなら、予算流出の原因になります。

今回、サードパーティーのプロバイダーへ送るトラフィックについて、この3段階目を無効にできるようになりました。ゲートウェイでRequire provider credentialsを有効にすると、API上ではbyok_only: trueとなり、利用できる顧客側の認証情報がないリクエストはHTTP 400で停止します。cf-aig-no-wholesale: trueを指定すれば、同じ制限をリクエスト単位でも適用できます。認証情報の判定順と2つの設定については、Cloudflareのドキュメントに詳しく記載されています。

支払者の候補が順に並んでいると考えると、仕組みを理解しやすくなります。

1. リクエストの認証情報： クライアントが呼び出し時にプロバイダーキーを送ります。AI Gatewayはキーを変更せずに転送するため、そのキーに紐づくアカウントへプロバイダーから請求されます。
2. ゲートウェイに保存された認証情報： リクエストにプロバイダーキーがなければ、Cloudflare Secrets Storeに保存されたキーをAI Gatewayが使います。Unified Billingのエンドポイントでは、対象となる保存済みキーにdefaultエイリアスが必要です。
3. Cloudflare Unified Billing： 利用できるクライアントキーも保存済みキーもなければ、Cloudflareの管理認証情報を使い、Cloudflareアカウントのクレジットから利用分を差し引けます。

新しいルールを有効にすると、この判定は2段階目で終わります。事業上の違いは明快です。認証情報の欠落が、見えないコスト移転ではなく、把握できる停止として現れます。

コスト管理が「事後照合」から「事前拒否」へ変わる

Unified Billingでクレジットを購入すると、5%の手数料が加算されます。Cloudflareの例は明快です。$100分のクレジットに対する請求は$105ですが、プロバイダーの推論料金そのものに上乗せはありません。

これをクライアント向けのワークフローに当てはめてみます。本来はクライアントのプロバイダーアカウントを使うジョブでキーが欠落すると、$100分のモデル利用料が運用者のCloudflareクレジットから差し引かれる可能性があります。そのクレジットの購入費は$105です。クライアント側のプロバイダーアカウントにはフォールバック分が一切記録されず、運用者が$105の支払いをすべて負担したうえで、どのクライアントが原因だったかを特定しなければなりません。

本質的な問題は5%の手数料ではありません。$100分のワークロード全体が、誤った予算に移ってしまうことです。追加の$5は、そのミスをさらに高くつかせるだけです。

プロバイダー認証情報を必須にすれば、問題の性質は請求調査からアプリケーションエラーへ変わります。自動救済は失いますが、誰が支払うかを明確に区切れます。ゲートウェイ手数料とプロバイダーへの直接請求を広く比較したい場合は、AIゲートウェイのコスト比較も参照してください。

この設定が向いているケース

クライアント向け自動化を運用する支援会社

1つのCloudflareアカウントを支援会社が運用しつつ、モデルプロバイダーとの契約はクライアントごとに用意する形があります。この場合、クライアント負担のルートでゲートウェイルールを有効にします。導入時のキー登録漏れやローテーション時の削除が起きても、支援会社のプリペイド残高を使わずにジョブが停止します。

効果は、請求の負担元が明確になることです。クライアントは有効な認証情報を提供するか、設定エラーを受け取るかのどちらかです。処理が終わってから共有クレジットの請求をさかのぼって調べる必要がなくなります。

顧客持ち込みのキーを受け付けるSaaSチーム

顧客が用意したプロバイダーキーを使うSaaSでは、HTTP 400をセットアップ未完了の状態として扱えます。プロバイダー認証情報がないことを顧客へ伝え、プラットフォーム自身のCloudflareクレジットが使われないようにできます。

特に有効なのは、リクエストが成功すると設定ミスに気づけない場面です。制限がなければ機能は動き続け、別の会社が料金を支払います。制限を設ければ、アカウント設定を直せる段階で早期に失敗させられます。

まず1つのルートから切り替えるプラットフォームエンジニア

影響範囲を小さく始めるなら、リクエストヘッダーを使います。サードパーティー向けの1つのリクエスト経路にcf-aig-no-wholesale: trueを追加し、キー欠落時の挙動をテストして、エラーを監視へ組み込んでからゲートウェイ全体へ広げます。

優先関係は、厳しくする方向にしか働きません。リクエストヘッダーを使えば、許可型のゲートウェイに厳しい条件を追加できます。一方、Require provider credentialsがすでに有効なゲートウェイで、リクエスト側からヘッダーをfalseにして制限を緩めることはできません。Cloudflareは、これらの制限が追加的に適用されると説明しています。

支払者の制御と予算の制御を分けたいFinOps担当者

この設定で決めるのは、どのアカウントに支払いを許すかです。いくらまで使えるかはAI GatewayのSpend limitで決めます。両者は異なる制御なので、テストも分ける必要があります。

Cloudflareがモデル価格を把握していれば、Spend limitはBYOKとUnified Billingの両方のリクエストを対象にできます。モデル、プロバイダー、メタデータごとの設定も可能です。ただし、コストはベストエフォートの推定値であり、Cloudflareも正確な請求額はプロバイダーのダッシュボードで確認するよう案内しています。プロバイダー認証情報のルールは支払者の境界として扱い、支出上限は別に検証してください。

原因不明の停止を招かずに設定する手順

1. 1

   各ルートの支払者を明確にする

   サードパーティープロバイダー向けのトラフィックとWorkers AIを分けます。サードパーティー向けの各ルートについて、プロバイダーキーをリクエストに付けるのか、ゲートウェイに保存したdefaultキーを使うのかを記録してください。支払い主体が明確になるまでは、認証情報がないと停止するルールを有効にしないでください。

2. 2

   最小の適用範囲を選ぶ

   1つの経路だけなら、cf-aig-no-wholesale: trueを送ります。ゲートウェイ全体なら、AI > AI Gatewayから対象のゲートウェイを選び、Settingsを開いてRequire provider credentialsを有効にし、確定します。APIで管理するゲートウェイでは、更新リクエストにbyok_only: trueを指定します。

3. 3

   2つの有効な認証経路を確認する

   まず、プロバイダーキーを付けたステージングリクエストを送ります。次に、保存済みのdefaultキーを使うリクエストを送ります。それぞれについて、想定したプロバイダーアカウントに利用記録が残ることを確認してください。Unified Billingのエンドポイントがproductionというキーに依存している場合は、先へ進む前にエイリアスを修正します。

4. 4

   意図的にキーを外す

   ステージング環境で、プロバイダーキーも対象となる保存済みのdefaultキーもない状態にし、同じサードパーティー向けリクエストを送ります。期待する結果は、モデルからの正常な応答ではなくHTTP 400です。この設定エラーをリトライ処理が繰り返さないことも確認してください。

5. 5

   エラーの担当者と対応キューを決める

   このHTTP 400は、リクエストヘッダー、保存済みシークレット、キーローテーションを管理するインテグレーション担当者またはプラットフォーム担当者に割り当てます。カスタマーサポートが状況を説明し、財務チームが監査することはあっても、修正の担当にすべきではありません。

導入前に知っておくべきトレードオフ

この設定では、気づきにくいフォールバックと引き換えに、認識できるエラーを受け入れます。Unified Billingを可用性確保の手段として意図的に使っていた場合、有効化するとサードパーティープロバイダー向けリクエストの救済経路がなくなります。期限切れや無効なリクエストキーも、別の請求経路へ差し替えられずにプロバイダーへ転送されるため、上流のプロバイダーが拒否する可能性は残ります。

重要な例外はWorkers AIです。Workers AIのリクエストではサードパーティーのプロバイダー認証情報を使わないため、そのまま許可され、別途設定されたWorkers AIの請求モードが維持されます。byok_onlyを有効にしても、「Cloudflareへの請求をすべて止める」スイッチにはなりません。

Spend limitでも、すべての抜け道を塞げるわけではありません。集計には遅延があるため、同時リクエストによって一時的に上限を超えることがあります。また、トークン数と既知のモデル価格からコストを推定しています。Spend limitは活用しつつ、正確な請求額はプロバイダーとCloudflare双方の請求画面で照合してください。

今週最初にやること

クライアント負担のサードパーティー向けルートを1つ選びます。まずリクエスト単位の制限を追加し、ステージング環境で認証情報がない状態をテストしてください。合格条件は、フォールバックが成功せず、担当者が決まったHTTP 400として処理されることです。そのエラーをインテグレーションチームまたはプラットフォームチームのキューへ入れ、キーを修正する担当者を決めてから、ゲートウェイ全体への適用を検討します。

すべてのサードパーティー向けトラフィックでCloudflare Unified Billingを意図的に使っているなら、ルールは無効のままにします。Workers AIだけを使っている場合、この設定で請求は変わりません。クライアントや部門のプロバイダーアカウントが支払うべき運用なら、今週中に着手し、次のキーローテーションで問題が表面化する前に失敗時の挙動をテストしてください。

このような変更を運用に落とし込むための解説をもっと読みたい方は、ニュースレターにご登録ください。