提供元障害シグナルをAIルーティングへ安全に使う

複数のAI providerを使う運用では、公開status pageだけを見て自動fallbackを決めると判断を誤りやすい。公開statusはprovider全体または広い利用者層の障害を示す重要な外部シグナルだが、個別tenant・project・region・model・API featureの実影響と一致するとは限らない。たとえばOpenAI Status自身が、availability metricsはtier/model/error typeを横断したaggregateであり、個別顧客のavailabilityはsubscription tierや利用model/API featureによって異なり得ると明記している。したがって、ルーティング判断では「provider公開status」「tenant/projectに紐づくhealth signal」「自分の実トラフィックまたはsynthetic probe」を別の証拠として保持し、最後に統合する。

第一層はprovider公開statusである。これは広域障害や既知incidentの検知に有効だが、自組織だけの障害を否定する証拠にはならない。OpenAIの過去incidentではAPI/ChatGPT全体のerror rate上昇が公開されている一方、status pageは個別顧客のavailabilityが異なり得ることも明記している。公開statusがgreenでも、自組織の認証、quota、region、network、特定model endpointだけが失敗する可能性は残る。

第二層はtenant/project-specific healthである。Google Cloud Personalized Service Healthは、projectまたはorganizationに関連するdisruptive eventをService Health APIで取得でき、organization-levelでは影響を受ける可能性のあるprojectも照合できる。これは公開statusより自組織へのrelevanceを高めるが、API有効化やIAM、project coverageなどの条件がある。organization viewに含めたいprojectごとにService Health APIを有効化する必要があり、権限も必要である。

第三層は自前観測である。実リクエストのerror rate、latency、timeout、rate-limit、authentication failure、model-specific failureなどを計測し、必要に応じて安全なsynthetic probeを追加する。synthetic probeは「providerが生きているか」を単一のpingで判定するのではなく、本番で必要な最小request pathに近いものを使う。ただしprobe自体のquota消費、課金、region差、認証失効、network経路差を考慮し、probe失敗を即provider障害へ一般化しない。

実装では各signalを同じbooleanへ潰さず、少なくとも source、scope、observed_at、event/update time、affected product/model/region/project、severity/state、confidence、TTL を保持する。公開statusのincident、tenant health event、synthetic/real-traffic telemetryが同じscopeを指す場合はconfidenceを上げられる。一方、公開statusだけが赤で自分のtrafficが正常なら、直ちに全trafficを退避するのではなく、対象componentとのscope一致を確認する。逆に公開statusが正常でも、自分のerror rateとtenant healthが同方向なら局所障害としてfallbackを検討する。

ルータは「正常/障害」の二値ではなく、NORMAL、DEGRADED、SUSPECTED_OUTAGE、CONFIRMED_OUTAGE、RECOVERINGのような内部状態を持つ方が安全である。ただしこれはproviderの公式stateを置き換えるものではなく、自組織のrouting decision stateである。状態遷移には複数回観測、時間窓、minimum sample、error classを使い、一時的なspikeで全trafficを切り替えない。

障害検知後のfallbackだけでなく、復旧後のfailbackを制御する。provider statusがResolvedになった瞬間に100%を戻すと、部分復旧、region差、cache warm-up、rate-limit、backlogなどで再障害を起こし得る。Google Cloud Personalized Service Healthはmulti-product/multi-location incidentでproduct/locationごとのAffected/Resolvedとrecovery timestampを扱えるため、全体incidentがactiveでも部分復旧を区別できる。この種の粒度をroutingへ反映し、復旧確認→少量traffic→段階的増加→通常化というhysteresisを設ける。

fallback先にもcapacity、quota、model capability、data residency、security/privacy、cost、latency、tool compatibilityの制約がある。primary障害時にsecondaryへ全量を送る設計は、secondary側のrate-limitや契約上限を超える可能性がある。routing policyには最大退避率、優先workload、shed対象、manual override、rollback条件を持たせる。

