Codexの `/goal` コマンドを使い倒す ― 数時間の無監督自律作業を成立させる目標設定の作法

はじめに 🎯

OpenAI Codexで長時間の自律作業をやらせようとして、こんな経験はないでしょうか。

• 数時間あれば終わるはずのコード移行を、結局つきっきりで指示し続けた
• 「全部のテストが通るまで頑張って」と頼んだのに、途中で「次は何をしますか？」と聞かれて止まる
• プロトタイプ開発を任せたら、勝手な方向に膨らんで気づいたら別物になっていた

これらは、「目標の渡し方」と「停止条件の合意形成」 が設計されていないことが原因です。Codexには /goal という機能があり、これを使うと 永続的な目標を与えて、検証可能な停止条件まで数時間にわたり自律的に作業させる ことができます。本記事では、公式ドキュメント「Follow a goal」をベースに、/goal を使い倒すための実用知識を、コマンド例・図解・効果的な目標の書き方まで含めて解説します。

この記事で得られること:

• 🛠️ /goal コマンドの基本構文と5つのサブコマンドの使い分け
• ⚙️ /experimental と config.toml 経由での有効化手順
• 🔁 4フェーズで動く /goal の動作メカニズムと、内部で起きていること
• ✍️ 「失敗する目標」と「成立する目標」の構造比較と、検証可能な停止条件の書き方
• 📦 公式の3つの推奨ユースケース（Migrations / Prototype creation / Prompt optimization）の具体的な活用方法
• ⚠️ /goal を使うべきでない場面の見極め方

💡 本記事は、執筆時点（2026年5月）における公式ドキュメント Follow a goal をベースにしています。仕様は更新される可能性があるため、最新情報は公式を確認してください。

---

/goal コマンドが解決する課題 🪜

最初に、/goal が 何を解決する機能なのか を、通常の対話モードと比較しながら整理します。

通常の対話モード vs /goal モード

通常のCodexは、ユーザーが投げた質問やタスクに対して 1ターンずつ応答する モデルで動いています。これはこれで便利なのですが、長尺の作業を任せようとすると、各ターンの境目で「次は何をしますか？」とユーザーに判断を返してきます。

この図のポイントは、通常モードではユーザー指示が毎ターン必要 な一方、/goal モードでは初期投入1回で完結する という構造の差です。Codexは内部で「作業 → チェックポイント → 検証 → 達成判定」のループを回し、達成と判断したら自律的に停止します。

公式が明示している価値

公式ドキュメントは /goal の本質を、こう要約しています。

Codex can work independently for multiple hours without needing your input.

「複数時間にわたり、ユーザーの入力なしに独立して動作できる」――これが /goal の存在意義です。普段は「数時間放っておいたら大変なことになるのでは？」と心配するのが普通ですが、/goal は 検証可能な停止条件をセットで渡す ことで、その心配を構造的に解消します。

---

基本構文とコマンドファミリー 🛠️

/goal の基本構文は、公式ドキュメントが推奨する以下のテンプレートです。

/goal Complete [objective] without stopping until [verifiable end state].

[objective] には やってほしいこと を、[verifiable end state] には 終わったことを機械的に確認できる状態 を埋めます。鍵は後者の 「検証可能（verifiable）」 という単語で、ここを曖昧にすると /goal は機能しません。

5つのサブコマンドの状態遷移

/goal には目標設定以外に4つのサブコマンドがあり、ライフサイクルを制御できます。

この図のポイントは、/goal pause と /goal resume で中断・再開ができる ことと、/goal clear でいつでも目標を破棄できる ことです。長時間の自律作業中でも人間が割り込んで制御権を取り戻せる、というのが安心して任せられる前提になります。

コマンド早見表

コマンド	動作	使うタイミング
/goal <objective>	目標を設定して作業を開始	最初に1回
/goal	現在の目標と進捗を確認	途中で進捗を見たいとき
/goal pause	一時停止	別作業を割り込ませたいとき
/goal resume	再開	一時停止後に再開するとき
/goal clear	目標をクリア	作業を打ち切りたいとき

基本コマンド例

たとえばPlaywrightベースで画面の視覚回帰テストを通しながら移行したい場合は、こう書きます。

/goal Complete migration of all screens from Vue 2 to Vue 3 without stopping
until `pnpm test:visual` passes for every page in `tests/visual/*.spec.ts`.

