Codexの「Selected model is at capacity」は利用上限ではありません。順番に試す6つの対処法

Codexの「Selected model is at capacity」とはどういう意味ですか。

選んだモデル向けのOpenAIのサーバーが足りなくなっている、という意味です。あなたのアカウントに問題はありません。Codexはこの文言を、オープンソースのコード内の1つのエラー、codex-rs/protocol/src/error.rs の ServerOverloaded から表示します。利用上限は別のエラーで、文言も異なります。2026年10月18日にそのファイルから作成した次の表と、表示された文言を見比べてください。

見分けるポイントは2つの言葉です。個人の上限には必ず「usage limit」と表示され、ワークスペースの上限には「credits」か「spend cap」と表示されます。容量不足の文言にはどちらもなく、アカウント側は何も変わっていないため時刻も示されません。GitHubでCodexのissueに回答しているOpenAIのetraut-openaiアカウントは、2026年5月12日にこう書いています。「If you receive this message, it does not mean that you are being rate limited or are out of usage. It means that we are running low on capacity to serve this model in your region.」

OpenAIのAPIは、同種の不足をHTTP 503の server_is_overloaded として返します。エラーコードのガイドでは、原因を「The requested model is temporarily overloaded.」としています。Codexの利用者は、デスクトップアプリ、CLI、VS Code拡張機能、ChatGPTデスクトップアプリ内のCodexでこの表示を報告しています。ChatGPT本体にも一度出ました。2026年7月9日、OpenAIは「across multiple models」でこの表示が出る利用者向けに障害を投稿しており、ステータスフィードのPulseticによる写しで確認できます。

Codexの容量不足はどのくらい続きますか。

容量不足エラー1回なら、たいてい数分で解消します。ステータスに掲載された中で最悪の日でも、3.4時間以内に収まりました。2026年10月18日にOpenAIのステータス履歴を確認しました。容量不足を告知した障害は3件です。6月16日の「Codex 'Selected Model is at Capacity' Error」(196分)、7月9日のモデル選択に関する障害(58分)、7月17日の「Codex 5.6-sol Experiencing Increased Server-Overload Errors」(203分)です。それ以降、容量不足の告知はありません。

フォーラムを見ると、もっと長い経緯が分かります。利用者は、6月15日と16日、7月28日から30日、9月7日から10日、10月3日から12日にこのエラーが続出したと投稿しました。後ろの3回は、容量不足の告知がありませんでした。9月の波のとき、Codexに触れたステータスの記載は、「unexpected usage limit resets」に関する25分の障害だけでした。7月には、GPT-5.6 Solが48時間以上「almost continuously unavailable」だったという投稿もあります。ステータスページが緑でも、Codexが使えるとは限りません。

2026年8月1日から10月16日までに、OpenAIのステータスページでタイトルにCodexを含む障害は13件ありました。継続時間は54分から506分で、中央値は95分、4件は3時間を超えました。分数は、OpenAIが最初に投稿した更新から復旧通知までで数えています。履歴ページは7月20日から始まるため、6月と7月の容量不足の障害は検索で見つけ、7月9日の分はPulseticのミラーから読み取りました。

「Selected model is at capacity」は、どの順番で直せばよいですか。

1回再試行し、次にモデルを切り替え、それから新しいチャットを始めます。Codexはこの文言を表示する前に、すでに再試行しています。設定リファレンスでは、失敗したリクエストの再試行は既定で4回、途切れたストリームは5回です。Enterをさらに10回押しても、ほとんど効果はありません。

1. プロンプトを残す。 何かを再読み込みする前にコピーしておきます。稼働中のセッションでは、同じスレッドで「continue」と入力すると作業が再開することが多いと利用者は報告しています。
2. 1分待って1回だけ再試行する。 短い急増は自然に解消します。1回の再試行で、一時的なものかどうかが分かります。
3. モデルを切り替える。 CLIでは /model を実行するか、codex -m gpt-6-luna で起動します。デスクトップアプリとChatGPT Workでは、入力欄の下にあるモデル切り替えを使います。GPT-5.5は2026年10月14日にChatGPTサインインのCodexから外れたため、代替には使えません。
4. 同じモデルで新しいチャットを開く。 OpenAIのスタッフが10月にフォーラムで勧めた方法です。/new を実行するか、先に /compact を実行して要約を引き継ぎます。
5. status.openai.com を確認し、次に /status を見る。 Codexに触れた障害があるなら待ちます。ページが正常で利用枠にも余裕があるなら、不足しているのはあなたのモデルとリージョンです。
6. 報告する。 失敗しているチャットから /feedback を実行し、時刻とタイムゾーンを書き添えます。OpenAIのスタッフが求めている内容です。/feedback 自体が失敗する場合、スタッフはサポートケースを案内しています。

