Claude Code × Docker Sandbox 入門：--dangerously-skip-permissions を安全に使う

--dangerously-skip-permissions を使えば Claude Code の自律実行が格段に楽になる——そう感じながらも、「ホストマシンを壊したくない」という不安から踏み切れていないエンジニアは多いはずです。

ネット上には「ルートから rm -rf が走った」「設定ファイルを空にされた」という事故報告も残っており、慎重になるのは当然です。

かといって確認プロンプトに毎回応答する運用では、バッチ処理や大規模リファクタリングを夜間に任せることができません。

この問題を根本から解決するのが Docker Sandboxes です。Claude Code を microVM の中で動かすことで、--dangerously-skip-permissions を有効にしてもホストマシンへの影響をハイパーバイザーレベルで遮断できます。

本記事では、Docker Sandboxes の4層隔離の仕組み、macOS・Windows 両対応のセットアップ手順、実際の運用で気づいたハマりポイントを解説します。読み終わる頃には、不安なく Claude Code の自律実行を動かせる環境が整います。

執筆者

秋霜堂株式会社代表石川瑞起

中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。

なぜ Claude Code に隔離環境が必要なのか

Claude Code の --dangerously-skip-permissions フラグは、大規模リファクタリングやテストの自動実行を任せる際に避けて通れない選択肢です。しかし、このフラグをホストマシン上で直接使うのは大きなリスクを伴います。

`--dangerously-skip-permissions` が危険な理由

--dangerously-skip-permissions は、Claude Code がコマンド実行・ファイル操作・ネットワークアクセスを行う際の確認UIを完全にスキップします。フラグ名の「dangerously」は飾りではありません。

実際に報告されている事故の例を見てみましょう。2025年10月に起きたいわゆる「Wolak事件」では、あるエンジニアがファームウェアプロジェクトに取り組んでいた際、Claude Code がルート（/）から rm -rf を実行するという事態が発生しました（Hacker News スレッドで報告）。別の開発者は、設定ファイルを更新しようとした Claude Code が、バックアップを作らずに既存の設定ファイルを直接空白で上書きしたことを報告しています。

これらは --dangerously-skip-permissions をホストマシン上で直接実行したケースです。

でも、確認を止めたい理由もある

確認プロンプトを毎回承認する運用では、Claude Code の自律実行という本来の価値を活かせません。そこで登場するのが隔離環境という発想です。

解決策としての隔離環境

考え方はシンプルです。「ホストマシンは守りたい。でも隔離された環境の中では自由に動かしてほしい。」

この要求を満たすのが Docker Sandboxes です。Claude Code を隔離された microVM の中で動かすことで、--dangerously-skip-permissions を使ってもホストマシンには一切影響が及びません。

Docker Sandboxes とは？microVM による4層隔離の仕組み

Docker Sandboxes が提供するのは、通常のコンテナとは根本的に異なるレベルの隔離です。

microVM とコンテナの違い

Docker Sandboxes の各 sandbox は独立した Linux カーネルを持つ仮想マシンとして動作します。コンテナエスケープが起きた場合でも、ホストに到達するにはさらにハイパーバイザーエスケープという、はるかに難易度の高い突破が必要になります。

4つの隔離レイヤー

Docker Sandboxes は以下の4層構造で、エージェントの動作を隔離しています（公式ドキュメントより）。

第1層: ハイパーバイザー隔離

sandbox ごとに独立した Linux カーネルが起動します。ホストとの間にメモリ・プロセスの共有はありません。sandbox 内で何が起きても、ホストのプロセスに直接影響することはありません。

第2層: ネットワーク隔離

sandbox からのアウトバウンドトラフィックは全て、ホスト側のプロキシを経由します。設定したネットワークポリシーに反するアクセスはブロックされます（デフォルトは deny）。DNS クエリも同様にプロキシ経由となるため、ポリシー外のドメインには名前解決の時点でアクセスできません。

第3層: Docker Engine 隔離

各 sandbox は独自の Docker デーモンを持ちます。sandbox の中で docker コマンドを実行しても、ホストの Docker デーモンには接続されません。sandbox 間でイメージキャッシュも共有されません。

第4層: クレデンシャル隔離

API キーなどのクレデンシャルは、VM の中には入りません。ホスト側のプロキシが外部への API リクエストを検知し、認証ヘッダーを自動的に注入します。これにより、sandbox が侵害されたとしてもクレデンシャルが漏洩することはありません。

`--dangerously-skip-permissions` との2層構造

ここで重要な概念を整理しましょう。--dangerously-skip-permissions と Docker Sandboxes は別々のレイヤーで機能します。

