Docker Sandboxes (sbx) 実務導入ガイド — Dev Containers から乗り換える価値

導入と結論：Dev Containers から乗り換える価値はあるか？

AI コーディングエージェント自律実行時の課題

Claude Code や Codex などの AI コーディングエージェントを業務利用する際、自律的なコマンド実行やコンテナビルドをどこまで許容するかは、開発者や DevSecOps 担当者にとって悩ましい問題です。エージェントに自由度を与えすぎると、ローカル環境の破壊（ホスト汚染）や、~/.aws・~/.ssh といった機微ファイルの漏洩といったセキュリティリスクが生じます。

これまで、これらのリスクを軽減するための事実上の標準解として Dev Containers が使われてきました。しかし、実運用では /var/run/docker.sock をマウントしてコンテナ内からホスト側の Docker デーモンを操作させる構成が多く、「root 相当のホスト脱出口」を自分で開けているに等しい状態でした。

【結論】乗り換える価値と「隔離の線引き」

こうした課題に対する Docker 公式のソリューションが、Docker Sandboxes（CLI名 sbx） です。本記事の結論を先にお伝えします。

• 隔離の境界が microVM まで上がりました。 /var/run/docker.sock のマウントも、~/.aws のような機微ファイルの露出も構造的に消えます。Dev Containers から乗り換える価値は、この一点だけでも十分にあります。
• シークレットをエージェントから「隠す」層が加わりました。 ホスト側のプロキシが送信時に実値へ差し替えるため、キーそのものを VM 内に置かずに済みます。Dev Containers には存在しなかった、本質的な前進です。
• チームで「揃える」のは無料、「守らせる」のは有料です。 Kit をリポジトリで共有すれば設定は配布できますが、ルールを強制できるのは組織ポリシー（別サブスクリプション）だけです。
• 守るのは「ホスト」であり、「リポジトリ」ではありません。 ワークスペースは即時双方向で反映されるため、エージェントによるコードの破壊的変更や不正な Git コミットは防げません。

本記事では、sbx が Dev Containers の弱点をどう解決し、実運用においてどのような制約（限界）が残るのか、技術的な裏付けとともに解説します。

Docker Sandboxes (sbx) の基本構造と Dev Containers 3大弱点の克服

microVM によるエージェント専用ランタイムの仕組み

Docker Sandboxes は、単なるコンテナではなく「独立した microVM 境界（ハイパーバイザ隔離）」を用いた AI エージェント専用の隔離ランタイムです。 プロジェクトのディレクトリで sbx run claude のように実行すると、ホストカーネルとは分離された完全に独立した仮想マシン内でエージェントのセッションが立ち上がります。

この構造により、Dev Containers が抱えていた 3 つの構造的弱点がどのように解決されるのかを見ていきましょう。

弱点1を克服：カーネル共有と docker.sock マウントの排除

Dev Containers はホストと同一のカーネルを共有しており、エージェントにコンテナ操作を許可するためには /var/run/docker.sock のバインドマウントがほぼ必須でした。 対して sbx は、VM の内側に専用の Docker デーモンを持ちます。ホスト側のデーモンには一切触れることなく、エージェントは隔離された環境内で自由にコンテナのビルドや実行を行えます。Docker 自身も「コーディングエージェントにコンテナのビルドと実行を許しつつホストから隔離できる唯一のサンドボックス」と表現している通り、ホスト脱出の抜け穴が塞がれます。

弱点2を克服：ワークスペース限定マウントによる機微ファイルの保護

Dev Containers の運用では、利便性のためにホームディレクトリ全体をマウントしてしまったり、シンボリックリンク経由でホストの機密ファイルにアクセスできてしまう事故が起こりがちでした。 sbx は、ファイルシステムに対して 「ワークスペースのみ（Workspace-only passthrough）」 をホストと同一の絶対パスでマウントします。親ディレクトリは空の足場として用意されるだけで、ホストの実体は存在しません。また、外部を指すシンボリックリンクも辿れない仕様となっているため、~/.aws や ~/.ssh といった機微ファイルが意図せず露出する事態を原理的に防ぎます。

