2025 年 9 月、OpenAI は、エージェント型コーディング向けに最適化した初の GPT-5 として、GPT-5-Codex を発表しました。同年 12 月に 5.2 をリリースすると、自律型コーディングエージェントに安心して作業を任せられると考える人が増え始めました。特に大きく伸びたのは、モデルが指示に沿って確実に作業を続けられる時間です。
私は、その限界を試してみたいと思いました。そこで、Codex に空のリポジトリとフルアクセスを与え、デザインツールをゼロから作るという仕事を 1 つだけ任せました。モデルには GPT-5.3-Codex を使い、推論強度を「超高」に設定しました。Codex は約 25 時間連続で稼働し、約 1,300 万トークンを使って約 3 万行のコードを生成しました。
今回は実験で、本番環境への導入ではありません。それでも、仕様に従い、目標からそれずに作業を続け、検証を行い、問題が起きるたびに修正するという、長時間の作業で重要な点では良い結果が得られました。
Codex の長時間セッションの様子
Codex に、セッションのデータをまとめたページを作ってもらいました。
こちらは、CLI で確認したセッションの統計とトークン使用量です。
これらの画面から、エージェント型コーディングで何が変わりつつあるかが見えてきます。ワンショットでどれだけの能力を発揮できるかに加え、どれほど長い時間軸で仕事を任せられるかが、ますます重要になっています。
大きく変わった作業の時間軸
単に「モデルが賢くなった」という話ではありません。実務上の変化は、エージェントが長時間にわたって一貫した方針で作業し、より大きな仕事を最初から最後までやり遂げ、エラーが起きてもそれまでの経緯を見失わずに立て直せるようになったことです。
この傾向を捉えるのに役立つのが、METR による時間軸のベンチマークです。フロンティアエージェントが約 50% の成功率で完了できるソフトウェアタスクの長さも、80% の成功率で完了できるタスクの長さも急速に伸びており、およそ 7 か月で倍増しています。詳しくは、長時間タスクを完了する AI の能力を測る（METR）をご覧ください。
先日の GPT-5.3-Codex のリリース発表で紹介したように、エージェントに作業を任せるうえで、さらに 2 つの点が改善しました。
- 複数の工程を順に進める能力が向上しました（計画 → 実装 → 検証 → 修正）。
- 実行中に軌道修正しやすくなりました。それまでの進捗を保ったまま指示を出せるため、最初からやり直す必要がありません。
長時間稼働する自律型コーディングシステムについて Cursor が公開した記事からも着想を得ました。ブラウザを開発した実験については、Cursor はどのようにウェブブラウザを構築したか（エージェントのスケーリング）で紹介されています。
Cursor チームは、OpenAI のモデルについて「長時間の自律的な作業に格段に強い。指示に従い、集中を保ち、方向性を見失わず、求められたものを正確に最後まで実装できる」と述べています。
Codex が長時間のタスクでも一貫性を保てる理由
長時間の作業では、巨大なプロンプトを 1 つ用意することよりも、モデルがどのような手順を繰り返して作業するか、つまりエージェントループのほうが重要です。
Codex のループは、おおむね次のように進みます。
- 計画を立てる
- コードを編集する
- ツールを実行する（テスト、ビルド、lint）
- 結果を確認する
- 問題を修正する
- ドキュメントと進捗状況を更新する
- 以上を繰り返す
このループが重要なのは、次のことが可能になるからです。
- エージェントが実際の結果からフィードバックを得る（エラー、差分、ログ）
- 作業状態をモデルの外に記録する（リポジトリ、ファイル、ドキュメント、Worktree、出力）
- 作業の途中でも方向を調整する（結果を見ながら軌道修正できる）
Codex モデルを汎用のチャット画面よりも Codex 専用の環境で使うほうが、作業を任せやすく感じるのもこのためです。ハーネスが構造化されたコンテキスト（リポジトリのメタデータ、ファイルツリー、差分、コマンド出力）を提供し、作業を終える前に完了条件を確認する手順を徹底します。
Codex のエージェントループの仕組みについては、先日公開した記事で詳しく説明しています。
さらに、このループを日々の開発に取り入れられるよう、次の機能を備えた Codex App をリリースしました。
- 複数のプロジェクトでスレッドを並行実行（長時間の作業を任せながら、普段の仕事を進められる）
- スキル（計画、実装、テスト、報告の手順を標準化できる）
- オートメーション（定型作業をバックグラウンドで実行できる）
- Git Worktree（実行ごとに作業環境を分け、差分をレビューしやすくし、手戻りを減らせる）
実験の設定
この実験の題材にデザインツールを選んだのは、実装の良し悪しがはっきり表れるからです。UI、データモデル、編集操作を組み合わせ、多くの境界ケースにも対応する必要があります。ごまかしは利きません。アーキテクチャに無理があれば、すぐに破綻します。
GPT-5.3-Codex に詳細な仕様を渡し、推論強度を「超高」に設定しました。モデルは約 25 時間にわたって中断することなく、一貫した方針で作業を続け、質の高いコードを仕上げました。また、マイルストーンを完了するたびに、テスト、lint、型チェックによる検証も行いました。
プロジェクトの記録を残す仕組み
最も重要な工夫は、プロジェクトの情報を後から何度でも参照できる形で残したことです。仕様、計画、制約、進捗状況を Markdown ファイルに書いておき、Codex が繰り返し読み返せるようにしました。これで作業の方向がずれるのを防ぎ、「何をもって完了とするか」という基準も一定に保てました。
以下のリンクからリポジトリ内の各ファイルを参照できます。それぞれの役割は次のとおりです。
Prompt.md（仕様と成果物）
目標をあらかじめ固定し、エージェントが「見栄えはよくても、求めていたものとは違うもの」を作ってしまうのを防ぎます。
主な記載内容は次のとおりです。
- 目標と対象外の事項
- 必ず守る制約（パフォーマンス、決定性、UX、プラットフォーム）
- 成果物（完了時にそろっているべきもの）
- 完了条件（確認項目とデモの手順）
最初のプロンプトでは、プロンプトと仕様を記載したファイルをプロジェクト全体の仕様書として扱い、マイルストーンごとの計画を立てるよう Codex に指示しました。
Plan.md（マイルストーンと検証）
進め方に自由度のある仕事を、エージェントが一段階ずつ完了して検証できるように区切ります。
主な記載内容は次のとおりです。
- ループ 1 回で完了できる規模のマイルストーン
- マイルストーンごとの受け入れ基準と検証コマンド
- 検証に失敗したら、先に進む前に立ち止まって修正するルール
- 同じ判断を何度も覆さないための決定事項の記録
- コードベースで目指すアーキテクチャ
最近、Codex App、CLI、IDE 拡張機能にプランモードを追加しました。変更を加える前に、大きなタスクをレビューしやすい一連の手順に分けられるので、あらかじめ進め方をすり合わせられます。確認が必要な点があれば、Codex が追加の質問をします。プランモードを有効にするには、スラッシュコマンド /plan を使用します。
Implement.md（計画に沿った作業手順）
このファイルは作業手順書です。計画に従い、変更を必要な範囲に絞り、検証を実行し、ドキュメントを更新するという進め方を Codex に具体的に指示します。
主な記載内容は次のとおりです。
- 各マイルストーンでは、計画を記載した Markdown ファイルを正とする
- マイルストーンごとに検証を実行する（失敗したらすぐに修正する）
- 差分を必要な範囲に絞る（作業範囲を広げない）
- 記録用の Markdown ファイルを随時更新する
Documentation.md（開発中の進捗と決定事項）
このファイルは、私と Codex が共有する記録であり、作業を後からたどるための監査ログでもあります。何時間か席を外しても、戻ってきたときに何が起きたかを把握できます。
主な記載内容は次のとおりです。
- 現在のマイルストーンの進捗状況（完了した作業と次の作業）
- 決定事項とその理由
- 実行方法とデモの手順（コマンドと簡単なスモークテスト）
- 既知の問題と今後の対応事項
実際に Codex がマイルストーンごとに検証を行った様子がこちらです。
マイルストーンごとの検証
Codex はコードを書くだけで終わらず、マイルストーンごとに検証コマンドを実行しました。検証に失敗した場合は、問題を修正してから次に進みました。
品質を確認するために実行するよう指示したコマンドの例です。
こちらは、lint に失敗した後に Codex が問題を修正した例です。
エージェントが作ったデザインツール
完成したツールには改善の余地があり、そのまま本番で使える段階ではありませんでしたが、実際に動かしてテストできるものでした。今回の基準は「コンパイルが通るか」ではなく、「指示どおりに実装され、実際に動作するか」です。
実装した主な機能は次のとおりです。
- キャンバス上での編集（フレーム、グループ、図形、テキスト、画像やアイコン、ボタン、グラフ）
- リアルタイムの共同編集（参加状況、カーソル、選択範囲、編集内容をタブ間で同期）
- インスペクターでの調整（位置やサイズ、スタイル、テキスト）
- レイヤー管理（検索、名前の変更、ロックや非表示、並べ替え）
- ガイド、整列、スナップ
- 履歴のスナップショットと復元
- タイムラインでの操作の再生と、過去の時点からの分岐
- プロトタイプモード（ホットスポットと画面フローに沿った移動）
- コメント（スレッドをピン留めし、解決済みにしたり再開したりできる）
- エクスポート（保存、インポート、エクスポートに加え、CLI から JSON 形式や React と Tailwind を使ったコードとして書き出し）
Codex に長時間タスクを任せるための要点
今回の実行を支えたのは、巧妙なプロンプトを 1 つ書いたことではなく、次の要素を組み合わせたことです。
- 明確な目標と制約（仕様ファイル）
- マイルストーンごとの確認と受け入れ基準（
plans.md） - エージェントの作業手順書（
implement.md） - 継続的な検証（テスト、lint、型チェック、ビルド）
- 進捗や作業内容をいつでも確認できるよう、随時更新する監査ログ（
documentation.md）
長時間にわたるコーディングは、逐一見守る必要を減らし、制約や確認手順を設けたうえで、より多くの作業を任せる方向へ進んでいます。
自分の長時間タスクでの Codex の活用
今回の 25 時間の実験から、これからのソフトウェア開発の姿が見えてきます。プロンプトを 1 回入力して答えを得たり、ペアプログラミングで細かくやり取りしたりする段階を越え、まとまった仕事を最初から最後までチームメイトに任せられるようになりつつあります。コードを 1 行ずつ指示する代わりに、マイルストーンごとに方向を調整できます。
Codex が目指す方向は明快です。チームメイトとしての能力を高め、実際の開発現場のコンテキストをより深く取り込み、安心して作業を任せ、成果をレビューしてリリースしやすくするための仕組みを整えます。定型的な実装と検証をエージェントが引き受けることで、開発が速くなる例はすでに見られます。開発者は、設計、アーキテクチャ、プロダクトに関する意思決定、定石のない新たな問題など、人の判断が特に重要な仕事に時間を使えるようになります。
こうした変化は開発者だけにとどまりません。Codex が意図をより正確にくみ取り、安全に作業を進めるための仕組み（計画、検証、プレビュー、ロールバック）が充実すれば、開発者以外の人も、IDE を常に開いていなくても、自分で作って改善を重ねられるようになります。Codex の各利用環境やモデルは今後も進化しますが、目標は一貫しています。つきっきりで見守るツールから、長時間の仕事を安心して任せられるチームメイトへと近づけることです。
ご自身のタスクで試すには、まず次のドキュメントをご覧ください。