本稿はrsync による成果物扇出とは切り分け、人の対話入口に絞ります。成果物同期の全体設計はrsync 意思決定マトリクス、マルチ AZ 網関はOpenClaw 実践記を参照。索引は技術ブログから。
意思決定を一文にすると、バッチと自動化の主路は SSH（または専用 runner）、長時間の対話デバッグや高ジッター跨ぎは Mosh を優先検討、です。どちらも flock やディレクトリ設計による排他には代わりません。SSH は監査と踏み台ポリシーに馴染み、Mosh は UDP が通る前提で体感を和らげます。入口は「プロトコル選好」より許可表とロック境界のセットで決めます。
ポート／ファイアウォール一覧
SG／出口ホワイトリスト／ノード pf に貼り、オフィス・モバイル・VPN の三経路で実測してください。
| 経路 | プロトコル／ポート | 備考 |
|---|---|---|
| SSH 制御面 | TCP 22（チーム独自ポート可） |
鍵ローテとレート制限を維持。scp／git+ssh も共有。 |
| Mosh データ面 | UDP 60000–61000（既定レンジ。サーバー側で絞り可） |
mosh-server 必須。TCP のみ許可だと「SSH 可・Mosh 不可」に見える。 |
| NAT／戻り | ステートフル FW で established／related を許可 | NAT 型差が UDP に効く。損失と RTT を runbook 化。 |
受入チェック：① 三経路それぞれで mosh user@host を実行、② Wi‑Fi 切替やスリープ復帰後も入力が追従するか、③ UDP レンジを変えたらクライアント側の指定も同時更新するか、を確認します。
ビルドロック／flock との組み合わせ
Mosh は表示と体感のみ。DerivedData／成果ディレクトリへの二重書き込みは直列化しません。「広く並列ビルド、狭く昇格」で flock を昇格・署名・配布のゲートにだけ載せます。
- ロック場所：ローカル SSD。SSHFS 等で長押ししない。
- クリティカル区間：コピー・manifest・通知のみ。全ビルドをロックで包まない。
- 人手と CI：同じ promote コマンドを叩き、
flockを迂回しない。 - 受入：二セッション同時昇格で一方は競合時に終了コードを返し、監視が待ちとハングを判別できる。
例：flock -n /var/tmp/m4-promote.lock bash -c './scripts/promote_artifacts.sh'
FAQ
Mosh は flock や CI の相互排他に取って代われるか？ いいえ。Mosh はパケット損失や IP 変更下での対話型端末の体感を改善するだけです。ファイルツリーが安全かはトポロジとクリティカルパスでのロック次第です。
企業 FW で TCP 22 は許可済みなのに Mosh が失敗するのはなぜか？ Mosh には UDP のレンジとサーバー側 mosh-server が追加で必要です。上表に沿って許可し、戻りが DPI で捨てられていないかも確認してください。
自動化ジョブも Mosh に全面移行すべきか？ 通常は不要です。非対話バッチは SSH に keepalive・リトライ・ウォールクロックのタイムアウトを載せた方が監査しやすいです。高ジッター下の人間と機械の協働に Mosh を割り当てましょう。
ログイン不要でノードを比較：まず料金から
料金とリージョンの閲覧にアカウントは不要です。決めたら購入ページで注文し、専有の Mac mini M4 を取得したうえで、本稿のファイアウォール表と flock の狭いゲートをチームの runbook に貼ってください。