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