複数の OpenClaw インスタンスを運用：マルチテナント Docker ガイド [2026]

1つの OpenClaw インスタンスの運用は簡単です。同じサーバーで20や50のインスタンスを実行し、それぞれが異なるユーザー向けに完全に分離され、HTTPS と独自のサブドメインを持つには計画が必要です。このガイドでは、マルチテナント OpenClaw デプロイメントのアーキテクチャ、リソース管理、運用プラクティスを解説します。これは ClawTank が数百の OpenClaw インスタンスをホスティングするのに使用しているのと同じアプローチです。

アーキテクチャの概要

各ユーザーが得るもの：

• openclaw-stack イメージを実行する専用の Docker コンテナ
• 管理されたプールからのユニークなポート（例：18800-18899）
• Caddy 経由でルーティングされるサブドメイン（例：alice.yourdomain.com）
• Let's Encrypt による自動 TLS
• 分離されたファイルシステム、ネットワーク、リソース

User A ──→ alice.yourdomain.com ──→ Caddy ──→ localhost:18800 ──→ Container A
User B ──→ bob.yourdomain.com   ──→ Caddy ──→ localhost:18801 ──→ Container B
User C ──→ carol.yourdomain.com ──→ Caddy ──→ localhost:18802 ──→ Container C

Docker コンテナのセットアップ

ユーザーコンテナの作成

docker run -d \
  --name openclaw-alice \
  --restart unless-stopped \
  -p 18800:3001 \
  -m 512m \
  --cpus=1 \
  -v openclaw-alice-data:/app/data \
  -e OPENCLAW_GATEWAY_TOKEN=alice-unique-token \
  -e ANTHROPIC_API_KEY=sk-ant-alice-key \
  openclaw/openclaw:latest

主要なフラグ：

• -m 512m — ハードメモリ制限 512MB
• --cpus=1 — 1 CPU コアに制限
• データ永続化のためのユニークなボリューム
• ユニークなゲートウェイトークン（再起動時のトークン再生成を防止）^[1]
• 各ユーザーが自分の API キーを提供

複数ユーザー向け Docker Compose

複数のコンテナを宣言的に管理する場合：

version: '3.8'

services:
  openclaw-alice:
    image: openclaw/openclaw:latest
    container_name: openclaw-alice
    restart: unless-stopped
    ports:
      - "18800:3001"
    volumes:
      - alice_data:/app/data
    environment:
      - OPENCLAW_GATEWAY_TOKEN=alice-unique-token-here
      - ANTHROPIC_API_KEY=${ALICE_API_KEY}
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '1.0'
        reservations:
          memory: 256M
          cpus: '0.25'

  openclaw-bob:
    image: openclaw/openclaw:latest
    container_name: openclaw-bob
    restart: unless-stopped
    ports:
      - "18801:3001"
    volumes:
      - bob_data:/app/data
    environment:
      - OPENCLAW_GATEWAY_TOKEN=bob-unique-token-here
      - ANTHROPIC_API_KEY=${BOB_API_KEY}
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '1.0'
        reservations:
          memory: 256M
          cpus: '0.25'

volumes:
  alice_data:
  bob_data:

実際には、各ユーザーごとに手動で YAML を編集するのではなく、この設定をプログラムで生成することが望ましいです。

ポート割り当て戦略

ポート範囲を割り当て、割り当てをデータベースまたは設定ファイルで追跡します：

新しいユーザーをプロビジョニングする際：

1. 範囲内の次に利用可能なポートをデータベースに問い合わせる
2. そのポートマッピングでコンテナを作成
3. ユーザー-ポートマッピングを保存
4. Caddy 設定を更新

体系的なアプローチにより、ポートの競合を防ぎ、どのコンテナがどのユーザーのものか簡単に見つけられます。

リソース制限とメモリ使用量

OpenClaw はどれくらいのメモリが必要か？

単一の OpenClaw コンテナはアイドル時に約200〜300MB の RAM を使用します。アクティブな使用中（メッセージ処理、スキル実行）は400〜600MB にスパイクすることがあります。ゲートウェイプロセス自体がベースライン使用量の大部分を占めます。^[2]

コンテナごとの推奨制限：

サーバーサイジング

複数インスタンスをホスティングする VPS の場合：

これらは標準的なワークロードを想定した見積もりです。ブラウザ自動化や Ralph Loop を実行するヘビーユーザーにはより多くの余裕が必要です。

リソースのオーバーコミット

すべてのユーザーが同時にアクティブになるわけではありません。コンテナごとにハード制限を設定していれば、物理的に利用可能な量より多くの合計メモリを安全に割り当てられます。Docker のメモリ制限により、単一のコンテナが利用可能な全 RAM を消費することを防ぎます。

合理的なオーバーコミット比率は 1.5 倍です。16GB の RAM がある場合、コンテナ全体で最大24GB を割り当てられます。スワップ使用量を監視し、サーバーが頻繁にスワップしている場合は比率を下げてください。

自動 TLS 付き Caddy リバースプロキシ

