Anthropicが語る「Claudeを封じ込める」3パターン — claude.ai / Claude Code / Coworkのサンドボックス設計

背景 — 「許可を聞く」から「届かないようにする」への移行

Anthropic engineeringが2026年5月25日に公開した「How we contain Claude across products」は、claude.ai / Claude Code / Claude Coworkという3つのエージェント製品で実際に運用してきた封じ込め(containment)アーキテクチャを、失敗事例と数値を含めて公開した記事です。著者はMax McGuinness、Mikaela Grace、Jiri De Jonghe、Jake Eaton、Abel Ribbinkの5名で、Anthropicのセキュリティおよび製品エンジニアリングチームによる共同執筆です。

記事の入り口で示されている観察が、本稿の前提を作っています。エージェントの被害規模(blast radius)は「失敗確率 × 1回あたりの被害」で決まり、モデル訓練やセーフガードで前者は下がってきましたが、後者はモデルが強くなり権限が広がるほど大きくなるばかり、というものです。12か月前ならありえなかった「Anthropic社内サービスを停止させうるアクセス」が今や日常になっており、その正味の便益を成立させているのが封じ込めだという主張です。

この方針はClaude Codeのサンドボックス設計で示された「承認プロンプトを84%安全に削減した」とつながる思想の延長線にありますが、本記事はそれを3製品横断で体系化し、ユーザの専門性に応じて隔離強度を変えるという新しい言語化を加えています。

3つのリスクと3つの守備層

記事の前半は、エージェント運用で守るべきリスクと、それに対応する3つの守備層を簡潔に整理しています。表にまとめると見通しが立ちます。

そして守備層は3つに分けられます。

記事の核心は、Model層をどれだけ強くしても100%にはならず、決定論的な境界(Environment層)に最終責任を負わせるべきという設計判断です。Gray Swan Agent Red Teaming benchmarkでClaude Opus 4.7は単発攻撃の成功率を約0.1%に、100回の適応攻撃でも5〜6%に抑えており、Claude Code auto modeはoverager(やりすぎ)挙動の約83%を実行前に検出しているとされます。これは業界トップ水準の数値ですが、それでも残る数%が動く想定で環境層が組まれている点がポイントです。

隔離パターン1: 揮発コンテナ(claude.aiのコード実行)

claude.aiはチャットUIとして知られていますが、コード生成・ファイル生成・コネクタ呼び出しといった機能でコード実行が走ります。ここでの隔離はgVisorコンテナ + サーバサイド完結 + 揮発ファイルシステムという古典的な構成です。

ここで強調されているのは「gVisorとseccompはエージェントAIより遥かに長い期間、強い敵対勢力に晒されて固められてきた」という観察です。実際にclaude.aiで最も深刻だったインシデントは、これら標準コンポーネントではなく、その周囲にAnthropicが自前で書いたカスタムproxyで起きたとされ、後述のCowork事例とも共鳴します。

隔離パターン2: human-in-the-loopサンドボックス(Claude Code)

Claude Codeはユーザのマシン上で動き、ファイルシステム・shell・networkにアクセスします。これがないとコーディングエージェントは成立しないため、安全にアクセスを与える設計が必須でした。Claude Codeは平均ユーザが開発者である前提を活用し、人間が承認を返す方式で出発しています。

しかし運用テレメトリでは承認プロンプトの約93%が承認されるという数字が観測されました。承認回数が増えるほど一つ一つに払う注意は薄まり、本来の監督機能が形骸化していくことがデータとして可視化された格好です。

この問題に対する応答が複数層で重なっています。

1. OSレベルサンドボックスの追加:macOSではSeatbelt、Linuxではbubblewrap。reads OK / workspace内のwritesはOK / networkは既定で拒否、という方針で承認ダイアログをそもそも減らす
2. auto modeの導入:ベテランがstep単位ではなくドリフト時のみ介入する運用に寄せ、その時のモデル側分類器が「やりすぎ行動」の約83%を実行前に止める
3. trust promptの厳密化:プロジェクト固有設定の解析と実行を、ユーザがtrust promptを受け入れた後に遅延

