ChatGPTを手がけるOpenAIは、サービス開始以来もっとも波乱に満ちた時期のひとつを経験したばかりです。2026年7月だけでも障害が繰り返し発生し、それは大規模な世界的障害でピークに達し、その後には丸一日近くに及ぶインシデントが続きました。この記事では、OpenAIの公式ステータスページで公表された日付と時刻に基づいて何が起きたのかを正確に記録し、AIを基盤に構築しているあらゆる企業にとって、それが実際に何を意味するのかを解説します。

執筆時点のリアルタイムのステータス

このレポートを準備していた2026年7月25日（土）リヤド時間12:20の時点で、OpenAIの公式ステータスページには、「Elevated error rates」（エラー率の上昇）と題された、調査中のアクティブなインシデントが表示されていました。これはリヤド時間12:17（09:17 UTC）に正式に始まり、ChatGPT、OpenAIのAPI、そしてコーディングツールのCodexという三つのサービスに同時に影響を与えました。同社は影響を「軽微」と評価し、プラットフォーム全体の状態を「Partial System Degradation」（システムの部分的な低下）と説明していました。言い換えれば、これは世界規模の完全なブラックアウトではなく、一部のユーザーにとって断続的な遅延とリクエストの失敗が起きている状態でした。

波乱の二週間のタイムライン

今日のインシデントは単発の出来事ではなく、7月を通じて続いた長い連鎖のひとつにすぎません。

  • 7月9日：複数のモデルで同時に「Please try a different model」（別のモデルをお試しください）というエラーが発生。
  • 7月11日〜15日：報道によれば、五日連続で五件のインシデントが発生し、最後には目立った障害が起き、その後ChatGPTは復旧しました。
  • 7月19日：250件を超える報告が寄せられた大規模な世界的障害。ウクライナ、米国、欧州、インド、日本のユーザーに影響し、502および503エラーとともにiOSに集中しました。
  • 7月21日：約23分間続いた短い障害。
  • 7月23日〜24日：もっとも深刻なインシデント。23日のリヤド時間18:36に始まり、不安定な状態が続いた末、24日の22:33になってようやく完全復旧が宣言されました。
  • 7月25日：現在アクティブなインシデント。影響は軽微で、調査中です。

根本原因は何だったのか

7月23日〜24日のインシデントに関するOpenAIの公式アップデートで注目すべき点は、「下流のインフラプロバイダーと共に」修正に取り組んでいると明言していたことです。これは、問題の根源がAIモデルそのものではなく、OpenAIが依存しているホスティングおよびクラウドネットワークの層にあった可能性が高いことを意味します。また、その週のインシデントの多くが完全な停止ではなく、エラー率の上昇や502/503エラーだった理由もこれで説明がつきます。サービスは稼働していたものの、リクエストの一部が失敗したり遅延したりしていたのです。

ChatGPTを一度も開かなくても、なぜこれが重要なのか

なぜなら、障害はChatGPTのウェブサイトだけでなく、OpenAIのAPIにも及んだからです。何千ものアプリ、ストア、カスタマーサービスシステムが、エンドユーザーからは見えないところでOpenAIのモデルをバックグラウンドで呼び出しています。APIのエラーが急増すると、それらのシステムはすべて同じ瞬間につまずきます。代替手段を持たずに単一のプロバイダー上に構築している人は、そのプロバイダーの障害を自分自身の障害にしてしまうのです。

教訓：障害を前提に設計する

大手プロバイダーもダウンします。それは例外ではなく、ルールです。脆弱なシステムとレジリエントなシステムの違いは、その瞬間にどう振る舞うかにあります。

  • マルチプロバイダー：メインのプロバイダーが故障したときに自動的に切り替えられる、バックアップのモデルプロバイダーをシステムに用意しましょう。
  • スマートなリトライ：リクエストが失敗したら、苦戦しているサービスにさらにトラフィックを浴びせるのではなく、指数バックオフでリトライしましょう。
  • リクエストキュー：緊急でないリクエストは失うのではなく保存しておき、サービスが戻ったときに実行しましょう。
  • 監視とアラート：エラー率とレイテンシを監視し、顧客から苦情が来たときではなく、それらが通常の範囲を超えた瞬間にアラートを受け取れるようにしましょう。

Origamiの役割

テクノロジー企業として、私たちはあなたのビジネスをAIモデルにつなぐだけではありません。プロバイダーはいつか必ず障害を起こすという前提で統合を設計します。プロバイダー間の自動フェイルオーバー層、規律あるリトライ、そして顧客より先に障害を検知する監視ダッシュボードです。こうして、他社が停止している間もあなたのシステムは動き続けるのです。

出典