Codexの「Selected model is at capacity」の意味と作業再開の方法
Codexで「Selected model is at capacity. Please try a different model.」と表示された場合、選択中のモデルに追加のリクエストを処理する余裕がないという意味です。少し待って再試行するか、利用可能な別モデルを検討しつつ、中断前に完了した作業を確認して未完了部分から再開します。
「Selected model is at capacity」の意味は?
Selected model is at capacity. Please try a different model.
日本語では「選択したモデルの処理容量がいっぱいです。別のモデルを試してください」という内容です。capacityは、モデルのサービスが現在リクエストを受け付けて処理できる余裕を指します。パソコンの保存領域不足を示す文面ではありません。
エージェントは作業の途中でも、次の判断や応答のためにモデルを再度呼び出すことがあります。そのリクエストが処理できないと、作業が停止したように見えます。ただし、それまでのファイル保存、コマンド、外部サービスの変更がすべて取り消されたとは限りません。エラーの発生時点と各処理の実際の完了状態を分けて確認します。
OpenAIの公式APIエラーガイドも、モデルの一時的な過負荷と使用量・リクエスト制限を区別しています。APIは、ソフトウェアがサービスと通信するためのアプリケーション・プログラミング・インターフェースです。ただし、このCodexの表示だけで実際の通信の状態コードや内部エラーコードは確定できません。API文書は区別を理解する参考資料であり、画面の文言と特定コードの一対一対応を証明するものではありません。
個人の使用量上限とはどう違う?
モデルの処理余力とアカウントの残り利用量は別の条件です。利用量が残っていてもモデル側の一時的な容量問題は起こり得ます。逆に、この表示だけで利用量が十分残っているとも断定できないため、別途上限の案内があれば確認します。
| 問題の種類 | 確認する対象 | 対応の方向 |
|---|---|---|
| モデルの処理容量 | 選択モデルが一時的に仕事を受け付ける余力 | 待って再試行、または利用可能な別モデルを検討 |
| 使用量・リクエスト制限 | アカウントの利用案内、リセット時刻、制限メッセージ | 表示された条件に従い、対象の制限を確認 |
| 会話・コンテキスト制限 | 一度に処理できる入力範囲を超えたという別の通知 | 必要な文脈を整理し、不要な入力を減らす |
| 接続・認証・実行環境 | 接続、ログイン、権限、ツールの具体的エラー | 表示された問題を調べ、その原因に対応 |
コンテキストは、現在の判断にモデルが利用できる会話や資料の範囲です。長い作業中に出たことだけを理由に、容量表示をコンテキスト超過と読み替えないようにします。OpenAIのエージェントのエラーと復旧の文書も、過負荷、コンテキスト、使用量、接続を別に説明しています。依頼が消えたり待機したりする症状が中心なら、CodexのVS Code拡張における依頼・待機の問題とも区別して考えられます。
停止した作業を再開する順番
- エラーと直前の進捗を残します。文面、モデル、発生時刻、最後に完了を確認した項目を記録します。コマンドやアップロードの実行中なら、同じ操作を重ねる前に結果を確認します。
- 少し待って再試行します。同じ依頼を連続送信するより間隔を空けます。繰り返し失敗する場合は間隔を広げます。この文面だけから必ず何分後に回復するとは予測できません。
- 続く場合は別モデルを検討します。現在の会話でモデル選択が使えるなら、アカウントに表示される別モデルを選びます。残りの仕事に必要なツールや機能を使えるかも確認します。
- 既存の結果を照合して、残りだけ依頼します。すべてを作り直すのではなく、保存ファイルや外部サービスの反映状態を読んでから続けるよう明示します。
- 小さな残作業で再開を確かめます。例えば最後の保存ファイルを確認してから次へ進めます。同じ表示が戻った場合は進行中と決めつけず、待機、モデル変更、問題報告の次の対応を選びます。
公式のモデル選択ガイドでは、利用可否、ツール、推論設定、使用量制限は製品やモデルの版により異なるとしています。特定モデルへの変更が必ず解決になるわけではありません。APIを直接開発する場合は、応答に再試行までの待機時間を示すRetry-Afterがあれば従います。このヘッダーがアプリ利用者にも常に表示されるわけではありません。
完了済みの作業は何を確認する?
会話の応答が止まったことと、何も変更されていないことは別です。ファイルは保存されたのに完了報告が失敗した、外部サービスが依頼を処理してからエラーが出た、という可能性があります。一つの表示で作業全体の成否を決めず、結果ごとに確認します。
| 作業例 | 再開前の確認 | 重複を防ぐ方法 |
|---|---|---|
| 原稿作成・ファイル編集 | 最新の内容、保存場所、変更点 | 現在のファイルを読み、残りだけ編集 |
| ブログの公開 | 記事ID、公開状態、URL、言語、カテゴリー | 既存記事を探してから新規作成の要否を判断 |
| メディアのアップロード | メディアIDと関連付けられた記事 | 既存アップロードを確認してから追加 |
| コマンド・外部ツール | 結果、変更記録、現在の実行状態 | 不明な処理を繰り返す前に反映を確認 |
例えば7言語の記事のうち3本を公開した後に止まったと仮定します。まず実際の記事と翻訳の関連付けを確認し、残り4本だけを処理します。これは復旧方法を説明する例であり、毎回同じ数の処理が完了しているという主張ではありません。公式の復旧案内も、再試行前にファイルや外部ツールの変更を確認するよう勧めています。
再開を依頼するときの文例
目標、完了結果を確認する場所、残りの仕事、維持すべき項目を一緒に伝えると役立ちます。既存の会話では次のように依頼できます。
モデルの容量エラーで作業が中断しました。まず現在のファイルと外部サービスに実際に保存された結果を確認してください。完了済みの操作を繰り返さず、未完了部分から続けてください。依頼範囲外では公開記事の本文、URL、アイキャッチ画像を維持し、最後に完了項目と残っている項目を分けて報告してください。
新しい会話が必要なら、この文だけでなく目標、フォルダーやファイルのパス、作成済み記事・メディアのID、完了・未完了リスト、適用する指示を渡します。新モデルや新会話が前の結果をすべて自動で知っているとは考えず、作業記録を示して実際の状態を再確認してもらいます。
再開後は「続けます」という返答だけでなく、実際に残作業が行われたかを確認します。保存なら最新のファイル、公開なら実際の記事と状態というように、仕事に合う基準を使います。成否が不明な外部操作は、照合するまで再作成・再公開しないよう依頼するとよいでしょう。
よくある質問
使用量が残っていても表示されますか?
はい。モデルサービスの現在の処理余力とアカウントの利用枠は別の条件です。この表示だけで残量は分からないため、別途使用量の案内も確認します。
アプリの再インストールや有料プラン変更が必要ですか?
この表示だけでは再インストールや支払い変更が必要と判断できません。まず待機後の再試行と利用可能な別モデルを検討します。ほかのエラーが併記される場合は、その具体的な問題を調べます。
何度も起こる場合は何を記録しますか?
時刻とタイムゾーン、モデル、アプリの版、正確な文面、実行中の仕事、別モデルでも再現するか、完了済みの結果をまとめます。公式エラー文書から案内されるサービス状態も確認し、続く場合はその情報で支援を求めます。共有する画面やログからパスワード、認証トークン、非公開情報は除きます。




