はじめに
2026年に入り、AIエージェントが「考えるだけ」から「実際に手を動かす」存在へと変わりつつあります。ファイルを編集し、コマンドを実行し、外部ツールと連携する ― そんなエージェントにとって、実行環境のセキュリティ設計は避けて通れないテーマです。
Anthropicは現在、エージェント型の製品を2つ提供しています。
- Claude Code: ターミナルベースの開発者向けコーディングエージェント
- Cowork: デスクトップアプリ上で動くナレッジワーカー向けタスク自動化ツール
裏側どうなっているんだろう？を調べていたのですが、両者には明確な違いがあり、その背景には設計思想の違いがありました。
本記事では、この設計思想の違いを「なぜそうなったのか」という観点から掘り下げます。エージェント製品のセキュリティ設計を考えるうえでの参考になれば幸いです。
本記事の情報は2026年3月時点のものです。Coworkはリサーチプレビュー段階であり、仕様は今後変更される可能性があります。
Claude Codeのセキュリティモデル
パーミッションベースモデル（デフォルト）
Claude Codeはターミナル上で直接動作するツールです。デフォルトでは読み取り専用であり、ファイルの変更やコマンドの実行には都度ユーザーの承認が必要です。echoやcatのような安全なコマンドは自動許可されますが、それ以外は明示的な「approve」を求められます。
つまり、ホストマシン上で直接動作し、コンテナやVMによる分離はデフォルトでは行われません。
OSレベルサンドボックス（オプション）
Anthropicは2025年後半にClaude Code向けのサンドボックス機能をリリースしました。これはDockerコンテナではなく、OSレベルのプリミティブを使ったアプローチです。
| OS | 使用技術 |
|---|---|
| macOS | Seatbelt（sandbox-exec） |
| Linux / WSL2 | bubblewrap |
サンドボックスは以下の2つの境界を提供します。
- ファイルシステム分離: カレントディレクトリとそのサブディレクトリへの読み書きに限定し、それ以外のファイル変更をブロック
- ネットワーク分離: Unixドメインソケット経由のプロキシサーバーを通じて、許可されたドメインのみにアクセスを限定
Anthropicの内部テストでは、サンドボックスの導入によって承認プロンプトが84%削減されたと報告されています。
# Claude Code でサンドボックスを有効化
/sandbox
なお、このサンドボックスランタイムはオープンソース（Apache 2.0）として公開されており、他のエージェントプロジェクトでも利用可能です。
コミュニティによるDocker化
公式サンドボックスとは別に、コミュニティからはDockerコンテナ内でClaude Codeを実行するソリューションが多数登場しています。
- Docker Sandboxes: Docker社がmicroVMベースの分離環境を提供
- DevContainer: VS Code / Cursorと組み合わせたコンテナ開発環境
- claude-code-sandbox: サードパーティ製のDockerラッパー
これらは特に--dangerously-skip-permissionsフラグを使ってClaude Codeを自律実行させたい場合に利用されています。公式のOSレベルサンドボックスでは対応しきれない、Docker-in-Dockerワークフローなどのユースケースに応えるものです。
Coworkのセキュリティモデル
VM分離（デフォルト）
Coworkのセキュリティモデルで最も重要なポイントは、タスクがホストマシン上で直接実行されないことです。
macOSでは、AppleのVirtualization Framework（VZVirtualMachine）を使ってカスタムLinuxルートファイルシステムを持つVMを起動します。Dockerコンテナでもプロセスサンドボックスでもなく、フルVMです。Simon Willisonによる独立したリバースエンジニアリングでもこの点が確認されています。
この設計により、仮にエージェントが破壊的なコマンドを実行しても、最悪のケースは「VM環境が壊れる」であって、「ホストシステムが消える」ことにはなりません。これを「爆発半径（Blast Radius）の封じ込め」と呼びます。
多層防御（Defense-in-Depth）
CoworkのセキュリティはVM分離だけで完結しません。VM内部にさらに追加の防御層が設けられています。
Human-in-the-Loop（HITL）
Coworkでは、すべてのアクションに承認を求めるのではなく、破壊的な操作（ファイルの永久削除など）のみユーザー確認をゲートしています。それ以外はVM内で自律的に動作します。
この設計は「すべてを聞く」のでも「すべてを許す」のでもなく、境界を事前に定義し、その中では自由に動かすというアプローチです。
なぜ設計が分かれたのか ― 3つの理由
ここからが本記事の核心です。同じAnthropicの2製品が、なぜ異なるセキュリティアーキテクチャを選んだのか。その背景には3つの明確な理由があります。
理由1: ターゲットユーザーの違い
これが最も根本的な要因です。
Claude Codeは開発者がリスクを理解し、自分でセキュリティ境界を設定できる前提で設計されています。ターミナル操作に慣れ、パーミッションの意味を理解し、問題が起きれば自分でリカバリできるユーザー層です。
一方、Coworkは非開発者が安全に放置できる前提で設計されています。Anthropic自身がその経緯を語っており、社内のマーケティングやデータチームがClaude Codeをコーディング以外の作業（資料整理、スライド作成、メール整理など）に使い始めたことがCowork誕生のきっかけでした。
Claude Code was originally developer-facing, but users quickly applied it to tons of non-coding work.
「マーケティングマネージャーが『この議事録とPDFからスライドを作って』と言ってそのまま離席できる」ことを目指すなら、「このbashコマンドを許可しますか？」と繰り返し聞くモデルでは成り立ちません。
Coworkは約1.5週間でClaude Code自身を使って開発されたと報告されています。ユーザー行動から生まれた製品であることが、アーキテクチャの方向性にも反映されています。
理由2: 「承認疲れ」問題への解法の違い
両製品とも「承認疲れ（Approval Fatigue）」を課題として認識しています。しかし、解決のアプローチが異なります。
| 観点 | Claude Code | Cowork |
|---|---|---|
| デフォルトの安全策 | 都度パーミッション承認 | VM境界 + フォルダスコープ |
| 承認疲れへの対策 | OSサンドボックス（オプション） | 境界の事前定義（デフォルト） |
| ユーザーの判断ポイント | 各コマンドの安全性 | どのフォルダを許可するか |
| 自律性の範囲 | サンドボックス内のコマンド | VM内のすべての操作（破壊的操作を除く） |
Claude Codeは粒度の細かいパーミッション制御を提供し、開発者が必要に応じてサンドボックスをオプトインします。Coworkは境界を先に決めて中は自由に動かすという設計で、ユーザーは「何を許可するか」だけ考えればよい構造です。
理由3: 爆発半径（Blast Radius）の許容度
3つ目の理由は、「もし何かが壊れたとき、どこまで許容できるか」の違いです。
開発者（Claude Code） の場合、ワーキングディレクトリの変更はgitで元に戻せます。仮にサンドボックスの外に影響が出ても、ターミナルの操作ログから原因を特定し、リカバリできるスキルを持っています。したがって、OSレベルのサンドボックスで「ある程度の」分離を提供すれば十分です。
ナレッジワーカー（Cowork） の場合、「大事な書類が消えた」「フォルダ構成が壊れた」といった事態は、自力でのリカバリが困難です。だからこそ、ホストOSとの完全分離というハードな境界が必要になります。
エージェント製品の設計パターンとしての示唆
Claude CodeとCoworkの比較から、エージェント製品のセキュリティ設計における一般的なパターンが見えてきます。
「構造で解決する」vs「指示で解決する」
Coworkのアーキテクチャに関する分析記事で、興味深い指摘がなされています。CoworkはVM分離、フォルダスコープのパーミッション、並列サブエージェントの進捗可視化、ファイルベースのプラグインによる監査可能性、MCPアプリによるサンドボックス化されたUI拡張性という5つの設計思想を持ち、それぞれがエージェントの能力とユーザーの安全性の間の緊張関係に対する具体的な立場を示しています。そしてその緊張関係を、ソフトなガイドラインではなくハードな境界で解決しています。
これはセキュリティ設計全般に通じる教訓です。
| アプローチ | 例 | 適する場面 |
|---|---|---|
| 指示で解決 | パーミッションプロンプト、ドキュメントによる注意喚起 | ユーザーが判断できる場合 |
| 構造で解決 | VM分離、ネットワークホワイトリスト、フォルダスコープ | ユーザーが判断を期待されない場合 |
多層防御のテンプレート
Coworkのセキュリティアーキテクチャは、エージェント製品を構築する際の再利用可能なテンプレートとして参考になります。
- ハード境界: VM / コンテナ / 分離実行環境で爆発半径を封じ込める
- ソフト境界: プロセスサンドボックス + syscallフィルタリングで権限昇格を防ぐ
- 最小権限 + デフォルト拒否: ファイル / ネットワーク / コネクタをホワイトリスト方式で管理
- HITL（Human-in-the-Loop）: 確認ポイントをプロセスノードとして設計する（UXの飾りではなく）
- 可視性と監査可能性: 「何をしようとしているか、何をしたか」をユーザーに伝える
まとめ
本記事では、Claude CodeとCoworkのセキュリティアーキテクチャの違いを、その設計意図から比較しました。
| 観点 | Claude Code | Cowork |
|---|---|---|
| ターゲット | 開発者 | ナレッジワーカー |
| デフォルトの分離 | なし（ホスト直接実行） | VM分離 |
| サンドボックス | OSレベル（オプション） | VM + bubblewrap + seccomp |
| 承認モデル | コマンド単位 | フォルダスコープ + 破壊的操作のみゲート |
| リカバリ前提 | ユーザーが自力で可能 | ユーザーには困難 |
| 設計思想 | 柔軟性と制御の提供 | 構造による安全性の保証 |
ポイントは、どちらが「正しい」かではなく、ユーザー層の違いがアーキテクチャの違いに直結しているということです。
- 開発者が自分でリスク管理できるなら → パーミッションモデル + オプショナルなサンドボックス
- 一般ユーザーが安全に放置できる必要があるなら → VM分離をデフォルトに
AIエージェントが「手を動かす」時代において、「誰のためのツールか」を起点にセキュリティアーキテクチャを設計する ― Claude CodeとCoworkの比較は、その重要性を教えてくれます。
参考リンク
- Anthropic Engineering Blog - Beyond permission prompts: making Claude Code more secure and autonomous
- Claude Code Docs - Sandboxing
- Cowork Product Page
- Anthropic Product Page - Claude Cowork
- Claude Help Center - Get started with Cowork
- Cowork Security Architecture Deep Dive（中文Claude技術コミュニティ）
- Claude Cowork Architecture: How Anthropic Built a Desktop Agent That Actually Respects Your Files
- Claude Cowork Architecture: Synthesis of Anthropic's Desktop Agent Framework
- Docker Blog - Docker Sandboxes: Run Claude Code and More Safely
- Sandboxing Claude Code on macOS（Infralovers）