Codexの /goal は何を変えるのか：プロンプトを「実行契約」として考える

Tech
Table of Contents

本記事は、hirokaji氏のnote「Codexの /goal は、プロンプトを実行契約に変える」の公開部分をもとに、内容をわかりやすく再構成した要約です。Codexの仕様面については、OpenAI公式の「Follow a goal」も確認しています。

一言でいうと

この記事の中心メッセージは、Codexの /goal は「長いプロンプトを走らせる便利コマンド」ではなく、AIに渡す依頼を実行契約に近づけるものだ、という点です。

これまでのプロンプトは、目的、作業範囲、禁止事項、過去の進捗、完了条件を一つの文章に詰め込みがちでした。しかし長期タスクでは、それだけだと文脈が落ちたり、AIが重要な制約を軽く扱ったり、作業範囲が膨らんだりします。

/goal は、タスクを「次に何をするか」ではなく、「どの状態になれば完了なのか」として持たせる発想です。

長期タスクで難しいのは、長く動くことではない

AIエージェントの話では、「何時間動けるか」「どこまで自律実行できるか」に目が行きがちです。しかし元記事が強調しているのは、長期タスクで本当に難しいのはそこではない、ということです。

  • 目的を失わずに進めること
  • 完了条件に照らして止まれること
  • 危険な変更が必要になったら人間に戻せること
  • 後からレビューできる証跡を残すこと

長く動けるAIほど、間違った方向に進んだときの差分も大きくなります。だから重要なのは「どこまで任せるか」だけでなく、どこで止めるかを設計することです。

従来のプロンプトは状態管理を背負いすぎていた

従来のCodex運用では、長い作業を頼むたびに、人間が毎回かなり多くの文脈を入れ直していました。

たとえば「前回の続き」「この範囲も見て」「DBスキーマは変えない」「API契約は変えない」「最後にテストも追加」といった情報を、毎回プロンプトの中に混ぜていました。

この依頼文は、実は多くの役割を背負っています。

  • 目的を伝える
  • 対象範囲を伝える
  • 禁止事項を伝える
  • 過去の進捗を復元する
  • 完了条件を暗黙に伝える

つまり、プロンプトが「作業の入口」「状態の復元」「制御ルール」を同時に担当していたわけです。短い作業ならまだ耐えられますが、長期タスクでは不安定になります。

/goal が変えるのは、タスクの出し方ではなく目標の持ち方

通常の依頼は、タスク列に近いものです。

このファイルを直して。
次にテストを追加して。
そのあとREADMEを更新して。

一方で、/goal 的な依頼は、達成状態を先に定義します。

/goal 検索UIの保守性を改善する。
対象は search/, filter/, 関連テストに限定する。
API契約とDBスキーマは変更しない。
完了条件は、既存テストが通り、新規回帰テストが追加され、変更理由が記録されていること。
破壊的変更や権限まわりの判断が必要なら停止して確認する。

前者は「次に何をするか」を渡しています。後者は「どの状態になるまで進めるか」を渡しています。

この違いが重要です。Codexのようなエージェントにとって必要なのは、手順を細かく命令されることだけではありません。むしろ、目的、範囲、完了条件、停止条件が明確であるほど、長期タスクは安定します。

OpenAI公式の説明とも重なる

OpenAI公式のCodex use caseでも、/goal は「長時間作業に対して、検証可能な停止条件に向かってCodexが複数ターンで作業し続ける」用途として説明されています。

公式ページでは、/goal <objective> で目標を設定し、現在のgoal確認、pause、resume、clearといった操作で実行を制御できることも示されています。

つまり、元記事の読み解きと公式情報はかなり近い方向を向いています。/goal は「大きなお願い」ではなく、検証可能な終了条件を持つ継続目標として使うものです。

悪い /goal は願望を書く

元記事では、悪い /goal は「願望」を書いてしまう、と整理されています。

/goal このアプリをいい感じに改善して

この依頼は自然に見えますが、長期タスクには向きません。何を改善するのか、どこまで触ってよいのか、何を変えてはいけないのか、どの状態なら完了なのかが分からないからです。

特に危ないのは、完了条件が主観的なままのgoalです。

  • 品質が十分になったら完了
  • 納得できる状態まで仕上げる
  • 100点になるまで改善する

これでは、AIが自分で基準を作り、自分で達成判定してしまいます。長期タスクで必要なのは、AIの自己採点ではなく、人間が確認できる完了条件です。

良い /goal は Goal Contract になる

良い /goal は、少なくとも次の要素を持ちます。

  • Objective: 何を達成するのか
  • Scope: どこまで触ってよいのか
  • Out of scope: 何を変えてはいけないのか
  • Acceptance Criteria: どの条件を満たせば成功か
  • Done When: 何を確認したら完了と言えるか
  • Stop Rules: どんな場合に停止して人間へ戻すか
  • Audit: 何を証跡として残すか

元記事では、この構造を「Goal Contract」として捉えています。これは単なる作業説明ではなく、目標、完了、停止をまとめて定義する実行の境界線です。

done_when の解像度が成果を決める

/goal の良し悪しは、コマンドそのものよりも done_when の解像度で決まります。

悪い例はこうです。

品質が十分になったら完了

良い例は、確認可能な条件になっています。

既存テストが通る。
新規回帰テストが追加されている。
Scope外の変更がない。
変更理由がAUDIT.mdに残っている。
未完了事項が明示されている。

このように書くと、Codexも人間も「終わったかどうか」を判断しやすくなります。

/goal だけでは足りない：plan・validation・audit が必要

元記事は、/goal だけで長期タスク運用が完成するわけではない、とも述べています。

長期タスクでは、次の3つが必要になります。

  • plan: AIが迷わないための計画
  • validation: 途中で壊れていないかを見る検証
  • audit: 何を変えたかを後で確認できる証跡

実務では、次のようなファイルを用意しておくと運用しやすくなります。

docs/goal/
  GOAL.md
  PLAN.md
  AUDIT.md
  DECISIONS.md
  STOP_RULES.md

/goal は入口です。その周辺に、計画、検証、判断ログ、停止ルールを置くことで、長期タスクをレビュー可能な形にできます。

まとめ

Codexの /goal は、プロンプトを長くするための機能ではありません。むしろ、長い作業を安定させるために、目的、範囲、完了条件、停止条件を明確にするための入口です。

良い /goal は「お願い」ではなく「実行契約」です。

  • 何を達成するのか
  • どこまで触ってよいのか
  • 何を変えてはいけないのか
  • 何で検証するのか
  • どこで止まるのか
  • 何を証跡として残すのか

この骨格があると、Codexは単なる作業者ではなく、検証可能な目標に向かって進むエージェントとして扱いやすくなります。

参考リンク

コメント