Grandream

公開: 2026.08.2713 min read

Docker SandboxesとDev Containerは、隔離の強さが一段違う｜共有カーネルとハイパーバイザ境界

AIエージェントの開発をご検討中ですか？ AIエージェント開発サービスを見る →

Dev Container の中で暴走したプロセスは、ホストのカーネルを叩けます。Docker Sandboxes の中で暴走したプロセスは、ハイパーバイザの壁にぶつかって止まります。両者ともローカルの Docker で動き、エディタから見た使い心地も似ていますが、破られたときに何が起きるかは別の話です。

差が実務に効くようになったのは、コーディングエージェントを無人で走らせる人が増えたからです。人間が一手ずつ確認しているうちは、境界の強度はあまり問われません。--dangerously-skip-permissions を付けた瞬間、止めてくれるのは境界だけになります。

先に結論を書きます。自分たちで書いたコードを、人間が確認しながら触らせるなら Dev Container で足ります。無人で走らせる、あるいは自分でレビューしていないコードを触らせるなら、共有カーネルのままでは足りません。ただし microVM に移しても、ワークスペース越しにホスト側へコードを置いていく経路は残ります。実務ではここが一番見落とされます。

前提：似て見える二つは、そもそも設計目標が違う

Dev Container の仕様（containers.dev）が掲げる目的は、開発環境を「使いやすく、作りやすく、作り直しやすく」することです。仕様書のどこにも、隔離やセキュリティを目標として掲げた記述はありません。privileged、capAdd、securityOpt といったセキュリティ関連のプロパティは定義されていますが、これらは達成すべき保証ではなく、開発ワークフローのために開けられる設定の穴として並んでいます。

つまり Dev Container は、チーム全員に同じツールチェーンを配るための箱です。再現性のための道具であって、敵対的なコードを閉じ込めるための道具ではありません。

Docker Sandboxes は逆側から出発しています。2026年4月16日に公開されたこの製品は、AIコーディングエージェントのセッションごとに、起動の速い軽量な仮想マシン——microVM——を割り当てることを最初の設計要件に置いています。Docker 社の説明でも、「境界はエージェントが動き出す前にインフラ側で決まっていなければならず、システムプロンプトで決めるものではない」という立場が明示されています。

同じ Docker の上で動く箱でも、片方は開発体験のため、もう片方は封じ込めのために設計されている。この出発点の差が、そのまま隔離レベルの差になっています。

Dev Container の境界は、ホストのカーネルで終わる

カーネルを共有している

コンテナの隔離は、プロセスやファイルの見え方を分ける名前空間と、CPU やメモリの取り分を区切る cgroup という Linux の機構でできています。ファイルシステムもプロセスツリーもネットワークも分かれて見えますが、その下で動いているカーネルはホストと同一のものです。カーネルに脆弱性が見つかれば、コンテナの中から踏んでホストに抜けられます。

この性質は事故の防止には十分に働きます。rm -rf を打ち間違えてもホストのホームディレクトリは消えません。ただし、攻撃を止める壁として設計されたものではありません。「レビューされたコードには適切な境界だが、誰も読んでいないモデル生成コードに対して欲しい境界ではない」という表現が、この差をよく捉えています。

Dockerを使わせた瞬間に、境界は一行で崩れる

実務で隔離が壊れる最大の経路は、カーネルの脆弱性ではありません。開発者が自分で開ける穴です。

エージェントにコンテナのビルドや docker compose を任せたくなると、Dev Container の中から Docker を使う必要が出てきます。方法は二つあり、どちらも境界を壊します。コンテナの中で Docker デーモンを動かす Docker-in-Docker は --privileged を要求し、これを付けた時点で隔離の保証はほぼ失われます。もう一方の、ホストの /var/run/docker.sock をマウントして外側のデーモンを借りる構成は、もっと直接的です。ソケットに触れるということは、ホストの Docker に任意の命令を出せるということです。

docker run -it --privileged --pid=host -v /:/host alpine chroot /host

コンテナの中からこの一行を実行すると、ホストのファイルシステム全体が手に入ります。ソケットをマウントした Dev Container の隔離は、この一行分の厚みしかありません。

