ガイド2026年4月5日

Claude Code Sandboxとは?サンドボックスの仕組みと有効化・設定方法を完全解説【2026年最新】

室谷東吾
監修者室谷東吾(@0x__tom

株式会社MYUUU 代表取締役 / 日本最大級AIコミュニティ「.AI」創設者(累計2,000名超)/ セプテーニ・ホールディングス(電通グループ)と資本業務提携 / 著書「お金を使わず、AIを働かせる『Dify』活用」(ぱる出版、3刷)/ Xフォロワー約2万人

テキトー教師
監修者テキトー教師(@tekitoo_T_cher

.AI 認定講師 / 教育×AIの専門家 / 累計300名以上にAI活用を指導 / 「テキトーに学ぶ」がモットーの実践派講師 / Xアカウント

Claude Code Sandboxとは?サンドボックスの仕組みと有効化・設定方法を完全解説【2026年最新】

Claude Code Sandboxとは?サンドボックスの仕組みと有効化・設定方法を完全解説【2026年最新】

室谷室谷
今回はClaude Codeのサンドボックス機能について話しましょう。正直、これを知らないでClaude Code使ってる人、かなり多いんですよね・・・
テキトー教師テキトー教師
ですよね。.AI(ドットエーアイ)のコミュニティのメンバーさんに「サンドボックス有効にしてますか?」って聞くと、8割くらいの方が「知らなかった」って言うんです。

Claude Codeの機能の中で最もスルーされがちなのがサンドボックスだと思いますよ。
室谷室谷
MYUUUのエンジニアに全員有効化させてるんですが、一度有効化すると「なんで今まで使ってなかったんだろう」って言うんですよw セキュリティが上がるだけじゃなく、実は承認の手間が減って生産性も上がるんですよね。
テキトー教師テキトー教師
その「承認が減る」という点、最初は直感に反するんですよ。セキュリティを強化したら制約が増えるはずなのに、なぜ楽になるのかって。

そこから入ると理解しやすいですね。
室谷室谷
整理するとこういうことです。通常のモードでは、Claude Codeがbashコマンドを実行するたびに「許可しますか?」って聞いてくる。

これが積み重なると「承認疲れ」が起きて、よく読まずにOKを押してしまう。サンドボックスは最初に「ここまでの範囲でやっていいよ」という境界を定義することで、その範囲内ではいちいち聞かなくて済む設計なんです。
テキトー教師テキトー教師
「事前に範囲を決める」という発想の転換ですよね。Claude Codeの公式ドキュメントにも「毎回承認を求めるより、境界を最初に定義する方がセキュリティ的に優れている」と書いてあって、実際にその通りだと思います。

Claude Code Sandboxとは何か:サンドボックスの概念と役割

室谷室谷
まず「そもそもサンドボックスとは何か」という話からしましょう。サンドボックスというのは、プログラムの動作範囲を制限する隔離環境のことです。

「砂場」のイメージで、砂場の中で遊んでいいけど外には出られない、という感じです。
テキトー教師テキトー教師
Claude Codeの場合、具体的には2種類の制限を実装しています。ひとつは「ファイルシステムの分離」、もうひとつは「ネットワークの分離」です。

この2つがセットで動いて初めてサンドボックスとして機能するというのが重要なポイントで、どちらか片方だけでは意味がないんです。
室谷室谷
そうなんですよね。ファイルだけ制限してもネットワークが自由なら、SSHキーを読み込んで外部に送信できてしまう。

逆にネットワークだけ制限してもファイルが自由なら、重要な設定ファイルを書き換えられてしまう。両方があってこそセキュリティが成立するんです。
テキトー教師テキトー教師
この点、コミュニティのメンバーさんが見落としやすいところです。「ネットワーク制限だけすれば安全でしょ?」って思いがちなんですが、公式ドキュメントにも明記されてますね。

「ネットワーク分離なしでは、侵害されたエージェントがSSHキーのような機密ファイルを外部に送信できてしまう」と。
室谷室谷
Claude Codeはそもそも何ができるか、という観点で考えるとより怖さがわかるんです。ファイルを読んで・書いて・bashコマンドを実行できる。

つまりシステムにアクセスできるユーザーと同等の権限を持っているわけです。
テキトー教師テキトー教師
そういう意味では「Claude Code sandboxing(サンドボックシング)」というのは、単なる機能の一つではなく、Claude Codeをチームや企業で安全に使う上での前提条件とも言えますね。
室谷室谷
MYUUUでは、新しいメンバーがClaude Codeを使い始める際に、まずサンドボックスの設定から入るようにしてます。後から設定するより、最初から適切な環境でスタートした方がいい。

Claude Code Sandboxingの公式ドキュメント概要ページ(Anthropic公式サイトより)

ネイティブサンドボックスの仕組み:OSレベルの制限

テキトー教師テキトー教師
Claude Codeのサンドボックスが強力なのは、OSのプリミティブを使っているからです。アプリレベルで「このコマンドはブロック」というソフトウェア制限ではなく、OSレベルで強制されるんです。
室谷室谷
これ、めちゃくちゃ重要なポイントですよね。OSレベルで制限されているということは、Claude Code自身が「バイパスしよう」と思ってもできない。

すべての子プロセスがサンドボックスの制限を引き継ぐんです。
テキトー教師テキトー教師
公式ドキュメントに記載されている、OS別の実装はこうなっています。
  • macOS: Seatbelt(AppleのサンドボックスフレームワークでmacOS標準搭載)
  • Linux: bubblewrap(namespacesベースの隔離技術)
  • WSL2: bubblewrap(Linuxと同じ)
  • WSL1: 非対応(必要なカーネル機能が不足しているため)

Claude Code Sandboxのアーキテクチャ図:サンドボックス境界・ファイルシステム分離・ネットワークプロキシの構成

室谷室谷
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は開発者のローカル環境と同等の権限を持って動作します。これはすごく強力なんですが、同時にリスクでもある。
室谷室谷
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の良さは「承認疲れを減らすこと」なので。
テキトー教師テキトー教師
講座でも「まず /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をインストールして /sandbox で有効化します。

注意点として、WSL1はサポートされていないので、WSL2を使うことが前提になります。
室谷室谷
WSL1とWSL2の確認は 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
室谷室谷
denyReaddenyWrite も重要です。逆に「ここだけはアクセスさせたくない」というパスを指定できます。
{
  "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 を追加しても、それ以外の設定は消えない。
室谷室谷
つまり各スコープは「追加」する。管理者がマネージド設定でパスを指定しても、開発者の個人設定のパスも維持される。

これは「より安全な方向」への配慮ですね。管理者が意図的に何かをブロックしたい場合は denyReaddenyWrite を使う必要があります。

ネットワーク分離の設定:allowedDomains・プロキシ設定

テキトー教師テキトー教師
ファイルシステムの次はネットワーク設定の話ですね。Claude Code sandboxのネットワーク分離は、プロキシサーバーを通じて実装されています。
室谷室谷
これ、仕組みが面白くて。サンドボックスの外側でプロキシが動いていて、サンドボックス内からのネットワークアクセスは全部そのプロキシを経由する。

プロキシが「このドメインは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コンテナがメインの隔離。その中で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の面白い設計として「エスケープハッチ」があります。サンドボックスが原因でコマンドが失敗した場合に、サンドボックスなしで再実行する仕組みです。
テキトー教師テキトー教師
名前がインパクトありますよね。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エージェントコミュニティ全体がより安全なシステムを作れるように」という意図でオープンソース化したということです。
室谷室谷
この方向性、すごく重要だと思います。Claude CodeのAIエージェントとしての能力は上がっていく一方ですが、それに伴ってセキュリティの標準も引き上げていく、という姿勢が見えます。

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.jsonpermissions.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: trueallowUnsandboxedCommands: 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.jsonenabled: 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モードで動かす → 問題が出たら excludedCommandsallowWrite で調整する → 慣れたら denyRead で機密ファイルを守る」という段階的なアプローチが現実的だと思います。
室谷室谷
MYUUUのエンジニアへの導入でも同じようにやりました。最初から完璧な設定を目指すより、まず動かしてから育てる方が続きます。

Claude Code sandboxingは「セキュリティと生産性のトレードオフを解消する」という設計思想で作られているので、うまく使うと本当に両立できますよ。

出典

.AI TIMES一覧に戻る