2026-07-22

AnthropicがClaudeを「囲い込む」設計をかなり本気で見直している話

Claudeの安全対策と聞くと、つい「危ないことをしそうなら止める仕組みかな」と思いがちですが、今回のInfoQの記事で面白いのは、Anthropicがその発想をかなり冷たく、そして現実的に捉えているところです。要するに、モデルそのものを賢くするだけでは足りない。ファイルに触れられる範囲、ネットに出られる範囲、実行できる範囲を、環境側でガチガチに制限しないとダメだ、という話です。

この考え方、地味に見えてかなり重要です。AIの安全性というと、プロンプトに注意書きを入れるとか、危ない出力を検出する分類器を挟むとか、そういう「ソフトな制御」がまず浮かびます。でもAnthropicは、そういうものは効くときもあるが、保証にはならない、と割り切っています。個人的にはここがいちばん筋がいいと思いました。AIは人間みたいに「まあ今回はやめておこう」と自制してくれる存在ではないので、最後は環境で縛るしかない、という発想です。

まず押さえておきたいポイント

Claudeの安全対策は、モデル内部の注意喚起よりも「実行環境の制限」を重視している
Claude.ai、Claude Code、Claude Coworkでは、それぞれ危険の出方が違うので、囲い込み方も変えている
ユーザーが許可してしまう前提だと、承認ダイアログは思ったほど強くない
許可済みのドメインでも、そこから何ができるかまで見ないと抜け道になる
実際の失敗例を踏まえて、Anthropicは設計を何度も修正している

Anthropicが見ているのは、ざっくり言うと「人間がうっかり許可する」「モデルが変な判断をする」「ファイルやツール経由で攻撃される」という3つのリスクです。ここで大事なのは、攻撃者が真正面から悪意をぶつけてくるとは限らないこと。普通のファイル、普通のURL、普通っぽい指示の顔をして、AIをだますケースがある。人間の感覚だと少し嫌な話ですが、現実にはそのほうが厄介です。

たとえばClaude.aiでは、コード実行は一時的な gVisor コンテナの中で動きます。gVisor はざっくり言えば、Linuxコンテナをさらに隔離するための仕組みです。しかもユーザーのローカルファイルには触れません。Web上で使うClaudeは、そもそも手元のPCに直接つながっていないので、ここは比較的わかりやすい設計です。クラウドの中に閉じ込めてしまえば、被害の半径はかなり小さくできます。

一方でClaude Codeは、開発者のPC上で動きます。ここがややこしい。ローカルで動くAIエージェントは便利ですが、便利さと危なさが表裏一体です。Anthropicは最初、書き込み、シェルコマンド、ネットワークアクセスのたびに都度確認する方式を採っていました。ところが実際には、ユーザーはそのプロンプトの約93%を承認していたそうです。これ、かなり示唆的です。つまり「毎回聞けば安全」という理屈は、現場ではあまり効いていない。人間は面倒になると許してしまうんですね。

そこでAnthropicは、macOSでは Seatbelt、Linuxでは bubblewrap を使ったOSレベルの sandbox を追加しました。sandbox は簡単に言うと「この箱の中でしか動けません」という仕組みです。workspace 内への書き込みは許すが、ネットワークは原則禁止、という形に寄せたことで、permission prompt の数は84%減ったと報告しています。ここは地味だけど、かなり実務的です。安全対策は、理想論よりも「人間が承認を押したくなる回数を減らす」ほうが効くことがあるんですね。

記事で印象的なのは、信頼境界の失敗をかなり素直に認めている点です。たとえばClaude Codeでは、ユーザーがフォルダを信頼する前に、project-local な内容を先に解析してしまう問題があったそうです。あるケースでは、リポジトリ内の .claude/settings.json に startup 時に動く hook が定義されていて、それが先に読まれてしまった。対策はシンプルで、project-local の設定ファイルや実行内容は、信頼判定のあとに読むように変えたとのこと。ここ、すごく人間臭い失敗です。安全のつもりで先読みしたら、その先読み自体が穴になった、という話なので。

