第80回ブログ｜Docker Cloud Sandboxes を一次情報で読み解く ― 「ローカルとクラウドを自由に行き来」の実際と、Kit仕様・CNCF提携までの全体像

はじめに

2026年9月24日、Docker社は AIエージェント向けのクラウド実行環境「Docker Cloud Sandboxes」を発表しました。

本記事では、この発表を Docker公式ブログ・公式ドキュメント・CLIリファレンス まで確認し、

1. そもそも何が発表されたのか
2. 「ローカルとクラウドを自由に移動」は実際どういう仕組みなのか（「動いたまま移動できる」わけではない点に注意が必要です）
3. 同日発表された「Sandbox Kit Specification」と CNCF 提携の意味
4. 導入前に知っておくべき制約

を整理します。記載内容はすべて末尾の参考資料に基づいており、公式情報から確認できなかった点は「不明」と明記しています。

用語の整理（先に押さえておくと読みやすい言葉）

背景：なぜ「エージェント専用のサンドボックス」が必要なのか

2月に登場したローカル版「Docker Sandboxes」

Docker は2025年11月に実験的プレビューとして Docker Sandboxes を公開し、2026年1月末に microVM ベースへ強化したうえで macOS / Windows 対応を発表しました。

公式ブログでは、エージェントを安全に無人で動かそうとすると次の壁に当たると説明されています。

• OSレベルのサンドボックス機能は作業を中断させがちで、プラットフォーム間の一貫性もない
• コンテナは一見よさそうだが、エージェント自身が Docker を使いたくなった瞬間に破綻する（Docker-in-Docker問題）
• フルVMなら安全だが、遅くて手作業が多く、プロジェクト間で使い回しにくい

そこで Docker Sandboxes は、エージェントごとに専用の microVM を立て、その中に独自のカーネルと独自の Docker デーモンを持たせる設計を採りました。これにより、エージェントはサンドボックス内で自由にパッケージを入れたり Docker コンテナをビルド・実行したりでき、それでもホスト側の Docker デーモンには一切触れられません。

Docker の問題意識：「コンテナはアプリを包む。サンドボックスはエージェントを閉じ込める」

同日公開された Kit 仕様のブログで、Docker のエンジニアは両者の違いを次のように整理しています（筆者要約）。

• アプリケーションは決められた仕事をして、渡されたものにしか触らない → コンテナで十分
• エージェントは確率的に振る舞う主体で、次に何をするか自分で決める。root権限が必要なパッケージを入れたり、想定外のポートを開けたり、ブロックされたら別の手を試したりする → コンテナの境界は「エージェントが突っついているのと同じカーネル」なので不十分

つまり「エージェントが到達・改変できる層よりも下に境界を置く」ために microVM を使う、という考え方です。

今回の発表：Docker Cloud Sandboxes とは

一言でいうと

ローカルの Docker Sandboxes と同じ microVM・同じCLI・同じ隔離モデルを、Docker が管理するクラウド上で動かせるサービスです。

公式ブログは、Docker Sandboxes が「無人で動かしても安全か？」という第一の問いに答えたのに対し、Cloud Sandboxes は「十数個のエージェントを、それぞれ5時間・10時間・21時間と、誰も見張らずにどう動かすか？」という第二の問いに答えるものだ、と位置付けています。

なぜクラウドが必要になったのか

公式ブログの主張はシンプルです。

30秒で終わるタスクなら問題になりませんが、一晩かかるタスクではすべてが問題になります。言い換えると、ローカルだけで運用すると次の2つの課題が出てきます。

• マシンを付けっぱなしにする必要がある：数時間〜数十時間のタスクの間、PCを起動し続けなければならない
• 並列数の限界：多数のサブエージェントがそれぞれサンドボックスを持とうとすると、1台のマシンの能力では足りなくなる

主な特徴（公式ブログより）

エージェントが「一人で働く」ための3つの要素

公式ブログでは、長時間無人で働くエージェントに必要なものとして、①何もインストールせずに始められること、②仕事の道具、③到達範囲の制限、の3つを挙げ、それぞれ次の機能で提供するとしています。CLI と Webコンソールの両方から操作できます。

1. Kits（キット） エージェントごとに事前構成・事前ビルドされたサンドボックス。発表時点で Claude Code、Codex、Copilot、Antigravity、OpenCode、Hermes などが用意されています。なお CLI リファレンスの sbx run には、利用可能なエージェントとして claude / codex / copilot / cursor / devin / docker-agent / droid / gemini / kiro / opencode / shell が列挙されています。

