--- doc-schema-version: 1 read_when: - 複数のユーザーまたは組織向けに OpenClaw をホストしている場合 - テナントワークロードの分離境界を選択する必要があります summary: 複数のテナント信頼ドメインを、テナントごとに分離された1つのOpenClaw Gatewayセルとしてホストする title: マルチテナントホスティング x-i18n: generated_at: "2026-07-26T09:21:59Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 383d32331b45d40db6fb4ff8242dd9a3cf8898a3ccab19f0372cd06bbd83fc05 source_path: gateway/multi-tenant-hosting.md workflow: 16 --- # マルチテナントホスティング OpenClaw のデフォルトのセキュリティモデルは、1 つの共有 Gateway 内で敵対的なマルチテナント分離を行うものではなく、Gateway ごとに 1 つの信頼されたオペレーター境界を設けるものです。したがって、信頼境界を共有しないユーザーや組織をホストする場合は、テナントごとに完全に独立した OpenClaw インスタンスを実行する必要があります。 `openclaw fleet` では、分離された各インスタンスを **セル** と呼びます。セルは、強化されたコンテナ内で動作する完全な Gateway であり、独自の状態、認証情報、ワークスペース、チャネルアカウント、トークン、およびループバック専用のホストポートを持ちます。 Fleet は **実験的機能** です。コマンド、フラグ、コンテナプロファイルは、非推奨期間なしでリリース間に変更される可能性があります。 Fleet は Linux および macOS ホストでテストされています。Windows ホストは現在テストされていません。 ## 各テナントにセルが必要な理由 1 つの Gateway 内で認証されたオペレーターは、信頼されたコントロールプレーンの役割を持ちます。セッション ID はルーティングを選択するものであり、あるテナントを別のテナントに対して認可するものではありません。エージェントのサンドボックス化によって、信頼されていないコンテンツやツール実行の影響を軽減できますが、1 つの共有 Gateway がテナント認可境界になるわけではありません。 信頼ドメインごとに個別の Gateway プロセス、コンテナ、永続状態ツリー、Gateway 認証情報を持たせるため、テナントごとに 1 つのセルを使用してください。これは [Gateway のセキュリティモデル](/ja-JP/gateway/security)に従うものです。相互に信頼していないユーザーを、1 つの OpenClaw プロセスまたは 1 つの OS ユーザーに同居させないでください。 ## アーキテクチャ Fleet CLI はホスト側のライフサイクルスーパーバイザーです。セルを OpenClaw の状態データベースに記録し、ローカルの Docker または Podman ランタイムに、コンテナの作成、検査、起動、停止、置換、削除を要求します。Fleet のバインドパスとループバック URL はローカルホストに属するため、リモートランタイムエンドポイントはサポートされません。Fleet はテナントのメッセージをプロキシせず、セル間に共有のアプリケーションレベルのデータパスを追加することもありません。 各セルは、独自のユーザー定義ブリッジネットワーク上で公式の `ghcr.io/openclaw/openclaw` イメージを実行します。個別のブリッジにより、プロバイダーやチャネル向けのアウトバウンド NAT アクセスを維持しながら、セル間のコンテナ IP による直接通信を防止します。アウトバウンド通信はデフォルトでは制限されません。Podman セルでは `--network internal` を使用して、公開されたループバック Gateway ポートを維持しながら外向き通信をブロックできます。Docker の内部ネットワークではその公開ポートが機能しなくなるため、Fleet はこの組み合わせを拒否します。代わりに、`DOCKER-USER` チェーンなどのホストファイアウォールルールを使用して Docker の外向き通信ポリシーを適用してください。セルの Gateway はコンテナ内のポート `18789` で待ち受けますが、ランタイムはホスト上の `127.0.0.1:` にのみ公開します。リモートアクセスが必要な場合、オペレーターは承認済みのリバースプロキシ、SSH トンネル、または tailnet をそのループバックエンドポイントの前段に配置できます。 永続的な Gateway の状態は `/fleet/cells//` に保存され、`/home/node/.openclaw` にマウントされます。認証プロファイルの暗号化キーは、個別のホストパス `/fleet/auth-profile-secrets//` から提供され、`/home/node/.config/openclaw` にマウントされます。これは公式の [Docker 永続化レイアウト](/ja-JP/install/docker#storage-and-persistence)と一致します。キーは通常の状態マウントの配下には配置されません。テナントごとのチャネルアカウントは、それを所有するセル内で終端されます。Fleet は共有チャネルアカウントや受信メッセージルーターを提供しません。 公式イメージでは、デフォルトで UID 1000 の非 root ユーザー `node` が使用されます。Fleet はプライベートなバインドマウントを書き込み可能に保つため、ホストと互換性のあるユーザーマッピングを使用します。Podman は `keep-id` を使用し、rootful Docker は呼び出し元の非 root ID を使用し、rootless Docker はコンテナの root を権限のないデーモンユーザーにマッピングします。ホストで SELinux が有効な場合、Docker と Podman はプライベートな `:Z` 再ラベル付けを適用します。コンテナプロファイルは特権的なホスト機能を避け、rootless に適した構成ですが、rootless 運用はホストランタイム側の選択および前提条件であり、Fleet が自動的に有効化するものではありません。 ## 信頼境界 マルチテナンシーは、テナントを相互に保護します。Fleet オペレーターとホストは、すべてのテナントから信頼されます。侵害されたホストへの耐性は対象外です。 つまり、ホスト管理者はコンテナの構成や環境を検査し、マウントされたセルデータを読み取り、イメージを置き換え、コンテナ内に入ることができます。Gateway トークンと `--env` で渡される値は、Docker または Podman の検査を通じて管理者から参照できます。これに応じて、ホスト制御、管理アクセスのポリシー、監視、バックアップ、承認済みのシークレットマネージャーを使用してください。 ベースラインは、意図しないワイルドカードのネットワーク公開を防ぎ、一般的なコンテナ権限昇格の手段を排除しますが、信頼されていないホストを安全にするものではありません。 ## 分離レベル ホストするテナントに適した境界を選択してください。 1. **強化されたコンテナのベースライン。** Fleet はすべての Linux ケーパビリティを削除し、`no-new-privileges` を有効にし、PID、メモリ、CPU、およびオプションの書き込み可能レイヤーのディスク制限を適用し、個別の永続マウントとセルごとのネットワークを使用し、ホストのループバックにのみ公開します。ブリッジネットワークでは外向き通信が制限されません。セルからの外向き接続を禁止する必要がある場合は、Podman の `--network internal` または Docker ホストのファイアウォールポリシーを使用してください。これは、オペレーターとホストを信頼するテナント向けのデフォルトプロファイルです。 2. **より強力なコンテナまたは VM 分離。** リスクの高いワークロードでは、gVisor や Kata Containers などのより強力な OCI 分離ランタイムを使用するよう Docker または Podman を構成するか、セルを microVM に配置してください。これはランタイムまたはインフラストラクチャの構成です。Fleet の `--runtime docker|podman` オプションはコンテナ CLI を選択するものであり、OCI 分離バックエンドを選択するものではありません。Docker の [代替コンテナランタイム](https://docs.docker.com/engine/daemon/alternative-runtimes/)および [Docker VM ランタイムガイド](/ja-JP/install/docker-vm-runtime)を参照してください。 3. **敵対的なテナントには別々のマシンを使用。** 敵対的なテナントを、1 つの OpenClaw プロセスまたは OS ユーザーに同居させないでください。テナントが同じホストオペレーターを信頼していない場合や、より強力な管理境界が必要な場合は、ランタイム管理を分離した個別の VM または物理ホストを使用してください。 この分離レベルのどの段階でも、OpenClaw アプリケーションの信頼モデルは変わりません。1 つの Gateway は引き続き 1 つの信頼されたオペレータードメインです。 ## クイックスタート セルを作成します。このコマンドは生成された Gateway トークンを一度だけ表示するため、すぐに保存してください。 ```bash openclaw fleet create acme ``` Fleet ホストで表示された `http://127.0.0.1:` URL を開き、そのテナントのトークンで認証して、セル内でプロバイダーの認証情報とチャネルアカウントを構成します。 コンテナの状態と Gateway の稼働状況を確認します。 ```bash openclaw fleet status acme ``` ホストポート、マウントされたデータ、リソースプロファイル、ユーザー指定の環境、および Gateway トークンを維持したままアップグレードします。 ```bash openclaw fleet upgrade acme ``` テナントデータを保持したまま、コンテナとレジストリ行を削除します。 ```bash openclaw fleet rm acme --force ``` 永続的なテナントデータも削除するには、`--purge-data` を追加します。パージには `--force` が必要で、元に戻すことはできません。何かを削除する前に、解決済みパスの包含チェックを実行します。 ```bash openclaw fleet rm acme --purge-data --force ``` すべてのコマンドとオプションについては、[`openclaw fleet` CLI リファレンス](/ja-JP/cli/fleet)を参照してください。 ## 現在のスコープ Fleet は次の機能を提供しません。 - 共有チャネルアカウントまたは共有受信ルーター - 完全な OpenClaw インスタンスの代わりとなる、テナントごとの軽量化されたホストプロセス - 1 つのスーパーバイザーで管理されるリモートセルホスト - テナント向けセルフサービスポータル、課金プレーン、または委任管理 UI これらの機能には、明示的な ID、ルーティング、認可、および障害ドメインの契約が必要です。1 つの Gateway またはその認証情報をテナント間で共有して、これらの機能を代用しないでください。Fleet は単一ホストのライフサイクルスーパーバイザーです。複数マシンにまたがり、ID によって管理される Fleet には、別個のコントロールプレーンレイヤーが必要です。 ## 関連項目 - [`openclaw fleet`](/ja-JP/cli/fleet) - [Gateway のセキュリティ](/ja-JP/gateway/security) - [複数の Gateway](/ja-JP/gateway/multiple-gateways) - [Docker](/ja-JP/install/docker) - [Podman](/ja-JP/install/podman)