Claude Code /goal 完全ガイド — AI自律実行で「人間がループから抜ける」全技術【2026年版】

Claude Codeを使っていて、結局プロンプトを打って確認するだけでイライラしたことはないだろうか。

プロンプトを入力する
Claudeが作業する
止まる、また入力する
作業する、止まる

1つのタスクを仕上げるまでに「続けて」「次に進んで」と十回以上打ち続ける。実際に手を動かしているのはClaude Codeなのに、画面の前から一切離れられない。

/goal コマンドは、その仕組みを根本から変える。 コマンドを1つ打って台所へ行き、コーヒーを淹れて戻ってきたら作業が終わっている。それが現実になる。

/goalとは — ループを人から機械へ渡すスキル

/goal は、完了条件を設定するとAIが条件達成までターンをまたいで自律実行するClaude Codeのスラッシュコマンドだ。

Claude Codeの通常動作は「1ターン実行 → 停止 → 次の入力を待つ」の繰り返しだ。毎ターン、ユーザーが次の指示を出さないと何も動かない。ユーザーがループの一部に組み込まれている状態である。

/goalを使うとこの構造が変わる：

/goal の後に「完了条件」を書いて実行する
Claude Codeが1ターン分の作業をする
**Haiku（評価専用の軽量モデル）**が会話ログを読み、「条件は満たされたか？」を判定する
まだなら即座に次のターンへ。条件が満たされたら「Goal achieved」と表示して停止する

ループを回すのが人間ではなくなる。それだけのことだが、AIに張り付く時間が劇的に変わる。

# 認証モジュールのテストが全件通るまで自律実行
/goal test/auth のすべてのテストが通り、npm test が exit 0 で完了する

3ステップで /goal を始める

数分で動くようになる導入手順だ。

ステップ1: 完了条件を1文で書く 観測可能・測定可能・ログから検証可能な条件を1文で記述する。曖昧な表現は避ける。

ステップ2: /goal コマンドを実行する Claude Codeのプロンプトで /goal <完了条件> と入力する。AIが条件達成までターンをまたいで自律的に実行を続ける。

ステップ3: Auto Modeと組み合わせる 別ターミナルで claude --permission-mode auto を起動すると、承認プロンプトもオフになり、条件達成まで完全無人で実行される。

📘 完了条件の書き方を5つのベストプラクティスで深掘りした記事は Claude Code /goal 完了条件の書き方を参照。

条件の書き方で9割が決まる

/goal のアウトプットの質は、条件の書き方でほぼ確定する。Haiku評価器は会話ログだけを読んで判定するため、「ログを見れば30秒で確認できる」レベルの具体性が必要だ。

通る条件の例：

# ✅ 観測可能・測定可能・ログから検証できる
/goal test/auth のテストがすべて通り、lint がクリーンな状態
/goal 今週マージされた全PRのエントリがCHANGELOG.mdに存在する状態
/goal 旧APIの呼び出し箇所が全件移行済みでビルドが成功する状態

うまくいかない条件の例：

# ❌ 曖昧・主観的・ログから検証不能
/goal コードをきれいにしておいて
/goal 良い感じに仕上げて
/goal だいたいできたら教えて

曖昧な条件は2種類の失敗で終わることが多い：

Claudeが「何をもって完了か」を判断できずに同じ作業を繰り返す
評価器が証拠のないまま「完了した」と誤判定する

どちらもトークンの無駄遣いで、作業は進まない。裁判の証拠のように考えると判断が楽になる。「この条件が満たされたという証拠が、会話ログの中に存在するか」そう問いかけて書き直せる形が良い条件だ。

長時間の作業には4ブロック構造を使う（Kanau Tech推奨テンプレート）

注: 公式の /goal 仕様では、条件は最大4,000文字の単一文字列。以下はKanau Tech が実務で採用しているテンプレートで、公式仕様ではなく現場ベストプラクティスだ。

