Docker Cloud Sandboxesの隔離・権限・料金

Claude CodeやCodexに、数時間かかる依存更新やリファクタリングを任せたい。ただ、開発者のPCで確認を省いて動かすと、ソースコードもSSH鍵もクラウドの認証情報も手の届く場所に置いたままになります。サンドボックスに入れるとしても、何が隔離されて何が残るのか、クラウドで動かすといくらかかり、会社として契約できるのかが分からなければ、開発責任者は判断できません。

Dockerは2026年9月24日、ローカルで使えていたDocker Sandboxesをクラウドでも動かせる「Cloud Sandboxes」と、エージェントの権限をOCIイメージとして配る「Sandbox Kit Specification v3」を公開しました。本記事は、Dockerの公式ブログ、docker/docsリポジトリのドキュメント原文、docker/sandbox-kit-specリポジトリを2026年10月4日に確認した資料調査です。Kitの権限の差分判定だけは、編集部の環境で仕様リポジトリのコードを動かして確かめました。

何が公開され、どの段階にあるか

発表の中身は次のとおりです。

• Cloud Sandboxes: ローカルと同じmicroVMのサンドボックスを、Dockerが管理する計算資源で動かす。sbx move でローカルとクラウドの間をファイルシステムごと移せる
• Sandbox Kit Specification v3: エージェント・ツール・権限の要求をまとめたKitを、通常のOCIイメージとして定義する。Apache 2.0で公開
• CNCFへの持ち込み: Kit仕様をCNCFの中立的なガバナンスへ移すと表明。10月4日時点の仕様リポジトリのGOVERNANCE.mdは「Docker maintains this specification.」と書いている

提供段階はローカルとクラウドで違います。Cloud Sandboxesの土台であるDocker Agentic Platformのリリースノートは、9月24日を「experimental public release」と書いています。CLIのクラウド機能のページにも「experimental. Features and behavior may change.」とあります。Kit仕様のREADMEも「This specification is experimental.」としたうえで、正式版の目標を2026年第4四半期に置いています。一方、ローカルのDocker SandboxesはCLIもローカルの計算資源も無料で、商用利用も可と明記されています。

ローカルのサンドボックスで隔離されるもの・残るもの

ドキュメントによると、サンドボックスごとに専用のLinuxカーネルを持つmicroVMが立ち、その中に専用のDocker Engineがあります。エージェントはVMの中ではsudoも使えますが、ホストのDocker daemonには届きません。コンテナにホストのDockerソケットを渡す構成とは、この点が違います。

注意したいのは、直接マウントしたワークスペースへの変更がそのままホストに反映されることです。ドキュメントは、.git/hooks/ やCIの設定、.claude/settings.json のようなAIツールの設定ファイルも書き換えられ、次のコミットやビルドで実行されうると警告しています。Gitのフックは git diff に出ません。エージェント向けの指示ファイルがどう読まれるかはClaude CodeがAGENTS.mdを読まない条件でも扱いました。社内の標準は、元のリポジトリに書き込めない --clone を起点に考えるのが安全です。

組織全体へのポリシー配布（ネットワーク・ファイル・MCP）や監査ログ、組織アカウントでのサインイン強制は「separate paid subscription」で、営業窓口への問い合わせが案内されています。価格は公開資料に載っていません。

クラウドに移すと何が変わるか

権限は引き継がれない

クラウドのサンドボックスは、ローカルとは別のシークレット保存先とネットワークポリシーを使います。sbx move で移してもローカルのルールや認証情報はコピーされません。ファイルに書いた認証情報だけはスナップショットに含まれうるため、移す前に消すよう案内されています。

もう1つ大きいのが、HTTPのメソッドやパスでの制限（L7フィルタリング）がクラウドでは使えないことです。「GitHubのAPIは使えるがリポジトリの削除はできない」といったルールは、ローカルでしか効きません。該当するルールがあるサンドボックスを移そうとすると、sbx move が警告して確認を求めます。ローカルのホストパスやGPUも、クラウドからは使えません。

料金と契約の条件

公式ブログに載っている料金は、秒単位の従量課金です。停止中は課金されず、ボリューム・外向き通信・公開イメージとKitの置き場所は無料とされています。モデルの利用料は別で、自社のAPIキーを持ち込みます。

既定の実行時間は1時間で、1回のセッションは最長24時間です。延長しても作成から24時間を超えられません。期限が来ると、再開できるものは停止、それ以外は削除されます。

契約の単位は会社で導入するときの壁になります。ブログは対象を「Docker Personal and Pro accounts」とし、ドキュメントは組織に属していても個人のDockerアカウントで申し込み、Dockerのサブスクリプションとは別に請求されると書いています。FAQは初回リリースを「for individual use」とし、チームでの共有や共同所有は未対応です。新規アカウントには期間限定で250ドル分のクレジットがあるとブログにありますが、条件と期限は申込画面で確かめてください。必要なsbxの版は、ブログが0.45.1以降、ドキュメントが0.45.0以降と書いています。

