Codex・Claude Codeの/goalと/planの使い分け
この記事で学べること
/planと/goalを、方法の確定状況と継続実行の必要性で選ぶ判断基準- 各コマンドに向く作業・向かない作業と、Plan・Goalを書くテンプレート
- 使用するAIモデルと考える深さ、利用量の上限、人の承認点を含めた併用手順
/planは進め方を決め、/goalは完了条件まで続ける
実行方法が未確定なら/plan、方法が合意済みで複数ターンの継続が必要なら/goalを使います。古い記事を新しい形式へ移す場合も、順序や保護範囲が未確定なら/planで進め方を作り、承認後の反復作業を/goalへ渡します。この「方法の確定度」と「継続の必要性」が、CodexとClaude Codeの両方で使える中心的な判断軸です。
この記事では、「進め方を決める/planと、完了まで続ける/goalをいつ切り替えるか」という問いに焦点を当て、選択を分ける比較軸、向いている条件、選択後の確認事項を扱います。
最後まで読むと、「進め方を決める/planと、完了まで続ける/goalをいつ切り替えるか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
/planは方法を設計し、/goalは合意した目的を維持する
/planは変更前に方法を調査・設計するコマンド、/goalは合意した目的を複数ターンで維持するコマンドです。前者の成果物はレビュー可能な計画、後者の成果物は検証済みの変更や文書です。
| 観点 | /plan | /goal |
|---|---|---|
| 答える問い | 何を、どの順序で、どのリスクに注意して行うか | 何を完了状態として、どこまで継続するか |
| 主な段階 | 調査、選択肢比較、設計、影響範囲の確認 | 実装、執筆、反復修正、検証 |
| 人の確認点 | 方針、範囲、受け入れ条件を承認する | 例外、権限が必要な操作、最終成果物を承認する |
| 終了状態 | 実行可能でレビュー済みの計画 | テスト、数値、件数、成果物で確認できる結果 |
| 単独で使う例 | 設計案の比較だけが必要 | 方法が既に承認済みの定型移行 |
| 併用する例 | 複雑な作業の方法を先に固める | 承認した計画を検証可能な完了条件まで実行する |
/planと/goalは競合する機能ではありません。計画と実行の責任を分けるために、同じタスクの異なる段階で使うと効果的です。
/goalは「終わり方」を先に決める
/goalとは、コーディングエージェントに複数ターンで維持する目標と停止条件を設定するコマンドです。通常の依頼より長く作業を継続させるため、作業内容だけでなく「何をもって完了とするか」を先に定義します。
| 項目 | Codex | Claude Code |
|---|---|---|
| 主な役割 | アクティブなチャットに永続的な目標を付ける | 完了条件が成立するまでターンを継続する |
| 基本操作 | 設定、表示、編集、一時停止、再開、解除 | 設定、表示、解除 |
| 終了判定 | Goal本文を最初の依頼と完了条件として進捗を判断 | 各ターン後に別の小型モデルが会話記録を評価 |
| 向く規模 | 1回の依頼より大きく、終わりが決まっていない仕事一覧より小さい作業 | 複数回のやり取りを要し、会話上の証拠で完了を確認できる作業 |
CodexのGoal
Codexでは、/goal <objective>で目標を設定し、/goalで状態を確認します。Goal本文は最初の依頼であると同時に、完了を判断する基準にもなります。設定後は編集、一時停止、再開、解除ができ、コードの移し替え、動作を保ったまま内部構造を大きく整理する作業、実験、試作品、採点結果を使った改善などに使えます。[1][2]
Claude CodeのGoal
Claude Codeでは、/goal <condition>で完了条件を設定します。各ターンの終了後、デフォルトではHaikuを使う小型の評価モデルが条件を確認し、未達なら次のターンを開始します。[4] Claude Code v2.1.139以降で利用でき、1セッションにつき1つのGoalを設定できます。[4]
重要な制約は、評価モデルがファイルを読んだりコマンドを実行したりしない点です。評価対象は会話に出た情報だけなので、テスト結果や確認コマンドの出力をClaude自身が会話へ示す必要があります。また、/goalは権限を変更しません。許可されていない操作が必要になれば、通常どおり承認待ちになります。[4]
/planは「進め方」を実行前に確認する
/planとは、実装や本文変更を始める前に、調査結果、選択肢、実行順序、検証方法を計画として提示させるコマンドです。要件を自動的に確定するものではなく、人が方針を確認するための判断材料を作ります。
CodexのPlan
Codexでは、/planでアクティブなチャットをPlan modeへ切り替えます。/plan Propose a migration plan for this serviceのように依頼を同じ行へ書けるほか、文章の貼り付けや画像添付も可能です。Codexが作業中の間は、このコマンドを利用できません。[2]
公式リファレンスは、Plan modeの目的を実装前に実行計画を提案させることだと説明しています。[2] 計画へ含めたいファイル、制約、決定事項、未決事項は最初に渡します。
Claude CodeのPlan
一方、Claude Codeでは/plan [description]でPlan modeへ入ります。[5] このモードでは、Claudeがファイルを読み、調査用コマンドを実行し、計画を作ります。通常はソースを編集せず、計画を承認した後に選択した権限モードへ移って実装を始めます。[6]
文字だけで操作する画面ではShift+Tab、コード編集画面やデスクトップアプリではモード選択から切り替えられます。計画を承認せずに追加調査を依頼することも、計画を直接編集することもできます。[6] ただし、bypassPermissions（操作前の権限確認を省略する設定）が利用可能な作業ではPlan modeの編集抑止が強制されないため、計画段階の安全境界として使う場合は避ける必要があります。[6]
進め方が未確定なら/planを使う
/planは、変更前に判断を集約する価値がある場合に使います。本記事では、次のいずれかに当てはまる作業を候補とします。
- 影響範囲が不明: 変更対象、依存関係、既存テストを先に調べる必要がある
- 複数の方法がある: アーキテクチャ、構成、移行順序の比較が必要である
- 失敗した場合の影響が大きい: 外部サービスとの接続方法、データ、本人確認、公開文書の主張へ影響する
- 人の合意が必要: 製品要件、文書の論旨、変更禁止範囲を実行前に確認したい
- 後続作業へ引き渡す: 別セッション、別担当者、または
/goalが迷わず実行できる計画が必要である
良いPlanは作業項目の一覧だけではありません。調査で確認した事実、採用案と不採用案、影響するファイル、確認方法、問題時に元へ戻す方法、人へ確認する点を区別します。
進め方の確定度と継続の必要性で/goalと/planを選ぶ
使い分けは、方法の不確実性と反復の必要性で判断できます。
| 状態 | 推奨 | 理由 |
|---|---|---|
| 方法も完了条件も明確で、1回で終わる | 通常の依頼 | モードを切り替える利点が小さい |
| 方法は未確定だが、実行はまだ不要 | /plan | 選択肢と影響範囲をレビューできる |
| 方法は承認済みで、複数回の修正と検証が必要 | /goal | 完了条件を維持して反復できる |
| 方法が未確定で、実行も長い | /plan → 承認 → /goal | 設計判断と継続実行を分離できる |
| 時刻や間隔で再実行する | 指定時刻に動く処理または/loop | 目標や計画ではなく時間が再開条件になる |
| 元に戻せない操作を含む | PlanとGoalを準備まで使い、人が実行 | 人が確認する境界を維持できる |
/goalが向く仕事の条件
本記事では、次の6条件がそろう作業を/goalの候補とします。これは公式仕様を踏まえた、私の判断用チェックリストです。
- 通常の1ターンでは終わらない: 調査、修正、検証を複数回繰り返す
- 目的を1つに絞れる: 複数の無関係な依頼を含めない
- 終了状態を測定できる: テスト結果、終了コード、件数、スコアなどで判定できる
- 検証方法を実行できる: エージェントが必要なファイル、コマンド、ログへアクセスできる
- 途中の判断を委ねられる: 毎回、人が製品要件や設計方針を決めなくても進められる
- 停止上限を置ける: ターン数、時間、試行回数、変更範囲のいずれかで制限できる
判断の中心は、長さではなく検証可能性です。数時間かかる作業でも、完了条件が「十分に良くする」だけでは停止判断が安定しません。反対に、作業量が大きくても同じテストを成功基準にできれば、Goalへ移しやすくなります。この考え方は、検証結果を基に修正を繰り返すコーディングエージェントの自己修復ループとも共通します。
日英同期・プロンプト改善・仕事一覧は/goalで継続しやすい
/goalに向くのは、反復する理由と完了を証明する方法がセットになった作業です。
日英ドキュメントの同期
/goal docs/guide配下の公開用日英ドキュメントを同期する。
完了条件は、翻訳プレースホルダーがなく、見出し数、表数、コードブロック数が一致し、リンク検査が成功すること。
本文の主張、公開URL、公開状態は変更しない。
機密情報や非公開資料が必要になった場合、または10ターンで完了しない場合は停止して報告する。公開用の文書だけを対象にし、構造、リンク、プレースホルダーを機械的に検証できるため、複数ターンの継続に意味があります。非公開資料が必要になった時点で停止させることで、Goalの継続判断と人による情報管理の判断を分けられます。
評価スコアを使ったプロンプト改善
/goal prompts/support.mdを改善し、評価スイートの合格率を92%以上にする。
各変更後にnpm run eval:supportを実行する。
テストデータとgraderは変更しない。
20回試して未達の場合は、失敗パターンを整理して停止する。OpenAIの公式ガイドにも、評価結果を確認しながらプロンプトを変更し、目標スコアまたは停止条件まで反復する例があります。[1] grader（出力を採点する仕組み）を変更禁止にするのは、評価基準自体を書き換えて目標を達成したように見せないためです。
範囲が決まった仕事一覧の処理
/goal label:docs-readyのIssueをすべて確認し、各Issueに対応する変更案またはブロック理由を用意する。
マージ、公開、Issueのクローズは行わない。
対象キューが空になった時点で、変更一覧と未解決事項を報告する。有限のキューと空になった状態を確認できるため、終了条件を作れます。外部への書き込みや公開を除外すれば、長時間作業と人の承認を分離できます。
/goalが向かないケース
次の作業では、通常の依頼、/plan、定期実行、または人の判断を優先します。
- 1回で終わる質問や軽微な修正: 継続判定を加える利点が小さい
- 主観的な改善: 「もっと良いUIにする」「品質を高める」だけでは終了を測定できない
- 無関係な作業の一覧: 1つのGoalの途中で優先順位と判断基準が変わる
- 機密性の高い作業: 資格情報、顧客データ、アクセス制御、本番環境を扱う作業はGoalの自律継続から外す
- 承認が中心となる操作: 本番公開、購入、メッセージ送信、データ削除は人の確認点を先に設ける
- 要件がまだ決まっていない実装: 先に
/planや通常の会話で選択肢と受け入れ条件を決める - 時間を空けて状態を監視する作業: 時間間隔で再開する
/loopや指定時刻に始まる処理が適する - 外部状態だけで完了が決まるClaude Codeの作業: 会話へ証拠を出せないと評価モデルが判定できない
不可逆な操作は、「準備までは継続し、実行前に停止する」と分けます。Goalは自律性を高めますが、承認範囲まで広げるコマンドではありません。
/planが向かないケース
/planは変更前の不確実性を減らすための手段です。次の作業では、計画自体が余分な工程になりやすいと考えます。
- 答えだけが必要な質問: 調査結果や説明を直接依頼すればよい
- 方法が固定された小さな変更: 受け入れ条件を通常の依頼へ書けば足りる
- 決定権者が不在の要件整理: Planは選択肢を示せても、事業判断を代行できない
- 実行しない長期方針: 会話内のPlanより、設計判断の記録や正式な企画書として保存する方が適する
- 緊急復旧中の既知手順: 承認済みの定型作業手順があるなら、その手順と停止条件を優先する
Planを長くしすぎると、実装中に発見した事実を反映しにくくなります。変更順序と検証は具体化しつつ、関数単位の編集内容まで固定しない方が、実行時の適応余地を残せます。
PlanとGoalは短いテンプレートで書ける
Planには判断事項・制約・検証方法を書く
良いPlanは、調査範囲、決定事項、選択肢、検証、承認点を分けます。実装を始めないことも明示すると、計画レビューへ集中できます。
/plan [目的]を実現する方法を調査して計画する。まだ変更は行わない。
[対象ファイル、資料、仕様]を確認する。
採用案、不採用案と理由、影響範囲、実行順序を示す。
[テスト、レビュー、測定値]を受け入れ条件にする。
[権限、公開、削除、要件判断]は人の承認点として分ける。
不明点は推測で確定せず、計画の未決事項として示す。Goalには目的・完了条件・停止条件を書く
良いGoalは、目的、検証、制約、停止条件の4要素で書けます。OpenAIの長時間作業ガイドも、単に計画を実装させるより、期待動作、レビュー条件、制約、明確な完了定義を与える方が強いGoalになると説明しています。[1]
/goal [1つの目的]を達成する。
完了条件は[コマンド、測定値、件数、成果物]で確認する。
[変更禁止範囲、互換性、権限境界]を維持する。
[人の判断が必要な条件]では停止して報告する。
[ターン数、時間、試行回数]の上限でも停止する。計画ファイルを使う場合も、「PLAN.mdを実装する」だけで終わらせず、受け入れ条件をGoal側または計画内に残します。私は、/planで方法を決め、人が範囲を確認したあとに/goalへ切り替える順序が扱いやすいと考えています。
AIモデルと考える深さの選び方
AIモデルはGoalの長さだけでなく、判断の難しさと失敗した場合の影響で選びます。effortはAIが回答前にどの程度深く考えるかを調整する設定です。以下は各社の公式な位置づけを基にした本記事での推奨で、実際に選べるモデルは契約プランや利用環境によって異なります。
Codexは不確実性とリスクに合わせてモデルと推論深度を選ぶ
Codexの既定のPower設定はGPT-5.6 Solのmediumです。Solは複雑で答えが一つに決まらない作業、Terraは日常的な実装、Lunaは手順が決まった反復作業に向きます。まず、目的を満たせる最も低いeffortから始め、品質差を確認できる場合にだけ上げます。[3]
| 段階と仕事 | 推奨モデル | 考える深さ（effort） |
|---|---|---|
| Plan: 定型的な文書構成、影響範囲が狭い変更 | GPT-5.6 Terra | medium |
| Plan: アーキテクチャ、複数案の比較、高リスク移行 | GPT-5.6 Sol | mediumから開始 |
| Goal: 規則が明確な一括修正、有限のキュー処理 | GPT-5.6 Luna | low〜medium |
| Goal: 原因が不明な障害、難しい最適化 | GPT-5.6 Sol | 評価しながらhigh以上を検討 |
Goalが進まないときは、すぐ最大設定にせず、完了条件、参照情報、実行環境のどれが不足しているかを先に確認します。推論の深さだけが原因だと確認できたときにeffortを上げると、コストを説明しやすくなります。
Claude Codeは不確実性とリスクに合わせてモデルと推論深度を選ぶ
モデル設定では、Sonnetを日常的なコーディング、Opusを複雑な推論、Fable 5を最も難しく長い作業向けとしています。opusplanはPlan modeでOpus、実行時にSonnetへ切り替える専用設定です。[7] effortはhighが多くのモデルの標準で、xhighはより深い推論、maxは最難関向けですが、過剰に考える場合もあるため比較評価が必要です。[7]
| 段階と仕事 | 推奨モデル | 考える深さ（effort） |
|---|---|---|
| Plan: 定型的な文書構成、影響範囲が狭い変更 | Claude Sonnet 5 | high |
| Plan: システム設計、複数案の比較 | opusplanまたはClaude Opus 5 | high〜xhigh |
| Goal: 検証が明確な通常の実装、修正、移行 | Claude Sonnet 5 | medium〜high |
| Goal: 未知要因が多い長時間の作業 | Claude Opus 5 | xhigh |
| Goal: 最も難しい長期作業、研究的な反復 | Claude Fable 5 | high〜xhigh |
| PlanとGoal: コストより最高能力を優先する作業 | Fable 5またはOpus 5 | maxを比較評価して使用 |
opusplanのopusとsonnetが指すバージョンはプロバイダーで異なります。モデル名を固定する必要がある環境では、実際の解決先を確認します。[7] Claude CodeのGoal評価モデルは、通常はデフォルトのHaikuから変更する必要はありません。別モデルへ変更するANTHROPIC_DEFAULT_HAIKU_MODELは、Goal判定だけでなく会話要約などのバックグラウンド機能にも影響します。[4]
金額・文脈・実行範囲・品質を別々の予算として管理する
トークン（モデルが処理する入力・出力の単位）の企業利用では、請求額の監視だけでは不十分です。本記事では、金額・利用量、コンテキスト、自律実行の3種類を別の予算として管理することを推奨します。
OpenAIは、リクエストとトークンを減らし、精度を維持できる範囲で小さいモデルを選ぶことをコスト最適化の基本としています。[8] Anthropicも、Claude Codeのコストはモデル、コードベース、利用方法で変わり、長いコンテキストほどトークン消費が増えると説明しています。[11] したがって、最大能力のモデルを常用するより、代表タスクで品質と利用量を比較して段階的に上げる方が管理しやすくなります。
| 予算 | /planで決めること | /goalで監視すること | 人へ戻す条件 |
|---|---|---|---|
| 金額・利用量 | 基準モデル、effort、上位モデルへ切り替える条件 | 利用量、ターン、試行、経過時間 | 承認済み上限への到達、上位モデルへの変更 |
| AIへ渡す情報 | 読む資料、対象範囲、残す判断記録 | 無関係な履歴、重複資料、会話の長期化 | 前提を保てない要約、別の仕事の混入 |
| AIに任せる実行範囲 | 許可する変更、禁止範囲、外部操作 | 権限追加、対象拡大、元に戻せない操作 | 公開、送信、削除、購入、利用環境への反映 |
| 品質 | 受け入れ条件と証拠 | テスト、評価、レビュー指摘 | 条件の変更、残存リスクの受容 |
製品の管理画面による上限と、個々のGoalの停止条件も分けます。OpenAIのガバナンス資料では、利用分析、利用制御、監査記録は目的が異なる管理面です。[9] Anthropicも、契約や認証方法によって、組織の支出上限と利用量の確認場所が異なると説明しています。[11] 管理画面の通知だけに頼らず、Goal自体にもターン、時間、試行、対象件数の上限を入れます。
正確なトークン数をセッション中に取得できない場合は、ターン数、試行回数、処理件数、経過時間を代理指標にします。企業全体ではチーム、用途、モデル別の利用傾向を確認し、個別タスクでは成果物の合格率やレビュー指摘も合わせて評価します。利用量が減っても、再作業や人の確認時間が増えれば、業務全体の効率が上がったとは限りません。
Human-in-the-Loopをイベントで設計する
Human-in-the-Loop（HITL）とは、あらかじめ定めた判断点で人が確認し、承認、修正、停止を選ぶ運用です。毎ターン人が介入するのではなく、リスクや予算が境界へ達した時点で人へ戻すと、継続性と統制を両立できます。
sandbox（ファイルやネットワークへの権限を制限する技術的な実行範囲）について、Codexではsandboxが可能な操作を制限し、approval policy（どの操作で人へ確認するかのルール）が確認時点を決めます。[10] Claude Codeでも、権限はモデルではなく製品側で強制され、allow、ask、denyを使い分けられます。[12] どちらでも、プロンプトに「禁止」と書くだけで組織の権限制御を代替せず、sandbox、権限ルール、管理設定を重ねます。
| リスク | 具体例 | 推奨する人の確認点 |
|---|---|---|
| 低 | 読み取り専用の調査、既存情報の整理 | 完了後に根拠と成果物を確認する |
| 中 | 元に戻せる文書・コード変更 | Plan承認後に実行し、差分と検証を確認する |
| 高・機密 | 資格情報、顧客データ、認証・アクセス制御、本番環境 | Goalの対象外とし、非機密の計画と判断材料だけをPlanで準備して、指定担当者が実行を管理する |
| 高・専門判断 | 法務、公開上の主張、重要な設計判断 | Planで範囲と根拠を確認し、専門担当者が実行前と最終結果を承認する |
| 外部・不可逆 | 公開、送信、購入、削除、DB更新、デプロイ | AIは準備までとし、実行直前に指定担当者が承認する |
HITLを機能させるには、誰が判断するかも決めます。依頼者は目的と優先順位、業務担当者は受け入れ条件、管理者はデータと権限、レビュー担当者は差分と証拠を確認します。同じ人が複数の役割を持っても構いませんが、Goal自身に最終承認をさせません。
人へ戻すイベントは、少なくとも次の6つです。
- Planの前提や採用案から外れる
- 利用量、ターン、時間、試行の上限へ達する
- 機密データ、未承認の外部サービス、追加権限が必要になる
- 公開、送信、削除、購入、DB更新、デプロイへ進む
- 根拠が矛盾する、または受け入れ条件を変更する必要がある
- 指定回数の検証失敗後も原因を特定できない
この設計では、人はAIの全手順を追うのではなく、判断が必要な差分と証拠を確認します。エージェントには、停止理由、完了済み項目、残る選択肢、利用量の代理指標を短く報告させます。
/planで方法を決めてから/goalで実行と検証を継続する
最も再利用しやすい流れは、Plan → 人の承認 → Goal → イベント時の確認 → 検証 → 人の最終判断です。ただし、この流れは組織の情報区分でGoal実行を許可された作業に限ります。機密性の高い作業はGoalへ移さず、Planの段階で人が管理する手順へ切り替えます。Planの承認は「そのまま最後まで実行してよい」という包括的な許可ではなく、実行中の例外と不可逆な操作は別の確認点として残します。
- 依頼者、レビュー担当者、目的、対象外、データ区分を整理する
/planで現状、選択肢、影響範囲、リスク、検証方法を調査する- Planへモデル、3種類の予算、権限、HITLのイベントを記載する
- 人が採用案、変更範囲、受け入れ条件、承認点を確認する
- 承認したPlanを短い実行仕様として残す
/goalへ目的、完了条件、制約、予算、停止上限を設定する- エージェントが変更と検証を反復し、イベント発生時に停止する
- 人が例外を判断し、継続する場合はGoalまたはPlanを更新する
- 人が差分、根拠、検証結果を確認し、公開やマージを判断する
PlanからGoalへ渡す情報は、採用案、対象ファイル、受け入れ条件、変更禁止範囲、停止条件に絞ります。調査ログをすべて渡すより、決定と根拠を短く残す方がGoalの焦点を保てます。
文書作業では/planで論旨を設計し、/goalで執筆と検証を続ける
文書作業では、Planで論旨と根拠を決め、Goalで日英本文、参照、形式チェックをそろえます。AIは構成整理、ドラフト、修正候補、形式確認を支援し、人が著者・編集者・公開責任者として最終判断します。
/planで論旨と証拠を設計する
/plan [テーマ]の記事更新を計画する。まだ本文は変更しない。
既存の日英記事、関連ページ、編集ルールを確認する。
読者の問い、記事の主張、必要な一次資料、既存記事との差分を示す。
日英で一致させる見出し、表、コード例、内部リンクを設計する。
外部事実、著者の解釈、人の確認が必要な体験を分ける。
利用を許可する資料とデータ区分、基準モデル、予算、上位モデルへ切り替える条件を示す。
公開、レビュー承認、既存記事の削除は計画に含めず、承認点として示す。計画レビューでは、主張が1つの記事に収まるか、各外部事実に一次資料があるか、既存記事と役割が重複しないかを確認します。情報源の数ではなく、各主張と根拠の対応を見ます。
/goalで執筆と検証を継続する
/goal 承認済みPlanに沿って[テーマ]の記事を日英で更新する。
日本語を先に作成し、英語版は同じ見出し順、表数、コードブロック数にする。
外部事実は承認済みの一次資料に限定し、本文番号と参考文献を対応させる。
機密情報を未承認の外部サービスへ送らない。
既存UI、URL、無関係な記事は変更しない。
完了条件は、日英差分、文体、内部リンク、参考文献、所定のレビューコマンドでCritical（公開を止める重大指摘）が0件になること。
根拠不足、著者体験の確認、公開操作、[利用量、ターン数、試行回数]の上限で停止して報告する。Goalの完了条件に「品質を高める」だけを書かず、日英構造、参照番号、リンク、レビュー結果へ分解します。人による校閲や著者体験の承認は機械的な終了条件へ置き換えず、停止後のレビューとして残します。
開発作業では/planで変更経路を設計し、/goalで実装と回帰確認を続ける
開発では、Planで仕様と影響範囲を確定し、Goalで小さな変更と検証を反復します。計画段階でロールバックと承認境界まで決めると、テストを通すためだけに仕様を変えるリスクを抑えられます。
/planで変更経路を設計する
/plan [機能または移行]の実装計画を作る。まだコードは変更しない。
関連仕様、呼び出し経路、データモデル、既存テストを調査する。
採用案と代替案、影響するファイル、互換性、移行順序を示す。
単体、統合、型、静的解析の検証方法と、元の状態へ戻す方法を定義する。
基準モデル、予算、上位モデルへ切り替える条件、担当者ごとの承認点を示す。
DB変更、公開API変更、依存追加、デプロイは個別の承認点にする。
不明な製品要件は推測せず、質問として残す。Planのレビューでは、実装手順より先に受け入れ条件を確認します。既存動作を維持する作業なら、成功条件と回帰を防ぐテストが同じ計画に含まれている必要があります。
/goalで実装と回帰確認を反復する
/goal 承認済みPlanの範囲で[機能または移行]を完了する。
小さな差分ごとに関連テストを実行し、最後に承認済みの検証一式を実行する。
公開API、既存データ、変更禁止ファイルを維持する。
完了条件は、受け入れ条件を満たし、対象テスト、型チェック、静的解析が成功すること。
Planと異なる設計、機密情報、DB変更、権限拡大、外部書き込み、デプロイが必要なら停止して報告する。
[利用量、ターン数、時間、試行回数]の上限でも停止し、未解決原因を整理する。実装中にPlanの前提が崩れた場合は、Goalを無理に継続しません。/goal pauseが使えるCodexでは一時停止し、必要なら再び/planで差分だけを再設計します。Claude CodeではGoalを解除または停止し、Plan modeで方針を更新してから新しい完了条件を設定します。
両製品自体の使い分けは、ClaudeとCodexの使い分けで整理しています。PlanとGoalを選ぶ前に、現在の利用形態で必要なファイル、コマンド、権限、検証結果へアクセスできるかを確認してください。
まとめ：/planで方法を固めてから/goalへ実行を渡す
/planは方法、予算、承認点をレビューするためのコマンド、/goalは承認済みの方法を検証可能な完了条件まで継続するためのコマンドです。設計判断と長い実行の両方がある文書作業や開発では、Plan → 人の承認 → Goal → イベント時の確認 → 検証 → 人の最終判断の順が適します。
実行前に確認したいのは、次の6点です。
- Planが採用案、影響範囲、検証、未決事項を分けているか
- 人がPlanと受け入れ条件を承認したか
- 金額・利用量、コンテキスト、自律実行の予算を分けたか
- Goalが完了条件、変更禁止範囲、承認点、予算、停止上限を持つか
- HITLのイベントと判断担当者を指定したか
- 最終的な公開、マージ、不可逆な操作を人の判断として残したか
この6点を明文化できたら、通常のモデルとeffortから始め、計画の判断難度または実行時の未達原因に応じて能力を上げる進め方が適しています。
単発で完了できる仕事や、方法を決める前に外部へ影響する操作が必要な仕事は、/goalへ渡さず通常の対話または人の判断に残します。
本記事は一般的な情報整理であり、法的助言ではありません。実務判断は専門家に確認してください。
参考文献
- OpenAI, Follow a goal, ChatGPT Use Cases
- OpenAI, Developer commands, ChatGPT Learn
- OpenAI, Model guidance, OpenAI API Docs
- Anthropic, Keep Claude working toward a goal, Claude Code Docs
- Anthropic, Commands, Claude Code Docs
- Anthropic, Choose a permission mode, Claude Code Docs
- Anthropic, Model configuration, Claude Code Docs
- OpenAI, Cost optimization, OpenAI API Docs
- OpenAI, Governance, ChatGPT Learn
- OpenAI, Agent approvals & security, ChatGPT Learn
- Anthropic, Manage costs effectively, Claude Code Docs
- Anthropic, Configure permissions, Claude Code Docs
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。