障害時フォールバック階層
記事状態: 公開 · 最終確認: 2026-10-22
要点
Enterprise AIのフォールバックは「失敗したら別モデルへ送る」だけでは成立しません。障害の種類を判定し、再試行、別capacity/配備、別region、別提供元/モデル、機能縮退、durable queueまたは人手移管を、品質・データ所在・権限・副作用の制約付きで順序化します。
現在の判断
Enterprise AIのフォールバックは「失敗したら別モデルへ送る」だけでは成立しません。障害の種類を判定し、再試行、別capacity/配備、別region、別提供元/モデル、機能縮退、durable queueまたは人手移管を、品質・データ所在・権限・副作用の制約付きで順序化します。
どこまで当てはまるか
障害時フォールバック階層
詳しく理解する
要点と前提
Enterprise AIのフォールバックは「失敗したら別モデルへ送る」だけでは成立しません。障害の種類を判定し、再試行、別capacity/配備、別region、別提供元/モデル、機能縮退、durable queueまたは人手移管を、品質・データ所在・権限・副作用の制約付きで順序化します。
まず失敗を分類する
認証・認可・入力検証の失敗は、同じrequestを繰り返しても通常は解消しません。これを一律再試行すると負荷と遅延だけを増やします。一方、429、503、処理待ち時間の上限などの一時障害は、提供元が示すRetry-Afterやexponential backoff、jitter、再試行 budgetに従う余地があります。AWS Well-Architected Agentic AI Lensもretryable/non-retryableの分類、transient 失敗へのbounded 再試行、persistent 失敗への失敗時の代替処理、unrecoverable 失敗へのhuman reviewを分離しています。
フォールバック階層
F0: 妥当性の検証 / authz 失敗
同一requestの自動再試行を止め、入力、認証情報、権限、policyを修正します。権限拒否を可用性障害として別提供元へ迂回させてはいけません。
F1: transient transport / service 失敗
同一endpointでbounded 再試行を行います。backoff、jitter、最大回数または時間budgetを固定し、budget超過後だけ次段へ進みます。
F2: capacity / throttling
Retry-Afterを尊重し、別配備やcapacity tierへのspillover、またはqueueへ移します。interactive workloadとbatch workloadでは許容待ち時間が異なるため、同じ再試行 policyを共有しない設計が必要です。Microsoft Azureのthrottling guidanceもinteractiveでは限定再試行後のdegraded response、batchではfailed chunkのdurable enqueueを例示しています。
F3: region / 提供元 失敗
事前に用意したsecondaryへ切り替えます。ただしregion、データの保存地域、非公開 network、利用枠、モデル 利用可能性、認証情報を事前検証します。Microsoft FoundryのHA guidanceはGlobal/Data Zone 処理先の振り分けをapplication-level regional failoverの代替として扱わず、secondary 配備への処理先の振り分けをアプリケーション/gateway側で設計するよう示しています。
F4: モデル / 利用可能な機能 失敗時の代替処理
別モデル/提供元へ切り替える場合、ツール データ形式の定義、構造化された出力、文脈・入力情報 length、安全性 policy、latency、cost、model-specific behaviorが同値とは限りません。「応答が返った」ことを意味上の equivalenceの証拠にしません。重要な処理の流れでは代替先ごとに受入試験を行います。
F5: 利用可能な機能 degradation
検索・取得、ツール、記憶情報など非必須機能を停止し、限定機能で継続します。縮退状態はdownstreamと利用者へ明示し、通常応答と混同させません。AWS AGENTREL04-BP03もordered 失敗時の代替処理 alternatives、quality trade-off、health check、degradation notificationを要求しています。
F6: durable deferral / human escalation
副作用を伴う処理、再実行安全性が不明な処理、critical decisionはqueue/途中状態の保存地点またはhuman reviewへ退避します。処理待ち時間の上限や通信断だけで「処理されなかった」と判断して再実行すると、二重実行を起こす可能性があります。
データ所在を壊さない
Google Vertex AI / Gemini Enterpriseの資料は429/503等へのexponential backoffを案内し、global endpointがregional capacity issueを減らし得ることを示しています。一方、global endpointではprocessing locationを固定できない場合があります。データの保存地域要件がある環境では、可用性向上だけを理由にglobal endpointを無条件失敗時の代替処理にしてはいけません。契約・提供元・機能ごとの処理地域条件を確認します。
副作用を伴うツール/agent
失敗時の代替処理 chainはexactly-onceを自動的には保証しません。ツール callが外部システムへ届いた後にresponseだけ失われた場合、別モデル/提供元へ再実行すると同じ副作用を重複させる可能性があります。各edgeに重複実行を防ぐ性質 key、操作内容 主体の識別、提供元/対象 結果の照合、reconciliationの要否を持たせ、結果不明時は再送より先に外部状態を確認します。
受入試験
各失敗時の代替処理 edgeについて、trigger condition、retryability、maximum attempts/time budget、対象、データの保存地域、認証情報/権限、重複実行を防ぐ性質/side-effect 条件・契約、quality delta、稼働状況を観測する仕組み、return-to-primary条件を固定します。429、5xx、処理待ち時間の上限、authz denial、region loss、ツール 失敗を別々に注入し、意図した段だけが作動すること、失敗時の代替処理 loopが起きないこと、縮退状態が観測できること、復帰後に重複外部への変更・送信が発生しないことを結果の照合します。
運用で残す記録
障害class、選択した失敗時の代替処理 edge、attempt count、再試行 budget、primary/secondary 主体の識別、モデル/配備/バージョン、region、residency判定、degraded flag、操作内容 主体の識別、外部副作用の結果の照合、primary復帰条件を記録します。失敗時の代替処理成功率だけでなく、品質差、重複実行、誤った権限迂回、residency違反を別評価指標として監視します。
適用境界
提供元文書が保証するのは各サービスの処理先の振り分け、再試行、spillover等の機構と制約です。組織固有の失敗時の代替処理順序、異種モデル間の意味的同値性、ツール 処理の流れのexactly-onceまでは保証しません。失敗時の代替処理 chainは対象use caseのSLO、リスク、residency、cost、ツール 外部への変更・送信に対して個別に検証します。
未確認事項
- 異種提供元/モデル間の意味上の equivalenceを一般化できる一次根拠は確認できません。
- global endpoint利用時のprocessing location要件は提供元、契約、機能ごとの確認が必要です。
- agent/ツール 処理の流れの外部への変更・送信 exactly-onceは失敗時の代替処理機構だけでは保証されません。
参考資料
- AWS Well-Architected Agentic AI Lens, AGENTREL07-BP02
- AWS Well-Architected Agentic AI Lens, AGENTREL04-BP03
- Microsoft Foundry, High 利用可能性 and resiliency
- Microsoft Azure Well-Architected Framework, Throttling
- Google Cloud, Reduce 429 errors on Vertex AI
- Google Gemini Enterprise Agent Platform, 再試行 strategy
よくある失敗・反証
認証・認可・入力検証の失敗は、同じrequestを繰り返しても通常は解消しません。これを一律再試行すると負荷と遅延だけを増やします。一方、429、503、処理待ち時間の上限などの一時障害は、提供元が示すRetry-Afterやexponential backoff、jitter、再試行 budgetに従う余地があります。AWS Well-Architected Agentic AI Lensもretryable/non-retryableの分類、transient 失敗へのbounded 再試行、persistent 失敗への失敗時の代替処理、unrecoverable 失敗へのhuman reviewを分離しています。
まだ確認できていないこと
- EA-440-UNKNOWN-01
- 異種提供元/モデル間の意味上の equivalenceを一般化できる一次根拠は確認できません。
- global endpoint利用時のprocessing location要件は提供元、契約、機能ごとの確認が必要です。
- agent/ツール 処理の流れの外部への変更・送信 exactly-onceは失敗時の代替処理機構だけでは保証されません。
根拠資料
この記事には、直接開ける外部出典が登録されていません。出典IDや検証情報は末尾で確認できます。
更新履歴
EA-440-RESEARCH-20261022-R1: 正式な 監査/publication 対応付け
出典ID・検証情報・機械可読データ
根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。
- 記事ID
- EA-440
- 最終確認日
- 2026-10-22
- 提供元・モデル・プラン・利用環境
- —
- 対象地域
- —
元資料の全文と収録照合記録
要点と前提
Enterprise AIのフォールバックは「失敗したら別モデルへ送る」だけでは成立しません。障害の種類を判定し、再試行、別capacity/deployment、別region、別provider/model、機能縮退、durable queueまたは人手移管を、品質・データ所在・権限・副作用の制約付きで順序化します。
まず失敗を分類する
認証・認可・入力検証の失敗は、同じrequestを繰り返しても通常は解消しません。これを一律retryすると負荷と遅延だけを増やします。一方、429、503、timeoutなどの一時障害は、providerが示すRetry-Afterやexponential backoff、jitter、retry budgetに従う余地があります。AWS Well-Architected Agentic AI Lensもretryable/non-retryableの分類、transient failureへのbounded retry、persistent failureへのfallback、unrecoverable failureへのhuman reviewを分離しています。
フォールバック階層
F0: validation / authz failure
同一requestの自動retryを止め、入力、credential、permission、policyを修正します。権限拒否を可用性障害として別providerへ迂回させてはいけません。
F1: transient transport / service failure
同一endpointでbounded retryを行います。backoff、jitter、最大回数または時間budgetを固定し、budget超過後だけ次段へ進みます。
F2: capacity / throttling
Retry-Afterを尊重し、別deploymentやcapacity tierへのspillover、またはqueueへ移します。interactive workloadとbatch workloadでは許容待ち時間が異なるため、同じretry policyを共有しない設計が必要です。Microsoft Azureのthrottling guidanceもinteractiveでは限定retry後のdegraded response、batchではfailed chunkのdurable enqueueを例示しています。
F3: region / provider failure
事前に用意したsecondaryへ切り替えます。ただしregion、data residency、private network、quota、model availability、credentialを事前検証します。Microsoft FoundryのHA guidanceはGlobal/Data Zone routingをapplication-level regional failoverの代替として扱わず、secondary deploymentへのroutingをapplication/gateway側で設計するよう示しています。
F4: model / capability fallback
別model/providerへ切り替える場合、tool schema、structured output、context length、safety policy、latency、cost、model-specific behaviorが同値とは限りません。「応答が返った」ことをsemantic equivalenceの証拠にしません。重要なworkflowでは代替先ごとに受入試験を行います。
F5: capability degradation
retrieval、tool、memoryなど非必須機能を停止し、限定機能で継続します。縮退状態はdownstreamと利用者へ明示し、通常応答と混同させません。AWS AGENTREL04-BP03もordered fallback alternatives、quality trade-off、health check、degradation notificationを要求しています。
F6: durable deferral / human escalation
副作用を伴う処理、再実行安全性が不明な処理、critical decisionはqueue/checkpointまたはhuman reviewへ退避します。timeoutや通信断だけで「処理されなかった」と判断して再実行すると、二重実行を起こす可能性があります。
データ所在を壊さない
Google Vertex AI / Gemini Enterpriseの資料は429/503等へのexponential backoffを案内し、global endpointがregional capacity issueを減らし得ることを示しています。一方、global endpointではprocessing locationを固定できない場合があります。data residency要件がある環境では、可用性向上だけを理由にglobal endpointを無条件fallbackにしてはいけません。契約・provider・機能ごとの処理地域条件を確認します。
副作用を伴うtool/agent
fallback chainはexactly-onceを自動的には保証しません。tool callが外部systemへ届いた後にresponseだけ失われた場合、別model/providerへ再実行すると同じ副作用を重複させる可能性があります。各edgeにidempotency key、operation identity、provider/target readback、reconciliationの要否を持たせ、結果不明時は再送より先に外部状態を確認します。
受入試験
各fallback edgeについて、trigger condition、retryability、maximum attempts/time budget、target、data residency、credential/permission、idempotency/side-effect contract、quality delta、observability、return-to-primary条件を固定します。429、5xx、timeout、authz denial、region loss、tool failureを別々に注入し、意図した段だけが作動すること、fallback loopが起きないこと、縮退状態が観測できること、復帰後に重複side effectが発生しないことをreadbackします。
運用で残す記録
障害class、選択したfallback edge、attempt count、retry budget、primary/secondary identity、model/deployment/version、region、residency判定、degraded flag、operation identity、外部副作用のreadback、primary復帰条件を記録します。fallback成功率だけでなく、品質差、重複実行、誤った権限迂回、residency違反を別metricとして監視します。
適用境界
Provider文書が保証するのは各サービスのrouting、retry、spillover等の機構と制約です。組織固有のfallback順序、異種model間の意味的同値性、tool workflowのexactly-onceまでは保証しません。fallback chainは対象use caseのSLO、risk、residency、cost、tool side effectに対して個別に検証します。
未確認事項
- 異種provider/model間のsemantic equivalenceを一般化できる一次根拠は確認できません。
- global endpoint利用時のprocessing location要件はprovider、契約、機能ごとの確認が必要です。
- agent/tool workflowのside effect exactly-onceはfallback機構だけでは保証されません。
参考資料
- AWS Well-Architected Agentic AI Lens, AGENTREL07-BP02
- AWS Well-Architected Agentic AI Lens, AGENTREL04-BP03
- Microsoft Foundry, High availability and resiliency
- Microsoft Azure Well-Architected Framework, Throttling
- Google Cloud, Reduce 429 errors on Vertex AI
- Google Gemini Enterprise Agent Platform, Retry strategy
EA-440-CURRENT-APPROVAL研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKET現行本文の監査・revision対応
- 裏付ける内容
- 現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。
- 確認日
- —
- 出典・実験ID
- EA440-CANDIDATE-20261025-ORPHAN-RESCUE-C2
- 検証箇所
- 1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ/EA_REVISION_LEDGER#ea_id=EA-440&revision_id=EA-440-RESEARCH-20261022-R1&candidate_id=EA440-CANDIDATE-20261025-ORPHAN-RESCUE-C2 · EA-440-RESEARCH-20261022-R1
- 適用範囲
- —
- 出典・来歴
- CURRENT_CANONICAL_APPROVAL_READBACK
- 限界
- 監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。
EA-440-CURRENT-BODY-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACK現行本文の収録照合
- 裏付ける内容
- 公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。
- 確認日
- 2026-10-25
- 出典・実験ID
- BODY-SHA256:bd5e3e7d2d71e93934cc93f2f769d0f7b3600ec9c97629c5011e27c9de95d946
- 検証箇所
- content/staging/EA-440.md · bd5e3e7d2d71e93934cc93f2f769d0f7b3600ec9c97629c5011e27c9de95d946 · EA-440-RESEARCH-20261022-R1
- 適用範囲
- —
- 出典・来歴
- CURRENT_APPROVED_BODY_HASH_MATCH
- 限界
- 本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。
- 出典ID
- EA440-CANDIDATE-20261025-ORPHAN-RESCUE-C2, BODY-SHA256:bd5e3e7d2d71e93934cc93f2f769d0f7b3600ec9c97629c5011e27c9de95d946
- 追跡中のUNKNOWN ID
- EA-440-UNKNOWN-01
- 再確認のきっかけ
- 正式な 改訂版/publication 状態 change · 本文 成果物 hash change · 出典 現行性 change · new contradiction or 実装 結果の照合
機械検査: 通過 — 機械検査の結果です。情報の正確性や実行の承認を保証するものではありません。
同じ記事IDの機械可読データです。