Codexの/goalコマンドとは — 完了条件まで自律的に走らせる使い方と、ゴールの書き方

/goalコマンドとは — ゴールが「指示」と「完了条件」を兼ねる

/goal コマンドは、Codexに通常の1ターンで止まらず、1つの持続的な目標に向かって作業を続けさせたいときに使います。

ポイントは、入力したゴールが「最初の指示」と「完了条件」の両方になることです。「これをやってください」であると同時に、「この状態になるまで終わらないでください」という意味を持ちます。

/goal では、目的地は固定されます。ただし途中で見えた景色に応じて、進む道はCodex自身が変えます。ツールを使って得た観察結果によって、ゴールへの経路は変わっていく——ここが「手順を指定する依頼」との根本的な違いです。

どんな仕事をゴールにするか — 3つそろっているか

誤解されやすいのですが、普通のプロンプトの中にもゴール（目標）は書きます。だから「目標がある仕事なら何でも /goal」ではありません。よいゴールは、1つのプロンプトよりは大きく、終わりのないやることリストよりは小さいものです。

目安は、次の3つがそろっているかどうかです。

1. 1一度の実行では終わらない可能性が高い
2. 2実行結果を見て次の一手を変える必要がある
3. 3完了を判定する証拠や基準がある

つまり本質は、道筋は不確実だが、ゴールは明確というタスクです。最初から手順を確定できなくても、何をもって完了とするかは確定できる。そこが使いどころになります。

「完了」を定義する — ここがCodexとの契約になる

この機能でもっとも大事なところです。始める前に「完了」の意味を共有しておく。これがCodexとの契約になります。

意識すべきは、Codexが自分で進捗を検証できる形で書くことです。公式が挙げているのは Outcome（結果）・Constraints（制約）・Verification（検証）の3つ。これに Context（前提）を足した4つで書くと、実際には迷いません。

いちばん大事なのは Verification（検証） です。ここが曖昧だと、Codexは「どこで止まっていいのか」が分からず、いつまでも作業を続けるか、中途半端なところで終わります。

コツは、定量的かつ客観的な基準にすることです。誰が見ても同じ判定になる形でなければ、Codexは自分で完了を確かめられません。移行作業なら「新しい経路がテストを通り、元の経路にも戻せる状態」、試作なら「アプリが立ち上がり、想定どおりの動きになっている状態」——このように、確かめる行為までセットで書きます。

プロンプトの型 — 4要素をそのまま並べる

型はこれだけです。先ほどの4要素を、そのまま並べます。

/goal 〈何をどこまでやるか〉

前提：〈対象のファイル・データ・環境〉
制約：〈やってはいけないこと・守る条件〉
完了条件：〈これが満たされたら終わり、と検証できる形で〉

実際に埋めると、たとえばこうなります。アンケートの自由記述を分類して集計する、という仕事です。

/goal アンケートの自由記述を分類して、集計表にまとめてください。

前提：対象は アンケート.csv の「ご意見」列。分類の定義は 分類ルール.md にある。出力先は 集計.md
制約：原文の言い回しは変えない。分類ルールにないカテゴリは勝手に作らない
完了条件：全件がどれかの分類に割り当てられ、分類ごとの件数と代表コメント3件が 集計.md に載っている

見るべきは完了条件の行です。「全件」「件数」「代表コメント3件」と、数えて確かめられる形になっています。これを「いい感じにまとめて」と書いてしまうと、Codexはどこで止まればいいのか判断できません。

もしゴールをうまく言語化できなければ、Codex自身に手伝ってもらえばよいです。まずは普通のチャットで「何を作りたいのか」を会話し、そのあとでこう頼みます。

ここまで話した内容をもとに、目標と完了条件を整理してゴールを設定し、
そのまま作業を始めてください。

コマンド一覧 — 途中で止めて、また再開できる

ゴールは、設定したあとも途中で確認したり、止めたり、再開したりできます。長く走らせる仕事なので、この操作を知っているかどうかで安心感がまったく違います。

覚えておきたいのは /goal pause です。「思っていたのと違う方向に進んでいる」と感じたら、まず一旦止める。ゴールは残るので、方針を伝え直してから /goal resume で再開できます。

プランモードとの組み合わせが基本形

プランモードと /goal は名前が似ていますが、役割は違います。プランモードは「どう進めるかを先に考える」、ゴールモードは「何を達成するまで走り続けるかを固定する」ものです。

公式のPromptingガイドでも、まずプランモードで調べさせて進め方を固め、そのあとに /goal で持続的な目標を設定する流れが案内されています。

/plan  →  進め方を調べて、計画を出してもらう
   ↓
/goal  →  完了条件を決めて、そこまで走らせる

組織で使うなら — 完了条件を書く力そのものが資産になる

/goal を使いこなせるかどうかは、コマンドを覚えたかではなく、自分の仕事の「完了」を言語化できるかにかかっています。そしてこれは、AIの話を抜きにしても、業務の引き継ぎ・外注・新人教育すべてに効く力です。

当社が支援に入ると、ここで詰まるケースが多くあります。「いい感じにまとめて」で回ってきた仕事は、完了条件が担当者の頭の中にしかありません。/goal を書こうとすると、それを外に出さざるを得なくなる。AIに任せるための作業が、そのまま業務の棚卸しになるというのが、実際に導入して分かったことです。

当社のCodex研修・導入伴走支援では、貴社の実業務を題材に、完了条件を検証できる形に翻訳するところから一緒に取り組んでいます。