Codex Webのレスポンス遅延は2026年5月から実測レベルで悪化している¶

対象 / ポイント

対象: Codex Web、Codexアプリ、CLI/IDE拡張を業務で使い、直近のレスポンス劣化を切り分けたい開発者・チームリード。

ポイント: - 2026年5月7日以降、OpenAI StatusにCodex関連の劣化記録が集中している - GitHub IssuesとDeveloper Communityでも、遅延・再接続ループ・ストリーム切断の報告が同時期に出ている - 利用者側では、サーフェス切替・reasoning設定・コンテキスト量の3点を先に切り分ける

Codex Webが「最近遅い」という体感は、2026年5月に入って公開記録で確認できるレベルまで強まった。 5月7日から11日にかけてOpenAI StatusにはCodex関連のインシデントが複数並び、同じ時期にGitHub IssuesとOpenAI Developer Communityにも速度低下や再接続ループの報告が出ている¹²³。

この記事の問いは1つだ。 Codexの遅延は利用者側の環境問題なのか、それともサービス側の劣化として扱うべきなのか。

結論から言えば、少なくとも2026年5月上旬については「サービス側の公開シグナルがある」と見るのが妥当だ。ただし、すべての遅延を同じ原因にまとめるのは危ない。公式インシデント、ユーザー報告、ローカル設定を分けて見る必要がある。

公式ステータスではCodex関連インシデントが集中した¶

最も強い根拠は、OpenAI公式ステータスページに残っている時系列だ。

5月7日夕方から5月11日にかけて、CodexまたはCodexの背後で使われるモデル層に関係する記録が続いた。 OpenAI Status上で確認できる主な記録は次の通りだ。

日付	公式記録	Codexへの関係
5月7日 17:15 - 5月8日 08:31	ChatGPT & Codexのtranscription failures増加	Codexが影響コンポーネントに含まれる¹²
5月8日 12:31 - 14:14	gpt-5.5 model in the APIのエラー率増加	途中更新で通常より高いlatencyが明記された⁸
5月8日 15:07 - 16:17	Codex Cloud Tasksの劣化	follow-up promptsの失敗率増加が説明された⁷
5月11日 01:23 - 05:35	ChatGPT file uploadとCodex Cloud task creationのエラー増加	Codex Cloudのタスク作成が影響対象¹
5月11日 16:11 - 17:59	GPT 5.5のエラー率増加	Codex特定ではないが、モデル層の隣接要因⁹

この表だけで「Codex Webの全利用者が同じ遅延を受けた」とは言えない。 OpenAI Statusも、可用性指標は全ティア・全モデル・全エラー種別を集約したもので、個別利用者の体験とはズレる可能性があると注記している。

それでも、5月上旬にCodex関連の劣化記録が重なったことは事実だ。「自分のWi-Fiが悪いだけ」と片付けるには、サービス側のシグナルが多すぎる。

GitHub Issuesでも「遅い」と「切れる」が別々に出ている¶

公式ステータスの外側では、GitHub Issuesにユーザー側の症状が残っている。

5月7日のIssue #21527では、Codex App 26.429.61741を使うProユーザーが、 VS Code拡張とCodexアプリのどちらでも応答が非常に遅いと報告している。使用モデルはgpt-5.5 fastと書かれており、速度重視のモデル選択だけでは解消しない症状として読める²。

3月20日のIssue #15334は、5月以前から遅延が散発していたことを示す補助線になる。この報告では、単純な質問でも応答に10分以上かかり、同じマシン・同じネットワークではChatGPT Webが正常に動いていると説明されている⁴。つまり、遅延のすべてを利用者ネットワークに帰すのは無理がある。

もう一つ重要なのが4月22日のIssue #18960だ。ここでは、Codex Appのストリーミング中にWebSocketがサーバ側で閉じられ、 stream disconnected before completion: websocket closed by server before response.completed というエラーと再接続ループが報告されている⁵。

速度低下と切断は別の症状に見える。しかしユーザー体験では、どちらも「待たされる」「やり直しになる」「作業が止まる」として同じ痛みに集約される。

「2x capacity until May 30」は引き金候補だが、原因断定はできない¶

5月12日のOpenAI Developer Community投稿は、今回の違和感をよく表している。

投稿者は「2x capacity until May 30」と呼ばれるロールアウト以降にCodexが不安定になり、利用量が約50%の状態でも再接続ループ、ストリーム切断、thinking状態のフリーズ、 1〜2分での生成中断が起きると報告した³。 OpenAI Help Center側でも、期間限定でCodexがFree/Goに含まれ、他プランは2x rate limitsを享受すると説明されている⁶。

