ハクソク

世界を動かす技術を、日本語で。

Dockerサンドボックス – AIエージェントのための使い捨てで隔離されたサンドボックス

2026年8月10日原文(docker.com)

概要

Docker Sandboxes は、AIエージェントのための使い捨て・隔離環境を提供。 Claude Code や Copilot CLI など主要なAIエージェントに対応。 安全性 と 自律性 を両立し、ホスト環境を守る設計。 高速な起動 と 簡単な破棄 で運用も容易。 Docker AI Governance による組織的なセキュリティ管理も可能。

Docker Sandboxes とは

  • AIエージェントを ローカルサンドボックス で安全に実行するためのソリューション
  • Claude Code、 Gemini CLI、 Copilot CLI、 Codex、 OpenCode、 Kiro などに対応
  • 各エージェントごとに 専用のmicroVM を割り当て、 プロジェクトワークスペース のみをマウント
  • エージェントは パッケージのインストール、 設定ファイルの変更、 Dockerコンテナの起動 などが可能
  • ホスト環境は完全に保護 され、手動レビューや許可プロンプト、監督不要

主な特徴

  • YOLOモード （--dangerously-skip-permissions）により、エージェントに最大限の自律性を付与
    • サンドボックスによる隔離で 安全性 を確保
  • microVM による強固な隔離
    • 従来のVMよりも 高速かつ軽量
  • 使い捨て設計 により、ワンクリックでサンドボックスを破棄可能
  • Dockerコンテナの内部利用 も可能
  • リアルな開発環境 で長時間・無人の作業を実現
  • 主要なAIコーディングエージェント すべてに対応

インストール方法

  • macOS
    • $ brew trust docker/tap && brew install docker/tap/sbx
  • Windows
    • > winget install Docker.sbx

なぜサンドボックスが必要か

  • エージェントに 安全な自律性 を与え、作業効率とセキュリティを両立
  • スピードと安全性 のトレードオフ解消
  • 組織全体 で統一されたセキュリティポリシーの運用が可能

管理機能とカスタマイズ

  • ネットワークやファイルシステムの制御 をユーザーが定義可能
  • Docker AI Governance による組織単位のポリシー強制
  • 管理者レベルの設定 やネットワークアクセス制限、ファイルシステムポリシーの追加

よくある質問（FAQ）

  • サンドボックスとは？
    • microVMによる 隔離環境 で、ファイルシステムやネットワークを保護
  • 対応エージェントは？
    • Claude Code、Gemini CLI、Copilot CLI、Codex、OpenCode、Kiroなど
    • 独自エージェント も作成可能
  • YOLOモードの安全性は？
    • 許可プロンプトなしでエージェントが動作
    • サンドボックス隔離により リスクを最小化
  • サンドボックスとVMの違いは？
    • microVMで 高い隔離性 と 高速起動 を両立
    • VMより 軽量かつ柔軟
  • Docker Desktopは必要？
    • 不要
  • 追加の管理機能が必要な場合は？
    • Docker AI Governanceで 組織的な管理 が可能

まとめ

  • Docker Sandboxes は、AIエージェントの安全な自律動作を実現する インフラレベルの隔離環境
  • 導入・運用が簡単 で、エージェントの能力を最大限に活かしつつ、 組織のセキュリティ要件 にも柔軟に対応
  • さらなる ネットワーク制御 や ファイルシステム管理 が必要な場合は、 Docker AI Governance の導入を推奨

Hackerたちの意見

これにワクワクしたのは、以前は存在しなかったからじゃなくて、Dockerがこれに力を入れるってことは、業界での広い普及とより良い統合を意味するからなんだよね。でも、ここでログインを求められるのはちょっと残念だな。意味がわからない。

└

それがDockerだよ。明日にはプレミアムアカウントなしでサンドボックスの実行に制限をかけるんじゃないかな。

└

マイクロVM（ファイアクラッカー）は何年も前から存在してる。これは新しいことじゃないよ。

半年くらい前から、自分専用の隔離されたセキュリティ強化されたDockerイメージをOpenCodeのために作り始めたんだ。毎日使ってるよ。 https://github.com/pkhamre/opencode-docker

各エージェントは専用のマイクロVM内であなたの開発環境を実行します。 「マイクロVM」って何？実際の制約がある仮想マシンと比べて、ここでのセキュリティモデルはどうなってるの？マーケティングの誇大広告かな？Incus/LXDはずっと前からVMを持ってるし。 incus launch images:ubuntu/26.04 my-ubuntu-vm --vm incus exec my-ubuntu-vm -- bash

└

本物のVMだよ、ファイアクラッカー方式で。

└

それはフルVMだね。マイクロVMはもっと小さくて、すごくすぐに立ち上がるよ。ミリ秒単位で。

└

“microvms”は本物のVMだけど、ハイパーバイザーとVM（ゲストカーネル）はほとんどのハードウェアやデバイスのエミュレーション、サポート、発見を省いてるから、従来のVMが本物のコンピュータのように見えたり感じたりするのとは違うんだ。これにより、非常に低いオーバーヘッドを実現してる。Firecrackerは125ms未満でVMを起動するように設計されていて、5MBで済むんだ。NetBSDは、10ms未満でMICROVMカーネル構成をダイレクトブートできるって宣伝してるよ。

└

Linuxの経験がほとんどない開発者がたくさんいるよね。特に、Windowsを使ってる企業の何十万もの.NETやJavaのCRUD開発者たち。こういう市場にはDockerデスクトップのようなGUIが必要だと思う。

└

Incusが起動するようなUbuntu Server VMは、インスタンスごとに少なくとも512MBのRAMを使うんだよね。もし10個のサンドボックスVMを立ち上げたら、ただそこに放置しておくだけで5GBのRAMを払うことになる。CPUコストもかかるし、10個のカーネルが管理してるけど、CPUコアの数を考えればあんまり気にしなくてもいいかも。俺はその中間を使ってて、単一のUbuntu VMを立てて、そこに複数のIncus LXCコンテナを立ち上げてエージェントを動かしてる。コンテナはインスタンスごとに50MBくらいしか使わないし（別々のsystemdとか）、これでVMのRAM税を一回だけ払えばいいし、万が一LXCコンテナから脱出してもエージェントはまだVMの中にいるから安心。

└

あなたの例は不完全だね。claude/codexをどう実行するかを示さないといけないし、そこにフォルダをインストールしてマウントするために余分なことをしなきゃならない。この方法は設定が少なくて済むし、エージェントがDockerを実行できるようにすることもできるけど、lxdではそれができない。

わあ、いつかLinuxがDockerサンドボックスの独占的なMacOs/Windows技術をサポートできるようになるといいな。（ドキュメントには書いてあるけど、メインページに指示がないのはちょっと変だね。多分ディストリビューションに関係してる。）

Hacker Newsで議論の続きを見る