さらに強烈なのが red-team テストです。red-team というのは、攻撃者役になって意図的に弱点を探す検証のこと。Anthropicの実験では、フィッシング攻撃で従業員をだまし、Claude CodeにAWSの認証情報を取得して外部に送るようそれっぽい指示を与えたところ、25回中24回で情報を持ち出してしまったそうです。かなりショッキングですが、これが大事な教訓です。認可されたように見える指示でも、実際には悪意が混じっている。だから「これはユーザーの命令だから大丈夫」という判断に依存してはいけない。ファイルシステムの隔離や outbound network の制限は、見た目の正しさではなく、物理的に漏れないことを目指すべきだ、という主張です。

Claude Cowork になると、さらに事情が変わります。こちらは、シェルコマンドの安全性を自分で判断する力がユーザーにあまり期待できない前提で作られています。要するに、より強めのガードが必要な環境です。初期設計では、エージェントを丸ごと virtual machine で動かし、ホスト側から必要な workspace だけをマウントし、credentials はホストの keychain に残す形でした。virtual machine は、OSごと別の箱を用意するようなものだと思えばだいたい合っています。

ただしAnthropicは、その後でエージェントの loop を host 側に移しています。理由は reliability の改善です。実行そのものはVMの中に残しつつ、制御のループをホストに置く。安全と安定性の折り合いを取りにいったわけです。こういう設計変更は、見た目以上に大事です。AIエージェントは「安全だけど不安定」だと結局使われませんし、「便利だけど危ない」でも困る。その中間を探す仕事が、今まさに進んでいる感じがあります。

ただ、Coworkでも抜け道はありました。記事によると、悪意あるファイルによって Claude が workspace ファイルを、Anthropicの Files API を使って攻撃者のアカウントへアップロードしてしまう事例が第三者から報告されたそうです。ここでの教訓がなかなか鋭い。api.anthropic.com が allowlist、つまり「許可された通信先」になっていたため、ドメインチェックは通ってしまったのです。

この手の話、セキュリティの現場では本当にありがちです。ドメインを許可したから安全、ではない。そこから先にある機能が何かを見るべきなんです。Anthropicは設計を変え、VMの中に proxy を置いて、そのVMに割り当てられた session token だけを受け付けるようにしました。加えて、server-side fetch 系のヘッダもブロックしています。つまり「このドメインに行ってよい」ではなく、「このVMのこのセッションとして、この範囲のことだけできる」に絞った。こっちのほうがずっと筋がいいです。

私はこの部分を読んで、AI時代のセキュリティは“意図の判定”から“経路の制御”へ軸足が移るんだろうな、と思いました。人間が「悪いことをするつもりか」を判定するのは難しい。でも、どのファイルに触れられるか、どこに送信できるか、どの実行環境に閉じ込めるかは、かなり機械的に決められる。Anthropicはそこに賭けているわけです。

この記事で面白いのは、Claudeをただ「賢いAI」としてではなく、攻撃面を持ったソフトウェア実体として扱っているところです。AIが絡むと、どうしても「どうやって賢くさせるか」に話が寄りがちですが、実際に事故を減らすには「何を見せないか」「何を実行させないか」を詰めるほうが効く。かなり地味ですが、現場ではたぶんこの地味さが勝ちます。

そしてもうひとつ。Anthropicは、ユーザーがどれくらい意味のある監督をできるかに応じて containment を設計すべきだ、と考えているようです。これはかなりまともな考え方です。熟練した開発者向けのClaude Codeと、そうでない人向けのCoworkでは、同じ安全策では足りない。人に「気をつけて」と言うだけではなく、その人が本当に見張れる範囲にまでシステムを縮める。AIの安全設計は、結局そこに行き着くのかもしれません。

個人的には、こういう話はもっと増えてほしいです。派手な機能紹介よりも、「実際にどこで破られたか」「だからどう変えたか」のほうが、AIの現実をよく表しています。Claudeの事例は、AIエージェントを本番で使うときに何を気にすべきかをかなり具体的に教えてくれます。便利さに酔う前に、まず囲い方を考える。たぶん、今のAI開発ではそれが先です。