ここで注意したいのは、相関と原因を分けることだ。 2x rate limitsの案内が存在し、その前後で不安定化を訴える投稿もある。しかし、OpenAIが「2x化のための構成変更が切断原因だった」と公式に説明したわけではない。

現時点で安全な言い方はこうだ。 2x rate limitsのロールアウトは、時系列上の引き金候補であって、確認済みの根本原因ではない。

この切り分けは重要だ。原因を早く決め打ちすると、利用者側で確認できる設定や経路の問題まで見落とす。

推定される劣化要因は3層に分かれる¶

公開情報をつなぐと、劣化要因は1つではなく3層で見るのがよい。

第1層はサービス側のインシデントだ。 5月8日のCodex Cloud Tasks劣化では、follow-up promptsが通常より高い率で失敗していたと説明されている⁷。 5月11日のインシデントでも、Codex Cloudのタスク作成が影響対象に入っている¹。

第2層はモデル層の不安定さだ。 5月8日と5月11日にGPT-5.5関連のエラー率増加が記録され、5月8日の途中更新では高いlatencyも明記された⁸⁹。 Codex WebやCodex Appがそのモデル層に依存する場面では、UI側の遅延として見える可能性がある。

第3層は利用者側のコンテキストと設定だ。 OpenAI Help Centerは、Codexの使用量はタスクの大きさ、複雑さ、実行場所によって変わり、大きなコードベースや長時間セッションはより多くのコンテキストを消費すると説明している⁶。また、OpenAI Codexリポジトリのメンテナーは、日常的なコーディングではmedium reasoningを推奨し、 xhighはトークン消費とターン時間を増やすとコメントしている¹⁰。

この3層を分けると、利用者側でできることも見えてくる。サービス障害は直せないが、症状の増幅要因は減らせる。

利用者側の切り分け手順¶

まず見るべきなのは、OpenAI Statusと自分の設定だ。

障害が出ている時間帯にCodexだけが遅いなら、ローカル原因を疑う前にStatusを見る。同じタスクをCodex Web、Codex App、CLI/IDE拡張で試し、どのサーフェスで再現するかを分ける。 Webだけ遅いのか、Codex Cloud task creationが失敗するのか、CLIのローカル実行でも遅いのかで、見るべき層が変わる。

次に、reasoning設定とモデルを確認する。日常的な修正でxhighを使っているなら、まずmediumに戻して再現を見る。可能ならGPT-5.5系と別モデルで同じ軽量タスクを投げ、モデル層の問題かどうかを分ける。

最後に、コンテキスト量を削る。大きなリポジトリでは.codexignoreで依存ディレクトリ、ビルド成果物、大容量データ、生成物を除外する。 InventiveHQの診断ガイドも、ネットワークのtime_connectとtime_starttransferを測り、コンテキスト量の差を比較する手順を紹介している¹¹。

実務では次の順番が扱いやすい。

OpenAI Statusを確認する
同じ軽量タスクを複数サーフェスで試す
reasoningをmediumに戻す
.codexignoreでコンテキストを削る
それでも遅ければ、IssueやCommunityの同時報告を見る

これで完全に直るわけではない。ただし、サービス側の障害と自分の設定問題を混ぜずに済む。

単一ベンダ依存は開発停止リスクになる¶

今回のCodex遅延は、AIコーディングエージェントを本番の開発基盤として扱う難しさを示している。

エージェントに実装、レビュー、PR作成を任せるほど、サービス側の障害は直接的な開発停止になる。モデルのベンチマーク性能だけでなく、インシデント頻度、復旧までの時間、上限と課金の透明性を見る必要がある。

短期的には、複数のハーネスを並走できる状態にしておくのが現実的だ。 GitHub Discussion #9588でも、Codexの遅さや挙動悪化を理由にClaude Code側へ移るという利用者コメントが出ている¹⁰。これは単なる好みの話ではない。業務停止を避けるための冗長化である。

まとめ¶

Codex Webのレスポンス遅延は、2026年5月上旬については公開記録で確認できる問題になっている。 OpenAI StatusにはCodex CloudとGPT-5.5関連の劣化が並び、 GitHub IssuesとDeveloper Communityにも遅延・切断・再接続ループの報告がある。

一方で、原因を「2x capacity until May 30」の一言で断定するのは早い。確認できるのは、2x rate limitsの案内と、不安定化を訴える時系列上の近接報告までだ。

利用者側の現実解は、Status確認、サーフェス切替、reasoning設定、コンテキスト削減、別ハーネス並走の5つに絞られる。 AIエージェントを業務の主動線に置くなら、速度だけでなく信頼性を調達条件として測る段階に入っている。