OpenAI・Codexの「28日間アップデート」を毎日追い、公式情報に基づいて詳しく解説しています。新機能とリセットを見逃したくない方は、ぜひフォローしてください。

2026年10月15日（米国時間）、OpenAIの「28日間、Codex・ChatGPT Workの改善またはフルリセット」企画でDay 11が発表されました。

今回のアップデートは、Codex・Workで発生していたモデルの処理容量不足による中断を減らし、エラー発生後も作業が自動で続くようにする安定性改善です。

対象となる代表的なエラーは次のものです。

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

Day 10はフルリセットでしたが、Day 11は新しい利用量リセットではなく、サーバーの処理能力と復旧挙動を改善した日です。

OpenAIのTibo Sottiaux氏は、追加の計算資源を投入し、複数の変更によってこのエラーの発生を「非常に大幅に」減らしたと説明しています。エラーが残った場合も、途中で止まりっぱなしにならず、最終的には自動的に処理を続けられるようにしたと発表しました。

ただし、エラー発生率の具体的な低下率、最大復旧時間、すべてのクライアントにおける完全な復旧保証は公表されていません。

この記事では、Day 11の発表を読み解き、過去のユーザー報告、バックエンドの容量不足とアカウント利用枠の違い、リトライ・キュー・サイドエフェクトの注意点、ユーザーができるトラブルシューティングまで整理します。

情報確認日：2026年10月16日（日本時間）。 発表済みの事実と、一般的な分散システムの設計としての解説を区別します。技術的な実装詳細は未公開です。

Day 11のポイント早見表

項目	発表内容
Day	11
発表	2026年10月15日（米国時間）、日本時間10月16日未明
改善対象	「Selected model is at capacity」エラー
対策1	計算資源（compute）を追加
対策2	複数のシステム変更により発生を大幅に削減
対策3	エラーが発生しても、最終的に自動継続できるよう改善
削減率・復旧までの秒数	公表なし
すべての処理の無停止保証	なし
Day 11の追加フルリセット	公式一覧に記載なし

公式情報：

公式X投稿は**2026年10月16日00:11ごろ（日本時間）**の発信です。

1. 何が変わった？発表の3つの要素

① モデルへのリクエストを処理できる計算資源を追加

大規模言語モデルは、リクエストを受け取るとGPUなどの計算資源を使って推論処理を実行します。

利用者が集中して、あるモデルを処理できる容量が足りなくなると、一時的に新しいリクエストを受け付けられないことがあります。

ユーザーA ─┐
ユーザーB ─┼─→ モデル推論基盤
ユーザーC ─┤       │
ユーザーD ─┘       └─ 処理が集中
                         ↓
                一部のリクエストを受け付けられない

Day 11の発表は、追加のcompute（計算資源）を投入したことを明示しています。

ただし、投入したGPUの台数、地域、データセンター、モデル別の配分、TPMの増加率などは公開されていません。

したがって、「GPUを何万台増やした」「速度が何倍になった」という具体的な数字を補うことはできません。

② 処理容量エラー自体の発生を大幅に減らした

Tibo氏は「複数の変更」により、容量不足のエラーを非常に大幅に減らしたと説明しています。

追加compute以外の変更の具体例は未公開です。

一般論としては、負荷分散・推論リクエストのキューイング・容量管理・バックプレッシャー制御などが関連する技術ですが、OpenAIがDay 11でそれらを採用したという証拠ではありません。

③ 万一エラーが起きても自動で処理を続けられるように

Day 11で特に実用的なのがこちらです。

従来は、

長いコーディングタスクを実行
        ↓
モデル容量不足
        ↓
Selected model is at capacity
        ↓
タスクが止まる
        ↓
ユーザーが手動Retry・モデル変更・再依頼

という経験をしたユーザーがいました。

Day 11では、公式説明上、

長いコーディングタスクを実行
        ↓
モデル容量不足
        ↓
待機・復旧を経て再び処理へ
        ↓
タスクが自動的に継続することを目指す

という改善が行われています。

ただしどのような内部状態で待機するか、何秒ごとに再試行するか、一定時間で諦めるのか、すべてのクライアントに展開済みかは、公表されていません。

「必ず無限に再試行される」「通信切断やPC再起動まで復旧保証される」という意味ではありません。

