Codex goalとは？/goalコマンドの使い方・/planとの違いを公式情報で整理
Codex goalとは、OpenAI Codexに「この目的を達成するまで進める」というゴールを持たせるGoal modeです。単発の依頼ではなく、ターンをまたいで目的を保持し、実装、検証、追加修正、報告までをゴールに沿って進めるために使います。
結論：Codex goal / Codex /goal は、Codexにターンをまたぐ目的と完了条件を持たせるコマンドです。/goal <objective>で設定し、/goalで現在のゴールを確認、/goal pauseで一時停止、/goal resumeで再開、/goal clearで解除します。/planが作業方針を整える入口なら、/goalはその方針を完了条件まで追いかけるための運用機能です。
本記事のポイント
- Codex goalは、Codexにターンをまたぐ目的と完了条件を持たせるGoal modeで、現在はCodex app、IDE拡張、CLIで利用できます。
- /goal <objective>で設定し、/goalで確認、/goal pauseで一時停止、/goal resumeで再開、/goal clearで解除します。
- /planは作業方針を整える入口、/goalはその方針を完了条件まで追いかける運用機能として分けると実務に組み込みやすくなります。
Codex goalとは何か
Codex goalは、Codexが現在追いかけるべき目的を明示し、その目的に沿って作業を続けるための機能です。公式のCodexドキュメントではGoal modeとして案内され、Codex app、IDE拡張、CLIで利用できる機能として位置づけられています。
たとえば「AEO分析レポートを作り、上位5記事の改善を実装し、検証まで終える」という作業は、1回の返答だけでは終わりにくいタスクです。途中で調査、ファイル編集、ビルド、差分確認、再修正が入ります。/goalは、このような長めの作業に対して、Codexが目的を見失わないようにするための指定です。
重要なのは、/goalが「何でも自動で正しく終える魔法」ではないことです。人間側が、達成条件、作業範囲、止め方、レビュー条件を明確に書くほど、Codexは判断しやすくなります。
| 確認対象 | 現在確認できる内容 | 実務での読み方 |
|---|---|---|
| Follow a goal | /goal <objective>、/goal、pause、resume、clearの使い方と、表示されない場合の有効化手順 | Goal modeの基本操作を確認する一次情報 |
| Codex app commands | /goalをCodexに持続的な目的を与えるコマンドとして案内 | Codex appでの位置づけを確認する |
| Codex CLI slash commands | /goalでタスクゴールの設定・一時停止・再開・確認・解除を行うと案内 | CLI利用時のコマンド一覧を確認する |
| Codex changelog | Goal modeが実験的機能ではなくなり、app、IDE拡張、CLIで利用できることを案内 | 古い「未掲載」情報を更新するときの根拠になる |
Codex /goalコマンドはどう使うか
基本形はシンプルです。まず/goalのあとに、Codexに追わせたい目的を自然文で書きます。目的は短くても動きますが、実務では「何が終わったら完了か」を入れる方が安定します。
1. /goal <objective>でゴールを設定する
ゴール設定では、目的、対象範囲、検証方法をまとめて書きます。良い例は、Codexが自分で達成判定しやすい形です。
/goal /media/codex-goal-command/ の古い情報を公式ドキュメントに合わせて更新し、route再生成、validate、build確認まで終える「記事を良くして」より、「どのURLを、何に合わせて、どの検証まで終えるか」を書く方が、途中の判断がぶれにくくなります。
2. /goalで現在のゴールを確認する
引数なしの/goalは、現在設定されているゴールの確認に使います。長い作業の途中で「今Codexは何を追っているのか」を見直すと、別作業へ寄り道しすぎていないか確認できます。
3. /goal pauseで一時停止する
/goal pauseは、ゴールを消さずに追跡を止める操作です。会議、レビュー待ち、別タスクの割り込みが入ったときは、いったんpauseしておくと、Codexが古い目的に引っ張られ続ける事故を減らせます。
4. /goal resumeで再開する
/goal resumeは、一時停止したゴールの追跡を再開します。中断前の目的を再利用できるので、長めの修正、調査、検証作業では、作り直しよりも安全です。
5. /goal clearで解除する
/goal clearは、現在のゴールを解除します。目的が完了したとき、別の目的に切り替えるとき、古いゴールが会話の邪魔になっているときに使います。pauseは一時停止、clearは解除、と分けて覚えると迷いません。
/goalと/planの違い
/planと/goalは似ていますが、使う場面が違います。/planは、作業前に方針、手順、リスク、確認方法を整理するための入口です。いきなり実装に入る前に、どの順番で進めるかを見たいときに向いています。
/goalは、その作業をターンをまたいで追いかけるための指定です。計画を出して終わりではなく、Codexに「この完了条件まで進めて」と持続的に渡すイメージです。
| 観点 | /plan | /goal |
|---|---|---|
| 主目的 | 作業方針と手順を整理する | 目的を保持し、完了条件に向けて作業を続ける |
| 向いている場面 | 新規実装、調査、設計判断の前段 | 複数ステップの実装、検証、修正、レポート作成 |
| 人間の関わり方 | 計画を見て進め方を判断する | 進捗を確認し、必要ならpause、resume、clearする |
| 実務での組み合わせ | まず/planで範囲と順序を決める | 合意した目的を/goalで追わせる |
実務では、まず/planで「何を、どこまで、どの順に進めるか」を整理し、そのうえで/goalに完了条件を渡す流れが扱いやすいです。特に本番環境、顧客データ、公開サイト、Git pushを含む作業では、計画とゴールを分けることでレビューしやすくなります。
Goal modeが表示されないときの確認
公式ドキュメントでは、/goalが表示されない場合に、Codexの設定でGoals機能を有効化する手順が案内されています。CLIではconfig.tomlのfeatures.goalsを確認するか、機能有効化コマンドを使います。
codex features enable goals組織管理の環境では、アプリ、IDE拡張、CLIのバージョン差や、管理者側の設定によって見え方が変わることがあります。チームで運用する場合は、使うCodexの入口、バージョン、設定ファイルの扱いをそろえてから手順書に落とし込むのが安全です。
業務で使うときの設計ポイント
Codex goalを業務に組み込むときは、コマンドの使い方よりも、ゴールの書き方と止め方が重要です。強いエージェント機能ほど、曖昧な目的のまま走らせると、成果物の範囲、実行コスト、確認責任が膨らみます。
1. 完了条件を検証可能にする
「最高レベルにする」「いい感じに直す」だけでは、Codexが完了を判断しにくくなります。「対象5URLのmetaと冒頭回答を更新」「route再生成」「validate-source成功」「build:verified成功」「公開URLがHTTP 200」のように、確認できる条件へ落とします。
2. 対象範囲を狭くする
ゴールは広すぎるほど失敗しやすくなります。サイト全体を直すより、GSCで機会損失が大きい記事5本、対象ファイル、検証コマンドを指定する方が、差分もレビューしやすくなります。
3. pauseとclearを運用に入れる
別作業に切り替えるときはpause、目的が終わったらclearを使います。ゴールを残したまま別件を依頼すると、Codexが古い目的と新しい依頼を同時に満たそうとして、意図しない広い変更につながることがあります。
4. 変更権限とレビュー条件を決める
Codex goalは、ファイル編集、コマンド実行、テスト、Git操作と組み合わせると強力です。そのぶん、本番公開、顧客データ更新、外部送信、削除操作などは、人間の確認を挟む境界を明確にします。AIエージェント運用では、AIエージェント ガバナンスや監査ログとセットで考えるべきです。
Codex goalに向いているタスク
Goal modeが向いているのは、1ターンで終わらず、複数の確認を積み上げる作業です。単純な質問や短い文章作成なら、普通に依頼するだけで十分です。
| 向いている作業 | ゴールに入れるべき完了条件 |
|---|---|
| 複数記事のSEO/AIO改善 | 対象URL、更新項目、route再生成、validate、build確認 |
| テスト失敗の修正 | 失敗しているコマンド、対象モジュール、全テスト成功 |
| フロントエンドの不具合修正 | 対象画面、再現手順、スクリーンショット確認、レスポンシブ確認 |
| レポート生成パイプラインの修正 | 入力データ、出力ファイル、再実行、差分確認 |
| GitHub PR対応 | 対応するレビューコメント、修正範囲、テスト、pushまたはPR更新 |
逆に、法務判断、採用判断、医療・金融の高リスク判断、顧客への送信、削除や権限変更を含む操作は、/goalで自走させる前に承認フローを設けるべきです。Codexが作業できることと、組織として任せてよいことは別です。
古い情報を見るときの注意
/goalは登場直後に、ChangelogやGitHub issueを中心に語られていた時期がありました。そのため古い記事では「公式slash commandsページには未掲載」「実験的機能」「特定バージョンでの不具合」といった説明が残っていることがあります。
2026年6月20日時点では、公式のCodexドキュメントで/goalが案内され、Goal modeはapp、IDE拡張、CLIで使える機能として整理されています。古い不具合情報を読むときは、現在のCodex docs、CLI slash commands、changelogを優先して確認してください。
よくある質問
Codex goalとは何ですか？
Codex goalとは、Codexにターンをまたぐ目的を持たせ、完了条件に向けて作業を続けさせるGoal modeです。/goal <objective>で設定し、作業途中でも現在の目的を保持できます。
Codex /goalコマンドはどう使いますか？
/goal <objective>でゴールを設定します。引数なしの/goalで確認、/goal pauseで一時停止、/goal resumeで再開、/goal clearで解除します。目的には対象範囲と検証方法を含めるのが実務向きです。
/goalと/planは何が違いますか？
/planは作業前に方針と手順を整理するための入口です。/goalは、その目的をCodexに保持させ、ターンをまたいで追いかけるための機能です。先に/planで範囲を決め、合意した作業を/goalにする流れが安全です。
Goal modeが表示されないときはどうすればよいですか？
Codexのバージョンと設定を確認します。公式ドキュメントでは、CLIでGoals機能が見えない場合にfeatures.goalsの設定やcodex features enable goalsによる有効化が案内されています。組織環境では管理者設定も確認してください。
業務で使うときの注意点は何ですか？
完了条件を検証可能にする、対象範囲を狭くする、pauseとclearを運用に入れる、変更権限とレビュー条件を決める、の4点が重要です。本番公開や顧客データ更新を含む作業では、人間の承認を必ず残します。
関連ページと関連記事
- Codex petsとは？/petの使い方とカスタムpetの作り方を解説
- Codex 自動化（オートメーション）完全ガイド
- Codex for (almost) everythingとは？Computer Use・OpenClaw・Claude Codeとの違いを整理する
- AIエージェント ガバナンスとは？権限、監査ログ、承認フローの設計を整理する
- AIエージェント監査ログテンプレートとは？権限・履歴・運用ルールの整理
CodexやAIエージェントの社内運用を整理したい場合
Codexの/goalのように、ターンをまたいで目的を追うエージェント機能を業務に取り込むときは、機能を試すだけでなく、完了条件、権限、レビュー、監査ログ、停止条件を同時に決める必要があります。ファネルAiでは、業務にAIエージェントを組み込む前提整理から、運用フローとガバナンス設計まで相談できます。
営業・マーケ運用へ使う場合
Goal modeを営業やマーケティングの定型業務に使う場合は、単にタスクをまとめるだけでなく、完了条件と次の担当者を明確にします。問い合わせの要約、資料請求後の確認、営業への受け渡しなどでは、MQL・SQL・SALの違いを基準にすると、AIの処理結果を運用に接続しやすくなります。