どうしてもソケットが必要なら、Docker API の呼び出しを仲介してコンテナ作成や exec を拒否するプロキシ（Tecnativa の docker-socket-proxy など）を挟む手はあります。ただし、これは穴を塞ぐ後付けの部品であって、Dev Container 自体が持っている性質ではありません。

ワークスペースは、ホストのファイルそのもの

Dev Container はリポジトリをバインドマウントで中に見せます。編集がそのままホスト側のファイルに反映されるのは利点ですが、書き込み権限もそのまま通っています。コンテナの中のプロセスは、ホスト上のリポジトリを直接書き換えられます。

Anthropic の Dev Container ドキュメントも、--dangerously-skip-permissions を使う場合について「Claude はバインドマウントされたワークスペース内のあらゆるファイルを変更でき、それはホスト上に直接現れる」と書いています。

中には資格情報が置いてある

実用的に使えば使うほど、コンテナの中には認証情報が集まります。Claude Code なら ~/.claude 配下の OAuth トークン、git の認証ヘルパー、SSH エージェントの転送、クラウドの資格情報ファイル。どれもエージェントが仕事をするために必要なものです。

そしてコンテナの外向き通信が自由なら、中で読めるものは外へ出せます。Anthropic の警告はこの点を正面から書いています。

Dev Container は相当な保護を提供しますが、あらゆる攻撃に対して完全に無防備でないシステムはありません。--dangerously-skip-permissions で実行した場合、Dev Container は悪意あるプロジェクトがコンテナ内でアクセスできるもの——~/.claude に保存された Claude Code の資格情報を含む——を外部へ持ち出すことを防ぎません。

対策として提示されているのが、外向き通信を既定拒否にする iptables ファイアウォール（init-firewall.sh）です。ただしコンテナの中でファイアウォールを動かすには NET_ADMIN と NET_RAW の権限を runArgs で追加する必要があり、隔離を強めるために権限を足すという構図になっています。

Anthropic 自身は、信頼できないコードを Dev Container に入れていない

Anthropic のサンドボックス選定ガイドは、目的別の推奨を表で示しています。「チーム内で環境を標準化したい」「無人で作業させたい」には Dev Container が挙がりますが、「信頼できないリポジトリで作業したい」の行だけは推奨が変わり、専用の仮想マシンか、Anthropic 管理の VM 上で動く Claude Code on the web が指定されています。

組織的な強制についても踏み込んだ書き方をしています。Dev Container をリポジトリにコミットするのは「強制の境界ではなく慣習」であり、Claude Code はコンテナを必須としないため、コンテナ外での実行を禁じたいならデバイス管理やソフトウェア許可リストで縛れ、という整理です。道具を作った側が、これは強制力のある壁ではないと明示しているわけです。

Docker Sandboxes は、ハイパーバイザで切る

セッションごとに専用カーネルを持つ

Docker Sandboxes は、サンドボックス1つにつき microVM を1つ立て、その中で専用の Linux カーネルを動かします。境界は、ハードウェア仮想化を担うハイパーバイザです。エージェントはVM内で sudo を含むフル権限を持ちますが、その権限はVMの内側でしか意味を持ちません。

Docker 社は Firecracker を使わず、独自の VMM（仮想マシンモニタ）を作っています。理由はクロスプラットフォームで、macOS の Hypervisor.framework、Windows の Windows Hypervisor Platform、Linux の KVM をひとつのコードベースから直接叩くためです。Firecracker は Linux/KVM 専用でクラウド基盤向けに最適化されているため、開発者のラップトップという要件には合わなかった、という説明になっています。

起動の速さは、この製品の実用性そのものです。従来の VM が起動に数十秒かかり、1台あたり4GB程度のメモリを食うのに対し、microVM は BIOS/UEFI のブートを飛ばしデバイスエミュレーションを削ることで、初回のイメージ取得を終えれば秒単位で立ち上がります。使い捨てのエージェントセッションを何十個も回す前提では、この差が「隔離を使うか、面倒だから省くか」の分かれ目になります。

VM の中に専用の Docker デーモンがある

Dev Container の最大の弱点だった Docker-in-Docker 問題は、ここで構造的に消えます。

