--- read_when: - 複数のユーザーまたは組織向けにOpenClawをホストしている場合 - テナントワークロードの分離境界を選択する必要があります summary: テナントごとに分離された OpenClaw Gateway セルを1つずつ配置し、複数テナントの信頼ドメインをホストする title: マルチテナントホスティング x-i18n: generated_at: "2026-07-12T14:34:45Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 15 provider: openai source_hash: 5ffb873c7b9e7e463d932ad35eb009c34218447a051ac065c151ba57dc71b799 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 MVP には共有チャンネルアカウントや共有受信メッセージルーターはありません。 公式イメージのデフォルトは、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 ホストのファイアウォールポリシーを使用してください。これは、オペレーターとホストを信頼するテナント向けの MVP プロファイルです。 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 リファレンス](/cli/fleet) を参照してください。 ## MVP で延期される機能 最初の Fleet リリースでは、意図的に次の領域を将来の設計に委ねています。 - 共有チャンネルアカウントまたは共有受信ルーター - 完全な OpenClaw インスタンスではなく、テナントごとに軽量化されたホストプロセス - 1 つのスーパーバイザーによって管理されるリモートセルホスト - テナント向けセルフサービスポータル、課金プレーン、または委任管理 UI これらの機能には、明示的な ID、ルーティング、認可、および障害ドメインの契約が必要です。1 つの Gateway またはその認証情報をテナント間で共有することで代用すべきではありません。また、これらは Fleet の対象領域でもありません。Fleet は単一ホストのライフサイクルスーパーバイザーに留まり、複数マシンで構成され、ID によって管理される Fleet は、その上位にある専用のコントロールプレーン層が担います。 ## 関連項目 - [`openclaw fleet`](/cli/fleet) - [Gateway のセキュリティ](/ja-JP/gateway/security) - [複数の Gateway](/ja-JP/gateway/multiple-gateways) - [Docker](/ja-JP/install/docker) - [Podman](/ja-JP/install/podman)