運用上は、(1) provider status ingestion、(2) tenant/project health ingestion、(3) application telemetry/synthetic probe、(4) signal normalization、(5) decision engine、(6) traffic router、(7) operator override/audit logを分離する。health signal取得不能そのものもUNKNOWNとして扱い、「取得できない=正常」にしない。

最低限の監査記録には、routing変更前後のprovider、対象workload、根拠signal、scope、decision timestamp、policy version、override有無、fallback率、failback開始/終了、観測結果を残す。これにより、status pageの誤読、probe誤検知、tenant signal遅延、policy bugのどれがrouting変更を引き起こしたか追跡できる。

公開statusは重要だが顧客固有の完全なground truthではない。tenant-specific healthも、providerが認識・分類したeventに依存し、検知遅延やcoverage差があり得る。synthetic probeは自分のpathに近い一方、sampleが少ない、実trafficとcredential/network/regionが異なる、probe自身がquotaやrate-limitの影響を受ける、といった偏りがある。三者が不一致になることを前提に設計し、単一sourceの自動強制切替を避ける。

AWS Healthもpublic service healthとorganization/account-specific healthを区別しており、organizational viewではaffected accounts/resourcesを確認できる。一方、AWS Health APIにはsupport plan条件がある。これは「tenant-specific health APIが常に無条件で使える」という一般化への反証であり、providerごとにavailability、IAM、plan、retentionを確認する必要がある。

この設計はprovider/model/API endpointのavailabilityに応じてAI trafficを切り替える運用を対象とする。回答品質低下、model behavior drift、安全性評価失敗、prompt regressionなどはavailability障害とは別のrouting signalとして扱う。status fusionだけで品質routingまで代替しない。また、provider間でmodel semantics、tool calling、context window、data handling条件が異なる場合、単純なendpoint置換はできない。

OpenAIの個別tenant向けhealth signal/APIの一般提供範囲は、このcandidateでは確証を置かない。providerごとのstatus更新遅延や検知SLOも一律値として断定しない。synthetic probeの最適interval/thresholdはworkload、quota、cost、error budgetに依存するため固定値を置かない。

「公開statusを自動fallbackの唯一の根拠にする」のではなく、「公開status、利用組織に関連するhealth signal、自前telemetry/probeをscope付きで統合し、hysteresisと段階的failbackを伴うrouting policyへ入力する」と表現する。provider statusが正常であることは個別tenantの正常性を保証しない。

• OpenAI Status, Elevated error rates (2026-07-25): https://status.openai.com/incidents/x9p6qd31 — aggregate availabilityとindividual customer availability差の明記、およびincident state/updateの一次例。
• OpenAI Status, API & ChatGPT Performance Degradation: https://status.openai.com/incidents/01JMYB4A62XNXSAHAY8ZGQAAKD — API error/latency incidentとfallback/recoveryの一次例。
• Google Cloud, Personalized Service Health overview: https://docs.cloud.google.com/service-health/docs/overview — project/organization relevant event、API、product/location granular recovery。
• Google Cloud, Access organization events with the Personalized Service Health API: https://docs.cloud.google.com/service-health/docs/organization-events — OrganizationEvents/OrganizationImpacts、API enablement/IAM条件。
• Google Cloud, Manage Personalized Service Health access: https://docs.cloud.google.com/service-health/docs/manage-access — roles/servicehealth.viewerとAPI access条件。
• AWS Health, Viewing organizational view: https://docs.aws.amazon.com/health/latest/ug/view-organizational-view-events.html — public healthとorganization/account-specific eventの区別、affected accounts/resources。
• AWS Health, Concepts for AWS Health: https://docs.aws.amazon.com/health/latest/ug/aws-health-concepts-and-terms.html — AWS Health APIのsupport-plan条件。

Audit handoff note: 本文はEA-733 canonical topic「Provider outage status fusion for AI routing」を維持し、公開status・tenant/project health・synthetic/real telemetryの分離と統合、routing/fallback/failback、limitations、適用境界、OPEN_UNKNOWN、SAFE_WORDINGを含む。READY/AUDIT_PASS/GIT_INTEGRATED/ACCEPTEDは未判定。