サンドボックスはそれぞれ自分の Docker Engine を持ちます。エージェントが docker build、docker run、docker compose を打つと、コマンドはVM内部のデーモンに対して実行されます。ホストのソケットをマウントする必要も、--privileged を付ける必要もありません。デーモンごとVMの中に入っているので、そもそも外に出す穴が要らないという設計です。

隔離は目に見える形で効きます。サンドボックス1で hello-world を起動してから、サンドボックス2で docker ps -a を打っても、何も表示されません。互いのコンテナは見えず、ネットワーク的にも直接通信できません。

資格情報は、VMの中に入らない

APIキーの扱いは、Dev Container と設計思想が真逆です。ここではホスト側のプロキシが HTTP ヘッダにキーを注入します。資格情報の値そのものはVMに入りません。 エージェントはAPIを使えます。キーを読み出して持ち出す手段がありません。

外向き通信は既定拒否で、TCP はホスト側のプロキシを経由します。外部への UDP と ICMP はネットワーク層で遮断されています。

サンドボックスから到達できないものを、Docker 社は明示的に列挙しています。ワークスペースとスキルストアの外にあるホストのファイルシステム、ホストの Docker デーモン、ホストのネットワークへの直接アクセス、ネットワークポリシーで拒否された宛先、そして他のサンドボックス。境界を越えるのはワークスペースの変更、プロキシ経由の外向き TCP、共有スキルストアへの変更の三つだけ、という整理です。

導入の敷居も低く、macOS は brew install docker/tap/sbx、Windows は winget install Docker.sbx で入ります。Docker Desktop のライセンスは要りません。単体の無償製品として配布されています。

脅威ごとに並べると、差はカーネル・ソケット・資格情報・通信に出る

脅威	Dev Container	Docker Sandboxes
誤操作でホストのファイルを壊す	防げる（ワークスペース外）	防げる（ワークスペース外）
カーネル脆弱性を踏んでホストへ抜ける	防げない（共有カーネル）	ハイパーバイザ境界で止まる
Dockerソケット経由でホストを掌握	ソケットをマウントすれば一行で成立	経路が存在しない（VM内に専用デーモン）
資格情報の持ち出し	中に置いてあるので読める	値がVMに入らない
想定外の宛先への通信	既定は自由（ファイアウォールは自前で追加）	既定拒否・ホスト側プロキシ経由
ワークスペースのファイル改変	防げない（バインドマウント）	既定では防げない（後述）
隣の環境への横断	同一デーモン上のコンテナは見える	相互に不可視・通信不可

同じ結果になるのは、誤操作によるホストのファイル破壊と、ワークスペース内のファイル改変の2行だけです。残りは色が変わります。カーネルを共有しているか、ソケットという抜け道があるか、資格情報が境界のどちら側にあるか、外向き通信が既定でどちらに倒れているか。これが「一段違う」の中身です。

引っかかるのは、色が変わらなかった側です。ワークスペースのファイル改変は、ハイパーバイザで切っても防げていません。

microVM にしても、ワークスペース経由の実行は消えない

microVM の話は「ハイパーバイザで切ったから安全」で終わりがちですが、Docker 社自身のセキュリティドキュメントは、そう書いていません。

既定のモードでは、ワークスペースのディレクトリは読み書き可能でマウントされ、エージェントの編集はホスト側へ即時に反映されます。使い勝手のためにそうなっているのですが、Docker 社はこれを「暗黙の実行経路」と呼び、具体的に何が危ないかを列挙しています。エージェントが書き換えられるものの中には、git のフック、CI の設定、IDE のタスク設定、AIプロジェクトの設定ファイル、Makefile、package.json の scripts が含まれます。

これらは通常の開発作業で自動的に実行されます。ホスト側で git commit を打った瞬間、あるいはエディタがタスクを走らせた瞬間に、VMの中で書かれた内容がVMの外の権限で動きます。ハイパーバイザ境界は、実行時のプロセスは止めますが、境界を越えて置かれたファイルが後からホストで実行されるところまでは面倒を見ません。

