Codexの/goalとは？使い方・設定・注意点を解説

Codexの/goalとは？長時間タスクを最後まで進める使い方・設定・注意点を解説

Codexの/goalは、長時間かかる実装、移行、リファクタリング、検証ループに「達成条件つきの目標」を設定するための機能です。通常の1ターンの依頼ではなく、Codexに継続的な作業目標を持たせたいときに使います。

Codex CLI /goal AIエージェント長時間タスク

この記事では、Codexの/goalの基本、CLIでの使い方、どんなタスクに向いているか、失敗しにくい目標文の作り方、注意点を実務向けに整理します。

前提：本記事は2026年5月26日時点のOpenAI公式Codexドキュメントをもとにしています。Codexの/goalは環境やバージョンによって表示・設定方法が変わる可能性があります。利用前に最新の公式ドキュメントと自分のCodex CLIの状態を確認してください。

Codexの/goalとは？

/goalは、Codexに「この作業は何が終わった状態なのか」を明示するためのスラッシュコマンドです。OpenAI公式ドキュメントでは、長時間作業に対して持続的な目標を与える機能として説明されています。

通常のプロンプトは、1回の依頼に対してCodexが作業して返答する形です。一方/goalは、複数ターンにまたがる作業、再開される可能性のある作業、検証しながら進める作業に向いています。

一言でいうと：/goalは「Codexに長期目標と停止条件を渡すコマンド」です。作業を丸投げする魔法ではなく、何を達成し、何を変えず、どう検証し、いつ止まるかを決めるための仕組みです。

基本コマンド

Codex CLIの公式スラッシュコマンドでは、/goalには次の操作があります。

コマンド	役割	使う場面
`/goal <objective>`	現在のスレッドに目標を設定する	長時間作業を始めるとき
`/goal`	現在の目標を確認する	何を目標に走っているか確認したいとき
`/goal pause`	目標を一時停止する	調査や方向転換のために止めたいとき
`/goal resume`	一時停止した目標を再開する	元の作業に戻るとき
`/goal clear`	目標を削除する	作業完了後、別タスクへ移るとき

公式ドキュメントでは、目標はアクティブなスレッドに紐づき、作業が続く間Codexがその目標を保持すると説明されています。また、目標文は空では使えず、上限は4,000文字です。長い仕様は/goalに直接詰め込まず、ファイルに書いて参照させるのが推奨されます。

有効化が必要な場合

/goalがスラッシュコマンド一覧に出てこない場合は、Codex CLI側でGoals機能が無効になっている可能性があります。OpenAI公式ドキュメントでは、config.tomlに次の設定を追加する方法が案内されています。

[features]
goals = true

また、CLIから次のコマンドで有効化できる場合もあります。

codex features enable goals

環境によっては/experimentalから機能を切り替える導線が用意されている場合もあります。表示されないときは、まずCodex CLIのバージョン、設定ファイル、公式Docsの最新表記を確認しましょう。

/goalが向いているタスク

/goalは、すべての作業に使うものではありません。OpenAI公式ドキュメントでは、明確な成功条件と検証ループがある長時間作業に向いていると説明されています。

向いている作業	理由	停止条件の例
コード移行	対象範囲、互換性、テストが明確になりやすい	新実装が既存テストと契約テストを通る
大きめのリファクタリング	段階的に直し、各チェックポイントでテストできる	公開APIを変えず、関連テストが通る
CI修復ループ	失敗ログを読み、修正し、再実行する流れが明確	対象ジョブが緑になる
プロトタイプ作成	PLAN.mdなどをもとに複数マイルストーンを進められる	ビルドでき、主要画面が期待どおり動く
プロンプト最適化	評価セットを回し、失敗例を見て改善できる	evalの目標スコアに到達する

反対に、関係ない作業をまとめた雑なTODOリスト、成功条件が曖昧な調査、途中判断が多すぎる企画作業には向きません。

良い/goalの書き方

良い/goalは、単なる願望ではなく、作業契約です。公式ドキュメントでは、良い目標は1つのプロンプトより大きく、開かれたバックログより小さく、達成内容、変更禁止範囲、検証方法、停止条件を定義すべきだと説明されています。

基本形

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

これを実務向けにすると、次の4点を入れると安定します。