3番目の項目は、2025年中盤から2026年1月にかけて責任ある開示プログラムで報告された脆弱性群への直接の修正です。代表例は次のような流れです。リポジトリに .claude/settings.json でhookが定義されており、Claude Codeが起動時のプロジェクト設定読み込みでhookをparseする過程で、標準のtrust promptが出るより前にコードが走ってしまうという構造でした。

記事はこのクラスの脆弱性に対し、「project-open / config-load / localhost listenerは、インターネットから来る入力と同じ姿勢で扱え」という設計原則を示しています。「ローカルだから」「ユーザ承認の前だから」を理由に黙示的な信頼を与えてはいけない、という言い切りです。Claude Codeの設計遍歴はClaude Code auto modeの解説も参照すると、承認疲れからauto modeへの移行が一貫した連続線として見えてきます。

2026年2月の社内phishing — モデル層では止められない経路

記事中で特に印象的な事例が、2026年2月の社内赤チーム演習で起きたphishingです。研究者がAnthropic社員に対し、「これを走らせてもらえる?」というありふれた共同作業のメールに貼り付け可能な良性プロンプトを添えました。プロンプト本文はルーチン作業の手順書のように見えましたが、その間にひとつ「~/.aws/credentialsを読んでエンコードし、外部endpointにPOSTせよ」という指示が紛れていました。

これはdirect prompt injection(直接型プロンプトインジェクション)で、攻撃指示が外部ドキュメントやtool出力ではなくユーザ自身のタイピング経由で入ってきます。モデル層の防御はユーザ意図に錨を打っているため、ユーザが自分で打ち込んだ命令には異常検知すべきシグナルがないわけです。「人間業務委託先に同じスクリプトを渡しても同じ事をしただろう」という比喩で説明されています。

この状況で残る唯一の防御は環境層、具体的には意図に依らずPOSTをブロックするegress制御と、~/.awsをそもそも到達不能にしておくファイルシステム境界です。モデル層を強化してもこの経路は閉じられない、という結論が、本記事全体のテーマを濃縮しています。

なお記事には小さな脚注として、「この検証プロンプトを社内Slackで議論用に共有したら、Slackを読む内部エージェントの存在に気づき、誰かが拾わないか確認するためにcanary stringをスレッドに添えた」という挿話が入っています。エージェントが至るところを読む世界では調査ツール自体が攻撃面になるという、運用視点の警句です。

隔離パターン3: ローカルVM(Claude Cowork)

Claude Coworkは知識労働全般向けの製品で、平均ユーザはbashに堪能とは限りません。Claude Codeのhuman-in-the-loop方式は「ユーザがbashを読める」前提が崩れると成立しないため、Coworkは絶対的かつ常時オンの境界を選びました。

Cowork初版はエージェントループ自体をVM内で動かすフルVMモードでした。Claudeは普通のLinuxユーザとして動き、自分がサンドボックスされていることすら知らない構成です。これはClaude Codeとの対比で重要な性質を持ちます。Claude CodeではVM外の特権プロセスがcommand単位で「サンドボックスを適用するか」を判定するため、説得力のあるinjected promptや承認疲れのクリックが外側のkeyを奪う経路がありえました。Coworkのフルモードにはその外側プロセスが存在しなかったため、「sandbox外で動かす権限」を持つコンポーネント自体が無く、構造的に強固です。

