OpenAI、Codexの障害発生と復旧を発表

Codexで障害発生、現在は復旧済み——OpenAIが公式Xで発表した内容

室谷代表取締役

OpenAIが、AIコーディングツール「Codex」で障害が発生したことを公式Xで発表しました。すでに復旧済みであることも同じ投稿で伝えられています。

まず、発表された内容をそのまま紹介しますね。OpenAIの開発者向けアカウントの投稿は「We experienced an outage on Codex today. The issue is now resolved and Codex is back up. Sorry for the disruption, and thanks for your patience.」というものです。

日本語にすると「本日、Codexで障害が発生しました。問題は解決し、Codexは復旧しました。

ご迷惑をおかけして申し訳ありません。お待ちいただきありがとうございました」という趣旨になります。

テキトー教師DotAI 認定講師

ものすごく短い告知なんですよ。でも、この短さが逆に大事なポイントで。

「起きたこと」「今どうなっているか」「謝罪」の3点だけに絞っている。障害対応の一次報としては、かなり教科書的な形なんですよね。

室谷代表取締役

そうなんですよね。ただ、開発者としては「いつから」「どれくらい」「何が使えなかったのか」が気になるところで。

そこは今回の投稿には書かれていないんです。

テキトー教師DotAI 認定講師

はい。だからこそ、この記事では「書かれている事実」と「書かれていないこと」を分けて整理しておきます。

講座でも、速報を読むときは必ずこの切り分けをするように伝えているんですよ。

何が起きたのか——障害発生から復旧までの経緯と影響範囲

室谷代表取締役

経緯として確実に言えるのは、ある時点でCodexに障害が発生し、その後OpenAIが問題を解決して復旧させた、という流れです。順序としては「障害発生」→「対応」→「復旧」で、発表の時点ですでに「Codex is back up」と明言されています。

テキトー教師DotAI 認定講師

ここで気をつけたいのは、公表されていない情報を想像で埋めないことなんですよ。たとえば障害の発生時刻、継続時間、原因、影響を受けたユーザー数、どの機能が使えなくなっていたのか。

これらは現時点では明らかにされていません。OpenAIの投稿にはそこまで書かれていないんです。

室谷代表取締役

じゃあ、その「書かれていない部分」はどこで確認すればいいんでしょう。

テキトー教師DotAI 認定講師

それが公式のステータスページなんですよ。OpenAIは status.openai.com で各サービスの稼働状況を公開していて、Codexは4つのコンポーネントで構成され、集計ベースの稼働率は99.95%と表示されています。

ただし、この数値は全プラン・全モデル・全エラー種別をまとめた集計値なので、個々の契約プランや利用中の機能によって体感は変わりうる、と注記されています。

室谷代表取締役

つまり「全体としてはほぼ動いている」という数字であって、自分の環境が必ず同じとは限らない、と。障害のときは、この公式ページと公式Xの両方を見るのが基本ですね。

室谷代表取締役

MYUUUでも開発チームが日常的にコーディング支援ツールを使っているので、こういう告知が出ると「どの作業が止まるか」が真っ先に気になります。ただ、今回の告知だけでは影響範囲は特定できない。

だからこそ「自チームでは今どのタスクがこのツールに依存しているか」を自分たちで確認するしかないんですよね。

テキトー教師DotAI 認定講師

影響範囲を整理する視点としては、大きく3つに分けられます。ひとつは「Codexに投げていた作業」、ふたつめは「Codexの結果を待ってから進める予定だった作業」、みっつめは「Codexと関係なく進められる作業」。

障害中はこの3つめに逃げるのが定石です。単にツールが止まったという話じゃなくて、タスクの依存関係を日頃から把握できているかどうかが問われる出来事なんですよ。

室谷代表取締役

依存関係の見える化、大事ですよね。復旧したとはいえ、止まっていた間に失敗した処理が残っていないか、という確認も必要になりますし。

テキトー教師DotAI 認定講師

そこは講座でもよく言っています。復旧直後は慎重に、と。

障害中に途中で止まったタスクや、意図した結果が出なかったタスクを一度洗い出してから、通常のペースに戻すのが安全です。

Codexとは何か——どんな開発者が使っているツールなのか

室谷代表取締役

ここで改めて、Codexが何なのかを整理しておきたいんですよね。CodexはOpenAIが提供するAIコーディングエージェントで、開発者がコードの生成や修正、リファクタリングといった作業を任せられるツールです。

チャットで指示を出すだけでなく、エディタや開発ワークフローに組み込んで使う形が広がっています。

テキトー教師DotAI 認定講師

使っているのは、いわゆるプロのソフトウェアエンジニアだけではないんですよ。個人開発者、スタートアップの少人数チーム、業務システムを内製している企業の開発部門など、幅広い層が「実装の初速」を出すために使っています。

だからこそ、止まったときの影響が「個人の作業が少し遅れる」で済む人もいれば、「チームのリリース計画に響く」人もいる。

室谷代表取締役

そこは本当にそうで、MYUUUでも「まずCodexに叩き台を作らせて、人間がレビューする」という流れが普通になっています。なので止まると、レビュー工程の前段がまるごと詰まるんですよね。

