Anthropicは2026年6月に、Claudeを社内外の製品へ広く載せるなかで、何を人間承認に任せ、何を環境側で絶対に止めるべきかを整理したエンジニアリング記事を公開しました。要点は単純で、AIエージェントの安全性をモデルの賢さだけに依存させないことです。権限の境界、ネットワーク送信の制御、秘密情報を見せない設計を先に作ると、業務自動化の速度を上げつつ事故の被害範囲を小さくできます。
Claudeのcontainment設計とは何か
Anthropicが今回強調したのは、AIエージェントのリスクは「失敗する確率」だけでなく「失敗したときの被害半径」で決まるという考え方です。Claude Codeでは従来、操作ごとに承認を求める方式を採っていましたが、社内テレメトリでは承認ダイアログの約93%がそのまま通っており、承認疲れが実運用上の弱点になっていました。そこで発想を変え、何をしてよいかを毎回聞くのではなく、そもそも届ける範囲を狭める containment が中心テーマになっています。
まず押さえるべき3つのリスク分類
記事では、AIエージェントの事故要因を3つに分けています。1つ目は user misuse で、利用者が危険な指示を与えるケースです。2つ目は model misbehavior で、誰も頼んでいないのにモデルが近道を探し、権限外の行動へ踏み出すケースです。3つ目は external attackers で、README、Web、MCP、外部ツール出力などに埋め込まれたプロンプトインジェクションや通常の攻撃です。この3分類にしておくと、運用ルールだけで防ぐのか、実行環境で遮断するのか、レビュー対象を切り分けやすくなります。
Anthropicは実例も開示しています。信頼確認前にプロジェクト設定を読んでフックが実行される不具合、悪意あるプロンプトをユーザー経由で貼り付けさせて ~/.aws/credentials の送信を狙うフィッシングなどです。後者は社内演習で25回中24回成功したとされ、ユーザー指示に見える攻撃はモデル側の意図判定だけでは止めにくいことが分かります。
防御は3層で考えると実務に落としやすい
Anthropicは、防御対象を environment、model、external content の3層で整理しています。最優先は environment で、サンドボックス、VM、ファイル境界、egress controls により「たとえ誤作動しても秘密を持ち出せない」状態を作ります。model 層では system prompt や classifier を重ね、Gray SwanのAgent Red Teaming benchmarkでは単発攻撃の成功率を約0.1%、100回の適応攻撃でも約5〜6%に抑えたと説明しています。さらにClaude Code auto modeは、実行前に危険行動の約83%を止めるとされますが、それでも100%ではないため、環境側の境界が前提になります。
外部コンテンツ層も軽視できません。監査済みのコネクタでも、読み込むREADMEやWebページが安全とは限らないからです。GitHub連携やWeb検索を許す場合は、接続先の信頼性よりも「そのツールに書き込み権限を与えるか」「本番DBへ届くか」を先に点検したほうが、被害半径を小さくできます。
Anthropicが示した3つの隔離パターン
1つ目は claude.ai の ephemeral container です。コード実行は隔離インフラ上の gVisor コンテナで行い、ファイルシステムはセッション単位で破棄されます。2つ目は Claude Code の human-in-the-loop sandbox で、macOS の Seatbelt や Linux の bubblewrap を使い、読み取りは許可しつつ、ワークスペース外への書き込みやネットワーク送信を厳しく絞ります。この変更で permission prompt は約84%減ったとされています。3つ目は Claude Cowork の local VM で、ユーザーが選んだ作業フォルダだけをマウントし、資格情報はホストのキーチェーンに残す構成です。技術力が高くない利用者ほど、対話的な承認よりも絶対境界のほうが向いている、という判断です。
Claude Codeの公式dev containerドキュメントも同じ方向を補強しています。dev container は強い保護を提供しますが、完全ではありません。特に --dangerously-skip-permissions を使う場合、コンテナ内で見える ~/.claude やマウント済み秘密情報は持ち出され得るため、trusted repositories だけで使い、~/.ssh やクラウド認証情報をホストからマウントしないことが明示されています。
導入判断に使えるチェックリスト
企業でAIエージェントを広げる前に、最低でも5点を確認すると失敗しにくくなります。第一に、認証情報は実行環境へ本当に見えてよいか。第二に、ネットワーク送信先を allowlist 化できるか。第三に、読み取り専用で足りる業務なのか、本番書き込みが必要なのか。第四に、プロジェクトを開く前の設定読込やローカルフックを信頼境界の外として扱えているか。第五に、承認UIの回数を減らす代わりに、どの絶対境界で止めるかを明文化できているかです。承認数を増やすより、秘密を置かない・届かせない・送らせないの3点を先に実装するほうが再現性があります。
FAQ
Q. 人間承認を残せば十分ですか。 A. 十分ではありません。Anthropicの実測では承認の約93%が通過しており、利用が増えるほど approval fatigue が起きます。承認は補助であり、秘密情報を見せない環境設計の代替にはなりません。
Q. dev container を使えば完全に安全ですか。 A. 完全ではありません。公式ドキュメントでも、trusted repositories でのみ使い、--dangerously-skip-permissions 利用時は host secrets をマウントしないよう警告しています。隔離の強さは、何を中へ持ち込むかで大きく変わります。
AIエージェントの安全運用ルールや sandbox 設計を社内標準に落とし込みたい場合は、 HelloCraftAIに相談する ことで、導入判断から権限制御、運用チェックリスト作成までまとめて整理できます。