2. MCP Jira、Linear、Grafana、incident.io、あるいは任意の streamable HTTP エンドポイントの MCP サーバーを一度接続すれば、クラウド・ローカル・ChatGPTデスクトップアプリなど他クライアントからも、単一のゲートウェイ経由で全エージェントが使えます。

3. Secrets（シークレット）と Policies（ポリシー）

• APIキーやトークンは一度保存すれば、プロキシがリクエストごとに注入する方式。エージェント自身は実際の値を見ることがありません。公式ブログは「そもそも持っていない秘密情報は、プロンプトインジェクション（悪意ある指示の埋め込み攻撃）でも盗めない」と説明しています。
• エージェントがアクセスしてよいエンドポイントをネットワークポリシーとして一度定義できます。企業向けの集中ガバナンスは「Docker AI Governance」で近日提供予定とのことです。

料金

従量課金（Pay-as-you-go）で、コンピュートを秒単位で課金。それ以外は課金されないと明記されています。

補足事項（公式ブログ・ドキュメントより）：

• 一時停止中のサンドボックスは無料。ボリューム、下り通信（egress）、公開イメージや Kit のホスティングも無料
• モデルの推論費用は別。自分のAPIキーを持ち込み、既存のモデルプロバイダー（Anthropic、OpenAI等）の請求になる
• サンドボックスはデフォルト1時間、1セッション最大24時間まで
• 利用には sbx 0.45.1 以降と従量課金プランが必要（Docker Personal / Pro アカウントで利用可能）
• ローカルの Docker Sandboxes は引き続き無料・単体で動作し、Docker Desktop も不要
• 期間限定で新規アカウントに $250 分の無料クレジット

始め方

# CLI のインストール（Homebrew）
$ brew install docker/tap/sbx
$ sbx login

# クラウドで Claude Code を起動
$ sbx --cloud run claude

ブラウザからは Webコンソール にサインインし、Kit を選んで Run するだけです。

ポイントは --cloud フラグを付けるだけで、同じ sbx コマンドの実行先がクラウドに切り替わることです。なおドキュメントによれば、クラウド側では sbx --cloud run claude . のようにローカルのパス（.）を渡すとエラーになります。

【重要】sbx move は「動いたまま移動」ではない

ここが本記事で最も伝えたいポイントです。「1コマンドでローカルとクラウドを行き来できる」と聞くと、エージェントが動いたまま移動するように感じますが、実際は違います。

公式ドキュメントの記述

公式ドキュメント「Move a sandbox」の冒頭には、sbx move はファイルシステムのスナップショットを転送するもので、実行中サンドボックスのライブマイグレーションではない、と明記されています。

sbx move の実際の処理は次の3ステップです。

1. 移動元サンドボックスのファイルシステムをテンプレートイメージとしてキャプチャ
2. そのイメージをローカル⇔クラウドの境界を越えて転送
3. 移動先でイメージから新しいサンドボックスを作成

そして以下の挙動が明記されています。

• ローカル→クラウドの移動では、キャプチャ中にローカル側のサンドボックスは停止する
• 移動先は別のサンドボックスIDになり、移動元は削除されない（以後は独立した別物として動く）
• 実行中のプロセス、メモリ、開いているソケットは移動しない
• 移動後、両者の変更は同期されない

つまり正確には、「作業途中のファイル状態を持ってクラウドで再開できる」であって、「動いているエージェントのプロセスがそのまま空中移動する」わけではない、ということです。公式ブログの表現も「A move captures the sandbox's filesystem and recreates it on the other side（ファイルシステムをキャプチャして向こう側で再作成する）」となっています。

移動時に「持っていけないもの」一覧

公式ドキュメントに列挙されている、移動で引き継がれないものは次のとおりです。見落とすと「クラウドに移したらコードがない」という事態になり得るので要注意です。

特に注意すべき点が2つあります。

① 手元のプロジェクトフォルダは移動しない ローカル版はホストのフォルダをマウントして使うのが基本ですが、そのファイルは「サンドボックスのファイルシステムの外側」にあるため、クラウドへ移動しても付いてきません。クラウドで作業させたいコードは、サンドボックス内で git clone するか sbx cp で転送する必要があります。

② サンドボックス内に書かれた認証情報は「付いていく」 逆に、エージェントの対話ログインなどでサンドボックス内のファイルに書き込まれた認証情報は、普通のファイルとしてスナップショットに含まれてしまいます。ドキュメントは移動前にこれらを削除するよう注意喚起しています。

その他の実務的な注意点