数分で終わる作業なら1行の条件で十分だが、1時間を超えるような大きなタスクには構造化した書き方が安定する：

/goal [達成したいゴール]

context:
[プロジェクトの構成・使用技術・今回の作業背景など判断に必要な情報]

done when:
- [測定可能な完了条件1]
- [測定可能な完了条件2]

do not:
- [触らないファイル・変更してはいけない設定・避けるべきアプローチ]

progress tracking:
completed steps を progress.md に随時記録すること

or stop after 20 turns

最後の progress tracking 行が特に重要だ。長時間の実行では、Claudeが前のターンで何を決定したかを忘れ始め、矛盾した行動を取ることがある。progress.md に進捗を書き出させておくと外部メモリとして機能し、実行が安定する。

末尾の or stop after N turns は公式仕様の安全装置で、必ず併記する。

さらに複数時間かかる作業には plan.md（開始前の方針）と decisions.md（なぜその選択をしたか）を追加すると、長い実行全体の一貫性が保たれる。

/goal を最大化する3つの環境設定

CLAUDE.md にプロジェクトのルールを書いておく

/goal は毎ターン、プロジェクトルートと ~/.claude/ の CLAUDE.md を自動で読み込む。ここにアーキテクチャの方針・コーディング規約・完了の定義を書いておくと、Claudeがすべてのターンで「このプロジェクトでの正解」を参照しながら動く。

## CLAUDE.md の記載例

### コーディング規約
- TypeScriptを使用。any型は禁止
- テストはvitest。カバレッジ80%以上を維持すること

### 完了の定義
- lint・型チェック・テストがすべてパスしている
- 変更したファイル以外のテストが壊れていない

設定を省いて実行すると、Claudeはゴールだけを手がかりに動く。CLAUDE.mdが充実しているほど、ゴール条件を短く書いても高精度な結果が返ってくる。

Auto Mode で承認プロンプトをなくす

デフォルトのClaude Codeは、ファイル書き込みやコマンド実行のたびに確認を求める。/goal で自律実行しても、途中で承認待ちが発生したら無人実行の意味がなくなる。

# 承認プロンプトをすべてオフにして起動
claude --permission-mode auto

/goal と Auto Mode を組み合わせると、条件が満たされるか上限に達するまで、何も確認を求めてこない状態で動き続ける。

--resume でクラッシュ後も再開できる

長時間実行中にセッションが切れた場合、--resume または --continue でセッションを再開すると、アクティブだった /goal の条件が自動で復元される。夜間実行が途中で落ちていても、朝に起動し直せばそこから続く。

/goal vs /loop vs /schedule vs Stop Hooks vs Auto Mode

Claude Codeには自律実行系の機能がいくつかある。混同しがちなので比較表で整理する。

機能	停止条件	セッション継続	評価方式	適性タスク
`/goal`	完了条件達成で停止	単一セッション	Haiku評価器	条件付き自律実行
`/loop`	時間間隔で繰り返し	単一セッション	なし（時間）	定期ポーリング
`/schedule`	cron形式	セッション閉じても継続	スクリプト型	定時バッチ
Stop Hooks	settings.jsonで定義	全セッション恒久	スクリプト/プロンプト	全セッション共通停止条件
Auto Mode	なし（手動停止）	単一セッション	なし	完全無人 + 他機能と併用

実は /goal の内部は Stop Hooks の仕組みで動いている。/goal はそのセッション限定で使い捨て、Stop Hooks は settings.json に書くため全セッションに恒久的に適用される。

📘 4つの自律実行方法の使い分けを4×6マトリクスで完全網羅した記事は /goal と /loop、Stop Hooks、Auto Mode の使い分けを参照。

コーディング以外の3領域で使う

/goal はコードを書くためだけのコマンドではない。「測定可能な完了条件がある作業」ならほぼ何でも使える。

リサーチ・情報収集

