Claude Code を長時間自律で走らせる - セッションを止めない手法の体系

Claude Code を長時間自律で走らせる - セッションを止めない手法の体系

作成日:
更新日:
Claude CodeAIエージェント自律エージェント自動化AI

「Claude Code に大きめのタスクを渡して、できるだけ長く・止まらずに・自律で進めてほしい」。AIコーディングを使い込むほど出てくる願いです。一方で、無制限に放任するのは危険でもあります。

この記事は、Claude Code を長時間自律で走らせる手法を体系的に整理するものです。Anthropic 公式のエージェント自律性の考え方を土台に、承認の自動化・ターンの継続・文脈の分離、そして全手法を貫く「自己検証」という軸でまとめます。

NOTE

本記事は Anthropic 公式（エージェント自律性の計測、auto mode の解説、/goal ほか）と、公式リポジトリの ralph-wiggum プラグインを一次情報として確認した内容に基づきます。確認に使った環境は Claude Code v2.1.165 です。

まず前提: 「自律」は3つの掛け算

Anthropic は、エージェントの自律性を「固定の性質」ではなく、モデル・ユーザー・プロダクト設計の3つが合わさって立ち現れるものと定義しています。実際、Claude Code の自律度はユーザーの習熟とともに上がります。公式の計測によると、

  • 経験豊富なユーザー（750セッション以上）は40%超が完全自動承認を使う（新規ユーザーは約20%）
  • ターンの99.9パーセンタイル（最も長いターン）は、2025年10月の25分未満から2026年1月には45分以上へ倍増

つまり「長く自律で走らせる」は、ツールの設定だけでなく信頼の積み上げと一体です。いきなり全権限を渡すのではなく、段階的に手綱を緩めるのが正しい順序です。

そして、すべての手法に共通する本質はこれです。

自律度を上げる鍵は、どのレベルでも同じ——Claude に自分の作業を検証する手段を与えること。

検証なしの自律は「速く間違える」だけです。逆に検証さえ自動化できれば、長時間の放任が現実的になります。以下、レベル別に見ていきます。

レベル1: 承認の壁を下げる（auto mode）

最初の摩擦は「ファイル編集していい？」「このコマンド実行していい？」という都度の承認です。これを外す方法は2段階あります。

--dangerously-skip-permissions（全スキップ・非推奨）

claude --dangerously-skip-permissions

ツール実行の許可確認をすべてバイパスします。名前のとおり危険で、公式も「ゼロメンテナンスだが保護もゼロ」と位置づけています。使うならネットワーク遮断したサンドボックス内に限るべきです。

auto mode（推奨される中間解）

公式が勧めるのは auto mode です。全スキップではなく、モデルベースの分類器で危険な操作だけ止めつつ自律実行します。仕組みは2層です。

  • 入力層（プロンプトインジェクション検知）: ファイル読み込み・Web取得・シェル出力などをスキャンし、注入の疑いがあれば「この内容は疑え」と警告を添える
  • 出力層（トランスクリプト分類器）: 各アクション実行前に Sonnet 4.6 で評価（高速な yes/no → 怪しい場合のみ熟考）

アクションは3ティアに分かれ、読み取り専用は許可リスト、プロジェクト内のファイル変更はバージョン管理で追えるとして通し、それ以外を分類器に回します。force push・本番デプロイ・データ持ち出し・権限バイパスなどが soft_deny / hard_deny の対象です。

WARNING

auto mode は安全側に倒した良い仕組みですが、万能ではありません。公式も「高リスクなインフラでの慎重な人間レビューの代替にはならない」と明言しています。承認疲れを減らす手段であって、責任放棄の手段ではありません。

プロンプトインジェクションが RCE になる話で書いたとおり、自律度を上げるほど攻撃面も広がります。auto mode の2層防御は、その現実への公式の回答です。

レベル2: コンテキストを保たせる

長時間走らせると、コンテキストウィンドウが埋まって自動コンパクションが走り、文脈が劣化します。これを能動的に管理します。

  • 別タスクに移るときは /clear で文脈をリセット
  • 自動コンパクション（上限近く）を待たず、早めに /compact で要約圧縮
  • 大きな作業は /context で何が容量を食っているか把握する

コンテキスト管理はコストにも直結します（トークンとコストの記事参照）。長時間タスクほど「無駄な文脈を持たせない」のが効きます。

レベル3: ターンを止めない（/goal・/loop・Stop hook）

承認を自動化しても、Claude は1ターンで「完了した（と判断した）」と制御を返してきます。長時間走らせるには、ターンを跨いで作業を継続させる仕組みが要ります。公式には3つの方法があり、「次のターンを何が始めるか」で選びます。

方法次のターンが始まる契機止まる条件
/goal前のターンが終わったらモデルが完了条件の充足を確認したら
/loop一定の時間間隔が経過したら自分で止める／Claude が完了と判断
Stop hook前のターンが終わったら自分のスクリプト／プロンプトが判断

/goal: 完了条件を満たすまで走り続ける

/goal（v2.1.139 以降）は、検証可能な完了条件を設定し、満たすまでターンを継続します。

/goal test/auth の全テストが通り、lint がクリーンになる

肝は、各ターンの後に「小さく速いモデル（既定 Haiku）」が完了条件を判定する点です。「まだ」なら理由付きで次のターンを促し、「満たした」ら自動で終了します。作業するモデルとは別の評価器が判定するので、「自分で完了と思い込む」誤りを減らせます。

良い条件の書き方は、「npm test が exit 0」「git status がクリーン」のようにClaude の出力で証明できる測定可能な終了状態にすること。暴走を防ぐため または20ターンで停止 のような上限句も入れられます。-p で非対話実行もできます。

