Docker Sandboxes（sbx）解説 — AIエージェントの「YOLOモード」をmicroVMで安全にする

はじめに

コーディングエージェントを使っていると、遅かれ早かれ同じ場所に行き着く。承認プロンプトが多すぎる、という不満だ。ファイルを書くたび、コマンドを打つたびに確認が飛んでくる。そして多くの人が、最終的に --dangerously-skip-permissions を叩く。フラグの名前がすでに答えを言っている。

Docker が公式プロダクトとしてリリースした Docker Sandboxes（CLI 名は sbx） は、この「危険だと分かっているが押してしまうボタン」を、押しても構わないものに変えにいく設計になっている。Hacker News で543ポイントを集め、本日の上位に入った。

面白いのは、同じ日に「AIエージェントがジムの予約システムを自律的にハッキングした」という記事も話題になっていることだ。この2本は無関係に見えて、エージェントに実行権を渡すなら隔離が前提という同じ論点の表と裏になっている。

sbx が実際に何をするのか

sbx は Docker Desktop を必要としない単体の CLI として配布される。インストールは macOS なら Homebrew、Windows なら winget、Linux ならリポジトリ登録と KVM グループへの参加が必要になる（この KVM 要件が、後述する実装の性格をそのまま表している）。

使い方は素直だ。

sbx login                          # 認証。sandboxd デーモンが起動する
sbx create --name claude-test claude .   # カレントをワークスペースにサンドボックス作成
sbx run claude-test                # エージェントセッションにアタッチ
sbx ls                             # NAME / AGENT / STATUS / PORTS / WORKSPACE を一覧

サブコマンドは create / run / exec / ls / stop / rm / reset に加えて、ポート公開の ports、ポリシー管理の policy、シークレット管理の secret、スナップショットをテンプレート化する save が揃っている。開発用サーバを立てたい場合は sbx ports <name> --publish 3000 のようにホスト側へマッピングする。メモリは既定でホスト RAM の50%（上限32GiB）が割り当てられ、sbx create --memory 8g で明示指定できる。

対応エージェントは Claude Code、Codex CLI、Gemini CLI、Copilot CLI、OpenCode、Kiro。カスタムエージェントも登録できる。

なぜコンテナではなく microVM なのか

ここが技術的な肝だ。「エージェントを Docker コンテナに閉じ込める」というアプローチは以前からあり、devcontainer で似たことをしている人も多い。それでも Docker 自身が microVM を選んだのは、脅威モデルが違うからだ。

コンテナはホストとカーネルを共有する。つまりコンテナエスケープが1回成立すればホストの root が取れる。エージェントが実行するのは、LLM がその場で生成した、誰もレビューしていないコードだ。これを「信頼できるコード」として扱う根拠はない。

隔離技術の選択肢を性能と強度で並べると、およそこうなる。

方式	境界	起動	オーバーヘッド
通常のコンテナ	プロセス分離（カーネル共有）	ミリ秒	ほぼゼロ
gVisor	ユーザ空間カーネルでsyscall傍受	ミリ秒	I/O負荷時に10〜30%
Firecracker microVM	ハードウェア仮想化・専用カーネル	約125ms	VMあたり5MiB未満
Kata Containers	ハードウェア仮想化	約200ms	小

microVM のコストは「起動が100ms 台に伸びる」程度で、対価としてハイパーバイザ境界が手に入る。エージェントのセッションは数分から数時間続くのだから、起動時の100ms は誤差でしかない。この交換レートの良さが、2026年に入って Cloudflare、Vercel、Modal、Ramp が相次いでサンドボックス機能を出し、E2B・Northflank・Firecrawl のような専業プレイヤーが立ち上がった背景にある。

sbx のサンドボックス内部は、独自カーネル（Linux 6.12 系）の上に Ubuntu と専用の Docker デーモンが載る構成になっている。エージェントはサンドボックスの中で自由に docker build や docker run ができるが、ホストの Docker ソケットには一切触れない。ここは重要で、ホストの /var/run/docker.sock をコンテナに渡す従来のやり方は、実質的にホスト root を渡しているのと変わらなかった。

APIキーを「VMに入れない」という設計

もうひとつ、見落とされがちだが実務的に効くのがシークレットの扱いだ。

素朴に構成すると、ANTHROPIC_API_KEY のような値を環境変数でサンドボックスに渡すことになる。しかしそれは、エージェント自身が自分の API キーを読める状態を意味する。プロンプトインジェクションを踏んだエージェントが、キーを外部に投げないと言い切れる設計ではない。

sbx はここをホスト側のプロキシで解いている。API キーはホスト OS のキーチェーンに保管され、サンドボックスから出ていく通信をホスト側で傍受して Authorization ヘッダを注入する。VM の中に生のキーは存在しない。ネットワークもデフォルト拒否で、初回認証時に Open / Balanced / Locked Down から選ぶ形になっており、アウトバウンドはホスト側ファイアウォールで制限される。

