メインコンテンツへスキップ
ブログ一覧

Claude Code Auto Mode実践ガイド —「承認疲れ」から解放される安全な自律実行の設計パターン

(更新: 2026年03月27日)
Claude CodeAuto ModeAI開発自動化セキュリティ

--dangerously-skip-permissionsは便利だが怖い。かといって毎回の承認プロンプトで集中力が途切れる」——Claude Codeユーザーなら誰もが感じるこのジレンマに、2026年3月24日、第三の選択肢が登場した。Auto Modeは、AIが実行前にアクションの安全性を自動判定する「分類器ベースの事前審査」で、自律性と安全性の両立を目指すresearch preview機能だ。

本記事では、内部アーキテクチャの解説から、既存の権限モードとの使い分け判断基準、そして自律デーモンやCI/CDへの組み込みパターンまでを実践的に解説する。

Auto Modeとは何か — 3つの権限モードの位置づけ

従来の2択: 毎回承認 vs --dangerously-skip-permissions

Claude Codeの権限管理は、これまで実質的に3段階だった。

  1. 全アクション手動承認 — 安全だが、長時間タスクで「承認疲れ」が発生する
  2. allowlistによる部分許可settings.jsonpermissions.allowで特定ツールを許可。柔軟だが設定が煩雑
  3. --dangerously-skip-permissions — 全許可。自動化には便利だが、名前が示す通りリスクが大きい

Auto Modeが埋める「安全な自律実行」の空白地帯

Auto Modeは「分類器が危険と判断したアクションのみ人間に確認を求める」第四のモードだ。内部的には三段階のTier分類で動作する。

Tier 対象 挙動
Tier 1 読み取り専用(ファイル読み取り、検索) 常に自動許可
Tier 2 プロジェクト内のファイル編集 ワーキングディレクトリ内なら自動許可
Tier 3 シェルコマンド・外部連携 分類器が判定

有効化はシンプルで、CLIから--enable-auto-modeフラグを付けて起動し、セッション中にShift+Tabで切り替える。

bash
# Auto Modeを有効化して起動
claude --enable-auto-mode

# セッション内でShift+Tabを押すと
# default → acceptEdits → plan → auto と4段階でモードが切り替わる

現時点ではresearch previewであり、Teamプランで利用可能。Claude Sonnet 4.6またはOpus 4.6が必要で、Haikuやclaude-3系モデルでは使えない。

内部アーキテクチャ — 二層防御と分類器の仕組み

入力層と出力層の二層構造

Auto Modeのセーフティネットは二層に分かれている。

入力層では、サーバー側でプロンプトインジェクションを検査する。ファイル内容やWeb取得結果に埋め込まれた悪意あるプロンプトを、メインモデルに到達する前にフィルタリングする。

出力層では、メインモデルが生成したツールコール(アクション)を分類器が審査する。この分類器は常にClaude Sonnet 4.6で実行され、メインセッションのモデル選択には依存しない。

分類器の設計上のポイント

分類器への入力はユーザーメッセージとツールコールペイロードのみに限定されている。アシスタントの推論テキストやツール出力は意図的に除外されている。これにより、ファイル内容やWeb取得結果に悪意あるテキストが含まれていても、分類器の判断を直接操作できない設計になっている。

出力層の分類器自体も二段階で動く。Stage 1は高速・低コストで、見逃し率(FNR)を下げる方向にチューニングされている。Stage 1で「要注意」と判定されたものだけがStage 2に進み、Chain-of-Thought推論で精査される。

分類器の性能と限界

Anthropicが公開している性能指標は以下の通り。

  • FPR(過剰ブロック率): 0.4% — 安全なアクションを誤ってブロックする確率
  • FNR(見逃し率): 17% — 危険なアクションを通してしまう確率
  • データ流出シナリオでのFNR: 5.7%

FNR 17%という数字は、正直に言えば低くはない。Simon Willison氏が指摘するように、「非決定論的なAI分類器」は「決定論的なサンドボックス」と本質的に性質が異なる。Dockerのネットワーク制限は100%機能するが、AI分類器には必ず見逃しがある。この限界を理解した上で使うことが前提だ。

実践: どの場面でAuto Modeを選ぶか

Auto Modeが適するケース

  • 対話的な開発セッション — 人間が画面を見ている状態で、承認疲れを軽減したい場面
  • 長時間リファクタリング — 大量のファイル編集が発生するが、基本的にプロジェクト内で完結する作業
  • 信頼できるリポジトリでのコード生成 — 既知の依存関係のみを使う開発

