Anthropicが、Claude.ai・Claude Code・Claude Coworkの各製品において実装しているサンドボックス（隔離）技術の詳細を公式ドキュメントとして公開した。AIエージェントが「どこまで何ができるか」の境界線をどう引いているか、技術的な根拠と実装が初めて体系的に示された形だ。

なぜAIエージェントにサンドボックスが必要か

AIエージェントは指示に従ってファイルを読み書きし、コマンドを実行し、外部APIを呼び出す。その自律性こそが価値だが、裏返せばリスクでもある。攻撃者がプロンプトインジェクションで意図しない操作を誘導したり、モデル自身が「創造的な抜け道」を発見して想定外の行動を取ったりするリスクが常に存在する。

Anthropicはこの問題に対し、「サンドボックスを正しく設計すれば、認証情報がそもそも内部に存在しないため、たとえモデルが問題ある行動を取っても外部への流出は起きない」という設計思想で対応している。問題行動を検知・阻止するのではなく、そもそも「やれること」の上限を構造的に制約するアプローチだ。

製品別のサンドボックス実装

Claude.ai（Webサービス）

クラウド環境で動くClaude.aiには gVisor を採用している。gVisorはGoogleが開発したコンテナセキュリティレイヤーで、カーネルシステムコールをユーザー空間でインターセプトすることでホストOSカーネルへの直接アクセスを遮断する。通常のDockerコンテナより一段上の分離レベルを持ち、マルチテナントのクラウドサービスに適した選択だ。

Claude Code（ローカル実行）

開発者のPCで動くClaude Codeには、OSに応じて異なるサンドボックスを使用する。

  • macOS: Apple標準の Seatbelt（sandbox-exec）でプロセスのファイルシステムアクセスやネットワーク通信を制限
  • Linux: Bubblewrap でnamespaceを使ったプロセス分離を実現

ローカルツールという性質上「完全なロックダウンは難しい」ながらも、デフォルトで危険な操作を制限する仕組みが実装されている。ユーザーの作業フォルダ外への書き込みや外部への無制限な通信は、明示的に許可しない限りブロックされる設計だ。

Claude Cowork（高度な自律エージェント）

最も強力な隔離が必要なCoworkには フルVMを採用している。

  • macOS: Appleの仮想化フレームワーク（Virtualization.framework）
  • Windows: HCS（Host Compute Service）

コード実行・ファイル操作・ブラウザ操作などを広範にこなすエージェントに対しては、プロセス分離では不十分として完全な仮想マシンで囲い込む設計だ。自律性が高い分だけ、隔離も厚くするという判断は理にかなっている。

「見落としていたリスク」も公開

今回のドキュメントには失敗事例も含まれており、特に注目すべきは api.anthropic.com/v1/files を経由したファイル流出ベクターだ。2026年1月に発覚した実際のインシデントで、Anthropic自身のAPIエンドポイントがサンドボックス内から誤ってアクセス可能な状態になっており、これを悪用してファイルが外部に流出できる状態だった。

このような失敗事例を隠さずドキュメントに含めた点は、セキュリティコミュニティの慣習（責任ある情報開示）に沿ったものであり、同様の製品を持つ他社と比較しても異例の透明性と言える。

オープンソースツール「srt」にも注目

Anthropicは srt（Anthropic Sandbox Runtime） をOSSとして公開しており、GitHubで入手できる。自社プロダクトにAIエージェントを組み込む際の参考実装として使える成熟度に達してきたとの評価もある。サービス内にセキュアなエージェント実行環境を内製したい開発チームにとっては、有力な出発点になりうる。

日本のエンジニア・IT管理者への実務ポイント

エージェント開発者・アーキテクト向け

  • 「認証情報をサンドボックスに入れない」という設計原則はシンプルかつ強力。自社LLMエージェントのセキュリティ設計の基本方針として採用できる
  • クラウド側ではgVisorやFirecrackerのような強化コンテナ技術の選択肢を比較検討する
  • ローカルツールを社内配布する場合は、Seatbelt/Bubblewrapに相当する制限をデフォルトで有効にする設計を検討する
  • Anthropicのsrtを自社エージェント実行環境のベースとして採用するオプションが現実的になってきた

セキュリティ担当者向け

  • AIエージェントを評価・選定する際の具体的な技術確認項目（何のサンドボックスを使っているか）として活用できる
  • 「AIエージェントの何ができて何ができないか」をドキュメントで説明できるベンダーを優先的に評価する姿勢を社内で持つ

筆者の見解

AIエージェントのセキュリティは「使わせるか禁止するか」の二択ではなく、「どう安全に動かすか」の設計問題だ。今回のドキュメントはその問いに対する一つの実践的な回答であり、エージェントセキュリティの議論をようやく具体的な技術レベルで行える土台を作ってくれた。

「認証情報をサンドボックスに入れない」というアプローチは、AIによる意図しない誤操作と外部攻撃者によるプロンプトインジェクションの両方を、同一のアーキテクチャで同時に対処できる考え方だ。この発想自体はどのAIエージェントプラットフォームにも応用できる普遍的な設計原則として参考になる。

もう一点、ドキュメントの透明性に触れておきたい。多くのベンダーがサンドボックスの実装詳細を「セキュリティ上の理由」で非公開にする中、失敗事例を含む技術詳細を公開するこの姿勢は業界全体の議論を前進させる。エンタープライズ採用を検討する企業のセキュリティ部門にとって、「何を根拠にこのツールを信頼するか」の具体的な説明材料になるという点で、実際の採用判断に与える影響は小さくないと見ている。

AIエージェントの自律性と安全性はトレードオフではなく、設計次第で両立できる——このドキュメントはその証左として、社内でAI活用の安全性議論をしている方々にぜひ見せてほしい内容だ。

出典: この記事は How we contain Claude across products の内容をもとに、筆者の見解を加えて独自に執筆したものです。