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

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

Claude Code 比較的新しいバージョンされた/goalコマンドは、完了条件をセッションに宣言するだけで、Claudeが条件達成まで複数ターンにわたって自律的に作業を継続する機能である。従来の開発フローでは、大規模なAPIクライアント移行やテストカバレッジの底上げといった長時間タスクで、エンジニアが「続けて」「次のファイルへ」と繰り返しプロンプトを打ち込む必要があった。/goalはこのループを排除し、目標に向けた自動進行を提供する。

公式ドキュメント（goal.md）によれば、各ターン終了後に小型の高速モデル（Haiku）が完了条件を評価する。条件が満たされていなければ次のターンを自動開始し、条件が満たされれば自動的にゴールをクリアしてユーザーに制御を返す。評価ループはClaudeのメインコンテキストとは分離されており、コンテキスト圧迫を抑えた設計になっている点は実装上の重要なポイントである。

この機能は単なる自動化を超えた実用的な価値を持つ。目標が明確に定義された作業——モジュール移行、大規模リファクタリング、テストカバレッジ達成——において、エンジニアは思考の中断なく別の作業に集中できる。Claude Codeの基本的なセットアップや料金体系については、Claude Code 入門ガイドおよびClaude Code 料金プランの詳細を参照されたい。

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

/goalは1回のプロンプトではなく、ターンが終わるたびに別の評価モデル（既定ではHaiku）が完了条件を判定し直す仕組みです。どれだけ詳細な指示文を書いても、それは1回のやり取りにすぎず、作業しているClaude自身が「終わった」と判断してターンを止めてしまえば、そこで処理は完結してしまいます。

Anthropic公式ドキュメントによると、/goalの実体は「セッション単位のプロンプトベースStop hookのラッパー」であり、ターンが終わるたびに、実際に作業しているモデルとは別の小型モデル（既定はHaiku。third-party providerでは各providerの既定モデル。ANTHROPIC_DEFAULT_HAIKU_MODELで変更可）が会話の履歴だけを読んで条件の達成可否をyes/noで判定します。この評価モデルはツールを呼び出したり自分でファイルやコマンドを確認したりはせず、あくまでClaudeが会話上に残した出力だけを根拠に判断します。条件が満たされていなければClaudeはユーザーに制御を戻さず自動的に次のターンを開始し、満たされていればゴールを解除して達成をトランスクリプトに記録します。つまり本質的な違いは「1回の指示にどれだけ書き込むか」ではなく「ターンをまたいで、作業者とは別の第三者的な評価役が完了を判定し続けるかどうか」にあります。

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

コマンド構文はシンプルだが、条件文の質がそのまま自走の精度と安定性に直結する。まず基本操作を確認したうえで、条件設計の実践的な方法論に踏み込む。

基本コマンド一覧

# ゴールを設定して自走を開始する
/goal <完了条件>

# 現在設定されているゴールの状態を確認する
/goal show

# ゴールを手動でクリアして自走を停止する
/goal clear

公式ドキュメント（goal.md）が例示する代表的なユースケースは次のとおりである。

• モジュールを新APIに移行し、すべてのコールサイトがコンパイルを通過し、テストがパスするまで継続する
• 設計ドキュメントに沿って実装を進め、すべての受け入れ条件が満たされるまで継続する
• 大きなファイルを分割し、各ファイルが行数制限内に収まるまで継続する
• Issueバックログを処理し、キューが空になるまで継続する

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

条件文の設計が自走の安定性を決定する。曖昧な条件はHaikuによる評価がブレやすく、早期終了や過剰継続の原因になる。公式ドキュメントおよび実利用の知見を踏まえると、実用的な条件文は以下の4要素を含むと安定する。

1. 終端状態：何が完了したら終わりか（例：「全ファイルの移行が完了した」）
2. 確認手段：どのコマンドで検証できるか（例：「npm testがすべてパスする」）
3. 制約：副作用として許容しないこと（例：「既存の公開APIの変更は行わない」）
4. 打ち切り句：手詰まりになった場合の判断基準（例：「同じエラーが3回連続したら停止して報告する」）

具体的な入力例を示す。

/goal src/api/v1/ 以下の全ファイルで fetch を axios に移行し、
`npm test` がエラー0件でパスすること。
既存の公開インターフェースは変更しない。
同じテストが3回連続で失敗した場合は停止し、理由を報告する。

逆に避けるべきパターンも明確にある。「きれいにリファクタリングする」「パフォーマンスを改善する」のような主観的・定量的根拠のない条件は、Haikuが達成判断を誤りやすい。機械的に検証できる状態——コンパイル成功、テストのパス数、ファイル数の変化、コマンドの終了コード——を条件の核に据えるのが原則である。

Claude Codeのスラッシュコマンド全般については、Claude Code スラッシュコマンド詳細ガイドも参照されたい。

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

