東京・大阪・台北・シンガポール側のチームが、カナダの Mac mini 級 M4に載った OpenClaw を前提にレビューと本番オペを分担するとき、最初の分岐はしばしばこう言語化されます。「全部コンテナに閉じ込めて再現性を買うか、Apple Silicon 上の素の macOS に install.sh と Homebrew で直載せして摩擦を減らすか」。この選択はCPU 効率の趣味というより、太平洋 RTT のもとで誰が何回ターミナルを叩くかという協業会計に直結します。本稿は、Docker Desktop／Colima／OrbStack 系の仮想化レイヤを挟むモデルと、専用ユーザで動かすネイティブモデルを、Gateway 18789 の公開形態、Workspace とログのディスク水位、そして負荷が伸びたときの並列ノード（2 台目）判断まで一枚のマトリクスに落とし込みます。運用フェーズに入ったあとの水位監視とローリング再起動の語彙は OpenClaw 2026｜カナダのリモートMac M4における制御アップグレードと安定運用ハンドブック：依存関係の固定、Gatewayのヘルスプローブとローリング再起動、ログのディスク水位、リモート経路ジッターの排障対照、中高配スペックの構成例（HowTo+FAQ） がそのまま継続編になります。長周期でディスクと並列だけを切り出したい場合は 2026年リモートMacの長周期開発・テストにおけるディスクと並行処理のボトルネック：カナダノードが北米協業とアーティファクト同期をどう補うか—M4構成の拡張と並列の意思決定マトリクス（アジア太平洋対照FAQ） と突き合わせてください。
ポイントは「Docker が悪い／ネイティブが正しい」ではなく、チームが支払う隠れコストの内訳です。コンテナはオンボーディングの再現性と依存の隔離に強く、一方で macOS ホストとの境界越しに出るファイル I/O の二重化、ブラウザ自動化や音声デバイスまわりの権限ダイアログ、そして launchd から見たときの PATH とソケット公開のズレが、太平洋向けの夜間オンコール時間を増やしがちです。ネイティブ載せは逆に、初日の摩擦は小さい一方、バージョン漂流と「その Mac だけ通る」スクリプトがチーム学習コストを押し上げます。以下の二表と HowTo は、どちらを主軸にするかの go／no-go を短く合意するための共通語彙になります。
太平洋協業で本当に高いのは RTT だけではない
往復遅延は確かに痛いですが、運用で破綻しやすいのは状態の非再現性です。APAC のメンバーがカナダ Mac に SSH で入り、手作業でコンテナを再起動し、ホスト側の plist は別担当が直し、チャネル Webhook の向き先だけが古いまま、という分散した一時しのぎが積もると、会議室では「Docker にした／しなかった」では説明できない時間が溶けます。協業コストの分解に使うと読みやすいのは次の四つです：(A) 初回セットアップの分単位作業、(B) 障害時の切り分けステップ数、(C) セキュリティレビューが要求する証跡の取りやすさ、(D) ディスク逼迫やスワップによる二次障害の頻度。Docker は (A)(C) を下げやすく、(B) はレイヤが増えると上がります。ネイティブは (A)(B) の体感が軽く、(C)(D) の設計を誤ると長期で膨らみます。
したがって「どちらが速いか」より先に、誰がどのレイヤのオーナーになるかを書きます。例：コンテナ内の Node ランタイムはプラットフォーム班、ホストの launchd とログローテーションはインフラ班、チャネル秘密はセキュリティ班、Workspace の tarball 世代管理は自動化リード。太平洋チームでは境界が曖昧なほど、夜間の sudo 依頼が増えます。
Docker ホスティングとネイティブ install.sh／Homebrew：選択の骨格
Docker モデルでは、OpenClaw 本体・依存・CLI をイメージに焼き、ホストは「十分新しい Docker エンジンと永続ボリュームのマウント先」に寄せます。ネイティブモデルでは、Homebrew で Node 系を固定し、install.sh が期待するディレクトリにワークスペースを置き、launchd が読む PATH を明示します。Gateway 18789 はどちらでも「コンテナ内で listen して -p 18789:18789 で出す」か「ホストのループバックで listen して SSH トンネルだけ開く」かで攻撃面と運用の簡さが変わります。
| 観点 | Docker／コンテナ主軸 | ネイティブ install.sh＋Homebrew 主軸 |
|---|---|---|
| 再現性・CI 親和 | イメージ digest でロックしやすい。複製ノードが速い。 | Brewfile と Node のメジャー固定が必須。ドリフト検知を別途。 |
| ファイル I／O と Workspace | バインドマウント越しのメタデータ同期が遅くなりがち。大 tarball は要注意。 | APFS 直は速い。権限と拡張属性は素直に扱える。 |
| GUI／ブラウザ自動化 | XQuartz 等を挟むと協業説明が難しい。ヘッドレス寄りに寄せるのが無難。 | Screen Sharing と整合しやすい。権限ダイアログは手順化しやすい。 |
launchd 統合 |
docker run ラッパか compose。再起動ポリシーは別設計。 |
plist から直接バイナリ。非対話検証が素直。 |
| セキュリティ監査 | ベースイメージの CVE 追従が必須。SBOM が取りやすい。 | ホスト OS のパッチ適用が表に出る。境界が一つで説明しやすい。 |
18789 がどの名前空間で listen しているかをレビュー観点に固定してください。
Gateway 18789：コンテナ publish とループバック＋SSH の協業トレードオフ
多くの手元構成では Gateway が 127.0.0.1:18789 に bind し、外向きは SSH のローカルフォワードかリバースプロキシで守られます。Docker に移すと「ホストの 18789 をコンテナへ転送する」か「コンテナが直接 listen し 0.0.0.0 を晒す」かの選択が出ます。後者はプロバイダのセキュリティ審査で即座に却下されがちなので、ループバック bind＋明示的なトンネルまたは TLS 終端をデフォルトに据え、公開範囲を IaC か Runbook で固定するのが太平洋チームに優しいです。SSH トンネルと直結ゲートウェイの対照は、同ブログ内の Gateway 18789 系の記事と突き合わせると説明が早くなります。
コンテナ経由で launchd から起動すると、親プロセスが docker CLI になり、失敗時のログが dockerd 側に吸われることがあります。運用では docker logs とホストの /var/log 系の二系統をどちらも追跡できるよう、集約先（例：単一ディレクトリへのシンボリックリンクまたはログシッパ）を先に決めます。
Workspace とログのディスク水位：閾値と先回り拡張
OpenClaw 系ワークロードでは、ブラウザプロファイル、キャッシュ、構造化ログ、失敗ジョブのスクショ保存が静かに APFS を埋めます。太平洋チームは現地ディスクが逼迫していることに気づくのが遅れがちなので、閾値を数字で固定します。目安として、システムボリュームの空きが連続して 15% を割る、Workspace 配下の増分が7 日間で二桁 GB、ログディレクトリがローテーション間隔より速く肥大したら、スケールアウトより先にディスク階層の分離または容量追加を検討します。スワップ地獄に落ちる前に RAM を増やす判断は、コンテナ有無にかかわらず同じです。
| 水位シグナル | 典型の原因 | 即応アクション（協業コスト順） |
|---|---|---|
| 空き < 15%（システム） | ログ・Docker イメージ層・ブラウザキャッシュの重なり | 重い成果物を外部ボリュームへ移し、イメージ prune を計画メンテに入れる |
| Workspace の日次増分 > 計画の 2 倍 | スクショ保存、未ローテートの tmp、失敗ループの成果物 | 保持日数を短くし、オブジェクトストアへ退避。並列二台目はまだ見送り |
iowait が常時突出 |
コンテナ bind のメタデータ負荷、同期スキャナ | ネイティブ層へ I/O 集約、rsync ウィンドウを夜間に限定 |
| スワップ使用量がジワ増し | RAM 不足＋ブラウザ同居 | RAM アップグレードまたはブラウザ分離（別ユーザ／別ホスト） |
| ログローテーション後も inode 逼迫 | 小ファイル嵐、テンポラリ残骸 | tmpwatch 相当の整理、生成物の命名規約を締める |
並列拡張の意思決定：いつ「同型 2 台目」か、いつ「役割分割」か
負荷が乗ったときにすぐ二台目を足すと、チャネル認証・トークン・スケジューラの二重化事故が増えます。まずはCPU ではなく待ち行列の長さと、Gateway の p95 レイテンシ、失敗ジョブ率を見ます。キューが単一ホストの I/O または RAM で頭打ちなら、同型を水平に足すより、ブラウザ自動化専用とチャネル専用のように役割分割した方が太平洋オペの説明が簡単なことが多いです。どうしても同型 2 台にするときは、トークンと DNS をホスト世代で分離し、クライアントのルーティングを一本化するゲートを先に通してください。
並列判断を短く合意するための内部チェックは次の三問です。(1) 失敗はリソース不足か論理バグか。(2) 二台に分けたとき、どのチャネルがどちらを正とみなすか。(3) 夜間に片方だけ巻き戻せるか。いずれかに即答できなければ、まだ並列拡張の準備不足です。
HowTo：初週にやるべき具体手順（ネイティブ主軸＋Docker オプション）
初週は「動く」より観測点を三つ置くことを優先します：Gateway ヘルス、Workspace サイズ、ログディレクトリの増分。ネイティブ主軸なら Homebrew の Node を固定し、OpenClaw を専用ユーザで展開、plist は白紙から組みます。Docker を併用するなら、まずはビルド専用コンテナから入り、Gateway だけはホストで listen する構成にすると切り分けが楽です。
df -h / du -sh ~/openclaw-workspace ~/Library/Logs 2>/dev/null docker system df 2>/dev/null || true lsof -nP -iTCP:18789 -sTCP:LISTEN || true
上のワンライナ群を毎日同じ時刻に cron ではなく launchd の軽いジョブで吐き、APAC の朝イチで diff を見るだけでも、協業の「感覚値」が減ります。コンテナを足した日は docker system df の増分も同じログに載せ、ホスト空きとの相関を見ます。
まとめ
Docker は再現性と監査容易性で太平洋チームのオンボーディングを短くし、ネイティブ install.sh／Homebrew はGUI・権限・launchdとの整合で夜間タスクを減らしやすいです。コストを下げる鍵は、18789 の公開モデルを最初に固定し、Workspace／ログの水位を数値閾値で追い、並列拡張の前にI/O と RAM のボトルネックを潰すことです。ハイブリッドにするならソケット所有者を図示し、ログの出口を一つに寄せてください。
FAQ
Docker にすると Gateway 18789 は必ずコンテナ内に置くべきか
必須ではありません。ホストで listen しコンテナはバックエンドのみという分離は、運用とセキュリティ説明の両面で扱いやすいです。コンテナ内 listen にするなら publish とファイアウォール境界を Runbook に明記してください。
Homebrew の Node を上げたら OpenClaw だけ壊れたのはなぜか
ネイティブモデルではメジャー固定が命です。brew pin 相当の運用か、asdf／Volta など別レイヤで可動域を狭め、plist の PATH をその実体に合わせます。
コンテナの bind マウントが遅いと言われたら最初に見る場所は
小ファイル大量同期と、ホスト側ウイルススキャナのリアルタイム監視です。除外ポリシーが取れないなら、Workspace をコンテナ外のネイティブ階層に置き、コンテナはツールチェーンだけ、が現実解になりがちです。
二台目を出すよりディスクを増やす判断はどう切るか
キュー長や CPU は余っているのに iowait と空き容量だけが悪化しているならディスク優先です。CPU が常時飽和でログは健全なら並列またはコア数の検討です。
太平洋チーム向けに「再現手順」をどこまで自動化すべきか
最低限、クリーン Mac から 30 分以内にヘルスプローブが緑になるスクリプトと、失敗時のロールバック tarball の場所を README ではなく Runbook に置いてください。動画よりテキストが検索に強いです。
Docker Desktop のライセンスとクラウド Mac の組み合わせで注意することは
組織ポリシーとプロバイダ利用規約の両方を確認します。代替として Colima／OrbStack 等を選ぶ場合、サポート担当が追える範囲にエンジンを絞るのが協業コストを下げます。
ログを集約するとプライバシー要件に触れないか
チャネル本文やトークンをマスクするサンプリング方針を先に決め、構造化ログのフィールドをホワイトリスト化します。集約基盤が国外にある場合はデータ所在地も合わせて文書化してください。