何が起きたか
木曜午前、主要4社のクラウドAIサービスで障害が重なりました。時系列は次の通りです（すべて米東部時間）。
- 9時23分 Anthropicが「部分障害（partial outage）」を公表。Claude Mythos 5.1、Claude Fable 5.1、Claude Opus 5へのリクエストでエラー増加。約15分後に原因を特定し、修正を適用、12時16分に解消。
- 正午過ぎ Anthropicは別インシデントとして、Claude Sonnet 5へのリクエストで短時間のエラー増加を報告。
- 10時43分 OpenAIがChatGPTとCodexでエラー増加による「パフォーマンス低下」を報告。30分強で緩和策を投入し、12時55分に解消。
- xAIのGrokは本稿執筆時点で「モデルに問題が発生している」旨のエラーメッセージを表示し、復旧作業中と告知。
- DownDetectorに寄せられたGrokの報告件数は、9時直前の10件未満から9時45分に1,365件へ急増し、執筆時点では273件まで減少。
Googleを含む4社が同時間帯に影響を受けた点が、この出来事の特異性です。
なぜ重要か
業務システムの障害は珍しくありません。異例なのは、競合関係にある独立した4社が、同じ数時間の窓に重なって不調を起こしたことです。多くの企業が採用している「マルチベンダー化すればAIの可用性は担保できる」という前提に、実測データとして疑問符が付きました。
事実として公表されているのは各社の症状と復旧時刻のみで、共通原因があったかどうかは示されていません。ただし事業側の意思決定にとって重要なのは原因究明ではなく、「同時に落ちうる」という事象がすでに一度観測されたという一点です。リスク評価の前提を、推測ではなく観測値として更新する必要があります。
見落とされがちな論点
第一に、障害の形が「停止」ではなく「劣化」だった点です。OpenAIの表現は「エラー増加によるパフォーマンス低下」、Anthropicは「部分障害」。全面停止であればフェイルオーバーが働きますが、エラー率が上がるだけの状態は監視をすり抜けやすく、リトライが積み上がってコストと遅延だけが膨らむ典型的なパターンに陥ります。
第二に、開発生産性への波及です。OpenAIの障害はChatGPTだけでなくCodexにも及びました。AIコーディング支援を前提に開発フローを組んでいる組織では、プロダクト障害ではなく「その日の開発チーム全体の生産性低下」という形で損失が出ます。これは可用性SLAの計算式に載っていないコストです。
第三に、復旧の速さです。Anthropicは覚知から約15分で原因を特定し、約3時間で解消。OpenAIも報告から2時間強で解消しています。数時間で戻る障害に、高コストな冗長化をどこまで積むかは経営判断の問題です。
💼 事業会社視点：これは自社にどう効くか
AI機能を組み込んだSaaS・ECの事業責任者にとって、今回の実務的な示唆は「マルチベンダー冗長化への投資判断」です。複数モデルへのフェイルオーバー実装は決して安くありませんが、今回のように4社が同じ午前中に重なると、その投資の期待効果は想定より小さいことになります。むしろ費用対効果が高いのは、AI応答が返らない／劣化したときのUX設計です。ECのレコメンドや商品説明生成なら静的なフォールバックに落とす、SaaSの要約機能なら「現在混雑中」と明示して再試行を促す。数時間の劣化を「サービス障害」にせず「機能の一時休止」に留められるかは、モデル選定ではなくアプリ側の設計で決まります。
受託開発・SIerは、AI機能を含む案件のSLAと契約条項を今すぐ見直すべきです。Anthropicは9時23分の覚知から12時16分の解消まで約3時間、OpenAIは10時43分から12時55分。この実測値を根拠に、上流のモデルAPI障害を免責範囲として明記できているかが問われます。曖昧なまま納品すると、自社の責任でない数時間が瑕疵扱いになりかねません。
日本企業の経営層への論点は、社内のAI利用実態の可視化です。Codexが止まれば開発が止まる程度に業務が依存しているなら、それは情シスの案件ではなく事業継続計画（BCP）の対象です。「どの業務が、どのモデルが何時間止まると、いくら損をするか」を一度棚卸しし、DownDetectorの1,365件のような外部指標を含めた検知経路を用意しておくことを勧めます。
