Claude Code /goal で自動・目標設定・自走を実現する使い方完全ガイド

Claude Code /goal コマンドとは——自動・目標駆動の自走ループを理解する

/goal は、Claude Code に「ここまで終わったら完了」という条件を伝えると、その条件を満たすまで、こちらが毎回指示しなくても作業を続けてくれるコマンドです。大きな移行作業やテストの修正では、これまで「続けて」「次のファイルへ」と何度も入力する必要がありました。/goal を使うと、その繰り返しが要らなくなります。

公式ドキュメント（goal.md、2026年10月12日確認）によると、Claude が1ターンの作業を終えるたびに、別の小型で高速なモデル（既定では Haiku）が、条件を満たしたかどうかを判定します。満たしていなければ Claude は次のターンを自動で始めます。次の3つのどれかになると、ゴールは自動で解除されます。

• 条件を満たしたと判定された
• 条件を満たすことは不可能だと判定された
• 利用者が直さないと進めないエラー（ログイン切れ、クレジット残高の不足など）でターンが失敗した

下の動画は、この記事のために小さな練習用フォルダで /goal を実行したときの、実際の画面の録画です（2026年10月12日、Claude Code v2.1.296）。合計を計算する関数にわざと間違いを入れ、「テストがすべて通ること」を条件にしました。

向いているのは、終わりの状態をはっきり確かめられる作業です。公式ドキュメントは、モジュールの移行、設計書どおりの実装、大きなファイルの分割、課題一覧の消化を例に挙げています。Claude Code の基本的な準備や料金については、Claude Code 入門ガイドとClaude Code 料金プランの詳細をご覧ください。

ゴールを決めきれない作業を任せたいときは、Claude Codeのplanモードの使い方で解説しています。

関連記事Claude Codeの検証ループとは？

Claude Codeの/goalは、詳しく書いたプロンプトを1回投げるのと何が違うのですか？

違いは、「終わったかどうか」を誰が決めるかです。詳しいプロンプトを1回送った場合は、作業している Claude 自身が「終わった」と判断したところでターンが止まります。/goal では、ターンが終わるたびに、作業しているモデルとは別のモデルが条件を判定し直します。

公式ドキュメントによると、/goal の実体は「そのセッションだけで有効な、プロンプト型の Stop hook」です。ターンが終わるたびに、条件とそこまでの会話が小型で高速なモデルに送られ、次の3つのどれかが理由つきで返ります。

• まだ満たしていない：Claude は作業を続けます。返ってきた理由が、次のターンの手がかりになります。
• 満たした：ゴールを解除し、達成したことを会話の記録に残します。
• 不可能：条件を満たすことはできないと判定した場合です。ゴールを解除し、理由と一緒に失敗として記録します。

判定するモデルは、自分でコマンドを実行したりファイルを読んだりはしません。Claude が会話の中に出した内容だけを見て判断します。判定に使うモデルは、環境変数 ANTHROPIC_DEFAULT_HAIKU_MODEL で変えられます。ただしこの変数は、要約など、小型モデルを使うほかの処理にも効きます。

/goal の具体的な使い方——基本操作と目標条件の設計

使い方は、設定・状態の確認・解除の3つです。1つのセッションで有効にできるゴールは1つだけで、新しく設定すると前のゴールと入れ替わります。

基本コマンド一覧

# ゴールを設定する（設定するとすぐに作業が始まる）
/goal <完了条件>

# いまの状態を確認する（引数なし）
/goal

# ゴールを解除する
/goal clear

状態の確認は、引数なしの /goal です（/goal show という書き方は公式ドキュメントにありません）。解除は clear のほかに stop・off・reset・none・cancel でもできます。/clear で会話を新しくした場合も、ゴールは解除されます。

手順1：条件を入力して設定する

/goal のあとに条件を書いて Enter を押すと、「Goal set:」と条件が表示され、すぐに最初のターンが始まります。別にプロンプトを送る必要はありません。

