25時間走るCodex、鍵は4枚のMarkdownだった
OpenAIが2026年2月23日に公開したCodex実験で面白いのは、25時間・約1300万トークン・約3万行のコードという派手さだけではありません。空のリポジトリからデザインツールを作らせたこの実験では、Codexをただ長く回したのではなく、仕様、計画、実装ルール、進捗記録をMarkdownに外出しし、各マイルストーンで検証して直す運用を徹底していました。
主題は「25時間動いた」ことより「長く崩れない」こと
OpenAIのブログ記事では、Codexに空のリポジトリとフルアクセスを渡し、GPT-5.3-CodexをExtra High reasoningで約25時間連続実行したと説明しています。対象はUI、データモデル、編集操作、エッジケースが多いデザインツールで、途中の検証込みで約3万行のコードを生成しました。OpenAI自身もこれは本番導入ではなく実験だと明記していますが、重要なのは『長く動いた』より、『仕様に沿い、途中の失敗を直しながら、最後まで筋を保った』ことです。
記事の中で繰り返されるのは、エージェント的なコーディングの変化は一発の賢さではなく時間軸だという見方です。Codexは計画し、編集し、テストやビルドを回し、失敗を観測し、修復し、状態を更新してまた進む。この反復が続く限り、長時間タスクは『大きなプロンプト1発』ではなく、『検証付きの作業ループをどこまで維持できるか』の勝負になります。
4枚のMarkdownがCodexの外部記憶になった
この実験でいちばん実務的なのは、Codexの長時間実行を支えた中心がモデル内部の記憶ではなく、`prompt.md`、`plans.md`、`implement.md`、`documentation.md`の4ファイルだった点です。`prompt.md`は仕様と非目標、`plans.md`はマイルストーンと受け入れ条件、`implement.md`は実行手順、`documentation.md`は進捗と判断の監査ログとして使われました。つまり『何を作るか』『どう進めるか』『どこで止まるか』『今どこまで終わったか』を、会話履歴だけに持たせなかったわけです。
| ファイル | 役割 | Codexに効く理由 |
|---|---|---|
| `prompt.md` | 仕様、非目標、完成条件を固定する | 派手だが的外れな実装に流れにくくなる |
| `plans.md` | マイルストーン、受け入れ条件、検証コマンドを分ける | 大きな作業を小さな完了単位へ切り直せる |
| `implement.md` | 進め方と停止条件を運用ルールとして与える | 失敗時に直してから進むループを保ちやすい |
| `documentation.md` | 進捗、判断、既知の問題を残す | 途中で離れても同じ状態に再同期しやすい |
OpenAIの説明では、各マイルストーンのあとにlint、typecheck、tests、build、exportのような検証を回し、失敗したら先へ進まず直す運用も徹底していました。ここで効いているのは、うまい言い回しのプロンプトより、戻れる記録と止まる基準です。長時間タスクを任せるとき、Codexに必要なのは『ずっと覚えていてほしい』ではなく、『忘れても同じ仕様と状態に戻れる場所を常に参照できる』ことだと、この実験はかなり率直に示しています。
Codex appの並列実行とWorktree設計がこの運用を支える
この考え方はブログだけの話ではなく、現在のCodex app機能説明ともつながっています。OpenAIはCodex appで並列プロジェクト、スキル、Automations、Git worktree対応を前面に出しており、長時間の作業を横で走らせつつ、検証や再開の単位を保つ設計を押しています。Automationsの説明も、定期実行は新しい作業を始めるだけでなく、背景でレポートや修正を回し、必要ならワークツリーでローカルの未完了作業と衝突させない流れを前提にしています。
Worktreesのドキュメントはさらに露骨で、同じリポジトリ内で複数の独立タスクを干渉させず進めることを主目的にしています。スキルはplan / implement / test / reportのような流れを再利用しやすくし、Automationsはその流れを時間で呼び戻す装置になります。2月の長時間実験は派手なデモですが、6月時点のCodex appまわりの公式説明を見ると、OpenAIはすでに『長く走る作業をどう壊さず運用するか』を製品面でも固めにきています。
このCodex実験の核心は、AIが25時間止まらず書けたことだけではありません。仕様、計画、実行ルール、進捗記録を外に出し、各段階で検証してから先へ進むという、人間のソフトウェア開発で当たり前だった運用を、エージェントにもそのまま渡したことです。長時間タスクを本気で任せるなら、良いプロンプトより先に、戻れる記録と壊れたときに止まる基準を用意する必要があります。