AI ワークフローが業務を支えている場合、プロバイダーの障害が短時間でも、意思決定が遅れたり、サービスが中断したりすることがあります。私たちは、OpenAI のモデルを使ってエージェント型アプリケーションやサイバーセキュリティのワークフローを構築する金融サービス企業と協力してきました。本稿では、決済ワークフローにおける読み取り専用の不正判定を例に、重要なワークロードの本番環境でのルーティングと復旧をどのように設計しているかを説明します。
ここでは、OpenAI API に直接アクセスする経路をファーストパーティ （1P）、クラウドプロバイダーを通じて OpenAI のモデルにアクセスする経路をサードパーティ （3P） と呼びます。この区別は、アプリケーションの実行場所には依存しません。まず、プレビュー段階のモデルや機能を直接アクセスで評価する利点、ワークロードの要件やプライベート接続を踏まえた経路の選び方、安全にフェイルオーバーできる処理を取り上げます。続いて、既存のゲートウェイにフェイルオーバーポリシーを実装するための Codex プロンプトと、有効化前に検証すべき項目を紹介します。
両方の経路を使う理由
本番環境でクラウドプロバイダーを利用していても、OpenAI に直接アクセスできることには利点があります。主な利点の一つは、プレビュー段階のモデルや機能を試せることです。OpenAI API で直接利用できるようになれば、利用条件を満たすチームは、選定したクラウドプロバイダーが対応する前に、自分たちのワークフローで評価できます。
本番用の経路は、多くの場合、ワークフローの実行場所を考慮して選びます。あるアプリケーションではサードパーティのクラウドサービスが既存のインフラや運用上の統制に適していても、別のワークフローでは OpenAI への直接アクセスの方が要件に合うこともあります。選んだ経路で必要なモデル、機能、動作を検証し、その後の実験にも OpenAI への直接アクセスを活用してください。利用できるモデルや機能は、プロバイダー、エンドポイント、リージョン、アカウントによって異なります。
重要なワークロードでは、1P と 3P の間でフェイルオーバーできることを検証したうえで、その利用も検討します。プロバイダー間のフェイルオーバーとは、プライマリがリクエストを処理できないときに、承認済みの別のプロバイダーを通じてリクエストを再試行することです。リクエストを安全に再実行でき、代替経路がワークフローの要件を満たす場合にのみ有効です。
たとえば、世界各地でサービスを提供する決済事業者が、単独で完結する読み取り専用の不正判定に Responses API を使うとします。判定結果が使われる前に呼び出しがタイムアウトした場合、アプリケーションは取引の期限内に、検証済みのセカンダリ経路で再試行できる場合があります。
一方、進行中の Agents API セッションには、別の復旧方法が必要です。プロバイダーを切り替えるだけでは、会話や保存済みの作業を再開することも、それまでに実行したアクションの結果を照合することもできません。こうした復旧ははるかに難しいため、本稿では扱いません。
この違いから、私たちは複数のプロバイダーへの対応をプラットフォームの機能と位置づけ、フェイルオーバーの可否はワークフローごとに判断しています。
計画的なルーティングとフェイルオーバー
本番用の経路を選ぶことと、フェイルオーバーを承認することは、別々の判断です。計画的なルーティングには、複数のプロバイダーにトラフィックを分散したり、処理能力を超えた分を別の経路に送ったりする方法があります。それぞれについて、処理能力、コスト、品質、復旧を個別にテストする必要があります。
一部のお客様は、必要に応じて Decisions API の結果を経路選択の判断材料にしています。ワークフローが障害に対応できるよう、このサービスが利用できない場合のルーティング動作も定義してください。
以下の図では、1P をプライマリ、承認済みの 3P 経路をセカンダリとしています。ワークロードに応じて、どちらもプライマリにできます。
ルーターの位置づけ
図 1. プライマリは OpenAI API、セカンダリは承認済みのサードパーティプロバイダーです。プラットフォームがルーターを運用し、アプリケーションがポリシーを定義します。モデル、機能、処理能力、統制、可用性は経路によって異なる場合があります。
経路ごとに別々のルールを適用できるなら、既存のモデルルーターや LLM ゲートウェイを利用できます。通常のトラフィックはプライマリに送り、フェイルオーバー条件を満たした場合にのみ、テスト済みのセカンダリを使用します。
各経路を誰が、どのリージョンで、どのモデルや API を使って利用できるかを定義します。承認の対象となる法人、チーム、プロバイダーのアカウントまたはプロジェクト、データの取り扱いルールを記録してください。承認は、合意したワークロードとリージョンにのみ適用されます。
プライベート接続と経路の選択
規制対象の業界では、セキュリティ対策の一環としてプライベート接続を必須とするお客様が多くいます。その場合、経路の選定時に、アプリケーションを実行するクラウドから各プロバイダーにプライベート接続する方法も確認します。下図では、お客様のプライベートネットワーク内にアプリケーションとゲートウェイを配置し、各プロバイダーに個別のプライベート経路で接続しています。
図 2. プライマリは OpenAI API（1P）、セカンダリは Amazon Bedrock や Azure OpenAI などの承認済みプロバイダー（3P）です。セカンダリを使用するのは、切り替え条件を満たす復旧時のトラフィックだけです。
本稿の公開時点では、1P と 3P でプライベート接続の方法が異なります。OpenAI への直接アクセス（1P）に使う OpenAI Private Link は、Azure プライベートエンドポイントを使用します。AWS や Google Cloud 上のワークロードから、このプライベート経路で OpenAI API に直接アクセスするには、お客様が Azure への接続を用意して管理する必要があります。
サードパーティ経由のアクセス（3P）では、Amazon Bedrock は AWS PrivateLink を介して API ごとのインターフェイス VPC エンドポイントを使用し、Azure OpenAI は Azure プライベートエンドポイントを使用します。フェイルオーバーを有効にする前に、両方の経路で DNS とアクセスを検証し、対象リージョンで必要なモデルと API がサポートされていることを確認してください。OpenAI Private Link はリージョン間でエンドポイントを自動的に切り替えないため、別のリージョンで復旧するには、別途設定とテストが必要です。復旧時にパブリック HTTPS に切り替える場合も、明示的な承認が必要です。
各プロバイダーの対応状況は変わることがあります。経路を選択または有効化する前に、公式ドキュメントを確認してください。
フェイルオーバーが可能な処理
すべての処理に適切なセカンダリ経路があるとは限りません。たとえば、次のような場合があります。
- 必要な機能がない場合： ワークフローによっては、OpenAI API に直接アクセスし、ウェブ検索で最新情報を確認します。セカンダリ経路がウェブ検索に対応していない場合、何も知らせずに検索を省略してはいけません。代替実装を検証するか、その処理のフェイルオーバーを無効のままにします。
- 動作が未検証の場合： モデル名が一致していることや、API に互換性があることだけでは不十分です。セカンダリを有効にする前に、ワークフローで使用しているハーネスと評価をセカンダリで実行してください。
- データの所在地や状態に制約がある場合： 承認済みのデータ所在地要件に違反する宛先や、処理を安全に完了するために必要な状態にアクセスできない宛先には切り替えないでください。
条件を満たすセカンダリがない場合は、合意した期限の範囲内で処理をキューに入れる、承認済みの縮退運転や手動対応に切り替える、または安全に停止するという対応を取ります。ワークフロー全体を切り替えられなくても、再試行可能な推論ステップだけなら条件を満たす場合があります。
読み取り専用の不正判定がタイムアウトしても、結果がまだ使われておらず、時間に余裕があれば再試行できる場合があります。出力が別のシステムに届いた後の復旧には、テスト済みの再開手順が必要です。アクションがすでに完了している可能性がある場合は、再開前にその結果を確認し、重複実行を防いでください。
フェイルオーバーの判断基準と手順
決済の例では、モデルが混雑している場合や利用できない場合に、承認済みの別のモデルに切り替えられます。これがモデルのフォールバックです。別のプロバイダーを通じて判定を再試行するのが、プロバイダー間のフェイルオーバーです。モデルとプロバイダーの両方を変更する場合もあります。
まず、プロバイダーを切り替えることで問題が解消するかを検討します。共通のゲートウェイ、情報取得サービス、認証基盤の障害は、両方の経路に影響する可能性があります。セカンダリの接続性、アクセス、処理能力をテストし、利用するモデルやホスト型ツール、データ所在地要件のもとで別のリージョンでの復旧が可能かを確認してください。
失敗や応答の遅延が続く場合は、サーキットブレーカーで、影響を受けた経路への新規リクエストを一時停止できます。プロバイダー、モデル、リージョン、ワークフローごとに、エラーと応答時間のしきい値を設定してください。この場合も、個々のリクエストがフェイルオーバー条件を満たす必要があります。
リクエストを再試行する前に、安全に再実行でき、ワークフローの期限内に完了できることを確認します。セカンダリは承認済みかつ有効で、正常に稼働し、追加の負荷に対応できることがテストで確認されている必要があります。予算にも余裕が必要です。OpenAI のエラーコードとレート制限のドキュメントを参照し、他のプロバイダーについてもエラー、再試行、クォータ、課金のルールを確認してください。
次の表は、自動フェイルオーバーを導入する際に、切り替え条件を慎重に設定するための出発点です。HTTP ステータスだけで判断せず、各プロバイダーが返すエラーの詳細を確認してください。
| 条件 | ルーティングの判断 |
|---|---|
| 一時的なサービス障害または接続障害 | 再試行可能なプロバイダーエラー、接続のリセット、タイムアウトでは、フェイルオーバーを検討します。 |
| 継続的なスロットリングまたは応答の遅延 | 待機するとリクエストまたはワークフローの期限を超える場合は、フェイルオーバーを検討します。一時的なスロットリングと、対処が必要なクォータや課金の問題を区別してください。 |
| 無効なリクエスト、アクセス失敗、応答拒否、利用枠の消尽 | リクエスト形式の不備、401/403 エラー、安全上の理由による応答拒否、クォータやクレジットの使い切り、支出上限への到達では、経路を自動で切り替えません。原因を解消するか、対応できる担当者にエスカレーションしてください。未分類のエラーでフェイルオーバーを起動しないでください。 |
| 部分的な出力、またはツールによるアクションの結果が不明 | 状況を確認せずに再実行しないでください。途中までの応答を別の経路で継続できるとも限りません。再開前にアクションの結果を照合し、書き込みの重複を防いでください。 |
| 特定のモデルが利用できない、または処理能力が不足している | 品質、機能、レイテンシの要件を満たす承認済みの別のモデルを試します。プロバイダー内で複数のモデルに共通する処理経路に影響がある場合は、上記の前提条件のもとでプロバイダー間のフェイルオーバーを検討します。 |
アプリケーション、SDK、ゲートウェイがそれぞれ再試行して試行回数が膨れ上がるのを防ぐため、再試行は一つの層でまとめて制御します。共通の再試行枠を設け、有効な Retry-After の指示に従ってください。有効な指示がない場合は、ジッター付きの上限付き指数バックオフを使用します。試行のたびに待機時間を延ばし、その長さにランダムなばらつきを加え、試行回数に上限を設けます。安全に再実行できる推論呼び出しに限り、リクエストとワークフローの両方の期限内で再試行してください。
セカンダリが過負荷にならないように、フェイルオーバー時のトラフィックを制限します。プライマリで代表的なリクエストのエラーと応答時間が所定の期間にわたってしきい値内に収まったら、トラフィックを段階的に戻します。しきい値を超えたら、トラフィックを増やすのを一時停止してください。両方の経路に制約がある場合は、ワークフローで合意した復旧ポリシーに従います。
Codex を使ったフェイルオーバーポリシーの実装
ここまでで定めた復旧ルールは、Codex を使って既存の LLM ゲートウェイに実装できます。決済の例では、対象を単独で完結する読み取り専用の不正判定ステップに限定します。プライマリ経路を維持し、セカンダリの承認と検証が済むまではフェイルオーバーを無効にしておきます。
ゲートウェイ設定またはアプリケーションのルーティングを管理しているリポジトリを Codex で開き、以下のプロンプトをワークフローと使用予定の経路に合わせて調整してください。
[workflow’s self-contained, read-only inference step] を対象に、プロバイダー間のフェイルオーバーを [repository/gateway] に追加してください。デフォルトでは無効にしてください。プライマリ経路を維持し、既存のゲートウェイ、承認済みのプラットフォーム経路、ワークフローのポリシーを再利用してください。
ゲートウェイ、SDK、アダプターのバージョン、デプロイ設定、API、最新の公式ドキュメントを確認してください。アプリケーションとゲートウェイの変更は、担当者と必要なレビューに応じて分けてください。他の担当者が管理する依存先については、設定と統合テストを用意してください。サポートされていない制御項目を明示してください。承認の有無や上限値を推測せず、確認が済むまで、それらに依存するフェイルオーバー経路は無効にしておいてください。
テスト済みのプロバイダー別エラーマッピングを使用してください。フェイルオーバーの対象は、一時的なサービス障害やネットワーク障害、および一時的であることを確認できたスロットリングに限ります。これらの場合も、安全に再実行できることが条件です。また、セカンダリが承認済みかつ有効で正常に稼働し、必要な機能とデータに関する統制を備え、必要な処理能力がテスト済みで、予算と完了までの時間が残っている場合にのみ切り替えてください。無効なリクエスト、アクセス失敗、応答拒否、クォータ・クレジット・予算の枯渇、未知のエラー、原因を特定できない 429 エラーでは、フェイルオーバーを禁止してください。
クライアント、ゲートウェイ、SDK 全体の再試行を一つのコントローラーで管理してください。競合する再試行やフェイルオーバーの連鎖を無効にし、総試行回数には共通の上限を一つ設け、リクエストとワークフローの両方の期限を守ってください。全体の期限内で、試行ごとに設定されたタイムアウトを適用してください。論理リクエストごとに結果を一つだけ採用し、それ以前の試行から遅れて届いた応答は無視してください。有効な Retry-After の指示に従い、それ以外の場合はジッター付きの上限付き指数バックオフを使用してください。出力が途中までしか得られていない場合やアクションの結果が不明な場合は、状況を確認せずに再実行しないでください。プロバイダー間で状態が引き継がれると仮定しないでください。キューでの待機、限定的な結果の返却、または停止について、承認済みのポリシーを適用してください。手動での無効化、サーキットブレーカーによる遮断、段階的なフェイルバックを実装してください。
外部ネットワークへの通信を遮断し、ローカルの HTTP スタブを使って実際のリクエスト経路をテストしてください。正常終了、切り替え対象の障害、切り替えを禁止する各エラー分類、切り替え条件を満たさない場合、部分的な出力、アクションの結果が不明な場合、予算の枯渇、両経路の障害、および復旧制御の動作について、経路を試す順序、呼び出し回数、経過時間をアサーションで検証してください。切り替えを禁止するケースでは、セカンダリの呼び出し回数が必ず 0 回になるようにしてください。テスト用の仮の上限値はテストフィクスチャ内に限定し、シークレットを保護してください。許可を得ずに実サービスを呼び出したり、デプロイしたりしないでください。
必要最小限のパッチ、各要件に対応するテスト、その結果、ロールバック手順、実際の経路で確認が必要な残りの項目を提示してください。未検証のフェイルオーバー経路はすべて無効のままにしてください。このプロンプトでは、対象を絞ったゲートウェイの変更、セカンダリを呼び出す場合と呼び出さない場合を確認するテスト、実際の経路で確認が必要な項目の一覧を Codex に求めています。まずパッチとローカルテストの結果をレビューしてください。その後、モデルの動作、データに関する統制、処理能力、負荷がかかった状態での復旧を検証してから、フェイルオーバーを有効にします。
経路と復旧の検証
決済の例で行う確認は、他の重要なワークロードにも適用できます。品質、安全性、出力形式、ツールの使用、コンテキストの上限について、両方の経路がワークフローの受け入れ基準を満たすかをテストしてください。処理ティアやホスト型機能も含め、テストした構成、利用可否、アクセス要件を記録し、再テストのタイミングを定めます。
プロンプトや出力のログ記録に関する制限を含め、不正判定のデータに適用される制約は、通常運用時も復旧時も同じです。どちらの経路についても、有効化する前に、認証情報、ネットワーク経路、情報取得、ツール、保存された状態、ログを、法務、プライバシー、セキュリティ、データガバナンスの各担当者と確認してください。
このレビューでは、サービスのドキュメントと契約に基づき、データの処理場所と保存場所、保持期間、暗号化方法、鍵とアクセス権の管理者を確認します。エンドポイントの所在地やプライベート接続の有無だけでは判断できません。適用される統制、利用条件、責任分担はエンドポイントによって異なります。OpenAI のデータ管理を参照してください。
要件に合う経路でも、復旧時のトラフィックを処理する余力が必要です。プロバイダー全体のダッシュボードでは、不正判定に使うモデルのスロットリングを見落とすことがあります。各経路について、モデル、アカウントまたはプロジェクト、リージョンごとに、単位時間あたりのリクエスト数とトークン数、同時リクエスト数、スロットリング、応答時間、承認済み予算の残額を追跡してください。
セカンダリが追加負荷に耐えられるかを確認するため、セカンダリの既存の処理に、想定される不正判定のトラフィックと再試行を加えて負荷テストを行います。その結果から、フェイルオーバー時のトラフィック上限を設定し、どのリクエストを待機させるか、機能を制限して処理するか、停止するかを決めます。クォータに余裕があるだけでは、期限内に処理が完了する保証はありません。
不正判定の経路を切り替えると、コストや応答時間が変わる場合もあります。キャッシュミスに伴うコスト、データ転送料金、接続コストを含め、判定の成功 1 件あたりのコストを比較してください。キャッシュミスやクラウドをまたぐリクエストによる遅延の増加も測定します。
最後に、表に挙げた障害シナリオに加え、必要な機能がない場合や、セカンダリが混雑している場合、利用できない場合を、負荷をかけた状態でテストします。トラフィック制限、手動停止、プライマリへの段階的な復帰を含め、復旧ポリシーが意図どおりに機能することを確認してください。
復旧の成否は、サービスが復旧するまでの時間、期限内に完了した判定の件数、結果の品質、コスト、アクションの重複状況で評価します。認証情報の期限切れ、設定の変更、処理能力の変動を踏まえ、定期的に復旧訓練を行って、検証結果を最新の状態に保ちます。
復旧の責任分担
実務で採用できる方法の一つは、ルーティングサービスの運用責任とアプリケーションの運用責任を分けることです。たとえば、プラットフォームチームがプロバイダーとの連携、ルーター、監視、監査ログを運用します。同チームは、ルーティングサービスを本番運用できる状態に保ち、宛先、ID、データ、トラフィック、支出に関する統制を適用します。経路の無効化とプライマリへの復帰を管理するオンコール担当者も明確にします。
この分担では、アプリケーションの担当者が、フェイルオーバーできる処理、サービスと品質の目標、許容できる機能制限を定めます。また、業務上の結果、保存された復旧用のコンテキスト、ツールの権限、応答の検証、アクションの重複防止にも責任を持ちます。状態やツールを共有している場合も同様です。
チームの事情に応じて、これらの役割を兼務したり、別の形で分担したりしても構いません。フェイルオーバーを有効にする前に、統制を承認する人、経路のテストと運用手順書に責任を持つ人、インシデント発生時に対応する権限を持つ人を決めてください。
まとめ
本番環境でクラウドプロバイダーを利用していても、OpenAI への直接アクセスを選択肢に加えてください。利用条件を満たすチームは、プレビュー段階のモデルや機能を評価でき、重要なワークロードの復旧経路としても直接アクセスを検討できます。本番に 1P と 3P のどちらを使うかは、ワークフローに必要な機能、ホスティング環境、運用上の統制に基づいて選びます。プライベート接続が必要な場合は、その要件も考慮してください。
重要なワークロードでは、まず単独で完結する読み取り専用の推論ステップを一つ選びます。Codex を使って、そのステップに適用するゲートウェイのポリシーとローカルテストを実装し、実際の経路でセカンダリがワークフローの要件を満たすかを検証します。こうして、いつ切り替え、いつ停止し、誰が判断するかを明確にした復旧計画をチームで用意できます。