2025 年 9 月、OpenAI はエージェント型コーディングに最適化した初の GPT-5 として、GPT-5-Codex を発表しました。2025 年 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 はコードを書いて、動くことを祈るだけではありませんでした。各マイルストーンの完了後に検証コマンドを実行し、失敗した箇所を修正してから先に進みました。
使用するよう指示した品質確認用コマンドの例を示します。
こちらは、lint の失敗を受けて Codex が問題を修正した例です。
エージェントの成果物
成果物は完璧でも、そのまま本番で使えるものでもありませんでしたが、実体があり、テストできるものでした。今回の実行での合格基準は「コンパイルが通るか」ではなく、「指示に従っているか、実際に動くか」でした。
実装された主な機能：
- canvas の編集（フレーム、グループ、図形、テキスト、画像・アイコン、ボタン、グラフ）
- リアルタイムの共同作業（参加状況、カーソル、選択範囲、編集内容をタブ間で同期）
- インスペクターでの調整（位置や寸法、スタイル、テキスト）
- レイヤー管理（検索、名前の変更、ロック・非表示、並べ替え）
- ガイド・整列・スナップ
- 履歴のスナップショットと復元
- タイムラインの再生と過去の時点からの分岐
- プロトタイプモード（ホットスポットとフロー内の画面遷移）
- コメント（ピン留めしたスレッドの解決・再オープン）
- エクスポート（保存・インポート・エクスポートと、CLI による JSON および React + Tailwind へのエクスポート）
Codex で長時間タスクに取り組むための要点
今回の実行を成功させたのは、巧妙なプロンプトを 1 つ用意したことではありません。次の要素を組み合わせたことでした。
- 明確な目標と制約（仕様ファイル）
- 受け入れ基準とチェックポイントを設けたマイルストーン（
plans.md） - エージェントの作業方法を定めた手順書（
implement.md） - 継続的な検証（テスト・lint・型チェック・ビルド）
- 実行状況をいつでも確認できるよう、随時更新する進捗・監査ログ（
documentation.md）
長時間にわたるコーディング作業は、つきっきりで見守る場面を減らし、ガードレールを設けてより多くを任せる方向へと進んでいます。
自分の長時間タスクで Codex を試す
今回の 25 時間にわたる Codex の実行は、コードによるものづくりの未来を垣間見せてくれます。単発のプロンプトや密接なやり取りを繰り返すペアプログラミングを超え、まとまった実作業を最初から最後まで担える、長時間働くチームメイトへと進化しつつあります。人間はコードを 1 行ずつ細かく管理する代わりに、マイルストーンごとに方向を示します。
私たちが Codex で目指す方向はシンプルです。チームメイトとしての能力を高め、実際の作業コンテキストとの連携を深め、信頼でき、レビューしやすく、リリースしやすい成果につながるガードレールを整えます。エージェントが定型的な実装と検証を引き受けることで、開発者の作業が速くなる例はすでに見られています。その分、人間はデザイン、アーキテクチャ、プロダクトに関する判断、そして定型的な解法のない新たな問題といった、特に重要な部分に集中できます。
この変化は開発者だけにとどまりません。Codex が意図を捉える力をさらに高め、安全に作業を進めるための仕組み（計画、検証、プレビュー、ロールバック）を充実させるにつれ、開発者ではない人も、より多くの人が IDE にかかりきりになることなく、ものを作り、改善を重ねられるようになります。Codex の各インターフェースやモデルでは今後も機能を拡充していきますが、目指すものは変わりません。エージェントを、つきっきりで見守る必要のあるツールから、長時間の仕事を安心して任せられるチームメイトへと近づけることです。
自分でも試してみたい方は、次のページから始めてください。