• クラウド側の有効期限（TTL）に注意：移動先のクラウドサンドボックスには、ローカル側に期限がなくても有効期限が付きます。--ttl を指定しないとサーバーのデフォルト（通常1時間）が使われ、タイムアウト時のデフォルト動作は「削除」になる場合があります。残したい作業なら --ttl 2h --on-timeout stop のように明示すべきです。
• L7フィルタリングは非対応：ローカル版では HTTPメソッドやパス単位の制限（例：GitHub APIの DELETE だけ禁止）ができますが、クラウド版ではサポートされていません。
• クラウド→ローカルはディスクを食う：ダウンロード時のレイヤー再利用のため、最大 32 GiB の一時ディスク領域が必要になることがあります。
• ホストのハードウェアは使えない：GPU、USB、ディスプレイ、ネスト仮想化はクラウド版では利用不可です。
• ステータスは「Experimental（実験的）」：公式ドキュメント上、Cloud sandboxes と Docker Agentic Platform はいずれも Experimental と表示されています。
• 当初は個人利用のみ：FAQ によると、初期リリースは個人向けで、共有ワークスペースやチームでの所有は未サポートです。

# 推奨：有効期限と期限切れ時の動作を明示して移動
$ sbx move local-project --to cloud --ttl 2h --on-timeout stop

# 移動後は両方の一覧を確認し、移動先を検証してから移動元を消す
$ sbx ls
$ sbx --cloud ls

同日発表：Sandbox Kit Specification v3 と CNCF 提携

Cloud Sandboxes と同じ9月24日に、Docker はさらに2つの発表をしています。筆者はむしろこちらの方が、長期的にはインパクトが大きいと感じました。

Kit とは「エージェントの権限をコードとして書く」もの

Kit 仕様を書いたエンジニアは、問題意識をこう語っています（筆者要約）。

• エージェントを役立たせるには、バインドマウント、広めのスコープのトークン、急いで開けたファイアウォールルールなど、権限を1つずつ与えることになる
• 1つ1つは妥当でも、積み重なると頼りにしていた隔離を自分で崩してしまう。しかもエクスプロイト（攻撃コード）は一切不要で、穴は「わざと追加した設定」
• そしてその権限はシェル履歴やダッシュボード、記憶の中にしかなく、同僚に渡すことも、先週との差分を取ることもできない

Dockerfile は「ソフトウェアがどうビルドされるか」は記述できますが、「外部のどこに通信してよいか、どの認証情報を使うか、どのボリュームが必要か」は書けません。これまで docker run のフラグや Compose ファイル、CI設定、誰かの記憶に散らばっていたこの「外側」の情報を、コンテンツと一緒に書き留めるのが Kit です。

v3 の最大の変更：Kit が「普通の OCI イメージ」になった

v3 では、Kit が独自アーティファクトではなく通常の OCI イメージになりました。宣言内容はマニフェストの1つのアノテーション（vnd.docker.sandbox.kit.descriptor）に入り、中身はレイヤーに入ります。

これによる実利は大きく、

• docker buildx build でビルド、docker pull で取得できる
• 既存のスキャナーや署名ツールがそのまま使える
• ダイジェスト（ハッシュ値）を固定すれば、中身と権限宣言がセットで固定される

Kit には2種類あります。

• workload：実際に動いてルートファイルシステムを提供するもの（例：Claude Code 本体）。1つだけ起動できる
• mixin：上に重ねるオーバーレイ（例：GitHub CLI とそのネットワークルール、認証情報のバインド）。いくつでも追加できる

「読める権限」の例

公式ブログには GitHub CLI 用 mixin の例が載っています。説明用に要点だけ簡略化すると、次のような構造です。

