📘 HATENA BOOKMARK REPORT

AIエージェントのためのDocker Sandboxes実践入門

🔖 はてブ数: 123 📅 ブックマーク日時: 2026-07-18 04:05 (UTC) 🏷️ タグ: あとで読む

🔗 元記事 (Qiita) ↗ 📌 はてなブックマーク ↗ ✍️ 著者: minamijoyo

💡 TL;DR（3行で）

Docker社が開発中の「Docker Sandboxes（sbxコマンド）」は、AIエージェントをMicroVMレベルで強力に隔離するサンドボックス環境。

コンテナとは異なりカーネルを共有しないため、AIが生成した信頼できないコードを安全に実行可能。しかも現時点では無料で商用利用できる。

本記事は「やってみた」以上の情報が少ない中、著者が実際に使い込んで得たカスタマイズのノウハウを詰め込んだガチの実践ガイド。

1. Docker Sandboxesとは？

Docker社が開発中の AIエージェント向けサンドボックス機能。執筆時点ではまだ Experimental だが、Docker Desktop のライセンスなしでも無料で商用利用可能（ガバナンス機能の一部のみ有償）。

AIエージェント向けサンドボックスは、アーキテクチャレベルで大きく3種類に分けられる：

方式	仕組み	強度
① OSセキュリティ機能	macOSのApple SeatbeltなどでFS・NW制限（Claude Codeのサンドボックスモード等）	△
② Linuxコンテナ	名前空間の分離によるリソース制限。しかしカーネルを共有するためセキュリティ境界にはならない	△
③ MicroVM	スリム化した仮想マシン。カーネルを共有しない隔離。FaaS/CIの裏側でも採用	◎

      🔑 ポイント：Docker Sandboxes は ③ の MicroVM 方式を採用。dockerデーモンも共有しないため、AIエージェントに docker コマンドを許可しても影響をMicroVM内に閉じ込められる。シークレットは環境変数ではなくプロキシでHTTPヘッダに注入する設計思想も面白い。
    

2. 基本的な使い方

📦 インストール（Mac）

brew install docker/tap/sbx でサクッと入る。執筆時点のバージョンは 0.35.0。

🚀 起動の流れ

sbx login でDockerアカウントログイン（ブラウザでデバイス認証）
sbx run claude でAIエージェント起動（claude / codex などデフォルト組み込み済み）
初回はネットワークポリシーのプリセットを選択：
Open（全許可）Balanced（デフォルト拒否＋開発サイト許可）Locked Down（全拒否）
初回起動はVMイメージDLが入るので少し時間がかかる

🎯 dockerライクなコマンド体系

意図的にdockerコマンドに寄せているので、docker使いなら sbx --help を見れば勘で扱える：

sbx create / exec / ls / stop / rm — ライフサイクル管理
sbx cp — ホスト↔サンドボックス間のファイルコピー
sbx policy — ネットワーク/ファイルのポリシー管理
sbx secret — シークレット管理
sbx template — VMイメージテンプレート管理
sbx daemon — デーモン管理（調子が悪い時は再起動が効く）

3. カスタマイズの実践（本記事の本丸！）

1️⃣ YOLOモードをOFFにする

sbx run claude のデフォルトは claude --dangerously-skip-permissions という承認スキップ（YOLO）モード。Kitという仕組み（spec.yaml）で引数を上書きできる。これがカスタマイズの第一歩。

2️⃣ VMイメージを差し替える

必要なコマンドが足りない場合、ベーステンプレートイメージをFROMにしてDockerfileを書くだけ：

ベース: docker/sandbox-templates:claude-code-docker（Claude CodeのDockerあり版）
ビルド: docker build -t minamijoyo/ccbase ./sbx/kits/ccbase
罠：docker buildしたイメージはそのままではsbxから見えない。sbx template load <(docker image save ...) でローカル経由で読み込ませる（ネットpush/pull不要のハック）
ベースイメージのDockerfileは非公開だが、docker history --no-trunc で中身を読んでリバースエンジニアリングできる

3️⃣ モノレポで使う

リポジトリルートをマウントしないと .git/ がサンドボックス内から見えなくなる。sbx create はルートで、sbx exec は作業ディレクトリで実行するのが定石。

4️⃣ 環境変数を設定する

Dockerfileの ENV だと一部上書きされて効かない罠。/etc/sandbox-persistent.sh に書き込むと確実に反映（例：PS1のカスタマイズ）。起動時に差し込むなら sbx exec -e。

5️⃣ 設定ファイルを配布する

Kit内の files/home/ にファイルを置くと、サンドボックス内の $HOME(/home/agent) 下に自動配布。例：files/home/.claude/settings.json や files/home/.config/mise/config.toml。

6️⃣ 通信先を制限する（Policy）

ポリシープリセットを「Locked Down」にし、sbx policy allow network <domain> で許可ドメインを足していく。sbx policy log でブロック/許可状況を確認。Kitの network.allowedDomains にコードとして管理可能。

      💡 著者の気付き：普段意識しない多数の通信先を可視化できるので、CI/CDのEgress制限やマルウェア対策にも流用できる資産になる。
    

7️⃣ Mixin（オプショナル依存）

kind: mixin でオプショナルな依存を定義。--kit を複数指定して必要な時だけ追加適用。例：特定のCA証明書（CATO）をインストールするmixin。commands.install で作成時、startup で起動時にコマンド実行。

8️⃣ gh / aws / mise コマンドの導入

gh: デフォルトはv2.46.0で古い。Dockerfileで最新化推奨（Project v2 API対応にはv2.82.1+が必要）。GITHUB_TOKENは sbx secret でプロキシ注入。GitHub AppのDevice Flowで権限絞るのがオススメ。
aws: デフォルト未収録。署名が必要なため sbx secret 非対応。aws-vault経由で sbx exec -e で環境変数として渡す（セキュリティレベルはやや下がるがコンテナ時代と同等）。
mise: /etc/sandbox-persistent.sh にアクティベーションを仕込む。mise-versions.jdx.dev 等を許可リストへ。

4. 気になるポイント & 注意点

⚠️ まだ Experimental 扱いで、破壊的変更がカジュアルに入る。困ったら GitHub: sbx-releases をチェック。
⚠️ spec.yamlの仕様はバージョン1のままちょいちょい変わる。
⚠️ sbx exec --env-file は v0.35.0 時点で壊れている（そのうち直るはず）。
⚠️ .git/config の [user] が自動登録されるが、メアドをorgごとに使い分けている場合は設定箇所がなく課題。
📖 網羅的なコマンドリファレンスは未整備。公式Usage や sbx-kits-contrib が参考に。

5. まとめ

著者の結び：

      「とりあえず触れるファイルや通信先を制限できるだけでも圧倒的な安心感があるので、試してみてね。」
    

AIエージェントが生成したコードをその場で実行する時代において、コンテナ（カーネル共有）の危険性とMicroVM隔離の価値をハッキリ示した超実用的な記事。単なる「やってみた」ではなく、実運用でハマった罠と回避策まで詰め込まれた、これからDocker Sandboxesを触る人にとっての必読リファレンス。