Codexの/GOALはなくなった？Goal modeの現在と使い方
結論からいうと、公式案内上のGoal modeと小文字の /goal はなくなっていません。 ただし、使う画面によって開始方法が違い、WebではWorkへ役割が分かれているため「消えた」と感じやすくなっています。
本ページは現行のOpenAI公式マニュアルを確認し、旧ページを全面的に整理し直したものです。画面や提供範囲は更新される場合があります。
公式表記は /goal です。 デスクトップアプリ、対話型Codex CLI、IDE拡張で、長時間作業の目標と完了条件をタスクへ保持する機能として案内されています。
/goal 目標文 → 開始
/goal → 現在の目標を表示
/goal pause → 一時停止
/goal resume → 再開
/goalはどこで使える？
現行公式案内では、長時間作業の扱いが画面ごとに分かれています。同じ「長い仕事」でも、すべての画面で同じスラッシュコマンドを使うわけではありません。
デスクトップアプリ
入力欄で /goal を開始します。進行中は入力欄の上に進捗行が出て、一時停止、再開、編集、解除を操作できます。
対話型Codex CLI
対話セッションで /goal を入力します。同じセッションへ追加指示や状況確認を送りながら継続します。
IDE拡張
開いているワークスペースのチャットで /goal を使います。同じIDEチャットから条件変更や進捗確認を行います。
ChatGPT Web
ホスト型の長時間作業はWorkを選び、成果、制約、確認条件をプロンプトへ直接書きます。デスクトップ版と同じ操作を探す必要はありません。
なぜ「/GOALがなくなった」と見えるのか
画面ごとに役割が違う
WebではWork、デスクトップ・CLI・IDEではGoal modeという案内です。Web画面だけを見るとコマンドが消えたように見えます。
固定ボタンではなくコマンド
/goal は入力欄で呼び出す操作です。常に大きなボタンとして表示されるとは限りません。
公式表記は小文字
検索では「/GOAL」と書かれますが、公式マニュアルの表記は半角・小文字の /goal です。
/goalのコマンド一覧
表は横へスクロールできます。
| 入力 | 役割 | 使う場面 |
|---|---|---|
/goal 目標文 | 新しいGoalを開始 | 成果と完了条件が決まり、長い作業を始める時 |
/goal | 現在のGoalを表示 | 目的や進行状態を確認する時 |
/goal edit | 目標を編集 | 目的、範囲、完了条件そのものを修正する時 |
/goal pause | 一時停止 | 確認待ち、離席、接続を切る前に止める時 |
/goal resume | 再開 | 確認が終わり、同じGoalを続ける時 |
/goal clear | Goalを解除 | 完了後や、別の目的へ切り替える時 |
目標文は空にできず、公式マニュアルでは最大4,000文字です。長い仕様書、URL一覧、確認表はファイルへ分け、Goalから参照します。
Goalには「作業」ではなく「完了状態」を書く
「SEOを続けて」「サイトを良くして」だけでは、どこで終了するか判断できません。公式案内では、Outcome、Constraints、Verificationの3要素を入れる方法が示されています。
Outcome：成果
何を完成させるか。例：既存5ページを改善し、本番公開まで完了する。
Constraints：制約
変更禁止箇所、対象URL、使う道具、権限、避ける方法を指定する。
Verification：確認
テスト、画面幅、リンク状態、差分など、完了を証明する条件を書く。
サイト改善のGoal例
/goal codexguide.jpの既存5ページを改善し、本番公開まで完了する。 成果：各ページへ検索意図に合う本文と内部リンクを追加する。 制約：title、canonical、robots、GSCタグは変更しない。新規URLは作らない。 確認：事前バックアップ、全リンク200、390/768/1280px表示、sitemap重複なし。
Codexの目標設定を5段階で作る
/goalへ書くのは、長いお願い文ではなく「どの状態になれば完了か」を判断できる目標です。成果、範囲、制約、確認方法、停止条件を順番に決めると、途中で作業が広がりにくくなります。
成果を1文で決める
「調べる」「改善する」ではなく、完成するページ、ファイル、公開状態、テスト結果などを指定します。
対象と対象外を分ける
対象URL、repo、フォルダ、ファイルを列挙し、変更しないページや設定も明記します。
守る条件を決める
既存デザイン、互換性、title、canonical、robots、個人情報、権限などの制約を書きます。
完了の証明を決める
テスト成功、リンク200、差分確認、画面幅、公開URL、件数など、確認できる基準を置きます。
止まる条件を決める
削除、外部送信、本番公開、契約、課金、Secrets、対象外変更が必要になったら停止して質問させます。
悪い目標と良い目標の違い
表は横へスクロールできます。
| 曖昧な目標 | 問題 | 確認できる目標 |
|---|---|---|
| サイトを良くする | 対象と終了地点がない | 指定3ページの本文と内部リンクを改善し、公開後に全リンク200を確認する |
| SEOを続ける | いつまでも完了しない | Search Consoleの上位10クエリを分類し、既存受け皿5ページだけ補強する |
| エラーを全部直す | 範囲と優先順位がない | 現在失敗しているテストを再現し、原因箇所を修正して対象テストを通す |
| 安全に公開する | 安全の意味が不明 | バックアップ、差分、390/768/1280px表示、内部リンク、sitemapを確認してから公開する |
習熟度と仕事の種類で書き分ける
初心者：一つの成果だけを目標にする
最初は1ページ、1機能、1レポートなどに限定します。途中で別の依頼を思いついたら、現在のGoalへ混ぜず、完了後に別タスクへ分けます。
例：「お問い合わせページの送信エラーを修正し、テスト送信が成功するところまで。ほかのページは変更しない」
中級者：工程ごとの確認を入れる
調査、実装、テスト、公開を分けます。「原因判明時」「差分作成後」「公開前」で状況を報告させると、長い作業を途中で修正できます。
例：「対象5URLを確認し、改善案を一覧化した時点で報告。その後、承認したページだけ変更し、公開前に差分とリンク確認結果を提示する」
上級者：並列作業と復旧条件を設計する
独立タスクは別Goalとworktreeへ分け、同じファイルや公開先を同時に変更させません。失敗時のロールバック、タイムアウト、ログ、依存タスクも完了条件へ含めます。
例：「3サイトを別タスクで監査する。変更は行わず、共通の分類表へ結果を統合する。同一FTPルートへの書き込みは禁止」
仕事・業務：誰が承認し、何を証拠として残すかを書く
成果物だけでなく、担当者、承認者、使用資料、情報区分、保存先、公開可否を決めます。契約、支払、法務判断、個人情報、顧客送信は人間確認を完了条件へ入れます。
例：「社内限定資料から月次報告書の初稿を作る。数値に出典と基準日を付け、個人情報は表示しない。外部送信せず、部門責任者レビュー待ちで完了とする」
進行中は「残り」と「完了の証拠」を確認する
- 現在完了した項目
- 残っている項目と次に行う操作
- 目標外へ広がった作業がないか
- 承認待ち・質問待ちの内容
- テスト、差分、公開URLなど完了の証拠
/goal [完成させる成果]
対象：[URL・repo・フォルダ・ファイル]
対象外：[変更しない場所]
制約：[守る仕様・権限・禁止操作]
中間確認：[どの段階で報告するか]
完了条件：[テスト・件数・表示・公開確認]
停止条件：[削除・送信・公開・課金・Secretsなど]
完了報告：[変更点・証拠・未解決事項]現在の公式案内では、Goalはデスクトップアプリ、対話型Codex CLI、IDE拡張で使い、Web上の長時間作業ではWorkへ成果・制約・確認基準を直接書きます。詳細はOpenAI公式「Long-running work」で確認できます。
/plan・通常タスク・Work・スケジュールとの違い
表は横へスクロールできます。
| 機能 | 役割 | 選ぶ目安 |
|---|---|---|
| 通常タスク | 一回の明確な依頼を実行 | 小さな修正、調査、1ページ確認など |
/plan | 実行前に質問し、手順と条件を整理 | 要件や優先順位がまだ曖昧な時 |
/goal | 成果と完了条件を保持して長い作業を継続 | 工程が多く、途中確認しながら最後まで進める時 |
| Work | Web上で資料、分析、表計算などの完成物を作る | コード変更より業務成果物が中心の時 |
| スケジュール | 決まった時刻や周期で作業を開始 | 毎日、毎週、指定日時の確認や更新 |
迷った時： 要件が曖昧なら /plan、明確な長期成果なら /goal、Webで業務成果物を作るならWork、繰り返しならスケジュールを選びます。
Goal modeを使う3つの実例
複数ページのサイト改善
URL確認、本文改善、内部リンク、sitemap、公開確認まで工程が続くため、完了条件を固定するGoal向きです。
コード移行・大規模修正
既存動作を保ち、コンパイルとテストを通すなど、検証可能な終了条件がある作業に向きます。
多数URLの監査と整理
対象一覧、分類ルール、変更禁止条件、最終確認を決め、途中結果を残しながら進めます。
使わない方がよい場面： 1つの質問、1ファイルの軽微修正、数分で終わる確認は通常タスクで十分です。Goal modeは長さではなく、目的を保持し続ける必要があるかで選びます。
実行中の変更・停止・並行作業
同じタスクで追加する
資料や条件を追加するだけなら、同じタスクへメッセージを送ります。目的自体を変える時は /goal edit を使います。
判断前に止める
公開、送信、削除、広い権限が必要になる前に停止条件を置きます。離席や接続を切る前はpauseを使います。
説明だけ聞く
主作業を止めず状況説明だけ聞きたい場合は、対応画面でside conversationを使うか、同じタスクで状況報告を求めます。
独立作業だけ並行する
複数Goalは別タスクへ分けます。同じファイルを同時に書き換えず、コード作業ではworktreeで作業場所を分離します。
Goal modeでも権限と承認は別管理
Goalを開始しても、サンドボックスや承認方針は変わりません。「長く任せる」ことと「広い権限を与える」ことは別です。
通常は承認あり
読み取りと限定した編集から始め、外部送信、公開、削除、資格情報、広いネットワークアクセスは必要な時だけ確認します。
最後は人が確認
Git差分、テスト、公開URL、ログ、変更したファイル、未完了事項を確認してからGoalをclearします。
/goalが表示されない・動かない時の確認
1. 小文字で入力する
半角の /goal を入力し、候補を絞ります。検索語の「/GOAL」と公式コマンド表記を分けます。
2. 画面を確認する
デスクトップ、対話型CLI、IDEなら/goal、ChatGPT Webのホスト作業ならWorkを使います。
3. 対話セッションで使う
CLIでは入力欄がある対話セッションで実行します。一回実行型のコマンドとは操作が異なります。
4. 同じタスクを続ける
Goalは現在のタスクへ付くため、別タスクへ移ると同じ目標としては扱われません。関連作業は同じタスクで続けます。
今回確認した公式情報
- Long-running work：対応画面、開始、完了条件、途中変更、並行作業。
- Codex CLI slash commands：/goalの表示・編集・停止・再開・解除、4,000文字上限。
- IDE extension slash commands：IDE上の/goal対応。
- Goal mode and prompting：Goalの書き方。
- Get started with Work：Web上の日常業務・成果物の委任。
- Sandboxing and approvals：権限と承認。
- Projects, chats, and tasks：関連タスクと文脈の整理。
- Scheduled tasks：繰り返し作業との違い。
Goal modeの実務別ガイド
FAQ
Codexの/GOALはなくなったのですか？
2026年7月17日時点の現行公式マニュアルでは、/goalは廃止されていません。デスクトップアプリ、対話型Codex CLI、IDE拡張で、長い作業の目標を固定するGoal modeとして案内されています。
/GOALと/goalはどちらを入力しますか？
公式表記は小文字の/goalです。コマンド候補を確実に出すため、半角・小文字で/goalと入力してください。
ChatGPTのWeb版でも/goalを使えますか？
公式案内では、Web上の長時間作業はChatGPT Workを使い、成果、制約、確認基準をプロンプトへ直接書く方法が案内されています。デスクトップアプリや対話型CLIと同じ操作とは限りません。
/planと/goalは何が違いますか？
/planは実行前に手順や条件を整理するためのモードです。/goalは決めた成果と完了条件をタスクに保持し、長い作業を継続するために使います。要件が曖昧なら/planで整理してから/goalへ進めます。
Goal modeを使うとフルアクセスになりますか？
なりません。Goal modeを開始しても、現在のサンドボックスと承認方針が維持されます。必要な操作で判断が必要になれば停止して確認を求めます。
Goal modeの途中で指示を追加できますか？
同じタスクで追加情報や制約を送れます。目的自体を変える時は/goal edit、いったん止める時は/goal pause、再開は/goal resumeを使います。
複数のGoalを同時に動かしても大丈夫ですか？
独立したタスクなら並行できます。ただし同じファイルや同じ公開先を複数タスクから変更しないよう、担当範囲を分けます。コード作業ではworktreeを使うと衝突を減らせます。
Goalの文章が長い場合はどうしますか？
公式マニュアルでは目標文は4,000文字までとされています。長い仕様や確認表はファイルへまとめ、/goalからそのファイルを参照する形にします。
OpenAI Startup Drop / 2026年7月
長時間のCodex作業をGoal・subagents・検証で組み立てる
/goalに入れる4要素
Goal: 完成させる成果
Context: 現在の状態と参照資料
Constraints: 触らない範囲、承認が必要な操作
Done when: テスト、公開確認、報告などの完了条件たとえば「SEO上位表示」のように外部結果と時間経過が必要な目標は、そのままでは完了判定できません。「対象ページを改善し、公開URLが200、メタデータ維持、内部リンク確認、計測開始まで」を今回のGoalにし、順位上昇は観測期間の指標として分離します。
subagentsに分けやすい仕事
同じファイルを同時に編集する作業や、直前の判断で次の手順が変わる作業は分割しすぎない方が安全です。subagentsの結果は、メインスレッドが採否を判断して一つの変更へまとめます。
PR Chat・Browser・Chromeを使う場面
| 機能 | 向いている用途 | 注意点 |
|---|---|---|
| PR Chat | レビュー後の追加修正や確認をCodex内で続ける | ブランチ保護と人間のレビューを残す |
| Built-in Browser | 独立したブラウザ環境で表示や操作を確認する | ログイン状態や許可範囲を確認する |
| Chrome extension | 現在のChromeのログイン済みタブを使う | 既存セッションへアクセスするため、対象タブを絞る |
| Computer Use | ブラウザ以外を含む複数アプリの長い操作 | 外部書き込みや破壊的操作の前に承認を置く |
Sitesは保存と本番公開を分ける
SitesではWebサイトやアプリを作成できますが、デプロイしたURLは本番環境です。まずバージョンを保存してレビューし、内容、権限、表示、リンクを確認してから公開します。公開後はデスクトップとモバイルの両方で確認します。
長時間作業の完了ループ
- GoalとDone whenを設定する
- 探索・実装・検証のうち、独立部分だけを並行化する
- メインスレッドで結果を統合する
- テストや公開確認で失敗した箇所を修正する
- 同じ確認を再実行し、証拠をそろえて完了する