Claude Code サンドボックス完全解説 — chroot ではない、カーネルレベル隔離の仕組みと実践設定

「Claude Code のサンドボックスって、要するに chroot でしょ？」という誤解をよく耳にします。答えは明確にノーです。Claude Code のサンドボックスは chroot とは次元の異なるカーネルレベルの隔離機構で、ファイルシステムとネットワークの2層を OS プリミティブで強制します。

Anthropic のエンジニアリングブログによると、サンドボックスにより承認プロンプトが84%削減されました。セキュリティと生産性を両立する仕組みの全貌を、技術的な背景から実践設定まで解説します。

chroot との決定的な違い

まず「chroot で十分か」という疑問に答えます。結論から言えば、chroot はセキュリティ対策として設計されていません。

隔離技術の比較

Practical CTF の解説を基に、主要な隔離技術を比較します。

chroot の脱出方法

chroot がセキュリティ対策に不十分な理由を具体的に示します。

1. カレントディレクトリ攻撃: chroot 実行時にカレントディレクトリが jail 外にあれば、相対パスで脱出可能
2. 二重 chroot: 別の chroot を実行して前の制限を上書き
3. ファイルディスクリプタ: jail 外で開かれた fd を経由してアクセス
4. openat syscall: ディレクトリ fd を使って jail 外のファイルを操作

つまり chroot は「ルートディレクトリの表示を変えるだけ」であり、ネットワーク制限もシステムコール制限もありません。AI エージェントのサンドボックスとしては全く不十分です。

Claude Code サンドボックスのアーキテクチャ

Claude Code のサンドボックスはファイルシステム隔離 + ネットワーク隔離の2層構造です。公式ドキュメントは、この2層が両方とも必須である理由を明確に述べています。

ファイルシステム隔離なしでは、侵害されたエージェントがシステムリソースにバックドアを仕掛けてネットワークアクセスを獲得できる。ネットワーク隔離なしでは、SSH キーなどの機密ファイルを外部に窃取できる。

┌─────────────────────────────────────────┐
│  ネットワーク隔離層                        │
│  プロキシサーバー（サンドボックス外で稼働）    │
│  ドメイン単位の許可/拒否                    │
│  ┌─────────────────────────────────────┐ │
│  │  ファイルシステム隔離層                 │ │
│  │  OS プリミティブによるパス制御           │ │
│  │  書き込み: CWD + 明示的許可パスのみ     │ │
│  │  読み取り: 全体（拒否パスを除く）        │ │
│  │  ┌─────────────────────────────────┐ │ │
│  │  │  Bash コマンド + 全子プロセス      │ │ │
│  │  │  （制限は自動的に継承される）        │ │ │
│  │  └─────────────────────────────────┘ │ │
│  └─────────────────────────────────────┘ │
└─────────────────────────────────────────┘

OS ごとの実装

macOS Seatbelt の仕組み

Seatbelt は Apple の TrustedBSD MAC（Mandatory Access Control）フレームワーク上に構築されています。ISE の技術分析によると、動作は以下の通りです。

1. sandbox_init() が呼ばれ、人間が読めるポリシー定義がバイナリ形式に変換される
2. バイナリポリシーが mac_syscall を通じてカーネルに渡される
3. カーネルの TrustedBSD サブシステムがほぼ全てのシステムコールにフックを設置
4. プロセスが制限された操作を試みると、カーネルレベルでブロック
5. 全ての子プロセスも同じポリシーに拘束される

重要なのは、これがアプリケーションレベルではなくカーネルレベルで強制される点です。プロセス自身がサンドボックスを解除することはできません。

Linux bubblewrap の仕組み

bubblewrap は Linux の namespace 機構を活用した非特権サンドボックスツールです。ArchWiki によると、以下の namespace を組み合わせます。

さらに PR_SET_NO_NEW_PRIVS フラグにより、サンドボックス内で setuid バイナリが機能しません。これは一般的なサンドボックス脱出ベクターを封じる重要な措置です。

ファイルシステム隔離の詳細

デフォルトの動作

パス設定の構文

settings.json で追加の書き込みパスを許可できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "//tmp/build"],
      "denyWrite": ["~/.ssh"],
      "denyRead": ["~/.ssh/id_rsa"]
    }
  }
}

パスプレフィックスの解釈ルールは以下の通りです。

設定のマージ動作