Codexがどういう位置づけのツールなのかは、Codex入門：OpenAIのAIコーディングエージェントを徹底解説でかなり丁寧に整理しているので、初めて触る方はそちらから入るのが分かりやすいです。

テキトー教師DotAI 認定講師

エディタ側の環境づくりまで含めて知りたい場合は、ChatGPT Codex VS Code完全ガイドも参考になります。インストールから日常的な使い方までを一通り押さえられるので、今回のような障害が起きたときに「自分の使い方のどこが止まるか」を把握するのにも役立ちます。

室谷代表取締役

逆に言うと、Codexを開発フローの一部として組み込んでいる人ほど、今回の告知を他人事として見ないほうがいいんですよね。

障害中に開発者はどう動くべきか——作業を止めないための代替手段

テキトー教師DotAI 認定講師

ここが実務的にいちばん知りたいところだと思うんですよ。障害が起きている間、開発者はどう動くべきか。

まず大前提として、公式の告知を確認する。今回もOpenAIが公式Xで状況を出していました。

公式の発信を見ずに「壊れた」「自分の環境がおかしい」と判断して、設定をいじり始めるのが一番危ないんです。

室谷代表取締役

これ、すごく分かります。障害のときにローカル設定をあれこれ変えて、復旧後に余計なトラブルを生むパターン、よくありますからね。

テキトー教師DotAI 認定講師

整理するとこうです。

• 公式アカウントの告知と公式ステータスページ（status.openai.com）を確認し、復旧済みかどうかを一次情報で判断する
• Codexに依存しないタスク（設計の検討、レビュー、ドキュメント整備、手元での実装）を先に進める
• 復旧後にまとめて投げる前提で、依頼内容をメモに書き出しておく
• 進行中の作業は、こまめにバージョン管理へコミットしておく

室谷代表取締役

ここで一つ注意したいのが、「実はサービス障害ではなく自分の環境の問題だった」というパターンです。会社のネットワークやプロキシの設定でCodexが止まって見えることがあるので、切り分けの手順も押さえておきたいところです。

室谷代表取締役

最後の「こまめにコミット」は本当に大事で。ツールが止まるかどうかに関係なく、作業の区切りで履歴を残しておけば、何が起きても戻せるんですよね。

GitとCodexをどう組み合わせるかはCodexとGitの連携をマスターで解説しています。

テキトー教師DotAI 認定講師

あと、通知の設定をしておくという手もあります。復旧したタイミングをいち早く掴めれば、止まっていた作業をすぐ再開できる。

Codexの通知機能には設定方法がまとまっているので、まだの人はこの機会に整えておくといいですよ。

室谷代表取締役

通知、地味ですけど効くんですよね。今回の告知も、タイムラインを追っていなければ見落としていた可能性がありますし。

テキトー教師DotAI 認定講師

ちなみに、Codexはモデルの推論やストリーミングにWebSocket接続を使うとOpenAIのヘルプセンターに記載があるんですよ。会社のネットワークでWebSocketが既定でブロックされていると、機能が止まったり切断されたりして「障害かな」と見えることがある。

だから切り分けとしては、まず自分のマシンだけかネットワーク全体か、社内WiFiをスマホのテザリングに切り替えて再現するか、を試すのが定石なんです。

室谷代表取締役

それで直れば自分の環境側、直らなければサービス側を疑う、と。ログインできない場合は、まず status.openai.com で障害が出ていないかを確認してから、キャッシュやCookieのクリア、シークレットウィンドウでの再試行、別ネットワークでの試行、という順番がヘルプセンターで案内されていますね。

自分の環境かサービス側か——Codex障害の切り分け手順

室谷代表取締役

さっき触れた切り分けを、手順として整理しておきますね。Codexが使えないとき、いきなり設定をいじる前に「サービス側の問題か、自分の環境の問題か」を切り分けるのが先です。

テキトー教師DotAI 認定講師

順番はこうです。

1. 公式ステータスページ（status.openai.com）を開き、Codexに進行中の障害が出ていないか確認する
2. 公式X（OpenAIの開発者向けアカウント）の告知を確認する
3. 自分のマシンだけか、同じネットワークの他の人も同じか、を確認する
4. 社内WiFiからスマホのテザリングなど別回線に切り替えて再現するか試す
5. それでも直らず、公式にも障害が出ていなければ、ログイン周りのトラブルシューティング（キャッシュとCookieのクリア、シークレットウィンドウ、別ブラウザ・別端末での試行）を順に試す

室谷代表取締役

3と4が特に効くんですよね。「自分だけか、みんなか」「ネットワークを変えたら直るか」で、原因の場所がかなり絞れますから。

テキトー教師DotAI 認定講師

会社のネットワーク管理者向けには、OpenAIが許可すべきドメインの一覧や、Codexが使うWebSocket（TCP 443番ポート）の要件もヘルプセンターで公開しています。プロキシやファイアウォール、TLS検査がWebSocketの接続を途中で切っていると、サービスは正常なのにCodexだけ止まって見えることがあるんですよ。

