はじめに
AIエージェントにちょっと長めのタスクを任せたいとき、承認ボタンを何度も押すのが地味につらくなってきます。夜に投げて、朝に結果だけ見たい、そう思う瞬間はありませんか？
そこで出てくるのが --dangerously-skip-permissions のような「承認を全部スキップする」オプションですが、名前のとおりホストのファイルや認証情報に手が届く状態で、エージェントが自由にコマンドを打つことになります。
さすがにそのままホストで動かすのは怖いです。
そこで今回は、AIエージェントを microVM の中に閉じ込めて動かす Docker Sandboxes（CLI 名は sbx） を手元の Mac で試してみました。
エージェントには Google の Antigravity CLI（agy） を使っています。
検証した環境は、sbx v0.48.0 と v0.50.1、Antigravity CLI 1.4.8 です（2026 年 10 月）。
Docker Sandboxes（sbx）とは
名前に Docker と付いていますが、Docker Desktop の機能ではありません。
Homebrew で入る独立した CLI で、Docker Desktop は不要ですがDocker アカウントでのサインインは必要になります。
Rancher Desktop を入れている環境にもそのまま並べて入れられました（sbx のデーモンが動いている間も、Rancher 側の docker ps は変わりませんでした）。
やっていることはシンプルで、AI エージェントをサンドボックスごとに専用の microVM の中で動かします。
なぜコンテナではダメなのか
「Docker コンテナに入れれば十分では？」と思うかもしれません。ただ、コンテナは同じ VM のカーネルを共有していて、ネットワークの面でもホストに届いてしまいます。
実際に Rancher Desktop の普通のコンテナから、host.docker.internal 経由で、ホストの 127.0.0.1 で待ち受けているサービスに届きました。
仮に承認を外したエージェントが同じことをやれば、ホストで動いているサービスに届きます。ポートを閉じたりファイアウォールで塞いだりすれば防げますが、ホストで動いているサービスを自分で洗い出して、1 つずつ塞ぐことになります。
試しに同じ接続を sbx のサンドボックスの中から試すと、プロキシが 403 で遮断して、Approval required for localhost:5999. と表示されました。
通信はすべてホストのプロキシを通り、既定としては拒否となりますので通すには承認が必要になります。
全体構成
- ホスト側で
sbxCLI が常駐のsandboxd（デーモン）に指示を出すと、デーモンが microVM を起動して、通信を中継するプロキシ、ポリシーとシークレットの管理を担当します - microVM の中には独自のカーネルやエージェント、独立した Docker Engine が入ります。ワークスペースはホストから virtiofs でマウントされます
- 外向きの通信はすべてホストのプロキシを通り、許可したホストにだけ出ることができます
出典: Docker Sandboxes のセキュリティモデル
ライセンスと動作環境
気になる料金ですが公式 FAQ によると sbx とローカルのサンドボックスは商用利用を含めて無料です。
条件は Docker アカウントでサインインすることと、Apple Silicon の Mac（macOS 14 以降）などの対応環境であることです。
出典: Docker Sandboxes FAQ、インストール要件
インストールしてサンドボックスを作る
インストールは Homebrew コマンドなら一発で導入できます。
brew trust docker/tap
brew install docker/tap/sbx
sbx login
インストールが終わったらまずはsbx login で Docker アカウントにサインインします。
ネットワークのポリシーは、最初に一度だけ初期化しておきます。
sbx policy init balanced
ワークスペースの3つのモード
サンドボックスを作るときは、ホストのどのフォルダを見せるかを選ぶことができます。
ここが安全に運用するうえで一番大事なところになってきます。
| モード | 作り方 | 中の書き込み |
|---|---|---|
| 直接マウント | sbx create <エージェント> <パス> |
ホストにそのまま反映される |
| クローン | sbx create --clone ... |
ホストには反映されず、元は読み取り専用 |
| マウントなし | パスを省略 | ホストのファイルを持たない |
直接マウントだと、エージェントがワークスペースの中で消したファイルはホストでも消えてしまいます。
これが--clone なら元のリポジトリは /run/sandbox/source に読み取り専用でマウントされて、エージェントは VM の中のクローンで作業することができます。
なおサンドボックスの中でコミットしても、ホストの作業ツリーには現れませんでした。
よく使うコマンド
| コマンド | 内容 |
|---|---|
sbx create <エージェント> [パス] |
サンドボックスを作る |
sbx exec [-it] <名前> <コマンド> |
中でコマンドを実行する |
sbx ls / sbx stop / sbx rm
|
一覧、停止、削除 |
sbx policy |
ネットワークなどの許可・拒否 |
sbx secret |
API キーなどの認証情報を保存する。プロキシが代わりに使う |
sbx kit |
サンドボックスのカスタマイズ（Experimental） |
Antigravity CLI を入れる
組み込みのエージェントは sbx create --help で確認することができます。
claude、codex、gemini、copilot など主要なAIコーディングエージェントは入っていますが、Antigravity は入っていませんでした。
ただDocker Hub に公式の Kit が公開されていましたので、今回はそれを指定して作ります。
sbx create docker.io/sbx/antigravity-kit:latest . --name agy-try
初回の作成では、Kit が Google の API キーを使うという以下のような確認が表示されます。
google: API key sent to generativelanguage.googleapis.com (not set)
Kitの中には agy、node、git、docker が入っていて、ユーザーは agent として利用します。
作成直後は未ログイン状態ですので、対話形式で進めるためターミナルで実行してみます。
sbx exec -it agy-try agy
今回はGemini Enterprise のライセンスで入るので、ログイン方法は「2. Use a Google Cloud project」を選びます。
あとはブラウザで Google アカウントの認証をして、表示されたコードを貼りライセンスを選べば完了です。
表示に従って進めるだけですので詳細は省きます。
認証情報は VM の中のどこにあるのか
sbx はAPI キーなどの認証情報をホストのプロキシが HTTP ヘッダーに注入する設計で、生の値は VM に入らないと説明しています。
Antigravity で OAuth ログインした場合は実際にどこに保存されるのか、サンドボックスの中を調べてみました。
ログインの直後には~/.gemini/antigravity-cli/antigravity-oauth-token というファイルが作成されました（権限は 600）。
ファイルを退避するとagy は「Authentication required」と表示してログインを求めてきましたので、今回作成されたGoogle の OAuth トークンであることがわかります。
承認なしで動かしてみる
冒頭に「夜に投げて、朝に結果だけ見たい」と書いた通り、ほったらかしで実装を進められるか試してみました。
--sandbox --dangerously-skip-permissions を付けて、「Next.js でカンバンボードを作って、npm run build が通るまで直して、README を書いて、コミットして」と頼んでみます。
管理者設定を変えておく
と、その前に今回はGemini Enterpriseのライセンスでagyを利用しておりますので、コンソール上でセキュリティ設定を確認しておきましょう。
今回の検証のためだけに、Gemini Enterprise の管理者設定を変更しています。
Google Cloud コンソールの「Gemini Enterprise > 設定 > AI デベロッパー ツール」を開いて、「セキュリティ」の「ターミナル自動実行モード」を、「サンドボックスで続行」から「常に続行」に変更します。
この設定を変えないと承認スキップを付けても、ファイルの作成やコマンドのたびに確認が表示されます。
「常に続行」はsbx の microVM のような、隔離された環境で使う前提の設定です。
検証が終わったら、元の値（サンドボックスで続行）に戻しておきましょう。
確認なしで最後まで流す
同じプロンプトを送ります（ディレクトリ名は kanban）。
sbx exec -it agy-try agy --model gemini-3.8-flash-medium --sandbox --dangerously-skip-permissions
確認が 1 回も出ないまま、npm install、npm run build、README の作成、コミットまで完了しました。
途中の操作は読み取りから編集、コマンドを合わせて 50 件を超えていますが、特に確認メッセージも出ないまま終わっていることを確認しました。
できあがったアプリは、サンドボックスの中で起動して、ホストの 3100 番に公開して開いてみます。
別のターミナルで、サンドボックスの中のアプリを起動します。
sbx exec -it agy-try sh -c "cd kanban && npx next dev -H 0.0.0.0 -p 3000"
続けて、さらに別のターミナルで、ホストの 3100 番に公開します
sbx ports agy-try --publish 3100:3000
ブラウザで http://127.0.0.1:3100/ を開くと、アプリが表示されます。
コミットした内容はホストのリポジトリにも入りました。
なおワークスペースを直接マウントしているためで、--clone を使えばホストの作業ツリーには入ることはありません。
ホストに影響しそうなコマンドを打ってみる
確認なしで任せるということは、「エージェントが何をしても止まらない」ということでもあります。
そこで開発中によく打つコマンドで、ホストに届くかを試してみました。
agy の画面で ! から始めると、モデルを通さずに、サンドボックスの中のシェルで、そのまま実行できます。
今回実行したのは以下のコマンドです。
-
ls -a /Users/*/：サンドボックスの中の/Usersには、AGENTS.md、kits-agent-context、sbx-tryの 3 つしかなく、ホストのホームにあるほかのファイルは見えません -
curl http://host.docker.internal:8080/（ホストで動かしているローカルのサーバー）：プロキシがApproval requiredを返して届きません -
curl -I https://example.com（外部サイト）：プロキシが 403 を返します（出力の最後のHTTP/1.1 403 Forbiddenが、外部サイトへのリクエストへの応答です） -
docker ps：コンテナは 1 つも表示されず、ホストの Docker とは別のエンジンということがわかります -
echo "..." >> README.md（ワークスペースのファイル）：書き込みが完了してホスト側の README.md にも反映されました
破壊的な git 操作を試す
確認なしで任せるなら、エージェントが git reset --hard のような破壊的な操作を打っても、止まらないかもしれません。使い捨てのリポジトリ（4 コミット）をワークスペースに置いて、エージェントに実行させてみました。
赤枠がコマンドの出力です。git -C . reset --hard HEAD~1 も、bash -c "git reset --hard HEAD~1" も、そのまま実行できました。4 コミットが 2 コミットになり、ホスト側のリポジトリの履歴も、同じように動きました。
ワークスペースを直接マウントしていると、エージェントは、ホストのリポジトリの履歴まで書き換えられます。守りたいリポジトリは、--clone で使います。元のリポジトリは読み取り専用でマウントされるので、ホストの履歴は動きません。
--clone で、同じ操作を試した結果です。サンドボックスの中のクローンは reset されましたが、ホストの main は commit 4 のままで、エージェントの作業は、sandbox-<名前> というリモートのブランチとして別に見えます。
まとめ
今回はDocker Sandboxes（sbx）を使って Antigravity CLI を microVM に閉じ込めて動かしてみました。
sbx を使うと、ホストのホームの中身は見えず、ホストで動いているサービスや外部サイトへの通信は、プロキシで止まることを確認できました。公式 Kit を使えば、Antigravity も、この隔離された環境で動かせます。
AI駆動で開発をすることが多くなってきたと思いますが、セキュリティが特に重要視されている昨今、ぜひ普段の開発環境を見直してみてください。
この記事が、みなさまの安心・安全なAI駆動ライフの一助となれば幸いです。