弱点3を克服：プロキシを介したシークレットの隠蔽

Dev Containers の最大の弱点は、コンテナ内に環境変数や設定ファイルとして API キーを配置してしまうため、エージェントから実値が丸見えになり、外部へ持ち出されるリスクがあったことです。 sbx はここに、「秘密をエージェントから隠す」という新たな層を追加しました。シークレットはホスト側の OS キーストア（macOS の Keychain、Windows の Credential Manager 等）に保管し、VM 内には**「センチネル値（ダミー文字列）」**のみを渡します。アウトバウンド通信を行う際に、ホスト側のプロキシがこれを実値へ差し替える仕組みです。

資格情報プロキシの仕組みと、その適用限界

センチネル置換方式（Sentinel replacement）とは

前述の通り、sbx はシークレット保護に「センチネル置換方式」を採用しています。 例えば、カスタムシークレットを次のように設定したとします。

sbx secret set-custom --host api.example.com --env API_KEY --value secret123

このとき、サンドボックス内の環境変数 API_KEY には sbx-cs-<ランダム文字列> というセンチネル値（ダミー）が注入されます。エージェントが指定されたホスト（api.example.com）宛てにリクエストを送信し、通信内容にこのセンチネル文字列が出現した場合にのみ、ホスト側のプロキシが実値（secret123）へと書き換えてから外部へ送信します。

「置換できない認証方式」には効かない

ここで押さえておくべきなのは、この仕組みが成立する前提です。センチネル置換は通信内容に現れた文字列を差し替えることで成り立っています。逆に言えば、キーそのものが通信に乗らない認証方式には原理的に適用できません。

代表的なのが署名型の認証です。この方式ではシークレットキーを通信に平文で含めず、リクエストの内容から署名を計算する鍵として使います。すると次の 2 点が同時に成立してしまいます。

1. 置換対象が存在しない: キーがリクエスト内に現れないため、プロキシには差し替えるべき文字列がありません。
2. 署名が破損する: 仮にプロキシが何かを書き換えたとしても、署名はリクエストのボディやヘッダを元に計算済みです。後から内容を変更すれば署名検証は必ず失敗します。

つまり「エージェントにキーを見せない」という sbx の利点は、ベアラートークンのように認証情報をそのままヘッダへ載せる方式に限って成立すると理解しておくのが正確です。

具体例として、AWS リソースへのアクセスで多用される AWS SigV4 はこの類型にあたります。公式ドキュメントに「非対応」との明言はありませんが、上記の理由から置換方式には載らないと考えられます。以降は、この SigV4 を題材に回避策を整理します。

置換できない認証を扱う回避策（AWS SigV4 の場合）

署名型の認証を使う環境で sbx を活用するには、以下のいずれかを選択する必要があります（推奨度順に記載します）。

A. Bedrock 経由であれば Bearer トークンを利用する 用途が Amazon Bedrock 経由での LLM 呼び出しに限定される場合、SigV4 ではなく Bedrock の Bearer トークンによる認証を利用すれば、文字列置換方式に乗せることができます。「キーを VM に一切入れない」という sbx の最大のメリットを維持できる唯一のアプローチです。

B. VM 内に短命な STS 資格情報を入れる（現実的な実務解） 「シークレットを VM に置かない」という理想は諦め、AWS STS（Security Token Service）によって発行した短命な一時的認証情報（AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN）を実値として VM 内に注入します。長期キーを晒していた従来よりは安全であり、TTL の制限と IAM スコープの最小化によって被害範囲を限定できます。

C. ホスト側に SigV4 署名プロキシを立てる awslabs/aws-sigv4-proxy のようなツールをホスト側で稼働させ、サンドボックスからは未署名のリクエストをホストプロキシ宛てに投げる方法です。ただし、サンドボックスからホスト側サービスへの到達性は執筆時点では発展途上であり、自作の検証が必要になります。

