Codex Goal 徹底解説：AI Agent を数時間動かし続ける目標駆動ワークフロー

ブラウザ、ターミナル、IDE の中で動く AI Agent は、ますますコードを書けるようになっています。しかし多くの開発者が本当に困っているのは、「できない」ことではなく、「途中までやって完了したと言ってしまう」ことです。

小さな ticket は coding agent に向いています。ボタンを直す、エンドポイントを追加する、短い文言を変える、テストを 1 つ追加する。目標が明確で、境界が小さく、検証方法も分かりやすいからです。しかし、大規模な移行、モジュール横断のリファクタリング、テストスイート修正、依存関係アップグレード、prompt eval の最適化になると、Agent はよく次の状態に陥ります。

それらしい中間状態まで進んだところで、早すぎるタイミングで止まってしまう。

Codex Goal / Persistent Goals が解決しようとしているのは、この「早すぎる終了」問題です。重要なのは Agent に何度もループさせることではありません。明確な目標に向かって作業を続けさせ、検証可能な完了基準を満たすまで進めることです。

Codex Goal が扱うのはループではなく停止条件

長時間タスクの自動化は、しばしば次のような粗い指示から始まります。

1

コードを確認し続け、問題を修正し、エラーがなくなるまで続ける。

もう少し機械的にすると、こうなります。

1
2
3
4


10 回ループする：
1. テストを実行する
2. モデルに失敗を修正させる
3. もう一度テストを実行する

このような rough loop は Agent を長く動かせますが、重大な弱点があります。

いつ本当に止まるべきか分からない。
「目に見えるエラーがなくなった」ことが「タスク完了」と同じか判断できない。

Codex Goal の要点はループ回数ではなく、goal、state、judge stop condition です。つまり Agent は、今回の作業の目標、現在どこまで進んだか、そして何がタスク完了の証拠になるかを理解する必要があります。

長時間 Agent の分かれ目は、「多くのステップを実行できるか」ではなく、「自分にまだ何が足りないかを判断できるか」です。

Goal と普通の prompt の違い

普通の prompt は一回限りの命令に近いものです。

1

このプロジェクトのテストを直して。

Goal prompt は、小さなタスク契約に近くなります。

1
2
3
4
5
6


目標：現在のリポジトリで失敗しているテストを修正する。
範囲：src/ と tests/ のみ変更する。ビルドスクリプトは変更しない。
完了基準：npm test がすべて通り、変更によって lint エラーが増えないこと。
検証コマンド：npm test && npm run lint。
失敗時：3 回試しても修正できない場合、残っている失敗ケース、試した方法、ブロッカーを出力する。
出力：変更ファイル、修正理由、検証結果をまとめる。

最大の違いは、Goal prompt が「完了」を定義している点です。

definition of done がないと、Agent は「コードを変更した」ことを「タスクを完了した」と誤解しがちです。明確な完了基準があれば、Agent はテスト、ログ、diff、ビルド結果、eval スコアといった外部証拠に基づいて作業を続ける必要があります。

LLM judge stop condition が重要な理由

長いタスクで難しいのは、Agent にコマンドを実行させることではありません。次の判断をさせることです。

本当に完了したのか？
一部のテストが通っただけではないか？
1 つの問題を直した代わりに別の問題を入れていないか？
さらに調査し、検証し、ある方針を戻す必要があるか？

ここで LLM judge stop condition が重要になります。

理想的には、Agent は「最後のコマンドの終了コードが 0 だったか」だけを見るべきではありません。次の点も総合的に判断する必要があります。

ユーザーが指定した完了基準をすべて満たしているか。
変更が許可された範囲内に収まっているか。
test、lint、build、eval を実行したか。
失敗ログに未解決の項目が残っていないか。
明らかな副作用やリスクがないか。
最終出力が人間のレビューに十分な証拠を含んでいるか。

つまり judge は「成功」と宣言するだけではありません。Agent が自分を納得させるだけの終了をしてしまうのを防ぐ役割も持ちます。

Goal に向いているタスク

Codex Goal / Persistent Goals は、複数回の探索と検証が必要な複雑な coding work に向いています。

コード移行：古いフレームワークから新しいフレームワークへ、CommonJS から ESM へ、古い API から新 API へ移行する。
大規模リファクタリング：モジュール分割、境界整理、重複実装の置き換え、複雑度低減。
テスト修正：失敗ケースを分析し、原因を特定し、修正後に繰り返し検証する。
依存関係アップグレード：フレームワーク、SDK、ビルドツールを上げながら breaking changes に対応する。
Prompt eval 最適化：評価を実行し、失敗サンプルを分析し、prompt や tool call の方針を調整する。
技術的負債の整理：明確なルールに沿って古い書き方を置き換え、挙動を保つ。

