Codexに長めの作業を任せたいとき、/goalにどの粒度で指示を書けばいいのか迷うことがあります。
結論から言うと、/goalは単発の質問ではなく、目的・対象・確認基準・完了条件がある程度まとまった作業をCodexに最後まで進めてもらうために使うものです。
たとえば、
- この機能を直したい
- 対象はこのファイル、またはこのディレクトリ
- 守ってほしい条件がある
- 実装後にこの確認コマンドを実行してほしい
- 最後に変更内容と確認結果をまとめてほしい
ここまで言えるなら、/goalに向いています。
逆に、「いい感じに直して」「何か改善して」のように目的や範囲が曖昧なままだと、作業範囲が広がったり、途中で別方向に進んだりしやすいです。
今回は、/goalに何を書くと良いかをコピペして使えるテンプレとあわせてまとめます。今回はコーディングタスク向けに解説します。
結論：目的・対象・確認方法が言えるなら/goal
まず判断基準です。
/goalに向いているのは、対象、やること、守る条件、確認方法、最終報告の形がある程度決まっている作業です。
完全に手順が決まっている必要はありません。ただし、目的や範囲が曖昧なままだとCodexがどこまで作業すればいいか判断しづらくなります。
Codexのマニュアル上でもGoalモードは長めのタスクに対して使うものとして説明されています。ポイントは「開始指示」と「完了条件」の両方がプロンプトに含まれていることです。
つまり、/goalに書く内容は単なるお願いではなく「完了条件つきの作業指示書」であることが求められるわけですね。
なので、短くてもいいので、次の情報は入れるのがおすすめです。
- 何を達成したいか
- どこを対象にするか
- 何を確認して、何を直すか
- 実装後に何で確認するか
- 最後にどう報告してほしいか
/goalに向いているタスク
/goalは、「あとは進めるだけ」状態のタスクに向いています。
たとえば、次のような作業です。
- 目的が決まっていて、そのための手順が概ね決まっている
- 成果物の確認方法が機械的に可能なものである
逆に、目的や対象がまだ大きく曖昧な場合は/goalで完了まで任せようとするのはおすすめしません。
先に調査や方針固めをし、作業範囲を絞った方がいいでしょう。そういう場面では/plan コマンドというものが便利です。
/goalに入れるべき5つの項目
/goalには最低限この5つを入れると出力結果が一定のレベルを超えやすくなります。
1. 概要指示
まず、何を達成したいのかを書きます。
ここでは「何のためにやるのか」も入れた方が良いです。
たとえば、ただ「入力フォームを直して」ではなく、
1設定画面の入力ミスを減らすために、フォームの見た目とバリデーション表示を整えてください。のように書く感じです。
目的があるとCodexが細かい判断をするときの基準になります。
2. 対象
次に、対象ファイル、対象ディレクトリ、対象機能を書きます。
対象を書かないとCodexが広範囲に探索して意図していないファイルまで触る可能性があります。
たとえば次のように書きます。
src/配下の対象機能app/settings/配下- 設定の保存機能
- 管理画面の記事生成フロー
ファイル名が分からない場合でも、
1この機能周辺を調べてから対象を絞ってください。と書いておくと事故が起きにくくなります。
3. 確認・修正
ここには、見てほしいこと、直してほしいこと、守ってほしい制約を書きます。
たとえば、
- 既存のUIパターンに合わせる
- 余計なリファクタはしない
- エラー文言は既存の言い回しに合わせる
- 仕様が不明な場合は勝手に決めず、残リスクとして報告する
のような内容です。
この項目を書いておけば「言ってないのに勝手に実装された」というケースが少なくなります。
4. 実装後
実装後に何を確認してほしいかを書きます。完了条件を兼ねているイメージですね。
例としては、次のようなものです。
- テスト
- lint
- build
- 型チェック
git diff --check- ブラウザでの目視確認
- 特定画面の手動確認
ここはかなり大事です。自己レビューを指示するだけで致命的なミスをCodex自身が修正してくれます。また、プロジェクトに決まった確認コマンドがあるなら最初から書いておくのが良いです。
逆にここのチェック方法が機械的にできないものだと/goalには向いていないと言えます。
5. 出力
最後に、作業後の報告形式を書きます。
ここを入れておくと人間のレビューがしやすくなります。
たとえば、
- 変更した内容
- 確認結果
- 残っているリスクや次に対応すべきこと
のように指定します。
特に、残リスクを書いてもらう形にしておくと「確認できなかったこと」や「仕様が不明なところ」が明らかになるので次の作業計画に非常に役立ちます。
コピペ用：/goalテンプレ
ここまでの項目を毎回ゼロから書くのは面倒ですよね。テンプレを用意したのでぜひご活用ください。もちろんこのテンプレをAIに渡してしまい、プロンプトを作らせる使い方も非常に有効です。
1/goal
2[概要指示]
3
4対象:
5- 対象ファイルや対象ディレクトリ
6- 対象機能
7
8確認・修正:
9- 確認してほしいこと
10- 必要なら修正してほしいこと
11- 守ってほしい制約や判断基準
12
13実装後:
14- 実行してほしいテストや確認コマンド
15- lint / build / 型チェックなど
16- 目視確認や手動確認が必要な観点
17
18出力:
191. 変更した内容
202. 確認結果
213. 残っているリスクや次に見るべきこと使う前のチェックリスト
/goalを書く前に、次の項目を確認してみてください。
- 何を終わらせたいかを1文で言える
- 対象ファイルや対象ディレクトリを指定できる
- やってほしくないこと、守ってほしい制約がある
- 実行してほしい確認コマンドが分かる
- 最後にどう報告してほしいか決めている
このうち1つでも大きく曖昧なら、まず調査や方針出しを先に行なってください。
たとえば「どのファイルを直すべきか分からない」状態なら、対象候補と確認方法を洗い出してもらう方が安全です。
長い指示はファイルにして参照させる
/goalの指示が長くなりすぎる場合は、ファイルにまとめると良いです。
公式のドキュメントによれば、/goalへの指示は最大4,000文字までとされています。ただしそれはチャット欄での指示の話で、ファイルにすれば4,000文字以上も可能です。
そういう場合は別ファイルにまとめて、以下のような指示でファイルを参照させる形にしましょう。
1/goal
2docs/codex-goal-task.md の内容に沿って、対象機能の修正と確認まで進めてください。途中で止めたい・変えたい・消したいとき
Goalモードは、途中で管理することもできます。
Codexのデスクトップアプリでは進行状況がチャット入力欄の上に表示され、編集、一時停止/再開、クリア、停止が可能です。
CLIでは、/goalで現在のgoalを確認できます。また、次のコマンドで管理できます。
1/goal pause
2/goal resume
3/goal clear途中で条件が変わったり、やっぱりこうしたいという場合は放置せず更新しましょう。
特に、作業の途中で「やっぱりこの範囲は触らないでほしい」と分かった場合は早めに条件を変えた方が事故防止になります。
まとめ
/goalは、要件が決まりきったタスクに対して非常に有効です。
目的、対象、確認方法、完了条件が言えるなら/goal。
次にCodexへ長めの作業を任せるときは、まず今回のテンプレを埋めるところから始めてみてください。
この形にしておくとAIの回答もレビューしやすくなります。うまく使いこなしたいですね。