blog

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

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

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

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

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

/goal コマンドの自走ループ図 ユーザーが/goalを入力→Claudeが1ターン実行→Haikuが条件を評価→条件達成なら制御を返す・条件未達なら次のターンへ戻るループの図 ユーザーが /goal を入力 Claude が 1ターン実行 Haiku が 条件を評価 条件達成 → 制御を返す 条件未達 → 次ターン開始
図1:/goal コマンドの自走ループ——各ターン後にHaikuが条件を評価し、未達なら自動的に次のターンへ進む。条件達成でゴールが自動クリアされ、制御がユーザーに返る(出典:Claude Code 公式ドキュメント goal.md

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

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

/goal:条件を満たすまでターンをまたいで自動で作業を続ける
/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利用料がインタラクティブ操作より大きくなりうる。事前のコスト見積もりが必要である。
  • 副作用の制御:不適切な条件文を与えると、想定外のファイル変更やコマンド実行が積み重なる可能性がある。本番環境での無制限実行は推奨されない。

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

以下は実際の開発作業で有効な/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による評価は安定しない。数値・ファイル数・コマンドの終了コードを条件の核に据えることで、自走の再現性が向上する。

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 使い方ガイドを参照されたい。


参考文献

監修

河合 継(クリスタルメソッド株式会社 代表取締役)

AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番組でのAI解説実績を持つAI研究者として、AIの研究開発を主導している。
運営会社について編集方針

AIブログ購読

 
クリスタルメソッドがお届けする
AIブログの更新通知を受け取る

Study about AI

AIについて学ぶ

  • 音声・音楽AIのイメージ

    SakuraSpeech(サクラスピーチ)|日本語特化のAI音声合成 – ブラウザ・API・完全オフライン対応【2026年版】

    SakuraSpeech(サクラスピーチ)は、入力したテキストを自然で表情ゆたかな日本語音声に変換する、日本語特化のAI音声合成(TTS:Text-to-Spe...

  • GPT-5.5 Claude エージェント ベンチマーク選定——日本企業が問い直すべき評価軸

    GPT-5.5 Claude エージェント ベンチマーク選定——日本企業が問い直すべき評価軸

    GPT-5.5がClaude Fable 5を上回った——「Agents’ Last Exam」とは何か 2026年6月、AIエージェント評価の文脈...

  • 米上院 金融AI 規制 公聴会——日本の銀行・証券への実務的示唆

    米上院 金融AI 規制 公聴会——日本の銀行・証券への実務的示唆

    上院 金融AI 規制 公聴会の要点——何が、なぜ今議題に上ったか 2026年6月11日午前10時(米東部夏時間)、米上院銀行・住宅・都市問題委員会(U.S. S...

View more