Auto Modeが適さないケース

  • 本番環境への直接操作 — 分類器の17%の見逃しが致命的になりうる
  • 機密情報を含むディレクトリでの作業.envやクレデンシャルへのアクセスリスク
  • --dangerously-skip-permissionsが依然有効な場面 — 完全に隔離されたDocker/VM内、かつネットワーク制限済みのCI環境

重要な仕様として、フォールバック挙動がある。分類器が連続3回または合計20回アクションをブロックすると、Auto Modeは一時停止する。対話モードでは手動承認に戻るだけだが、-p(非対話)モードではセッションが終了する。自動化で使う場合、この挙動への対処が必須になる。

Hooksとの併用パターン

HooksはAuto Modeの分類器より先に実行される。つまり、Hooksで明示的にdenyしたアクションは分類器に到達しない。この優先順位を利用して、「絶対に実行させたくない操作」をHooksで確実にブロックしつつ、それ以外はAuto Modeに委ねるハイブリッド構成が組める。

json
// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -qE '(rm -rf /|DROP TABLE|curl.*\\| bash)'; then echo 'BLOCK: destructive command detected' >&2; exit 2; fi"
          }
        ]
      }
    ]
  }
}

この構成では、rm -rf /やパイプ経由のスクリプト実行といった明らかに危険なパターンをHooksが決定論的にブロックし、それ以外のグレーゾーンをAuto Modeの分類器が判定する。個人的には、この「決定論的フィルタ + 非決定論的分類器」の組み合わせが現時点で最もバランスが良いと感じている。

自律デーモン・CI/CDへの組み込み設計

非対話モード(-p)での制約

-pモードでAuto Modeを使う場合、最大の問題はフォールバック時のセッション終了だ。自律デーモンでは、このリトライハンドリングが設計上の必須要件になる。

bash
#!/bin/bash
# Auto Mode + -p モードでのリトライハンドリング例

MAX_RETRIES=3
RETRY_COUNT=0

run_claude_task() {
  claude -p --enable-auto-mode \
    --model claude-sonnet-4-6 \
    <<< "$1"
  return $?
}

while [ $RETRY_COUNT -lt $MAX_RETRIES ]; do
  # Git checkpointを作成(分類器の見逃しに備える)
  git stash push -m "auto-mode-checkpoint-$(date +%s)" 2>/dev/null

  if run_claude_task "$PROMPT"; then
    echo "Task completed successfully"
    # 変更内容を検証
    git diff --stat
    break
  else
    RETRY_COUNT=$((RETRY_COUNT + 1))
    echo "Session ended (attempt $RETRY_COUNT/$MAX_RETRIES)"
    git stash pop 2>/dev/null
    sleep 10
  fi
done

現時点での現実的な選択

正直なところ、CI/CDや自律デーモンでは--dangerously-skip-permissions + Dockerネットワーク制限の方が予測可能性が高い。理由は明確で、決定論的なサンドボックスは「何がブロックされるか」が事前に100%わかるが、Auto Modeの分類器は確率的に動作するため、同じコマンドでも通ったり通らなかったりする可能性がある。

ただし、Auto Modeが正式版になった際の移行を見据えて、モード切替を環境変数で制御できるようにしておくのは良い設計判断だ。

bash
# 環境変数でモード切替
if [ "$CLAUDE_PERMISSION_MODE" = "auto" ]; then
  CLAUDE_FLAGS="--enable-auto-mode"
else
  CLAUDE_FLAGS="--dangerously-skip-permissions"
fi

claude -p $CLAUDE_FLAGS <<< "$PROMPT"

Git checkpointingとの併用も推奨される。Auto Modeであれ--dangerously-skip-permissionsであれ、実行前にgit stashやブランチ作成で復元ポイントを確保しておけば、分類器の見逃しやCLIの暴走に対するセーフティネットになる。

まとめ — research previewとの正しい付き合い方

Auto Modeは「承認疲れ vs 全許可リスク」という二項対立を解消する有望なアプローチだ。しかし、FNR 17%が示す通り完璧ではない。

今すぐ試す価値があるのは対話的な開発セッションだ。Shift+Tabで気軽に切り替えられるので、まずは信頼できるリポジトリで体験してみてほしい。一方、自律デーモンやCIへの本格導入は正式版リリースを待ちつつ、環境変数による切替機構だけ先に仕込んでおくのが現実的だ。

最も重要なのは、「分類器に任せて終わり」にしないこと。Git checkpoint、Hooks、サンドボックスとの多層防御の一部としてAuto Modeを位置づけるのが、research previewとの正しい付き合い方だ。


参考リンク:

もっと読む他の技術記事も読む