セッションを継続させる手段は/goalだけではない。公式ドキュメント（goal.md）は3つのアプローチを整理している。

手段	次のターンが始まる条件	停止条件	主な用途	設定の永続性
/goal	直前のターンが終了したとき	モデルが完了条件を確認したとき	目的の明確な長時間タスク	セッション限定
/loop	設定した時間間隔が経過したとき	手動停止、またはClaudeが完了を判断したとき	定期的な繰り返し処理	セッション限定
Stop hook	直前のターンが終了したとき	自作スクリプトまたはプロンプトが判断	決定論的チェックを伴う自動化	設定ファイルに永続

選択の判断軸は以下のとおりである。

• その場限りで目標が明確なタスク：/goalが最も手軽。セッション外への設定持ち越しが不要で、条件を打ち込むだけで済む。
• 時間で区切って繰り返したい処理：/loopが適している。スケジュール的な発想に近く、定期実行に向く。
• CIや複数セッションにまたがる決定論的チェック：Stop hookが堅牢。シェルスクリプトで終了判断を実装でき、外部ツールとの連携が容易である。

Auto modeも継続的な動作を提供するが、ターンごとの条件評価ではなくモデル自身の判断に依存するため、/goalとは制御の粒度が異なる（出典：goal.md）。この違いはエンジニアとして把握しておく価値がある。確実に停止させたい境界条件がある作業では、/goalにStop hookを組み合わせるのが現実的な設計である。

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

自走が便利である反面、エンジニアとして把握しておくべき制約がある。

• バージョン依存：比較的新しいバージョンでのみ動作する。古い環境では利用できない（出典：goal.md）。
• 評価モデルの限界：条件評価にHaikuを使用するため、複雑な主観的条件や文脈依存の判断は正確に評価されない可能性がある。
• セッション限定：/goalはセッション内でのみ有効である。長時間処理でセッションが切断された場合、ゴールはリセットされる。
• コスト増加：自走によってターン数が増えるため、API利用料がインタラクティブ操作より大きくなりうる。事前のコスト見積もりが必要である。
• 副作用の制御：不適切な条件文を与えると、想定外のファイル変更やコマンド実行が積み重なる可能性がある。本番環境での無制限実行は推奨されない。

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

/goal・/loop・Stop hookはいずれもClaude Code本体に組み込まれた機能だが、コミュニティではもう一つ、外部のシェルスクリプトで同じプロンプトを繰り返しClaude Codeへ投げ続ける手法が知られている。俗に「Ralph Wiggum方式」と呼ばれるこのやり方は、Claude Code自体に自走用の状態管理を持たせず、外側のループ（bashのwhile文など）が終了条件を判定してプロセスを再実行する点が特徴で、/goalや/loopのような内部の完了判定・停止判定を持たない。

手段	次のターン開始条件	停止条件	主な用途	設定の永続性
Ralph Wiggum方式	外部シェルループが再実行した時	外部スクリプト側の判定（終了コード等）	使い捨てプロンプトを軽量に反復させたい場合	スクリプト側に依存（Claude Code本体には残らない）

この方式は導入が手軽な反面、進行状況や失敗理由をClaude Code側が構造的に把握しないため、複雑な目標には/goalやStop hookの方が扱いやすい。実際に自社の自動化パイプラインでも、目標をシェルスクリプトの終了条件だけに委ねると失敗理由の切り分けが難しくなる場面があり、機械的に検証できる小さな単位まで目標を分割してから/goalやStop hookに渡す、という運用に落ち着いている。

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

以下は実際の開発作業で有効な/goalの使い方パターンである。Claude Code公式ドキュメントのCommon Workflows（common-workflows.md）が示すワークフローと組み合わせると、より体系的な自動化が実現できる。

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

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

シナリオ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% 以上であること。
既存のテストを削除・修正しない。新規テストファイルの追加のみ許可する。
解決困難なモック設計上の問題に3回直面した場合は停止して報告する。

これらのシナリオに共通するのは、終了状態がコマンドで機械的に検証できる点である。主観的な品質や「きれいなコード」を条件にしても、Haikuによる評価は安定しない。数値・ファイル数・コマンドの終了コードを条件の核に据えることで、自走の再現性が向上する。

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

当メディアの監修者・河合継はClaude Codeを3.5の時代から1年以上、実務で運用してきた。目標駆動の自走は強力だが、放っておくと暴走もする。実際に回して効いたコツを補足する。

• 停止条件を必ず先に書く。「N回失敗したら止めて報告」のような明確な打ち切り条件を入れておかないと、解けない問題に延々とトークンを溶かす。終了条件と同じくらい「止め時」を機械的に決めておくのが、コストと時間の両面で効いた。
• 最初の数ループは張り付いて観察する。自走させても完全には放置せず、序盤は方向がずれていないかを見ておく。早い段階で軌道修正すれば、無駄な往復を大きく減らせる。
• 小さく区切って投げる。一度に大きな目標を丸投げするより、機械検証できる小さなゴールに割って順に自走させるほうが、再現性も復旧性も高かった。

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

