Codexタスク作成エラーの原因と再試行・Windows対応方法

Codexタスク作成エラーを最初に分類する

「タスクを作成できませんでした」という表示は、Codexが依頼を受け取る前に止まった場合にも、依頼を受け取った後に処理場所を準備できなかった場合にも使われます。最初の一文だけを手掛かりにすると、サインインの問題とフォルダーの問題、利用枠の問題を同じ設定変更で直そうとしてしまいます。まず、エラーが表示された画面、押したボタンや入力したコマンド、作成操作の直前に選んだ項目を記録してください。

Codexは、ChatGPTのデスクトップアプリ、Codex CLI、IDE拡張、Webやクラウドの画面など複数の入口から利用できます。公式ヘルプも、WindowsでのCLI診断、リモート操作、WSLディストリビューションの選択を別々の機能として説明しています。つまり同じアカウントでも、端末上の処理と遠隔側の処理は、失敗する場所も確認する情報も同じではありません。出典 URL: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

「作成できない」と「作成中に止まる」を分ける

作成ボタンを押した直後にエラーが出るなら、ログイン状態、対象のワークスペース、利用権限、入力値の不足を先に見ます。モデルやフォルダーを選んだ直後なら、その選択肢が現在の入口で利用できるか、対象場所を読み取れるかを確認します。まだ処理が始まっていない段階で、長い依頼文やコードの品質を疑う必要はありません。

一度タスクが作られたように見えてから「作成中」の表示で止まるなら、処理先の準備、通信、利用枠、サービスの状態が候補になります。画面を閉じて何度も押す前に、タスク名、発生時刻、表示された状態、同じ状態が続いている時間を残します。再現条件が分かれば、入口を変えた結果との違いも比較できます。

ローカル、クラウド、APIの境界を分ける

端末上のCodexは、指定したフォルダー、端末の設定、ローカルの認証状態、利用しているCLIや拡張の版の影響を受けます。一方で、クラウドに委ねた処理は、遠隔の作業場所、タスクの状態、結果を表示する画面の状態を確認する必要があります。同じ「Codexタスク」という呼び方でも、どこでコードを読んでいるかを先に分けてください。

2026年9月10日に発表されたAgents APIは、Codexを支える仕組みを開発者向けに公開ベータとして提供するものです。手元のCLIやデスクトップ画面をそのままAPIで表示する機能ではなく、セッション、ツール、実行環境を組み合わせてエージェントを利用する別の入口です。APIの応答を見ているのに、手元のCodexの設定だけを変更する、といった取り違えを防げます。出典 URL: https://openai.com/index/introducing-the-agents-api/

なぜ今、Codexタスクの確認順を見直すのか

今回このKWを確認する理由は、Codexの利用方法が増え、同じ名前の処理でも見るべき状態が広がっているためです。OpenAIの公式ヘルプは現在、CodexをChatGPTの各プランで利用できること、プランごとに利用上限が異なること、WindowsではCodex Doctorを使えることを案内しています。タスク作成の失敗を単なるインストール不良と決めつけると、使用量やアカウント側の表示を見落とします。

また、2026年9月10日のAgents API公開ベータでは、Codexのような長い作業を支えるセッション管理、文脈の整理、復旧、ツールや実行環境の扱いが開発者向けに説明されました。9月22日のAPI更新ではGPT-6 SolとGPT-6 Lunaも公開されていますが、APIのモデル一覧に現れることと、ChatGPTにサインインしたCodexの画面で選べることは同じではありません。入口と契約、クライアントの版を分けて見る必要があります。出典 URL: https://developers.openai.com/api/docs/changelog

公式ヘルプには、ChatGPTアカウントでCodexを使う場合のモデル変更も記載されています。2026年8月31日以降、該当するCodexの入口ではGPT-5.4とGPT-5.4 miniが使えず、GPT-5.6 TerraとGPT-5.6 Lunaへ置き換える案内があります。モデルを固定した設定を持つ利用者は、タスク作成時に選択欄へ何が表示されるかを確認し、古いモデル名が残っていないかを見てください。出典 URL: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

公式情報と手元の症状を分けて読む

公式ページが示すのは、利用できる入口、診断方法、プランやモデルの扱い、公開された更新です。実際に自分の画面で起きたエラーの原因まで公式ページが断定しているとは限りません。たとえば新しいモデルが公開された日と、自分の画面で古いモデルを選べない日が近くても、それだけで同じ更新が原因とは言えません。版、画面、時刻、操作を別々に記録します。

