Claude Codeの/goalコマンド｜完了条件でAIを自律実行させる方法

Claude Codeの/goalコマンドは、完了条件をひとつ決めておくだけで、その条件が満たされるまでClaudeがターンを跨いで自律的に働き続ける機能です。

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

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

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

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

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

この記事でわかること

/goalをこれから使い始める方から、すでに自律実行を試している方まで、完了条件の設計と運用の線引きを判断に使える範囲で整理します。

• /goalの基本的な仕組み — 完了条件を設定すると、毎ターン後に別の小型モデルが条件成立を判定し、満たされるまで作業が続きます
• 設定・状態確認・解除の3操作 — /goal ＜条件＞で設定、引数なしの/goalで状態確認、/goal clearで解除します
• 効く完了条件の書き方 — 測定できる終了状態・証明方法・守るべき制約に打ち切り条件を加えた4要素が、書き方の軸です
• /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. 守るべき制約が書かれていること — 「他のテストファイルを変更しない」など、ゴールに到達するまでに変わってはいけないこと

実務では、この3点に「回り続けないための打ち切り条件」を加えた4要素で書くと、書き漏れがなくなります。順に見ていきましょう。

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

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

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

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

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

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

条件文は、次の4要素を並べる形にすると整理しやすくなります。

先ほどの「良い書き方」の条件文も、この4要素に分解できる形になっています。

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

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

なお、条件は最大4,000文字まで書けます。制約や証明手段を丁寧に書き込んでも、通常の条件文なら十分に収まる長さです。

/loop・Stop hookとの使い分け

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

次の図は、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月時点で確認）

/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のいずれでも動きます。スクリプトやCIに組み込んで長時間回したい場合の挙動と、セッションをまたいだときに何が引き継がれるのかを押さえておきます。

-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が向かない作業もはっきりしています。

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

ただし「向いていない」は恒久的な線ではなく、証明手段を条件文に書き足せるかどうかで変わります。判定材料を会話に残せる形に作業を設計し直せば、使える範囲は広がります。

自律実行のなかで「人」と「AI」の役割を分ける

/goalを軸にした自律実行は、工程ごとに担い手が違います。次のように整理すると、「どこまで任せるか」の線引きがはっきりします。

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

「AIに任せるもの」と「人が判断するもの」の線引きは、/goalを使う場合も変わりません。自律的に回せる範囲を広げることと、判断そのものを手放すことは別の話です。終わりを定義してから仕組みに任せるという考え方は、HubSpotのワークフローやBreezeのエージェント機能を業務に組み込むときにも通じるものだと、私たちは考えています。

うまくいった条件文は「仕組み」として共有する

条件文の書き方は、身につけてしまえば個人のスキルですが、そのままでは属人化します。うまくいった条件文はチームのテンプレートとして共有し、プロジェクト共通のルールに育ったものはStop hookとして設定ファイルに移します。こうしておくと、経験の浅いメンバーが回しても同じ品質で自律実行できる仕組みになり、引き継ぎのたびにやり方を教え直す必要もなくなります。個人の力量ではなく仕組みで解決する、という発想です。

どこまでを条件に含めるか、ターン数をどこで区切るかの最適な形は、チームの開発スタイルや対象システムの性質によって異なります。汎用的な正解がひとつあるわけではありません。まずは開発環境の閉じた作業で1本だけ条件文を試し、評価器が返す理由を見ながら自社の流儀に合わせて調整していくスモールスタートが、結果として近道になります。長時間の作業を見守る手段としては、Claude CodeのMonitorツールと組み合わせる形も検討の余地があります。

よくある質問

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

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

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

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

できません。1セッションにつき有効なゴールは1つで、新しいゴールを設定すると前のゴールが置き換えられます。複数の終了条件を扱いたい場合は、ひとつの条件文の中に「かつ」の形でまとめてください。止めたいときは/goal clear（エイリアスはstop／off／reset／none／cancel）で解除します。

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

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

Q4. /loopやStop hookとはどう使い分けますか？

「次のターンが始まる条件」と「止まる条件」の2軸で整理すると迷いません。時間間隔が主役なら/loop、完了条件が主役なら/goal、判定ロジックを自分で書いてチーム全体に効かせたいならStop hookが向いています。/loopが廃止・改名されたという事実はなく、役割分担の関係です。

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

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

まとめ

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

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

自律実行の第一歩は、終わりの定義をひとつ書くことです。まずはnpm testやlintのように結果が客観的に判定できる閉じた作業で条件文を1本書いてみて、評価器がどんな理由を返すかを観察するところから始めるのがおすすめです。

次の3ステップで進めると、無理なく適用範囲を広げられます。

1. 開発環境の閉じた作業で/goalを設定し、評価器の判定と理由を観察する
2. 条件文に証明手段と打ち切り条件を足し、判定がどう変わるかを確かめる
3. うまくいった条件文をチームのテンプレートにし、恒久的なルールはStop hookに移す

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。無料相談はこちら

あわせて読みたい

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