/goalはインタラクティブなCLI操作向けの機能であるが、同様の自走・自動化をプログラムから実現したい場面では、Claude Code Agent SDKが選択肢となる。公式ドキュメント（Agent SDK overview）によれば、Agent SDKはPythonとTypeScriptで利用可能であり、同じツール群・エージェントループ・コンテキスト管理をプログラムから操作できる。

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本体のバイナリが同梱されるため別途インストールは不要である。

2026年6月15日以降、Agent SDKおよびclaude -pのサブスクリプションプランでの利用は、インタラクティブ利用とは分離した月次Agent SDKクレジットから消費される点に注意が必要である（出典：Agent SDK overview）。APIの料金体系についてはClaude Code API料金ガイドで詳細を確認できる。

CI/CDパイプラインへの組み込みを検討する場合、Agent SDKのプログラム制御の方が/goalよりも適している。セッション管理・エラーハンドリング・ログ収集を自前のオーケストレーターで制御できるため、本番運用の観点から信頼性が高い。/goalは開発者のローカル作業効率化、Agent SDKはシステム間自動化と使い分ける判断基準が実用的である。

なお、弊社が開発するDeepAIは、実在の人物の容姿・表情・声を再現するバーチャルヒューマン／AIアバター製品である。定量的な達成条件（例：推論テストが全件パス、型チェックがエラーゼロ）を条件文として与える形で/goalを活用できる作業領域として認識している。ただし、本番推論コードへの影響範囲が広い変更には制約句の設計を慎重に行う必要がある。

Claude Codeの他ツールとの違いについては、Claude Code vs Cursor 比較およびClaude Code vs Codex 比較も参照されたい。

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

Claude Code /goalコマンドは、エンジニアが「次のステップ」を都度指示する必要をなくす。完了条件を自然言語で記述するだけで、Haikuによる毎ターンの評価ループが条件達成まで処理を継続する仕組みは、長時間の定型的な移行・整理作業において開発効率への直接的な効果が期待できる。

ただし、条件設計の責任はエンジニア側にある。曖昧な条件は誤った停止を招き、制約のない条件は副作用のリスクを高める。「終端状態・確認手段・制約・打ち切り句」の4要素を意識した条件文を書く習慣が、自走の品質を決定する。Haikuが評価するのはあくまで「条件文が示す状態が達成されているか」であり、作業の正しさそのものを保証するわけではない点は見誤らないようにしたい。

Agent SDKと組み合わせれば、CI/CDパイプラインやバッチ処理からも同様の目標駆動型の自走エージェントを構築できる。セキュリティや料金管理の観点から、実行環境・ツール許可・コスト上限を適切に設定したうえで運用することを推奨する。

Claude Codeのインストール手順はClaude Code インストールガイド、全体像の把握にはClaude CodeとはおよびClaude Code 使い方ガイドを参照されたい。

---

利用できるモデルも進化を続けており、現在はClaude 5世代（最上位のFable 5、速度と知能のバランスに優れたSonnet 5）とOpus 4.8・Haiku 4.5が使えます。

最終更新日：2026年8月

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

「終端状態・確認手段・制約・打ち切り句」の4要素フレームワークは分かっていても、実際にどう書けば良いのか迷う方が多いはずです。ここでは私(河合継)が現場で/goalを使う中で、実際に「効かなかった目標」と「うまく回った目標」の書き方の違いを対比で示します。

悪い目標条件の例：「認証まわりを改善して」「テストをちゃんと書いて」といった指示は、終端状態が曖昧なため、モデルが「改善した」と自己判断してしまい、無限に手を加え続けたり、逆にすぐ切り上げてしまったりと結果が安定しません。確認手段（何をもって完了とするか）が無いことが最大の原因です。

良い目標条件の例：「〇〇のAPIエンドポイントについて、既存のテストスイートが全件パスすることを終端状態とし、`npm test`の実行結果を確認手段とする。ただし既存のpublic APIのシグネチャは変更しない（制約）。3回連続で同じエラーが出た場合は作業を打ち切り、原因をコメントで報告する（打ち切り句）」のように、4要素をすべて具体的な文で埋めると、自走の暴走や手戻りを大きく減らせます。目標を投げっぱなしにせず、最初の数サイクルは張り付いて挙動を観察し、条件文を調整していくのが実務でのコツです。

よくある質問（FAQ）

参考文献

• Claude Code 公式ドキュメント「Keep Claude working toward a goal」（goal.md）
  https://code.claude.com/docs/en/goal.md
• 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