Selected model is at capacity：Codexの意味と対処、利用枠切れとの違い

「Selected model is at capacity」は、選んだモデルがその時点でリクエストを受け付けられない旨のエラーです。ただし、これだけで利用枠切れやPCの故障とは判断できません。まず依頼文を保存し、公式の障害情報と自分の使用状況を確認します。

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

何が起きている？公式の障害記録で分かること

直訳すると「選択したモデルは容量に達しています。別のモデルを試してください」です。ここでいう容量を、あなたのPCのメモリやディスク容量と読み替える根拠はありません。この文言を伴うサービス側の障害が、OpenAIの公式ステータスに記録されています。

この2件から分かるのは、「同じ表示がサービス側の障害でも出る」「別モデルに変えても改善しない状況がある」ということです。公表された件数から発生頻度を計算することはできず、あなたのエラーが過去の障害と同じ原因だったとも言えません。日付は公式ページの表示に従い、時刻の日本時間への換算はしていません。

両記録には、具体的なハードウェア不足やアカウント切り替えの不具合といった根本原因は公表されていません。「GPUが足りない」「Proの認証が壊れた」などと断定するのは、確認できた情報を超えます。本記事は2026年10月1日に公式原文を確認し、確定できる事実と対処の判断を分けています。

利用枠・401・thread not foundとの違い

作業が止まるという見た目は似ていますが、確認する場所が違います。容量エラーが出たら、まず画面の全文と使用状況を組み合わせてください。同じアカウントで複数種類の問題が起きる可能性もあります。

利用枠が残っているかは、専用画面で見る

OpenAIの料金・利用枠ガイドは、使用状況ダッシュボードで現在の上限を確認するよう案内しています。Codex CLIの実行中なら/statusも使えます。発生直後に確認すれば、その時点の残量とエラーを比較しやすくなります。

また、公式ガイドでは、処理中に利用上限へ達しても、その処理は公平利用の制約の下で継続できると説明しています。したがって「途中にエラーがあったが、その後完成報告が出た」だけでは、上限到達の有無は判定できません。反対に、枠が十分残っていてもサービス側の障害は起こり得ます。プラン内の枠と追加クレジットの仕組みは、ChatGPT Proのプラン比較で整理しています。

401は、まず認証方式を確認する

Codexの認証ガイドは、ChatGPTでのログインとAPIキーでのログインを分けています。デスクトップアプリではプロフィールメニューでアクティブなアカウントやAPIキーの状態を確認できます。CLIではcodex login statusを使います。

ChatGPTでログインしているのに「Incorrect API key」と出たとしても、画面だけから利用者が誤ったキーを設定したとは特定できません。どの認証情報が拒否されたのかは別途確認が必要です。容量エラーの対策として、いきなりサインアウトや認証ファイルの削除へ進む必要はありません。APIキーで利用する場合は、ChatGPTの契約とは別にAPIの標準料金が適用されます。

thread not foundが出ている場合は、Codexの「thread not found」の調査と対処を参照してください。同じPCで過去に認証やチャットのエラーが起きたというだけでは、今回の容量エラーとの因果関係は分かりません。

APIの503と、アプリの表示は分けて考える

OpenAI APIのエラーコードガイドには、モデルの一時的な過負荷を示すHTTP 503、service_unavailable_error、server_is_overloadedの説明があります。429にはリクエスト頻度や利用限度に関するエラー、401には認証エラーがあります。

作業を戻すための手順

以下は、公式の障害記録・利用枠ガイド・一般的なトラブルシューティングを踏まえた推奨手順です。このエラー専用の、必ず直る操作として公表されたものではありません。

1．依頼文と、最後に済んだ作業を残す

送信前の入力文が残っていればコピーし、最後の完了報告や変更ファイルの状態を保存します。エラーの後にチャットを閉じたり作り直したりする前に、「何を依頼したか」「どこまで終わったか」を残すと再開が楽です。

エラー表示だけでは、ファイル編集やコマンドが全く実行されなかったとは判断できません。Gitを使う開発なら、差分表示やgit statusで状態を確認してから、同じ変更をもう一度依頼します。公開・送信・購入などを含む仕事は、結果を確認せず同じ指示を繰り返さないようにします。

2．少し待ち、公式ステータスを見る

OpenAI Statusを開き、Codexやモデル選択に関係する障害がないか確認します。現在の表示だけでなく、エラーが出た時刻と障害の時間帯が合うかも見ます。過去に同名の障害があることと、今その障害が続いていることは別です。

APIの過負荷について公式は、Retry-Afterがあれば指定以上待ち、なければ再試行の間隔を延ばすよう案内しています。アプリ画面に待ち時間が出ない場合に、利用者が守るべき固定秒数は確認できませんでした。短い間隔で何度も送るより、少し待ってから再試行するのが本記事の推奨です。障害が掲載されている間は、公式の復旧情報を参考にします。

ステータスページは全体を集計した情報です。個別のアカウントやモデルの状況と完全に一致するとは限りません。「障害が載っていないから自分のPCが壊れている」とは判断しないでください。

3．使用状況を確認し、急ぐなら別モデルを検討する

残量とリセット時刻を確認し、上限到達が明示されていれば、その案内に沿って判断します。容量エラーしか出ていない段階で、追加クレジットや有料リセットを買うことを復旧手段にはしません。自分の利用枠を回復する仕組みと、モデルがリクエストを受け付けられるかは別の問題です。

