---
title: "Docker Cloud Sandboxesを試す"
description: "Docker Cloud SandboxesでCodexを動かし、Notionのチケットをもとに実装からGitHubのPull Request作成までを試します。環境の準備やSSH接続、課金体系、アクセス制限についても紹介します。"
createdAt: "2026-09-25"
tags: [AI, Docker, Docker Cloud Sandboxes]
---
2026-09-24にDocker社から、[Docker Cloud Sandboxesが発表された](https://www.docker.com/press-release/cloud-sandboxes-extending-secure-ai-agent-isolation-beyond-the-laptop/)ので、そちらを試していこうと思います。
## Docker Cloud Sandboxesについて
[Docker Cloud Sandboxes](https://www.docker.com/products/docker-sandboxes/)は、Docker社が提供するインフラ上でAI Agentを動かすことができるといったサービスです。
これの何が嬉しいかというと、ローカルマシンに干渉しないという点です。
最近、ローカルマシン上でAI Agentを動かす際に、強い権限を与えてしまったことで意図しないファイルの削除をはじめとした事故や、セキュリティ的な事故が発生してしまったというニュースをよく目にするようになりました。
もちろん、AI Agentに与える権限を最小限にしたり、全てのアクションを許可制にすれば事故のリスクを減らすことはできると思いますが、そうするとAI Agentの自律性を著しく損ねることになってしまいます。
そのような理由から、以前よりAI Agentはホストマシンから切り離された安全な環境で動かすことが重要であるという話がなされてきました。
そうした要求に対しては、Dev Containerのような仕組みをはじめとして、完全なリモート環境のSandbox環境の中でAgentを動かすことのできるものまでいくつかのサービスがすでに存在していますが、そんな中今回登場したのがDocker Cloud Sandboxesとなります。
Docker Cloud Sandboxesは、ホストマシンとは完全に隔離されたリモートのSandbox上でAgentを動かすためのマネージドな仕組みを提供してくれています。
単純な開発用途として扱う場合には、自前でのセットアップなどがほとんど不要な程度に仕組みが整っており、そこが強みの1つとなっていそうです。
以降では、実際に0の状態からAgentを動かすところまでを試してみて、実際の使用感をみてみようと思います。
## やること
Docker Cloud Sandboxesを利用して、実際に普段行っている開発フローを再現してみようと思います。
大体の流れは以下のようなものとなります。
- Notion上でタスクのチケットを切る
- Agentにチケットを渡して実装を依頼する
- 実装してPull Requestを発行してもらう
## 試してみる
### Docker Cloud Sandboxesの利用を開始する
にアクセスします。
Dockerのアカウントを要求されたので、未所持の場合は登録します。
アカウントへのログインに成功すると、Docker Agentic PlatformというDocker Cloud Sandboxesを操作するためのコンソールにリダイレクトします。
### 事前準備
今回はCodex、GitHub、Notionを利用するので、そのための事前準備を行います。
#### Codex
API Keyを取得して、内容を控えておきます。
#### GitHub
PATを取得します。
今回は、操作対象のリポジトリに対して、以下の画像のような最低限の権限を割り当てたPATを用意しました。
#### Notion
左側のサイドメニューからMCPの項目を選択して、Notionへの接続を行います。
私の環境では、Connectボタンを押すと自動的に接続が完了しました。
### Sandboxに接続する
サイドメニューのNewをクリックして、Sandbox環境を作成します。
ここまでで準備を適切に行っている場合は、tokenの入力と数クリックで作成が完了します。
Runボタンをクリックすると、Sandbox環境が作成されます。
### ローカルマシンからSandboxに接続する
このままブラウザ上でターミナル操作を行うこともできるのですが、今回はより実践的に、手元のローカルマシンからSandbox上を操作します。
右上のConnectボタンをクリックすると、ローカルマシンからの接続手順が表示されるので、それに従って操作をします。
> [!NOTE]
> 設定には[sbx](https://www.docker.com/products/docker-sandboxes/)コマンドを利用するため、状況に応じてセットアップを行います。
```bash
> sbx --cloud setup ssh
SSH configured. Connect with: ssh sbx_@sbx_cloud
> ssh sbx_@sbx_cloud
```
これにより、Sandbox環境に接続できます。
### リポジトリのセットアップ
この時点でSandbox環境はセットアップ直後の完全クリーンな状態なので、リポジトリのcloneを行います。
環境変数の`GH_TOKEN`を利用することで設定したPATを扱うことができるので、次のコマンドによりリポジトリのクローンが可能です。
```bash
> git clone https://${GH_TOKEN}@github.com//.git .
```
### Agentに実装を依頼する
ここまでで一通りの準備が完了したので、実際にAgentに実装を依頼してみます。
ログを追う感じ、Notion MCPの利用もできており、ローカルで動かすのと何ら変わらない感じでAgentが動いている様子が確認できました。
Pull Requestも指示通り発行してくれました。
## 補足
ここまでで一通りの開発フローが実現できることを確認しましたが、今回は触れられなかった点についていくつか補足します。
### 課金体系について
Docker Cloud Sandboxesでは、Sandbox環境の利用が秒単位の従量課金となっています。
また、AI Agentについてもサブスクライブを利用する仕組みなどはなくAPI Keyを利用した接続方式となるので、そこにも原則として課金が発生します。
なお、Sandboxについては停止していれば課金は発生しないとのことです。
そのため、利用しない時間が続く場合は都度停止するのが吉です。 (停止しても、メモリとディスクの内容は失われない)
### Secret
Secretが必要な場合は、コンソール上から設定することによりSandbox内で利用することが可能となっています。
> [!NOTE]
> Secretは、Sandbox外部に保存した上で、Sandbox内には識別子のみが渡されます。
> 利用時にはプロキシにより実値に変換されます。
### Agentのアクセス制限
Docker Cloud Sandboxesでは、Agentへのアクセス制限をPolicyという枠組みで設定することが可能となります。
今回はデフォルトで用意されているBalanced AccessというPolicyを利用しましたが、これを自前で用意して利用することができます。
### Docker
Sandbox環境にはデフォルトでDockerがインストールされていたので、Dockerを利用する開発フローでも簡単に乗っかることができます。
## まとめ
Docker Cloud Sandboxesについて、一通りの開発フローを体験することにより理解を深めることができました。
現時点ですでに非常に便利なものだと感じましたが、組織での開発用途などにおいてはさらに価値を発揮する場面がありそうです。
リリースされたばかりなので、今後の展開にも期待したいです。