Claude Codeの/goalコマンド｜完了条件を決めてAIに自律的に働き続けさせる方法

「テストが全部通るまで直してほしいのに、一度直したところで止まってしまう」

「イシューのバックログを片付けたいのに、毎回こちらから『次』と打ち込んでいる」

——AIコーディングエージェントを使っていると、こうした「あと一押し」の手間が地味に効いてきます。

Claude Codeの/goalコマンドは、この「あと一押し」をなくすための機能です。作業の完了条件をひとつ設定しておくと、その条件が満たされるまでClaudeがターンを跨いで作業を続けます。各ターンの終了後に小型高速モデルが条件の成立を判定し、まだなら次のターンが自動的に始まる仕組みです。

本記事の内容は、Claude Code公式ドキュメント「Keep Claude working toward a goal」（2026年8月1日確認）に基づいて整理しています。

この記事でわかること

/goalの仕組みから実務での使いどころまで、開発者・開発リーダーが判断に使える範囲を整理します。

• /goalの基本的な仕組み — 完了条件を設定すると、毎ターン後に別の小型モデルが条件成立を判定し、満たされるまで作業が続きます
• 設定・状態確認・解除の3操作 — /goal ＜条件＞ で設定、引数なしの/goalで状態確認、/goal clearで解除します
• 効く完了条件の書き方 — 測定できる終了状態・証明方法・守るべき制約の3点が揃っているかが分かれ目です
• /loop・Stop hookとの使い分け — 「次のターンが始まる条件」と「止まる条件」の2軸で整理すると迷いません
• 使う前に確認しておくべき要件 — 信頼ダイアログの承認や、評価モデルを変える環境変数の副作用に注意が必要です

対象読者: Claude Codeを日常的に使っている開発者・開発リーダー。長時間かかる修正作業やバックログ処理を、確認のたびに止めずに回したい方。読み終える頃には、/goalをどの作業に使い、どこは人が握っておくべきかの線引きを自分の言葉で説明できる状態になります。ぜひ最後までご確認ください。

/goalとは何か

まずは/goalが何をしてくれるコマンドなのか、そして「誰が終わりを判定しているのか」を押さえておきます。ここを理解しておくと、後の条件文の書き方が腹落ちしやすくなります。

完了条件を起点にした自律継続の仕組み

/goalは、Claudeに「どうなったら終わりか」を先に伝えておくコマンドです。通常のClaude Codeは、Claude自身が「作業が終わった」と判断した時点でターンを終えます。/goalを設定しておくと、ターンが終わるたびに別のモデルが「条件は満たされたか」を判定し、まだであればClaudeは次のターンを自動的に始めます。

利用にはClaude Code v2.1.139以降が必要です。それより前のバージョンではコマンド自体が存在しません。

判定を担うのは「別の小型高速モデル」

ここが/goalの設計上いちばん重要なところです。完了判定を行うのは、作業をしているモデル自身ではなく、小型高速モデル（small fast model）による評価器です。Claude APIを使っている場合、既定ではHaikuが担当します。サードパーティのプロバイダー経由で利用している場合は、プラットフォームの既定モデルが何かを各プロバイダーのページで確認してください。

評価の結果によって、その後の動きは次のように分かれます。

なお、1セッションにつき有効なゴールは1つです。新しいゴールを設定すると、前のゴールは置き換えられます。複数の完了条件を並行させたい場合は、条件文の中に「かつ」の形でまとめる必要があります。

/goalの基本操作

操作は「設定する・状態を見る・解除する」の3つだけです。順に見ていきます。

ゴールを設定する

コマンドのあとに、そのまま完了条件を書きます。公式ドキュメントの例は次の形です。

/goal all tests in test/auth pass and the lint step is clean

ここでのポイントは、設定した時点で条件そのものが指示として扱われ、1ターン目がすぐ始まることです。「ゴールを設定してから、改めて作業指示のプロンプトを送る」という手順は必要ありません。

ゴールが有効な間は、画面に ◎ /goal active というインジケーターが表示され、経過時間を確認できます。

状態を確認する

引数をつけずに/goalだけを実行すると、現在の状態が表示されます。

/goal

表示されるのは以下の5項目です。

このうちターン数と直近の理由は、最初の評価が走った後に表示されます。設定直後に確認しても空欄になるのはそのためです。

ゴールを解除する

作業の途中で方針が変わったときは、次のコマンドで解除します。

/goal clear

解除されると Goal cleared: に続けて条件が表示されます。そもそもゴールが設定されていなければ No goal set と返ってきます。clearにはstop／off／reset／none／cancelというエイリアスがあり、どれを打っても同じ動作です。また、/clear（新しい会話の開始）を実行した場合も、有効なゴールは消えます。