逆に、手元の印象だけで「サーバーが落ちている」「Windowsだけの不具合だ」と決めるのも早すぎます。公式の利用状況画面、リリース情報、サービス状態、エラーコードを照合し、確実に分かる事実と推測を分けてください。分からない部分を残したままでも、確認の順番が正しければ次に見るべき場所は狭められます。

作成前に残すべき四つの情報

エラー調査では、再現操作を増やす前に記録を作ることが重要です。次の四項目があれば、入口の違い、更新前後、利用枠の状態、対象場所の違いを比較できます。画面のスクリーンショットを残す場合も、不要なコードや個人情報を広く写さず、エラー文、時刻、入口、版番号が分かる範囲に絞ります。

この記録は、サポートへ問い合わせるときだけでなく、自分で再試行するときにも役立ちます。設定を変えた後に直ったとしても、どの変更が効いたのかを残さなければ、次に同じ問題が出たときにまた最初からやり直すことになります。最初の失敗時点の情報を保存し、変更後の情報を別に記録してください。

Codexタスク作成エラーの確認手順

ここでは、作成操作の直前から、短い再試行とAPI側の状態確認までを順番に進めます。途中で原因が分かっても、複数の設定をまとめて変えず、変更した項目と結果を記録してください。目的は、何となく直った状態を作ることではなく、次に同じ表示が出たときに、どの入口のどの状態を見ればよいかを残すことです。

最初の確認は読み取り中心にし、ファイルの変更や権限の拡大は後ろへ回します。タスクが作られない段階では、依頼内容の品質よりも入口、アカウント、利用枠、モデル、対象場所のどこで準備が止まったかが重要です。順番を固定すると、Windowsの端末、WSL、クラウド、APIを行き来しても条件を比較できます。

Step 1: エラーが出た入口と直前の操作を固定する

まず「Codexで失敗した」と書かず、どの画面または端末で、何を選んだ直後に止まったかを具体化します。デスクトップならアプリの画面と選択したプロジェクト、CLIなら実行したコマンドと作業フォルダー、IDE拡張なら開いているワークスペース、Webやクラウドならタスクを送った画面を記録します。APIならリクエストの種類、返された状態、エラーコードを分けて残します。

同じ依頼を別の入口で試す場合も、最初の条件を変えすぎないでください。入口、モデル、対象フォルダー、依頼文を一度に変えると、作成できたとしても何が原因だったか判断できません。まずはエラー文を保存し、再試行の前に比較対象を一つだけ決めます。

Step 2: サインイン先と利用状況を確かめる

ChatGPTアカウントでCodexを使っている場合は、画面に表示されたアカウントとワークスペースが、普段の作業場所と同じかを確認します。複数のアカウントやワークスペースを切り替えた後は、見えているプロジェクトやモデルの候補が変わることがあります。ログインし直す前に、現在のアカウント名を記録し、別の場所へ意図せず切り替わっていないかを見てください。

タスク作成時に利用枠の表示が出る場合は、使用状況画面で消費した枠、残り、次のリセット時刻を確認します。CLIのセッションでは/statusを入力して状態を見られると公式ヘルプに案内されています。利用枠が原因なら、同じ操作を繰り返すより、表示されたリセット時刻を待つか、アカウントに表示された別の選択肢を確認する方が情報を増やせます。出典 URL: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

Step 3: WindowsではCodex DoctorとCLIの版を確認する

Windowsで起動、接続、処理速度の問題が疑われるときは、公式ヘルプが案内するcodex doctorを先に実行します。続けてcodex --versionを確認し、実際に呼び出されているCLIの版を残します。アプリを更新したつもりでも、端末のパスにあるCLIが別の版を指している場合があるため、アプリの表示だけで判断しないことが大切です。出典 URL: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

複数のWSLディストリビューションを使っているなら、Codexがどのディストリビューションを対象にしているかも確認します。Windowsの端末とWSLの端末では、同じプロジェクト名でもパス、ファイルの見え方、利用できるコマンドが変わることがあります。タスクを作る前に、対象フォルダーを読み取れる小さな確認を行い、Windows側とWSL側のどちらで失敗したのかを分けてください。

Step 4: モデルの候補とクライアントの版を照合する

