# Claude CodeのBashサンドボックス実装ガイド

> Claude CodeのBashサンドボックスはmacOSのSeatbelt・Linuxのbubblewrapでコマンドをカーネルレベルに封じ込め、権限ルールとは独立した第2の防御層になります。設定と限界を解説。

- Canonical: https://kuucorp.com/blog/claude-code-sandboxed-bash-tool-configuration/
- Date: 2026-09-13
- Last modified: 2026-09-13
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
「AIエージェントに承認なしでコマンドを実行させたいが、暴走したときの被害範囲が怖い」——[エージェントガバナンス](/glossary/agent-governance/)を検討する現場でよく出る懸念だ。Claude Codeはこの問題に、[Bashサンドボックス](https://code.claude.com/docs/en/sandboxing)というOS層の隔離機構で答える。[権限ルールによる事前承認](/blog/claude-code-permission-mode-settings-design-smb/)とは独立した仕組みで、承認済みコマンドが想定外の動作をしてもカーネルが機械的に止める。本記事は公式ドキュメントに基づき、設定方法と限界を整理する。

## Claude CodeのBashサンドボックスとは何か

> Bashサンドボックスはコマンド実行前ではなく実行中に、OSがファイルとネットワークの境界を強制する仕組みです。

macOSでは追加インストール不要のSeatbeltフレームワーク、LinuxとWSL2ではbubblewrap（`bwrap`）を使い、Bashコマンドとその子プロセス全てにファイルシステムとネットワークの境界を強制する。`/sandbox`コマンドでモード選択・除外コマンド・解決済み設定を確認できる。Linuxではオプションのseccompフィルタでユニックスドメインソケットのブロックも追加できる。

## サンドボックスと権限ルールはどう違うか

> 権限ルールは「実行して良いか」を事前判定し、サンドボックスは「実行後に何に触れるか」をOSが強制する、独立した2層です。

権限ルールはコマンド文字列（またはauto modeの分類器判定）を根拠に実行前へ判断する。一方サンドボックスは実際に動くプロセスをOSが縛るため、モデルが何を意図していたかに関わらず境界が保たれる。auto-allowモードではサンドボックス化できるコマンドはプロンプトなしで自動承認されるが、`rm`等の[危険パス](https://code.claude.com/docs/en/permission-modes)操作や明示的なdenyルールは常に優先される。

## ファイルシステムと通信はどう隔離されるか

> デフォルトでは作業ディレクトリのみ書き込み可、読み取りはホーム含め全体可、通信は許可済みドメインのみ通過します。

書き込みは作業ディレクトリ・`--add-dir`で追加したディレクトリ・セッション一時ディレクトリに限られ、`.claude/settings.json`や`.git/hooks`などの設定ファイルは書き込み可能領域の中でも保護される。読み取りはデフォルトで`~/.aws/credentials`や`~/.ssh/`も含め全体に及ぶため、`sandbox.credentials`でファイル・環境変数を`deny`（遮断）または`mask`（実利用先にだけプロキシ経由で復元）に設定する必要がある。ネットワークはサンドボックス外で動くプロキシが仲介し、`sandbox.network.allowedDomains`で事前許可したドメイン以外は初回アクセス時にプロンプトまたは分類器判定にかかる。

## エンタープライズ環境ではどう強制すればよいか

> 組織全体に強制するには managed settings で `enabled`・`failIfUnavailable`・`allowManagedDomainsOnly` を配布します。

個人設定は`.claude/settings.local.json`に保存されるが、全開発者に強制するにはMDMまたはserver-managed settings経由で`sandbox.enabled: true`と`failIfUnavailable: true`を配布し、依存パッケージ欠如時に無防備な平文実行へフォールバックさせない。`allowManagedDomainsOnly`を設定すれば開発者側の`allowedDomains`追加を無視し、組織承認ドメインのみに固定できる。AWS認証情報のように署名を伴う値は`credentials.awsPairs`でペア指定すれば、プロキシがSigV4署名を再計算しつつ実値を隠したまま送信できる。大規模なマルチチーム統制は[RDE](https://kuucorp.com/services/rde/)の設計支援対象になる。

## 導入前に知っておくべき限界は何か

> 標準のプロキシはTLSを終端しないため、ドメイン偽装（domain fronting）で許可ドメイン外への通信が理論上可能です。

サンドボックスのネットワーク許可はクライアントが提示するホスト名を根拠に判定し、デフォルトではTLSの中身を検査しない。厳格な脅威モデルでは`network.tlsTerminate`によるTLS終端か、独自CA証明書を組み込んだカスタムプロキシが必要になる。また対象はBashサブプロセスのみで、Read/Edit/Writeツールは通常の権限システムで別途制御され、Computer Useは実機の画面を直接操作するため対象外である。`docker`や`jest --watchman`など一部ツールはサンドボックスと非互換なため`excludedCommands`での除外が必要になる。

## 規模別の留意点（SMB / エンタープライズ）

**SMB（中小企業）向け**

エンジニアが少ない環境では、まず`/sandbox`パネルでauto-allowモードを有効にし、`kubectl`や`terraform`など書き込み先を広げたいツールだけ`sandbox.filesystem.allowWrite`に個別追加するのが現実的な出発点だ。設定は`~/.claude/settings.json`に1回書けば全プロジェクトに適用される。[Kuuのエージェントガバナンス支援](https://kuucorp.com/services/ai-ops/)ではこうした最小構成の導入相談も受け付けている。

**エンタープライズ向け**

managed settingsで`sandbox.enabled`と`failIfUnavailable`を固定し、`.claude/settings.json`側からの無効化を防ぐ。加えて`sandbox.credentials`で`~/.aws`や`~/.ssh`を明示的にdeny/maskしないと、デフォルトの読み取り許可がそれらを素通りさせる点に注意したい。

## 参考

- [Configure the sandboxed Bash tool — Claude Code Docs](https://code.claude.com/docs/en/sandboxing)
- [Settings reference — Claude Code Docs](https://code.claude.com/docs/en/settings-reference)

## まとめ

Claude CodeのBashサンドボックスは、権限ルールという確率的・事前判定の防御に、OSレベルで強制される決定論的な第2層を重ねる仕組みだ。デフォルトの読み取り許可範囲やTLS非検査といった限界を理解した上で、SMBは`allowWrite`の個別追加から、エンタープライズはmanaged settingsでの強制から始めるのが実践的な導入順序になる。自社のエージェント実行基盤への組み込みを検討する際は、[Kuu株式会社](https://kuucorp.com/services/ai-ops/)のエージェントガバナンス支援を活用してほしい。