Docker Sandboxes を
まず動かしてみる
sbx をインストールし、Claude Code や Codex を
「隔離された箱」の中で起動するまでを最短で進める。
1.なぜ必要か — エージェントに「全権」を渡す時代のリスク
AI コーディングエージェントは今や開発の主役級になった。Docker の 発表資料で引用された統計では、 開発者の 84% がコーディングエージェントを利用し、新規コードの 41% が AI 生成とされている。 調査の定義や母集団によって数字は変わるが、エージェントはファイル・シェル・ネットワークへ広く手を伸ばしながら動く。 便利な反面、確認を全部飛ばして任せる運用（いわゆる YOLO モード）を Mac 本体の上で直接やると、誤操作も攻撃もそのまま本体の被害になる。
📖 用語: YOLO モード
エージェントは通常、コマンド実行やファイル編集のたびに人間の承認を求めてくるが、
この確認をすべてスキップして全自動で走らせる運用の俗称（"You Only Live Once" から）。
Claude Code の --dangerously-skip-permissions、
Codex の --yolo（--dangerously-bypass-approvals-and-sandbox の別名）などが該当する。
自律的に長時間作業させる場面では使われやすく、確認疲れもあって常用されがちだが、
ホスト直接実行と組み合わせると誤操作や攻撃が一発でそのまま実害になる。
Docker Sandboxes は「YOLO モードの被害範囲を狭めるためのサンドボックス」と言い換えられる。
⚡ YOLO モードの常態化
確認プロンプトが煩わしいので claude --dangerously-skip-permissions のような
「全承認スキップ」で走らせがち。エージェントが出すコマンドが、そのまま Mac で実行される。
💉 プロンプトインジェクション
Web ページや Issue、依存パッケージの README に仕込まれた指示をエージェントが「命令」として実行してしまう。 Cursor の CVE-2025-54135 のように、実際に RCE につながった脆弱性も報告されている。
🔗 サプライチェーン攻撃
侵害された npm パッケージ（axios の事例など）を npm install した瞬間に、
Mac 上の認証情報（~/.aws、~/.ssh、ブラウザの Cookie…）が窃取されうる。
🔑 認証情報の漏洩
エージェントは API キーやトークンを環境変数・設定ファイルとして「見える」状態で扱うのが普通。 悪意ある指示ひとつで外部に送信されうる。
問題は「エージェントが優秀かどうか」ではなく、 信頼しきれない入力を食べながら、任意のコードを自分の全権限で走らせている という構造そのものにある。 Docker Sandboxes はその構造を断ち切る。エージェントを Mac 本体ではなく 軽い仮想マシン（microVM）の中に入れ、壊せる範囲・見える範囲・通信できる範囲を箱の境界で機械的に区切る。 YOLO モードで自律的に作業させつつ、タガを外したときの被害範囲をあらかじめ狭くしておく発想だ。 「エージェントを信用してタガを外す」のではなく、「タガを外したときの被害範囲を制限するサンドボックスに入れる」。 自律エージェントの時代に、安全の柵をエージェントの行儀ではなく実行環境そのものに移すのが Docker Sandboxes の意義だ。
🏢 AI ガバナンスの文脈での意義（組織向け）
Docker はこれを単体ツールではなく「AI ガバナンス」の 3 層戦略の一部として位置づけている （出典: Docker Sandboxes & AI ガバナンス）。 個人利用なら第 1 層だけで十分。以下の第 2・第 3 層は組織導入の話である。
- サンドボックス層 — ネットワーク（ドメイン/IP/CIDR の許可・拒否）とファイルシステム（読み取り専用 / 読み書き）を、 プロキシ層とマウント層で強制的に適用する。エージェントの「お行儀」に依存しない。
- MCP 層 — 組織で一元管理された MCP カタログ。未審査の MCP サーバーはデフォルトでブロックし、許可/拒否ポリシーで管理。
- チームポリシーと監査 — SAML/SCIM でポリシーを割り当て、SIEM に取り込める構造化イベントを出力。
CLI は現時点で Docker Desktop のライセンス不要・無料で使える（組織向けガバナンス機能は有料サブスクリプション）。
2.このページでやること
3.macOS へインストールする
準備：Docker アカウント
Docker アカウントを持っていなければ Docker の新規登録ページで作成しておく（無料）。
Docker Desktop のインストールは不要
組み込みエージェントを起動するだけなら Docker Desktop のインストールは不要。
例外は、独自テンプレートをホストで docker build するときだけ
（手順は応用を参照）。
Docker Sandboxes のインストール
Homebrew であれば、Docker Sandboxes のインストールは簡単。
$ brew trust docker/tap
$ brew install docker/tap/sbx
$ sbx versionsbx version: v0.35.0 ... のように表示されればインストール完了。
Docker アカウントでログイン
$ sbx loginブラウザが開いたら Docker アカウントで認証する。
Windows / Linux の場合
Windows は winget install -h Docker.sbx。
Linux（Ubuntu）は docker-sbx パッケージと、KVM が使えることが必要。
最新の要件は公式の Get
startedを参照する。
このサイトで詳しく検証しているのは macOS (Apple Silicon)である。
4.コーディングエージェントを動かす
インストールとログインが済んだら、作業したいプロジェクトへ移動して起動する。
$ cd ~/path/to/project
$ sbx run claude$ cd ~/path/to/project
$ sbx run codex
上のコマンドでは、作業ディレクトリとエージェントからサンドボックス名が自動的に決まる。
同じ場所でもう一度同じコマンドを実行すると、そのサンドボックスへ再接続する。
同じプロジェクトで複数のサンドボックスを使い分ける場合や、別の場所から特定のサンドボックスへ再接続する場合は、
名前で区別する必要がある。その場合は --name オプションを使う。
詳細はワークスペースの説明を参照。
初回だけ時間がかかることがある
初回起動ではテンプレートの取得と microVM の準備が走るため、ネット環境によっては数分かかることがある。
失敗したら sbx diagnose で常駐プロセスを確認し、通信がブロックされている疑いがあれば
sbx policy log を見る。足りない宛先は
sbx policy allow network … で足せる。
初回は、この Mac 上のサンドボックスに適用するネットワークの初期設定を聞かれる。 普段の開発なら、主要な開発サイトだけ通す Balanced から始めるのが分かりやすい。 選んだあと、エージェント本体のログイン（Claude / Codex など）を行う。
ネットワーク設定は後から変更できる
ネットワーク設定は後からでも変えられる。足りない接続先の許可や、不要な接続先の拒否は
sbx policy allow network … / sbx policy deny network …
で足せ、変更はすぐ効く。
何も付けなければこの Mac 上の全サンドボックス向け、
--sandbox <サンドボックス名> を付ければそのサンドボックス内だけ、と範囲を選べる。
Open / Balanced / Locked Down を丸ごと選び直すときは sbx policy reset を使う。
この操作はバックグラウンドの常駐プロセスと、動いているサンドボックスをいったん止める。
次に sbx を打つと常駐プロセスがまた立ち上がるので、作業の区切りで行うとよい。
⚠️ 最初に知っておくこと：通常はホストのフォルダに書き込む
デフォルトでは、いまいるディレクトリが箱の中に読み書きできる形で見える。
エージェントが直した内容は、Mac 側の作業ツリーにもすぐ現れる。
手元のエディタと一緒に進めるには便利だが、放置気味に走らせるときや、リスクの高い作業では
--clone を検討する。違いは
ワークスペースの選び方で説明する。
初回はエージェント本体の認証を求められる。ログイン状態や、箱の中で入れたツール、
取得した Docker イメージなどは、そのサンドボックスを sbx rm するまで残る。
Claude Code の公式テンプレートは、デフォルトで権限確認を省略する設定になっている （いわゆる YOLO 寄りの起動）。microVM は Mac 本体への被害を狭めるが、 渡したプロジェクトへの書き込みや、許可した通信先・渡した認証情報での外部操作まで止めはしない。
5.次に読む
🛠 使い方
直接マウントと clone の選び方、日常操作、ポート公開、箱の中の Docker など。
🧩 応用
Kit、独自テンプレート、環境変数・AWS、自律運用の型。
🧱 仕組み
なぜ microVM なのか、コンテナとの違いと多層隔離モデル。
🛡 安全性
ネットワークと認証情報の境界、守れるものと自分で締めるもの。
困ったときの最初の 3 コマンド
$ sbx diagnose # インストールと常駐プロセスを確認
$ sbx ls # 自動生成された名前と状態を確認
$ sbx policy log # ブロックされた通信を確認 → 足りなければ allow
diagnose で改善しなければ、常駐プロセスの再起動を試す:
sbx daemon stop && sbx daemon start -d
（フラグは sbx daemon --help で確認。sbx reset は状態をまとめて消す最終手段で、これとは別）。
--name だけで運用している箱は、素の sbx run claude では開かない（デフォルト名の箱が無ければ新規作成されてしまう）。
名前の衝突や再接続の罠は使い方の名前解決を参照。
Docker Sandboxes は Early Access で、破壊的な変更もあり得る。挙動が本文と違うときは
sbx version と
リリースノート
を確認する。