効く完了条件の書き方

/goalがうまく働くかどうかは、ほぼ条件文の書き方で決まります。公式ドキュメントは、効く条件文の要素として次の3点を挙げています。

1. 測定できる終了状態がひとつだけあること — テスト結果、ビルドの終了コード、ファイル数、キューが空になること、といった形で言い切れるもの
2. どう証明するかが書かれていること — 「npm testが0で終了する」「git statusがクリーンである」のように、成立を示す手段まで含める
3. 守るべき制約が書かれていること — 「他のテストファイルを変更しない」など、ゴールに到達するまでに変わってはいけないこと

評価器はツールを呼ばない、という前提

ここがいちばんの落とし穴です。評価器はファイルを読んだりコマンドを実行したりを独自には行いません。判定材料になるのは、会話に残っている内容だけです。

つまり条件は、Claude自身の出力で示せる形で書く必要があります。先ほどの「test/authのテストがすべて通る」が成立するのは、Claudeがテストを実行し、その結果がトランスクリプトに残るからです。逆に、Claudeが一度も触れないまま静かに満たされるような条件を書いてしまうと、いつまでも判定が「No」のままになります。

ポイント: 完了条件を書くときは、「この条件が満たされたことを、会話ログだけを読んだ第三者が判断できるか？」と自問してみるのが結構ミソになってきます。判断できないなら、証明の手段（実行するコマンドや確認方法）を条件文に足してください。評価器は、その第三者そのものです。

良い条件文と避けたい条件文

同じ作業でも、書き方ひとつで結果が変わります。

ターン数・時間で区切る書き方

/goalには実行時間の制限がシステム側にありません。放っておけば条件が満たされるまで走り続けます。そのため、条件文の中に or stop after 20 turns のような節を自分で入れて区切るのが実務的です。Claudeは毎ターン、その節に対する進捗を報告し、評価器も会話の内容からその成立を判定します。

なお、条件は最大4,000文字まで書けます。制約や証明手段を丁寧に書き込んでも、まず足りなくなることはありません。

/loop・Stop hookとの使い分け

Claude Codeでセッションを回し続ける方法は/goalだけではありません。/loopとStop hookという選択肢があり、この3つの使い分けが実務では最も判断に迷うところです。

「始まる条件」と「止まる条件」の2軸で見る

公式ドキュメントは、この3つを次の比較表で整理しています。

この表を「何をトリガーに次が始まるか」「誰が終わりを決めるか」の2軸として読むと、選び方がはっきりします。時間が主役なら/loop、条件が主役なら/goal、判定ロジックを自分で書きたいならStop hookです。定期的な状態チェックの設計についてはClaude Codeの/loopコマンドの解説記事で詳しく触れています。

/loopは廃止も改名もされていません

ここは誤解が生まれやすいので明記しておきます。/goalが登場したことで/loopが古くなった、非推奨になった、という事実はありません。公式ドキュメント上の位置づけが「時間間隔で繰り返す」という役割に整理され、「条件が満たされるまで回す」という用途が/goalとして分かれた、という関係です。両者は置き換えではなく、役割分担です。

むしろ/loop側も機能が広がっています。現在の/loopはバンドルスキル（エイリアスは/proactive）として提供されており、間隔を省略すると、Claudeが毎イテレーション後に1分〜1時間の範囲で次の待ち時間を自分で決めるセルフペースモードで動きます。ビルドが終わりかけなら短く、動きが止まれば長く、といった具合に間隔が変わり、選んだ待ち時間とその理由が毎回表示されます。さらにv2.1.202以降は、タスクが完了したと判断した時点でClaude自身がループを終了できます。つまり/loopは「固定間隔でひたすら繰り返すだけの機能」ではなく、次のターンの起点が時間側にあるか、前のターンの終了側にあるかが/goalとの本質的な違いです。（出典: Run prompts on a schedule、2026年8月1日確認）

/goalとStop hookの違いはスコープ

/goalとStop hookは、どちらも毎ターン後に発火するという点で仕組みが近い関係にあります。実際、/goalはセッションスコープのプロンプトベースStop hookのラッパーとして実装されています。違いは効く範囲です。

その場かぎりの作業なら/goal、チーム全体やリポジトリ全体で常に効かせたいルールならStop hook、という切り分けになります。「マージ前に必ずlintを通す」のようにプロジェクト共通の決まりごとであれば、Stop hookとして設定ファイルに置く方が理にかなっています。フックの設計そのものについてはClaude Codeのフック自動化の記事をあわせてご覧ください。

auto modeと組み合わせて無人で回す

/goalを設定しただけでは、実は完全な無人運転にはなりません。ここは実務で必ずつまずくポイントです。

