3社共通の原因は未確認、複数の障害が重なった可能性
米国版記事公開日の9月5日時点では、ChatGPT、Claude、Grokで起きた障害すべてを説明できる共通原因は確認されていない。複数の障害が同じ時間帯に発生したため、当初は共通するクラウド基盤が原因ではないかとの見方も出た。
マイクロソフトのAzureの米国東部（East US）リージョンの障害を指摘する声も複数あった。同じ時間帯にAzure自身の障害報告も急増していたからだ。ただCircleIDによれば、マイクロソフトはAzureが原因ではないとしている。
その後、SpaceXAIは米国時間9月3日の午後に謝罪を投稿した。Grokの問題はメンフィスにある同社の計算施設（コンピュートセンター）の障害を受けて起きたと説明した上で、「影響を受けたコンピュートパートナー」にも謝罪した。この言い回しは、SpaceXAIが他のAI研究所と計算能力を共有しており、メンフィスが落ちたときに少なくとも1社が道連れになったことを示唆している。GrokとClaudeが同時に落ちたことの説明にはなる。だが、自社の問題をルーティングの誤りだと説明したOpenAIについては説明がつかない。
最もありそうな結論、そして私が考え直すたびに行き着くのは、これらは別々の事故がたまたま重なったもので、その一部に共有された計算資源が絡んでいた、というものだ。米国時間9月4日の朝の時点で、質問にきちんと答えていたのはOpenAIだけだった。
AIブレイン（企業の知識と業務を一元的に扱うAIの中枢）やAIエージェントへの流れが続くなかで、AIインフラの重要性はますます高まっている。
オンプレミス側から見たAI障害
クラウド事業者や外部AIサービスへの依存を減らす方法の1つが、AIを自社設備で動かすオンプレミス型の運用だ。シカゴに本拠を置くGo.AI（旧称Go Abacus）は、規制産業の約200社の企業顧客向けに、オンプレミス型のAIを構築している。CEOのデービッド・モスカテッリは今週私が話を聞いた際に、こう言い切った。「AIは生産性向上ツールから重要インフラへと、驚くほどの速さで移行しました。今や稼働率と制御は、電気と同じくらい重要です」。
自社ハードウェアでAIを動かし、外部サービスへの依存を減らす
Go.AIの顧客は、AIの運用を自社で管理したい大企業で、ファーマーズ・インシュアランス、D.L.エバンス銀行、アクソス銀行、ジョンズ・ホプキンスなどが名を連ねる。
これらの顧客は、自社所有のハードウェア上でGoLLMやオープンウェイトのモデルを動かしている。料金は月額固定で、トークン（AIが処理する文字の単位）ごとの課金はない。だから、よその会社の朝のトラブルが自分たちのトラブルになることはない。
モスカテッリは、クラウドを捨てろと企業に言っているわけではない。だが、アーキテクチャ（システムの構成）には重きを置いている。Go.AIのGo1は最大2000ユーザー向けにAIを稼働させる装置で、クラウドも共有インフラも使わず、クエリ（問い合わせ）もトークンも無制限で料金は固定、設置はイーサネットか光ファイバーにつないで15分ほどで済む。
1モデル・1クラウドに依存せず、必要に応じて切り替える
「企業向けAIの未来は、すべてを1つのモデル、1つのクラウド事業者で動かすことにはなりません」と彼は私に語った。「自社のデータと業務に対する管理権を保ちながら、適切なモデルを適切な環境で動かせる柔軟性を組織に与える。そういう方向に進むでしょう」。
彼の考えでは、企業はどの事業者も単独では落ちうるものと想定し、それを前提に設計すべきだという。備えるべきは、モデルを選べる柔軟性、インフラを選べる柔軟性、そして「明かりが消えたとき、計算資源を握っているのは誰か」という問いへの明確な答えの3つだ。
