Codex、DAY10は改善なく使用量のリセットへ｜DAY11は混雑エラー軽減・自動続行へ

Codexに仕事を任せている途中で、「選択したモデルが混雑しているので、別のモデルを試してください」という表示が出る。新しい機能が増えるのもありがたいですが、普段使う立場からすると、こうした中断が減ることも大切です。

今回のDAY10は改善なく使用量のリセットへ。そしてDAY11では、「Selected model is at capacity」というエラーの発生を大幅に減らし、発生しても処理が自動的に続くようにする対策が案内されました。私のCodexでも実際に見かける表示なので、今回は身近な改善です。2 3

前回のDAY8・DAY9に続き、実際の画面と投稿の日本語訳から変更点を確認します。使用量上限との違い、ほかのAIが用意する混雑時の対策、同時期に発表された日本語の音声更新まで見ていきます。

---

---

私のCodexでも出ていた「モデル混雑」エラー

まずは、今回の改善対象になったメッセージです。下の画像は告知用のデモではなく、私が使っているCodexで実際に表示された画面です。1

図1：筆者のCodexで実際に出たエラーメッセージ。2026年10月16日に取得したスクリーンショット。画面内では、すでに2件のファイルを編集した表示も確認できます。1

画面のメッセージ

Selected model is at capacity. Please try a different model.

日本語訳

選択したモデルは現在、処理能力の上限に達しています。別のモデルを試してください。

私の体感では、いまも1〜2日に1回は見かける印象です。回数を記録して集計した数字ではありませんが、たまにしか見ない表示という感覚でもありません。これが減るなら、素直にうれしいところです。

画面には「2件のファイルを編集」と出ています。作業が始まる前に断られるだけでなく、途中まで進んだ状態で中断している点が、このエラーの困るところです。ただし、編集の表示があることと、依頼全体の完了・動作確認が済んでいることは別。再開するときには、どこまで進んだかを確かめたい場面です。

---

DAY10は改善なく、使用量のリセットへ

DAY10の告知は、新機能ではなく使用量のリセットでした。Tibo氏は、リセットボタンがなくなったという話を冗談交じりに否定しながら「Day 10/ Reset」と投稿。その返信で、今後2時間以内に反映する予定を案内しています。2

図2：DAY10のリセット告知と、その後の反映予定の返信。2026年10月16日取得。出典：Tibo氏（@thsottiaux）の投稿。2

DAY10の投稿の日本語訳（筆者訳）

「私のリセットボタンが行方不明になった」という話は、ずいぶん大げさです。

DAY10／リセット。

続く返信の日本語訳（筆者訳）

今後2時間以内に反映される予定です。

ここでいうリセットは、会話やファイルを消す操作ではなく、対象の利用枠を回復させるものです。今回の画面で確認できるのは告知と反映予定までなので、自分のアカウントへの反映は「Settings → Usage／設定 → 使用量」で確認します。対象条件や回復する枠は告知ごとに異なり、購入済みクレジットが増えるという意味でもありません。4

---

DAY11はエラーを減らし、止まったままにしない改善

DAY11では、先ほどの「Selected model is at capacity」という表示が名指しで取り上げられました。発表の柱は、発生を減らすことと、発生しても処理を続けられるようにすることの2つです。3

図3：DAY11の改善告知。対象のエラー文を具体的に挙げ、計算資源の追加と、自動的に処理が続く方向の変更を説明しています。2026年10月16日取得。3

DAY11の投稿の日本語訳（筆者訳）

DAY11。

作業を中断させる「選択したモデルは処理能力の上限に達しています。別のモデルを試してください」という表示の発生を大幅に減らすため、一連の変更を導入し、計算資源も増やしました。

この状態が発生した場合でも、そこで止まったままになるのではなく、時間がたてば自動的に処理を続けるようになるはずです。

実際の利用でまだこの表示を見かける場合は、知らせてください。調査します。

「発生しにくくする」と「復帰させる」を両方扱う

計算資源を増やす対策は、モデル側で処理を受け持つ余力を増やす方向です。一方、自動続行の改善は、一時的に受け付けられなくなった場合でも、それだけで仕事全体が止まり続ける状態を減らす方向と読めます。3