2. 「Selected model is at capacity」は何のエラー？

このエラーを直訳すると、「選択したモデルは現在処理容量の上限に達しています。別のモデルを試してください」です。

重要なのは、ユーザー個人の利用枠と、サービス側の計算処理容量は別という点です。

利用枠・処理容量・API Rate Limitの違い

問題	主な意味	一般的に確認するもの
モデルがcapacityに達した	モデル提供側の処理能力・受け入れに問題	一時的なサービス混雑と復旧
Codex / Workの利用枠を使い切った	契約プランの利用可能量が不足	Settings → Usage
API Rate Limit	APIの回数・トークン数などの上限に抵触	APIの制限表示・レスポンス
認証・権限エラー	ログイン、APIキー、組織権限などが不適切	アカウント・権限
ローカルの実行エラー	テスト失敗、プログラムの例外、ビルド失敗	ターミナル・CIログ

容量不足エラーが出たからといって、即座に「ChatGPT Proの週間利用枠がなくなった」とは限りません。

実際、OpenAIのCodex GitHubリポジトリには、まだプランの利用量が残っているのに容量不足エラーで止まったとの報告があります。

参考：Issue #41790

なお、表示メッセージだけでは本当の根本原因までは確定できないことがあります。同種のエラーに見えても、バックエンドのルーティング、クライアントの接続状態などが関わる可能性があります。

3. なぜ開発者から改善要望が多かったのか

Day 11の改善内容を理解するには、過去の実例を見るのが分かりやすいです。

事例A：長時間の作業が途中で中断

2026年7月17日に公開された openai/codex Issue #33878 では、macOSのCodex Desktopで長時間タスクがcapacityエラーにより終了し、元の作業の継続ができなくなったと報告されています。

さらに同Issueには、Windowsで約25分間作業した後に server_overloaded という内部エラーで終了した例も追記されました。

開発者にとっての問題は、単に数分待たされることだけではありません。

それまでの調査・修正の文脈が途切れる
続きの指示を自分で書き直す必要がある
中途半端な編集が残ったか確認が必要になる
自動化していた長いタスクが途中で失敗する

自分が画面を見ていないと進行が止まるため、長時間のエージェント利用にとって大きな障害でした。

事例B：15分の間に繰り返し容量エラー

Issue #41790 では、Proユーザーから約15分の同一タスクで3回capacityエラーが発生したという報告があります。

この例では、自動の再試行と待機（backoff）自体は行われていたものの、復帰した後に再びエラーになっていました。

つまりDay 11以前でも一部環境で再試行は存在しました。

Day 11を「初めて自動再試行機能が実装された日」と説明するのは不正確です。

事例C：次のキューへ進んでしまう問題

Issue #33853 は、現在のタスクがcapacityエラーになったとき、そのタスクが完了しないまま次のキュー済み指示が処理されることを避けてほしいという改善要望です。

タスクA：バグ修正
   ↓ エラーで中断

タスクB：Aの修正完了後にマージ
   ↓
Aが終わっていないのにBを開始すると危険

Day 11の発表は「再開しやすくする」改善を示しますが、キュー順序と依存関係の不具合をすべて解決したという明示的な発表ではありません。

こうしたIssueは、Day 11の背景を理解するためのユーザー報告・要望であって、OpenAIが個別不具合の修正完了を認定した資料ではありません。

4. 自動復旧の仕組みを技術的に考える

ここからは、Day 11の実装の説明ではなく、一般的な分散システムやAIエージェントの設計例です。

Retry（リトライ）

一時的に失敗した処理を再度実行することです。

Backoff（バックオフ）

失敗直後に大量のリクエストを送り続けるのではなく、次の試行まで待機時間を設けることです。

一例：

1回目の失敗 → 少し待つ
2回目の失敗 → さらに待つ
3回目の失敗 → もっと長く待つ
              ↓
容量が戻ったら処理へ

待機時間を徐々に増やすことを**Exponential Backoff（指数バックオフ）**と呼びます。

さらに、同時に多くのクライアントが再試行することを防ぐため、待機時間にランダムな揺らぎ（Jitter）を加える設計もあります。

これらの用語を理解しておくと、Codexが一定時間待った後に再開する挙動を解釈しやすくなります。

