2026 年、remote Mac 上の OpenClaw を分散チームが安全に利用する:
Gateway と Control UI の SSH ローカル転送、TLS リバースプロキシ、ベアメタル M4 Pro の六地域マトリクス

シンガポール/日本/韓国/香港/米東/米西ベアメタル remote Mac mini M4 ProOpenClawが安定稼働したあと、次に壊れやすいのはモデル上限ではなく、18789GatewayControl UI誰がどの経路で開くかという運用設計です。本稿ではループバック限定、SSH ローカルポートフォワード、TLS リバースプロキシとアクセス制御までを段階表に整理し、メンバーの居住地域とモデル/データの位置関係から六地域の主機をどこに置くかの採点表、さらに変更管理に貼れる十二ステップのランブックを示します。料金と在庫は料金ページ、申し込みは注文ページ、接続方針の補足はヘルプセンターを正とします。Webhook 向けのチャネルとリバースプロキシの記事、マルチワークスペースの記事、SSH と VNC の安全記事とあわせて読むと証明書とポートの方針が一本化されます。

読了後に答えられるようになる三点です。第一に、既定はループバック上の 18789を維持し、メンバーはSSH トンネルで寄せるか、ブラウザの鍵アイコンが必須のTLS 公開名まで上げるか。第二に、オペレータがアジアと北米に割れるとき、主制御ホストをどの都市の Mac に置くとモデル往復とインシデント操作の RTT が同時に抑えられるか。第三に、外注に一時閲覧を渡すとき、時間枠付きのユーザまたはワークスペース~/.openclawの本番資格情報を分離できるかです。インストール手順や CLI の意味はリリースで変わり得るため、以下のコマンド断片は構造例として扱い、導入後は必ず公式ドキュメントで再確認してください。

第一の落とし穴は、18789 をそのまま公網に出すのに、社内の本人確認と整合した認証層を置かないことです。スキャンでログが埋まり、本当の異常が見えなくなります。第二は、同一 macOS ユーザーで Gateway とブラウザ操作を共有し、外注の深夜の設定変更が本番チャネルに静かに波及し、翌朝も変更者が特定できないことです。第三は、手順書が「ブラウザを開く」だけで、ノート PC のループバックなのかScreen Sharing 先のループバックなのかリバースプロキシのホスト名なのかを書き分けていないことです。NAT と踏み台の組み合わせで一時間溶け、Gateway は健康なままというパターンが起きます。

第四はSSH の黙断です。Keepalive を置かないと昼休みでローカル転送だけが落ち、デーモンは生きているのに「落ちた」と誤認して再起動が連鎖します。第五はディスク競合です。大きなエクスポートや添付のダウンロードを 256GB ボリュームに積み上げると空き容量が揺れ、構造化ログの書き込みが一瞬止まってモデル遅延に見えることがあります。これらを変更審査のチェックリストに載せるほうが、追加のファイアウォール穴を議論するより安上がりです。

  • 公網の素ポート:スキャン騒音と設定ミスのコストが高い。
  • ホーム共有:資格情報とプラグイン境界が曖昧で監査に弱い。
  • URL 語彙の不一致:手順と実際の入口がずれる。
  • Keepalive なし SSH:トンネルだけが静かに死ぬ。
  • ログとキャッシュの衝突:大容量コピーと Gateway ログが同一ボリュームで争う。
  • 地域分散オペレータ:クリック主体のメンバーから遠い Mac は検証時間を延ばす。

チーム接続の本質はポート開放ではなく、経路に名前を付け、監査し、契約終了時に巻き戻すことです。

信頼半径で段階化します。L0 は機械上のループバックと限定的な Screen Sharing に留めます。L1 は各エンジニアが SSH で 18789 を自分の PC のループバックへ運びます。L2 は自社管理の縁で TLS を終端し、上流はループバックかプライベート IP に限定します。L3 は公開 DNS と証明書と許可リストを前提にします。小規模チームは L1 か L2 を既定にし、デモや外部 Webhook など理由が明文化された場合だけ L3 を選ぶのが無難です。

OpenClaw Gateway/Control UI のチーム経路対照(2026 現場メモ)
観点 A・ループバックと Screen Sharing のみ B・SSH ローカルポートフォワード C・TLS リバースプロキシとアクセス制御
向き先 単独保守、短時間障害、外注なし SSH 鍵と踏み台運用が既にあるチーム ブラウザの鍵アイコンや SSO 前置が必須な関係者
露出 最小だが共同作業に弱い 中程度、鍵運用と踏み台ログに依存 証明書と上流パッチの運用負荷が増える
監査性 GUI のみだと弱い 踏み台と SSH ログでユーザーと紐付けやすい プロキシログでホスト名とクライアント IP を追いやすい
六地域 データとモデルに近いノードを優先 オペレータ多数派の RTT が最小のノードを主機に TLS 終端を Mac に近づけ二重の越境 TLS を避ける

マルチワークスペースでポートとディレクトリを分けている場合は、その境界と入口 URLを一致させます。サンドボックス用ワークスペースの Control UI だけを外注に見せ、本番ワークスペースの管理 URL を混在させないことが重要です。

