2026年10月5日時点、OpenClawは既定のGatewayを「単一の信頼された運用者境界」と説明しています。つまり、信頼関係のないチームを同じGatewayに収容しても、会話の振り分けだけでは隔離できません。チームごとにGatewayのインスタンス、状態、認証情報、作業領域を分け、そのうえでMacホストを共用するか判断してください。根拠はOpenClaw公式のマルチテナント運用説明で確認できます。
今週の推奨アクション： チーム間の信頼関係を一覧化し、共有できない組み合わせから独立Gatewayの対象にしてください。
この記事は、OpenClawをMacで運用する企業IT責任者、プラットフォームエンジニア、安全管理担当者向けです。
Gateway、ノードペアリング、Agentの権限、認証情報の分離を見直し、導入時の判定と検収に使える形で整理します。
最終更新：2026年10月5日。信頼モデル、ノード権限、Fleetの状態は、本文中で参照するOpenClaw公式文書と公開時点の変更履歴で照合しています。導入時には、使用するバージョンの説明も再確認してください。
01会話を分けてもチーム境界にはならない
たとえば、プロジェクト担当者ごとに会話IDやAgentを振り分けても、同じGatewayを操作できる利用者が互いを信頼していなければ、分離要件を満たすとは限りません。会話IDはルーティングに使う識別子であり、チーム間の認可境界として扱うものではありません。OpenClawの公式文書は、単一の共有Gatewayを、信頼しない利用者同士の隔離手段と見なさないよう説明しています。
権限を細かく設定しても、役割はそれぞれ異なります。Operator scopesの説明にあるscopeは、Gateway操作の許可範囲を制御するためのものです。Agentのツールポリシーは、そのAgentに許すツールや操作を絞り込むために使います。どちらも設定の有効性を確かめる必要がありますが、別のチームに属する管理者同士を、Gatewayそのものから独立させる保証にはなりません。
境界が曖昧なまま共用を始めると、権限設定の変更、認証情報の更新、作業領域の参照可能範囲を誰が管理するのかが混線します。責任者の違うチームや、データを共有できないプロジェクトは、まず独立したGatewayインスタンスとして設計してください。
02ペアリングはコマンドごとの許可ではない
MacノードをGatewayにペアリングすると、Gatewayとノードの間に接続関係が作られます。これは、Mac上で実行できる操作を一つずつ承認したことを意味しません。公式のペアリング手順とノードのコマンド実行仕様を参照し、ペアリング後に利用可能となるノード機能を、導入中の構成で確認してください。
コマンド実行に関わる制御も一つではありません。Gatewayのノード設定で接続や機能の構成を確認し、実行承認の仕様では実行ポリシーと承認条件を個別に確認します。Gateway側の許可設定と、Mac上で適用される実行・承認条件を同じものとして扱わないでください。
さらに、OSアカウントやMac本体の共有は、Gatewayの権限設定とは別の境界です。同じMacに複数のチームがログインできるなら、各チームが参照・変更できるファイルやプロセスも確認が必要です。Macノードのリモート実行を許可する前に、担当者、実行可能な操作、承認者、監査記録の保管先を決めます。
03プラグインと認証情報は信頼域ごとに管理する
隔離対象はGatewayの設定だけではありません。モデルの認証情報、チャネルのアカウント、動的スキルの保存先、Agentの作業領域、プラグインを誰が追加・更新できるかを洗い出します。各チームの担当者が他チームの秘密情報を読めないこと、また、許可なくコードやスキルを書き換えられないことを検証してください。
OpenClawのプラグイン文書では、プラグインを信頼済みコードとして扱う前提を確認できます。スキルの文書も参照し、スキルの配置場所と変更権限を点検してください。実行環境をコンテナ化したり、Agent sandboxを有効にしたりする場合も、それだけでGatewayのマルチテナント分離が成立したと判断してはいけません。
信頼域ごとにインスタンスを分ける場合は、設定ファイルや状態保存先を分離し、認証情報の登録・更新をそれぞれの担当者に限定します。プラグインやスキルは審査済みのものだけを登録できる運用にします。共用Macを選ぶ場合も、OSアカウント、ファイルのアクセス権、実行ユーザー、ログの閲覧範囲を別に決める必要があります。
04信頼関係からGatewayとMacの構成を選ぶ
まず分けるのは、同じ物理ホストかどうかではなく、誰が同じ管理境界を信頼できるかです。判断を混同しないよう、次の表でGatewayとMacの論点を切り分けてください。
| 判断対象 | 同じ信頼域で運用する場合 | チーム間に信頼がない場合 |
|---|---|---|
| Gateway | 役割、scope、Agentツールポリシーを制限して運用を評価 | チームごとに独立したインスタンスを用意 |
| 状態・認証情報 | 管理者と参照範囲を明示 | 状態保存先、モデル・チャネルの認証情報を分離 |
| 作業領域・スキル | 書き込み担当と参照範囲を制限 | チーム別に配置し、変更権限を分離 |
| Macノード | 実行機能、OSアカウント、承認条件を確認 | Gateway分割後もMac上の共有リスクを別途評価 |
| 物理ホスト | 管理責任とOS上の境界が要件を満たすか検証 | 専有要件があれば別ホストを検討 |
OpenClawのFleet機能は、公式文書上で実験的な機能として扱われています。Fleetの説明を読んだうえで評価することはできますが、企業向けの確立した隔離保証として構成判断の根拠にしないでください。実験状態や仕様は変わる可能性があるため、採用時には該当バージョンの文書と変更履歴を照合します。
導入作業は、次の順序で進めると責任境界の抜けを見つけやすくなります。
- [ ] チームごとにデータの機密度、運用責任者、相互信頼の有無を書き出します。
- [ ] 信頼できないチームの組み合わせを抽出し、それぞれに独立Gatewayが必要か決定します。
- [ ] Gatewayごとに状態保存先、モデルやチャネルの認証情報、Agentの作業領域を分けます。
- [ ] Operator scopeとAgentのツールポリシーを確認し、許可する操作と管理者を記録します。
- [ ] Macノードのペアリング後に利用できる機能を確認し、Gateway側の実行ポリシーとMac側の承認条件を別々に試します。
- [ ] プラグインとスキルの導入・更新担当を限定し、変更履歴と認証情報へのアクセスを確認します。
- [ ] OSアカウント、ファイル権限、ログ閲覧範囲、ホストの共有可否を検証し、要件を満たさない場合はMacホストも分けます。
- [ ] 変更後に、別チームの作業領域・認証情報・ノード操作へアクセスできないことを、権限の異なる利用者で検収します。
次の比較は、構成を決める際の利点と残るリスクを簡潔に示したものです。権限を制限した共有構成は管理対象を減らせますが、信頼しないチームの分離要件を満たすものではありません。
| 構成 | 利点 | 残るリスク・確認点 |
|---|---|---|
| 共有Gateway、制限付き権限 | インスタンスの運用を集約しやすい | 信頼域が共通であることが前提。権限設定だけで独立テナントにはならない |
| チーム別Gateway、共用Mac | Gatewayの状態や認証情報を分けやすい | OSアカウント、ファイル、プロセス、ノード実行境界は別途検証が必要 |
| チーム別Gateway、別Mac | Gatewayと物理ホストの境界を分けやすい | ホストごとの管理、更新、監視が必要。実際の提供条件や運用要件との照合が必要 |
Macの共有可否は、Gatewayを分割しただけでは決まりません。OSアカウントやデータ保管、実行権限を共用できるか、また監査要件が物理ホストの分離を求めるかで判定します。Mac環境の選択肢を確認する場合は、Macの導入・注文に関する案内を参照できます。ただし、ページに記載された内容と企業の隔離要件が一致するかは、別途確認してください。
導入後の運用負荷も判断に含めます。分離構成は、認証情報の更新、プラグイン審査、ログ確認、障害対応の管理対象を増やします。一方、共用構成では、変更権限やアクセス境界の誤設定がチーム横断のリスクになります。保守責任を集約することだけを理由に、信頼の異なるチームを一つのGatewayへまとめないでください。
05よくある質問
チームごとに分けるのはGatewayだけで十分ですか？
十分とは限りません。信頼境界を分けるには、Gatewayの状態、認証情報、作業領域、プラグインやスキルの変更権限も確認します。さらにMac自体を共用する場合は、OSアカウント、ファイル権限、ログへのアクセス、ノードの実行条件を検証してください。どこまで分けるべきかは、データ保護要件と運用責任の所在で決めます。
Operator scopeをチーム別に設定すれば、共有Gatewayを安全にできますか？
Operator scopeは操作範囲を制限するための設定です。信頼しないチームを同じGatewayに置くための独立したテナント境界として扱わないでください。AgentのツールポリシーやOS上のアクセス制御も役割が異なります。共有を検討するなら、全利用者が同じ運用者境界を信頼できるかを先に判定してください。
Fleetを使えば複数のGatewayを企業向けに安全に管理できますか？
Fleetは公式文書で実験的な機能として説明されています。そのため、企業向けの分離保証や確立した運用方式として前提に置かず、対象バージョンの機能と制約を確認してから評価してください。採用判断では、独立Gatewayの状態や認証情報をどう管理するか、障害時に誰が復旧するかも合わせて検討します。
06分離要件を満たすMac構成を確認する
汎用サーバーや共有ホストは、既存の運用に組み込みやすい反面、macOS固有の実行環境を用意しにくく、OSアカウントや実機の境界も要件に合うとは限りません。チームごとにMacを購入すれば物理的な分離を取りやすくなりますが、調達、保守、余剰稼働分の管理が発生します。遠隔Macのレンタルは、必要な期間の環境を検討しやすい選択肢ですが、提供されるアクセス方式、アカウント境界、ホスト管理方法が要件に合うかを確かめてから選んでください。
まず信頼域のチェックリストで、独立Gateway、アカウント、Macホストのどこまで分ける必要があるかを確定します。そのうえで、VpsMeshのMac環境に関する案内にある情報と、実際の企業要件を照合してください。要件を満たす提供条件が確認できた場合に限り、構成や導入方法の相談へ進むのが安全です。