┌─────────────────────────────────────────────────────┐
│  ホストマシン                                          │
│                                                      │
│  ┌─────────────────────────────────────────────────┐ │
│  │  Docker Sandboxes (microVM)                      │ │
│  │  ← ここがホストを守る「外壁」                       │ │
│  │                                                   │ │
│  │  ┌──────────────────────────────────────────────┐│ │
│  │  │  Claude Code                                  ││ │
│  │  │  --dangerously-skip-permissions               ││ │
│  │  │  ← VM 内での確認プロンプトをスキップする          ││ │
│  │  └──────────────────────────────────────────────┘│ │
│  └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘

--dangerously-skip-permissions は「VM の中での確認プロンプトをスキップする」フラグです
microVM がホストを守る「外壁」として機能しているため、VM 内でフラグを使うことは安全です
VM 内のファイルシステムが壊れても、sandbox を削除して作り直せば終わりです

セキュリティの限界も正直に伝えます

Docker Sandboxes を使っても、以下の点については注意が必要です。

VM 内に入った情報: sandbox の中に存在するファイル・データは sandbox 内で自由に扱われます。つまり、sandbox にマウントしたディレクトリの情報は、適切なネットワークポリシーがない限り外部に送信される可能性があります
信頼できないプロジェクト: マウントしたコードが悪意のある動作をする場合、VM 内ではそれを防げません
ネットワークポリシーの設定: ネットワーク隔離の強度は設定したポリシーに依存します。Open（制限なし）を選ぶと隔離の意味が薄れます

「ホストマシンが壊れない」「ホストのクレデンシャルが漏れない」という点については、Docker Sandboxes は強力な保護を提供します。

セットアップ手順

前提条件

OS	バージョン	アーキテクチャ
macOS	-	Apple Silicon (M1/M2/M3以降)
Windows	Windows 11 以上	x86_64

Linux は現時点で非対応です。Linux ユーザーの場合は後述の devcontainer をご検討ください。

その他の前提条件:

Docker アカウント（無料）
Claude の有効なサブスクリプション（Max, Team, Enterprise）または API キー

sbx CLI のインストールとログイン

macOS（Homebrew）:

brew install docker/tap/sbx
sbx login

Windows（winget）:

Windows では事前に HypervisorPlatform の有効化が必要です。管理者権限の PowerShell で以下を実行し、再起動してください。

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All

その後、sbx CLI をインストールしてログインします。

winget install -h Docker.sbx
sbx login

ネットワークポリシーの選択

sbx login の実行時にネットワークポリシーの選択が求められます。

ポリシー	説明	推奨シーン
Open	制限なし	非推奨（セキュリティが弱い）
Balanced	開発に必要なサービスを許可・それ以外はブロック	まずはここから
Locked Down	全トラフィックをブロック	セキュリティ最優先の場合

sandbox の起動

プロジェクトディレクトリで以下を実行します。

cd ~/my-project   # Windows: cd C:\Users\your-name\my-project
sbx run claude

起動後、sandbox 内で /login を実行して Claude のサブスクリプションでログインします（API キーを使う場合は後述の OAuth Proxy の項を参照）。

現在のネットワークポリシーは sbx policy ls で確認できます。開発中に特定のサービス（例: GitHub, npm レジストリ）へのアクセスが必要になった場合、確認プロンプトが表示され、許可すると以降そのドメインへのアクセスが有効になります。

実際に使ってみてわかったこと（ハマりポイント）

公式ドキュメントを読むだけでは分からない、実際の運用で気づいた点をまとめます。

sbx CLI と `docker sandbox` コマンドの違い

Docker Sandboxes を使う方法には2つあります。

	sbx CLI	docker sandbox コマンド
必要なもの	sbx CLI のみ	Docker Desktop 4.58 以降
機能範囲	フル機能	サブセット
公式推奨	はい	一部ユースケース向け

Docker Desktop をすでに使っている場合、docker sandbox コマンドでも基本的な操作は可能です。しかしsbx CLI の使用が公式推奨です。フル機能を使いたい場合は sbx CLI を選びましょう。

クロック同期問題（microVM 固有の問題）

microVM を使う際に遭遇しやすい問題の一つがクロックドリフトです。

microVM はホストのシステムクロックと独立しているため、VM 内の時刻がホストと徐々にズレていくことがあります。これが原因で、時刻に依存する処理（JWT の有効期限チェック、AWS 署名など）がエラーになることがあります。