モデルを選んだ直後にエラーが出る場合は、モデル名が表示されたことだけで利用可能だと判断しません。公式ヘルプには、Codex CLIやIDE拡張の既定モデルはクライアントの版と設定によって変わるとあります。選択したモデル名、Codexの版、サインイン方法を一組にして記録し、別のモデルを試す場合も変更は一つだけにします。出典 URL: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

API側でモデルを選ぶ場合は、APIのモデルカタログとCodexの画面を混同しないでください。9月のAPI更新で公開されたモデルが、すべてのChatGPTプランやすべてのCodexクライアントで同時に選べるという意味ではありません。公式のモデル資料と、実際の画面に表示される候補を別々に確認し、候補に出ないモデル名を設定へ無理に残さないことが安全です。出典 URL: https://developers.openai.com/api/docs/changelog

Step 5: 対象フォルダーとプロジェクトの指示を小さく確認する

フォルダーを指定した直後に止まるなら、まず読み取り可能な小さなプロジェクトで同じ操作を試します。深い階層、同期中の場所、移動したばかりのフォルダー、複数の環境から見える場所では、どのパスが実際の対象なのかを確認してください。タスク作成の失敗と、後でファイルを変更できない問題を同じものとして扱わず、最初にフォルダーを見つけられるかを切り分けます。

プロジェクト内にAGENTS.mdなどの指示ファイルがある場合は、内容が現在の入口に合っているかを確認します。古いパス、存在しないコマンド、利用できないモデル名が書かれていると、タスクの準備段階で矛盾が表面化することがあります。いったん説明を短くした検証用のプロジェクトで作成できるかを見て、元のプロジェクトだけで起きる問題かどうかを比べます。

Step 6: 依頼と対象を小さくして一度だけ再試行する

原因候補を記録したら、読み取り中心の短い依頼で一度だけ再試行します。たとえば「このフォルダーの構成を説明し、変更はしないでください」のように、結果を確認しやすい内容へ縮めます。大きな変更、複数のフォルダー、複数のモデルを同時に試すと、作成できた後の問題まで重なり、最初の失敗と比較できなくなります。

再試行では、モデルだけ、入口だけ、対象場所だけのいずれか一つを変えます。成功した場合は、成功した条件を記録してから元の条件へ一つずつ戻します。失敗した場合は、エラー文と時刻を更新し、同じボタンを何度も押すのを止めます。繰り返しは利用枠やサービス側の負荷を増やし、原因の手掛かりを薄くすることがあります。

Step 7: APIや遠隔処理ならエラーコードと状態を読む

Agents APIやAPI経由の処理でタスクを作っている場合は、Codex CLIの画面ではなく、APIが返したHTTP状態、エラーの種類、コード、リクエストの時刻を確認します。公式のエラーコード案内では、入力不備、認証、権限、利用上限、接続、サーバー側の問題が別の種類として整理されています。APIの返答にRetry-Afterが含まれる場合は、その時間を基準に待ち、短い間隔で繰り返さないようにします。出典 URL: https://developers.openai.com/api/docs/guides/error-codes

Agents APIは公開ベータのため、セッション、実行環境、ツール、結果の取得をそれぞれ確認します。自分のサービスから見て作成要求が届いているのか、セッションは作られたのか、処理先の環境が準備できたのか、結果を読み出す段階で止まったのかを分けてください。手元のCodexアプリを再起動しても、API側の状態は変わらないことがあります。出典 URL: https://developers.openai.com/api/docs/guides/agents-api/overview

エラー文から見る原因の候補

表示された文言は、そのまま検索するだけでなく、発生したタイミングと組み合わせて読みます。次の表は確定診断ではありませんが、最初に見る場所を決めるための地図になります。複数の症状が同時に出ている場合は、一番早く表示されたものから確認してください。

「権限がない」と見える場合でも、実際には別のアカウントや別の作業場所を選んでいることがあります。「モデルが使えない」と見える場合でも、クライアントの版が古い、プランで対象外、保存した設定が古い、という複数の候補があります。候補を一つずつ消し、直った時点の条件を残してください。

Windowsで起動前から止まる場合

タスク作成画面まで進めない場合は、タスクそのものより、Codexの起動や設定を先に見ます。公式ヘルプでは、Codex CLIからcodex doctorを実行して起動、接続、性能の診断を行えると案内されています。診断結果を保存し、codex --versionの出力と同じ記録へ並べれば、アプリとCLIの版が食い違っていないか確認できます。出典 URL: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

