7月4日、Collabnixが「Run an AI Agent Safely Inside MicroVM using Docker Sandbox: A Simple Step-by-Step Guide」と題した記事を公開した。この記事では、AIエージェントをMicroVM（Docker Sandbox）内に閉じ込め、ホストマシンを安全に保ちながら完全自律で動作させる手順について詳しく紹介されている。

「承認疲れ」と「野放し」の間にある第三の選択肢

Claude CodeやCodexを使い始めると、すぐに気づく問題がある。エージェントが「このコマンドを実行していいですか？」と聞いてくるたびに承認を求め、20分後には内容をろくに読まずにOKを押している——これが承認疲れだ。

その反動で確認を全部オフにすると、今度はSSHキー、クラウドの認証情報、ブラウザセッション、これまでcloneしたすべてのリポジトリにエージェントがアクセスできる状態になる。エージェントが読んだREADMEに悪意ある指示が一行混じっているだけで、すべてが危険にさらされる。

Docker Sandboxes（sbx） はこの二択を回避する。エージェントを完全自律で動かしつつ、「渡した1つのプロジェクトフォルダ」以外には一切触れさせないMicroVMの中に閉じ込める仕組みだ。

アーキテクチャを先に理解する

コマンドを打つ前に、全体像を把握しておきたい。

押さえるべき点は3つだ。

1. コンテナではなくVM。サンドボックスは独自のカーネルで起動する。分離境界はハードウェア仮想化であり、だからdocker psにすら表示されない（後述の手順で自分で確認できる）。

2. ホストと共有されるのは1つのフォルダだけ。指定したプロジェクトディレクトリのみがVM内にマウントされる。ホスト上の他のファイルは、エージェントの視点からは存在しない。

3. APIキーはVM内に入らない。キーはOSのキーチェーンに保管され、ホスト側のプロキシが転送中にアウトバウンドリクエストへ注入する。エージェントは生のキーを一切見ない。

動作環境

Docker Desktopと、Anthropic・OpenAI・GoogleいずれかのAPIキーが必要だ。

6ステップで動かす

Step 1：sbxをインストール

# macOS
brew install docker/tap/sbx

# Linux
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm

# Windows
winget install -e --id Docker.sbx

sbx version

バージョン文字列が表示されれば成功だ。

Step 2：ログインとネットワークポリシーの選択

sbx login

デバイスコードが発行されるのでブラウザで認証する。その後、ネットワークポリシーを選ぶ画面が出る。ここは読み飛ばさないこと。

1. Open        - すべてのトラフィックを許可
2. Balanced    - デフォルト拒否、一般的な開発サイトは許可
3. Locked Down - すべてのトラフィックをブロック

Balancedを選ぶ。このポリシーはVM外部、境界で強制される。エージェントはどんな手を使っても回避できない。npm、PyPI、GitHubへはアクセス可能だが、それ以外はデフォルトで遮断される。プロンプトインジェクションで操られたエージェントが外部にコードを送ろうとしても、越えられない壁に当たる。

Step 3：APIキーの安全な保管

ここがsbxの設計で最も重要な部分だ。

export ANTHROPIC_API_KEY=sk-ant-...
echo "$ANTHROPIC_API_KEY" | sbx secret set -g claude
sbx secret ls  # マスクされた状態でリスト表示される

キーはホスト側のOSキーチェーンに格納される。エージェントがAPIを呼び出すとき、リクエストはキーなしでサンドボックスを出て、ホスト側プロキシが転送中にキーを注入する。

エージェントは環境変数にも、コンテキストウィンドウにも、どこにもキーを持たない。完全に侵害されたエージェントでも盗むものがない——これが、APIキーをエージェントと同じ環境にexportする通常のアプローチとの根本的な違いだ。

なお、元記事ではClaude ProサブスクリプションユーザーはStep 3をスキップし、サンドボックス内から/loginで認証する方法も案内されている。

Step 4：プロジェクトを用意する

記事ではバグを意図的に仕込んだFastAPI + Next.jsのサンプルリポジトリが用意されている。

git clone https://github.com/dockersamples/sbx-quickstart ~/sbx-lab
cd ~/sbx-lab

このフォルダがエージェントの見える世界のすべてだ。

Step 5：サンドボックスを作成する

sbx create --name=sbxlab claude .

末尾の.は「このディレクトリをマウントする」という指示だ。初回はエージェントイメージのプルで1〜2分かかる。

mount policy deniedエラーが出た場合は、Docker組織でAI Governanceが有効になっており、ファイルシステムアクセスがデフォルト拒否になっている状態だ。組織管理者にパスのallow ruleを追加してもらうか、個人のDockerアカウントでsbx logout && sbx loginしてから再試行する。

※このエラー対応は元記事に記載のトラブルシューティング情報に基づく。

Step 6：実行する

sbx run sbxlab

初回起動時に「このディレクトリの内容を信頼しますか？」というプロンプトが出る。1を選択して続行だ。

あとはエージェントに指示を出すだけだ。

Explore this codebase and give me:
1. A summary of the architecture and tech stack
2. How to run it locally without Docker Compose
3. What the test suite covers
4. Any obvious issues or areas of concern

本当に分離されているか確認する

記事では「信じるな、確かめろ」というアプローチを推奨している。エージェントが動いている最中に、ホスト側で別のターミナルを開いて実行する。

docker ps    # サンドボックスはここに表示されない
sbx ls       # こちらには表示される（status: running）

SANDBOX   AGENT    STATUS    WORKSPACE
sbxlab    claude   running   /Users/ajeetraina/sbx-lab

docker psに出ないのはコンテナではないからだ。独自カーネルを持つVMだ。

さらに、ホスト側でエディタから~/sbx-lab内のファイルを編集して保存し、エージェントにそのファイルを読ませると、即座に変更が反映されている。コピーも同期ステップも不要——これが双方向マウントの実態だ。

リアルタイムの監視ダッシュボード

sbx

引数なしで実行するとライブダッシュボードが起動し、CPU・メモリ使用量が表示される。TabキーでNetworkパネルに切り替えると、サンドボックスが行ったすべてのアウトバウンド接続（許可・拒否を含む）がリアルタイムでログされる。

このネットワークログを眺めると、エージェントが何に接続しようとして、何が遮断されているかが一目でわかる。

何が実現されたか

この手順を踏むと、以下の状態が同時に成立する。

• エージェントは承認プロンプトなしで完全自律で動く
• SSHキー、クラウド認証情報、他のプロジェクトには設計上アクセス不可
• APIキーはエージェントの環境に一切存在しない
• すべてのネットワーク接続がデフォルト拒否ポリシーでフィルタされ、ログに残る
• エージェントが変更できるのは指定した1つのフォルダのみ

詳細はRun an AI Agent Safely Inside MicroVM using Docker Sandbox: A Simple Step-by-Step Guideを参照していただきたい。