何を達成するか
何を変えてはいけないか
どのコマンドや成果物で検証するか
どの状態になったら止まるか

良い例：移行タスク

/goal Migrate the authentication pages from the legacy router to the new app router.
Keep the public UI and auth behavior unchanged.
After each checkpoint, run npm test and npm run build.
Stop when the migrated pages pass tests, build succeeds, and the old route can be removed safely.

良い例：CI修復

/goal Fix the failing GitHub Actions job documented in logs/ci-failure.md.
Read the failure log first, make the smallest necessary changes, and rerun the affected tests.
Stop when the same test command passes locally or when the next blocker requires external credentials.

悪い例

/goal Make this project better

このような目標は広すぎます。Codexが何を優先し、どこで止まればよいか判断できません。

長い仕様はファイルに分ける

/goalの目標文には4,000文字の上限があります。さらに、長い仕様を1行のコマンドに押し込むと、読みづらく、後から修正しにくくなります。

大きな作業では、PLAN.mdやGOAL.mdを作り、そこに要件、チェックポイント、検証コマンド、停止条件を書いておくのがおすすめです。

# GOAL.md

## Objective
Move the billing settings UI to the new settings layout.

## Must not change
- Existing billing API endpoints
- Public labels and Japanese copy
- Stripe webhook behavior

## Validation
- npm test
- npm run build
- Playwright check for /settings/billing

## Stop condition
- Tests pass
- Build passes
- Billing settings screen matches the current behavior

そのうえで、/goalには短く参照を書きます。

/goal Implement GOAL.md. Work in checkpoints, keep changes minimal, and stop when all validation steps pass.

進捗報告のさせ方

長時間実行では、進捗報告が曖昧になると信頼しにくくなります。OpenAI公式ドキュメントでは、現在のチェックポイント、検証済みの内容、残作業、ブロック有無がわかる短い進捗報告が有用だと説明されています。

/goal設定時に、次のような一文を入れておくと実務で扱いやすくなります。

After each checkpoint, report:
1. current checkpoint
2. files changed
3. validation command and result
4. remaining work
5. whether you are blocked

特に、ビルドやテストの結果を「実行したか」「通ったか」「失敗したならどこで失敗したか」まで書かせると、途中確認が楽になります。

/goalと通常プロンプトの違い

項目	通常プロンプト	/goal
作業単位	1回の依頼	複数ターンにまたがる目標
向いている作業	小さな修正、質問、単発調査	移行、リファクタ、CI修復、長い検証ループ
必要な情報	今やってほしいこと	達成条件、禁止事項、検証方法、停止条件
管理方法	会話で都度指示する	`/goal`で確認、停止、再開、削除する

小さな変更に毎回/goalを使う必要はありません。普通のプロンプトで済む作業は普通に依頼し、長い作業だけ/goalに切り替えるのが現実的です。

使うときの注意点

1. 目標を広げすぎない

「アプリ全体を改善して」のような目標は危険です。Codexが関係ないファイルまで触り、レビューしづらい差分になる可能性があります。対象ディレクトリ、対象画面、対象テストを絞りましょう。

2. 削除・本番操作は慎重に扱う

/goalは長時間作業に向いているため、実行権限が強い環境では影響範囲も大きくなります。本番DB、外部API、課金処理、削除処理を含む作業では、人間の確認ポイントを明示してください。

3. 完了後はclearする

作業が終わったら/goal clearで目標を削除します。古い目標が残っていると、次の会話や作業の判断に影響する可能性があります。

4. 途中で方向転換するならpauseする

別案の調査や要件変更が入ったら、まず/goal pauseします。元の目標に戻るなら/goal resume、目標自体が変わったなら/goal clearして新しく設定します。

実務用テンプレート

迷ったら、次の形を使うと失敗しにくいです。

/goal Complete [task name].
Scope: only change [files/directories/features].
Do not change: [public API, UI copy, schema, unrelated files].
Read first: [PLAN.md, issue URL, logs, docs].
Validation: run [commands] after each checkpoint.
Progress: keep reports compact with changed files, verification result, and remaining work.
Stop when [specific verifiable condition] is met, or pause if [blocker condition] appears.

このテンプレートのポイントは、Codexに「自由に頑張って」ではなく、「この範囲で、こう検証し、ここまで来たら止まる」と伝えることです。