[objective] が「Vue 2 から Vue 3 への全画面移行」、[verifiable end state] が「pnpm test:visual が tests/visual/*.spec.ts の全ページで通ること」になっています。検証コマンドが具体的なファイルパスとセットで渡されている点がポイントです。

---

有効化方法 ⚙️

/goal は実験的機能（experimental feature）として提供されており、デフォルトでは無効です。有効化には2つのルートがあります。

この図のポイントは、対話的に1コマンドで切り替えるルートと、設定ファイルに永続化するルートの2系統がある ことです。チームで同じ設定を共有したい場合は後者、自分だけ試したい場合は前者が向いています。

ルート1: /experimental で対話的に有効化

Codexのプロンプトでスラッシュコマンド /experimental を入力すると、experimental機能の一覧が開きます。その中から goals を有効にすれば、その場で /goal が使えるようになります。

ルート2: config.toml に書き込む

設定ファイルに以下のセクションを追加すれば、起動時から有効化されます。

[features]
goals = true

設定ファイルのパスは環境によって異なりますが、Codex CLIの設定ディレクトリ配下にある config.toml を編集します。チームで使う場合は、このスニペットをdotfilesリポジトリやセットアップスクリプトに含めておくと、新メンバーも同じ条件で /goal を試せます。

---

動作メカニズム 🔁

公式ドキュメントの「Set up the loop」セクションと「Let Codex work independently」セクションをまとめると、/goal の動きは大きく 4つのフェーズに整理 できます（フェーズ分けは公式そのものではなく、私が運用しやすいように再構成したものです）。表面的には「コマンド投入 → 数時間後に成果が出ている」だけに見えますが、実際にはチェックポイントを刻みながら自律的にループしています。

4フェーズの全体像

この図のポイントは、Phase 3のチェックポイントが Phase 2の独立動作に戻るループ を持つことです。検証コマンドが通らなければ作業を続け、通れば停止する――この条件分岐が /goal の心臓部分です。

チェックポイントループの運用イメージ

Phase 3のチェックポイントを、/goal を機能させる側の運用ループとしてズームインしたのが次の図です（公式は「checkpointsで動かし、短い進捗ログを残せ」とユーザーへ指示する記述があり、それを運用フロー図に書き起こしたものです）。

この図のポイントは、検証コマンドの結果がループ脱出の唯一の判定材料 になっていることです。曖昧な「だいたい完成した気がする」では止まりません。だからこそ、/goal を使う側にとっての最大の準備は 「機械的に判定できるコマンドを用意しておく」 ことになります。

Phase 1で渡すべき4要素

公式ドキュメントの「Set up the loop」セクション（5つの番号付きステップ）を再構成すると、初期設定で押さえるべき要素は以下の4つに整理できます。

要素	内容	例
Objective（目標）	やってほしいことの中身	Vue 2 → Vue 3 への全画面移行
References（参照）	関連するファイル・ドキュメント	tests/visual/、PLAN.md、対象ディレクトリ
Verification（検証方法）	進捗確認に使うコマンド	pnpm test:visual 、pytest -k migration
Stop Condition（停止条件）	成功と判定する状態	全テストPass、もしくはeval評価スコア > 0.9

この4要素が すべて揃って初めて /goal が機能します。1つでも欠けると、Phase 3のチェックポイントが判定不能になり、ループが脱出できなかったり、誤った状態で停止したりします。

---

推奨ユースケース3領域 📦

公式ドキュメントは "Example goals" セクションで3つの目標例を提示しており、それぞれが /goal の代表的な活用領域に対応しています。

この図のポイントは、3領域すべてに「明確な検証手段」がセットになっている ことです。Migrationsには視覚回帰テスト、Prototype creationにはマイルストーンテスト、Prompt optimizationにはevalスイート――いずれも機械的に判定可能なものが用意されています。

領域① Migrations（コード移行）

レガシースタックから新フレームワークへの移行は、/goal の最も自然な活用先です。各画面のビジュアル同一性を playwright interactive で検証しながら進めるパターンが、公式の Example goals に 抽象テンプレート として紹介されています。これを業務文脈に当てはめた具体例（私の現場ではこう書いています）はこちらです。

/goal Complete migration of all 47 screens listed in `MIGRATION_PLAN.md`
from Vue 2 to Vue 3 without stopping until `pnpm test:visual` and
`pnpm test:unit` both pass with zero failures.

ポイントは 対象スコープの上限を MIGRATION_PLAN.md で固定し、終わりを2つのテストコマンドで定義する こと。スコープを絞らないと「ついでにあれもこれも」になりがちです。

領域② Prototype creation（プロトタイプ作成）

ゲーム・新機能・一からのアプリ作成など、既存コードベースへの依存が薄い作業に向きます。公式は PLAN.md を先に書き、それに沿って各マイルストーンでテストを作り、Playwrightで挙動を確認する流れを Example goals で示しています。これを具体化した独自例がこちらです。

/goal Implement all milestones in `PLAN.md` for the canvas-based puzzle
prototype, writing tests at each milestone, without stopping until
all milestones are checked off and `pnpm e2e` passes.

PLAN.md を「作業範囲を表す契約書」として使うのがコツです。Codexは原則 PLAN.md の中だけを動き、新しいスコープを加えない――これが暴走防止の鍵になります。

領域③ Prompt optimization（プロンプト最適化）

evalスイートに対して反復実行し、評価スコアが基準を超えるまで続ける、という使い方です。プロンプトの調整は人間がやると気が遠くなりますが、機械的なevalがあれば停止条件が決まります。以下も公式テンプレートを具体化した独自例です。

/goal Iteratively improve `prompts/router.md` against `evals/router/`
without stopping until the average score in `evals/router/results.json`
is greater than or equal to 0.9.

ここでも 数値しきい値で停止条件を定義 している点が重要です。「品質を上げて」ではなく「スコア >= 0.9」と書く――これが /goal を成立させる書き方です。

3領域の共通パターン

3つを並べると、共通する型が見えてきます。

領域	作業範囲を縛る物	検証手段
Migrations	MIGRATION_PLAN.md 等のリスト	視覚回帰テスト（公式の例文では playwright interactive。必要に応じて単体テストも併用）
Prototype creation	PLAN.md のマイルストーン	テスト + e2e
Prompt optimization	対象プロンプトファイル	evalスイートの数値スコア

📝 検証手段の欄は、公式の Example goals 例文を基に筆者が一般化したものです。Migrations の中心は視覚回帰、Prompt optimization の中心は数値evalで、これらは公式記述に明記されています。

「作業範囲を縛るドキュメント ＋ 機械的な検証手段 をセットで渡す」――これが3領域すべてに通底するパターンです。

---

効果的な目標の書き方 ✍️

/goal を使いこなす上で、最大のスキルは 目標と停止条件をどう書くか です。同じ作業内容でも、書き方ひとつで成功率が大きく変わります。

良い目標 vs 悪い目標の構造比較

この図のポイントは、「悪い目標」は4要素すべてが曖昧で、「良い目標」は4要素すべてが具体的 だということです。1要素だけ強くしても効果は限定的で、4つを揃えるからこそ自律実行が成立します。

4要素チェックリスト

/goal を投入する前に、自分の文面を以下の4要素でチェックしましょう。

#	要素	質問
01	Objective	何を達成するのか1文で言えるか？
02	References	参照すべきファイルやドキュメントを明示したか？
03	Verification	機械的に実行できる検証コマンドを書いたか？
04	Stop Condition	「達成した」と判定する具体的な状態を書いたか？

すべてYESならGo、1つでもNOがあれば書き直します。

失敗しやすい書き方の例

実際にやりがちな失敗例を3つ挙げます。

❌ 失敗例1: 検証手段が主観的

/goal Refactor the user service until the code looks clean.

「looks clean」は機械判定できないため、Codexは終わりを判断できません。

❌ 失敗例2: スコープが無限

/goal Improve the entire codebase quality.

スコープが「entire codebase」と広すぎ、参照ファイルもなく、何をもって完了とするかが定義されていません。

❌ 失敗例3: 検証コマンドはあるが、スコープが定義されていない

/goal Add tests until coverage reaches 90%.

検証は具体的ですが、対象ディレクトリやテスト種別が指定されていないため、Codexがどこまで広げるかを暴走的に決めることになります。

✅ 改善例

/goal Add unit tests for files in `src/services/` only, without stopping
until coverage measured by `pnpm test:cov -- src/services/` is greater
than or equal to 90% line coverage and 80% branch coverage.

スコープ（src/services/ のみ）と数値しきい値（line 90% / branch 80%）が明示されました。

---

/goal の運用パターン 🔀

/goal は単独で使ってもいいのですが、開発フローに組み込むと真価を発揮します。私が推奨するのは 「PLAN.md → /goal → tests → human review」 の4ステップ運用です。

この図のポイントは、人間の役割が「最初の契約書（PLAN.md）作成」と「最後のマージ判断」だけに集中する ことです。中間の数時間は完全にCodex任せで、テストが番人として品質を担保します。

/goal と /workflow の使い分け（参考）

Codexには /goal と別に /workflow という機能も存在することが、別ページで言及されています。本記事のベースとした「Follow a goal」ページ自体には /workflow の比較記述は ありません。そのため、ここでは「/goal を使うべきかどうか迷ったときの考え方」として、私が運用しているざっくりした棲み分けの感覚を示すにとどめます。

⚠️ 以下の /workflow 列は 筆者による推測を含みます。「Follow a goal」公式ページに /workflow との比較記述はないため、/workflow の正確な仕様・適用領域は公式ドキュメントを直接ご確認ください。

観点	/goal（公式根拠あり）	/workflow（筆者推測）
想定する作業形態	単一の長期目標（公式: 検証可能な停止条件まで連続実行）	構造化された複数ステップ
終了条件	検証コマンドの成功（公式）	ステップ完了
動作時間	数時間レベル（公式: "multiple hours"）	短〜中時間
中間介入	基本不要（pause/resumeはあり、いずれも公式）	ステップ毎に介入余地
向いている例	Migrations / Prototype creation / Prompt optimization（公式 Example goals）	段階的な複数フェーズの作業

ざっくり言えば、「明確な終わりが1つに決まる仕事」は /goal と覚えておくのが、本記事の目的としては十分です。/workflow 側のフィット感は公式ドキュメントを当たって判断してください。

---

制約と注意点 ⚠️

/goal は強力ですが、向き・不向きがあります。公式ドキュメントが明示する 不適合ケース はこちらです。

Avoid using a goal for a loose list of unrelated work.

「関連性のない雑多な作業リストには使うな」と言い切られています。/goal は1つの大きな目標と1つの検証条件で動くため、寄せ集めのTODOには根本的に向きません。

適用判断フロー

実際に「これって /goal 案件？」と迷ったときの判断フローをまとめました。

この図のポイントは、4つのチェックすべてをYESで通過したケースだけが /goal の適用対象 ということです。検証手段がない場合、最初にやるべきは /goal を打つことではなく、検証手段を整備する ことになります。

よくある失敗とリカバリ

/goal 運用で起きがちな失敗を3つと、それぞれのリカバリ手段を挙げておきます。

症状	原因	リカバリ
何時間経っても止まらない	検証コマンドが永久に通らない／検証ロジックがバグっている	/goal pause で停止 → 検証コマンドを直接実行して原因確認
想定外のファイルを編集している	スコープがReferencesで縛られていない	/goal clear → References明記の上で再投入
進捗ログがほぼ進まない	目標が大きすぎる／途中の難所でスタック	/goal で状態確認 → 必要なら手動でヒントを与えてresume

/goal pause と /goal clear を遠慮なく使うのが、安心して任せるコツです。

デバッグTips

• 最初は 小さな目標 で試す。「1ファイルだけ移行する」「5%カバレッジを上げる」など、30分〜1時間で終わる規模から始める
• 投入前に検証コマンドを 手動で1回実行 し、それが「失敗するけど明らかに到達可能」な状態であることを確認する
• 重要なブランチ上で直接走らせるのではなく、必ずfeatureブランチを切ってから 投入する

---

まとめ 🏁

サマリー

/goal を使い倒すために覚えておきたいことを、3つに絞ります。

#	キーメッセージ
①	/goal は「目標 + 検証可能な停止条件」を1度だけ渡せば、数時間レベルの自律作業が成立する
②	成功の鍵は Objective / References / Verification / Stop Condition の4要素を揃える こと
③	雑多なTODOには使わない。「終わり」が機械的に判定できる仕事だけ が /goal の射程

明日からの最初の一歩

実際に試してみるなら、以下のミニマムな手順を推奨します。

1. 有効化: /experimental から goals をオンにするか、config.toml の [features] に goals = true を追加
2. 小さな対象を選ぶ: 30分〜1時間で終わる、検証コマンドが書きやすい作業（例: 1モジュールのテストカバレッジを80%まで上げる）
3. 4要素を書き出す: Objective / References / Verification / Stop Condition を、/goal を打つ前にメモ
4. 投入する: テンプレートに沿って /goal Complete ... without stopping until ... を打つ
5. 観察する: 30分後に /goal（状態確認）を打って、何が起きているか見てみる

おわりに

AIエージェントに長時間任せる運用は、これからの開発フローの主流になっていく流れです。/goal はそのための非常にミニマムで、しかし強力なインターフェースを提供してくれます。「目標と検証条件を明確に書く」というスキルさえ磨けば、本記事で紹介した3つの公式ユースケースに留まらず、自分の業務文脈に沿った独自の活用法を発見できるはずです。

/goal の構文は1行ですが、その1行を書くために必要な思考――作業範囲をどう縛るか、何をもって完了とするか、検証手段をどう用意するか――こそが、この機能の真価です。本記事が、その1行を書くためのチェックリストとして役立てば幸いです。

参考

• Codex Docs / Use cases / Follow a goal — 本記事のベースとした公式ドキュメント