たとえば、ファイルを読む、修正する、動作確認する、結果を見て直すという仕事なら、途中のどこかで中断する可能性があります。そのたびに人が気づいて再開を指示する必要があるか、待てば続きが動くかで、任せやすさは変わります。1回の回答を速くする改善とは違う、「仕事を最後までつなぐ」改善として注目したいところです。

「完全解消」や「必ず何分で復帰」とまでは発表されていない

原文は、発生を大幅に減らすための対策を実施したことと、発生しても自動的に続くようになるはずだ、という説明です。削減率、待ち時間、対象モデル別の内訳などは示されていません。また、自動で別モデルへ切り替える実装だとも説明されていません。3

私の環境でどれだけ減るかは、これから確認することになります。現時点で「もう出なくなった」「放置しても必ず完了する」とまでは言えません。

---

使用量のリセットと、モデルの混雑対策は別の話

連載では「使用量」「容量」「上限」が続いていますが、今回の話を理解するには分けて考える必要があります。利用枠が残っていることと、選んだモデルがその瞬間に処理を受け付けられることは、同じ条件ではありません。 DAY10は前者、DAY11は後者に関わる対策です。3 4 6

リセットを待てば、どんなエラーも直るわけではない

使用量上限は、契約に含まれる利用枠をどこまで使ったかという話です。一方、今回の「at capacity」は、モデル側の処理余力に関する表示。自分の月額枠を使い切ったという通知や、PCのSSDがいっぱいになったという通知とは区別します。画面の一言だけで、個別のバックエンドの原因まで確定できるわけではありません。3 6

同じ文言については、OpenAIが2026年6月16日に公式の障害情報を出した例もあります。その障害は解消済みの過去事例であり、今回の筆者のエラーと同一原因という意味ではありませんが、「自分の使いすぎ」と決めつけないための参考になります。5

逆に、共有の利用枠を使い切っている場合、モデルを切り替えただけではその枠は回復しません。まず使用量画面で、上限に達したのかどうかを確認するのが切り分けの出発点です。6

中断後は「最初からやり直す」より、進んだところを確認する

今回の実機画面のように、ファイルの変更がすでに残っている場合があります。手動で続きを依頼するなら、次のように伝えると、再開時に確認してほしい範囲が明確になります。これは公式の復旧コマンドではなく、依頼文の一例です。

変更済みのファイルと実行済みの操作を確認し、未完了の部分から再開してください。公開・送信・削除などは、すでに実行されたか確認する前に繰り返さないでください。

エラーが続くときは、表示や処理の状態を見ながら自動続行を待ち、動かない場合に利用枠と公式ステータスを確認します。報告用には、発生日時、選択モデル、アプリのバージョン、エラー画面、自然に復帰したかどうかを残すと状況を伝えやすくなります。DAY11の投稿でも、改善後にまだ見かける場合の報告を求めています。3

---

他のAIは？ Claude Code・Gemini CLIの対策を比較

混雑したときにどう仕事を続けるかは、Codexだけの論点ではありません。ほかの開発支援AIにも、再試行や別モデルへの切り替えを組み込む仕組みがあります。ここでは発生頻度の優劣ではなく、公式資料で確認できる「止まったときの続け方」を比較します。7 8

2026年10月16日に確認した告知・公式資料に基づく機能比較。同じ条件で稼働率や復帰時間を測定した比較ではありません。3 7 8

再試行とモデル切り替えは、似ているようで違う

Claude Codeには、代替モデルを指定する--fallback-modelなどの仕組みがあります。Gemini CLIのガイドにある「Keep trying」は、再試行の間隔を徐々に広げながら待つ方法です。連打するのではなく、混雑に合わせて待ち方を変えます。7 8

同じモデルでの復帰を待つ方法なら、使いたいモデルを維持できます。一方、別モデルへの切り替えは仕事を進める選択肢になりますが、回答の傾向や利用条件も変わり得ます。どちらが常によいというより、モデルを変えても先へ進みたい仕事なのか、同じモデルで続けたい仕事なのかで判断が変わります。