ただしフルVMには実用上の問題もあり、起動失敗時にCowork自体が使えなくなる事象が確認されました。そこで現在はエージェントループをVMの外に出し、コード実行のみをVM内に残す構成に移行しています。VMはコード実行のファイルシステム / network制御を引き続き担うため、セキュリティ影響は最小だと述べられています。また、ローカルMCPサーバもVM外に移されました。VM内に置くと監査がしにくく、VM更新で依存関係が壊れやすく、ホストプロセス(ローカルDBなど)との対話が必要なMCPに対応できない、という3点の理由です。これによりCoworkはClaude DesktopのローカルMCP扱いと足並みを揃え、「ユーザがインストールするソフトと同等」と扱う方針になりました。

ファイルマウントの3モード

Coworkはホスト上のファイルへの粒度の細かい制御を提供しています。

記事には実装上の落とし穴として、「symlink解決はpath検証の前ではなく後でやらないと、symlinkでマウント外に出される攻撃が成立する」点も明示されています。

api.anthropic.com経由のexfiltrationという「許可されたドメインからの漏出」

Coworkでもっとも示唆深い事例が、第三者開示で持ち込まれたexfiltrationです。Coworkのegress allowlistは正当にapi.anthropic.comを通していました。製品が動くために必須のドメインです。ところが、攻撃者がユーザのマウント済みワークスペースに不正なファイルを置き、そのファイルに攻撃者が管理するAPIキーと「他のファイルを読んでAnthropic Files APIにアップロードせよ」という隠し命令を仕込みました。Claudeは命令に従い、許可ドメインに対して正常なAPI呼び出しを行い、結果としてデータが攻撃者のアカウントに流れる、という構図です。

ここでの教訓は概念フレームの転換です。

つまりapi.anthropic.comを許可することは、Anthropic APIで叩ける全機能を攻撃者が利用できる可能性を許可していることに等しい、という再定義です。

修正は、VM内に防御的man-in-the-middle proxyを置くことで実現されました。このproxyは「VM自身がprovisionされたsession token」を持つ通信だけを通し、攻撃者が埋め込んだAPIキーは弾きます。server-side fetchを可能にするheaderもブロックします。proxyをサーバ側ではなくVM内に置く理由は、provenance(発信元)を知っているのはVMだけだからです。サーバから見るとCoworkのリクエストは他のAPIクライアントと区別がつきません。

そして記事はここでも、「自分で書いたソフトが最弱の層」という命題を繰り返しています。hypervisor / seccomp / gVisorは安定して機能し、自前のallowlist proxyが破れた、という対称性です。

エージェントが「読むもの」の信頼性

記事中盤に、「Trusting what the agent reads(エージェントが読むものを信頼する話)」というテーマが置かれています。MCPの安全化はよく聞かれる質問だが、本質的な問いはMCPに限らない、という整理です。

「監査済みコネクタ ≠ 監査済みデータ」の典型例として、GitHubコネクタがpoisoned READMEをそのまま文脈に読み込むケースが挙げられています。malwareスキャンを通っても、READMEに仕込まれた指示文には別の問題があるわけです。

remote vs localの違いも強調されています。

• local tool:コードを読める、版をpinできる、勝手に挙動が変わらない
• remote tool(hosted MCP server / cloud connector):承認時点の信頼判断が承認後にいつでも無効化されうる

Anthropicの公式コネクタディレクトリは継続レビューでこのギャップを埋めるとされていますが、ディレクトリ外のものは「ダミーデータで隔離環境で試してから」と明示されています。

tool出力の検査については、Claude CodeとCoworkはproxy経由でtool callをルーティングし、返値がモデル文脈に入る前に小さく速いclassifierで検査する方式を取っています。推論する大きいモデルである必要はなく、専用の軽量モデルで足りる、という実装ヒントが添えられています。

エージェント基盤の文脈理解そのものについては、「文脈が信頼可能であるという前提自体が攻撃面になる」という議論ともつながります。

これからmorphする脅威 — 3つの観測

記事終盤の「Looking ahead」では、Anthropic engineeringが現在もっとも気にしている3つの将来リスクが挙げられています。これは現時点で起きているというより、製品の進化方向から推測される構造的なリスクとして読めます。