Caddy はサブドメインごとに TLS 証明書を自動処理するため、マルチテナントセットアップに理想的です^[3]。

Caddyfile の構造

alice.yourdomain.com {
    reverse_proxy localhost:18800
}

bob.yourdomain.com {
    reverse_proxy localhost:18801
}

carol.yourdomain.com {
    reverse_proxy localhost:18802
}

Caddyfile の再生成

ユーザーが追加または削除された時は、データベースから Caddyfile 全体を再生成してリロードします：

# データベースから Caddyfile を生成
./generate-caddyfile.sh > /etc/caddy/Caddyfile

# adapter フラグ付きでリロード（重要！）
caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile

リロード時には必ず --adapter caddyfile フラグを使用してください。これがないと、Caddy がサイレントに失敗する可能性があります。

DNS セットアップ

サーバーを指すワイルドカード DNS A レコードを作成します：

Type: A
Name: *.yourdomain.com
Value: YOUR_SERVER_IP
TTL: 300

Cloudflare ユーザーへの重要な注意： Cloudflare の無料プランはプロキシされたワイルドカード DNS をサポートしていません。レコードを Proxied ではなく DNS only（グレーのクラウドアイコン）に設定してください。Caddy が Let's Encrypt の HTTP-01 チャレンジ経由で直接 TLS を処理します。

信頼済みプロキシ

すべての OpenClaw コンテナは Caddy プロキシを信頼する必要があります。コンテナセットアップに含めてください：

docker exec openclaw-alice openclaw config set gateway.trustedProxies '["127.0.0.1"]'

または docker-compose.yml で環境変数として設定してください。

セキュリティ分離

Docker が提供するもの

• ファイルシステム分離 — コンテナは互いのファイルにアクセスできません
• プロセス分離 — あるコンテナは別のコンテナのプロセスを見たりキルしたりできません
• ネットワーク分離 — コンテナは明示的にマッピングされたポートを通じてのみ通信します
• ユーザーネームスペースマッピング — コンテナ内の root がホスト上の非特権ユーザーにマッピングされます

追加のハードニング

docker run -d \
  --name openclaw-alice \
  --read-only \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt no-new-privileges \
  -v openclaw-alice-data:/app/data \
  ...

• --read-only — マウントされたデータボリュームを除きファイルシステムが読み取り専用
• --cap-drop=ALL — すべての Linux ケーパビリティを削除
• --no-new-privileges — コンテナ内での特権エスカレーションを防止

API キーの分離

各ユーザーが自分の AI プロバイダー API キーを提供します。ユーザー間で単一の API キーを共有しないでください。請求のあいまいさと単一障害点を作り出します。あるユーザーのキーが取り消されたりレート制限されたりしても、影響を受けるのはそのインスタンスだけです。

監視

コンテナヘルスチェック

応答のないコンテナを検出するためにヘルスチェックを追加します：

docker inspect --format='{{.State.Health.Status}}' openclaw-alice

リソース使用量

コンテナごとのメモリと CPU を監視します：

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}"

cron ジョブで実行し、コンテナがメモリ制限の90%を超えた場合にアラートを出してください。

ログ集約

デバッグのためにすべてのコンテナからログを収集します：

docker logs --tail 50 openclaw-alice

本番セットアップでは、コンテナログを集中システム（Loki、ELK、またはシンプルなログローテーションセットアップ）に転送してください。

スケーリングの考慮事項

垂直スケーリング

最もシンプルなアプローチ：より大きな VPS にアップグレードします。4GB から 16GB RAM に移行すれば、他に何も変更せずに10ユーザーから50ユーザーに対応できます。

水平スケーリング

単一サーバーでは不十分な場合：

1. 複数のサーバーの前にロードバランサー（または DNS ベースのルーティング）を配置
2. 各サーバーがユーザーコンテナのサブセットを実行
3. 中央のデータベースがどのユーザーがどのサーバーにいるかを追跡
4. 各サーバーで Caddy が動作し、自身のユーザー用の TLS を処理

コンテナオーケストレーション

100ユーザー以上の場合、自動スケジューリング、スケーリング、フェイルオーバーのために Kubernetes または Docker Swarm を検討してください。トレードオフは大幅な運用の複雑さです。

100ユーザー未満のほとんどのデプロイメントでは、このガイドで説明したアプローチによる適切にプロビジョニングされた単一サーバーの方がシンプルで十分です。

ClawTank に任せる

このガイドで説明したすべて（コンテナプロビジョニング、ポート割り当て、Caddy 設定、TLS、リソース制限、監視）は、まさに ClawTank が自動化していることです。各ユーザーが自動 TLS、リソース保証、管理ダッシュボード付きの分離されたコンテナを得ます。インフラを自分で構築せずに OpenClaw ホスティングを他の人に提供したい場合、ClawTank はすぐに使えるプラットフォームです。

参考文献

1. OpenClaw Docker Setup Guide
2. OpenClaw System Requirements
3. Caddy — Automatic HTTPS
4. Docker Resource Constraints Documentation
5. Docker Security Best Practices