既定はSSH でループバックへ寄せる。TLS はブラウザ要件が本当に出たときに昇格させます。

ローカル転送は、リモート Mac 側のリスナをループバックに留めたまま、各メンバーが自分の PC のhttp://127.0.0.1:18789を開く形です。手順書に書きやすく、鍵失効で一括に戻せます。TLS が必要なら、縁側で証明書を終端し、上流はループバックかプライベート IF のみにします。管理用ロケーションとデモ用ロケーションを分け、デモ側だけ短い証明書寿命と狭い許可リストを適用します。ゼロトラストクライアントを強制する企業では、制御面が落ちたときの避難経路として SSH 手順を残しておくと夜間の孤立が減ります。

公式のinstall.shopenclaw onboard --install-daemonopenclaw gateway statusopenclaw dashboardの意味は公式ドキュメントを正とします。以下は参照リンクです。リリース採用後は必ず再確認してください。

https://docs.openclaw.ai/getting-started

https://github.com/openclaw/openclaw

ssh-local-forward.example
ssh -N \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
  -L 18789:127.0.0.1:18789 \
  user@novakvm-remote-host.example

ディスクは Gateway ログと人間の大容量ダウンロードを分け、256GB 構成では週次の空き確認を推奨します。オペレータと Mac が遠い場合は、再起動とステータス確認を短いスクリプト化し、体感 RTT に依存しない手順にします。

  1. 段階表を固定する:L0〜L3 の責任者と禁止事項を一枚にまとめます。
  2. 公式 CLI を記録する:メンテナンス窓でopenclaw gateway statusを取得し変更票に添付します。
  3. ユーザまたはワークスペースを分離する:外注と本番の書き込み権限を共有しません。
  4. SSH 設定を配布する:LocalForwardと Keepalive とIdentityFileを標準化し、0.0.0.0 へのバインドを禁止します。
  5. ブラウザ手順を固定する:SSH のあとhttp://127.0.0.1:18789とだけ書きます。
  6. 必要なら TLS を追加する:専用ホスト名を切り、上流はループバック、アクセスログを有効にします。
  7. アプリ層の制御を重ねる:IP 許可、静的トークン、SSO 前置など、秘密 URL だけに頼りません。
  8. 切断ドリルを行う:ローカル転送を落とし、五分以内に手順どおり復旧できるか検証します。
  9. ディスク水位を監視する:~/.openclawとログルートに閾値を置きます。
  10. 六地域を採点する:オペレータの都市、モデル地域、データ所在地を重み付けし合計が最小のノードを主機にします。
  11. 並列リソースを検討する:常時 Gateway と重いデバッグが衝突するなら料金ページの並列構成と比較します。
  12. 四半期レビューする:プロキシと SSH ログから未知のクライアントを抽出します。

以下は現場でよく使う前提であり、ビルドごとの保証ではありません。アップグレードのたびに公式ドキュメントでポートとフラグを再確認してください。

  • 既定 Gateway ポート:コミュニティのトラブルシュート例は18789に集約されがちです。変更したらブックマークとヘルスチェックも一括更新します。
  • SSH Keepalive:ServerAliveInterval=30ServerAliveCountMax=3の組み合わせは長距離回線の黙断を減らします。プロセス監視は別途置きます。
  • TLS 寿命:デモ用ホスト名は短寿命証明書にし、鍵漏えい時の影響面を抑えます。
  • 越境 RTT:Mac がアジアにありクリック主体が米東なら、単純な再起動確認でも往復が伸びます。主機は多数派に寄せるのが得策です。

FAQ:

  • Q:18789 を公網に出してパスワードだけでは?A:最後の手段として扱い、TLS と許可リストと本人確認を積み、セキュリティ審査を通します。
  • Q:外注は一瞬だけ見るので SSH は省略?A:時間枠付きの読み取り専用スコープを切り、可能なら企業アクセス基盤経由にします。
  • Q:Webhook チャネル記事との違いは?A:チャネルは外向きトラフィック、本稿は人間のコンソールです。証明書方針は一つの変更票にまとめます。
  • Q:M4 と M4 Pro?A:軽作業は M4 でも足りることが多く、常時複数ワークスペースとデスクトップ併用は M4 Pro 側が現実的です。詳細は料金ページを参照します。

Screen Sharing だけでは帯域と監査ログと同時操作に弱く、素の公網ポートはコンプライアンスとスキャン騒音に弱く、オフィス所有機だけでは短期の越境ピークと経路の予測可能性に弱い場面があります。OpenClaw と iOS CI と AI エージェント自動化を本番品質の Apple Silicon に載せ、人間が Gateway と Control UI を安全に開く物語まで一緒に設計したいチームにとって、NOVAKVM の Mac mini ベアメタルレンタルはしばしばより良い運用解です。六地域、独占ハード、日次や週次での検証から月次の定常運用、必要に応じた M4 Pro 高メモリと並列リソースまでを同じ変更管理の中で扱えます。次の会議では、既定経路をSSH ループバック優先と一行で決め、TLS は名前付きオーナーがいるときだけ昇格させてください。追加の穴を開ける議論より、夜間の驚きを減らせます。