複数の設定スコープ（managed-settings.json、ユーザー設定、プロジェクト設定）で allowWrite が定義されている場合、配列はマージされます。上書きではなく結合です。

例: managed-settings が //opt/company-tools を許可し、ユーザー設定が ~/.kube を追加した場合、両方が最終的なサンドボックス設定に含まれます。

ネットワーク隔離の詳細

ネットワーク制限はサンドボックス外で稼働するプロキシサーバーを経由して実現されます。

動作フロー

サンドボックス内のプロセス
  → プロキシサーバー（サンドボックス外）
    → ドメインが許可リストにあるか確認
      → 許可: 接続を中継
      → 未許可: ブロック + ユーザーに通知

ドメイン許可設定

1
2
3
4
5
6
7
8
9

{
  "sandbox": {
    "allowedDomains": [
      "registry.npmjs.org",
      "api.github.com",
      "pypi.org"
    ]
  }
}

未承認のドメインへの接続試行時、ユーザーには3つの選択肢が提示されます。

1. 拒否: 接続をブロック
2. 一度だけ許可: 今回のみ接続を許可
3. 設定を更新: 永続的にドメインを許可リストに追加

ネットワーク隔離の制約

公式ドキュメントが明示している制約があります。

• ドメインフロンティング: ドメインフィルタリングは接続先ドメインの制限のみ。トラフィックの内容は検査しないため、ドメインフロンティングによるバイパスが理論上可能
• 広範なドメイン許可のリスク: github.com のような広範なドメインを許可すると、データ窃取の経路になり得る

Docker との違い — 4つの隔離アプローチ

「Docker コンテナで十分では？」という疑問も多いでしょう。技術比較分析によると、AI エージェントの隔離には4つのアプローチがあり、Claude Code はそのうち2つを使い分けています。

隔離技術の全体像

弱い ◄─────────────── 隔離強度 ──────────────► 強い
軽い ◄─────────────── オーバーヘッド ──────────► 重い

chroot      OS プリミティブ     Docker/gVisor      マイクロVM
(パスのみ)   (bubblewrap/       (namespace +       (Firecracker)
             seatbelt)          cgroups)
              ▲                    ▲                  ▲
              │                    │                  │
         Claude Code CLI      Claude Code Web      Docker Sandbox

4つのアプローチの比較

Anthropic は環境に応じて技術を使い分けている点が重要です。ローカル CLI では起動10ms未満の OS プリミティブを、クラウド（Claude Code Web）ではマルチテナント向けの gVisor を選択しています。

Docker コンテナとの根本的な違い

Docker コンテナと Claude Code のネイティブサンドボックスは、同じ Linux namespace 技術を基盤としていますが、設計目標が異なります。

重要な共通点として、Docker もネイティブサンドボックスもホストカーネルを共有しています。Palo Alto Networks Unit 42 は「従来のコンテナ（Docker, LXC, rkt）はホスト OS カーネルを共有しており、真のサンドボックスではない」と指摘しています。カーネルの脆弱性を突けば、どちらも脱出可能です。

真のハードウェアレベル隔離が必要な場合は、マイクロVM（Firecracker）や通常の VM が選択肢になります。

Claude Code の3つの隔離オプション

Claude Code は用途に応じて3つの隔離手段を提供しています。

1. ネイティブサンドボックス（日常開発向け）

1
2

# 有効化
/sandbox

• 用途: 日常的な開発作業
• 強み: 起動が速い、設定が簡単、開発フローを妨げない
• 弱み: ホストカーネル共有、Bash ツールのみに適用

2. DevContainer（チーム開発・セキュリティ監査向け）

公式ドキュメントによると、DevContainer は Docker ベースの隔離環境です。

1

# VS Code で「Reopen in Container」

• 用途: チームオンボーディング、セキュリティ監査、untrusted リポジトリ
• 強み: ファイルシステムの完全分離、--dangerously-skip-permissions が安全に使える、ファイアウォールで許可ドメインのみ
• 弱み: 起動が遅い、Docker Engine が必要、ライセンスコスト

DevContainer はコンテナ自体がサンドボックスとして機能するため、承認なしの自動実行（--dangerously-skip-permissions）が想定されています。ただし公式は「悪意あるプロジェクトがDevContainer内のアクセス可能なもの（Claude Code の認証情報を含む）を窃取することは防げない」と警告しています。

3. Docker Sandbox（最強の隔離）

Docker 公式ブログで紹介されている Docker Sandbox は、マイクロVM ベースの隔離を提供します。

