Claude Code Sandboxとは?サンドボックスの仕組みと有効化・設定方法を完全解説【2026年最新】
室谷今回はClaude Codeのサンドボックス機能について話しましょう。正直、これを知らないでClaude Code使ってる人、かなり多いんですよね・・・
テキトー教師ですよね。.AI(ドットエーアイ)のコミュニティのメンバーさんに「サンドボックス有効にしてますか?」って聞くと、8割くらいの方が「知らなかった」って言うんです。
Claude Codeの機能の中で最もスルーされがちなのがサンドボックスだと思いますよ。
Claude Codeの機能の中で最もスルーされがちなのがサンドボックスだと思いますよ。
室谷MYUUUのエンジニアに全員有効化させてるんですが、一度有効化すると「なんで今まで使ってなかったんだろう」って言うんですよw セキュリティが上がるだけじゃなく、実は承認の手間が減って生産性も上がるんですよね。
テキトー教師その「承認が減る」という点、最初は直感に反するんですよ。セキュリティを強化したら制約が増えるはずなのに、なぜ楽になるのかって。
そこから入ると理解しやすいですね。
そこから入ると理解しやすいですね。
室谷整理するとこういうことです。通常のモードでは、Claude Codeがbashコマンドを実行するたびに「許可しますか?」って聞いてくる。
これが積み重なると「承認疲れ」が起きて、よく読まずにOKを押してしまう。サンドボックスは最初に「ここまでの範囲でやっていいよ」という境界を定義することで、その範囲内ではいちいち聞かなくて済む設計なんです。
これが積み重なると「承認疲れ」が起きて、よく読まずにOKを押してしまう。サンドボックスは最初に「ここまでの範囲でやっていいよ」という境界を定義することで、その範囲内ではいちいち聞かなくて済む設計なんです。
テキトー教師「事前に範囲を決める」という発想の転換ですよね。Claude Codeの公式ドキュメントにも「毎回承認を求めるより、境界を最初に定義する方がセキュリティ的に優れている」と書いてあって、実際にその通りだと思います。
Claude Code Sandboxとは何か:サンドボックスの概念と役割
室谷まず「そもそもサンドボックスとは何か」という話からしましょう。サンドボックスというのは、プログラムの動作範囲を制限する隔離環境のことです。
「砂場」のイメージで、砂場の中で遊んでいいけど外には出られない、という感じです。
「砂場」のイメージで、砂場の中で遊んでいいけど外には出られない、という感じです。
テキトー教師Claude Codeの場合、具体的には2種類の制限を実装しています。ひとつは「ファイルシステムの分離」、もうひとつは「ネットワークの分離」です。
この2つがセットで動いて初めてサンドボックスとして機能するというのが重要なポイントで、どちらか片方だけでは意味がないんです。
この2つがセットで動いて初めてサンドボックスとして機能するというのが重要なポイントで、どちらか片方だけでは意味がないんです。
室谷そうなんですよね。ファイルだけ制限してもネットワークが自由なら、SSHキーを読み込んで外部に送信できてしまう。
逆にネットワークだけ制限してもファイルが自由なら、重要な設定ファイルを書き換えられてしまう。両方があってこそセキュリティが成立するんです。
逆にネットワークだけ制限してもファイルが自由なら、重要な設定ファイルを書き換えられてしまう。両方があってこそセキュリティが成立するんです。
テキトー教師この点、コミュニティのメンバーさんが見落としやすいところです。「ネットワーク制限だけすれば安全でしょ?」って思いがちなんですが、公式ドキュメントにも明記されてますね。
「ネットワーク分離なしでは、侵害されたエージェントがSSHキーのような機密ファイルを外部に送信できてしまう」と。
「ネットワーク分離なしでは、侵害されたエージェントがSSHキーのような機密ファイルを外部に送信できてしまう」と。
室谷Claude Codeはそもそも何ができるか、という観点で考えるとより怖さがわかるんです。ファイルを読んで・書いて・bashコマンドを実行できる。
つまりシステムにアクセスできるユーザーと同等の権限を持っているわけです。
つまりシステムにアクセスできるユーザーと同等の権限を持っているわけです。
テキトー教師そういう意味では「Claude Code sandboxing(サンドボックシング)」というのは、単なる機能の一つではなく、Claude Codeをチームや企業で安全に使う上での前提条件とも言えますね。
室谷MYUUUでは、新しいメンバーがClaude Codeを使い始める際に、まずサンドボックスの設定から入るようにしてます。後から設定するより、最初から適切な環境でスタートした方がいい。

ネイティブサンドボックスの仕組み:OSレベルの制限
テキトー教師Claude Codeのサンドボックスが強力なのは、OSのプリミティブを使っているからです。アプリレベルで「このコマンドはブロック」というソフトウェア制限ではなく、OSレベルで強制されるんです。
室谷これ、めちゃくちゃ重要なポイントですよね。OSレベルで制限されているということは、Claude Code自身が「バイパスしよう」と思ってもできない。
すべての子プロセスがサンドボックスの制限を引き継ぐんです。
すべての子プロセスがサンドボックスの制限を引き継ぐんです。
テキトー教師公式ドキュメントに記載されている、OS別の実装はこうなっています。
- macOS: Seatbelt(AppleのサンドボックスフレームワークでmacOS標準搭載)
- Linux: bubblewrap(namespacesベースの隔離技術)
- WSL2: bubblewrap(Linuxと同じ)
- WSL1: 非対応(必要なカーネル機能が不足しているため)