/goal [テーマ]に関して過去90日以内の信頼できるソースを20件以上収集し、
著者・日付付きで構造化したサマリーを research/output.md に保存する。
低信頼性サイトからのソースは除外すること

コンテンツ制作

/goal [テーマ]の1500字記事を、/writing-samples のサンプルに対して
「明確さ・独自性・文体の一致」の3観点で自己レビューをパスするまで書き続ける。
style-guide.md の禁止表現は一切使わない

依存関係の監査

/goal package.json の全パッケージについて、バージョン・最終更新日・
既知の脆弱性・推奨アクション（維持/更新/置換）を一覧にした
audit-report.md を作成する。実際の依存関係は変更しない

パターンは共通だ。「何を作るか・合格基準は何か・やってはいけないことは何か」の3点が書ければ、業種や作業の種類を問わず使える。

📘 実務事例3つを完全形ゴール文付きで解説した記事は Claude Code /goal 実務事例集を参照。

複数 /goal を並列で走らせる

3つのターミナルウィンドウを開いて、別のプロジェクトを並列実行することもできる。夜寝る前にそれぞれに /goal を設定すれば、朝起きた時に3タスクが完了している。

# ターミナル1：フロントエンドのリファクタリング
/goal src/components の全コンポーネントをTypeScriptに移行し、型エラーが0件になる

# ターミナル2：テストカバレッジの改善
/goal カバレッジが60%を下回っているモジュールのテストを追加し、全体を80%以上にする

# ターミナル3：ドキュメントの更新
/goal 先週のPRで変更されたAPIエンドポイントのドキュメントをすべて最新の仕様に揃える

単純に「3倍速い」というより、1人のエンジニアが物理的に同時進行できない並列ストリームを走らせていることになる。

制約はClaude側にはない。「3つの条件を前日に明確に書けるか」というユーザーの側にある。

/goal が苦手なこと

正直に伝えておく。すべての作業に向いているわけではない。

リアルタイムの外部検証が必要な作業（本番APIの応答を確認しながら進める場合など）
完了基準が主観的・審美的な作業（「良いデザインになったら止めて」は判定不能）
隠れた依存関係がある作業（Claudeがアクセスできないデータが判断に必要な場合、ループが止まらない）
間違った方向にゴールを設定した場合（正しい方向なら速く完了し、間違った方向でも速く完了してしまう）

最後の点が一番重要だ。/goal は自律性を増幅させる仕組みなので、方向が正しいときは強力だが、方向が間違っているときも強力に動いてしまう。大きなゴールを設定する前に、方針が正しいことを確認しよう。

📘 暴走・ループ・コスト爆発を回避する5つの運用ルールは自律実行のループ＆コスト爆発を回避する戦略を参照。

中小企業にとっての意義 — Atomic DX™とAI自律実行

/goal の本質的な価値は開発現場だけにとどまらない。経営者が画面に張り付かない、夜間にAIが業務を完了させる、というのは中小企業の人手不足への直接的な答えだ。

Kanau Tech™が提唱する Atomic DX™ は、業務を第一原理思考で最小単位に分解し、AIが安全に回せる粒度まで再構築する方法論だ。/goal はその実行エンジンになる。

具体的にはこういう使い方ができる：

介護施設：日報の集約とシフト最適化を夜間バッチで自律実行
税理士・社労士事務所：法令変更チェック・申告書類の事前レビューを早朝に完了
飲食店：在庫発注計算と売上日報を営業終了後に自動生成
製造業：不良品データの集計とマニュアル更新を週次自走

「経営者が朝起きたら仕事が終わっている」という働き方の本質的変化が、/goal で現実になる。

📘 業種別の実装パターンとROI試算は中小企業の業務自動化 — 介護・福祉・士業・飲食向け実装パターンで詳説。

クイックリファレンス

# ゴールを設定する
/goal [条件]

# 現在の状態を確認する（進行ターン数・使用トークン・評価結果）
/goal