技術資料でも、Anthropicは一時的な過負荷を529 overloaded_error、Googleは一時的な過負荷・停止を503系のエラーとして説明し、利用上限などの429とは分けています。これらはAPIの仕様であり、Codexの画面表示に同じHTTP番号が付いているという意味ではありません。「混雑」と「自分の利用枠」を分けて扱う考え方は、各社に共通しています。9

今回のDAY11も、この流れの中で読むと分かりやすくなります。モデルの賢さだけではなく、一時的な混雑をどう受け流し、作業を続けるか。その設計も、AIを仕事道具として比べるポイントになってきています。

---

関連更新：GPT-Live-1.1で日本語の声も追加

同時期には、OpenAIからGPT-Live-1.1の音声更新も発表されました。こちらはTibo氏のDAY11の混雑対策とは別の告知ですが、対象にCodexも含まれるため、関連する更新として押さえておきます。10

図4：OpenAI公式のGPT-Live-1.1告知。画面上の投稿日時は日本時間2026年10月16日3時19分。画像内の動画は告知用デモであり、筆者の試用結果ではありません。10

音声更新の投稿の日本語訳（筆者訳）

新しい声。より自然なアクセント。そして「確認中……」を減らします。

GPT-Live-1.1は、ChatGPT、Codex、dotsのVoiceにこれらの改善をもたらします。フランス語、ドイツ語、ヒンディー語、メキシコのスペイン語、韓国語、日本語で新しい声を追加します。

本日、すべてのユーザーに向けて展開を開始します。APIにも近日中に対応する予定です。

日本語の声が増え、待っている間の言い回しも自然に

公式リリースノートは10月15日付で、日本語などの新しい声に加え、言語ごとのアクセントや、検索中に伝える短いフレーズの種類を改善したと説明しています。声の選択は「Settings → Voice → Voice」から。表示される選択肢は地域やアカウントによって異なる場合があります。11

「確認中……」が減るという表現は、同じつなぎ言葉を繰り返す体験を改善する話として読むのが適切です。検索そのものの時間が一定割合で短くなる、DAY11の混雑エラーが音声モデルによって解消する、といった発表ではありません。10 11

日本語で仕事を相談したり、作業の途中で口頭の指示を加えたりする使い方では、声の自然さも使い心地に関わります。ただし、今回の画像から確認したのは発表内容まで。新しい日本語音声を試して評価した結果ではありません。また、告知時点ではAPIは「近日中」で、利用可能になったという案内ではありません。10

---

DAY1〜11を振り返ると、改善は「仕事の続けやすさ」へ

ここまでの主な発表を並べると、速度だけでなく、指示の出しやすさ、長い文脈、保存容量、そして混雑時の継続へと、改善の対象が広がっていることが分かります。以下は各DAYの発表当時の整理であり、すべての機能が現在の全プランに同じ条件で提供される一覧ではありません。12

DAY1〜9はこれまでの連載、DAY10・11は本記事の投稿画像・日本語訳を参照。GPT-Live-1.1は同時期の関連更新として別に扱っています。2 3 12

改善とリセットは、必ずしも完全な二者択一ではありませんでした。DAY2は複数の更新の後にリセットがあり、DAY3も機能更新と保存型リセットの両方がありました。「何勝何敗」と数えるより、仕事のどの部分が楽になるかを見るほうが実態をつかめます。12

特にDAY7の文脈、DAY9の保存、DAY11の混雑対策は、見た目が大きく変わる機能ではありません。それでも、長い仕事を任せるためには重要な部分です。できることを増やす更新から、増えた仕事を続けやすくする更新へも手が入っていると受け止めています。

---

まとめ｜賢さだけでなく、途中で止まらないことも大切

DAY10は使用量のリセット、DAY11はモデル混雑による中断を減らす対策でした。使える枠が戻ることと、その枠で仕事を進めやすくなること。今回は、この2つを分けて考えると変化の意味が見えてきます。2 3

私が確かめたいのは、新しい機能の数よりも、普段の作業であの表示を見る回数が減るか、出ても自分で再開を促さずに続くかという点です。発表どおりに改善が進めば、画面に戻って中断を確認する手間も減らせそうです。

