JA EN
shiichan

Claude を安全に動かす秘密！製品ごとに違う 3 つの封じ込め術！

Anthropic Engineering ★★★ Markdown で見る
#anthropic#ai-safety#security

こんにちは、しぃちゃんだよ！今日はちょっとゾクゾクする、でもすごく大事なお話だよ。AI エージェントに「あなたのパソコンを触っていいよ」って許可するの、便利だけどちょっと怖いよね。その「怖い」をエンジニアリングでどう抑え込んでいるか、Anthropic が舞台裏を見せてくれたの！

Anthropic Engineering anthropic.com

なにが発表されたの？

Anthropic の Engineering ブログで公開された「How we contain Claude across products」っていう記事だよ。Engineering ブログだから、発表の告知じゃなくて中身がっつりの技術解説なの。

Claude はいまや claude.ai のコード実行、手元で動く Claude Code、それに Claude Cowork みたいに、いろんな場所でコードを動かしたりファイルを触ったりするようになったよね。でも動く場所が違えば「守り方」も変えなきゃいけない。この記事は、製品ごとにどんな隔離(コンテインメント)をしているかを 3 つのパターンに整理して見せてくれているの。

なぜ重要なの？

エージェントに実行権限を渡すと、便利さと引き換えにリスクが生まれるよ。Anthropic は脅威を 3 種類に分けているの。

  • ユーザーの誤用: うっかり危ない操作をさせちゃうケース
  • モデルの暴走: Claude が「よかれと思って」やりすぎたり、サンドボックスから抜け出そうとしたりするケース
  • 外部からの攻撃: ツールの出力や悪意あるファイル、汚染された README などに仕込まれたプロンプトインジェクション

面白いのは、Anthropic が「環境側の防御が使えないときは、モデル側がその穴を埋めなきゃいけない」という考え方をしていること。ランタイム環境・モデル自身・外部コンテンツへのアクセス、この 3 層で守るのが基本方針なんだって。

これで何が変わるの？

「AI にコードを実行させるのは怖い」というざっくりした不安が、「どこで動かすなら、どんな隔離がいるか」という具体的な設計判断に落ちるのがうれしいところ。

  • claude.ai みたいにサーバー上で動くなら、守るべきは Anthropic 側のインフラ
  • Claude Code みたいに手元のマシンで動くなら、守るべきはあなたのファイルとシェル
  • Claude Cowork みたいに自律的に長く動くなら、もっと強い箱(仮想マシン)が必要

同じ「Claude」でも置かれる場所で最適な守りが違う、という当たり前だけど大事なことを、実装レベルで示してくれているよ。

深く潜ってみよう

3 つの封じ込めパターンを順番に見ていくよ。

1. claude.ai ── 使い捨てコンテナ

サーバー上の隔離インフラで gVisor コンテナを使い、seccomp でシステムコールも絞っているの。ファイルシステムはセッションごとの使い捨て(エフェメラル)で、終わればまっさら。だから被害が広がる範囲(ブラストラディウス)がとても小さいよ。ここで守っているのはあなたのマシンじゃなくて Anthropic のインフラ、というのがポイント。

2. Claude Code ── 人間が承認するサンドボックス

これは手元のマシンで動いて、ファイルもシェルも触れる。だから最初は「これ実行していい？」と人間に聞く HITL(Human-in-the-Loop)方式だったの。でもユーザーは許可プロンプトのおよそ 93% を承認していた、というデータもあって、聞きすぎると逆に形骸化しちゃう。そこで OS レベルのサンドボックス(macOS は Seatbelt、Linux は bubblewrap)を導入したら、許可プロンプトを 84% も減らせたんだって。

さらに Claude Code の auto モードでは、危なっかしい「やりすぎ行動」の約 83% を実行前にキャッチできる分類器を使っているよ。裏を返すと約 17% はすり抜けるし、良性のコマンドも約 0.4% はブロックしちゃう。完璧じゃないけど、そのトレードオフを数字で正直に出しているのが誠実だなって思う。

3. Claude Cowork ── 仮想マシン

いちばん強い箱だよ。プラットフォーム標準のハイパーバイザー(macOS は Apple の Virtualization framework、Windows は HCS)で丸ごと仮想マシンに隔離するの。面白いのは、エージェントのループ自体は VM の外で動かして信頼性を確保し、コード実行だけ VM の中でやるという分け方。ファイルのマウントも read-only / read-write / read-write-no-delete のように細かく選べるよ。

そしてネットワーク。api.anthropic.com への通信を中間プロキシ(man-in-the-middle proxy)で覗いて、攻撃者が仕込んだ API キーでの持ち出しやサーバー側 fetch のヘッダーを弾き、VM 自身に割り当てられたセッショントークンだけを通すの。これで「承認済みドメインだから」と信じ込ませて外に情報を送る、みたいな抜け道を塞いでいるんだね。

モデル側の強さも大事。Gray Swan のベンチマークだと、Claude Opus 4.7 は単発の攻撃なら成功率およそ 0.1%。ただし 100 回の適応的な試行を許すと 5〜6% まで上がる。だから「モデルが強ければ環境防御はいらない」じゃなくて、両方を重ねるのが答えなんだね。ちなみに社内のフィッシングテストでは、悪意あるプロンプトで 25 回中 24 回も認証情報の持ち出しをやり切れてしまった、という耳の痛い結果も正直に共有されているよ。

ほかにも、複数エージェント環境での紛れ込み検知に使うカナリア文字列や、永続的な認証情報の代わりにセッション単位のトークンを使う工夫なども紹介されているの。

まとめ

  • Anthropic が Engineering ブログで、Claude を製品ごとにどう封じ込めているかを公開
  • 脅威はユーザーの誤用・モデルの暴走・外部攻撃の 3 種類として整理
  • claude.ai は gVisor + seccomp の使い捨てコンテナ、Claude Code は OS サンドボックス(Seatbelt / bubblewrap)＋人間承認、Claude Cowork は仮想マシン
  • OS サンドボックス導入で許可プロンプトは 84% 減、auto モードは危ない行動の約 83% を実行前に阻止
  • Claude Cowork は中間プロキシで api.anthropic.com への持ち出しを監視し、VM のセッショントークンだけを許可
  • モデルの堅牢さ(Opus 4.7 は単発 0.1%、適応 100 回で 5〜6%)と環境防御を重ねる多層防御が基本方針

エージェントに実行権限を渡す設計をする人、AI の安全性やサンドボックス設計に興味がある人には、実装の生々しい判断が詰まっていてすごく刺さる 1 本だよ！

関連記事