AI API ゲートウェイのコントロール プレーン調整
AI API ゲートウェイは、プロバイダーのプロジェクト、ワークスペース、サービス アカウント、API キー、制限、レポートが依然として変動している間に、ランタイムのルーティングと請求を一元化できます。帰属、支出制御、および緊急措置が分岐する前に、テナント ポリシーに対して上流のコントロール プレーンを調整します。
AI API ゲートウェイは、上流のプロバイダーのコントロール プレーンが変動し続ける一方で、ランタイム アクセスを統合しているように見せることができます。チームは多くの場合、推論呼び出し、請求、API キー管理、使用状況分析をゲートウェイで一元管理し、OpenAI プロジェクト、Anthropic ワークスペース、Google クラウド プロジェクト、Gemini キー、サービス アカウント、予算、レポート スコープを手動で構成したままにします。これにより、静かな障害モードが作成されます。ゲートウェイは 1 つのテナント ポリシーが存在すると言っていますが、プロバイダー アカウントは別のものを強制または報告します。
実際のパターンは、コントロール プレーンの調整です。上流プロバイダーの管理オブジェクトをインベントリとして扱います。観察されたインベントリを、ゲートウェイ内の目的のテナント ポリシーと比較します。ドリフトの結果を生成し、承認を通じて修復をルートし、明らかにリスクの高い状態に対して自動アクションを予約します。
この記事では、事実、推奨事項、予測を分けて説明します。事実は、今日文書化されたプロバイダーの行動です。推奨事項は、ゲートウェイ オペレーターにとってのアーキテクチャの選択です。マルチプロバイダーの AI スタックが成熟するにつれ、予測は運用上のプレッシャーになる可能性があります。
ゲートウェイ導入後のドリフトの様子
ランタイム ゲートウェイは問題の 1 つの層を解決します。アプリケーションは共通のエンドポイントにリクエストを送信し、テナントはスコープ指定されたゲートウェイ キーを取得し、使用状況は 1 つの台帳に記録されます。しかし、上流のプロバイダー オブジェクトは依然として重要です。どのプロジェクトまたはワークスペースがキーを所有するか、どのレポートに支出が含まれるか、どのレートとリソース制限が適用されるか、およびどのような緊急制御が利用できるかを決定します。
一般的なドリフトの例は次のとおりです。
- テナントはゲートウェイ内の OpenAI プロジェクトにマッピングされていますが、ランタイム キーは依然として共有のデフォルト プロジェクトに属しています。
- Anthropic API キーは間違ったワークスペースに作成されたため、目的のワークスペースに移動できません。
- Google API キーはコンソール フローの外で作成され、制限が明示的に設定されていないため、制限されないままです。
- プロバイダの支出しきい値がゲートウェイ テナントの予算より低いため、ゲートウェイが予期する前にプロバイダ側で障害が発生します。
- プロバイダの支出しきい値がゲートウェイ ポリシーより高いため、プロバイダ アカウントはそのままになります。バックストップが弱い。
- 使用状況レポートには null または継承されたワークスペース フィールドが含まれているため、財務部門はプロバイダーのコストとゲートウェイ テナントを明確に調整できません。
- サービス アカウントは、ゲートウェイの所有権モデルに関連付けられていないため、従業員がオフボーディングしても存続します。
リスクはセキュリティだけではありません。ドリフトにより、帰属、緊急対応、コスト管理、監査可能性が損なわれます。
設計で保持すべき事実
プロバイダのコントロール プレーンは交換可能ではありません。リコンサイラーは、オペレーターが効率的に作業できるように十分なデータを正規化する必要がありますが、プロバイダー固有のセマンティクスを保持する必要があります。
OpenAI プロジェクト
事実: OpenAI プロジェクトを使用すると、組織は作業を整理し、アクセスと制限を管理し、サービス アカウントをプロビジョニングし、プロジェクト スコープ内で使用状況を追跡できます。使用量はプロジェクトごとに分類でき、プロジェクトごとに使用量制限を設定できます。
事実: OpenAI プロジェクト サービス アカウントは、作成されたプロジェクトに固有です。生成された秘密鍵は一度表示され、それを失うと新しい鍵を生成する必要があります。
事実: OpenAI API 鍵は、すべて、制限付き、読み取り専用などの権限レベルをサポートしています。サービス アカウント API のキー権限は、変更しない限り、デフォルトですべてのプロジェクト API リソースへの読み取りおよび書き込みアクセスになります。
事実: OpenAI のドキュメントでは、あるヘルプ記事でプロジェクトの月間使用量制限をソフトしきい値として説明していますが、トラブルシューティング資料では project_spend_limit_exceeded などのハード制限エラーについても説明しています。ゲートウェイは、構成されたすべてのプロバイダーの支出制限が、すべてのアカウント構成で同期ハード キャップとして動作すると想定すべきではありません。
Anthropic ワークスペース
事実: Anthropic ワークスペースは、API 個のキー、チーム アクセス、およびコストを整理します。追加のワークスペースには、メンバー、サービス アカウント、API キー、およびリソース制限を含めることができます。
事実: API キーは、作成されたワークスペースに関連付けられており、ワークスペース間で移動することはできません。 Anthropic は、リクエストごとに該当するワークスペースと組織の制限を評価します。
事実: デフォルトのワークスペースには特別なレポート動作があります。使用状況レポートとコスト レポートには null workspace_id が表示される場合があります。これは、ゲートウェイがプロバイダー レポートをテナントにマッピングしようとするときに重要です。
事実: Anthropic 管理 API と分析 API は、組織とワークスペースの管理、API キー、使用状況レポート、コスト レポート、関連分析をカバーしますが、アクセスは管理キーとアカウントまたはロールの資格によって異なります。
Google クラウドとGemini キー
事実: Googleクラウド API キーのガイダンスでは、無制限の API キーは安全ではないと述べています。 API 制限は呼び出すことができる API を制限し、アプリケーション制限はキーを使用できる場所を制限します。 Google は、該当する場合は両方を設定することをお勧めします。
事実: Google クラウドのドキュメントには、コンソールで作成された API キーには少なくとも 1 つの API 制限が必要であると記載されていますが、gcloud または REST で作成されたキーには制限が明示的に指定されていない限り制限はありません。
事実: Google AI for Developers のドキュメントでは、Gemini API は標準から移行していると記載されています認証キーへのキー、制限のない標準キーは拒否され、サービスの中断を避けるために、標準キーは 2026 年 9 月までに認証キーに移行する必要があります。
事実: Google アラート付きの Cloud Billing 予算では、支出の上限が自動的に設定されません。プログラムによる Pub/Sub 通知はコスト管理の応答を自動化できますが、Pub/Sub 配信は少なくとも 1 回であり、メッセージが順序どおりに到着しない可能性があります。
リファレンス アーキテクチャ
推奨事項: ホット リクエスト パス内ではなく、ランタイム ゲートウェイの横にあるコントロール プレーン サービスとして調整を構築します。プロバイダ管理画面を読み取り、ゲートウェイ テナント ポリシーと比較し、ドリフト イベントを発行する必要があります。
実際のアーキテクチャには 5 つの部分があります:
- 望ましい状態ストア: ゲートウェイ テナント ポリシー: テナント、所有者、許可されたプロバイダ、モデル プロファイル、予算ポリシー、料金ポリシー、許可された上流プロジェクトまたはワークスペース、キーの所有権、および緊急status.
- 観察された状態のインベントリ: 管理 API、請求エクスポート、コンソール エクスポート、またはスケジュールされたスキャンを通じて検出されたプロバイダ オブジェクト。
- プロバイダ アダプタ: OpenAI、Anthropic、Google クラウド、およびネイティブ ID を保持するその他のプロバイダ固有のコレクタセマンティクス。
- ドリフト エンジン: プロバイダーの状態をサイレントに変更するのではなく、結果を生成する決定論的な比較。
- 修復ワークフロー: チケット、承認、チャット アラート、高リスク ドリフトに対する狭い範囲の自動アクション。
ゲートウェイはテナントのソースのままです。請求の真実。プロバイダーのコストと使用状況レポートは、決済入力と異常シグナルになります。プロバイダのレポートでは遅延が発生したり、異なるディメンションが使用されたり、ゲートウェイ テナントに適切にマッピングされていないレポート フィールドが公開されたりする可能性があるため、この区別は重要です。
意味をなくすのではなく、インベントリを正規化する
推奨事項: 正規化されたインベントリ テーブルを使用しますが、プロバイダ固有のフィールドを含めます。 OpenAI プロジェクト、Anthropic ワークスペース、および Google クラウド プロジェクトを同じオブジェクトであるかのように装わないでください。
有用なインベントリ モデルには次のものがあります:
- プロバイダー: openai、anthropic、google、azure、または別のアダプターname.
- provider_account_id: 組織、請求先アカウント、またはクラウド アカウント ID。
- container_type: プロジェクト、ワークスペース、クラウド プロジェクト、フォルダー、またはアカウント。
- container_id: プロバイダー ネイティブ プロジェクトまたはワークスペースidentifier.
- container_name: プロバイダーからの人間が判読できるラベル。
- tenant_id: マップされたゲートウェイ テナント、またはマップされていない場合は null。
- service_account_id: プロバイダー サービス アカウントまたはワークロード ID
- api_key_id: キーの指紋、キー ID、またはハッシュ化されたキー識別子。このテーブルには未加工のプロバイダ シークレットを保存しないでください。
- key_scope: プロジェクト、ワークスペース、組織、アプリケーション制限、API 制限、または同等のプロバイダ固有のスコープ。
- 権限: ネイティブ権限レベル、ロール バインディング、制限付き機能リスト、または読み取り/書き込みstate.
- model_allowlist: モデルまたは API ファミリで、キーが到達できます。プロバイダはそのコントロールを公開します。
- rate_policy: 観察されたプロバイダの制限と、それがサポートすると予想されるゲートウェイ ポリシー。
- spend_policy: 観察されたプロバイダのしきい値、または予算とゲートウェイ テナントの予算ポリシー。
- reporting_scope: 既知の null または継承されたフィールドを含むプロバイダ レポートで予期されるディメンション。
- last_seen_at: 最新のスキャンのタイムスタンプ。
- owner: ゲートウェイ テナント、チーム、サービス所有者、または人間owner.
- source: admin API、請求のエクスポート、コンソールのエクスポート、構成のインポート、または手動構成証明。
このテーブルは追加に適している必要があります。オペレータには履歴が必要です。つまり、キーが最初に出現した時期、出現しなくなった時期、その権限がいつ変更されたか、どのスキャナが変更を観察したかなどです。
望ましい状態を明示的に定義する
推奨事項: 調整は、望ましい状態が具体的である場合にのみ機能します。テナント A が Anthropic を使用する可能性があるなどのポリシーは曖昧すぎます。テナント A などのポリシーは、ワークスペース ws_123、サービス アカウント svc_billing_prod を使用し、人間が所有するランタイム キーは使用しない、モデル プロファイルのサポートは高速、プロバイダーの支出しきい値はゲートウェイ予算の 80 ～ 110 パーセントである必要があります。
望ましい状態には次のものが含まれている必要があります。
- 各テナントがどの上流コンテナを使用できるか。
- かどうかテナントはゲートウェイ所有の認証情報、テナントの BYOK 認証情報、またはその両方を使用します。
- ランタイム キーはサービス アカウントが所有する必要があるかどうか。
- どのプロバイダ API とモデルが許可されるか。
- 許容可能なアップストリーム費用の最大および最小しきい値。
- 予想されるプロバイダ レポートのディメンション決済。
- Google キーの必須アプリケーションと API 制限。
- 各プロバイダーとテナントの緊急無効化動作。
バージョン管理されたポリシー テーブルに望ましい状態を保存します。すべてのドリフト検出結果は、比較に使用されるポリシー バージョンを参照する必要があります。これにより、ポリシーの変更によって多くの新しい検出結果が作成された場合に、レビューとロールバックが可能になります。
オペレーターが操作できるドリフト クラスを実装する
推奨事項: 型指定されたドリフト検出結果を出力します。一般的な不一致アラートを回避します。オペレータは、何が壊れたのか、なぜそれが重要なのか、どのアクションが許可されているのかを知っておく必要があります。
役立つドリフト クラスは次のとおりです。
- missing_container: テナント ポリシーでは、存在しない、またはスキャナに表示されなかったプロバイダ プロジェクトまたはワークスペースが想定されます。
- unmapped_container: プロバイダ プロジェクト、ワークスペース、またはクラウド プロジェクトは存在しますが、テナント マッピングがありません。
- wrong_container: テナント トラフィックで使用されるキーは、ポリシーで許可されているものとは異なるプロジェクトまたはワークスペースに属しています。
- stale_key: プロバイダ キーは、定義された期間ゲートウェイ トラフィックに表示されませんが、アクティブなままです上流。
- orphaned_owner: キーまたはサービス アカウントは、オフボードされたユーザーまたはマップされていない ID によって所有されています。
- excessive_permission: キーには、ゲートウェイ ポリシーが必要とするよりも広範なプロバイダー権限があります。
- unrestricted_google_key: a Google キーには、必要な API 制限、アプリケーション制限、または Gemini と互換性のある認証移行状態がありません。
- limit_below_policy: プロバイダ制限により、ゲートウェイ ポリシーが予期する前にトラフィックがブロックされる可能性があります。
- limit_above_policy: プロバイダ制限は、制限として機能するには寛大すぎます。 backstop.
- reporting_unreconcilable: プロバイダの使用状況レポートや費用レポートをテナント、キー、プロジェクト、またはワークスペースに適切にマッピングできません。
- scanner_blind: 必要な管理 API またはロールが欠落しているため、調整者は要求を行うことができません。
各検出結果は次のとおりです。これには、重大度、信頼度、影響を受けるテナント、プロバイダー ネイティブの識別子、最初に観察された時刻、最後に観察された時刻、推奨されるアクション、許可された自動アクション、ロールバック メタデータが含まれます。
修復: ドライに開始し、範囲を絞って自動化します
推奨事項: デフォルトでは、変更の前にドライランの結果をテストします。プロバイダー管理者の資格情報は強力です。マッピングが不適切な場合、本番環境のワークロードが無効になったり、アトリビューションが削除されたり、費用のかかる停止が発生したりする可能性があります。
2 段階モデルが適切に機能します:
- 通知とチケットを発行: 所有者ラベルの欠落、マップされていないレポート フィールド、ポリシーからわずかに逸脱した支出しきい値など、低リスクまたはあいまいな変動については。
- 事前承認済み自動アクション: 漏洩したキー、オフボードされたユーザーが所有するキー、無制限の Gemini 対応キー、またはゲートウェイですでに無効になっているテナントに関連付けられたキーなど、限定された高リスクのケースの場合。
可能な場合、自動化は元に戻せる必要があります。たとえば、ゲートウェイ キーを無効にすることは、アップストリーム キーを削除するよりも簡単に元に戻すことができます。公開後に上流のプロバイダー キーのローテーションが必要になる場合がありますが、それには下流の展開の調整が必要です。ゲートウェイ予算をゼロに下げると即時に監査可能になりますが、プロバイダーの予算アラートは遅れたり、非同期に動作する場合があります。
緊急時シャットダウン ランブック
推奨事項: 必要になる前にプロバイダーの緊急シャットダウン ランブックを作成します。ゲートウェイ コントロールとプロバイダ コントロールの両方をカバーする必要があります。
実際のシーケンスは次のとおりです。
- 影響を受けるゲートウェイ キーを無効にマークし、新しいランタイム リクエストがゲートウェイで停止するようにします。
- テナント ゲートウェイの予算または予約制限をゼロに設定します。
- 影響を受けるプロバイダまたはモデル プロファイルへのテナント ルーティングをブロックします。
- アップストリームを取り消す、無効にする、またはローテーションするプロバイダ キーがサポートされている場合。
- プロバイダ キーが利用可能でアカウント設定に役立つ場合は、プロバイダ側のしきい値を低くします。
- アクター、タイムスタンプ、理由、プロバイダ オブジェクト、ロールバック命令を含むすべてのアクションを記録します。
- 伝播遅延を報告した後、プロバイダ側の使用量とコストを調整します。
- インシデント後のドリフト レビューを開きます。オブジェクトがどのように管理されなくなったか、また、どのポリシー チェックでもっと早く検出する必要がありましたか?
このシーケンスでは、最初にゲートウェイでトラフィックを意図的に停止します。プロバイダーの制御は依然として重要ですが、速度、可用性、適用のセマンティクスが異なる場合があります。
トレードオフ
自動調整によりずれは軽減されますが、管理者の資格情報が必要です。推奨事項: 管理者の認証情報を実行時の認証情報から分離し、別のボールト パスに保存し、変更権限を制限し、すべての読み取りと書き込みを監査します。
テナントごとに 1 つのアップストリーム プロジェクトまたはワークスペースにより、アトリビューションとブラスト半径の制御が向上します。トレードオフは、オブジェクトのスプロール化、プロバイダの制限、運用オーバーヘッド、および共有キャッシュ、プロビジョニングされた容量、またはプールされたスループット戦略の複雑さです。
プロバイダの制限は便利なバックストップとなりますが、ゲートウェイ側の予算予約の代わりにはなりません。プロバイダーの制限は、ソフト、非同期、プラン依存、またはリクエストとレポート間で異なる評価になる場合があります。
スキャンを頻繁に行うとドリフトの検出が速くなりますが、管理者 API の使用量、割り当てのプレッシャー、およびアラートの量が増加します。より良いパターンは、可能な場合はイベント ドリブンの更新に加え、完全性を確保するためにスケジュールされた調整を行うことです。
正規化によりダッシュボードが使用可能になりますが、過剰な正規化により重要な違いが隠蔽されます。ネイティブ プロバイダー フィールドを検出結果とレポートに表示したままにします。
予測
予測: AI API ゲートウェイ オペレーターは、クラウド IAM や請求先アカウントの構成と同様に、プロバイダー管理オブジェクトを規制された構成として扱うことが増えています。ランタイム プロキシだけでは、財務、セキュリティ、プラットフォームの各チームが多くのテナントにまたがる支出とアクセスの規模を満足させることはできません。
予測: 主要なモデルは変化し続けます。標準キーから認証キーへの Gemini の移行は、目に見える例です。プロバイダー ネイティブのオブジェクト タイプ、移行状態、および最後に確認されたソースを保存する調整システムは、生のシークレットとプロバイダー名のみを保存するシステムよりも、これらの変更をより適切に処理します。
予測: プロバイダーのレポートは、解決には引き続き役立ちますが、リアルタイムの適用には不均一になります。独自のリクエスト台帳、予約モデル、テナントの属性を保持するゲートウェイは、プロバイダーの請求エクスポートを待機するゲートウェイよりも予測しやすくなります。
実装チェックリスト
- テナントとプロバイダーのマッピング用に望ましい状態のポリシー テーブルを作成します。
- プロバイダー ネイティブの識別子とハッシュ キーを使用して監視インベントリ テーブルを作成します。 ID。
- 最初に読み取り専用のプロバイダ アダプターを構築します。
- スキャナーの障害を非表示にするのではなく、検出結果として分類します。
- 重大度および信頼性を持って型指定されたドリフト イベントを発行します。
- 検出結果をチケット、アラート、または承認キューにルーティングします。
- 事前承認された限定された高リスクの場合にのみ自動アクションを有効にする
- 管理者の資格情報を実行時の資格情報とは別にしてください。
- 決済と異常検出のために、ゲートウェイ台帳レコードをプロバイダー レポートに結合します。
- 非運用テナントで緊急シャットダウンをテストしてから、信頼してください。
実行可能な結論
やってはいけない共通のエンドポイントを介した推論呼び出しのルーティングを停止します。上流のコントロール プレーンがドリフトした場合でも、ゲートウェイは帰属を失ったり、古いキーを見逃したり、プロバイダーの支出動作を読み間違えたり、緊急時に障害を起こしたりする可能性があります。
最も強力なパターンはシンプルです。ゲートウェイに必要なテナント ポリシーを書き込み、観察されたプロバイダー オブジェクトをスキャンし、プロバイダー固有の意味を保持し、型指定されたドリフト結果を出力し、制御されたワークフローを通じて修復します。読み取り専用で開始します。在庫を証明します。次に、修正するドリフトよりもリスクが低いアクションのみを自動化します。