効かない対処もあります。Codexの再インストール、~/.codex の削除、クレジットの購入では、サーバーは増えません。9月には、3つのリージョンで4つのIPアドレスを試しても駄目だったという投稿がありました。すべてのモデルが失敗する場合、9月25日の障害時にOpenAIが出した案内は「Login via API key will unblock access at this time.」でした。APIキーのセッションは、OpenAIのCodex料金ページによると標準のAPI料金で課金されるので、本当に締め切りが迫っているときのために取っておいてください。

容量不足エラーはCodexの利用上限を消費しますか。

いいえ。容量不足の表示は利用上限ではなく、OpenAIのエンジニアも「out of usage」を意味しないと述べています。確認は10秒でできます。稼働中のCLIセッションで /status を実行すると、使用中のモデルと利用状況が表示され、ウェブでは chatgpt.com/codex/settings/usage で同じメーターが見られます。メーターに余裕があるのにエラーが続くなら、原因は容量不足です。途中で止まったターンが数えられるかどうかは、OpenAIは明らかにしていません。

利用上限は、それとは別の時計で動いています。2026年10月18日に確認したOpenAIのCodex料金ページでは、PlusとStandard BusinessのGPT-6.1 Solで5時間あたり15〜160件のローカルメッセージと見積もられています。GPT-6 Astraは5〜45件、GPT-6 Lunaは350〜3,000件で、さらに「Pro plans currently have no five-hour limit.」と記載されています。加えて週次の上限がかかる場合もあります。したがってProで「usage limit」と書かれない壁に当たったなら、週次の上限ではなく容量不足です。Codexの利用上限では、各プランの枠と、上限メッセージで案内される内容をまとめています。

Codexで3つ目の紛らわしい表示は「rate limit exceeded」で、リクエストが速すぎるという意味です。容量不足の表示と違い、あなた自身のリクエスト頻度が原因なので、1分ほど間隔を空ければ同じモデルで解消します。

有料プランなのに、なぜCodexで容量不足になるのですか。

プランが買うのは利用枠であって、専用のサーバーではなく、OpenAIはモデルとリージョンごとに容量を割り振っているからです。報告はリリース前後に集中します。投稿者は、9月の波をGPT-6 Astraのリリースと結び付けていました。多くはPro 20xのアカウントで、同時にPro 5xのアカウントは動き続けたという人もいます。10月には、チャットに名前を付けるバックグラウンドのGPT-6 Lunaリクエストが原因だとたどった投稿者がいました。スタッフは「can't confirm the background Luna explanation from the thread alone」と返答しています。

本当の解決はOpenAI側の仕事です。2026年10月15日、OpenAIのスタッフはフォーラムに「We've added capacity and shipped changes today to reduce these interruptions.」と書きました。容量不足エラーをバックオフ付きで再試行するようCodexに求めるissue #22390は、2026年5月12日から未解決のままです。これが実装されるまでは、無人で動かしている実行は、組み込みの再試行を超えて続く最初の容量不足エラーで止まります。

Codexが容量不足のあいだ、何を使えますか。

リポジトリを必要としない作業なら、別ベンダーのモデルが使えます。スタックトレースへの質問、リファクタリングの計画、正規表現などは、Codexが待機しているあいだClaudeやGeminiに回せます。作業の短い要約(目的、決まったこと、失敗したこと)を貼り付けて続けましょう。

このページを公開しているWhiziは、Codexの代わりにはなりません。開発者向けAPIはなく、あなたのリポジトリにも触れません。GPT、Claude、Geminiを1つのチャットにまとめたサービスで、会話の途中でモデルを切り替えるとスレッドが新しいモデルに引き継がれ(切り替えの仕組み)、失敗した生成は課金されず返金されます。Claude SonnetとClaude Opusは月$29.99のProが必要で、どのプランも1時間あたり60メッセージが上限です。不足しているのがOpenAI側なら、ClaudeかGeminiのモデルを選んでください。