Codex goalは、完了基準をタスク自体に委ねること

目標は「次へ（または続行）ボタン」ではありません

コマンドの形式（命令形）だけを見ると、/goal は「完了するまで続ける」という概念を強化したようなものに非常に似ています。しかし、このように捉えすぎると、議論が脱線してしまいます。

長期間のタスクで最も厄介な点は、モデル自身が継続を望むかどうかという点ではなく、各ラウンド終了後に、誰が（またはどの仕組みが）継続すべきかを判断する点です。

これらの停点は必ずしも間違っているわけではありませんが、人の受け入れ基準とは異なる場合がよくあります。

目標が解決すべきことは、このことです。すなわち、受入基準（または「判定基準」）を事前に明確に記述し、それによって以降のすべてのラウンドで判断ができるようにすることです。

一般的な目標の例は以下の通りです。

/goal フロントエンドを Next.js に移行する手伝いをしてください。

その問題は短いことではなく、停止条件がないことです。Codexは数ページの移動ができたり、ついでにコンポーネントをリファクタリングしたりでき、さらに追加すべきだと考えるものを継続的に追記し続けることもできます。

より使える書き方は次のようになります。

/goal 注文の管理画面を React Router から Next.js App Router へ移行する。
ログインページ、注文リスト、注文詳細、および購入（または決済）ページの見栄えは旧バージョンと一致させる必要がある。
API契約とデータベーススキーマは変更しないこと。
ページ群が完成するたびに、npm run build、npm test、およびPlaywrightの重要パスを実行すること。
これらの検証すべてが通った場合のみ完了とする。

この追加部分は、単なる余談ではなく、4つのコントロールプレーン（制御面）に関するものです：

要素	作用
目標	最終的にどのような結果であるか
境界	手動では対応できないインターフェース、データ、ファイル、または動作は何か
検証	それが本当に完了したことを証明するための証拠は何か
停止条件	どのような条件を満たした後に停止できるか

「目標」を高くするのは、これら4つのことです。

なぜ長時間実行できるのか

Codex は、一度の回答が引き伸ばされたからではなく、goal の下で継続的に推進することができます。

実際の作業方法は、むしろサイクルに近いです。すなわち、計画し、実行し、ツールの結果を観察し、修正を行い、続けるかどうかを決定する、というプロセスです。ビルド失敗、テスト失敗、スクリーンショットの不一致、リンティングエラー、評価サンプルが通らないといった事象はすべて、タスクを次のサイクルに戻します。

「検証方法」が目標に記載されている場合、エージェントは直感や推測だけで「完了したはずだ」とは述べられません。必ず証拠を得る必要があります。証拠が得られない場合は調査を継続し、証拠に問題がある場合は修正を続けなければなりません。すべての証拠が通過して初めて、「完了」と認める資格があります。

これが、goal が移行（マイグレーション）、リファクタリング、バッチ校正、プロンプト評価、長尺のデバッグといったタスクに適している理由です。これらの共通の特徴は、一度で完結しない点、そして完成に主観的な判断だけでは頼れない点にあります。

逆に、このような目標は非常に危険です：

/goal より高度なプロダクトプランを考案する

境界がなく、検証もされず、かつ停止条件もない。エージェントは長時間動作するかもしれませんが、「長い時間動くこと」が「有用であること」を意味するわけではありません。最低限、何組のソリューションを出力するのか、どのような制約を網羅しているのか、どの基準で絞り込むのか、そしていつ停止するのかを明確に記述する必要があります。

Claude Codeも同じことを処理しています

Claude Code にも /goal があり、公式ドキュメントの説明の方がより直接的です。ユーザーが「完了条件」（completion condition）を設定すると、Claude はその条件が満たされるまでターンをまたいで継続的に作業します。

『Claude Code』のドキュメントには、各ラウンド終了時に完了条件が満たされているかを確認し、もし条件を満たしていない場合は次のラウンドへ進むと記されています。この点が非常に重要であるのは、「継続」という判断をモデル自身の主観的な結論付けのプロセスから切り離し、外部の追加的な条件判定（ロジック）としているためです。

両社の具体的な実装詳細が無理に同一である必要はありませんが、方向性は一致しています。すなわち、エージェントは「次の指令を実行する」という段階から、「検証可能な目標を中心に継続的に推進していく」という段階へと移行し始めているということです。

簡単に分類すると：

この表において、goal の役割は非常に明確です。それはフックの代替ではなく、記憶（メモリ）の代替でもありません。それが管理しているのは、「今回のタスクをどの程度まで達成すれば完了とみなせるか」という点です。

Good goals should be written like acceptance criteria

今から、一つのゴールを四行に分けて記述します。

目標：最終的にどのようなユーザーに見える結果が出なければならないか。
範囲：どのファイル、インターフェース、データ、視覚的要素、または動作を変更してはならないか。
検証：どのようなコマンド、テスト、スクリーンショット、評価、または手動チェックを証拠として使用するか。
停止条件：すべてが満たされたときに停止するもの。どの権限、事実、製品判断に遭遇したときに一時停止するか。

これは普通のプロンプトとは大きく違います。

通常のプロンプトは次のアクション（行動）のようなものであり、ゴール（目標）は完成の基準（クオリティ）のようなものです。それは人間をプロセスから排除するのではなく、人間の判断を事前に組み込むものになります。あなたは、「これはまだ完了ではない」と都度指摘する必要がなくなり、「何をもって完了とするか」という条件を最初から守らなければならない制約として記述できるようになるのです。

ですから、エージェントに自主的に動かしてもらいたいほど、目標はより狭く（限定的に）設定する必要があります。

プロセスへの注視を減らそうとすればするほど、検証（バリデーション）はより具体的・現実的に記述する必要があります。

逸脱（暴走）を最も避けたいからこそ、境界線を明確に定義することが重要だ。

「goal」が真に注目すべき点は、ここです。単にコマンドが増えることでも、どれだけ長く動作するかという点でもありません。むしろ、ターミナルエージェントが、「完了の判断を下す主体は誰か」という問題を表舞台に引き上げてきた点にあります。

参考文献

執筆に関する補足

元のプロンプト

$blog-writer codexが新しくリリースしたgoalコマンドの詳細について、動作原理は何か、なぜ長時間の処理が継続するのか、そして公式が提供する具体的な事例を解説してください。Claude Codeに同様の命名規則はあるか？また、ついでに、最近リリースの2つのターミナルで、便利でおすすめな機能をいくつかピックアップして表としてまとめてください。

執筆のアイデア概要

原文の主要な判断点を維持する：goal の核となるのは、コマンド名ではなく、完了条件である。
元のプロンプトで要求されていた Claude Code の比較とターミナル機能の表を補完する。
「公式ドキュメントの再述」は排除し、実用的な goal の記述方法に重点を置く。