最近、Codexに開発作業を依頼しても、最後まで完了せずに終了することが増えた。残りの作業を認識しているように見えても、そこで処理を終えてしまう。再指示して続きを実行させ、もう一度レビューする機会が増えている。

以前から、Claude Codeと比べるとCodexは大規模開発で設計や実装について指摘することが多い印象はあった。それでも、時間をかけて作業を進めてもらうことはできていた。最近は、実装内容をレビューする以前に、依頼した仕事が最後まで実行されたかを確認する必要がある。

私が深刻だと感じているのは料金やコード生成品質よりも、人間の介入時間だ。AIに仕事を任せているのに、作業の進行確認、再指示、再試行に費やす時間が増えている。

この問題は自分の環境だけで起きているのか。2026年10月18日時点の公開GitHub Issueとコミュニティの報告を調べた。

GitHubには作業の途中終了を報告するIssueが複数ある

2026年9月29日のIssue #49390では、Codex Desktopを使用する開発者が、調査・実装・テストまで続けるよう指示しても、中間作業を終えた段階でターンが終了する問題を報告している。残作業があることをCodexが説明しても、そこで止まってしまう。

10月4日のIssue #50771には、作業を続けると説明したまま次の操作を行わず終了する事例がある。モデルや実行環境の異なる報告も寄せられ、記録の一部ではコンテキスト上限や実行エラーが発生していない。

10月7日のIssue #51552では、macOS上のCodex CLI 0.160.0とGPT-6 Lunaを使い、Pythonコード修正10種類を各10回、計100回実行している。96回は成功したが、4回はファイルを変更せずにexit 0で終了した。うち3回は変更を完了したと報告している。

この数字は提示されたタスクと環境での結果であり、Codex全体の失敗率ではない。それでも、実装を実行しないまま正常終了することがあるという具体的な記録だ。

実行環境や作業内容は異なるが、依頼された完了条件に到達する前に処理が終了するという問題は共通している。

Redditでも実用性への不満が反響を集めている

9月にr/codexへ投稿された「Codex is done」は、多くの賛同を集めた。投稿者は長時間の実行と利用枠の消費に対し、十分な成果が得られなかったと訴えている。コメント欄には途中終了や作業未完了の報告も寄せられている。

9月22日のr/OpenaiCodexには、直近数日でCodexが作業の途中で頻繁に止まるようになったという投稿がある。

OpenAI Developer Communityでも9月21日、前週まで完了できていた定型レポートの作成を、同じモデルで6回試しても完了できず、利用者が手作業で仕上げたという報告がある。これはコード修正とは異なる作業だが、最後まで実行できないことで人間の作業が増えた例だ。

複数の公開投稿で同様の問題が話題になっている。ただし、投稿への賛同やコメント数を実際の発生率として扱うことはできない。異なるモデルや環境で起きた現象が、すべて同じ原因とも限らない。

自分の作業でも完了確認と再指示が増えている

私の環境でも、実装範囲と完了条件を伝えた作業が、部分的な成果を残した段階で終了することがある。残りの作業を改めて指定し、追加実装のあとにもう一度全体を確認する。実装している時間だけでなく、完了したかどうかの確認にも手間がかかるようになった。

自作のagentオーケストレーターを通してCodexを実行しているため、個々の終了がモデル自身の判断によるものか、実行環境の制御によるものかは切り分けが必要だ。実際に編集したファイルをrevertしてexit 0で終了した事例と、その際の成功判定については別の記事に記録している。

28日間の改善と利用上限リセット

OpenAIでCodexの開発を率いるThibault Sottiaux氏は10月4日、今後28日間は毎日、CodexやChatGPT Workの多くの利用者に関係する改善を提供するか、利用上限を全面的にリセットすると発表した。期間は米国時間の10月5日から11月1日までとされ、実際に複数回のリセットが行われている。

私の利用枠も10月16日と18日にリセットされた。回数だけを見れば利用者への還元だが、その一方で作業の途中終了や未完了が続いている。利用枠が増えても、同じ仕事を何度も依頼し直す必要があれば、開発に使える時間が増えるわけではない。

28日間の集中改善という取り組みは、積極的な開発として受け取ることもできる。しかし現在の挙動を見ていると、変更を急いで投入し、利用者が実際の仕事で問題を発見して、次の改善につなげているように感じる。私自身も、有料で利用しながらベータテストをしている気分だ。

似た問題意識はコミュニティにもある。Redditでは、利用枠のリセットより作業が完了することを重視し、仮にA/Bテストを行うなら参加者への説明や選択肢が必要だという意見が出ている。また、不具合による利用枠の消費について、利用者が実質的なベータテスターや利用データの提供者になっていると指摘する声もあった。

OpenAIが社内でどのようなテストを行い、どの程度の回帰を把握しているかは公表されていない。少なくとも、依頼された作業を最後まで進めるという基本的な品質について、公開後も複数の問題報告が続いている。利用者が毎回結果を調べ、失敗を再現し、回避策を探さなければならない状況では、事前の品質検証が十分に機能しているとは感じられない。

ユーザーはデバッガーではない。

利用者からのフィードバックを改善に役立てること自体は自然だと思う。ただ、仕事を任せるために料金を払っている利用者に、不具合の発見や再現、変更の影響確認まで継続的に担わせるのは違う。改善を頻繁に提供するのであれば、既存の作業が以前どおり完了することも品質として守ってほしい。

再指示とレビューの増加が、開発の時間を奪っている

下位モデルは設計やコード品質で上位モデルに劣る場合がある。それでも時間をかけて作業が完了するなら、どのモデルに何を任せるかを調整できる。最近のLunaでは簡単なスクリプトのコード生成品質も以前よりよくなったと感じている。

ところが途中終了が頻発すると、コードをレビューする前から利用者の作業が増える。成果物を確認し、不足分を指示し、再実行後に同じ完了条件を確かめなければならない。正常終了したという表示や、作業したという最終メッセージだけでは任せきれない。

コミュニティには、自動継続ツール、チェックリスト、新規セッション、作業の細分化などの提案がある。ただし実行環境やタスクが異なり、完遂率の改善を確認できる検証結果は限られている。

私自身も作業を小分けにして進めている。中断後に残作業を渡し直しやすくなる反面、分割・進行確認・統合の作業は人間側に戻ってくる。自動で継続指示を送り直しても、同じ失敗を繰り返す場合には完成しない。

現時点では確実な解消方法は確認できていない。上位モデルへ変更すれば解決するかについても、同じタスクと実行環境での比較が必要だ。

Codexに任せたいのは、実装途中の報告を受け取ることではなく、指定した仕事を最後まで進めてもらうことだ。以前より多くの再指示とレビューが必要な現状は、コーディングエージェントを使う利点そのものに影響している。