設定ファイルに古い承認ポリシーが残っている場合も、起動時のエラーがタスク作成エラーに見えることがあります。公式ヘルプはCodex CLI 0.149.0以降などでapproval_policy = "untrusted"がサポートされず、Windowsでは%USERPROFILE%\.codex\config.tomlを確認するよう説明しています。該当する表示がある場合だけ、古い行やプロファイル側の参照を確認し、変更後に再起動します。関係のない設定までまとめて消す必要はありません。出典 URL: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

WSLを使う場合は、インストールされているディストリビューションと、Codexが選んでいる対象をそろえます。Windows側のパスをWSLのパスとして入力したり、逆にWSLの場所をWindowsアプリへそのまま渡したりすると、存在しない場所として扱われることがあります。まず対象フォルダーを開けるか、構成を読み取れるかを確認し、ファイル変更の許可は最後に試してください。

再試行してよいケースと待つケース

ローカルのパス間違い、古いモデル名、選択中のアカウントの違い、未対応の設定が原因なら、原因を一つ直した後の再試行には意味があります。変更前の値を記録し、修正した値を一つだけ残し、短い依頼で確認します。成功したからといって、すぐ元の大きなタスクへ戻らず、対象範囲を少しずつ戻してください。

利用上限に達した、サービス側で処理が遅れている、APIが一時的な過負荷を返した、といった場合は、連続した再試行を避けます。公式のエラーコード案内は、急な通信量増加を示すslow_downや一時的な過負荷を示すserver_is_overloadedを区別し、Retry-Afterがあればその時間を待つよう案内しています。待つべき問題に設定変更を重ねると、原因が見えなくなります。出典 URL: https://developers.openai.com/api/docs/guides/error-codes

公式ヘルプでは、利用上限に達したとき、使用状況画面で消費した枠、クレジット残高、リセット時刻を確認するよう案内しています。サポートへ連絡しても利用上限を直接リセットできるわけではないため、表示された選択肢とリセット時刻を確認します。画面の数字が明らかに合わない、リセット時刻を過ぎても戻らない、といった場合は、入口、モデル、発生時刻、画面の表示を添えて問い合わせます。出典 URL: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

公式サポートへ伝える内容

自分で直せない場合も、「動きません」だけではなく、再現に必要な最小の情報をまとめます。最初に、デスクトップ、CLI、IDE、Web、クラウド、APIのどれで起きたかを書きます。次に、発生日時を日本時間で記録し、エラー文を省略せず、Codexの版、モデル、アカウントの種類、対象フォルダーの環境を添えます。Windowsならcodex doctorの結果、WSLを使ったか、設定ファイルに表示された警告があるかも役立ちます。

スクリーンショットを添付する場合は、プロジェクト名、個人名、メールアドレス、ファイルの中身など不要な情報を隠します。APIの場合は、公開してはいけない認証情報を貼らず、HTTP状態、エラーコード、発生時刻、利用したモデル、セッションの識別情報のうち共有できるものだけを示します。再現用の依頼文も、秘密の値を含まない短い内容へ置き換えてください。

公式ページで最後に照合する場所

Codexの一般的な利用方法とWindowsの診断はOpenAI Help Center、APIの新しいモデルやAgents APIの公開日はOpenAI Developersの更新情報、APIの失敗理由はエラーコード案内を見ます。第三者の投稿は症状の手掛かりになりますが、利用上限、モデルの提供対象、設定名の現在の扱いは公式ページで確認します。記事を読んだ時点で内容が変わっている可能性もあるため、ページの更新日と自分の発生日時を分けて残してください。

まとめ

Codexタスク作成エラーの確認は、再インストールから始めるのではなく、入口、アカウント、利用状況、モデル、対象フォルダー、処理先の順に切り分けます。Windowsではcodex doctor、codex --version、WSLの対象を確認し、CLIのセッションでは/statusで利用枠を照合します。APIや遠隔処理ではHTTP状態とエラーコードを見て、同じ画面の設定だけで直そうとしないことが重要です。

2026年9月のAgents API公開ベータやモデル更新によって、Codexに関係する入口と選択肢は増えています。だからこそ、エラー文、発生時刻、版、モデル、対象場所を一組の記録として残し、設定を一つだけ変えた短い再試行で結果を比べます。原因が利用枠や一時的な応答不良なら待ち、設定や場所の問題なら具体的な差分を直す。この境界を守ると、焦って条件を増やさず、次の確認へ進めます。