Sandbox Kitで権限をレビューできる差分にする

Kitは、エージェントが「どこへつなぎ、どの認証情報とボリュームを使うか」を、イメージのマニフェストの注釈 vnd.docker.sandbox.kit.descriptor に書いたOCIイメージです。普段のレジストリやスキャナー、署名の仕組みでそのまま扱え、ダイジェストで固定すると中身と権限の要求が一緒に固定されます。リポジトリにあるGitHub CLIのKitの一部です。

- type: com.docker.sandbox/network-policy@2
  config:
    runtime:
      allow:
        - github.com
        - hosts: [api.github.com]
          methods: [GET, HEAD, POST, PATCH, PUT, DELETE]
      deny:
        - hosts: [api.github.com]
          methods: [DELETE]
          paths: [/repos/**]

拒否が許可より優先されるため、このトークンでプルリクエストは作れても、リポジトリは削除できません。認証情報は proxyManaged: true で、サンドボックスの中には実際の値が入りません。ただしKitは要求を書くだけで、守らせるのは仕様に沿ったランタイムです。現時点で対応を表明しているのはDocker Sandboxesだけです。

仕様は、Kitの更新で要求が広がったら利用者の承認を求めるよう定めています。編集部では、仕様リポジトリ（commit 129be2f）のGoパッケージで、GitHub CLIのKitを4通りに書き換えて判定させました（Linux、Go 1.26.8）。

拒否ルールを消す変更も、権限の拡大として扱われました。逆に権限を減らす変更は承認なしで通ります。これは仕様のライブラリの判定で、Docker Sandboxesの実際の更新画面は確認していません。社内でKitを配るなら、Kitの定義をGitで管理し、接続先・認証情報・拒否ルールの差分をプルリクエストのレビュー対象にすると、この仕組みと噛み合います。

導入前に決めておくこと（編集部の提案）

1. ワークスペースの渡し方。 既定は --clone、直接マウントは対象リポジトリを限る。.env などの秘密情報は作業ディレクトリの外に置く
2. ネットワークの初期値。 Locked Downから始めて必要な接続先を足すか、Balancedの一覧を sbx policy ls で精査する。SSHエージェントの転送を使わないなら止める
3. クラウドに出す作業の範囲。 認証情報とポリシーをクラウド側で別に設定し、L7ルールに頼る作業はローカルに残す。個人アカウントの契約になるため、費用の精算と、誰のAPIキーで動かすかを先に決める
4. Kitの取得元。 リモートのKitの取得元は既定でDocker Hubのみ（kit.allowedSources）、ローカルのKitは既定で許可（kit.allowLocalKits）です。社内で作ったKitをどこに置き、誰がレビューするかを決める

権限をどこまで渡すかの考え方は評価用のAIがサンドボックスを抜けた事例、実行環境を自前で持つかどうかはAIの実行環境の線を引く記事も参考になります。

2026年10月4日に、Dockerの公式ブログ（Cloud Sandboxesの発表、Kit仕様の解説、CNCFとの連携、WeAreDevelopersのまとめ）、docker/docsリポジトリ（commit 1cb9a4d）のDocker SandboxesとDocker Agentic Platformのページ、docker/sandbox-kit-specリポジトリ（commit 129be2f）を直接開いて照合しました。Kitの差分判定は、編集部の環境で仕様リポジトリのGoパッケージを1回ずつ動かした結果です。この環境はKVMが使えないため、ローカルのサンドボックスは起動しておらず、Cloud Sandboxesの契約と実行、料金の請求、L7ルールを含むKitをクラウドで動かしたときの挙動、組織向けガバナンスの価格は確認していません。

コーディングエージェントを使う開発体制の設計や、権限の分け方を含む自動化の進め方は、グリームハブへご相談ください。

Sources

• Introducing Cloud Sandboxes: Start on Your Laptop, Finish in the Cloud — Docker Blog
• From Dockerfile to Kit: the Docker Sandboxes Kit Specification — Docker Blog
• Docker and CNCF partner on an open spec for agent permissions — Docker Blog
• Trust Docker for the agents you don’t — Docker Blog
• Docker Sandboxes — docker/docs (content/manuals/ai/sandboxes)
• Compare local and cloud sandboxes — docker/docs
• Security model / Isolation layers — docker/docs
• Docker Agentic Platform release notes — docker/docs
• Sign up for Docker Agentic Platform — docker/docs
• Docker Agentic Platform FAQ — docker/docs
• docker/sandbox-kit-spec — README
• docker/sandbox-kit-spec — examples/gh/gh.yaml