/goalは権限を変更しない

/goalは権限を一切変更しません。既定の権限モードのままであれば、設定で許可していないツール呼び出し（先ほどの例で言えばテストコマンドの実行）は、これまで通り確認を求められます。ゴールを設定して席を離れたのに、1ターン目の途中で確認待ちのまま止まっていた、というのはよくある話です。権限モードの整理はClaude Codeの権限モードの記事にまとめています。

両者は補完関係にある

auto modeと/goalは、止まる理由がそれぞれ違います。

つまり、auto modeがツールごとの確認をなくし、/goalがターンごとの確認をなくすという関係です。ゴールのターンを無人で回したいのであれば、この2つの併用が必要になります。/goalはさらに、作業をしているモデルとは別の新しいモデルを評価器として毎ターン後に走らせる点でも、auto modeとは役割が異なります。auto modeの挙動と注意点はClaude Codeのauto modeの記事で解説しています。

非対話モード・セッション再開での挙動

/goalは対話セッション専用の機能ではありません。非対話モード・デスクトップアプリ・Remote Controlのいずれでも動きます。

-pオプションで1回の起動から回し切る

-pオプションで設定すると、1回の起動でループを完走させられます。

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

ただし注意点があります。既定のテキスト出力では、条件が満たされるまで何も表示されません。多くのターンを回すゴールでは、動いているのに止まって見えてしまいます。途中経過を見たい場合は次のオプションを足してください。

claude -p "/goal ..." --output-format stream-json --verbose

これでループ中の各メッセージが出力されるようになります。なお、非対話モードで途中停止したい場合は Ctrl+C です。

resume時に引き継がれるもの・されないもの

セッション終了時に有効だったゴールは、--resume／--continueで復元されます。ただし引き継がれる範囲には差があります。

条件文に or stop after 20 turns のようなターン数の節を入れている場合、再開後はカウントがゼロから数え直しになる点は把握しておいてください。

使う前に確認しておきたい要件と注意点

/goalは環境によっては利用できないケースがあり、設定の変更が思わぬところに波及することもあります。使い始める前に押さえておきたい3点をまとめます。

信頼ダイアログの承認が前提

/goalの評価器はhooks機構の一部として動いているため、ワークスペースの信頼ダイアログ（trust dialog）を承認済みであることが要件になります。加えて、次のいずれかに該当する場合は/goalを利用できません。

• disableAllHooksがいずれかの設定レベルで有効になっている
• managed settingsでallowManagedHooksOnlyが設定されている

いずれの場合も、コマンドが理由を教えてくれます。黙って何も起きないわけではないので、動かないときはメッセージを確認してください。

評価モデルを変える環境変数には副作用がある

評価に使うモデルはANTHROPIC_DEFAULT_HAIKU_MODELで変更できます。ただしここは注意が必要で、公式ドキュメントも警告している点です。

この環境変数は/goalの評価だけでなく、小型高速モデルを使うすべての箇所に効きます。haikuエイリアスの解決先や、会話の要約といったバックグラウンド処理も含まれます。「/goalの判定だけ厳しくしたい」といった局所的な調整の目的でこの変数を触ると、想定外の場所に影響が出ます。

トークン消費の考え方

評価に使われるトークンは、そのプロバイダーで設定された小型高速モデルとして課金されます。メインのターンの消費に比べれば、通常は無視できる程度です。コストを気にして/goalを避ける必要はほとんどありません。むしろ気を配るべきは評価トークンではなく、条件が満たされないまま回り続けるターンそのものの消費です。だからこそ、先ほどのターン数による打ち切りが効いてきます。

実務でどう使うか

機能として使えることと、業務に組み込んで効果が出ることは別の話です。どういう作業に向いていて、どこは人が握っておくべきなのかを整理します。

向いている作業

公式ドキュメントは、ユースケースとして次の4つを挙げています。いずれも「終わりが客観的に判定でき、そこに至るまでに何度も試行が必要」という共通点があります。

少数精鋭のチームでAIエージェントを回す場合、こうした「待ちが発生する反復作業」をどれだけ手放せるかが効率を左右します。人が張り付いて「次」と打ち込む時間は、そのまま設計や意思決定に使えるはずの時間です。確認の手間を減らすための投資として、条件文を丁寧に書く時間は十分に見合います。

向いていない作業も正直に

一方で、/goalが向かない作業もはっきりしています。

• 終わりが主観的な作業 — 「読みやすい文章にする」「デザインを良くする」のように、成立を客観的に判定できないもの
• 証明する出力が会話に残らない作業 — 評価器は会話に出た内容しか見ません。人が別環境で目視確認して初めて分かるような作業は、判定材料が残りません
• 途中の判断を人が握るべき作業 — 本番データの変更や外部への送信を伴う作業は、ターンごとに人が確認する価値の方が大きくなります