claude -p "/goal CHANGELOG.md に今週マージした全PRのエントリがある"

Stop hook と Ralph Wiggum（公式プラグイン）

実は /goal の正体は「セッションスコープの prompt ベース Stop hook のラッパー」です。Stop hook は、Claude が終了しようとした瞬間を捕まえて、続行させたりブロックしたりできる仕組みです。

これを使った自律ループの代表が Ralph Wiggum——Anthropic 公式リポジトリ（anthropics/claude-code）の正式プラグインです。/ralph-loop コマンドで起動し、Stop hook が終了をブロックして同じプロンプトを再投入し続けます。

1. タスクに取り組む
2. 終了しようとする
3. Stop hook が終了をブロック
4. Stop hook が同じプロンプトを再投入
5. 完了まで繰り返す

プロンプトは毎回同じでも、前回の作業はファイルと git 履歴に残るので、各反復は変更後の状態から再開します。

Ralph ループの起動（公式プラグイン）
/ralph-loop "<プロンプト>" --max-iterations <n> --completion-promise "<完了の証明>"
/cancel-ralph   # 中断

IMPORTANT

Stop hook で再投入し続ける設計には無限ループの危険があります。素朴に書くと「Claude 応答 → Stop hook がブロック → 続行 → またブロック…」が止まりません。stop_hook_active フラグの確認・最大反復数（--max-iterations）・完了条件ファイルなどで、必ず止まる設計にしてください。

レベル4: 文脈を汚さない（サブエージェント）

ビルド・テスト・ログ解析のような冗長な出力を伴う処理をメイン会話で実行すると、コンテキストが汚れて長時間タスクが続きにくくなります。サブエージェントは別コンテキストで動き、結果（要約）だけをメインに返すので、本筋を汚さずに済みます。

ただし注意があります。サブエージェントは別コンテキストですが、ファイル変更や git 操作の副作用は同じ作業ツリーに出る場合があります。並行作業を本当に分離したいなら、worktree などファイルシステム側の分離も併用してください。大規模な並列化は Opus 4.8 の Dynamic Workflows（数十〜数百のサブエージェントを編成）の領域です。

レベル5: 24時間走らせる（VPS + tmux + スケジュール）

セッションを「閉じても走り続ける」段階です。

  • VPS 上の tmux 内で Claude Code を起動し、デタッチして放置。翌日に完成した差分を受け取る
  • 開いたセッションに依存しない定期実行は、cloud routines や desktop scheduled tasks（/loop や /schedule）でスケジュールする

ヘッドレス（-p）実行を cron に乗せる際の定番のつまずきは、(1) claude のフルパスを使う、(2) cron はシェルプロファイルを読まないので API キーを明示的に渡す、の2点です。そして本番投入前に必ず手動で1回試すこと。5分の手動テストが、壊れた自動化のデバッグ数時間を救います。

全レベルを貫く本質: 自己検証

ここまでの手法は、結局すべて1点に収束します。

スレッドが長く・自律的になるほど、検証は自動化されていなければならない。26時間走るスレッドを手でレビューはできない。システムが自分を検証しなければならない。

具体的には、Claude が自分の作業を確かめる手段を持たせることです。

  • テストが通るか（npm test exit 0）
  • ビルドが成功するか
  • lint がクリーンか
  • 実際に動くか（curl で 200、画面の目視、verify スキル）
  • git status がクリーンか

重要なのは、テストは「書いたこと」を検証するが「頼んだこと」は検証しないという点です。ページネーションを頼んだのにソート機能を実装しても、テストは全部通るかもしれません。だから完了条件（/goal の condition や Stop hook の判定）は「意図どおりか」を見るように書く必要があります。Anthropic の計測でも、Claude は複雑なタスクで人間が割り込むより2倍以上の頻度で自分から不確実性を申告しており、「黙って間違えない」性質が長時間自律の土台になっています。

安全に長時間走らせるためのチェックリスト

体系をまとめると、長時間自律は「継続の仕組み × 検証 × 安全設計」の組み合わせです。

  • 継続: auto mode で承認を自動化＋ /goal か Ralph ループでターンを継続
  • 検証: 完了条件を「意図どおりか」を測れる形で定義（テスト・ビルド・lint・実動作）
  • 分離: 冗長処理はサブエージェント、並行作業は worktree
  • 安全: 権限は必要最小限、最大反復数・時間上限・監査ログ、危険操作は人間承認を残す
  • 検証運用: 本番投入前に手動で1回、サンドボックス／隔離環境で

まとめ

  • エージェントの自律は「モデル・ユーザー・プロダクト設計」の掛け算。信頼を積み上げて段階的に手綱を緩めるのが正しい順序
  • 承認は --dangerously-skip-permissions（全スキップ・危険）ではなく auto mode（2層防御＋3ティア）で自動化するのが公式推奨
  • ターンの継続は /goal（完了条件を別モデルが判定）/ /loop（時間間隔）/ Stop hook の3択。Ralph Wiggum は Stop hook を使う Anthropic 公式プラグイン
  • Stop hook ループは無限ループ対策（stop_hook_active・最大反復数・完了条件）が必須
  • 冗長処理はサブエージェントで文脈分離、24時間運用は VPS+tmux やスケジュール
  • 全レベルの本質は「自己検証」。長くなるほど検証は自動化必須で、条件は「意図どおりか」を測る形に

「長く自律で走らせる」は、放任ではなく検証の自動化です。auto mode で承認を、/goal でターンを自動化し、検証可能な完了条件を与える——この3つが揃って初めて、安心して席を立てるようになります。

参考リンク