/goal vs /loop vs Stop Hooks vs Auto Mode — 4つの自律実行方法を完全比較【2026年版】
Claude Codeには自律実行系の機能が4つある — /goal、/loop、Stop Hooks、Auto Mode。それぞれ停止条件と継続性が違うため、用途に応じて使い分ける必要がある。
この記事では4×6の比較マトリクスとフローチャートで、即決定できる選び方を示す。
4つの自律実行方法とは
4つの方法は「停止条件」と「セッション継続性」の2軸で性格が違う。
/goal — 条件達成で止まる
完了条件を1文で設定すると、Haiku評価器が毎ターン後に判定。条件を満たしたら自動停止する。「終わりが明確な作業」に最適。
/loop — 時間間隔で繰り返す
/loop 5m のように間隔を指定すると、5分おきにプロンプトが実行される。停止条件は別途設定が必要。「定期ポーリング」に最適。
Stop Hooks — settings.jsonで恒久設定
~/.claude/settings.json に判定ロジックを書くと、全セッションで恒久的に停止条件が適用される。/goal の内部実装でもある。
Auto Mode — 承認プロンプトをオフ
claude --permission-mode auto で起動すると、ファイル書き込み・コマンド実行の承認待ちが消える。停止条件ではなく「無人化」の仕組み。 他の3つと併用する位置づけ。
4×6 完全比較マトリクス
それぞれを6つの観点で並べると、選び方が一発で見える。
| 観点 | /goal | /loop | Stop Hooks | Auto Mode |
|---|---|---|---|---|
| 用途 | 条件達成で停止 | 定期繰り返し | 全セッション共通の停止条件 | 承認プロンプトを排除 |
| 停止条件 | Haiku評価器が判定 | 時間間隔（手動停止） | settings.jsonで定義 | なし（手動停止） |
| セッション継続 | 単一セッション | 単一セッション | 全セッション恒久 | 単一セッション |
| 評価方式 | プロンプトベース（Haiku） | なし（時間） | スクリプト型 or プロンプト型 | なし |
| 設定の手間 | 軽（コマンド1回） | 軽（コマンド1回） | 重（settings.json編集） | 軽（起動フラグ） |
| 適性タスク | テスト・リファクタ・移行 | デプロイ監視・ポーリング | 全プロジェクト共通ルール | 他3つと併用 |
どれを使うべき？ — フローチャート
ユースケースから即決定できるフローを置いておく。
タスクの性格は？
├─ 終わりが明確（条件で定義可能）
│ ├─ 単発で短時間 → /goal
│ ├─ 単発で長時間 → /goal + Auto Mode + ターン上限
│ └─ 複数セッションで共通 → Stop Hooks（プロンプト型）
│
├─ 定期実行が必要
│ ├─ セッション中だけ → /loop
│ └─ セッション閉じても継続 → /schedule（cron）
│
└─ 承認待ちが鬱陶しいだけ
└─ 単独で → Auto Mode
└─ /goal や Stop Hooks との併用 → 推奨パターン
推奨組み合わせパターン
実務で頻出するパターンを3つ紹介する。
パターン1: テスト全件通過まで完全無人実行
# ターミナル1: Auto Modeで起動
claude --permission-mode auto
# プロンプト内
/goal test/auth のテストがすべて通り、npm test が exit 0 で完了する, or stop after 15 turns
/goal + Auto Mode で、承認なしで条件達成まで自律実行。最も多い使い方。
パターン2: 全プロジェクト共通の安全装置
~/.claude/settings.json の permissions.deny で破壊操作を全セッション共通でブロック：
{
"permissions": {
"deny": [
"Bash(rm -rf /)",
"Bash(rm -rf ~)",
"Bash(sudo *)",
"Bash(git push --force *)",
"Bash(DROP TABLE *)",
"Edit(.env)",
"Edit(.env.*)"
]
}
}
deny rules は全 permission mode で常に効く（bypassPermissions でも rm -rf / / rm -rf ~ 等はサーキットブレーカーが残る）。これに加えて Stop hookイベント（Stop / PostToolBatch）で decision: "block" を返すスクリプトを書けば、独自の停止条件を実装できる。
⚠️ 注：「ターン数N超えたら停止」のような汎用キーは
settings.jsonにない。ターン上限は/goal文内のor stop after N turnsで明示するのが公式仕様。
パターン3: 夜間バッチ + 朝の状況確認
# 夜（cron経由）
/schedule daily 02:00 -- "/goal 前日PRレビュー要約をreport.md に書く"
# 朝（手動）
/loop 30s -- "report.md の最終更新時刻を確認"
/schedule（cron）+ /loop（ポーリング） の組み合わせ。夜間に重い処理、朝に状況確認の2段構成。
失敗しやすい組み合わせ
逆に やめておいた方が良い 組み合わせも知っておく。
| ❌ 危険な組み合わせ | 理由 |
|---|---|
/goal + /loop | 評価が二重に走り、判定が矛盾しがち |
| Auto Mode 単独で長時間タスク | 暴走時の停止装置がない |
| Stop Hooks に重いLLM判定 | 全セッションで評価コストが累積 |
/schedule でAuto Mode必須タスク | セッションが閉じている時の承認待ちで詰まる |
よくある質問
/goal と /loop はどちらを使うべきですか？
「条件達成で止めたい」なら /goal、「一定間隔で繰り返したい」なら /loop。テスト全件通過まで自走させたい場合は /goal、5分おきにデプロイ状況をチェックしたい場合は /loop を選ぶ。
Stop Hooks は /goal と併用可能ですか？
可能だ。実は /goal の内部は Stop Hooks の仕組みで動いている。/goal はセッション限定の使い捨て、Stop Hooks は settings.json に書くため全セッションで恒久適用される、という違いだ。
Auto Mode 単体で十分なケースは？
短時間（5-10分）の作業で、停止条件が「全工程完了」と明確な場合だ。コード生成→テスト→commit の一連の流れなら、Auto Mode単体で承認なしで完走できる。長時間タスクは /goal との併用を推奨する。
/schedule はいつ使いますか？
セッションを閉じても定時で実行したい場合だ。毎朝7時に前日のPR要約レポートを生成する、毎週月曜に dependencies 監査を回す、等の定期バッチに最適だ。/goal や /loop はセッション継続中のみ動作する。
4つを併用しても安全ですか？
可能だが推奨は2-3つの組み合わせまで。例：/goal（条件） + Auto Mode（無人化） + Stop Hooks（全セッション共通の停止条件）。/loop と /goal の併用は冗長なので避けてほしい。
スクリプト型とプロンプト型の Stop Hooks の違いは何ですか？
スクリプト型は shell スクリプトで判定（exit code 0 で停止）、プロンプト型は AI に判定させる（LLMが「達成」と返したら停止）だ。確定的な判定はスクリプト型、柔軟な判定はプロンプト型を選ぶ。
セッションを閉じても続けたい場合は？
/schedule で cron 形式の定期実行を組むか、CI/CD から Remote Control で呼び出すのが王道だ。/goal --resume はセッション中断後の再開には使えるが、無人での継続実行には向かない。
関連記事
- Claude Code /goal 完全ガイド — シリーズPillar
- Claude Code 自律実行機能の進化 — v2.1.139以降で何が変わった？ — 機能の歴史
- Claude Code スラッシュコマンド完全リファレンス 2026年版 — 全コマンド一覧