• 用途: 完全無人運用、untrusted コード実行
• 強み: ハードウェアレベル隔離、Docker-in-Docker 対応、ネットワーク制御
• 弱み: Docker Desktop 必要（大企業は有料）、環境互換性の課題

どれを選ぶべきか

サンドボックスモードの選択

Claude Code は2つのモードを提供しています。

有効化方法

/sandbox

このコマンドでモード選択メニューが表示されます。macOS ではそのまま動作しますが、Linux/WSL2 では事前に依存パッケージが必要です。

1
2
3
4
5

# Ubuntu/Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

エスケープハッチ — 最大のセキュリティリスク

サンドボックスの設計上、最も議論を呼んでいるのがエスケープハッチ（dangerouslyDisableSandbox）です。

仕組み

サンドボックス制限でコマンドが失敗した場合、Claude はエラーを分析し、dangerouslyDisableSandbox: true パラメータ付きでコマンドを再試行することがあります。この場合、通常の Claude Code パーミッションフローに従い、ユーザーの承認を求めます。

報告されている脆弱性

GitHub Issue #14268 は深刻な問題を報告しています。

問題: Bash が自動承認ツールに設定されている場合、dangerouslyDisableSandbox: true がユーザーの確認なしに実行される。

再現手順:

1. Bash を自動承認ツールに設定
2. プロジェクト外にテストファイルを作成: touch ~/test1
3. サンドボックス有効で削除試行:
   Bash(rm ~/test1)
   → Operation not permitted（正常にブロック）

4. dangerouslyDisableSandbox: true で再試行:
   Bash(rm ~/test1, dangerouslyDisableSandbox: true)
   → ファイル削除成功、ユーザープロンプトなし

つまり、サンドボックスが保護しているはずのパスに対して、承認なしでアクセスできてしまうのです。

対策

1
2
3
4
5

{
  "sandbox": {
    "allowUnsandboxedCommands": false
  }
}

この設定で dangerouslyDisableSandbox パラメータは完全に無視されます。全てのコマンドがサンドボックス内で実行されるか、excludedCommands に明示的にリストされている必要があります。

推奨: セキュリティを重視する場合は allowUnsandboxedCommands: false を必ず設定してください。

CVE-2026-25725 — サンドボックス脱出の実例

サンドボックスの実装にも脆弱性が発見されています。GHSA-ff64-7w26-62rf として公開されたこの脆弱性は、サンドボックス脱出を可能にするものでした。

攻撃の仕組み

1. bubblewrap サンドボックスは .claude/settings.local.json を読み取り専用で保護していた
2. しかし .claude/settings.json が存在しない場合、保護が適用されなかった
3. 親ディレクトリは書き込み可能だったため、サンドボックス内から settings.json を作成可能
4. SessionStart フックなどの永続的なコマンドを注入
5. Claude Code 再起動時に、注入されたコマンドがホスト権限で実行される

この脆弱性は v2.1.2 で修正済みですが、サンドボックスが「完璧な防御」ではないことを示す重要な事例です。

互換性と既知の制約

全てのツールがサンドボックスと互換性があるわけではありません。

オープンソースのサンドボックスランタイム

Claude Code のサンドボックスランタイムは @anthropic-ai/sandbox-runtime として npm パッケージで公開されています。GitHub リポジトリ から利用可能です。

用途

• 独自の AI エージェントのサンドボックス化
• MCP サーバーの隔離実行
• 任意のプロセスのサンドボックス化

1
2

# MCP サーバーをサンドボックス内で実行
npx @anthropic-ai/sandbox-runtime <command-to-sandbox>

Anthropic がこれをオープンソース化した理由は明確です。「セキュリティの改善はエコシステム全体に利益をもたらす」という信念に基づき、AI エージェントコミュニティ全体でより安全な自律システムを構築するためです。

実践的な設定ガイド

最小構成（個人開発）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "allowedDomains": [
      "registry.npmjs.org",
      "api.github.com"
    ]
  }
}

Web 開発向け

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "allowedDomains": [
      "registry.npmjs.org",
      "api.github.com",
      "pypi.org",
      "cdn.jsdelivr.net"
    ],
    "filesystem": {
      "allowWrite": ["//tmp"],
      "denyRead": ["~/.ssh", "~/.aws/credentials"]
    },
    "excludedCommands": ["docker"]
  }
}

