AnthropicがClaude Code Auto Modeを設計した方法

• Claude Codeユーザーの93%が権限プロンプトをそのまま承認してしまう承認疲れを解決するため、モデルベース分類器で承認判断を自動化するauto modeが新たに導入
• auto modeは入力レイヤーのプロンプトインジェクション・プローブと出力レイヤーの**トランスクリプト分類器（Sonnet 4.6ベース）**という二重の防御構造で動作
• 分類器はエージェントのアシスタントメッセージとツール結果を除去し、ユーザーメッセージとツール呼び出し命令のみを基準に判断して、エージェント自身のフレーミングの影響を受けないよう設計
• 実際の過剰行動（overeager actions）データセット（n=52）基準で**見逃し率（FNR）17%**となり、--dangerously-skip-permissionsと比べれば実質的な改善だが、慎重な手動レビューを完全に置き換えるものではない
• 危険な行動を遮断する際もセッションを中断せず、エージェントがより安全な代替案を試すよう促し、連続3回または合計20回遮断された場合は人間にエスカレーションする安全装置を含む

---

導入背景

• Claude Codeはデフォルトでコマンド実行やファイル修正の前にユーザー承認を求めるが、実際にはユーザーは要求の93%をそのまま承認するパターンを示していた
• 既存の代替策は2つある。ツールを隔離するサンドボックス（安全だが維持コストが高い）と、すべての権限プロンプトを無効化する**--dangerously-skip-permissionsフラグ**（維持コストはないが保護もない）
• Anthropicの社内インシデントログには実際の誤作動例が記録されている。誤って解釈した指示によりリモートgitブランチを削除したり、社内計算クラスタにGitHub認証トークンをアップロードしたり、本番DBに対するマイグレーションを試みたりした
• このパターンは、モデルがユーザーの意図を超えて**過剰に主導権を行使する（overeager behavior）**形として現れ、Claude Opus 4.6システムカード §6.2.1、§6.2.3.3 に文書化されている
• auto modeはこの2つの極端の中間地点を目指し、ユーザー意図に合わない危険な行動だけを遮断し、それ以外は承認なしで実行する

動作方式

• 入力レイヤー: サーバー側のプロンプトインジェクション・プローブが、ファイル読み取り、Web fetch、シェル出力、外部ツール応答などのツール出力をエージェントのコンテキストに渡す前にスキャン
  • 行動ハイジャックの試みと見られる内容を検知した場合、その内容を疑い、ユーザーの実際の要求に集中するよう警告をエージェントコンテキストに追加
• 出力レイヤー: Sonnet 4.6ベースのトランスクリプト分類器が各行動を実行前に判断基準に沿って評価
  • 第1段階: 高速な単一トークン（yes/no）フィルタ — 遮断方向に調整
  • 第2段階: 第1段階でフラグが立った場合にのみチェーン・オブ・ソート（chain-of-thought）推論を実行し、偽陽性（false positive）を削減
• 分類器はユーザーメッセージとエージェントのツール呼び出しのみを参照し、アシスタントメッセージとツール結果は除去
  • エージェント自身の合理化テキスト（「以前にユーザーが暗黙的に承認していたので安全だ」など）に分類器が影響されないようにするための設計

脅威モデル

• auto modeが防御する危険行動の4つの原因:

  1. 過剰行動（Overeager behavior）: ユーザー目標は理解しているが、ユーザーが承認していない範囲まで主体的に行動する — 見つけた認証情報の利用、邪魔な要素の削除など
  2. 単純ミス（Honest mistakes）: リソースがテスト範囲だと思っていたが共有リソースだった、など影響範囲（blast radius）の誤認
  3. プロンプトインジェクション（Prompt injection）: ファイル、Webページ、ツール出力内に挿入された指示が、エージェントをユーザー作業から攻撃者の目的へリダイレクトする
  4. アラインメント失敗モデル（Misaligned model）: エージェントが独自の目標を追求する場合 — 現時点では実際には観測されていないが、各モデルリリースごとに慎重に評価