ただし、Day 11で指数バックオフやJitterが新たに導入されたと公式が発表したわけではありません。

State Preservation（状態保持）

途中で失敗した際に、ユーザーの依頼、これまでのツール結果、ファイル変更状況などを保持し、再開できるようにする設計です。

RUNNING
  ↓ 容量不足
WAITING / RETRYING
  ↓ 処理可能
RUNNING
  ↓ 作業完了
COMPLETED

これに対して、容量不足でただちにFAILEDへ落とし、以前の状態を復元できなければ、ユーザーの手間が増えます。

今回の発表は「最終的にはそのまま継続できるように」という方向性を示していますが、内部の状態遷移がこの図と一致するという保証はありません。

5. 自動再試行でも、外部操作の二重実行には注意

ここはエージェント自動化を利用する開発者にとって特に重要です。

たとえばCodexに次の作業を依頼したとします。

1. ファイルを編集
2. テスト実行
3. PRを作成
4. CIを確認
5. PRをマージ

モデルの推論リクエストの再試行と、GitHubへの書き込み・外部APIへの投稿などの再実行は同じではありません。

一般的に、一度成功した外部書き込みを、失敗と誤認してもう一度実行すると、重複したPR、コメント、注文、投稿などが発生する可能性があります。

例えば、

PR作成APIへ送信
   ↓
GitHub側ではPR作成成功
   ↓
応答が途切れてクライアント側は失敗扱い
   ↓
同じAPIを再送
   ↓
重複PR作成の可能性

のようなパターンです。

Day 11の公式発表は容量不足の改善と自動継続についてであり、すべての外部APIに対してExactly Once（副作用が絶対に1回だけ）の実行を保証したものではありません。

自動化で守っておきたい設計

操作前後でGitHubなどの現在の状態を読み直す
既存のIssueやPRを検索してから新規作成する
APIが対応するなら冪等性キー（Idempotency Key）を使う
書き込み結果が分からない場合、無条件で連続再送しない
CIやデプロイは実行IDを記録する
重要なマージ・削除・本番書き込みは権限や承認の設定を明確にする

自動再開が改善されても、重要な副作用の安全性はアプリ側・ワークフロー側で設計する必要があります。

6. 自分の環境でまだcapacityエラーが出たら？

OpenAIのDay 11投稿は、エラーがまだ発生する場合は報告してほしいと呼びかけています。

Step 1：直ちに何度も再送しない

エラーが出たら、まずクライアントが待機・再試行中かを確認しましょう。

自動で継続する途中なのに新しいタスクを重ねると、どこまで実行したか分かりにくくなることがあります。

ただし、待てば必ず復旧するという保証はありません。

Step 2：Usageを確認する

Codex・Workの利用可能な残量は、デスクトップアプリなどで確認できます。

Settings
  └─ Usage

Codex CLIで利用状況が表示できる環境なら、セッション内で次のスラッシュコマンドを確認します。

/status

Usageに余裕があるのにcapacityエラーが発生するなら、少なくとも単純にプラン上限へ到達したという説明だけでは不十分です。

Step 3：重要な書き込み操作の状態を確認する

再試行ボタンを何度も押す前に、ソースコードの差分、PRの有無、CI・デプロイの結果を確認します。

手元のGit作業ディレクトリなら、次のような読み取り専用コマンドが使えます。

git status --short
git diff --stat

git status --short：変更済み・未追跡ファイルの概要を表示
git diff --stat：未ステージの変更量をファイル別に表示

これらは変更を確認するコマンドで、ファイルを修正・削除しません。

Step 4：症状を再現して公式へ報告する

引き続き発生する場合は、次の情報を整理すると調査しやすくなります。

項目	記録したい内容
日時	例：2026-10-16 10:30 JST
クライアント	Codex Desktop / CLI / Work、OS
バージョン	アプリのAbout表示など
利用モデル	GPT-6 Astra / GPT-6.1 Solなど
タスク	新規開始時か、長時間作業の途中か
エラー	表示されたメッセージ
その後	自動で回復したか、何分待ったか、再試行で止まったか
利用量	Usageが残っているか
その他	可能なら診断ID、スクリーンショット

