10月22日、Oleg Selajevが「Run Collaborative AI Agents in Docker Sandboxes」と題した記事を公開した。注目すべき点は二つある。一つは、APIキーなどのクレデンシャルがエージェント自身には見えないという設計。もう一つは、ローカルワークスペースへのアクセスが必要なエージェントだけをDockerサンドボックスで動かせばよく、他のエージェントはクラウドに置いたまま同じルームで協調できるという構成の柔軟さだ。DockerサンドボックスとBAND AIを組み合わせて、複数のAIエージェントをチームとして協調動作させる手法を詳しく紹介している。
「孤立したエージェント」から「チームのメンバー」へ
AIエージェントをDockerのサンドボックス内で安全に実行する仕組みは以前から存在していたが、そこには一つの壁があった。エージェントが隔離されているがゆえに、他のエージェントや人間と連携しにくいという問題だ。
BAND AIのDockerサンドボックス向けキット（docker.io/bandhq/band-python-kit:latest）はこの問題に対応する。サンドボックス内で動くエージェントを「BANDルーム」と呼ばれる共有空間に接続し、人間や他のエージェントとリアルタイムで協調できるようにする。エージェントはどこで動いていても構わない——ローカル、クラウド、自社インフラ——すべてが同じルームに集まれる。
BAND AIは、AIエージェント同士および人間との協調を支援するプラットフォームで、エージェントへの永続的な識別子（ハンドル）の付与、共有ルームへの参加管理、@mentionによるタスクルーティング、メッセージ履歴の管理、ツール実行イベントの可視化といった協調レイヤーをまとめて提供する。クラウドホスト版とセルフホスト版の両方に対応しており、既存のインフラに組み込みやすい設計になっている。
Dockerサンドボックスが提供するもの
Docker Sandboxesは、独立したmicroVMを提供する。microVMとは、通常のDockerコンテナよりも強い分離レベルを持つ軽量な仮想マシンのことで、各VMは専用のカーネル、ファイルシステム、Dockerデーモン、ネットワークスタックを持つ。コンテナがホストOSのカーネルを共有するのに対し、microVMはカーネルレベルから分離されているため、エージェントが予期しない操作をホスト環境に及ぼすリスクが大きく下がる。
エージェントはそのmicroVM内でローカルのソースファイルを読み書きし、テストを実行し、マウントされたワークスペースを変更する。外部からサンドボックスに接続する必要はなく、すべての通信はエージェント側からのアウトバウンドのみ。エージェントがBANDへWebSocket接続を開き、REST API経由でメッセージを送るだけだ。
Humans (BAND Desktop)
|
v
+------ BAND (cloud or self-hosted) ------+
| BAND API <--> Room --> Transcript |
+-----------------------------------------+
^
| REST + WebSocket
| (opened from your machine)
Your machine |
+-------------|---------------------+
| Docker Sandbox microVM |
| | |
| mounted workspace |
+-----------------------------------+
ハンズオン：Repo Doctorを動かす
記事の核心は、「Repo Doctor」という具体的なエージェントを使ったチュートリアルだ。Repo Doctorは意図的に壊されたPythonプロジェクトを修復するエージェントで、ローカルのDockerサンドボックス内で動きながらBANDルームに参加する。
動かすために必要なものは以下の3つだ：
- Docker Sandboxesのインストールとサインイン
- BANDアカウント
- AnthropicのAPIキー（Claudeを使用）
まずリポジトリをクローンする：
git clone https://github.com/dockersamples/band-ai-sbx-demo.git
cd band-ai-sbx-demo
次に、シークレットをサンドボックスに登録する。ここが本構成の重要なポイントだ。実際のキーはホスト側に保持され、アウトバウンドリクエストに動的に挿入される。エージェントはプレースホルダー値しか見えない——つまり、エージェントが侵害されてもクレデンシャルが漏洩しない：
sbx secret set-custom \
--sandbox band-repo-doctor \
--host '**.band.ai' \
--env BAND_API_KEY \
--placeholder proxy-managed
sbx secret set-custom \
--sandbox band-repo-doctor \
--host api.anthropic.com \
--env ANTHROPIC_PROXY_KEY \
--placeholder sk-ant-proxy-managed
サンドボックスをBANDキットで作成し、Claude APIへのアクセスを許可する：
sbx create --name band-repo-doctor \
docker.io/bandhq/band-python-kit:6.0.0 "$PWD"
sbx policy allow network --sandbox band-repo-doctor api.anthropic.com
エージェントを起動する：
sbx run --name band-repo-doctor
ログに「Connected to platform」が表示されたら、BANDルームにRepo Doctorを追加し、ハンドルを@mentionするだけでタスクを渡せる。
エージェントの設定はband.yamlに記述する。どのエントリーポイント（main.py）を起動するか、どのツールを持たせるか（ファイル読み書き、テスト実行など）をここで定義する。モデルはClaudeに限らず、他のコーディングエージェント向けアダプターにも対応している。
複数エージェントの構成例
Repo Doctorは単一エージェントのデモだが、BANDルームはより大規模な構成も扱える。記事では以下のようなパターンが紹介されている：
BAND room
|-- Planner agent (hosted)
|-- Research agent (hosted)
`-- @<your-user>/repo-doctor
|
v
local Docker Sandbox
|
your workspace
プランナーエージェントが変更計画を立て、リサーチエージェントにAPI調査を依頼し、リポジトリへのアクセスが必要になった段階でRepo Doctorを@mentionする。ローカルワークスペースへのアクセスが必要なのはRepo Doctorだけなので、Dockerサンドボックスで動かすエージェントはそれだけでよい。他のエージェントはクラウドで動いていても問題ない。この「必要なエージェントだけをサンドボックスに限定する」という設計は、インフラコストと管理複雑度の両面で合理的だ。
エージェントのコンテキストは、自分宛ての@mentionが含まれるメッセージのみに絞られる。ルーム全体の会話ログは人間が確認できる。エージェント間の接続はWebSocketとルームのメンションが全てであり、エージェントのID管理、ルーティング、クレデンシャル管理、監査ログといった仕組みを自前で構築する必要がない点が特徴だ。
関連リソース
- BAND Python SDK（GitHub） — SDKとキットのソース
- Repo Doctorサンプル（Docker Samples） — エージェント、フィクスチャ、スクリプト一式
- Docker Sandboxes ドキュメント — 設定、クレデンシャル、ネットワークルールの詳細
詳細はRun Collaborative AI Agents in Docker Sandboxesを参照していただきたい。