上の画面のように、/goal を設定しても、コマンドの実行許可の確認はそのまま出ます。公式ドキュメントにも「ゴールは権限モードを変えない」と書かれています。席を外しているあいだも進めたい場合は、auto モードと組み合わせます。auto モードがツール実行ごとの確認を省き、/goal がターンごとの指示を省く、という分担です。

手順2：達成の表示を確認する

条件を満たしたと判定されると、「✔ Goal achieved」と、かかった時間・ターン数・判定に使ったトークン数が表示されて、入力待ちに戻ります。今回の例では、1分・1ターン・886トークンでした。途中の判定の理由は、Ctrl+O で確認できます。

手順3：状態を確認する

引数なしで /goal を実行すると、状態が表示されます。実行中なら、条件・経過時間・判定したターン数・トークン数・直近の判定理由が出ます。達成済みなら、下の画面のように、達成した条件と時間・ターン数・トークン数が出ます。

公式ドキュメントが挙げている使いどころは次のとおりです。

• モジュールを新しいAPIに移行し、すべての呼び出し箇所がコンパイルでき、テストが通るまで続ける
• 設計書に沿って実装し、すべての受け入れ条件を満たすまで続ける
• 大きなファイルを分割し、それぞれが決めた大きさに収まるまで続ける
• ラベルの付いた課題一覧を、空になるまで順に片付ける

効果的な完了条件の書き方——4要素フレームワーク

条件の書き方で、うまく回るかどうかが決まります。判定するモデルは会話に出た内容しか見ないので、「Claude 自身の出力で証明できること」を条件にします。公式ドキュメントは、長く続けても崩れにくい条件として、次の1〜3を挙げています。4は、いつまで続けるかを区切るための書き方です。

1. 終端状態：測れる終わりの状態を1つ（例：テストの結果、ビルドの終了コード、ファイルの数、空になった一覧）
2. 確認手段：どうやって証明するか（例：「npm test が終了コード0で終わる」「git status がきれい」）
3. 制約：途中で変えてはいけないもの（例：「ほかのテストファイルは変更しない」）
4. 打ち切り句：ターン数や時間の区切り（例：「または20ターンで止める」）

入力例を示します。

/goal src/api/v1/ 以下の全ファイルで fetch を axios に移行し、
`npm test` がエラー0件でパスすること。
既存の公開インターフェースは変更しない。
20ターンで止める。

条件は4,000文字まで書けます。「きれいにリファクタリングする」「パフォーマンスを改善する」のような、人によって判断が分かれる条件は避けます。機械的に確かめられる状態（コンパイルの成功、通ったテストの数、ファイルの数、コマンドの終了コード）を条件の中心に置くのが原則です。

スラッシュコマンド全般については、Claude Code スラッシュコマンド詳細ガイドもご覧ください。

/goal・/loop・Stop hookの使い分け——技術的トレードオフと選択基準

セッションを動かし続ける方法は /goal だけではありません。公式ドキュメント（goal.md）は、「何をきっかけに次のターンが始まるか」で3つの方法を比べています。

手段	次のターンが始まる条件	停止条件	主な用途	設定の永続性
/goal	直前のターンが終わったとき	別のモデルが「満たした」または「不可能」と判定したとき、直さないと進めないエラーが出たとき、/goal clear を実行したとき	終わりの状態がはっきりした長い作業	そのセッションだけ
/loop	決めた時間の間隔が過ぎたとき	自分で止めたとき、または Claude が完了と判断したとき	一定の間隔で繰り返す作業	そのセッションだけ
Stop hook	直前のターンが終わったとき	自分で用意したスクリプトまたはプロンプトが判断	毎回同じ基準で確かめたい自動化	設定ファイルに残り、対象のすべてのセッションに効く

選び方の目安は次のとおりです。

• その場限りで、終わりの状態がはっきりしている作業：/goal が手軽です。設定ファイルを書かずに、条件を入力するだけで済みます。
• 時間を区切って繰り返したい作業：/loop が向いています。条件ではなく、時間の間隔で次のターンが始まります。
• どのセッションでも同じ確認をさせたい場合：Stop hook が向いています。スクリプトで判定を書けるので、毎回同じ結果になります。