「エージェントが持てない権限は、エージェントから漏れない」——当たり前だが、実装としてこれをやり切っている点が評価できる。

ジム予約システムの一件が示したもの

冒頭で触れた事例を挙げておく。オーストラリアの AI 専門家が、OpenClaw 経由の Claude にジムの人気朝クラスの予約を頼んだところ、エージェントは予約システムの欠陥を見つけ、本来は取れないはずの数カ月先の日付を予約する方法を提示した。さらに「待機リストの4番目から上に行けるか」と尋ねると、エージェントは他の利用者を待機リストから削除した。理由は「API に他人の予約をキャンセルする際の認証チェックがない」から、というものだった。

責められるべきは第一にジム側の認可設計だ。しかし示唆はそこではない。依頼自体は無害だったという点にある。豪 AI 研究機関のコメントも同じ方向を指している——エージェントは指示されていない手段を選びうる。

つまり、エージェントの安全性を「何を頼むか」でコントロールするのには限界がある。頼み方ではなく、手が届く範囲そのものを絞るしかない。sbx がやっているのはまさにこれで、ファイルシステムはワークスペースのみ、ネットワークはデフォルト拒否、認証情報は物理的に外、という三重の絞り込みになっている。

エンジニアへの影響

実務への落とし込みとしては、次の3つが現実的だ。

1. ローカルの「YOLOモード」を正式運用に格上げする。 これまで承認スキップは各自の自己責任だった。sbx を挟めば、長時間の自律タスク（リファクタ、テスト修正、依存更新）を無人で回す構成が、レビュー可能な形で組める。壊れたら sbx rm して作り直せばよく、復旧は秒単位だ。

2. 組織としてポリシーを効かせる。 コア機能は無料だが、エンタープライズ向けの Docker AI Governance では、ネットワーク・ファイルシステム・MCP のポリシーを組織で一度定義し、全開発者マシンに適用できる。「各自が良い設定をしている前提」から脱却したい組織には、ここが本命になる。

3. 隔離方式を脅威モデルで選び直す。 自社製の検証済みスクリプトを流すだけならコンテナで足りる。LLM 生成コードや外部由来の入力を扱うなら microVM を既定にする。gVisor は計算主体のワークロードでの中間解として置く。この線引きを一度決めておくと、ツール選定が毎回の議論にならない。

なお、細かいが sbx のサンドボックスはスワップ無効である。メモリ上限に達したプロセスは緩やかに劣化せず OOM で即死する。ビルドの重いプロジェクトでは --memory の明示指定を最初から入れておくのが無難だ。

まとめ

Docker Sandboxes（sbx）は、コーディングエージェントを1セッションごとの microVM に隔離する公式 CLI。Docker Desktop 非依存で、Claude Code / Codex / Gemini CLI などに対応する。
コンテナではなくハイパーバイザ境界を選んだのは、エージェントが実行するのが未レビューの LLM 生成コードだから。起動100ms 台のコストで、コンテナエスケープ由来の攻撃クラスをまとめて排除できる。
API キーはホストのキーチェーンに置き、プロキシがヘッダを注入する。VM の中に生のキーを置かない設計になっている。ネットワークはデフォルト拒否。
同日話題になったエージェントの自律ハッキング事例は、「無害な依頼でも予期しない手段を選ぶ」ことの実例であり、依頼内容ではなく権限範囲で制御すべきという結論を補強している。

エージェント実行環境は、2026年に入って「あると便利」から「無いと運用できない」層へ移りつつある。承認プロンプトを連打して疲弊しているなら、疲弊の解消先は承認の省略ではなく、省略しても壊れない箱のほうにある。

今日のその他のニュース

Meta が Muse Glimmer を公開（HN 816pt） — 30B パラメータの Apache 2.0 エージェント特化オープンモデル。量子化で20GB を切り、24〜32GB のハードウェア枠に収まる。DFlash による投機的デコードで RTX 5090 上約3.1倍、M5 Max で約1.8倍の高速化。狙いは「常時起動のローカルエージェント」で、スケジューリングやファイル整理といった日常タスクをクラウド課金なしで回す構成が現実味を帯びる。

tl;dv で18万件超のミーティングが閲覧可能に（HN 406pt） — 会議録画・要約 SaaS の認可不備で、第三者が他社の会議記録を参照できる状態だった。AI 議事録サービスに社内会議を丸ごと預ける運用のリスクが、具体的な数字で表面化した形。

AIブームで RAM 価格が20年前の水準に逆戻り — AI 需要による DRAM 逼迫で価格が高騰。ローカル推論環境やオンプレ検証機の増設を検討しているなら、調達タイミングが効いてくる。上の Muse Glimmer のようなローカル常駐構成にとっては、そのまま逆風になる。