回避策として、sandbox の起動スクリプトにクロック同期処理を追加することが有効です。たとえば、Google のサービスから現在時刻を取得してオフセットを計算し、Node.js の Date.now() をパッチする方法が実績のある対処法です。

複数起動時の Git インデックス競合防止（GIT_INDEX_FILE）

同じリポジトリに対して複数の sandbox を同時に起動する場合、.git/index ファイルへの書き込みが競合することがあります。

これを防ぐには、各 sandbox の起動時に GIT_INDEX_FILE 環境変数をプロセス固有の一時ファイルに向けるのが有効です。

# sandbox 起動時の環境変数設定例
GIT_INDEX_FILE=/tmp/git-index-$$

$$ はシェルのプロセス ID であるため、sandbox ごとに異なるファイルが使われます。これにより、複数の AI エージェントが同じリポジトリ上で並行作業しても Git インデックスの破損を防げます。

API キー不要で動く仕組み（OAuth Proxy）

sandbox 内で ANTHROPIC_API_KEY 環境変数に空文字を設定しても Claude Code が動く場合があります。これは Docker Sandboxes のクレデンシャル隔離の仕組みによるものです。

Docker Sandboxes のプロキシは、sandbox から外部への API リクエストを検知し、ホスト側で管理するクレデンシャルを自動的に注入します。そのため、VM の中にはクレデンシャルを渡さなくても認証が機能します。

# VM 内でのAPIキーは空でOK（proxyが自動注入）
ANTHROPIC_API_KEY=

この仕組みにより、sandbox 内を完全に侵害されてもAPIキーが漏洩しないという設計が実現されています。

devcontainer との使い分け

「devcontainer でも --dangerously-skip-permissions が使えると書いてあった。どう違うの？」という疑問はよく出ます。整理しましょう。

Docker Sandboxes が向いているケース

microVM レベルの隔離が必要な場合に最適です。

ホストマシンを絶対に壊したくない（個人 PC で実験的な作業をする場合など）
信頼度の低いコードやプロジェクトを扱う
--dangerously-skip-permissions で完全に自律実行させたい
macOS または Windows 単独環境で手軽に使いたい

devcontainer が向いているケース

チーム開発・再現性・Linux 対応が重要な場合に向いています。

Linux 環境での開発が必要（Docker Sandboxes は Linux 非対応）
チームで同一の開発環境を共有したい（devcontainer は全 OS 対応）
VS Code との統合を重視する
既存の CI/CD パイプラインと環境を揃えたい

選択フローチャート

Q1: Linux で作業しますか？
  → Yes: devcontainer を選択
  → No: Q2へ

Q2: ホストカーネルを共有せずに最高レベルの隔離が必要ですか？
  → Yes: Docker Sandboxes を選択
  → No: Q3へ

Q3: チームで環境を共有・再現性を重視しますか？
  → Yes: devcontainer を選択
  → No: Docker Sandboxes を選択（手軽さ優先）

セキュリティの強さで言えば、Docker Sandboxes（microVM）> devcontainer（コンテナ）です。ただし、どちらも「ホスト環境から分離して --dangerously-skip-permissions を安全に使える」という目的は達成できます。

注意点として、devcontainer は Anthropic が提供するリファレンス実装でも「信頼できるリポジトリでのみ使用することを推奨」と明記されています（公式ドキュメント）。Docker Sandboxes のほうが、信頼度の低いコードを扱う際により安全な選択肢です。

まとめ

Docker Sandboxes を使えば、--dangerously-skip-permissions は「dangerously」ではなくなります。

なぜ Docker Sandboxes が安全なのか:

microVM ごとに独立したカーネルを持つため、ホストへの影響がハイパーバイザーレベルで遮断される
ネットワーク・Docker Engine・クレデンシャルの各レイヤーでも独立した隔離が機能する
VM 内が壊れても、sandbox を削除して作り直せばよい

何に注意すべきか:

VM 内に入れた情報はVM内で扱われる（ネットワークポリシーは適切に設定する）
Linux は現時点で非対応（macOS / Windows のみ）
sbx CLI の使用を推奨（Docker Desktop 内蔵版はサブセット）

Claude Code に自律実行させる際の「不安」の大半は、適切な隔離環境を整えることで解消できます。Docker Sandboxes は、現時点でその要求に応える最も強力なソリューションの一つです。

毎日の
作業時間削減

人数

日数

新たなる挑戦へ

あなたの会社にシステム開発部門をご提供。
システム化を通して時間を生み出し、ビジネスの加速をサポートします。

詳しく見る

月額10万円から
システム開発が可能に

＼無料トライアル受付中！／