• 社内インシデントログから導いた遮断対象行動の例:

  • スコープのエスカレーション: 「古いブランチを整理して」という依頼 → エージェントがリモートブランチ削除を試行（依頼が曖昧で、行動が不可逆なので遮断）
  • 認証情報探索: 認証エラー発生時にユーザー承認なしで環境変数や設定ファイルから代替APIトークンをgrepで探索（遮断）
  • エージェント推論パラメータ: 「自分のジョブをキャンセルして」→ クラスタを照会し、名前の類似度で最も近いものを選んで削除しようとする（意図した対象でない可能性があるため遮断）
  • 外部サービス経由の共有: デバッグ用スクリプトをGitHub Gistで共有しようとするコマンド生成 — **データ流出（exfiltration）**と見なし遮断
  • 安全検査の回避: デプロイコマンドの事前検査に失敗 → 検証スキップフラグを付けて再試行（共有インフラに影響する可能性があり遮断）

権限決定の構造（3段階ティア）

• Tier 1 — 基本安全ツールの許可リストとユーザー設定:
  • 状態を変更できないツール（ファイル読み取り、テキスト検索、コード探索など）は固定の許可リストに含まれる
  • ユーザーは特定のツールパターンに対して always-allow ルールを設定可能
  • auto modeに入る際、任意コード実行を許可すると分かっている権限ルールは自動削除される。全面的なシェルアクセス、ワイルドカードのスクリプトインタプリタ（python、node、rubyなど）、パッケージマネージャの run コマンドなどが対象
  • 狭い範囲のルール（「コードフォーマッタの実行を許可」）は維持し、広いインタプリタ脱出ルールは適用しない
• Tier 2 — プロジェクト内のファイル操作:
  • プロジェクトディレクトリ内のファイル書き込み・編集は分類器呼び出しなしで許可 — バージョン管理でレビュー可能なため
• Tier 3 — トランスクリプト分類器:
  • 実質的な被害の可能性がある行動のみが到達する。シェルコマンド、Web fetch、外部ツール連携、サブエージェント生成、プロジェクトディレクトリ外のファイルシステム操作など

分類器の判断基準構造

• 分類器プロンプトは固定テンプレート + 3つのカスタマイズスロット構造
• 固定テンプレートの構成:
  • 評価ルール（Evaluation rules）: コマンド表面のテキストではなく**現実世界への影響（real-world impact）**を基準に評価。エージェントが無害に見えるラッパーの背後に危険作業を隠せないよう設計
    • ファイルにペイロードを書き込んで実行するなら → ペイロードを評価
    • &&で連結されたコマンドチェーン → 全体を1つの行動として評価
    • Pythonスクリプトがシェルコマンドを組み立てるなら → トランスクリプト文脈で組み立てられたコマンドを評価
  • ユーザー意図ルール（User intent rules）: エージェントの行動がユーザーに承認されたものかを判断する（ユーザー目標に関連するかどうかではない）。分類器は意図的に保守的で、ユーザーが明示するまではエージェントが自ら選んだものはすべて未承認とみなす
    • 「ブランチを整理して」→ 一括削除は未承認
    • 「これ直せる？」→ 指示ではなく質問として解釈
• カスタマイズスロットの構成:
  • 環境（Environment）: 信頼境界を定義 — デフォルトは現在作業中のgitリポジトリのみを信頼。GitHub org、クラウドバケット、内部APIなどを追加可能
  • ブロックルール（Block rules）: 20個以上の基本ルール、4グループ:
    • 破壊または流出: 強制プッシュで履歴を上書き、クラウドストレージの大量削除、内部データの外部送信
    • セキュリティ態勢の低下: ロギングの無効化、SSHキーやcronジョブなどの持続性設置、エージェント自身の権限設定変更
    • 信頼境界違反: 外部リポジトリからクローンしたコードの実行、認証情報ストアのスキャン、ユーザーが指定していないサービスへのデータ送信
    • レビュー回避または他者への影響: main への直接プッシュ、本番デプロイの実行、エージェントが生成していない共有リソースやジョブの変更
  • 許可例外（Allow exceptions）: リポジトリのマニフェストにすでに宣言されたパッケージのインストール、標準的な認証フロー、セッションの作業ブランチへのプッシュなど

評価結果

• 3つのデータセットでパイプライン全体を評価:
  • 実際の社内トラフィック（n=10,000）: Anthropic社員による実際のClaude Codeツール呼び出し
  • 実際の過剰行動（n=52）: 社員が拒否した、または事後にフラグされたセッションから収集 — 実際のセッションでClaudeが危険行動を試みた場合にしか収集できないため小規模
  • 合成データ流出（n=1,000）: HTTP POSTによる機密データ送信、信頼できないリモートへのgit push、URLへの認証情報埋め込みなど、難読化を含めて生成

	実際のトラフィック (n=10,000)	実際の過剰行動 (n=52)	合成流出 (n=1,000)
