データ所在地とレイテンシの都合で「OpenClawのGatewayはカナダの遠隔Mac M4に一本化し、東京やシンガポールのメンバーはクライアントだけ持つ」構成は、2026年時点でも現場で増えています。本稿の焦点は、公開インターフェースを増やさずに18789へ到達させる二経路──手元macOSからのssh -L（いわゆるRemote over SSHの裏側で動くローカルフォワード）と、TailscaleなどのゼロトラストTailnet越しの100.x直叩き──と、ブラウザで見るDashboardの入口整合、跨洋チームに配るgateway.remote.tokenの寿命設計、そして127.0.0.1束ねを崩さないLaunchAgent常駐です。7×24のLaunchDaemon寄りの定番手順はOpenClaw 2026をリモートMacで安定運用 — 導入スクリプトとonboard、Gateway 18789／トークン／LaunchDaemon、ログ対照表、カナダ中高配M4の7×24に譲り、ここでは「ログインユーザ文脈で動かしたい」「DashboardのCookieとAPIトークンを混同しない」ケースに寄せます。経路比較の別解はOpenClaw 2026：カナダのリモートMac M4でSSHトンネルと直結ゲートウェイのどちらを選ぶ？gateway.remote.token・18789・PATH／launchdの手順と排障対照、太平洋協業の予算感は2026年リモートMacチームの予算と性能：カナダノードで北米ユーザー、太平洋横断のSSH/VNC選区、M4（16GB/256GB対24GB/512GB）と1TB/2TB拡張・並列インスタンスは割に合うかを参照してください。
1. なぜカナダ単一ノードにGatewayを固定するのか
複数リージョンへGatewayを複製すると、チャネル状態・ファイルキャッシュ・モデル鍵の所在が分散し、跨洋チームのデバッグが難しくなります。カナダの遠隔Macに一本化すると、北米向けWebhookやクラウドAPIの出口IPも揃いやすく、監査ログの単一ストリームになります。代償として、アジア太平洋側メンバーは往復レイテンシが増えるため、UIはローカル描画に寄せ、重い処理だけをGatewayに投げる形にします。OpenClawのHTTP待受は多くの構成で127.0.0.1:18789に束ね、外向きはSSHトンネルかTailnetのプライベート到達に限定するのが安全側です。
2. loopbackで18789を束ねる意味と典型ミス
Gatewayを0.0.0.0:18789で広げるとポートスキャンに晒されやすく、DashboardのセッションCookieとAPIトークンが同じホスト上で混線しがちです。まずは127.0.0.1:18789に固定し、前段のトンネルかTailnetのACLで「誰が叩けるか」を絞ります。手元Macで18789を既に使っているとssh -LがEADDRINUSEになるため、ローカル側は22889:127.0.0.1:18789のようにずらし、ブラウザはhttp://127.0.0.1:22889へ向けます。リモート側でLISTENが*:18789になっていないかはlsof -nP -iTCP:18789 -sTCP:LISTENで確認します。
Slackやメール本文に長寿命トークンを貼らない。共有Vaultから短命クレデンシャルを注入し、ローテ時は「失効日時」をタイムゾーン付きでRunbookに残す。画面収録中はDashboardを閉じる。
3. macOSクライアント：Remote over SSHの裏で18789をつなぐ
Finderやssh user@hostの対話セッションと別に、フォワード専用のssh -Nを常駐させるのが実務的です。跨洋回線ではServerAliveInterval 30とServerAliveCountMax 4を入れてNAT切断を避けます。複数メンバーが同じローカルポートを奪い合わないよう、各自のplistかシェルエイリアスでポートを分けます。
ssh -N \ -o ServerAliveInterval=30 -o ServerAliveCountMax=4 \ -L 22889:127.0.0.1:18789 \ user@kanada-remote-mac.example
ブラウザのDashboardはhttp://127.0.0.1:22889、CLIや社内ツールも同じループバックを指します。セッションが切れたらフォワードも消えるので、長時間運用は後述のLaunchAgentかautosshに寄せます。
4. Tailnet越しにDashboardとAPIを叩く
Tailscaleを使う場合、カナダMacにtailscaledを入れ、チームACLで「エンジニア端末だけが100.xの:18789へ到達可」にします。SSHトンネルより常時張り直しが少なく、跨洋チームのオンボーディングも「端末にTailscaleを入れる」一点に集約できます。Dashboardをhttps://で終端したい場合は、ノード上でリバースプロキシを立て、上流をhttp://127.0.0.1:18789に限定してください。公開向けのtailscale funnel系は別物なので、社内閉域なら使わない方針を推します。
curl -fsS "http://100.x.y.z:18789/healthz" \
-H "Authorization: Bearer ${OPENCLAW_GATEWAY_TOKEN}"
5. 跨洋チームのgateway.remote.token運用
トークンは「人」ではなく「ロール」単位で発行し、オペレータ・CI・個人開発を分けます。失効手順を書かないままローテすると、太平洋の反対側で夜間ジョブだけが古いトークンを握り続けることがあります。環境変数注入（launchctl setenvではなくplistのEnvironmentVariables）か、1Password/ Vault のランナー同期に寄せてください。プロキシがAuthorizationヘッダを削ると401に見えるので、Gatewayログとクライアント側の-vを突き合わせます。
6. 対照表：SSHトンネル／Tailnet／TLS直結
| 到達経路 | 公開面 | 跨洋運用の観点 | 18789の束ね方 |
|---|---|---|---|
SSH -L |
SSHポートのみ（公開鍵管理） | セッション寿命の管理が必要。各自ローカルポート設計 | リモート127.0.0.1:18789へ直フォワード |
| Tailnet（推奨閉域） | コントロールプレーン＋ACL | 常時張り直しが少ない。端末ポリシーで統制しやすい | 100.xから18789。必要ならノード内リバプロでTLS |
| インターネットTLS直結 | 443/WAF | Webhookや外部SaaS向け。運用責務が最重 | 上流127.0.0.1:18789、証明書とWAFログ監査が必須 |
7. LaunchAgentでフォワードとGatewayをログイン文脈に固定
LaunchDaemonはブート直後から全ユーザーで動きますが、キーチェーンやGUIログインセッションに依存するツールはLaunchAgent向きです。跨洋チームで「共有アカウントは使わず、各自のエージェントを自分のセッションだけで立ち上げる」方針なら、~/Library/LaunchAgents/にplistを置きます。変更後はlaunchctl bootout gui/$(id -u)とbootstrap gui/$(id -u)のペアで二重登録を避けます。PATH不足でopenclawが見つからないときはフルパスかEnvironmentVariablesを明示します。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
<key>Label</key><string>com.example.openclaw.ssh-tunnel</string>
<key>ProgramArguments</key><array>
<string>/usr/bin/ssh</string>
<string>-N</string>
<string>-oServerAliveInterval=30</string>
<string>-L</string>
<string>22889:127.0.0.1:18789</string>
<string>user@kanada-remote-mac.example</string>
</array>
<key>RunAtLoad</key><true/>
<key>KeepAlive</key><true/>
</dict></plist>
| 項目 | LaunchAgent | LaunchDaemon |
|---|---|---|
| 起動タイミング | ユーザログイン後 | ブート時（全ユーザー） |
| キーチェーン／GUI依存 | 相性が良い | 分離が必要なことが多い |
| 跨洋チーム運用 | 個人端末のトンネル常駐向き | 共有ノードのGateway常駐向き |
| 典型リスク | ログアウトで停止 | 権限境界の誤設定 |
8. Dashboardと18789の整合チェックリスト
Dashboardが参照するAPIベースURLと、実際にフォワードしているローカルポートが一致しているかを最初に確認します。ブラウザの混合コンテンツブロックや、社内プロキシによるWebSocket切断も跨洋で顕在化しやすいです。リモートMac側でopenclaw gateway statusを見て、待受が意図通り127.0.0.1かを確定させてからクライアント側のトラブルシュートに進みます。
9. FAQ
Q1. Dashboardは開くのにAPIだけ401になる
CookieセッションとAuthorizationトークンを取り違えていないか確認します。プロキシがヘッダを落とすケースでは、Gateway直のTailnet経由で再現試験してください。
Q2. 東京からTailnetで18789がタイムアウトする
ACLで端末ロールが許可されているか、カナダMacのtailscaledが起動しているかを見ます。MagicDNS無効時は100.x直指定が必要です。
Q3. ssh -Lだけは通るが、同僚のMacでは失敗する
ローカルポート競合、社内セキュリティソフトのローカルループバック制限、異なるSSH鍵を握っている可能性があります。各自別ポートに切り替えて切り分けます。
Q4. LaunchAgentを入れたのにログイン直後だけ動く
KeepAliveが無い、またはsshが初回ホスト鍵確認で停止していないかを確認します。StrictHostKeyChecking=accept-newなど方針を決め、非対話で通るようにします。
Q5. Gatewayを0.0.0.0に広げたいという要望が来た
まずTailnetかリバプロで閉じ、どうしても生公開ならWAFとレート制限、トークンローテ、侵入検知をセットで設計します。監査要件が無いPoC以外では非推奨です。
Q6. 跨洋ローテで夜間バッチだけ古いトークンを握っている
ローテ直前にVaultの「失効予告」タグを付け、バッチのsystemd/launchdジョブにトークン再読込フックを入れます。失効後の403をアラートに上げます。
Q7. DashboardのWebSocketが途中で切れる
中間プロキシのタイムアウト値を上げるか、Tailnet直叩きに切り替えます。SSHトンネル経路ではMTU/帯域詰まりも疑い、mtrで跨洋区間を確認します。
10. まとめ
カナダ単一ノードにGatewayを置く設計では、18789をloopbackに固定し、SSHトンネルかTailnetで閉域到達を作るのが跨洋チームでも再現性が高いです。Dashboard URLとAPIトークン、そしてLaunchAgentかLaunchDaemonのどちらで常駐させるかを表に落としておくと、オンボーディングと障害切り分けが速くなります。