はじめに
OpenClawをはじめとするAIエージェントの普及により、自然言語でローカル環境の操作を自動化することが容易になりました。しかし、これらのエージェントにシェルの実行権限を渡すことは、事実上のリモートコード実行（RCE）を許可することと同義です。
本記事では、Dockerが提案する「Docker Shell Sandboxes」と軽量エージェント「NanoClaw」を組み合わせることで、AIエージェントのリスクを最小化しながら活用する方法を解説します。
この記事でわかること
- NanoClawとは何か、OpenClawとの違い
- Docker Shell Sandboxesの仕組み
- コンテナ突破（コンテナ脱出）とは何か
- 実際にNanoClawを安全なサンドボックス上で動かす手順
AIエージェントを業務や検証環境で活用したい方にとって、安全設計の具体例として参考にしていただけると幸いです。
NanoClawとは何か：OpenClawとの違い
NanoClawは、先行して注目を集めたOpenClawの設計思想を継承しつつ、極限まで軽量化とセキュリティを追求したAIアシスタントです。
OpenClawが多機能かつ大規模なコードベース（数万行単位）を持つのに対し、NanoClawは数千行程度のTypeScriptで構成されています。
OpenClawから着想を得ていますが、より「監査しやすく、カスタマイズしやすい」ことを目的としてゼロから設計し直された別プロジェクトです。コード規模が小さいことは、そのままセキュリティレビューのしやすさにつながります。
対応するAIモデル
NanoClawはAnthropicのClaude Agent SDKをベースとしていますが、OpenRouterを介することで、OpenAI、Google Gemini、Llama 3、DeepSeekなど、主要なLLMプロバイダーのモデルを動かすことが可能です。
ただし、ツール呼び出し精度やプロンプトインジェクション耐性の観点から、現時点ではAnthropic系モデルの利用が推奨されています。
コンテナ突破（Container Escape）とは何か
まず前提として「コンテナ突破（Container Escape）」とは、コンテナ内で実行されているプロセスが、本来隔離されているはずのホストOS側へ影響を及ぼしてしまう脆弱性や攻撃手法のことを指します。
通常のDockerコンテナはホストOSのカーネルを共有しているため、カーネルの脆弱性や設定不備を突かれると、コンテナ外のリソースへアクセスされる可能性があります。
AIエージェントのように「未知のコードを自動生成して実行する仕組み」を動かす場合、このリスクは無視できません。
Docker Shell Sandboxes：MicroVMによる強力な隔離
今回の肝となるのが、実行環境に「コンテナ」ではなく「MicroVM」を採用している点です。
MicroVMとは
通常のDockerコンテナは、ホストOSのカーネルを共有し、Namespaceなどの機能によって論理的に隔離されています。
これに対し、MicroVM（Firecrackerやlibkrun等）は、仮想化技術を用いて独自のカーネルを持つ軽量な仮想マシンを起動します。
通常のコンテナとの違い
通常のコンテナは軽量ですが、前述のコンテナ突破リスクがゼロではありません。
一方、MicroVMはホストOSから独立したカーネルとリソース空間を持ちます。つまり、エージェントがサンドボックス内でどれほど破壊的な操作を行っても、ホスト側のファイルシステムやプロセスには直接影響を与えません。
※コンテナからは起動時に明示的にマウントしたディレクトリのみが見えます
AIエージェントを動かす環境としては、理想的な隔離レベルと言えます。
認証情報の流出を防ぐ「Dockerプロキシ」の仕組み
AIエージェント運用時のもう一つのリスクがAPIキー管理です。
通常、コンテナ内でLLMを呼び出すには環境変数にAPIキーを設定します。しかしこれは、エージェントに「キーを盗み外部へ送信する隙」を与えることになります。
Docker Shell Sandboxesに搭載された「Dockerプロキシ（認証プロキシ）」は、この問題を解決します。
- ホスト側での保持: APIキーはホストマシンのセキュア領域に保存され、サンドボックス内には渡されません。
- リクエストの傍受: サンドボックス内のエージェントがLLM APIへリクエストを送ると、Dockerプロキシがこれをインターセプトします。
- キーの注入: プロキシがリクエストにAPIキーを動的に付与します。
- 安全性の確保: エージェントはAPIキーそのものを知ることができません。
これにより、プロンプトインジェクション経由でのキー漏洩リスクを根本から低減できます。
実践：WhatsAppからNanoClawを動かす手順
NanoClawの特徴の一つは、WhatsAppをインターフェースとして利用できる点です。
1. 前準備
- Docker Desktop 4.58以降をインストール
- 設定で「Docker Sandboxes」を有効化
- Node.js v20以降をインストール
2. インストールと初期設定
# NanoClawのインストール
npm install -g @qwibit/nanoclaw
# 初期設定（APIキーなどの入力を求められます）
nano-claw onboard
3. WhatsAppへのログイン
nano-claw channels login
実行するとターミナルにQRコードが表示されます。スマートフォンのWhatsAppアプリから「リンクされたデバイス」を開き、QRコードをスキャンしてペアリングします。
4. Docker Shell Sandboxでの実行
# サンドボックスを起動し、NanoClawを実行
docker sandbox run shell --name nanoclaw-env
サンドボックス内でNanoClawのゲートウェイを起動し、WhatsAppからの指示を待ちます。
5. 動作確認
WhatsAppから以下のように送信します。
- 入力: 「現在のディレクトリにあるファイルの一覧を表示して」
- 動作: サンドボックス内で
lsコマンドが実行され、結果が返信されます。
結論：AIエージェントは「隔離」して飼う時代へ
利便性と引き換えに、私たちは常にセキュリティリスクを抱えています。特に実行権限を持つAIエージェントにおいては、「信頼する」のではなく「隔離する」という設計思想が不可欠です。
Docker Shell SandboxesとNanoClawの組み合わせは、AIエージェントを安全に活用するための現実的かつ強力な選択肢です。
今後、社内検証環境や開発補助エージェントを導入する際には、「どこで動かすか」という視点をぜひ設計に組み込んでみてください。
参考リンク