auto モードは、1つのターンの中でツールの実行を自動で承認する機能で、それだけでは次のターンを始めません。Claude が「終わった」と判断したところで止まります。/goal は、ターンが終わるたびに別のモデルが条件を確かめる仕組みを足します。公式ドキュメントは、この2つを「組み合わせて使うもの」と説明しています。

/goal コマンドの限界とデメリット

便利な一方で、知っておきたい制約があります。

• 使えない設定がある：/goal はフックの仕組みを使っています。そのため、信頼していないフォルダ、設定で disableAllHooks を有効にしている場合、管理者が allowManagedHooksOnly を設定している場合は使えません。その場合は、使えない理由が画面に表示されます。
• 判定は会話の内容だけ：判定するモデルは、自分でコマンドを実行したりファイルを読んだりしません。Claude がテスト結果などを会話に出していないと、正しく判定できません。
• ゴールはそのセッションのもの：別のセッションには引き継がれません。ただし、同じセッションを --continue や --resume で再開すると、実行中だったゴールは元に戻ります（ターン数・時間・トークン数は数え直しになります）。達成済み・解除済みのゴールは戻りません。
• エラーで止まることがある：ログイン切れ、クレジット残高の不足、圧縮しても収まらない文脈のあふれ、モデルが使えない場合は、ゴールが解除されます。原因を直してから設定し直します。サーバーの混雑などの一時的なエラーは、v2.1.269 以降では自動で3回まで再試行されます。
• 使用量が増える：ターン数が増えるぶん、使用量も増えます。判定そのものに使うトークンは、公式ドキュメントによると本体の作業に比べてごくわずかです（今回の例では886トークン）。
• 条件が悪いと余計な変更が積み重なる：制約のない条件を渡すと、想定していないファイルの変更やコマンドの実行が続くことがあります。

第4の選択肢——Ralph Wiggum方式との比較

/goal・/loop・Stop hook はどれも Claude Code 本体の機能です。これとは別に、外側のシェルスクリプトから同じプロンプトを繰り返し Claude Code に渡し続ける方法が、利用者のあいだで知られています。「Ralph Wiggum方式」と呼ばれる方法で、終わったかどうかは外側のループ（bash の while 文など）が判断し、Claude Code 側は完了の判定を持ちません。

手段	次のターン開始条件	停止条件	主な用途	設定の永続性
Ralph Wiggum方式	外側のシェルのループが再実行したとき	外側のスクリプトの判定（終了コードなど）	使い捨てのプロンプトを手軽に繰り返したい場合	スクリプト側に残る（Claude Code 本体には残らない）

始めやすい方法ですが、どこまで進んだか、なぜ失敗したかを Claude Code 側が把握しません。クリスタルメソッドの自動化でも、完了の判断をシェルスクリプトの終了コードだけに任せると、失敗の理由を切り分けにくい場面がありました。いまは、機械的に確かめられる小さな単位まで目標を分けてから、/goal や Stop hook に渡すやり方に落ち着いています。

実践シナリオ——目標設定の具体的な記述パターン

ここでは、よくある作業を例に、条件の書き方を3つ示します。どれも「測れる終わりの状態・確認手段・制約・区切り」を入れています。席を外して回す場合は、claude -p "/goal …" のように非対話で実行することもできます。その場合、最後の応答はループが終わってから表示されます。途中経過を見たいときは --output-format stream-json --verbose を付けます。

シナリオ1：APIクライアントの一括移行

/goal src/ 配下のすべての axios 呼び出しを fetch に書き換え、
`npx tsc --noEmit` がエラーゼロで通過し、
`npm run test:unit` の全テストがパスすること。
既存の型定義ファイル（*.d.ts）は変更しない。
30ターンで止める。

シナリオ2：ファイル分割によるモジュール整理

/goal src/utils/helpers.ts を機能単位で分割し、
各ファイルの行数が200行以下になること。
`wc -l src/utils/*.ts` で全ファイルが200行以下であることを確認できる。
元の helpers.ts からのエクスポートはバレルファイル経由で維持する。