緩和策は用意されていて、--clone を付けるとリポジトリは読み取り専用でマウントされ、エージェントはVM内の私的なクローンで作業します。ただしこれはオプトインです。既定では有効になっていません。

残るリスクとして、ドキュメントはほかに三つ挙げています。

エージェントの共有スキルストアは読み書き可能でマウントされるため、あるサンドボックスが他のサンドボックスのエージェントが読む指示を書き換えられます。サンドボックス間の隔離を謳いながら、ここには信頼の依存が残っています。次に、ローカルの MCP サーバーはホスト側で動きます。効くのはホストの権限で、サンドボックスの保護は境界の外にあるこのプロセスまで届きません。最後に、kit のインストールはサンドボックス内で root 権限のパッケージ導入として走り、供給網リスクは許可リスト（既定は Docker Hub）で抑えられています。

既定のネットワークポリシーも、そのまま信用しないほうがよい部類です。許可リストには *.googleapis.com のような広いワイルドカードが最初から入っています。管理者向けには、sbx policy ls で有効なルールを確認し、不要なものを削るよう促しています。既定拒否は既定拒否ですが、既定の許可リストは狭くありません。

どちらを選ぶかは、コードを信頼しているかで決まる

技術的な優劣で並べれば Docker Sandboxes の隔離が強いのは明らかですが、Dev Container が要らなくなるという話ではありません。二つは守っている対象が違います。

自分たちで書いたリポジトリで、エージェントの操作を人間が確認しながら進めるなら、Dev Container で足ります。環境の再現性という本来の価値はそのまま得られますし、init-firewall.sh 相当の外向き制限を足せば、資格情報の持ち出しという最大の懸念も実務上は抑えられます。この使い方でソケットのマウントだけは避ける、というのが現実的な線です。

無人で走らせる場合、あるいは自分でレビューしていないコードを触らせる場合は、判断が変わります。確認する人間がいない状態では、止められるのは境界だけです。ここで共有カーネルとホストの Docker ソケットを抱えたまま走らせる理由はありません。Anthropic のガイドが「信頼できないリポジトリ」の行だけ VM を指定しているのは、この線引きと同じ考え方です。

そして、どちらを選んだ場合でも、ワークスペースに置かれた package.json の scripts や git フックがホスト側で実行される経路は残ります。Docker Sandboxes なら --clone を明示的に付ける、Dev Container ならホストに戻したリポジトリを無検査で動かさない。ここは境界の強さでは解けず、運用で塞ぐ部分です。

まとめ：一段強い隔離を買っても、既定値は自分で締める

Dev Container の仕様は開発環境の再現性を目的に掲げており、隔離やセキュリティを目標として掲げていない。守れるのは事故であって攻撃ではない
Dev Container はホストとカーネルを共有する。実務で境界が壊れる最大の経路はカーネル脆弱性ではなく、/var/run/docker.sock のマウントと --privileged で、前者は一行のコマンドでホスト全体が取れる
Anthropic は自ら、--dangerously-skip-permissions 実行時に Dev Container は ~/.claude の資格情報を含む持ち出しを防がないと警告し、信頼できないリポジトリには VM を指定している。組織への適用も「強制の境界ではなく慣習」と位置づけている
Docker Sandboxes（2026年4月16日公開）はセッションごとに専用カーネルの microVM を立て、VM内に専用の Docker デーモンを持つ。ソケットのマウントも --privileged も不要になり、Docker-in-Docker 問題が構造的に消える。資格情報はホスト側プロキシが注入し、値はVMに入らない
ただし既定ではワークスペースが読み書き可能で直マウントされ、git フック・Makefile・package.json の scripts といった暗黙の実行経路がホスト側に残る。--clone はオプトイン。共有スキルストア、ホストで動くローカル MCP サーバー、広めの既定許可リストも残存リスクとして公式に挙げられている

隔離レベルの差は、境界をカーネルで切るかハイパーバイザで切るかという一点に集約されます。無人で走らせるならこの一段は買う価値があります。ただし買った後で最初にやることは、--clone を付けるかどうかを決めることと、sbx policy ls で既定の許可リストを削ることです。壁を厚くしても、既定で開いている扉は開いたままです。

参考にした一次情報