AIエージェントの安全対策というと、モデルに危険な操作を拒否させたり、実行前に人へ確認したりする設計が先に浮かびます。しかし、能力と接続先が増えるほど「判断を絶対に間違えない」前提は危うくなります。Anthropicが2026年5月に公開した実運用の知見から見えてくるのは、賢さを監視するより、失敗しても届かない境界を先に作るという考え方です。
承認ダイアログは、最後の砦にならない
Anthropicによると、Claude Code利用者は権限確認の約93%を承認していました。確認が増えるほど一件ごとの注意が薄れる「承認疲れ」が起きるため、人が毎回見れば安全とは限りません。
さらに同社の管理されたレッドチーム演習では、研究者が従業員へ「このプロンプトを実行して」と依頼する形で攻撃しました。その指示には、認証情報を読み出して外部へ送る処理が紛れ込んでおり、同じプロンプトを25回試したうち24回で情報送信まで進んだと報告されています。利用者自身が入力した指示は、モデル側から見ると正規の依頼に見えやすいからです。
ここで重要なのは、モデルや利用者を責めることではありません。確認操作には確率的な見落としがあり、ゼロにはできないと認めることです。
守る対象を3層に分ける
Anthropicは、エージェントの防御対象を大きく3つに整理しています。
- モデル：システム指示、分類器、学習などで危険な行動を選びにくくする
- 実行環境：サンドボックス、仮想マシン、ファイル境界、外向き通信制御で到達範囲を制限する
- 外部コンテンツ：MCP、プラグイン、Web検索などから入る未信頼データと権限を管理する
モデル層は「何をしようとするか」を整えます。一方、環境層は「何ができるか」を強制します。たとえば認証情報をサンドボックスへ入れず、許可先以外への通信を遮断しておけば、悪意ある指示をモデルが見抜けなくても被害範囲を狭められます。
用途ごとに隔離の強さを変える
同社は、製品の性格に応じて異なる隔離方式を採用しています。
- claude.ai：セッションごとに消えるコンテナでコードを実行し、利用者の端末から分離
- Claude Code：開発者の端末上で動くため、作業領域への書き込みを許しつつ、ネットワークを初期状態で拒否するOSレベルのサンドボックスを利用
- Claude Cowork：一般利用者が難しいコマンドを判断する前提を置かず、仮想マシンと限定した共有フォルダで境界を固定
Claude Codeのサンドボックス導入では、権限確認が84%減ったとされています。境界を強くすると自由が失われるように見えますが、安全な範囲を先に決めれば、その内側では確認を減らして自律性を上げられます。
設計レビューで確認したい4項目
実務では、次の順で確認すると設計の穴を見つけやすくなります。
- 秘密情報：エージェントの実行環境に本当に置く必要があるか
- 外向き通信：必要な宛先だけに制限されているか
- ファイル権限：読み取り、書き込み、削除を別々に制御できるか
- 未信頼入力：リポジトリ設定、ローカル設定、MCPの返却内容を実行前に信用していないか
これは車両の機能安全にも似ています。制御ソフトが常に正しく判断すると期待するだけでなく、異常が起きても危険側へ広がらない独立した制約を置きます。AIエージェントでも、モデルの性能評価と被害範囲の設計は別のレビュー項目にするべきです。
まとめ
高性能なモデルは失敗を減らせますが、接続できる資源が増えれば、一度の失敗が持つ影響も大きくなります。安全なエージェント運用の核心は「絶対に間違えないAI」を待つことではありません。
- 承認操作を過信しない
- モデル、実行環境、外部コンテンツを別々に守る
- 認証情報と通信経路を実行環境から切り離す
- 用途と利用者の専門性に合わせて隔離方式を選ぶ
賢さは性能を上げます。境界は事故の大きさを決めます。エージェントを本番へ入れるなら、この2つを別々に設計することが出発点です。
公式ソース
- Anthropic Engineering: How we contain Claude across products（2026年5月25日公開）
- Anthropic Experimental: sandbox-runtime（GitHub）
※本文中の割合や試験結果はAnthropicが公開した自社製品・自社演習の値です。他のモデルや環境へそのまま一般化できる数値ではありません。