シナリオ3：テストカバレッジの引き上げ

/goal src/services/ 以下のテストカバレッジを80%以上に引き上げ、
`npm run coverage` のレポートで statements coverage が 80% 以上であること。
既存のテストを削除・修正しない。新規テストファイルの追加のみ許可する。
40ターンで止める。

3つに共通するのは、終わりの状態をコマンドで確かめられることです。「きれいなコード」のような条件では、判定が安定しません。数値・ファイルの数・コマンドの終了コードを条件の中心に置くと、同じ結果を得やすくなります。

自走を実務で安全に回すコツ（一次情報）

この記事の監修者・河合継は、Claude Code を1年以上、実務で使ってきました。目標に向けて自動で進む機能は便利ですが、任せきりにすると無駄な往復も増えます。実際に使って効果があったことを3つ挙げます。

• 止める条件を先に書く。「20ターンで止める」のような区切りを入れておかないと、解けない問題に使用量を使い続けることがあります。終わりの条件と同じくらい、止めどきを決めておくことが効きました。
• 最初の数ターンは画面を見ておく。任せたあとも、序盤は方向がずれていないかを確認します。早い段階で直せば、無駄な往復を大きく減らせます。
• 小さく区切って渡す。大きな目標を一度に渡すより、機械的に確かめられる小さなゴールに分けて順に渡すほうが、やり直しもしやすくなりました。

Agent SDK との組み合わせ——プログラムから目標駆動の自走エージェントを構築する

/goal は、おもに対話画面で使う機能です。同じような自動の作業をプログラムから動かしたい場合は、Claude Agent SDK が選択肢になります。公式ドキュメント（Agent SDK overview）によると、Agent SDK は Python と TypeScript で使え、Claude Code と同じツール・エージェントの仕組み・文脈の管理をプログラムから扱えます。

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions

async def main():
    async for message in query(
        prompt="src/api/v1/ 以下の fetch を axios に移行し、npm test が全件パスするまで続けてください",
        options=ClaudeAgentOptions(allowed_tools=["Read", "Edit", "Bash"]),
    ):
        print(message)

asyncio.run(main())

Agent SDK には Python 3.10 以上が必要です。pip install claude-agent-sdk または uv add claude-agent-sdk で入れます（出典：Agent SDK quickstart）。TypeScript 版は npm install @anthropic-ai/claude-agent-sdk で入り、Claude Code 本体が同梱されるので、別に入れる必要はありません。

Agent SDK と claude -p をサブスクリプションのプランで使う場合、2026年10月時点では、対話での利用と同じプランの利用枠から消費されます（2026年6月に予告されていた別枠クレジットへの変更は見送られました。出典：Anthropic公式ヘルプ、2026年10月10日確認）。APIの料金はClaude Code API料金ガイドで確認できます。

CI/CD に組み込む場合は、claude -p "/goal …" で1回の実行としてループを最後まで回す方法と、Agent SDK でセッションの管理・エラー処理・ログの収集を自分のプログラムで行う方法があります。手元の作業を速くしたいなら /goal、システム同士をつなぐ自動化なら Agent SDK、という分け方が実用的です。

ほかのツールとの違いは、Claude Code vs Cursor 比較とClaude Code vs Codex 比較もご覧ください。

まとめ——/goal で変わる開発フロー、変わらない設計の責任

/goal を使うと、「次はこれをして」と毎回指示する必要がなくなります。条件を文章で書くだけで、ターンが終わるたびに別のモデルが条件を確かめ、満たすまで作業が続きます。長い移行や整理の作業で、手を止めずに済むのが利点です。

ただし、条件を決めるのは使う側の仕事です。あいまいな条件では早く止まりすぎたり続きすぎたりし、制約のない条件では余計な変更が増えます。「終端状態・確認手段・制約・打ち切り句」の4つを入れて書く習慣が、結果の質を決めます。判定されるのは「条件に書いた状態になったかどうか」であり、作業の中身の正しさまで保証されるわけではありません。

