2026-08-23

Docker Sandboxesを触ってみる

Docker Sandboxes はコーディングエージェント向けに開発されたDockerのsandbox環境です。

ここでは、Docker Sandboxesのどのあたりがコーディングエージェント向けで、どのような特徴があるのかを見ていこうと思います。

環境

macOS Tahoe 26.6.2
Homebrew 6.0.18
Docker version 29.7.2

Docker Sandboxesのインストール

Homebrewを利用して簡単にインストールできました。

> brew trust docker/tap

> brew install docker/tap/sbx

> sbx version
sbx version: v0.39.0 def8cb0523a77e757bdd6ef52b459fe374f3783e

このsbxというのがDocker Sandboxesのコマンドとなります。以下ではこのsbxを利用していくつかの検証を行なっていきます。

Docker Sandboxesの特徴

Docker Sandboxesは名前の通り、Dockerのsandbox環境を提供してくれます。要するに、安全にDockerを利用できる環境を提供してくれるということです。

Docker Sandboxesを利用すると、sandboxごとに用意されたDocker Engineを利用することができます。ホストのDocker daemonとは隔離されているため、悪意のあるソフトウェア等がDockerを経由してホストマシンや他のコンテナへ影響を与えるリスクを大きく低減できるというのがコアコンセプトとなっています。

この特徴は、良くも悪くも縦横無尽に動き回ることのできるAI Agentとの相性が良いです。安全性のよくわからないソフトウェアなどを動かしたい場合、Docker Sandboxesの枠組みを利用することで、ホストマシンへのリスクを抑えることができます。

sbxコマンドを使ってみる

よりDocker Sandboxesへの解像度を高めるために、まずは簡単な例を用いてsbxコマンドを利用してみます。

はじめに、以下のコマンドでsandbox環境を作成してshellモードで中に入ります。

@host> sbx run --name example shell

そして、適当にDockerコンテナを起動してみます。

@sandbox> docker run --name example-container alpine:latest true

ターミナルを別タブで開いて、sandbox環境のdockerとホストのdockerを確認して、sandbox環境でのみコンテナが起動したことを確認します。

> sbx exec example \
	docker ps -a --filter name=example-container
CONTAINER ID   IMAGE           COMMAND   CREATED              STATUS                          PORTS     NAMES
110a49a144ac   alpine:latest   "true"    About a minute ago   Exited (0) About a minute ago             example-container

> docker ps -a --filter name=example-container
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

確かに、sandbox環境上でのdockerはホスト側のdockerとは隔離されて動いていることが結果から分かります。

例えば、適当にDockerfileを書いて、sandbox環境で動かしてみて安全性を確認する、みたいなことがDocker Sandboxesを利用すると簡単にできます。これは結構嬉しい場面がありそうです。

AI Agentとの連携

Docker Sandboxesには、AI Agentといい感じに連携して動作する機能が実装されているので、それも試してみます。

適当な空のディレクトリに移動して、以下のコマンドを実行します。 (私はcodexを利用しているのでcodexを指定していますが、他にもclaude codeなどを始めとして色々対応しています。)

# dockerにログイン
> sbx login

# CodexのOAuth認証 (これはdockerにログインしていないと出来ないので注意)
> sbx secret set openai --oauth

> sbx run --name docker-sandbox-tutorial codex .

しばらくするとCodexが起動してよく見るプロンプト入力画面が現れるので、適当に指示を書きます。

最小構成のGo HTTP serverを作ってください。GET /healthがJSONを返すようにし、unit testとDockerfileを追加してください。その後、test、Docker imageのbuild、containerの起動、health checkまで実行してください。

しばらく待つとAgentが実装を完了させて、Docker経由で動作確認を済ませてくれました。

- 最小構成のGo HTTPサーバーを実装し、Docker上でのヘルス

  チェックまで完了しました。

  - main.go:13: {"status":"ok"} を返却
  - main_test.go:9
  - Dockerfile:1: マルチステージビルド、非root実行、
    HEALTHCHECK付き

  - go test ./...: 成功
  - go vet ./...: 成功
  - Docker image minimal-go-health:local: ビルド成功
  - Container minimal-go-health-check: 起動中、healthy
  - 公開先: http://127.0.0.1:32768/health
  - 実際の応答: HTTP 200 OK / {"status":"ok"}

  停止する場合:

  docker stop minimal-go-health-check

もちろん、ここで立ち上がったコンテナもホストのdockerとは隔離されて動いています。

> sbx exec docker-sandbox-tutorial docker ps -a
CONTAINER ID   IMAGE                     COMMAND     CREATED          STATUS                    PORTS                       NAMES
ab68cee6fc5b   minimal-go-health:local   "/server"   11 minutes ago   Up 11 minutes (healthy)   127.0.0.1:32768->8080/tcp   minimal-go-health-check

> docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

これは素晴らしいですね。 Agentが自分で実装、動作環境は隔離された安全なところで行うという一連の動作がローカルで完結しています。

なお、今回扱ったのはデフォルトのDirect Modeと呼ばれるもので、作業ディレクトリをホストと読み書き可能な状態で共有します。 Agentによる変更がホスト側にも反映されるため、ホストへの影響を完全に防げるわけではありませんが、 Clone Modeを利用すると、Agentによる変更をホストの作業ツリーから隔離した環境で扱うことが可能となっています。

まとめ

Docker Sandboxesを利用することで、Dockerを利用した開発や検証を従来よりもより安全に実現できることを確認しました。

特にAI Agentの利用がどんどん加速している現代のスタイルにおいて、この仕組みは非常に価値のあるものだと感じます。

頭の片隅に入れておいて、いざという時に活用できるようにしておきたいです。