# 障害時フォールバック階層 CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-440 CLAIM_IDS: none EVIDENCE_IDS: EA-440-CURRENT-APPROVAL, EA-440-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-440-UNKNOWN-01 OPS_IDS: none ## Summary Enterprise AIのフォールバックは「失敗したら別モデルへ送る」だけでは成立しません。障害の種類を判定し、再試行、別capacity/deployment、別region、別provider/model、機能縮退、durable queueまたは人手移管を、品質・データ所在・権限・副作用の制約付きで順序化します。 ## Current judgment Enterprise AIのフォールバックは「失敗したら別モデルへ送る」だけでは成立しません。障害の種類を判定し、再試行、別capacity/deployment、別region、別provider/model、機能縮退、durable queueまたは人手移管を、品質・データ所在・権限・副作用の制約付きで順序化します。 ## Scope 障害時フォールバック階層 ## Confirmed ## UNKNOWN - EA-440-UNKNOWN-01: - 異種provider/model間のsemantic equivalenceを一般化できる一次根拠は確認できません。 - global endpoint利用時のprocessing location要件はprovider、契約、機能ごとの確認が必要です。 - agent/tool workflowのside effect exactly-onceはfallback機構だけでは保証されません。 ## Evidence - EA-440-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-440-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits 認証・認可・入力検証の失敗は、同じ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を分離しています。 ## 要点と前提 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 NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.