これらの共通点は、中間状態が多く、失敗原因が一度で見えず、完了判断が検証結果に依存することです。

Goal だけに頼るべきではないタスク

Goal は万能ではありません。次のようなタスクを 1 つの長い prompt だけで進めるのは危険です。

目標が非常に曖昧。たとえば「プロダクト成長を改善する」。
期間が長い。たとえば数週間にわたる SEO、GEO、広告運用の最適化。
コンテンツ、データ、広告、サポート、事業指標をまたぐクロスシステム調整が必要。
本番リスクがある。たとえばデータベース変更、本番設定、財務操作、アカウント権限変更。
テスト、指標、ログ、人間の受け入れ基準など、検証手段がない。

この種のタスクは Goal ではなく Mission に近いものです。

Goal は数時間から 1、2 日程度の深い実行に向いています。Mission には状態、履歴、スケジュール、人間の承認、段階的な振り返り、長期指標が必要です。たとえば SEO / GEO / Ads の最適化は、Agent にコンテンツを書かせたりパラメータを調整させたりするだけでは足りません。戦略、実験、データ変化、次のアクションを継続的に記録する必要があります。

良い Goal Prompt のテンプレート

使いやすい Goal prompt には、少なくとも次の要素を含めるべきです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


目標：
最終的に達成したい結果を一文で書く。

背景：
現在の問題、関連ファイル、業務上の制約、これまでの試行を説明する。

範囲：
変更してよいディレクトリ、ファイル、モジュールと、触ってはいけない場所を書く。

完了基準：
検証可能な definition of done を列挙する。

検証コマンド：
実行すべき test、lint、build、eval、script を明記する。

失敗戦略：
完了できない場合、原因、試した方法、残るブロッカーを出力させる。

リスク境界：
破壊的操作、本番設定、秘密情報、データベース、外部サービスは人間の確認を必須にする。

提出形式：
変更点、検証結果、リスク、次の提案をまとめさせる。

長時間タスクの品質を決めるのは、prompt の美しさではなく、完了基準がどれだけ硬いかです。

Goal Buddy の価値

長時間タスクが失敗するのは、Agent の能力不足ではなく、人間が最初にタスクを十分に定義していないことが原因の場合も多いです。

Goal Buddy のような補助ツールの価値は、正式に Agent に任せる前に、目標、境界、完了基準、検証方法を準備することにあります。タスクの事前チェックリストとして、次のように問いかけます。

このタスクの最終的に見える成果は何か？
どのディレクトリは変更でき、どこは変更してはいけないか？
成功を証明するコマンドは何か？
失敗時に続けるべきか、どこまで試すべきか？
段階的な commit が必要か？
どの操作は人間の承認が必要か？

このステップは冗長に見えますが、Agent が途中でずれたり、早く止まりすぎたり、レビューしづらい巨大な差分を作ったりする確率を大きく下げます。

Codex、Claude Code、OpenCode ユーザーへの実践アドバイス

Codex、Claude Code、OpenCode、OpenClaw、または類似の coding agent を使っているなら、長時間タスクは次のように扱うとよいです。

まず現在の作業ツリーを commit し、きれいな rollback point を作る。
依頼を曖昧な一文ではなく Goal として書く。
変更してよい範囲と禁止範囲を明確にする。
検証コマンドを与え、できれば各ラウンドで Agent が自分で実行できるようにする。
完了できない場合は成功を捏造せず、ブロッカーを報告させる。
ファイル削除、データベース変更、デプロイ設定変更など高リスク操作には人間の確認を置く。
テスト結果と変更サマリーを含む最終成果だけを受け入れる。

長時間 Agent の正しい使い方は、「一晩好きにやらせる」ことではありません。明確な目標、堅いガードレール、検証可能な出口を与えることです。

まとめ

Codex Goal / Persistent Goals の意味は、coding agent を「一文の指示を実行する存在」から「目標に向かって作業を続ける存在」へ進めることにあります。

最も向いているのは、複雑だが境界が明確なエンジニアリングタスクです。移行、リファクタリング、テスト修正、依存関係アップグレード、eval 最適化などです。一方で、曖昧で周期が長く、検証標準がないビジネス系タスクには向きません。それらは Mission システムとして設計する方が自然です。

これからの AI Agent の競争軸は、モデルがコードを書けるかだけではないかもしれません。目標に向かって継続的に進み、正しい停止タイミングを判断し、人間がレビューできる証拠を残せるかが重要になります。

参考：