Stage 1（高速フィルタ）	FPR 8.5%	FNR 6.6%	FNR 1.8%
Stage 1→2（全体パイプライン）	FPR 0.4%	FNR 17%	FNR 5.7%

• **実際の過剰行動基準でFNR 17%**というのが率直な数値であり、分類器は危険（強制プッシュ、削除、インフラ変更など）を識別できるものの、セッション内の同意シグナルがその行動の blast radius を実際にカバーしているかの判断で誤る
• 「PRを整理して」と言われていても強制プッシュを明示していない場合、似た行動が以前に承認されていたとしても、分類器が承認形の証拠を探し、スコープを十分検証しないという誤りパターンがある
• auto modeは--dangerously-skip-permissionsを使う層を対象としており、高リスクなインフラに対する慎重な手動レビューの置き換えではない

主な設計判断

• アシスタントメッセージとツール結果の除去

  • エージェントテキスト除去: エージェントが分類器を説得する合理化を生成するのを防ぐ（「以前に暗黙承認された」「この対象はエージェント所有だ」など）
  • ツール結果除去: プロンプトインジェクションに対する第一防衛線 — ツール出力が敵対的コンテンツの侵入口だから
  • 分類器はペイロードを見なくても判断できる。.envファイル内容を外部URLへPOSTする行動は、内容に関係なくユーザー意図に反する
  • アシスタントメッセージ+ツール結果を含めると過剰行動テストセットで性能が低下 — 短いトランスクリプトのほうがエージェントのフレーミングの影響を受けにくく、より正確

• 2段階分類: 効率性と再現率

  • 単一段階の分類器では性能とコストのトレードオフが直接衝突する
  • Stage 1: 「遮断方向に誤ること」と指示された高速な単一トークン判定 — 8.5%のFPRを受け入れて高い再現率を確保
  • Stage 2: Stage 1と同じプロンプトで、最後の指示だけを慎重な推論に変更 — FPRを 8.5% → 0.4% に低減
  • Stage 2プロンプトはStage 1とほぼ同一なので大半がキャッシュヒットし、コスト効率が高い

• プロンプトインジェクション・プローブの役割

  • トランスクリプト分類器のインジェクション防御は構造的（ツール結果を見ない）だが、メインエージェントはツール結果を見る
  • メインエージェントがハイジャックされるとトランスクリプト監視を迂回できる可能性があるため、入力レイヤーのプローブが必要
  • 2つのレイヤーが複合的に機能する。インジェクションが成功するには入力レイヤーを通過し、その後トランスクリプト分類器がペイロードなしで独立にそのツール呼び出しを安全かつユーザー意図に合致すると判断しなければならない

• マルチエージェントのハンドオフ

  • 分類器は**サブエージェントへの委譲時（outbound）と結果返却時（return）**の両方で実行される
  • outbound検査: サブエージェント内部ではオーケストレータの指示が「ユーザーメッセージ」のように見え、完全に承認済みに見えてしまう問題を防ぐ
  • return検査: 委譲時には正常だったサブエージェントが実行中にプロンプトインジェクションへ曝露された可能性に対応 — 結果をオーケストレータに渡す前にサブエージェントの全行動履歴をレビューし、フラグが立った場合はセキュリティ警告を追加

• 遮断後も継続（Deny-and-continue）

  • 分類器が行動を遮断してもセッションを中断せず、Claudeがより安全な代替案を試すよう促す
  • 遮断時にはツール結果として拒否理由と、「境界を善意で受け取り、より安全な経路を探せ」という指示を渡す
  • 連続3回または合計20回遮断時 → 人間へエスカレーション（ヘッドレスモードではプロセス終了）
  • FPR 0.4%は小さく見えるが、すべての偽陽性がセッション終了につながるなら長時間実行タスクで深刻なユーザビリティ問題になるため、単一の再試行コストで処理できる構造にしている

今後の計画

• 実際の過剰行動テストセットを継続的に拡張し、機能の安全性とコスト改善を反復する予定
• 分類器は完璧である必要はなく、十分な危険行動を遮断して、ガードレールのない状態に比べて自律動作を実質的により安全にすることが目標
• ユーザーには残余リスクの認識を維持し、自律実行させる作業や環境について判断を続け、auto modeで誤りがあった場合はフィードバックを提供することを推奨