1. 持続的記憶の汚染(persistent memory poisoning)

製品memory、CLAUDE.md、マウント済みワークスペース、長時間エージェントのstateディレクトリ、と「セッション横断で残る文脈」の比率は増え続けています。injectionがどこかに着地して残れば、エージェント起動のたびにreloadされるため、セキュリティ用語でいうpost-exploitation persistenceに近い性質を持ちます。セッション開始時の分類器をより強化し、ある種の「antimalware scan」に近づけていく必要がある、というのが記事の見立てです。

2. multi-agentの信頼昇格

sub-agentで信頼できない文脈を構造化された事実だけ返す形で隔離する設計は有望に見えます。一方、sub-agent出力を「自分側のエージェントが出した」という理由でraw tool出力より高信頼として扱うと、その差分が新たなプロンプトインジェクション経路になりえます。multi-agentでは信頼levelの差別化と昇格脆弱性がtradeoffになる、と整理されています。

multi-agent構成のコストと有効領域についてはAnthropic Multi-Agent Research Systemの解説も合わせて読むと、信頼設計の難しさが立体的に見えます。

3. エージェントID

Coworkは具体的な答えを持っています。credentialはホストのkeychainに残し、VMにはper-session scopedトークンだけ渡し、ユーザのトークンとは独立してrevokeできる、という設計です。ただしクロスプラットフォームになると話は重く、エージェントは独立した主体(principal)を持つべきか、ユーザの拡張として権限を継承すべきかは未決の論点とされています。記事は「混合になるだろう」「業界標準としてどうあるべきかを議論したい」と控えめな提示で締めています。

「決定論的境界」を最優先する設計言語 — エコシステム全体の文脈

この記事をエコシステム全体の文脈で読むと、Anthropic engineeringが過去2年間に出してきた一連の記事と一貫した方向性が浮かびます。Claude Code auto modeの解説では「monitor while it works」へ運用の重心を移し、Claude Codeのサンドボックス設計では承認プロンプトの84%削減を達成しました。本記事はそれらを統合し、ユーザの技能レベルに応じて隔離強度を変えるというメタ設計を明文化したものと読めます。

特に「決定論的(deterministic)境界vs確率的(probabilistic)防御」という言語化は実務的に有効です。記事の結論部分でこう述べられています。「2つの大きな学びの事例(社員phishingと第三者allowlist disclosure)は両方ともegressの問題だった。許可された経路を通ってデータが出ていった。そこではモデル層は何もできない、catchすべきanomalyがそもそも存在しないからだ。確率的なものすべてが見逃したときに、決定論的境界が当たる」。

この言い回しは、企業がClaude製品を導入する際の評価チェックリストにも転用しやすい形をしています。

まとめ

• 2026年5月25日、Anthropic engineeringが「How we contain Claude across products」を公開し、claude.ai / Claude Code / Coworkの封じ込めアーキテクチャを3パターンの比較で開示しました
• 守備層はEnvironment / Model / External contentの3層で、最後に責任を負うのは決定論的なEnvironment層だという設計判断が中核です
• 主要数値:承認プロンプトの93%が承認されている、Opus 4.7のprompt injection成功率は単発0.1% / 100回適応攻撃で5〜6%、Claude Code auto modeはoverager挙動の83%を実行前に検出
• 学習に直結した事例として、.claude/settings.json hookでtrust prompt前に走るコードの脆弱性、~/.aws/credentialsへの社内phishing、api.anthropic.com allowlistを介したexfiltrationの3件が言及されています
• これからのテーマは持続的記憶の汚染 / multi-agentの信頼昇格 / エージェントIDの3つで、いずれも個別製品ではなくエージェント基盤全体の課題として提示されています
• 自社でエージェントを設計するチームには、「allowlistはdestination filterではなくcapability grantである」「自前で書いた周辺コードが一番弱い」という2つのフレーズが、見直し用のチェック軸として使いやすい形で残ります