室谷macOSはデフォルトで使えるんですが、LinuxとWSL2は事前にパッケージのインストールが必要です。後で詳しく説明しますが、Ubuntu/Debianなら
sudo apt-get install bubblewrap socat で入ります。
テキトー教師kubectl や terraform、npm といったサードパーティツールもすべてサンドボックス内で動作するというのが重要です。「Claude Code自身のコマンド」だけが制限されるのではなく、それらが呼び出すサブプロセス全てに制限が効くんです。
なぜ今サンドボックスが必要なのか:Claude Codeのリスクを理解する
室谷少し前に話題になったんですが、Claude Codeのソースコードが流出する事件がありましたよね。npmパッケージのソースマップ設定ミスで51万行超が流出した件。
あのとき「セキュリティやばい」って声が多かったんですが、注目すべきはそこじゃないんですよ。
あのとき「セキュリティやばい」って声が多かったんですが、注目すべきはそこじゃないんですよ。
テキトー教師そうですね。本質的なリスクは「Claude Code自体が持つ権限の大きさ」にあります。
Claude Codeは開発者のローカル環境と同等の権限を持って動作します。これはすごく強力なんですが、同時にリスクでもある。
Claude Codeは開発者のローカル環境と同等の権限を持って動作します。これはすごく強力なんですが、同時にリスクでもある。
室谷MYUUUでも考えてることなんですが、「AIエージェントに開発をお願いする」というのは、ある意味「信頼できるかどうかわからない人に自分のパソコンを渡す」に近い行為なんですよね。プロンプトインジェクション攻撃、つまり悪意のある指示をClaudeに紛れ込ませる攻撃が成功した場合に何ができるか、を考えると怖い・・・
テキトー教師プロンプトインジェクションというのは、たとえば「外部から読み込んだコードにコメントとして悪意のある指示が埋め込まれていて、Claude Codeがそれを指示として解釈してしまう」といったケースです。サンドボックスがあれば、たとえその指示を実行しようとしても「境界の外には出られない」んです。
室谷具体的に「何から守られるか」を整理すると、こうなります。
| リスク | サンドボックスなし | サンドボックスあり |
|---|---|---|
| SSHキー(~/.ssh/)へのアクセス | 可能 | 読み取り拒否可能 |
| AWS認証情報(~/.aws/credentials)へのアクセス | 可能 | 読み取り拒否可能 |
| システムファイルの書き換え(/etcなど) | 可能 | 書き込み拒否 |
| 未許可ドメインへのデータ送信 | 可能 | プロキシでブロック |
| 悪意のあるNPMパッケージの実行 | 制限なし | ネットワーク・ファイル制限あり |
| プロンプトインジェクションによる操作 | 無制限 | 境界内に制限される |
テキトー教師この表を見ると、サンドボックスが「できることを減らす機能」ではなく「リスクを限定する機能」だというのが伝わりますよね。Claude Codeの有益な機能は全て使えながら、万が一の時のダメージを最小化する、という発想です。
室谷海外のエンタープライズ企業だと、むしろ「サンドボックスなしで使っているClaude Codeは導入禁止」というポリシーを持っているところも増えてるんですよね。日本でもこれからそういう議論が増えると思います。
Claude Code Sandboxの有効化方法:macOS・Linux・WSL2別手順
macOSでの有効化(追加インストール不要)
テキトー教師macOSの場合はいちばんシンプルです。追加のパッケージインストールは不要で、Claude Code内のコマンドだけで有効化できます。
室谷/sandbox コマンドを実行するだけです。メニューが開いてサンドボックスのモードを選べます。/sandbox
テキトー教師このメニューでは2つのモードを選べます。
- Auto-allowモード: サンドボックス内のコマンドは自動的に許可される。許可が必要なコマンドだけ通常の承認フローに戻る
- Regular permissionsモード: サンドボックス内のコマンドも通常の承認フローを通る。より厳格なコントロールが必要な場合に
室谷ほとんどのケースではAuto-allowモードで十分だと思います。「サンドボックスを有効にして、かつすべての承認を求める」というRegular permissionsモードは、ちょっとやりすぎ感があるんですよね。
そもそもAuto-allowの良さは「承認疲れを減らすこと」なので。
そもそもAuto-allowの良さは「承認疲れを減らすこと」なので。
テキトー教師講座でも「まず
/sandbox を有効にしてAuto-allowで使ってみましょう」と教えてます。最初から細かい設定にこだわると動かなくなったりするので、まずデフォルト設定で動かしてみてから調整する方がいいですね。Linuxでの有効化(bubblewrapのインストールが必要)
室谷Linuxの場合はbubblewrapとsocatが必要です。Ubuntu/Debianなら以下のコマンドでインストールできます。
# Ubuntu/Debian
sudo apt-get install bubblewrap socat
# Fedora
sudo dnf install bubblewrap socat
テキトー教師インストール後はmacOSと同じく
/sandbox コマンドで有効化します。依存パッケージが見つからない場合、メニューにインストール手順が表示されるので、それに従えばOKです。
室谷Linuxサーバーで Claude Codeを使う場合も同じ手順ですね。ただしLinuxの場合、Dockerコンテナ内で使うときは少し注意が必要で、後で詳しく話します。
WSL2での有効化
テキトー教師WSL2はLinuxと同じ手順です。bubblewrapとsocatをインストールして
注意点として、WSL1はサポートされていないので、WSL2を使うことが前提になります。
/sandbox で有効化します。注意点として、WSL1はサポートされていないので、WSL2を使うことが前提になります。
室谷WSL1とWSL2の確認は
バージョンが1のディストリビューションは
wsl --list --verbose で確認できます。VERSION列が2になっていればWSL2です。バージョンが1のディストリビューションは
wsl --set-version <distro-name> 2 でWSL2に変換できます。# WSLバージョン確認
wsl --list --verbose
# WSL1 → WSL2に変換
wsl --set-version Ubuntu 2
テキトー教師Windowsネイティブのサポートは現時点(2026年4月)では計画中で、まだリリースされていません。WindowsでClaude Code sandboxを使うにはWSL2経由が唯一の方法です。
サンドボックスの2つのモードを使い分ける
室谷Auto-allowモードとRegular permissionsモードの使い分けについて、もう少し詳しく話しましょう。
テキトー教師整理するとこういう違いです。
| モード | サンドボックス内のコマンド | サンドボックス外のコマンド |
|---|---|---|
| Auto-allowモード | 自動的に許可(承認不要) | 通常の承認フロー |
| Regular permissionsモード | 通常の承認フロー | 通常の承認フロー |
室谷「サンドボックス内のコマンドが自動で許可される」ということは、ファイル編集ツールが「Accept editsモード」でなくても、サンドボックス内のbashコマンドはプロンプトなしに実行されるということです。これがAuto-allowモードの核心ですね。
テキトー教師コミュニティのメンバーさんでよく混乱するのが「EditツールとBashコマンドで扱いが違う」という点です。
- Edit / Readツール: パーミッションシステムで直接制御される(サンドボックスの対象外)
- Bashコマンドとそのサブプロセス: サンドボックスのOSレベル制限が適用される
室谷つまりサンドボックスは「bashコマンドを安全に実行するための仕組み」であって、Claude Codeの全てのツールを制限するわけじゃないんです。ReadツールやEditツールはパーミッション設定で別途管理する必要があります。
テキトー教師「サンドボックスとパーミッションは補完的に動く」というのが公式ドキュメントの表現で、これが正確な表現ですね。サンドボックスがあれば全て安全、というわけではなく、両方を組み合わせることでより強固なセキュリティが実現する。
settings.jsonでサンドボックスを設定する
室谷/sandbox コマンドで手動有効化するのはいいんですが、チームや組織で使う場合は settings.json で設定を管理した方がいいです。コードと一緒にバージョン管理できますし、全員に同じ設定を強制できるので。
テキトー教師設定ファイルの場所は3層構造になっています。
- ユーザー設定:
~/.claude/settings.json(個人の設定) - プロジェクト設定:
<project-root>/.claude/settings.json(プロジェクト全体の設定) - マネージド設定: Enterprise向けに管理者が強制できる設定
室谷基本的なサンドボックス設定はこんな形です。
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true
}
}
テキトー教師enabled: true でサンドボックスを有効にして、autoAllowBashIfSandboxed: true でAuto-allowモードにする。これが最もシンプルな設定です。
室谷failIfUnavailable というオプションもあって、これが便利なんです。{
"sandbox": {
"enabled": true,
"failIfUnavailable": true
}
}
テキトー教師これを
true にすると、サンドボックスが起動できない場合(依存パッケージがないなど)にエラーで停止します。デフォルトは false で、その場合は「警告を表示してサンドボックスなしで実行」という動作になります。
室谷エンタープライズ環境で「必ずサンドボックス付きで実行させる」というポリシーを貫く場合は
failIfUnavailable: true が必須ですね。気づかないうちにサンドボックスなしで動いていた、という状況を防げます。ファイルシステムの分離設定:allowWrite・denyRead・denyWriteの使い方
室谷settings.jsonのサンドボックス設定、もう少し深掘りしましょう。特にファイルシステムの設定は、実際に使う場面で「あれ、ここに書けない」ってなりやすいんですよね。
テキトー教師そうです。デフォルトの挙動を理解してから設定した方がいいですね。
デフォルトでは「現在の作業ディレクトリとそのサブディレクトリへの読み書き」が許可されています。それ以外のパスへの書き込みはブロックされます。
デフォルトでは「現在の作業ディレクトリとそのサブディレクトリへの読み書き」が許可されています。それ以外のパスへの書き込みはブロックされます。
室谷読み込みはもう少し広いんですよね。デフォルトでは「特定のディレクトリ以外はコンピュータ全体を読めます」。
書き込みだけが厳しく制限されている。
書き込みだけが厳しく制限されている。
テキトー教師具体的なケースで考えましょう。たとえば kubectl や terraform を使うとき、それらのツールは
デフォルトのサンドボックスだと、作業ディレクトリ以外への書き込みがブロックされるので、こういったツールがエラーになる可能性があります。
~/.kube とか /tmp に書き込む必要があります。デフォルトのサンドボックスだと、作業ディレクトリ以外への書き込みがブロックされるので、こういったツールがエラーになる可能性があります。
室谷そのために
filesystem.allowWrite があります。追加で書き込みを許可するパスをリストアップするものです。{
"sandbox": {
"enabled": true,
"filesystem": {
"allowWrite": ["/tmp/build", "~/.kube"]
}
}
}
テキトー教師パスの書き方には規則があって、まとめるとこうなります。
| プレフィックス | 意味 | 例 |
|---|---|---|
/ | ファイルシステムルートからの絶対パス | /tmp/build |
~/ | ホームディレクトリからの相対パス | ~/.kube → $HOME/.kube |
./ またはプレフィックスなし | プロジェクトルートからの相対パス | ./output |
室谷denyRead と denyWrite も重要です。逆に「ここだけはアクセスさせたくない」というパスを指定できます。{
"sandbox": {
"enabled": true,
"filesystem": {
"denyRead": ["~/.ssh", "~/.aws/credentials", ".env*"]
}
}
}
テキトー教師SSHキーやAWS認証情報は読ませたくないですよね。こういう設定を入れておくと、プロンプトインジェクション攻撃でこれらのファイルを読まれるリスクをゼロにできます。
室谷面白いのは、
denyRead で範囲を広く禁止しつつ、allowRead でその中の特定パスだけ許可できることです。{
"sandbox": {
"enabled": true,
"filesystem": {
"denyRead": ["~/"],
"allowRead": ["."]
}
}
}
テキトー教師この設定、実際に使うシーン何ですか?
室谷「ホームディレクトリ全体は読ませたくないけど、今いるプロジェクトフォルダだけは読んでほしい」というケースです。
allowRead の . はプロジェクトルートを指すので、プロジェクト内のファイルだけ読めて、~/.aws や ~/.ssh などには一切アクセスできない状態になります。
テキトー教師この「最小権限原則」の実装ですね。Claude Codeに必要最小限の権限しか与えない。
エンタープライズ環境では特に重要な考え方です。
エンタープライズ環境では特に重要な考え方です。
設定のマージ動作:複数スコープで配列が結合される
室谷settings.json の設定、実は「上書き」じゃなくて「結合」される動きをするんです。これ、知らないと混乱するポイントです。
テキトー教師そうなんですよ。たとえばユーザー設定の
マネージドの設定で
allowWrite に ~/.kube が入っていて、プロジェクト設定の allowWrite に /tmp/build が入っている場合、両方が有効になります。マネージドの設定で
/opt/company-tools を追加しても、それ以外の設定は消えない。
室谷つまり各スコープは「追加」する。管理者がマネージド設定でパスを指定しても、開発者の個人設定のパスも維持される。
これは「より安全な方向」への配慮ですね。管理者が意図的に何かをブロックしたい場合は
これは「より安全な方向」への配慮ですね。管理者が意図的に何かをブロックしたい場合は
denyRead や denyWrite を使う必要があります。ネットワーク分離の設定:allowedDomains・プロキシ設定
テキトー教師ファイルシステムの次はネットワーク設定の話ですね。Claude Code sandboxのネットワーク分離は、プロキシサーバーを通じて実装されています。
室谷これ、仕組みが面白くて。サンドボックスの外側でプロキシが動いていて、サンドボックス内からのネットワークアクセスは全部そのプロキシを経由する。
プロキシが「このドメインはOK、このドメインはNG」という判断をするんです。
プロキシが「このドメインはOK、このドメインはNG」という判断をするんです。
テキトー教師network.allowedDomains で許可するドメインをリストアップします。ワイルドカードも使えます。{
"sandbox": {
"enabled": true,
"network": {
"allowedDomains": [
"github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com"
]
}
}
}
室谷新しいドメインへのアクセスが発生したとき、デフォルトでは「このドメインへのアクセスを許可しますか?」というプロンプトが出ます。ここで「常に許可」を選ぶとそのドメインが設定に追加されます。
テキトー教師network.allowManagedDomainsOnly というオプションもあって、これを true にするとマネージド設定で許可したドメイン以外は一切ブロックされます。開発者が新しいドメインを追加することもできなくなる。エンタープライズ向けの厳格なモードですね。
室谷カスタムプロキシを持ち込むことも可能で、これが企業向けのかなり重要な機能なんです。
{
"sandbox": {
"network": {
"httpProxyPort": 8080,
"socksProxyPort": 8081
}
}
}
テキトー教師独自プロキシを使うと「HTTPSトラフィックを復号して検査する」「カスタムフィルタリングルールを適用する」「全ネットワークリクエストをログに残す」といったことが可能になります。大企業のセキュリティポリシーに合わせた実装ができるわけです。
室谷Anthropicの公式ドキュメントには「既存のセキュリティインフラと統合する組織向けの高度なネットワークセキュリティのため」とあります。ここまで来ると本格的なエンタープライズ対応ですよね。
Unixソケットの設定
テキトー教師network.allowUnixSockets というオプションもあって、SSHエージェントなど特定のソケットへのアクセスを許可できます。
室谷ただしこれ、慎重に使う必要があります。公式ドキュメントが「セキュリティリスクに注意してください」と明記していて、たとえば
docker.sock を許可するとDockerを経由してホストシステムに実質的にアクセスできてしまいます。{
"sandbox": {
"network": {
"allowUnixSockets": ["~/.ssh/agent-socket"]
}
}
}
テキトー教師SSHエージェントのソケットだけを許可するなら、このような設定になります。
/var/run/docker.sock を追加すると事実上サンドボックスを突破できてしまうので、要注意ですね。DockerコンテナでClaude Code Sandboxを使う:注意点と設定
室谷Dockerとの組み合わせについて話しましょう。最近、CI/CD環境でClaude Codeを使いたいというニーズが増えているんですが、Dockerコンテナの中でbubblewrapを動かすのは一筋縄ではいかないんですよね。
テキトー教師bubblewrapはLinuxのuser namespacesを使っているんですが、多くのDockerコンテナ環境ではprivileged namespaces(特権的なネームスペース)が使えないように制限されています。つまりそのままでは動かない。
室谷そのために
enableWeakerNestedSandbox というオプションがあります。{
"sandbox": {
"enabled": true,
"enableWeakerNestedSandbox": true
}
}
テキトー教師ただしこれ、名前の通り「弱いサンドボックス」なんです。公式ドキュメントに「セキュリティが大幅に低下する」と明記されています。
Docker内で使う場合は、Dockerコンテナ自体が外側の隔離を提供しているという前提で、その中でさらにサンドボックスを重ねるという二重構造で使うことが推奨されています。
Docker内で使う場合は、Dockerコンテナ自体が外側の隔離を提供しているという前提で、その中でさらにサンドボックスを重ねるという二重構造で使うことが推奨されています。
室谷つまりDockerの場合の考え方は「外側のDockerコンテナがメインの隔離。その中でClaude Codeのサンドボックスも動かすが、こちらは弱い補助的な制限」という位置づけになります。
テキトー教師「claude code sandbox docker」の組み合わせで調べている方、多いと思うんですが・・・Dockerを強い隔離手段として使いつつ、Claude Code内のサンドボックスは弱いモードで有効化するのがベストプラクティスです。
室谷CI環境でClaude Codeをどう安全に使うか、というのは今後日本でも議論が活発になると思います。GitHubで公開されているDockerのサンドボックステンプレートを使うのが現時点では一番手軽な方法ですね。
Dockerとの互換性についての注意
テキトー教師もう一点、docker コマンド自体をサンドボックス内で実行しようとすると問題が起きます。docker はサンドボックスと相性が悪いです。
室谷excludedCommands でdockerをサンドボックスの対象外にすることで解決します。{
"sandbox": {
"enabled": true,
"excludedCommands": ["docker *"]
}
}
テキトー教師excludedCommands に指定したコマンドはサンドボックスの外で実行されます。サンドボックス外なので通常の承認フローが適用されます。docker だけでなく、他にもサンドボックスと相性が悪いツール(watchmanなど)も同様に対応できます。
エスケープハッチ機能:dangerouslyDisableSandboxとallowUnsandboxedCommands
室谷Claude Code sandboxの面白い設計として「エスケープハッチ」があります。サンドボックスが原因でコマンドが失敗した場合に、サンドボックスなしで再実行する仕組みです。
テキトー教師名前がインパクトありますよね。
あるコマンドがサンドボックスの制限に引っかかって失敗した場合、Claudeはその失敗を分析して、必要であれば
dangerouslyDisableSandbox というパラメータです。あるコマンドがサンドボックスの制限に引っかかって失敗した場合、Claudeはその失敗を分析して、必要であれば
dangerouslyDisableSandbox パラメータを使ってサンドボックスなしで再実行を試みます。
室谷これ、通常の承認フローが適用されるんですよね。ユーザーに「このコマンドをサンドボックスなしで実行していいですか?」って確認が来る。
なので完全な「抜け穴」ではなく、ユーザーの意識的な許可が必要なんです。
なので完全な「抜け穴」ではなく、ユーザーの意識的な許可が必要なんです。
テキトー教師ただし、このエスケープハッチ自体を無効化したい場合は
allowUnsandboxedCommands: false で封じられます。{
"sandbox": {
"enabled": true,
"allowUnsandboxedCommands": false
}
}
室谷これを
エンタープライズで「絶対にサンドボックスを外れてほしくない」というポリシーの場合はこれですね。
false にすると、dangerouslyDisableSandbox パラメータが完全に無視されます。全てのコマンドはサンドボックス内で実行するか、excludedCommands に明示的にリストされているかのどちらかしかない。エンタープライズで「絶対にサンドボックスを外れてほしくない」というポリシーの場合はこれですね。
テキトー教師「claude code dangerously skip permissions sandbox」というキーワードで検索している方、多いんですが・・・これが正確には
dangerouslyDisableSandbox の話で、「サンドボックスのパーミッションをスキップする」ではなく「サンドボックス自体を外してコマンドを実行する」という機能です。CLIからサンドボックスを操作するコマンド
室谷/sandbox コマンド以外にも、サンドボックスに関連するコマンドがいくつかあります。まとめましょう。
テキトー教師知っておくと便利なコマンドはこうなります。
| コマンド | 機能 |
|---|---|
/sandbox | サンドボックスモードの選択・有効化 |
/status | 現在のサンドボックス設定を含む全設定状況を表示 |
/permissions | 現在のパーミッション設定を表示・管理 |
室谷/status は特に便利で、どのsettings.jsonが読み込まれているか、どの設定が有効になっているかを全部見せてくれます。「設定したはずなのに効いてない」というときにまず確認するコマンドです。
テキトー教師設定が複数のスコープ(ユーザー・プロジェクト・マネージド)から来ている場合に、何が最終的に適用されているかを確認できます。設定ファイルにエラーがある場合も
/status で教えてくれます。オープンソースのサンドボックスランタイム:@anthropic-ai/sandbox-runtime
室谷あまり知られてないんですが、Claude Codeのサンドボックスランタイムがオープンソースとして公開されているんです。
テキトー教師@anthropic-ai/sandbox-runtime という npm パッケージです。これを使うと、Claude Code以外の自作エージェントや任意のプログラムを同じサンドボックス技術で隔離して実行できます。
室谷MCPサーバーのサンドボックス化に使うのが公式が推奨しているユースケースで、こんなコマンドで実行できます。
npx @anthropic-ai/sandbox-runtime <サンドボックスで実行したいコマンド>
テキトー教師MCPサーバーは外部ツールと連携するものなので、セキュリティリスクがあります。信頼できないMCPサーバーをサンドボックスで隔離して実行する、という使い方は理にかなっていますよね。
Anthropicが「AIエージェントコミュニティ全体がより安全なシステムを作れるように」という意図でオープンソース化したということです。
Anthropicが「AIエージェントコミュニティ全体がより安全なシステムを作れるように」という意図でオープンソース化したということです。
室谷この方向性、すごく重要だと思います。Claude CodeのAIエージェントとしての能力は上がっていく一方ですが、それに伴ってセキュリティの標準も引き上げていく、という姿勢が見えます。
MYUUUでも社内の自作エージェントにこのランタイムを使う検討をしているところです。
MYUUUでも社内の自作エージェントにこのランタイムを使う検討をしているところです。
サンドボックスのセキュリティ上の限界と注意事項
室谷ここまでサンドボックスのメリットと設定方法を話してきましたが、「何ができて何ができないか」の正確な理解も大事です。過信するのが一番危ない。
テキトー教師そうです。公式ドキュメントが「セキュリティの限界」というセクションを明示しているのは、ちゃんと理解した上で使ってほしいというAnthropicのメッセージだと思います。
室谷主な制限事項をまとめると、こうなります。
| 限界・注意事項 | 詳細 |
|---|---|
| ネットワーク検査は行われない | プロキシはドメインを制限するが、HTTPS通信の内容は検査しない |
| ドメインフロンティングの可能性 | github.com のような広いドメインを許可すると、サブリソース経由でデータが漏洩する可能性 |
| Unixソケットの危険性 | docker.sock などを許可すると実質的にサンドボックスが突破される |
| Linuxの弱いモード | Docker環境ではWeakerNestedSandboxが必要で、セキュリティが低下 |
| Bashコマンドのみが対象 | Read/Edit/Writeツールはパーミッションシステムで管理。サンドボックスの対象外 |
| Computer useは非対応 | Claude Codeが画面操作をする場合は実際のデスクトップ環境で実行される |
テキトー教師「ネットワーク分離はドメインレベルでの制限」という点が重要ですね。
ドメインを広く開けるほど、その中でのリスクは上がります。
github.com を許可すれば、GitHub経由で悪意のあるコードを取得する可能性はゼロではない。ドメインを広く開けるほど、その中でのリスクは上がります。
室谷だからこそ「始めは制限的に、必要に応じて広げる」というアプローチが推奨されているんです。最初から github.com を全部許可するのではなく、実際に必要なエンドポイントだけを許可する、という考え方です。
テキトー教師「claude code sandbox settings」を調べている方、この観点は絶対に押さえてほしいですね。設定の方法だけでなく、何がカバーされて何がカバーされないかを理解した上で設定を組む。
サンドボックスがカバーしない領域
室谷サンドボックスはbashコマンドとそのサブプロセスに適用されます。Claude Codeの他のツールは別の仕組みで管理されています。
テキトー教師整理するとこうです。
| ツール | セキュリティ管理の仕組み |
|---|---|
| Bashコマンド | サンドボックス(ファイルシステム・ネットワーク分離) |
| Read / Edit / Writeツール | パーミッションシステム |
| WebFetchツール | パーミッション + 独立したコンテキストウィンドウ |
| MCPツール | パーミッション + ユーザーによる信頼設定 |
| Computer use(画面操作) | 実際のデスクトップで実行(サンドボックス外) |
室谷つまり「サンドボックスを有効にすればOK」ではなく、ReadツールやEditツール、WebFetchのパーミッション設定も別途きちんと管理する必要があります。「多層防御」という考え方ですね。
テキトー教師パーミッション設定については、Claude Codeの
/permissions コマンドや settings.json の permissions.allow / permissions.deny で管理できます。サンドボックスとパーミッションを組み合わせることで、より包括的なセキュリティが実現します。Claude Code Sandboxの実践的な設定例
室谷ここからは実際の設定例を紹介しましょう。ユースケース別に「こういう設定がいい」という例を見せた方がわかりやすいと思います。
テキトー教師ですよね。抽象的な説明だけだと「結局どう設定すればいいの?」ってなりますから。
個人開発者向けの標準設定
室谷個人で使う場合のシンプルな設定です。
~/.claude/settings.json に書きます。{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": ["~/.ssh", "~/.aws/credentials", "~/.aws/credentials*"]
},
"network": {
"allowedDomains": [
"github.com",
"*.npmjs.org",
"api.anthropic.com",
"pypi.org",
"*.pypi.org"
]
}
}
}
テキトー教師SSHキーとAWS認証情報の読み取りをブロックしつつ、よく使うサービス(GitHub、npm、PyPI)へのアクセスは許可する設定です。これが個人利用の出発点としては適切だと思います。
室谷ネットワーク設定は「使うたびに追加」で育てていくのがいいですよ。最初からすべてを許可リストに入れようとするのではなく、実際に使って「このドメインへのアクセスが必要」となったときに追加する。
チーム・プロジェクト向けの設定
テキトー教師プロジェクトで使う場合、プロジェクトルートの
.claude/settings.json に設定を入れます。チームメンバー全員が同じ設定でスタートできます。
室谷こんな感じになります。
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"failIfUnavailable": false,
"excludedCommands": ["docker *"],
"filesystem": {
"allowWrite": ["/tmp"],
"denyRead": ["~/.ssh", "~/.aws"]
},
"network": {
"allowedDomains": [
"github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com"
]
}
}
}
テキトー教師dockerをexcludedCommandsに入れているのは実用的ですね。Dockerを使うプロジェクトでサンドボックスを有効にすると、docker コマンドが動かなくなることがあるので。
室谷/tmp への書き込みを許可しているのも重要です。多くのツールが一時ファイルを /tmp に書くので、これがないと予期せぬエラーが起きやすいです。エンタープライズ向けの厳格設定
テキトー教師企業環境で「サンドボックスなしは禁止」という場合の設定です。これはマネージド設定ファイルに入れます。
室谷マネージド設定の場所はOSによって異なりますが、
failIfUnavailable: true と allowUnsandboxedCommands: false の2つを入れることで「必ずサンドボックスが動いている環境でしか使えない」という強制ができます。{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false,
"filesystem": {
"denyRead": [
"~/.ssh",
"~/.aws",
"~/.gcp",
"~/.azure",
".env",
".env.local",
".env.production"
]
},
"network": {
"allowManagedDomainsOnly": true,
"allowedDomains": [
"company-internal-domain.com",
"github.com",
"*.npmjs.org"
]
}
}
}
テキトー教師.env や .env.local などの環境変数ファイルをdenyReadに入れているのが実践的ですね。これらにはAPIキーやパスワードが入っていることが多いので。
室谷allowManagedDomainsOnly: true にすることで、開発者がローカルで追加のドメインを許可することができなくなります。会社が管理するドメインリストだけが有効になる。Claude Code Sandboxとクラウド実行の違い
室谷「Claude Code on the Web」というクラウド版のサンドボックスについても触れましょう。ローカルのサンドボックスとはまた別の話なんです。
テキトー教師クラウド版では、各セッションが独立した仮想マシン上で動きます。Anthropicが管理するVMで、デフォルトではネットワークアクセスが制限されています。
室谷ローカル版との主な違いはこうなります。
| 項目 | ローカルサンドボックス | クラウド実行 |
|---|---|---|
| 実行場所 | ユーザーのマシン上 | AnthropicのVM |
| 隔離の仕組み | OS(Seatbelt/bubblewrap) | 仮想マシン |
| 設定の管理 | ユーザーまたはマネージド設定 | Anthropicが管理 |
| コードの保存先 | ローカル | クラウドVM |
| GitHub認証 | 通常のGit設定 | スコープ付きクレデンシャル経由 |
| 監査ログ | ローカルに記録 | 自動的にログ保存 |
テキトー教師リモートコントロールセッション(Web UIからローカルのClaude Codeを操作する場合)はまた別で、これはクラウドVMではなくユーザーのローカルマシンで実行されます。TLSでAnthropicのAPIを経由するだけで、コード実行は完全にローカルです。
室谷この使い分けを理解しておくのは重要ですよね。「クラウドで実行してる」と思ったらローカルだった、またはその逆、というケースで誤ったセキュリティ認識が生まれることがある。
よくある質問(FAQ)
テキトー教師コミュニティのメンバーさんからよく来る質問をまとめましょう。
室谷「サンドボックスを有効にしたら速度は落ちますか?」というのが最初によく聞かれます。
テキトー教師公式ドキュメントによると「最小限のオーバーヘッドはあるが、一部のファイルシステム操作がわずかに遅くなる程度」と書いてあります。体感できるほどの速度低下はほとんどの場合ないですね。
講座のメンバーさんでも「遅くなった」という報告はほとんど来てないです。
講座のメンバーさんでも「遅くなった」という報告はほとんど来てないです。
室谷「npmインストールがサンドボックス内で失敗する」という質問も多いです。
テキトー教師これはネットワーク設定の問題であることが多いです。npmはデフォルトで
registry.npmjs.org にアクセスしますが、ここをallowedDomainsに追加してないとブロックされます。*.npmjs.org を追加すれば解決することが多いです。
室谷「git pushがサンドボックス内でできない」というケースもあります。
テキトー教師これもネットワーク設定です。
github.com を許可リストに入れるか、GitHubのSSHアクセスを使っている場合はSSHソケットの設定が必要になることがあります。
室谷「claude code sandbox command」について質問する方、多いです。これは
/sandbox コマンドのことで、有効化のメニューが開きます。/sandbox on や /sandbox off というコマンドは現時点では存在しないので注意です。
テキトー教師「サンドボックスを無効化したい」という相談もあって・・・その場合は
/sandbox でメニューを開いて「Disable sandbox」を選ぶか、settings.json で enabled: false にします。ただし本当に無効化が必要な場面は少なくて、excludedCommands で特定のコマンドだけ除外する方が適切なケースが多いです。
室谷「claude code sandbox mode」という言葉で混乱している方もいますよね。Auto-allowモードとRegular permissionsモードの2つがあって、どちらもサンドボックスは有効です。
「モード」はサンドボックス内のコマンドをどう承認するか、の違いです。
「モード」はサンドボックス内のコマンドをどう承認するか、の違いです。
テキトー教師「claude code sandbox runtime」というのはさっき紹介した
@anthropic-ai/sandbox-runtime のことですね。Claude Code自体のサンドボックスの話ではなく、外部エージェントやMCPサーバーを隔離実行するためのパッケージです。前回の記事・関連記事
室谷サンドボックスと合わせて理解しておきたいのがパーミッション設定ですね。サンドボックスはbashコマンドの隔離を担当しますが、ReadやEditツールはパーミッションで管理されます。
テキトー教師権限管理の全体像を理解したい場合は「」も合わせて読んでほしいです。サンドボックスとパーミッションの使い分けが整理できると思います。
室谷セキュリティ全般については「Claude Code Security」の記事も参照するといいですね。SOC 2やISO 27001の認証、プロンプトインジェクション対策の仕組みなど、より広い視点でセキュリティを解説しています。
まとめ
テキトー教師今回はClaude Code Sandboxの全体像を解説しました。重要なポイントをまとめると、こうなります。
室谷まとめましょう。
- サンドボックスはbashコマンドのファイルシステム・ネットワーク分離を担当する。ReadやEditツールはパーミッションシステムで別途管理する
- OSレベルの強制なので、Claude Code自身もバイパスできない。すべての子プロセスに制限が適用される
- macOSはすぐ使える(Seatbelt)。LinuxとWSL2はbubblewrap + socatのインストールが必要
- Auto-allowモードが推奨。サンドボックス内のコマンドは承認不要になり、生産性が上がる
- settings.jsonの配列設定はマージされる(上書きではなく結合)。各スコープで追加していく
- docker、watchmanはexcludedCommandsに入れると互換性の問題が解決しやすい
- サンドボックスは「完璧な防御」ではなく、リスクを限定する道具。パーミッション設定と組み合わせて多層防御を実現する
テキトー教師設定の始め方として「まず有効化してAuto-allowモードで動かす → 問題が出たら
excludedCommands や allowWrite で調整する → 慣れたら denyRead で機密ファイルを守る」という段階的なアプローチが現実的だと思います。
室谷MYUUUのエンジニアへの導入でも同じようにやりました。最初から完璧な設定を目指すより、まず動かしてから育てる方が続きます。
Claude Code sandboxingは「セキュリティと生産性のトレードオフを解消する」という設計思想で作られているので、うまく使うと本当に両立できますよ。
Claude Code sandboxingは「セキュリティと生産性のトレードオフを解消する」という設計思想で作られているので、うまく使うと本当に両立できますよ。
