AIエージェントの確認画面は、安全装置である一方、増えすぎると「全部承認する」作業になります。Anthropicによると、Claude Code利用者は権限確認の93%を承認していました。そこで同社は、人間の確認を単に消すのではなく、別モデルが実行直前の操作を審査する「auto mode」を設計しました。
重要なのは、AIに自由を与えたことではありません。通常作業は流し、被害が起こり得る操作だけを狭い情報で再判定する構造にした点です。
「毎回聞く」と「全部許す」の間を作る
従来の選択肢は極端でした。手動確認は安全性を高めますが、クリックが続けば確認疲れが起きます。一方、権限確認を全面的に迂回する方式は手軽でも、多くの環境で危険です。
auto modeは、操作を3段階で扱います。
- Tier 1：読み取りや検索など、状態を変えない安全なツールは許可
- Tier 2：プロジェクト内のファイル編集は許可。変更はGitで追跡可能
- Tier 3：シェル、外部通信、プロジェクト外の操作などは分類器が審査
すべてを重い審査へ送らず、損失可能性のある操作に審査コストを集中させています。
審査役には「言い訳」を見せない
出力側の分類器が見るのは、主にユーザーのメッセージと実行予定のツール呼び出しです。エージェント自身の説明文とツール出力は除外されます。
これは意図的な設計です。エージェントが「これは安全です」と自分の行動を正当化したり、Webページやファイルに混入したプロンプトインジェクションが審査役まで届いたりする経路を減らします。審査対象を「AIが何と言ったか」ではなく、「ユーザーが何を頼み、AIが何を実行しようとしているか」に絞っています。
入力側では別に、ツール出力を走査するプロンプトインジェクション検知が働きます。つまり、入ってくる情報の検査と出ていく操作の検査を分けた二層構造です。
承認は「目的」ではなく「被害範囲」で読む
分類器は、操作が目的に関連しているだけでは許可しません。たとえば「古いブランチを整理して」は、リモートブランチの一括削除まで明示的に認めたとは限りません。「ジョブを止めて」も、AIが名前の近い対象を推測して削除する根拠にはなりません。
ここでの原則は明快です。
- 対象が特定されているか
- 操作が可逆か
- 共有資源や他人へ影響しないか
- 安全確認の迂回や外部送信を伴わないか
これは車載開発の変更管理にも似ています。「不具合を直す」という目的への合意と、本番ECUへ特定の変更を書き込む承認は別物です。AI運用でも、目的と実行権限を分ける必要があります。
二段階判定は速さと見逃しを交換する
auto modeの分類器は、まず単一トークン出力の高速判定を行い、危険の可能性がある場合だけ推論を伴う第二段階へ進みます。Anthropicの評価では、実トラフィック1万件に対する誤検知率は第一段階の8.5%から、全パイプラインで0.4%まで下がりました。
ただし安全性は完全ではありません。実際の「先回りしすぎた危険操作」52件では、全パイプラインの見逃し率は17%でした。合成した情報流出1,000件でも見逃し率は5.7%です。Anthropic自身も、高リスクなインフラ作業で慎重な人間レビューを置き換えるものではないと説明しています。
この数字は重要です。分類器は「無確認」より安全にする層であり、サンドボックス、明示的な拒否ルール、最小権限、Gitによる復元性を不要にはしません。
実務へ持ち込む4つの設計原則
- 可逆な操作を先に自動化する：読み取り、検索、作業ブランチ内の編集から始めます。
- 審査役へ必要最小限だけ渡す：ユーザー指示と実行内容を中心にし、AI自身の説明を判定根拠にしません。
- 信頼境界を環境ごとに定義する：社内Git、クラウド、外部URLを同じ扱いにしません。
- 高リスク操作は人間へ戻す：本番デプロイ、強制push、大量削除、機密情報の外部送信は別枠にします。
まとめ
確認回数を減らすだけなら、権限を広げれば済みます。しかし、それでは速さと安全を交換しただけです。
auto modeが示したのは、通常操作を流す許可層、危険操作を狙う分類層、到達範囲を物理的に狭める隔離層を組み合わせる考え方です。AIエージェントの自律性は「確認をなくす」ことでなく、どの操作を、誰が、どの情報で止めるかを設計して初めて実用になります。
公式ソース