公式のモデル選択ガイドでは、デスクトップアプリの入力欄下にあるモデル・推論量のコントロールで変更できます。対話式CLIでは/modelを使います。選べるモデルはアカウントやクライアントなどによって異なるため、画面にないモデルが使える前提にはしません。

別モデルを選ぶと、回答の性質や利用量も変わります。「容量エラーを避けるには常に最上位モデルへ」という根拠はありません。複雑な実装や設計を引き継ぐ場合は、変更後の出力を差分とテストで確認します。選択の目安は、GPT Solの世代比較と使い分けも参考にしてください。

4．アプリ自体が固まっている場合だけ、状態を切り分ける

容量エラーが出ることと、アプリの入力・端末・画面が反応しないことは区別します。公式のトラブルシューティングは、止まったように見えるチャットについて、承認待ちの確認、基本的なコマンドでの端末確認、小さな依頼での新規チャットを案内しています。

端末が引き続き固まる場合は、進行中のチャットが完了するのを待ってからアプリを再起動する案内があります。これは一般的な停止状態への対処で、サーバー側の容量不足を再起動で解消できるという説明ではありません。ほかのチャットが動いている場合は、先にその状態を確認します。

新規チャットで再開するなら、目的・作業フォルダ・済んだ変更・未完了項目を短く引き継ぎます。過去の会話が全て伝わる前提で「続きだけ」と送らないようにします。新規チャットも同じサービスを利用するため、容量エラーが必ず避けられるわけではありません。

再発したときに残す情報

再発した場合は、後から原因を調べられる形で証拠を残します。設定を何度も変える前に記録すると、どの条件で失敗したかが分かりやすくなります。

「設定で選んだモデル」と「実際に失敗したリクエストで使われたモデル」は、記録によっては一致を確認できません。画面の設定だけを記録したなら、その範囲で説明します。モデル変更の直後に直った場合も、同時にサービスが復旧した可能性があるため、変更が原因で直ったとは断定しません。

公式ガイドは、メッセージ入力欄で/を入力してフィードバックを送る方法を案内しています。既存のチャットから送る場合は、会話を共有するか選べます。送るログ・スクリーンショットから、APIキー、メールアドレス、私的な会話、社内情報を除いてください。キーの値や認証ファイルそのものを公開する必要はありません。

報告は「何回も壊れる」だけでなく、「この日時に、このモデルで、この文言が出て、残量はこの表示だった」と書くと調査しやすくなります。通信コードやリクエストIDが取得できた場合はサポートへ伝える材料になりますが、取得していなければ推測で補いません。

端末で調べた結果と、特定できなかったこと

AI Arteでは、利用者から同じエラーが繰り返し出るとの画面報告を受け、2026年10月1日に、この端末のCodexが読み取り専用で利用状況とローカルログを調査しました。Windowsのアプリのパッケージ版は26.928.3736.0でした。エラー発生時も同じ版だったとは確認していません。

9月29日0時（JST）以降のログDBの32,737レコードと、9月29日〜10月1日のデスクトップログ15ファイルを対象に、容量エラーの原文や関連するエラー名を検索しました。該当する容量エラーは見つかりませんでした。更新されたセッション記録143ファイルも補助的に確認しましたが、検索対象のエラーイベントはありませんでした。

ログで見つからないことは、エラーが起きなかった証拠にはなりません。アプリの表示が同じ形式で保存される保証はなく、保存範囲や別の記録経路の可能性があります。また、後から週間枠が31％残っていると分かっても、失敗した瞬間の残量は復元できません。今回は「個別の原因は未特定」が結論です。

この調査では、モデル変更・契約変更・リセット券使用・認証情報の削除は実施していません。意図的にリクエストを連打する再現試験もしていないため、どの操作で復旧するかを比較した実験結果はありません。公式に確認できた障害事例と、この1端末での観測を分けて掲載しています。

まとめ：エラーの種類を見てから対処する

「Selected model is at capacity」が出たら、依頼文を保存し、少し待って、障害情報と使用状況を確認する。急ぐ場合は利用可能な別モデルを検討できますが、複数モデルで発生する障害もあります。容量エラーだけを理由に、課金・有料リセット・認証情報の削除へ進む根拠はありません。

401なら認証、thread not foundならチャットの状態、上限の案内なら使用状況へと、確認先を分けます。再発時に日時・全文・モデル・残量を残せば、原因不明のまま設定を変更するより、次の調査に役立ちます。

よくある質問

Proを契約していても、このエラーは出ますか？

本記事の利用者はPro契約で同じ表示を報告しています。ただし1件の報告からプランごとの発生率は分かりません。公式の障害記録も、Proが対象外であるとは説明していません。契約の利用枠が残っていることと、モデルがその瞬間に処理を受け付けられることは分けて確認してください。

クレジット追加や有料リセットで直せますか？

この容量エラーをそれらの操作で解消できるという公式の根拠は確認できませんでした。追加クレジットなどは自分の利用枠に関する仕組みです。まず使用状況で本当に上限へ達しているかを確認し、容量エラーの復旧と混同しないでください。

別モデルに変えても出るのはなぜですか？

公式には、複数モデルで同じ文言が出た障害事例があります。別モデルでも出ること自体は、PCやアカウントの故障を証明しません。障害情報と残量を確認し、再試行の結果を記録します。どのモデルなら必ず回避できるかは公表資料から確定できません。

アプリを再起動したり、新しいチャットにすべきですか？

必須とは確認できません。アプリや端末自体が固まる場合の状態切り分けには使えますが、サービス側の容量問題を解消する保証はありません。ほかの進行中の作業を確認し、依頼文・変更内容・未完了項目を残してから判断してください。