チームでの設定共有とガバナンス（Kit / 環境ファイル / 組織ポリシー）

ローカルポリシーの共有における課題

sbx では、sbx policy allow network <host> のように、CLI からアウトバウンドの通信許可（allow）や拒否（deny）を設定できます。しかし、これらのローカルポリシーは sbx デーモン内部で管理されており、具体的な保存ファイルパスは公式ドキュメントに公開されていません。つまり、そのままでは Git リポジトリ等を通じてチーム開発者に共有することができません。

チームで環境やセキュリティ基準を揃えるためには、性質の異なる 3 つのアプローチが存在します。

手段 A：無料で宣言的な「Kit (spec.yaml)」

リポジトリ内に spec.yaml を配置し、ネットワークの許可・拒否ルール、必要なパッケージのインストール手順、環境変数、起動コマンドなどを宣言的に記述します。

# spec.yaml の抜粋例
setup:
  install:
    - command: "apt-get update && apt-get install -y jq"

これを Git で共有することで環境の再現性を高められます。ただし、Kit の適用は開発者側の起動コマンド（オプション）に依存するため、利用を強制する力はない点に注意が必要です。

手段 B：環境ごと宣言する「.sbxenv.yaml」（実験的機能）

Kit よりも広い範囲を 1 ファイルにまとめたい場合は、環境ファイル（.sbxenv.yaml） という選択肢があります。使用するエージェント、ワークスペース、適用する Kit、環境変数、シークレット、レジストリ認証、公開ポート、リソース上限までを宣言し、リポジトリにコミットしておけば、他のメンバーは sbx env run で同一環境を立ち上げられます。共有設定とローカル上書きのために複数ファイルを合成したり、マシン固有のパスをホスト側の環境変数から参照することも可能です。

位置づけとしては Dev Containers の devcontainer.json に最も近い仕組みですが、執筆時点では v0.39 系のリリース候補に含まれる実験的機能です。ファイル形式やコマンド体系が変わる可能性があるため、本番の共有基盤として据えるのは時期を見たほうが無難でしょう。

手段 C：強制力を持つ「Organization Policy」

確実にポリシーを強制したい場合は、有料機能である Organization Policy（AI Governance） を利用します。 Docker Home（AI Platform）から一元管理を行い、ネットワークのアウトバウンド許可先や、ホストからのマウント許可パスを組織レベルで定義します。 重要な仕様として、組織ポリシーの allow だけが許可を与え、ローカルの allow ルールは無視されるようになります。開発者は「より厳しく絞る」ことはできても、組織の許可を超えて通信先を広げることはできなくなります。

整理すると、「チームで揃える」のは Kit（安定・無料）か .sbxenv.yaml（実験的・より広範囲）、「チームで守らせる」のは Organization Policy（有料）です。三者は排他ではなく、組織ポリシーで下限を敷き、日常の環境定義を Kit や環境ファイルで配る形が素直な運用になります。

テンプレートカスタマイズによる既定環境の運用

サンドボックスがブートする際の OCI イメージ（テンプレート）もカスタマイズ可能です。公式提供の docker/sandbox-templates:claude-code などをベースイメージとして独自のツールチェインを組み込み、リポジトリにプッシュして利用します。 Docker 自身が推奨する定石は、「重い依存関係を含んだテンプレートイメージ 1 枚」と「プロジェクト固有の薄い Kit」の組み合わせです。これにより、ツール更新のたびにイメージ全体をビルドし直す手間を省けます。

開発サーバーの起動とエディタ接続はどうなるか

Dev Containers から移行する際に最も気になるのが、「ランタイムのバージョンを揃えた環境で開発サーバーを起動し、ホストのブラウザやエディタから触る」という日常の開発サイクルが維持できるかどうかです。結論としては維持できますが、操作の入口が変わります。

サーバー起動には 3 つの経路がある

sbx では、サーバーの起動方法を用途に応じて選べます。