StartLinkでも、AIエージェントに任せる範囲を広げるときは「終わりをどう定義するか」から先に決めています。人が「次」「続けて」と打ち込み続けている状態は、AIの能力が足りないのではなく、終わりの定義が言語化できていないサインであることがほとんどです。/goalは、その定義をコマンド1行として扱えるようにした機能だと捉えると、位置づけがはっきりします。

「AIに任せるもの」と「人が判断するもの」の線引きは、/goalを使う場合も変わりません。自律的に回せる範囲を広げることと、判断そのものを手放すことは別の話です。まずは開発環境の閉じた作業から試し、様子を見ながら適用範囲を広げるスモールスタートが結局は早道になります。長時間の作業を見守る手段としては、Claude CodeのMonitorツールと組み合わせる形も検討の余地があります。

よくある質問

/goalを使い始めるにあたって、疑問になりやすい5点にお答えします。

Q1. /goalはどのバージョンから使えますか？

Claude Code v2.1.139以降で利用できます。それより前のバージョンではコマンド自体が存在しないため、まずお使いのバージョンを確認してください。対話セッションだけでなく、非対話モード・デスクトップアプリ・Remote Controlのいずれでも動作します。

Q2. ゴールを複数同時に設定できますか？

できません。1セッションにつき有効なゴールは1つで、新しいゴールを設定すると前のゴールが置き換えられます。複数の終了条件を扱いたい場合は、ひとつの条件文の中に「かつ」の形でまとめてください。条件は最大4,000文字まで書けるため、文字数で困ることはまずありません。

Q3. 条件が満たされないまま、いつまでも動き続けることはありませんか？

システム側には実行時間の制限がないため、条件次第では長く走り続けます。対策としては、条件文の中に or stop after 20 turns のようなターン数や時間の節を入れて自分で区切る方法が公式に案内されています。Claudeは毎ターンその節に対する進捗を報告し、評価器も会話の内容から成立を判定します。

Q4. /loopは/goalに置き換えられたのですか？

いいえ。/loopは廃止も改名もされていません。公式ドキュメント上の位置づけが「時間間隔で繰り返す」という役割に整理され、「条件が満たされるまで回す」という用途が/goalとして分かれた、という関係です。定期的な状態チェックには引き続き/loopが適しています。

Q5. /goalを設定すれば、確認なしで最後まで動きますか？

いいえ。/goalは権限を変更しません。既定の権限モードでは、許可していないツール呼び出しはこれまで通り確認を求められます。ターンごとの確認をなくすのが/goal、ツールごとの確認をなくすのがauto modeという役割分担なので、無人で回したい場合は両方を有効にする必要があります。

あわせて読みたい

• Claude Codeの/loopコマンド｜定期実行でデプロイ監視・ステータスチェックを自動化する
• Claude Codeのautoモード完全ガイド｜確認なしでAIに自律実行させる設定と安全な運用方法
• Claude Code Hooksで開発を自動化する方法｜フック設計パターンと実装ガイド
• Claude Codeのパーミッションモード完全ガイド｜default・plan・auto・bypassの使い分け

まとめ

Claude Codeの/goalコマンドについて、実務で押さえておきたい点を整理します。

• /goalは完了条件ベースの自律継続コマンドです。v2.1.139以降で利用でき、毎ターン後に別の小型高速モデル（Claude APIでは既定でHaiku）が条件成立を判定します
• 効く条件文の要は3点 — 測定できる終了状態、それをどう証明するか、守るべき制約。評価器はツールを呼ばないため、Claudeの出力で示せる形に書けているかどうかで結果が変わります
• /loopとの関係は置き換えではなく役割分担です。時間で回すなら/loop、条件で回すなら/goal、判定ロジックを自分で書きチーム全体に効かせたいならStop hookを選びます
• 無人運転にはauto modeとの併用が必要です。/goalは権限を変更しないため、単体ではツールの確認で止まります
• 向かない作業もはっきりしています。終わりが主観的な作業や、証明する出力が会話に残らない作業には使えません

まずはnpm testやlintのように結果が客観的に判定できる閉じた作業でひとつ条件文を書いてみて、評価器がどんな理由を返すかを観察するところから始めるのが確実です。条件文の書き方さえ手に馴染めば、「あと一押し」を人が打ち込む時間はそのまま設計や判断に回せます。

AI活用とCRM運用をどう組み合わせるかについてご興味がある方は、お気軽にご相談ください。StartLinkでは、HubSpotゴールドパートナーとして、AIを前提とした業務設計から運用定着まで一貫して支援しています。無料相談はこちら