室谷代表取締役

つまり「Codexが動かない＝必ずしもOpenAIの障害とは限らない」と。切り分けの順番を持っておくだけで、無駄な設定変更を避けられますね。

Codexの利用プランと可用性——止まったときのリスクをどう考えるか

室谷代表取締役

ここは注意が必要なところで、Codexの利用プランの詳細や、可用性に関する数値目標のようなものは、今回の発表では触れられていません。料金体系やプランごとの提供条件についても、この告知から読み取れる情報はないんです。

テキトー教師DotAI 認定講師

なので「プランによって止まりやすさが違う」といった話は、少なくともこの発表からは言えないんですよ。推測で語るのは避けたいところです。

ただ、考え方としては整理できます。外部から提供されるツールである以上、こちらの環境が正常でも使えなくなる時間はゼロにはならない、という前提に立つことです。

室谷代表取締役

公式ステータスページにはCodexの稼働率が99.95%と出ていますが、これはあくまで集計値で、100%ではないんですよね。

テキトー教師DotAI 認定講師

そう、そこが大事なんですよ。99.95%という数字は「ほぼ動いている」という意味であって「絶対に止まらない」ではない。

だからこそ、止まったときの逃げ道を用意しておく価値があるんです。

室谷代表取締役

そうなんですよね。だからこそ「止まったらどうするか」を事前に決めておく。

属人化させない。MYUUUでも、外部ツールに依存する工程には必ず「手で進められる逃げ道」を用意するようにしています。

これは能力の問題ではなく設計の問題なんです。

テキトー教師DotAI 認定講師

単に「障害があった、復旧した」で終わらせず、自チームの業務継続の観点で振り返る材料にする。これが講座で一番伝えたいところですね。

可用性をどう考えるかは、ツールの評判ではなく、自分のワークフローの依存度から逆算して考えるものです。

室谷代表取締役

依存度が高い工程ほど、代替の手順を一枚のメモにしておく。それだけで障害時の消耗が全然違いますから。

公式ステータスページの読み方——何が分かり、何が分からないか

室谷代表取締役

最後に、公式ステータスページで何が分かって何が分からないかを整理しておきます。ここを誤解すると、判断を間違えるんですよね。

テキトー教師DotAI 認定講師

分かることは、Codexを含む各サービスの現在の稼働状況と、集計ベースの稼働率です。Codexは4つのコンポーネントで構成され、集計の稼働率は99.95%と表示されています。

過去のインシデント履歴も追えます。

室谷代表取締役

一方で分からないことは、自分の契約プランや利用中の特定機能が今どうなっているか、です。稼働率は全プラン・全モデル・全エラー種別をまとめた集計値で、個々の契約では体感が異なりうると注記されています。

テキトー教師DotAI 認定講師

だから「ステータスページが緑だから自分の環境は絶対に正常」とは言い切れないし、逆に「赤くなければ障害ではない」とも言い切れない。公式の告知と、自分の環境での再現テストを組み合わせて判断するのが正解なんですよ。

室谷代表取締役

今回の発表のように、公式Xで「発生した」「復旧した」とだけ短く伝えるケースもあります。速報を読むときは、公式X・ステータスページ・自分の環境、この3つを突き合わせる習慣をつけておきたいですね。

よくある質問(FAQ)——復旧状況・データへの影響・再発時の対応

室谷代表取締役

最後に、今回の発表に関してよく出そうな疑問を整理しておきますね。

テキトー教師DotAI 認定講師

まず「今もまだ使えないのか」という点。これはOpenAIの発表で「The issue is now resolved and Codex is back up」と明言されているので、発表時点では復旧済みです。

ただし、その後の状況は公式の発信を確認するのが確実です。

室谷代表取締役

次に「作業中のデータは消えたのか」という点ですが、これについてOpenAIは何も触れていません。データへの影響の有無は現時点では明らかにされていません。

だからこそ、心当たりのある作業は復旧後に内容を確認しておくのが安全です。大事な変更は事前にバージョン管理へ残しておく習慣が効きます。

テキトー教師DotAI 認定講師

「原因は何だったのか」も、今回の投稿には書かれていません。現時点では明らかにされていません。

原因が公表されれば、また別の学びがあると思いますが、発表されていない以上は推測しないのが原則です。

室谷代表取締役

「また同じことが起きたらどうすればいいか」については、公式アカウントの告知を確認する、依存していない作業に切り替える、復旧後にまとめて再開する、という基本の動きを決めておくことですね。特別なことをする必要はなくて、日頃の備えがそのまま効きます。

テキトー教師DotAI 認定講師

あとは、影響を受けた作業を記録しておくこと。障害のたびに「どの工程が止まったか」を残しておくと、次に同じ状況になったときの判断が速くなります。

今回の発表は短いですが、チームの運用を見直すきっかけとしては十分な材料なんですよ。

室谷代表取締役

そうですね。復旧済みとはいえ、依存しているツールが止まる可能性はこれからもゼロにはならない。

今回の告知を、自分たちの開発フローを見直す機会にしたいところです。