1. エージェントに任せる: サンドボックス内で Claude などがそのまま npm run dev を実行します。VM 内で完結するためホストは汚れません。
2. sbx exec で人間が叩く: sbx exec -it my-sandbox bash で対話シェルに入る、sbx exec -d my-sandbox npm start でバックグラウンド実行する、といった操作ができます。引数なしで sbx を実行するとダッシュボードが開き、各サンドボックスへの attach やシェル起動、停止をここから行えます。
3. Kit に宣言して自動起動する: spec.yaml の起動コマンドとして background: true を指定しておけば、サンドボックス作成時に常駐プロセスとして立ち上がります。

ポート公開は独立した操作として明示する

起動しただけではホストからアクセスできません。ポートのマッピングは別の操作として指定します。

sbx run --publish 8080:3000 claude          # 起動時に指定する
sbx ports my-sandbox --publish 8080:3000    # 稼働中のサンドボックスへ後から追加する

これでホストの localhost:8080 がサンドボックスの 3000 番へ繋がります。ここで サンドボックス内のサーバーは 0.0.0.0 にバインドする必要がある点に注意してください。多くの開発サーバーは既定でループバック（127.0.0.1）のみを listen するため、--host 0.0.0.0 相当のオプションを付けないとポートを公開してもホストから見えません。Dev Containers の自動ポートフォワードに慣れているほど、最初につまずきやすい箇所です。

エディタは SSH 経由で接続する

VS Code や Cursor から中を触る場合は、初回のみ sbx setup ssh を実行し、以降は ssh <サンドボックス名>.sbx で接続します。SSH 鍵やネットワークポートは使わず、ProxyCommand で sbx デーモンのローカルソケットを経由し、Docker ログインが有効な間のみ接続が許可される仕組みです。VS Code / Cursor に加えて Claude Desktop や ChatGPT からの接続にも対応しています。

なお、ランタイムのバージョンを揃える部分はテンプレートが担います。公式のベースイメージには Ubuntu・Git・GitHub CLI・Node.js・Go・Python 3 と主要なパッケージマネージャが同梱されているため、多くのプロジェクトは追加インストールなしで動きます。より厳密にバージョンを固定したい場合は、独自テンプレートにバージョン管理ツールを焼き込む形になります。

導入前に押さえるべき残存リスク（隔離の境界線）

「ホスト」は守れるが「リポジトリ」は守れない

ここまで解説した通り、sbx はホスト環境の保護においては極めて強力です。しかし、ワークスペース内のファイルに対しては無力であることを正しく認識する必要があります。

ワークスペースは双方向で即時同期されるため、エージェントがコードを破壊したり、誤った Git コミットやプッシュを行ったりした場合、それはホスト側のリポジトリにもそのまま反映されます。Git 側での防御策（別ブランチでの作業、Worktree の活用、プッシュ制限など）は、Dev Containers 時代と変わらず必須です。

ワークスペース直下の .env 露出とリソース消費

同じ理由から、ワークスペース直下に置かれた .env ファイルなどはファイルシステム隔離の対象外となり、エージェントから丸見えです。これらの情報が外部に送信されないよう、ネットワークの deny ポリシーで適切にガードする必要があります。

また、ホスト側の設定（例：~/.claude 内の MCP 設定など）は VM 内には引き継がれません。Kit などを通じてプロジェクトごとに再設定する運用が求められます。 さらに、microVM はプロジェクト単位で個別に立ち上がるため、Dev Containers に比べてディスクやメモリのオーバーヘッドが重くなる点にも留意してください。

まとめ：導入判断のためのチェックリスト

Docker Sandboxes (sbx) は、「AI エージェントに安全な自律実行環境を与える」という目的において、Dev Containers から乗り換える価値のある強力なソリューションです。 自チームでの導入可否を判断する際は、以下のチェックリスト（判断軸）を参考にしてください。

技術の仕組みと限界の「境界線」を正しく理解し、エージェントの力を安全に引き出す開発環境の構築に役立ててください。