# ※ 公式ブログの例をもとに筆者が要点のみ簡略化したもの
capabilities:
  - type: com.docker.sandbox/network-policy@2
    config:
      runtime:
        allow:
          - github.com            # GitHub には行ってよい
          - hosts: [api.github.com]
            methods: [GET, POST, PATCH, PUT, DELETE]
        deny:
          - hosts: [api.github.com]
            methods: [DELETE]
            paths: [/repos/**]    # ただしリポジトリ削除は禁止（deny が優先）

  - type: com.docker.sandbox/credential@1
    config:
      service: github
      apiKey:
        name: GH_TOKEN
        proxyManaged: true        # 実際の値はプロキシが注入。サンドボックス内にはダミー値のみ

これは「許可証」として読めます。プルリクエストを作れるトークンでも、リポジトリは削除できない。そして Kit 自体は何の権限も自分に与えず、各項目はあくまで「要求」で、判断するのはホスト側です。

ここで重要なのが「適合ランタイム（conforming runtime）」という概念です。仕様どおりに動作を実装したランタイムだけがこの宣言を強制でき、適合ランタイムでなければアノテーションはただの飾りになります。Docker Sandboxes が最初の適合ランタイムです。

「差分がレビューになる」

個人的に最も面白いと感じたのがこの設計です。

• Claude Code の Kit の次バージョンが新しい接続先や2つ目の認証情報を要求したら、それは「ソフトウェア更新」ではなく「権限の変更」であり、プルリクエストの追加行として人間が拒否できる
• さらに人間が差分を読まなくても機能する第二の関門として、ランタイムが「許可済みの権限集合」を記録しておき、次バージョンがそれを広げる場合は更新を止めて確認を求める。deny ルールの削除も「拡大」とみなされる

Docker はこれを「Dockerfile はソフトウェアを再現可能にした。Kit は権限を再現可能にする」と表現しています。

CNCF への寄贈：「エージェント権限の OCI」を目指す

もう1つの発表が、この Kit 仕様を Apache 2.0 のオープンソースとして公開し、CNCF の中立的ガバナンスに持ち込むというものです。

Docker はこれを、10年前に自社のイメージ形式と runc ランタイムを Linux Foundation に寄贈し、OCI が生まれた歴史になぞらえています。当時「ベンダーごとにイメージ形式が乱立する未来」を避けたように、今度は「エージェントに何を許すか」の記述形式が乱立するのを防ぎたい、という狙いです。

• 共同で Kit を作成したパートナーとして AWS、Box、Datadog、Dynatrace、JFrog、NanoClaw、OpenClaw、Palo Alto Networks、Snyk などが挙げられています
• CNCF の CTO である Chris Aniszczyk 氏も歓迎のコメントを寄せています
• 公式ブログは「MCP はエージェントがツールと話す標準を与えた。Kit はエージェント・ツール・到達範囲の組み合わせ全体を公開する標準を与える」と位置付けています

仕様リポジトリ：docker/sandbox-kit-spec

公式情報からは確認できなかった点（不明点）

以下は今回の調査範囲の公式情報では確認できませんでした。導入検討時には直接確認が必要です。

なお、データ保持については FAQ に記載があり、サービスログは31日、生のテレメトリは12か月保持、スナップショット（一時停止時のものを含む）は7日間使われないと自動削除されるとのことです。

まとめ：誰に、どう効くか

今回の発表の本質

1. Cloud Sandboxes：ローカルと同じ隔離モデル（microVM）をクラウドで。「どこで動いているかによって、エージェントをどこまで信頼できるかが変わるべきではない」という設計思想
2. sbx move：ファイルシステムのスナップショットによる移動。便利だがライブマイグレーションではなく、ワークスペースやシークレット、ネットワークポリシーは引き継がれない
3. Kit 仕様 v3 + CNCF：エージェントの「権限」をOCIイメージに同梱し、レビュー・差分管理・強制を可能にする標準化の動き

筆者の所感

Cloud Sandboxes 単体で見ると、「クラウドのエージェント実行環境」自体は他社にも存在するサービスで、Docker 自身も「他にこの形で動くエージェントサンドボックスは我々の知る限りない」と主張しているのはローカルとクラウドを同一モデル・1コマンドで行き来できる点についてです。

ただ、実際に sbx move の仕様を読むと、ワークスペース・シークレット・ネットワークポリシー・L7フィルタが持ち越されないなど、「1コマンドで移動」の裏にはかなりの前提条件があります。ローカルで作り込んだ運用をそのままクラウドへ、というよりは、最初から「クラウドで長時間回すタスク」として設計し直す方が現実的だと感じました。

むしろ注目すべきは Kit 仕様の方です。AIエージェントに渡す権限が「誰の頭の中にもない」状態は、多くの開発現場で起きているはずです。これを OCI イメージとしてバージョン管理し、差分でレビューし、権限拡大を自動で止められるという発想は、Docker 製品を使うかどうかに関わらず、エージェント運用のあり方として参考になります。

参考資料

Docker 公式ブログ

• Introducing Cloud Sandboxes: Start on Your Laptop, Finish in the Cloud（2026年9月24日）
• From Dockerfile to Kit: the Docker Sandboxes Kit Specification（2026年9月24日）
• Docker and CNCF partner on an open spec for agent permissions（2026年9月24日）
• Docker Sandboxes: Run Claude Code and Other Coding Agents Unsupervised (but Safely)（2026年1月30日）

Docker 公式ドキュメント

• Move a sandbox
• Compare local and cloud sandboxes
• Use cloud sandboxes
• Docker Agentic Platform FAQ
• sbx move（CLIリファレンス）
• sbx run（CLIリファレンス）

その他

• docker/sandbox-kit-spec（GitHub）
• docker/sbx-releases v0.42.0（GitHub）