Azure OpenAI Service（マイクロソフトのクラウド上でOpenAI系モデルを推論APIとして提供するPaaS層のAIサービス）で、2026年5月29日、欧州のスウェーデン中部と豪州東部を中心に約7時間45分にわたる障害が発生した。原因は外部攻撃でも単純な実装バグでもなく、マイクロソフト社内のリトライ設計にあった。容量不足を伝えるエラーの表現方法が変更されたことをきっかけに、顧客ではなく社内の別ワークロードからのリトライが急増し、複数リージョンの推論トラフィックをさばく共有ロードバランサ（負荷分散装置）を圧迫した。IT×経営の読者にとって、この事故は他人事ではない。自社サービスがAzure OpenAIをはじめとする外部APIに依存する設計を採る限り、同種のリトライ増幅は自社の運用でも起こり得る。本稿は当日の経緯を整理し、クライアント側リトライ設計と単一障害点排除という運用アーキテクチャ判断の論点を示す。
予備知識
- リトライストーム（サンダリングハード）: 一時的なエラーに対して多数のクライアントが同時に再試行し、かえって負荷が急増する現象
- 指数バックオフとジッター: 再試行の間隔を回を重ねるごとに延ばし、さらにランダムなずれ（ジッター）を加えて再試行が同時刻に集中するのを防ぐ手法
- サーキットブレーカー: 一定回数エラーが続いたら呼び出しを一時的に止め、下流システムを保護する仕組み
- 単一障害点（SPOF）: そこが止まると関連する全体が止まってしまう、冗長化されていない箇所
自社のAPI呼び出しにリトライを実装する際、単純な再試行ループは今回のような増幅事故を招きやすい。
2026年5月29日に何が起きたか
Azure OpenAI Serviceの利用者は5月29日09:39〜17:05（UTC）の間、推論リクエストのレイテンシ上昇、断続的な失敗、タイムアウト、HTTP 5xxエラーを経験した[1]。影響が最も大きかったのは、対象トラフィックを直接処理していた欧州（スウェーデン中部）と豪州東部だった[1]。
最初の顧客影響は09:20（UTC）に始まり、豪州東部での上流ロールアウトに伴うリトライ増幅が複数リージョンで失敗率とレイテンシを押し上げた[1]。
| 時刻（UTC） | 日本時間 | できごと |
|---|---|---|
| 09:20 | 18:20 | 豪州東で上流ロールアウトに伴う影響が開始 |
| 09:39 | 18:39 | 顧客がレイテンシ上昇・タイムアウト・5xxエラーを検知 |
| 14:20 | 23:20 | 上流ロールアウトがスウェーデン中部に拡大、影響が増幅 |
| 17:05 | 翌2:05 | 原因ワークロードを分離し障害が収束 |
障害発生時の検知・診断・収束までの一連の動きを組織としてどう回すかは、個別の技術対策だけでは決まらない。
リトライ増幅（サンダリングハード）のメカニズム
今回の引き金は、容量不足を示すエラーの表現方法を変えた上流依存サービスの変更だった[1]。この変更により、マイクロソフト社内の第一者ワークロード（顧客ではなく自社サービス）が想定外の頻度でリトライを発生させた[1]。
マイクロソフトの調査チームは当初、別の症状に対処してしまい根本原因を見誤った[1]。スウェーデン中部への拡大でより大きな規模の障害が再現したことで、劣化の原因がリトライ増幅であると確定的に相関づけられ、引き金が上流API層の変更であると正しく診断できた[1]。
クラウド費用の急増に気づいてから原因を突き止めるまで、FinOpsやインフラの担当者はコストエクスプローラーの画面とCloudTrailのログを手作業で突き合わせてきた。AWSは2026年6月9日、この調査作業を生成AIエージェントに任せ[…]
共有ロードバランサという単一障害点
障害を長引かせた本質は、推論トラフィックを複数リージョンで束ねる共有ロードバランサが、単一障害点として機能してしまった点にある。特定ワークロードのリトライ急増が、無関係な顧客トラフィックまで巻き込んで劣化させた。
障害は豪州東単独の段階（09:20〜14:20、約5時間）から、スウェーデン中部を巻き込んだ段階（14:20〜17:05、約2時間45分）へと拡大し、後者でより高いトラフィック量がリトライ増幅の影響をさらに大きくした[1]。
マイクロソフトは原因となった内部ワークロードを特定した後、そのワークロードを専用インフラへ分離し、上流サービスと連携して引き金となった変更をロールバックしてトラフィック量を下げることで収束させた[1]。
2026年6月22日、CDN大手Cloudflareのネットワークが劣化し、X、Reddit、Microsoft Teams、Zoomなど数多くのサービスで遅延やタイムアウトが発生した[1][2]。原因は設定変更のミスではなく、北米東部で[…]
運用アーキテクチャへの教訓
自社システムが外部APIを呼び出す場合、クライアント側のリトライ設計そのものが障害の増幅装置になり得る。単純な固定間隔リトライは避け、指数バックオフとジッターを組み合わせるのが最低限の対策になる。
| 方式 | 挙動 | リトライストームへの耐性 | 実装コスト |
|---|---|---|---|
| 単純リトライ（固定間隔） | 失敗直後に同じ間隔で再試行 | 低い（再試行が重なりやすい） | 低い |
| 指数バックオフ | 再試行のたびに間隔を倍々に延長 | 中程度（なお同期しやすい） | 低い |
| 指数バックオフ+ジッター | 間隔にランダムな揺らぎを加える | 高い（再試行が時間的に分散） | 中程度 |
| サーキットブレーカー併用 | 連続失敗で呼び出しを一時遮断 | 高い（下流への流入自体を絞る） | 中〜高 |
マイクロソフトは再発防止として、単一の内部ワークロードからの過剰なリトライが共有コンポーネントを圧迫できないよう、過負荷防止とワークロード単位のスロットリング制御の強化を進めており、完了目標は2026年7月とされている[1]。推論ルーティング層の単一障害点排除も継続課題として挙げられている[1]。
MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]
よくある質問（FAQ）
Q1. Azure OpenAI Serviceとは何か。ChatGPTと同じものか。
Azure OpenAI Serviceは、マイクロソフトのクラウド基盤上でOpenAI系モデルを推論APIとして提供するPaaS層のサービスであり、OpenAI社が単独運用するChatGPTとは提供主体もインフラも異なる[1]。
Q2. なぜクライアント側のリトライが障害を悪化させるのか。
一時的なエラーに対して多数のクライアントが同時に再試行すると、正常時より多いリクエストが短時間に集中し、指数バックオフやジッターを備えない実装では負荷がかえって増幅するためである[1]。
Q3. 今回の障害の直接の引き金は何だったのか。
容量不足に関するエラーの表現方法を変更した上流の変更が引き金となり、マイクロソフト社内の別ワークロードのリトライ挙動を想定外に増加させたことが直接の原因である[1]。
まとめ
今回の障害は、外部からの攻撃でも単純なバグでもなく、社内ワークロードのリトライ設計が招いた自己増幅型の事故だった。容量エラーの表現を変えるという一見軽微な変更が、共有ロードバランサという単一障害点を経由して欧州・豪州の広範囲に波及した。自社のシステムがAzure OpenAIをはじめとする外部APIに依存している場合、まず自社側のリトライに指数バックオフとジッター、サーキットブレーカーを組み込んでいるかを点検したい。次に、依存先の共有コンポーネントがどこにあるかを把握し、専用容量や別リージョンへのフォールバックを予算化するかどうかを判断する材料としたい。
[1] Azure Status History, “Azure OpenAI Service” incident report for 2026-05-29 (09:39-17:05 UTC), https://azure.status.microsoft/en-us/status/history/
