Docker Cloud Sandboxesは、Claude CodeやCodexなどのコーディングエージェントを、Dockerが管理するクラウド上のmicroVMで動かす仕組みです。2026年9月24日にDocker公式ブログで発表され、手元で動かしていたDocker Sandboxesと同じ隔離モデルとsbx CLIのまま、作業をクラウドへ移せるようになりました。国内での報道は9月28日前後ですが、一次情報の公開日は9月24日です。
この記事では、隔離の構造とローカル版との違いを押さえたうえで、sbxでクラウドにエージェントを起動するコマンド、sbx moveで引き継がれない状態、TTLと時間単価からの費用試算、そして受託開発の現場で採用するかどうかの線引きまでを扱います。
まとめ：Docker Cloud Sandboxesを使う条件と見送る条件
結論を先に書きます。数時間単位で走らせたいエージェント作業が複数あり、ノートPCを閉じても止めたくない場合は試す価値があります。一方、ホストのGPUや社内ネットワークのファイルに依存する作業、そしてHTTPメソッドやパス単位で通信を絞る必要がある作業はローカルに残すほうが無難です。業務案件の標準にするかどうかは、sbxのクラウド対応が実験的機能という表記を外すまで判断を保留して構いません。
- 中身：各サンドボックスは専用のDockerデーモンを持つmicroVM。ローカル版と隔離モデル・CLIが同じで、動く場所がDocker管理のクラウドに変わる
- 使い始め：sbx 0.45系を入れ、
sbx loginのあと--cloudを付けて起動する。クラウド用のシークレットとネットワーク許可は別に登録し直す - 移動：
sbx moveはファイルシステムのスナップショット複製で、実行中のプロセスやメモリ、シークレットは移らない - 寿命：既定のTTLは1時間、延長しても作成から24時間が上限
- 料金：秒単位の従量課金で、既定サイズ（2 vCPU・4GiB）は1時間0.14ドル。一時停止中は課金されない
Docker Cloud SandboxesのmicroVM隔離とローカル共通の仕組み
前提になるのは、2026年に入ってDockerが公開したローカル版のDocker Sandboxesです。エージェントにシェルやパッケージのインストール、docker buildまで任せると、手元の端末のファイルや認証情報に手が届いてしまいます。そこでエージェントを丸ごと軽量な仮想マシンへ閉じ込め、ホストから切り離して動かすのがDocker Sandboxesの発想でした。クラウド版は、その仮想マシンを動かす場所を手元の端末からDocker管理の計算資源へ広げたものです。
操作はsbxという専用CLIで行い、Docker Desktopは不要です。配布リポジトリではmacOS・Windows・Ubuntu・Rocky Linux 8向けのパッケージが公開されており、ライセンスはDocker社のプロプライエタリと明記されています。ローカルで使う範囲は無料で、クラウドで動かした分だけ課金される構成です。
専用Dockerデーモンを持つmicroVMとgVisor・Kataの位置関係
公式のアーキテクチャ解説によると、各サンドボックスはハイパーバイザで分離され、それぞれが専用のDockerデーモンとイメージキャッシュを持ちます。ホストのDockerソケットをコンテナへマウントする方式はnamespaceによる部分的な分離にとどまり、ホストのデーモンも共有する構造です。エージェントにdocker composeまで自由に叩かせたい場面では、この差が効いてきます。
資格情報の扱いも特徴的です。エージェントから見えるのはダミー値で、通信がmicroVMの外へ出た時点でホスト側のプロキシが本物のAPIキーへ差し替えます。外向きのTCP通信はすべてこのプロキシを通り、ネットワークポリシーで許可した宛先にしか届きません。
カーネルを共有せずに隔離する技術としては、システムコールをユーザー空間で受け止めるgVisorや、軽量VMでコンテナを包むKata Containersが先にあります。違いは使い手の想定です。gVisorやKataはKubernetesなどの実行基盤に組み込む部品で、Docker Sandboxesはエージェントを1つずつ起動して捨てる開発者向けの完成品として作られています。部品側の仕組みと選び方の参照先はgVisorの仕組みとrunc・Kataとの比較をまとめた記事です。また、Docker Desktopの仮想化層を自前実装へ替えたDocker VMMの解説で触れた新しいエンジンも、Docker Sandboxesの実行基盤になっていると報じられています。
ローカル版Docker Sandboxesとクラウド版で変わる主な項目の比較表
同じCLIでも、--cloudを付けると実行場所と使えるリソースが変わります。ローカルとクラウドの比較ページから、移行時に影響の大きい項目を抜き出しました。
| 項目 | ローカル | クラウド |
|---|---|---|
| 作業ディレクトリ | ホストのパスをマウント | マウント不可・cloneか転送 |
| ハードウェア | GPUやUSBを利用可 | ホストの機器は使えない |
| ポート公開 | ホストのポートへ割当 | 公開HTTPSのURLを発行 |
| シークレット | ローカルの保管庫 | クラウド用の別の保管庫 |
| 通信制限 | メソッドやパス単位も可 | 宛先単位のみで指定 |
| 寿命 | 削除するまで保持 | TTLで自動的に失効 |
| 課金 | サンドボックス課金なし | 計算資源の従量課金 |
見落としやすいのはリソースの分離です。sbx lsの結果はsbx --cloud lsに出てきません。テンプレート、シークレット、ボリューム、ネットワークポリシーもそれぞれ別管理なので、ローカルで整えた設定はクラウドで一から作り直すことになります。
sbx CLIを入れてクラウドでClaude Codeを起動するまでの手順
必要なものは3つです。sbx CLI、サインインできるDockerアカウント、そしてクラウド実行の契約です。クラウドサンドボックスのドキュメントはsbx 0.45.0以降とDocker Agentic Platformの契約を前提に挙げ、発表ブログは0.45.1以降と従量課金プランを挙げています。版の表記が食い違っているため、両方の条件を満たす導入対象は0.45.1以降です。ブログによると従量課金プランはPersonalとProのアカウントでも使えます。
OS別sbx導入とWindows Hypervisor Platform有効化の手順
インストールはパッケージマネージャで済みます。インストール手順のページに載っているコマンドは次のとおりです。
# macOS（macOS 14以降・Apple silicon）
brew trust docker/tap
brew install docker/tap/sbx
# Windows 11（現在のユーザー向け）
winget install -h Docker.sbx
# Ubuntu 24.04以降
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt install docker-sbx
# 共通：サインインとクラウド接続の確認
sbx version
sbx login
sbx --cloud diagnoseクラウドだけを使う場合、手元のハイパーバイザ設定は不要です。ローカルのサンドボックスも併用するなら、WindowsではWindows Hypervisor Platformを有効化し、Linuxではkvmグループへの所属が求められます。社内の検証用VMやVDIの上で動かす場合は入れ子の仮想化が必要になるため、クラウド側だけで始めるほうが手間がかかりません。
シークレット登録から通信許可・clone・成果物回収までのコマンド
ローカルで済ませた認証はクラウドへ持ち越されません。Claude Codeを使うなら、クラウド用の保管庫にAnthropicのAPIキーを登録するところから始めます。ドキュメントの例をもとに、リポジトリをレビューさせて結果を手元へ回収するまでを並べると次のようになります。
# クラウド用シークレットにAPIキーを登録（対話で入力）
sbx --cloud secret set anthropic
# GitHubへの通信だけ許可し、TTL 2時間でサンドボックスを作成
sbx --cloud create --name review-job \
--allow-network github.com:443 \
--ttl 2h --on-timeout stop claude
# サンドボックス内でリポジトリを取得
sbx --cloud exec review-job git clone \
https://github.com/docker/welcome-to-docker.git /home/agent/workspace/project
# エージェントに接続（Ctrl+\ で切り離してもエージェントは動き続ける）
sbx --cloud attach review-job
# 成果物を手元へコピーし、不要になったら削除
sbx --cloud cp review-job:/home/agent/workspace/review.md ./review.md
sbx --cloud rm review-job--allow-networkで許可しなかった宛先には、エージェントは接続できません。パッケージレジストリやモデルのAPIなど、作業に必要な宛先を最初に洗い出しておくと、途中で通信が止まって作業が空回りする事態を避けられます。サンドボックスの中にだけ置いたファイルは削除と同時に消えるので、成果物はcpで回収するか、リポジトリへpushさせる運用にします。
sbx moveでローカルの作業をクラウドへ移すときに引き継がれない状態
発表で最も目を引くのは、手元で始めたサンドボックスを1コマンドでクラウドへ送れる点です。ただし移動手順のページを読むと、これはライブマイグレーションではありません。ファイルシステムのスナップショットを複製して、移動先に新しいサンドボックスを作る操作です。
# ローカルの作業をクラウドへ（TTLとタイムアウト時の動作も指定できる）
sbx move local-project --to cloud --name cloud-project --ttl 2h --on-timeout stop
# クラウドの作業を手元へ戻す
sbx move cloud-project --to local --name local-copy移動時にプロセスとメモリは移らずファイルシステムだけ複製される挙動
移動しても、実行中のプロセス、メモリ、ソケットは引き継がれません。エージェントの会話途中で送った場合は、移動先で改めて起動し直す前提で考えます。ホストからマウントしていた作業ディレクトリとボリューム、そしてシークレットも転送されないため、移動先で登録し直す作業が発生します。
逆に、移ってほしくないものが移る場合もあります。エージェントの対話型サインインで作られた認証ファイルは、ファイルシステムの一部としてスナップショットに含まれます。クラウドへ持ち出したくない資格情報があるなら、移動前にサンドボックス内から消しておいてください。移動元は自動では削除されず、ローカルから送った場合はローカル側が停止されます。両者の変更は同期されないので、どちらを正とするかを決めてから作業を続けます。
amd64とarm64の不一致やL7通信制限で移動が止まる典型パターン
止まりやすい原因は2つあります。1つはCPUアーキテクチャです。sbx moveは変換を行わないため、Apple siliconの端末で作ったarm64のサンドボックスは、クラウド側がarm64を提供していないと送れません。クラウドの対応状況はアカウントの提供範囲に左右されると書かれています。
もう1つは通信制限の粒度です。クラウドはHTTPメソッドやパスによる制限に対応しないため、ローカルでそうしたルールを設定していると、移動時に警告と確認が入ります。標準入力が端末でない状態、つまりスクリプトやCIから呼んだ場合は、--forceを付けない限り確認待ちとなり処理は失敗する挙動です。クラウドから手元へ戻す方向では、レイヤーの再利用中に最大32GiBの一時ディスクが必要になる場合がある点にも注意が要ります。
TTL既定1時間と最大24時間・時間単価から月額費用を見積もる方法
クラウドのサンドボックスは放置すると自動で消えます。費用が青天井にならない反面、長時間の作業では寿命の設定を誤ると成果物ごと失う可能性があります。そのため、料金とTTLはセットで設計する必要がある項目です。
既定1時間のTTLと–on-timeoutの3つの動作を作業時間に合わせる設定
利用手順のページによると、TTLの既定は1時間です。sbx --cloud ttl +30m review-jobのように延長できますが、作成から24時間を超えて延ばすことはできません。--ttl 0は無期限ではなくエラーになります。停止中はTTLが進まず、再開した時点で新しい期間が始まる仕様です。
期限が来たときの動作は--on-timeoutで選びます。stopは再開できる形で保持し、restartは停止後すぐに起動し直し、deleteは削除します。ボリュームを付けたサンドボックスはdeleteしか選べません。成果物をリポジトリへ逐次pushさせる作業ならdelete、途中の状態を残したい作業ならstopを明示しておくのが安全です。
Micro 0.07ドルからXL 1.12ドルまでの単価で並列実行の費用を試算
発表時点の単価は次のとおりで、秒単位で計測されます。一時停止中のサンドボックス、ボリューム、外向き通信、公開イメージやKitの保管は、発表時点ではいずれも無料という扱いです。モデルの推論料金は別で、自前のAPIキーを使う場合は既存のプロバイダに支払います。
| サイズ | vCPU | メモリ | 1時間あたり |
|---|---|---|---|
| Micro | 1 | 2GiB | 0.07ドル |
| Small（既定） | 2 | 4GiB | 0.14ドル |
| Medium | 4 | 8GiB | 0.28ドル |
| Large | 8 | 16GiB | 0.56ドル |
| XL | 16 | 32GiB | 1.12ドル |
サイズは--cpus 4 --memory 8gのように指定し、省略するとSmallで起動します。試算の例を挙げます。Smallを1日8時間、月20日動かすと0.14×8×20で22.4ドルです。Mediumを10本並べて1日4時間、月20日なら0.28×4×20×10で224ドルになります。計算資源の費用は、エージェントが消費するモデルのトークン代より小さく収まる場面が多いはずです。予算管理の主眼は、TTLで止め忘れを防ぐことと、並列数の上限をチームで決めることに置きます。新規アカウントには期間限定の無料クレジット（発表時点で250ドル）が用意されているので、検証はその範囲で回せます。
受託開発でDocker Cloud Sandboxesを採用する条件と見送る場面
ここからは判断です。採用の可否は、速さよりも「エージェントに何を触らせてよいか」で決めます。次の3条件がそろう作業は、クラウドのサンドボックスへ出して構いません。
- 作業がGitリポジトリで完結する：入力はcloneで、成果物はpushかcpで回収でき、ホストのファイルやGPUに依存しない
- 外部の宛先を列挙できる：GitHub、パッケージレジストリ、モデルのAPIなど、許可する宛先をドメインとポートで書き出せる
- 数時間単位の長い処理や並列実行がある：依存関係の一括更新、テストの修正、複数ブランチの調査など、端末を占有させたくない作業がある
逆に、次のどちらかに当てはまる場合は見送ります。第一に、顧客から預かったデータやソースコードを外部のクラウドへ置くことが契約上認められていない案件です。サンドボックスの隔離はエージェントからホストを守る仕組みであり、データの保管場所の問題は解決しません。第二に、HTTPメソッドやパス単位で通信を絞らないと安全性を説明できない作業です。クラウド側はこの粒度に対応していません。隔離環境が守れる範囲と守れない範囲の整理は、サンドボックスの役割と限界を解説した記事が判断の土台になります。
実験的機能の段階で業務案件へ入れる前にチームで決める運用ルール
ドキュメントは、sbxのクラウド対応を機能や挙動が変わりうる実験的機能と明記しています。組織単位の集中管理を担うDocker AI Governanceとの連携も「近日提供」の段階です。この時点で業務へ入れるなら、少なくとも次の運用を決めてから始めてください。許可する宛先の一覧、TTLと--on-timeoutの既定値、成果物の回収方法、そして顧客データを置かないというルールです。これらを1枚にまとめておけば、仕様が変わったときに見直す範囲がすぐに分かります。
エージェントの実行環境は、最終的には本番のクラウド構成やCIと地続きになります。サンドボックスの通信許可や資格情報の扱いを、自社のAWSやGoogle Cloudのネットワーク設計と合わせて組み立てたい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）で、開発環境から本番環境までを通した構成の設計から相談できます。
よくある質問
Docker Cloud Sandboxesを検討するときによく出る疑問を、2026年10月時点の公式ドキュメントに沿って整理しました。
Docker Cloud Sandboxesを使うのにDocker Desktopは必要ですか？
必要ありません。発表ブログは、ローカルのDocker SandboxesがDocker Desktopなしで動き、無料で使えると明記しています。操作はsbx CLIだけで完結し、クラウドで動かす場合は手元のハイパーバイザ設定も不要です。クラウド実行には、sbx login でサインインしたアカウントで従量課金の契約を有効にしておく必要があります。
どのAIエージェントに対応していますか？
発表ブログでは、事前構成済みのKitとしてClaude Code、Codex、Copilot、Antigravity、Open Code、Hermesが挙げられています。KitはDocker Sandbox Kit Specification v3に沿ったOCIイメージとして配布され、通常のイメージと同じようにbuildやpullができます。社内のツールを組み込んだ独自のKitを作ることも可能です。
ノートPCを閉じてもエージェントは動き続けますか？
クラウドで動かしていれば動き続けます。sbx --cloud attachで接続している最中でも、Ctrl+\ で切り離せばエージェントは実行を続けます。ただしTTLが切れると停止または削除されるため、長い作業ではTTLを延ばすか、--on-timeout stopで状態を残す設定にしておいてください。延長の上限は作成から24時間です。
ローカルで設定したAPIキーやネットワーク許可はクラウドへ引き継がれますか？
引き継がれません。クラウドのシークレットとネットワークポリシーはローカルとは別に管理されており、sbx moveで移動した場合もコピーされません。移動先でsbx --cloud secret setや--allow-networkを使って登録し直します。逆に、サンドボックス内のファイルとして保存された認証情報はスナップショットに含まれるため、持ち出したくなければ移動前に削除します。
料金の上限を決めて使い過ぎを防ぐ方法はありますか？
2026年10月時点の公式ドキュメントには、アカウント単位の予算上限を設定する手順は見当たりません。実務上の歯止めはTTLです。既定は1時間で、作成から24時間を超えて延長できないため、止め忘れによる課金は1本あたり最大でも24時間分に収まります。サイズを既定のSmallに固定し、並列で起動する本数をチームで決めておけば、月額は時間単価から事前に計算できます。
関連記事
- Firecracker（マイクロVM）とは？仕組み・KVMとの関係とgVisor・コンテナとの使い分け：microVMという隔離方式が何を守り、どこにコストがかかるのかを仕組みから確認できます
- Kata Containersとは？軽量VMで隔離するセキュアコンテナの仕組みとgVisor・runc比較：自社のKubernetes基盤でVM級の隔離を組む場合の選択肢を比べられます
- Agentic Coding（エージェンティックコーディング）とは？意味と進め方・Claude Codeでの始め方：エージェントに長い作業を任せる開発の進め方を整理しています
- Claude Codeとは？できること・使い方・料金：コード解析の実力と導入手順：サンドボックスで動かすエージェント本体の機能と料金を確認できます
- コンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説：コンテナと仮想マシンの違いという前提知識を補えます