「前より賢い」だけでなく、「任せた仕事が前より止まりにくい」。 毎日使う側には、そうした改善もありがたいものです。

---

参考資料

[1] 筆者のCodex実機スクリーンショットと体感の報告
2026年10月16日取得。図1。本文で示したエラーメッセージと、ファイル編集表示の実画面。「1〜2日に1回」は筆者の体感で、発生回数を測定・集計した値ではありません。

[2] Tibo氏のDAY10リセット告知と返信
図2の提供スクリーンショット、2026年10月16日取得。告知本文と「Landing within the next 2 hours」を日本語訳しました。反映予定と個別アカウントでの回復確認は区別しています。
発信元： https://x.com/thsottiaux

[3] Tibo氏のDAY11改善告知
図3の提供スクリーンショット、2026年10月16日取得。本文と訳文は画像内の原文で確認。個別投稿URLはOpenAI Developer Communityの案内から特定しました。
https://x.com/thsottiaux/status/2110750421367287996

[4] OpenAI Help Center：使用量リセットの仕組み
自動・全体リセットと保存型リセット、対象条件と使用量画面の確認。資料に記された過去の配布条件をDAY10へそのまま適用していません。
https://help.openai.com/en/articles/20001498-how-banked-codex-resets-work
https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

[5] OpenAI Status：Codex “Selected Model is at Capacity” Error
2026年6月16日の障害記録。解消済みの過去事例で、今回のエラーの原因や現在の障害発生を示すものではありません。
https://status.openai.com/incidents/0pqnp2gq
現在の状況を確認する公式ページ： https://status.openai.com/

[6] OpenAI Help Center：Managing usage with GPT-6 Astra in Work and Codex
使用量画面での上限確認、モデル変更だけでは共有利用枠が回復しないこと、リセットの区別。
https://help.openai.com/en/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex

[7] Anthropic：Claude CodeのCLI・モデル設定資料
--fallback-modelと「Fallback model chains」。混雑・利用不能に対する代替モデル設定を参照。安全分類など別の理由で行われる切り替えとは混同していません。
https://code.claude.com/docs/en/cli-reference
https://code.claude.com/docs/en/model-config

[8] Google：Gemini 3 Pro and Gemini 3 Flash on Gemini CLI
「Capacity errors」「Usage limits and fallback」。同じモデルでの再試行と代替モデルの選択、待ち時間を広げる再試行を参照。Gemini 3向けガイドで確認できる事例として扱っています。
https://geminicli.com/docs/get-started/gemini-3/

[9] Anthropic・Google：APIエラーの公式資料
Anthropicの529／429、Googleの503／429の区別。一般向けアプリのエラー画面とAPIのHTTP番号を同一視していません。
https://platform.claude.com/docs/en/api/errors
https://ai.google.dev/gemini-api/docs/api-errors
https://ai.google.dev/gemini-api/docs/troubleshooting

[10] OpenAI公式のGPT-Live-1.1告知
図4の提供スクリーンショット。表示日時は日本時間2026年10月16日3時19分。投稿全文を日本語訳しました。「本日」は告知時点、「APIは近日中」は発表時点の予定を指します。
発信元： https://x.com/OpenAI

[11] OpenAI：2026年10月15日付GPT-Live-1.1リリースノート
新しい声、より自然なアクセント、検索中の短いフレーズ、音声設定と地域・アカウント差を確認した資料。
https://help.openai.com/en/articles/6825453-chatgpt-release-notes
https://openai.com/products/release-notes/

[12] AI実践ラボのこれまでの連載
振り返り表は各回の発表当時の整理です。各機能の現在の対象プラン・提供条件を一覧化したものではありません。

• DAY1：GPT-6系の速度改善
• DAY2：4つの更新と使用量リセット
• DAY3：GPT-6・Intelligent UIと保存型リセット
• DAY4：途中修正とUltrafast
• DAY5：入力予測とdots連携
• DAY6・DAY7：使用量リセットと500kの文脈
• DAY8・DAY9：使用量リセットとデスクトップ保存の最適化