--- title: "Docker Sandboxesを触ってみる" createdAt: "2026-08-23" tags: [ソフトウェアエンジニアリング, AI, Docker Sandboxes] --- [Docker Sandboxes](https://www.docker.com/ja-jp/products/docker-sandboxes/) はコーディングエージェント向けに開発されたDockerのsandbox環境です。 ここでは、Docker Sandboxesのどのあたりがコーディングエージェント向けで、どのような特徴があるのかを見ていこうと思います。 ## 環境 - macOS Tahoe 26.6.2 - Homebrew 6.0.18 - Docker version 29.7.2 ## Docker Sandboxesのインストール Homebrewを利用して簡単にインストールできました。 ```bash > 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モードで中に入ります。 ```bash @host> sbx run --name example shell ``` そして、適当にDockerコンテナを起動してみます。 ```bash @sandbox> docker run --name example-container alpine:latest true ``` ターミナルを別タブで開いて、sandbox環境のdockerとホストのdockerを確認して、sandbox環境でのみコンテナが起動したことを確認します。 ```bash > 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などを始めとして色々対応しています](https://docs.docker.com/ai/sandboxes/agents/)。) ```bash # dockerにログイン > sbx login # CodexのOAuth認証 (これはdockerにログインしていないと出来ないので注意) > sbx secret set openai --oauth > sbx run --name docker-sandbox-tutorial codex . ``` しばらくするとCodexが起動してよく見るプロンプト入力画面が現れるので、適当に指示を書きます。 ```plain 最小構成のGo HTTP serverを作ってください。GET /healthがJSONを返すようにし、unit testとDockerfileを追加してください。その後、test、Docker imageのbuild、containerの起動、health checkまで実行してください。 ``` しばらく待つとAgentが実装を完了させて、Docker経由で動作確認を済ませてくれました。 ```plain - 最小構成の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とは隔離されて動いています。 ```bash > 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](https://docs.docker.com/ai/sandboxes/workflows/git/#direct-mode)と呼ばれるもので、作業ディレクトリをホストと読み書き可能な状態で共有します。 Agentによる変更がホスト側にも反映されるため、ホストへの影響を完全に防げるわけではありませんが、 [Clone Mode](https://docs.docker.com/ai/sandboxes/workflows/git/#clone-mode)を利用すると、Agentによる変更をホストの作業ツリーから隔離した環境で扱うことが可能となっています。 ## まとめ Docker Sandboxesを利用することで、Dockerを利用した開発や検証を従来よりもより安全に実現できることを確認しました。 特にAI Agentの利用がどんどん加速している現代のスタイルにおいて、この仕組みは非常に価値のあるものだと感じます。 頭の片隅に入れておいて、いざという時に活用できるようにしておきたいです。