# 途中で止める（off / cancel / reset / none も同じ効果）
/goal clear

# ターミナルから直接実行（CI・自動化での活用）
claude -p "/goal [条件]"

# 安全装置：Nターンまたは指定時間で強制停止
/goal [条件], or stop after 10 turns
/goal [条件], or stop after 30 minutes

# 完全無人モードで起動
claude --permission-mode auto

今日のタスクで1つ試してみよう。どんな条件を書けばいいか迷ったときは、「コードを読まない人が30秒で確認できるか」を基準にするのがいちばん早い解決策だ。

よくある質問

/goal と /loop の違いは何ですか？

/goal はターン後に完了条件を評価し、満たされたら自動停止する。/loop は時間間隔で繰り返し実行する仕組みで、停止条件は別途必要だ。自律実行の中心が「条件」か「時間」かの差である。

完了条件はどう書けば良いですか？

観測可能・測定可能・ログから検証可能な条件を1文で書く。例：「test/auth のすべてのテストが通り、npm test が exit 0 で完了する」。曖昧な条件はHaiku評価器が判定できず、無限ループの原因になる。

Auto Modeと組み合わせて安全ですか？

破壊操作のないタスクなら安全だ。Auto Mode（--permission-mode auto）で承認プロンプトをオフにし、/goal と組み合わせると完全無人実行が可能。本番DBやデプロイは対象外にすべきだ。

--resumeでクラッシュ後も再開できますか？

可能だ。--resume または --continue でセッション再開すると、アクティブだった /goal の完了条件が自動復元される。夜間実行が途中で落ちても、朝に起動し直せば続きから実行可能だ。

コスト（トークン消費）はどれくらいですか？

評価器はHaikuで動作し、メインターンのトークン比5-10%程度。100行のリファクタリングで平均3.2ターンが目安だ。ターン上限を併記することで暴走時のコスト爆発を防げる。

中小企業でも導入できますか？

可能だ。Claude Codeは月額固定の個人プランから利用でき、夜間バッチ・日報集約・申請書ドラフトなど中小企業の業務にも適用できる。Kanau Tech™のAtomic DX™は /goal を軸にした業務再構築方法論だ。

どんな業務に向きませんか？

完了基準が主観的・審美的な業務（「良いデザインになったら止めて」）、リアルタイム外部検証が必要な業務、隠れた依存関係がある業務には不向きだ。

並列実行のリスクは何ですか？

別プロジェクトで /goal を複数並列実行する場合、ファイル競合は起きない。ただし誤った方向のゴールは並列に強く動いてしまうため、事前に方針を確認することが重要だ。

既存のRPAと何が違いますか？

RPAは事前定義した固定手順を繰り返すが、/goal は「ゴール条件」を与えるとAIが状況を見て手段を選びながら進める。要件変化や例外対応に強いのが本質的な違いだ。

失敗を判定する仕組みは何ですか？

Haikuモデルが各ターン後に会話ログを読み、完了条件と照合する。「ログから30秒で検証できる」レベルの条件であれば高精度に判定される。

評価器に使われるHaikuとは何ですか？

Anthropic社の軽量・高速モデルで、判定タスクに特化している。メインで動くSonnetやOpusとは別プロセスで会話ログを読み、完了条件を充足しているか判定する。

セキュリティ上の注意点は何ですか？

Auto Modeで認証情報・API Key・本番DB変更を伴うタスクを実行しないこと。Hooks・Workspace信頼ダイアログで実行範囲を制限し、CI/CDでは最小権限のシークレット運用が必須だ。

参照・元記事

この記事を書くにあたって、以下を参考にした。

The Complete Guide to /goal, /loop, /schedule & Stop Hooks in Claude Code — @sairahul1
Just 1 command that changed my whole life — @defileo
How to Use /goal to Build an Entire SEO Content System While You Sleep — @cyrilXBT
Claude Code 公式ドキュメント — /goal