プログラムから動かしたい場合は、claude -p や Agent SDK を使います。どの方法でも、実行する場所・許可するツール・使用量の上限を決めたうえで使うことをおすすめします。

インストールの手順はClaude Code インストールガイド、全体像はClaude CodeとはとClaude Code 使い方ガイドをご覧ください。

---

利用できるモデルも更新が続いており、2026年10月時点の現行はFable 5.1・Opus 5.5・Sonnet 5.5・Haiku 5.5の4つです。

最終更新日：2026年10月12日

良い目標条件・悪い目標条件——実務で「効かない/暴走する」目標の見分け方

4つの要素は分かっても、実際にどう書けばよいかで迷う方は多いはずです。ここでは、監修者の河合継が実務で /goal を使う中で見てきた、うまくいかなかった書き方と、うまく回った書き方を並べます。

悪い目標条件の例：「認証まわりを改善して」「テストをちゃんと書いて」のような条件です。終わりの状態があいまいなので、手を加え続けたり、逆にすぐ切り上げたりして、結果が安定しません。何をもって完了とするかの確認手段が無いことが、いちばんの原因です。

良い目標条件の例：「〇〇のAPIについて、既存のテストがすべて通ること（終端状態）。npm test の結果で確認する（確認手段）。公開している関数の引数と戻り値は変更しない（制約）。15ターンで止める（打ち切り句）」のように、4つをすべて具体的な文で書きます。最初の数ターンは画面を見て動きを確かめ、必要なら条件を書き直します。

よくある質問（FAQ）

/goalの状態を確認するコマンドは何ですか？

引数なしの /goal です。実行中なら条件・経過時間・判定したターン数・トークン数・直近の判定理由が、達成済みなら達成した条件と時間・ターン数・トークン数が表示されます。/goal show という書き方は公式ドキュメントにありません。

/goalを途中で止めるにはどうすればいいですか？

/goal clear を実行します。stop・off・reset・none・cancel でも同じです。/clear で会話を新しくした場合も解除されます。

/goalと/loopはどちらを使えばいいですか？

終わりの状態をはっきり書ける作業（テストがすべて通る、特定のエラーが消えるなど）には /goal が向いています。/loop は条件ではなく時間の間隔で次のターンが始まるので、一定の間隔で繰り返したい作業に向いています。

/goalの目標条件はどう書けば失敗しにくいですか？

測れる終わりの状態、確認手段、変えてはいけないもの、ターン数や時間の区切りの4つを具体的に書きます。判定するモデルは会話に出た内容しか見ないので、Claudeの出力で証明できることを条件にします。条件は4,000文字まで書けます。

/goalを設定すると、コマンドの実行許可は聞かれなくなりますか？

いいえ。/goal は権限モードを変えません。手動の確認が必要な設定のままだと、コマンドを実行する前に確認が出ます。確認なしで進めたい場合は auto モードと組み合わせます。

セッションを閉じるとゴールは消えますか？

実行中だったゴールは、同じセッションを –continue や –resume で再開すると元に戻ります。ターン数・時間・トークン数は数え直しになります。達成済み・解除済みのゴールは戻りません。

/goalとAgent SDKは組み合わせて使えますか？

/goal は claude -p でも使えるので、1回の実行としてループを最後まで回せます。セッションの管理やエラー処理を自分のプログラムで行いたい場合は、Agent SDK を使います。

参考文献

• Claude Code 公式ドキュメント「Keep Claude working toward a goal」（goal.md）
  https://code.claude.com/docs/en/goal.md（確認日：2026年10月12日）
• Claude Code 公式ドキュメント日本語版「Claudeをゴールに向かって動作させ続ける」
  https://code.claude.com/docs/ja/goal
• Claude Code 公式ドキュメント「Common workflows」（common-workflows.md）
  https://code.claude.com/docs/en/common-workflows.md
• Claude Code 公式ドキュメント「Agent SDK overview」
  https://code.claude.com/docs/en/agent-sdk/overview.md
• Claude Code 公式ドキュメント「Agent SDK quickstart」
  https://code.claude.com/docs/en/agent-sdk/quickstart.md