エンタープライズ（managed-settings.json）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "allowedDomains": [
      "registry.npmjs.org",
      "api.github.com",
      "internal-registry.company.com"
    ],
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws", "~/.gnupg"],
      "denyWrite": ["~/.bashrc", "~/.zshrc", "/usr/local/bin"]
    },
    "network": {
      "httpProxyPort": 8080,
      "socksProxyPort": 8081
    }
  },
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

カスタムプロキシを使えば、HTTPS トラフィックの復号・検査、リクエストのログ記録、SIEM 連携が可能です。

サンドボックスとパーミッションの関係

サンドボックスとパーミッションは補完的な2つのセキュリティ層です。

重要な点は、サンドボックスは Bash ツールにのみ適用されるということです。Claude Code の Read/Edit/Write ツールは独自のパーミッションシステムで制御されます。したがって、包括的なセキュリティには両方の設定が必要です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/.ssh"]
    }
  },
  "permissions": {
    "deny": [
      "Read(.env*)",
      "Read(**/*.pem)"
    ]
  }
}

ただし、deny ルールには既知のバグがあることに注意してください。サンドボックスのファイルシステム制限は OS レベルで強制されるため、deny ルールよりも信頼性が高いです。

まとめ

• chroot とは全く違う: chroot はファイルシステムのパス解決を変えるだけで、セキュリティ対策として設計されていない。root 権限で容易に脱出可能
• Docker とも違う: Docker はアプリケーションのパッケージングが目的で起動に数秒かかる。Claude Code のネイティブサンドボックスは10ms未満で起動し、開発フローを妨げない。ただし両者ともホストカーネルを共有しており、カーネル脆弱性への耐性は同等
• カーネルレベルの2層隔離: macOS は Seatbelt（TrustedBSD MAC）、Linux は bubblewrap（namespaces + seccomp）で、ファイルシステムとネットワークを OS レベルで強制的に隔離
• 3つの隔離オプション: ネイティブサンドボックス（日常開発）、DevContainer（チーム開発・監査）、Docker Sandbox（マイクロVM による最強隔離）を用途で使い分ける
• 承認プロンプト84%削減: セキュリティを維持しながら「承認疲れ」を解消。Auto-allow モードではサンドボックス内のコマンドが自動実行される
• エスケープハッチに要注意: dangerouslyDisableSandbox はデフォルトで有効。Bash が自動承認されている場合、承認なしでサンドボックスを迂回できる。allowUnsandboxedCommands: false の設定を推奨
• CVE-2026-25725 の教訓: settings.json が存在しない場合の保護漏れでサンドボックス脱出が可能だった（v2.1.2 で修正済み）。サンドボックスは「完璧」ではない
• サンドボックスは Bash のみに適用: Read/Edit/Write ツールは別のパーミッションシステムで制御される。包括的なセキュリティには両方の設定が必要
• オープンソースで利用可能: @anthropic-ai/sandbox-runtime として npm パッケージが公開されており、独自の AI エージェントや MCP サーバーの隔離に使える

参考

• Anthropic — Claude Code Sandboxing（エンジニアリングブログ）
• Claude Code — Sandboxing（公式ドキュメント）
• Claude Code — Security（公式ドキュメント）
• Claude Code サンドボックス — 日本語公式
• @anthropic-ai/sandbox-runtime — npm
• sandbox-runtime — GitHub
• GHSA-ff64-7w26-62rf — settings.json 経由のサンドボックス脱出（CVE-2026-25725）
• GitHub Issue #14268 — dangerouslyDisableSandbox がパーミッションプロンプトをバイパス
• GitHub Issue #20259 — エスケープハッチをオプトイン化する提案
• Practical CTF — Sandboxes: chroot, seccomp & namespaces
• ISE — The Apple Sandbox（技術分析）
• HackTricks — macOS Sandbox
• bubblewrap — GitHub
• ArchWiki — Bubblewrap
• Pierce Freeman — A deep dive on agent sandboxes
• claudefa.st — Claude Code Sandbox Guide
• Qiita — Claude Code入門 #3: パーミッション＆Sandbox完全ガイド
• Trail of Bits — claude-code-config
• Why Anthropic and Vercel chose different sandboxes
• Docker — Docker Sandboxes: Run Claude Code and More Safely
• Claude Code — Development containers（公式）
• Trail of Bits — claude-code-devcontainer
• Palo Alto Networks Unit 42 — Making Containers More Isolated
• Docker Sandbox vs Native vs DevContainers