Cloudflare は、オペレーターがサードパーティ モデルのリクエストでプロバイダーの認証情報を要求できるようにするコントロールを AI Gateway に追加しました。この変更はインターフェースの点では小さなものですが、ゲートウェイ経由で AI トラフィックをルーティングするチームにとって実際的なガバナンスの問題に対処するものです。つまり、顧客、プロジェクト、またはテナントが有効なプロバイダー キーを提供しなかった場合はどうなるでしょうか?

この更新前、Cloudflare AI Gateway は、サポートされているサードパーティ プロバイダーのフォールバック パスとして統合請求設定を使用できました。これはリクエストが失敗する場合に便利ですが、コストの帰属とコンプライアンスの境界があいまいになる可能性もあります。新しい BYOK のみの設定により、ゲートウェイ所有者はそのフォールバックを防止し、代わりに明示的に提供された Bring-your-own-key 認証情報をリクエストに使用するよう要求できます。

Cloudflare によると、この設定はダッシュボードまたは API と byok_only=true を通じて有効にできるそうです。また、チームが個別の呼び出しでの大規模な認証情報または Cloudflare が管理する認証情報の使用をブロックしたい場合に備えて、リクエストごとのヘッダー cf-aig-no-wholesale も追加されました。

変更点

9 月 14 日の AI ゲートウェイの変更ログでは、サードパーティ プロバイダーのリクエストに対する認証情報の要件が導入されています。有効にすると、呼び出し元が許容可能なプロバイダー資格情報を提供しなかった場合、ゲートウェイは Cloudflare が管理する Unified Billing 資格情報にサイレントにフォールバックしません。

AI ゲートウェイが多くの内部アプリケーション、外部顧客、および複数のモデル プロバイダーの間に配置されることが増えているため、この区別は重要です。キーの欠落は単なる技術的な故障モードではありません。どの法人に請求されるか、どのアカウントのプロバイダ割り当てが消費されるか、使用量が適切なコスト センターに表示されるかどうかを決定できます。

新しい管理により、プラットフォーム チームはより厳格な運用モードを得ることができます。ゲートウェイは、顧客資格情報の欠落をルーティングの不都合として扱う代わりに、ポリシー違反として扱うことができます。これは、再販業者のセットアップ、顧客所有のキーの導入、プロバイダーとの関係を事業部門やテナントに直接結び付ける必要があるエンタープライズ環境に特に関係します。

AI ゲートウェイ オペレーターにとって重要な理由

AI ゲートウェイの設計では、多くの場合、ルーティング、レイテンシ、キャッシュ、再試行、モデルの抽象化に重点が置かれてきました。請求行動にも同様の注意が必要です。 1 つのパスが使用できないときにゲートウェイが資格情報モードを自動的に変更すると、ダウンストリームのレポートが誤解を招く可能性があります。リクエストは通常​​のアプリケーション トラフィックのように見えますが、請求書は別の場所に送信されます。

中央 AI APIコスト管理 レイヤを運用している企業にとって、これは運用リスクを生み出します。財務チームはクリーンなチャージバック データを失う可能性があります。セキュリティ チームは、どの資格情報が実際に使用されたのかを知らない可能性があります。製品チームは、あるテナントの使用量が、そのテナント独自のプロバイダ アカウントではなくプラットフォーム アカウントを通じて請求される理由を説明するのに苦労するかもしれません。

BYOK 専用モードは、顧客のコミットメントにも役立ちます。一部の購入者は、独自のプロバイダー契約、データ処理条件、または地域設定がモデル コールを管理することを要求します。ゲートウェイが管理された請求資格情報にフォールバックできる場合、フォールバックがポリシーによって無効にされない限り、そのコミットメントを強制するのは難しくなります。

リクエストごとのヘッダーにより、より詳細なオプションが追加されます。プラットフォームは、より厳格なコンプライアンス、リセラー、または帰属の要件を伴うリクエストに対してはそれを防止しながら、一部のワークロードでは広範な統合請求動作を利用できるようにすることができます。これにより、すべてのアプリケーションを一度に最も厳格なモードに強制することなく、開発者に移行パスが提供されます。

影響を受けるのは誰ですか

当面の対象となるのは、Cloudflare AI Gateway を使用してサードパーティ AI プロバイダーにリクエストをプロキシしているチームです。この変更は、複数のチーム、テナント、または顧客がゲートウェイを共有している場合、およびプロバイダーの資格情報が中央プラットフォーム アカウントの外部で所有されることが予想される場合に最も関連性があります。

Enterprise AI プラットフォーム チームは、ゲートウェイの動作が内部ポリシーと一致しているかどうかを確認する必要があります。プロジェクトが独自の OpenAI、Anthropic、Google、Mistral、またはその他のプロバイダー アカウントを使用することになっている場合、ゲートウェイはその依存関係を表示して強制できるようにする必要があります。デモの成功に役立つフォールバックが、壊れた認証情報の設定を隠している場合、本番環境で問題になる可能性があります。

再販業者とパートナー プラットフォームには、同じ問題のより鋭いバージョンがあります。顧客が独自のプロバイダー キーを持ち込む場合、プラットフォーム オペレーターは、トラフィックが誤ってプラットフォーム課金の使用量に変換されないことを確信する必要があります。そうしないと、マージン、請求書、監査記録、顧客の信頼がすべて影響を受ける可能性があります。

開発者も影響を受けますが、そのほとんどはより明確な障害モードによるものです。 BYOK のみの強制では、適切な資格情報が欠如しているリクエストは、代替の請求パスを介してルーティングされるのではなく、失敗する必要があります。そのためには、より適切なオンボーディング チェック、より明確なエラー処理、トラフィックが開始される前にプロバイダ キーを検証する展開テストが必要となる場合があります。

実際的な結果

最初の実際的なステップは、ポリシーのインベントリです。チームは、どのワークロードがCloudflare管理の統合請求の使用を許可され、どのワークロードが顧客所有またはプロジェクト所有のプロバイダー認証情報を使用する必要があるかを決定する必要があります。この決定は、デフォルト ゲートウェイの動作に任せるのではなく、明示的に行う必要があります。

2 番目のステップは可観測性です。ログと使用状況分析では、どの資格情報モードが使用されたか、BYOK のみが有効になっているためにリクエストがブロックされたかどうか、どのテナントまたはプロジェクトがキーを提供したかを記録する必要があります。このような可視性がなければ、より厳格な管理により請求の不明確さは軽減されますが、依然としてオペレータに不十分なトラブルシューティング データが残る可能性があります。

3 番目のステップは、開発者のワークフローです。 AI ゲートウェイに依存するアプリケーションは、資格情報が不足している場合に早期に失敗する必要があります。起動チェック、デプロイメントの検証、または管理コンソールの警告は、運用リクエストが拒否された後に問題を発見するよりも優れています。

残りの不確実性は、機能自体に関するものではなく、導入パターンに関するものです。 Cloudflareは新しいコントロールを文書化しましたが、各オペレーターはそれをどこに適用するかを決定する必要があります。一部のチームは、内部実験のためにフォールバック請求の復元力を好む場合があります。実稼働テナント トラフィックのデフォルトを BYOK のみにする人もいます。重要な変更は、これがルーティング層内に隠された暗黙的な動作ではなく、ガバナンスの選択となることです。