秘密鍵や認証トークン、顧客情報をログや公開Issueに載せないようにしてください。

7. Day 11で「変わらないもの」

Day 11は安定性の改善なので、別の施策と混同しないようにしましょう。

項目	Day 11で公式発表された？
capacityエラーの大幅削減	はい
エラー後の自動継続の改善	はい
新モデル・性能ランキング更新	いいえ
全タスクの処理速度2倍・8倍	いいえ
Codex利用枠のフルリセット	確認なし
保存可能なリセットチケットの追加	確認なし
全クライアントで永久に無エラー	保証なし
APIのRate Limit・料金変更	確認なし
外部APIのExactly Once保証	保証なし

特にDay 10では利用枠のリセット完了が報告されましたが、Day 11ではモデルの処理容量が混雑した場合のサービス品質を改善しています。

両者は「使えるようになる」という点では似ていても、根本的に異なる問題への対策です。

8. Day 1〜Day 11を振り返る

Day	主なアップデート
1	GPT-6 Astra / GPT-6.1 Solの標準速度改善
2	Auto-review無料化、APIティア整理、Meetings、Decisions API、追加リセット
3	GPT-6・Intelligent UI、保存可能なリセットの配布
4	GPT-6.1 Sol Ultrafastと途中指示への高速反応
5	Dotsの機能強化、Composer predictions
6	グローバルリセット
7	GPT-6.1 Solの標準コンテキスト272K→500K
8	グローバルリセット
9	ChatGPT / Codexデスクトップの状態保存データを約60%削減見込み
10	フルリセット、完了報告あり
11	モデルのcapacityエラーを大幅削減し、自動継続を改善

Day 10が利用可能量の回復であるのに対し、Day 11は長時間の作業が途中で中断される可能性そのものを減らす改善です。

よくある質問

Q. Day 11でリセットも配布された？

確認した公式トラッカーには、Day 11の追加リセットは掲載されていません。 Day 11は処理容量と安定性の改善です。

Q. 「Selected model is at capacity」はもう出ない？

ゼロになるとは発表されていません。 発生を大幅に減らし、発生しても最終的には自動継続できるようにしたという説明です。

Q. 全ユーザーが同じ改善を受ける？

Day 11の公式告知には、対象プラン別の実測値や提供バージョンの完全な表はありません。Codex / Work全体へ関わる施策ですが、各アカウントでの効果を一律に保証する情報ではありません。

Q. 以前からの自動リトライ機能がなくなって、新しい仕組みに変わる？

そのような発表ではありません。 過去にも一部クライアントで自動リトライは行われていました。今回の変更で何を置き換え、何を維持したかは未公開です。

Q. Codex CLIでも必ず自動で再開できる？

CLIを含む全クライアントへの同一の復旧保証は公開されていません。 まだ発生する場合は使用アプリ・バージョン・ログを添えて公式へ報告しましょう。

Q. 外部APIの操作も必ず1回だけ実行される？

保証されていません。 ファイル変更、PR作成、デプロイなどは、実際の外部状態を確認するように設計しましょう。

まとめ

Day 11は、目立つ新機能よりも長時間タスクの実用性に直結する安定性改善でした。

押さえるべき点は次の通りです。

2026年10月15日（米国時間）のDay 11はcapacityエラー対策
追加の計算資源＋複数のシステム改善を実施
「Selected model is at capacity」エラーを大幅に削減
エラーが残っても最終的に自動継続しやすくする改善
発生率・待機時間・モデル別の実測値は未公表
すべての失敗・外部操作・キュー動作を保証するわけではない
Day 11の追加フルリセットは公式発表で確認されていない
まだ発生する場合、アプリ、モデル、時刻、再試行の結果を添えて報告する

Codexを、何十分・何時間もかかるリポジトリ調査、テスト、レビュー、PR作成へ使う人ほど、途中で止まりにくくなる恩恵が期待できます。

単に推論が速いこと以上に、途中で人間がエラー対応に戻されないことは、AIエージェントによる継続的な開発の重要な品質指標です。

参考資料・一次情報

今後もOpenAI・Codexの28日間アップデートを毎日追跡し、公式発表と未確認事項を区別して詳しく発信します。Day 12以降の改善・リセットも見逃したくない方は、ぜひフォローしてください。