「ループ」が作業の単位になる──Codexホワイトペーパーに見る長時間タスクの設計¶

対象 / ポイント

対象: AIエージェントを単発タスクから継続的な業務へ組み込もうとしているエンジニア・チームリード層。

ポイント:

作業単位は、1回のプロンプトから文脈・記憶・再起動・レビューを束ねたループへ移る
記憶は会話履歴ではなく、diffで確認できる vault として分離する
長時間タスクの完了は、検証できるゴールと人間の判断点で定義する

Codexホワイトペーパーが示しているのは、コーディング支援ツールの機能追加だけではない。差分を作り、リポジトリを変え、成果物をレビューする作業そのものが、1回のプロンプトから継続的なループへ移りつつある。¹

この記事の問いは、長時間タスクをAIエージェントに渡すとき、何を作業単位として設計すべきかである。ホワイトペーパーはCreatorのJason Liu氏の使い方を題材に、Codexを「作業が住む場所」として描いている。本記事では、その中でも実務設計に効く記憶、再起動、ゴール、人間の判断点に絞る。

ループが作業の単位になる構造図

図: プロンプト単位からループ単位へ移る設計要素。画像内の表記は原図のまま。

作業の単位はプロンプトからループへ動く¶

長時間タスクでは、1回の依頼文よりも、同じ作業へ戻り続ける構造のほうが重要になる。ホワイトペーパーは、継続スレッド、memory vault、ツール接続、定期再起動、レビュー面を組み合わせた作業像を示している。¹

この5つがそろうと、作業は会話欄の中で消費されず、状態を持つ。

継続スレッド: 文脈、好み、過去判断、未解決の論点をためる
memory vault: 会話の外に、TODO、人物、プロジェクト、メモを残す
ツール接続: Slack、Gmail、ブラウザ、GitHubなど実務の発生場所へ届く
定期再起動: 同じスレッドへ一定間隔で戻る
レビュー面: 成果物をその場で確認し、次の指示へつなげる

ここでの中心は「賢い返答」ではない。文脈が残り、変化を検知し、成果物を見ながら次の行動へ戻れることだ。この束がループになる。

記憶をレビューできる資産にする¶

長く続くスレッドほど、会話の外へ記憶を逃がす必要が出る。ホワイトペーパーが示す型は vault と呼ぶ記憶領域で、TODO、人物、プロジェクト、エージェント用メモを独立したファイルとして持つ。¹

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

効くのは置き場所の分離だ。リポジトリはコードを持ち、vault は作業まわりの流動的な文脈を持つ。誰が何を好むか、どの判断をなぜ下したか、どのループが閉じたかといった情報は、会話履歴だけに置くと後から読み返しにくい。

さらに vault をGitHubに置くと、diffが記憶のレビュー面になる。エージェントが「書き留める価値あり」と判断した内容を、人間が差分として確認できる。会話履歴に曖昧な印象が静かに蓄積するのではなく、変わった点だけが記録される。

ただし、継続スレッドにはコストの裏返しがある。文脈を抱え続けるスレッドは、毎回新しく立てる短いスレッドより実行コストが高くなりやすい。重要な作業では継続性が見合うが、すべてを長いスレッドで回すのが最適とは限らない。

「変化したら進める」指示に変える¶

定期再起動は、通常のプロンプトと指示の質が違う。通常のプロンプトは「今これをやれ」と一度きりの実行を頼む。定期再起動では「これを監視し、変化があれば前へ進めろ」と、同じスレッドへ戻る条件を渡す。

たとえば、30分ごとにSlackとGmailを確認し、未返信のうち対応が要るものを探す。必要なら背景文脈を調べ、返信案まで作る。ただし承認なしには送らない。

ここで重要なのは、再起動のたびに文脈をゼロから組み直さない点だ。ホワイトペーパーはThread automationsを、同じ会話へ戻る定期的な呼び出しとして説明している。¹ 過去の判断、メモ、未解決の論点が引き継がれるため、ループは単なるcronより作業に近づく。

検証できるゴールが完了を定義する¶

ループを安全に回す鍵は、エージェントが自分で答え合わせできるゴールにある。ホワイトペーパーは弱いゴールと強いゴールを対比し、期待する挙動、レビュー基準、制約、完了条件を最初から指示に含める重要性を示している。¹

弱いゴールは「この計画を実装して」と頼む形だ。これでは完了の基準が曖昧になり、エージェントはどこまで進めればよいかを判断しにくい。

強いゴールは、成功条件を作業の中に埋め込む。たとえば、公開APIの互換を保ったままライブラリを移植し、元のユニットテストを成功条件にする。同じテストが通り、差分が文書化されたらレビュー可能とする。

RichライブラリのRust移植例は、この違いをよく示す。狙いは移植そのものではなく、元のテストが通る形で移植することだった。テスト群が現実の基準になり、同じテストを通すまで作業は完了扱いにならない。

すべてのループに人間の判断点を残す¶

ホワイトペーパーのループ例に共通するのは、エージェントが準備することと、人間が決めることの分離だ。秘書役、フィードバック監視、返金対応のいずれも、エージェントは背景調査、要約、返信案、次の選択肢を用意する。

人間が握るのは、承認、トーン、タイミング、最終決定だ。取り消せない操作や対外的な送信は、人間側に残る。再起動や遠隔操作で作業が手元を離れても、行動の範囲は区切られている。

つまり、このホワイトペーパーが描くのは全自動エージェントではない。作業に住む場所と戻る周期を与えつつ、決定の点には人間を残す。長時間タスクの設計は、能力の最大化より境界の設計に寄っていく。

まとめ¶

作業の単位は、単発プロンプトから「文脈、記憶、ツール、再起動、レビュー」を束ねたループへ移りつつある。記憶はdiffでレビューできる資産にし、ゴールはエージェントが自己検証できる基準にするほど安定する。

ここから見えるのは、長時間タスクの難所が「エージェントの能力」から「完了の定義とレビュー面の設計」へ移っている点だ。同じ収束は特定のツールに限らず、エージェント型の開発ツール全般で起きている。次に問われるのは、何を検証可能にし、どこに人間を残すかの判断である。