2026 Mac mini リモートアクセス：SSH と VNC — クラウド Mac でどちらを使うか（両方を組み合わせる場合）
香港、東京、ソウル、シンガポール、または米国でビルド・QA・自動化のために Mac mini を借りるなら、ほぼ必ず SSH と VNC の両方 を使います。しかし多くのチームは最初に誤った経路を選び、「もっさり」「不安定」と感じます。この 2026 年版ガイドはプロトコルレベルで答えます：帯域と RTT で SSH が有利なとき、macOS 画面共有（VNC）が避けられないとき、そして ProxyMac 顧客の実際のリリースペースに合うハイブリッドの回し方。特性比較表、迅速な意思決定マトリクス、Runbook に書ける 3 つの数値、セッション前の 5 ステップチェックリストを収録。RTT 調整は リージョン間レイテンシ最適化、切断対策は SSH の安定性、GUI 詳細は VNC リファレンス。
要点：2026 のデフォルト
まず SSH でシェル、git、パッケージインストール、ログの tail、ファイル同期。macOS が GUI を強制するときだけ VNC — システム設定、画面収録／アクセシビリティの承認、Xcode のデバイスウィンドウ、スクリプト化できないビジュアル QA。GUI 作業が終わったら SSH に戻し、長時間セッションの帯域を予測可能に保ちます。
経路を誤ったときの典型的なつまずき
- 「VNC が使えない」 は、180ms RTT で 4K デスクトップを引きずりながら同じ上りでビデオ会議をしている状態であることが多い — 作業の 9 割は SSH で快適だったはずです。
- 「SSH が遅い」 は巨大な MOTD、色付きログの洪水、数 GB の scp が原因であることが多く、プロトコルの前にワークフローを直します。
- 「24時間 GUI が要る」 はプロセスの問題 — 繰り返しクリックは自動化し、VNC は承認画面に限定します。
各プロトコルが実際に運ぶもの（特性表）
| 観点 | SSH（macOS の OpenSSH） | VNC / 画面共有 |
|---|---|---|
| 主なペイロード | テキストストリーム、ファイルコピー、転送 TCP ポート | Framebuffer + 入力イベント（ピクセル） |
| 典型的な定常帯域 | 対話シェル約 0.05–2 Mbps | 1080p 相当の動きで約 3–15 Mbps（コーデック依存） |
| 遅延感度 | CLI なら 120–220ms RTT も許容しやすい | 適応品質なしで ~150ms 超えると重く感じる |
| 自動化向き | 優秀（鍵、ジャンプホスト、CI） | 不向き — UI スクリプトは壊れやすい |
| macOS 管理 | 限定的（ネイティブ GUI なし） | 多くの TCC プロンプトに必須 |
意思決定マトリクス：1 分以内に選ぶ
| シナリオ | SSH | VNC | メモ |
|---|---|---|---|
xcodebuild 実行 + ログ閲覧 | ✓ | — | tmux で切断してもビルドを殺さない |
| OpenClaw の画面収録を承認 | — | ✓ | 一度きりの GUI；ヘルプに記録 |
| Safari レイアウトを手動デバッグ | — | ✓ | 表示スケールを下げて Mbps を節約 |
| 12GB の Xcode アーカイブをコピー | ✓ | — | VNC 経由の Finder ドラッグより rsync -avz --partial |
| 音声付きペアプロ | ハイブリッド | ハイブリッド | 編集は SSH、デモは短い VNC |
上級 ProxyMac ユーザーが回すハイブリッド
- まず SSH で入る — keepalive は 安定性ガイド 参照。
- 長時間ジョブは
tmux下で — VNC を閉じてもコンパイルは止まらない。 - システム設定または TCC が必要なときだけ VNC — 終わったら切断して上りを空ける。
- ブラウザ／地域テスト は mini のリージョン経由 — エグレス を読み、SSH ポートフォワードで足りることが多い。
- チーム Wiki に SSH のみのタスク を明記し、新人が一日中画面共有にいないようにする。
Runbook に書く価値のある 3 つの数字
- 5900 — macOS 画面共有のデフォルトリスナー（ポートを固めたら
lsof -nP -iTCP:5900で確認）。 - 22 — SSH；内部サブネットには バスティオンガイド のジャンプホストと組み合わせ。
- 150ms — フルデスクトップ作業で VNC 品質が大きく落ちる目安の RTT；これより下なら M4 クラスでハイブリッドが自然。
次のセッション前の 5 ステップ
- 料金ページ で最寄りノードを選び、SSH と VNC の両方を楽にする。
pingと無害なリモートコマンドでSSH レイテンシを測る；RTT >200ms ならピクセル重い VNC は後回し。- 本当に必要な GUI ステップを列挙；5 を超えるなら終日接続ではなく集中 VNC 枠を取る。
- 認証を確認：SSH 鍵を読み込み済み、VNC パスワードまたはトンネル方針を ヘルプ Runbook に記載。
- 使ったトランスポートを記録し、VNC 過多なチームを運用が把握できるようにする。
よくある質問
ファイル編集だけなら VNC が必要？
SSH 連携エディタまたは rsync を優先。VNC は framebuffer コストを増やすだけでマージ品質は上がりません。
解像度が高いと VNC は常に不利？
はい — 更新あたりのピクセルが増えます。まず単一ディスプレイのスケールを下げてからプロバイダを責めないでください。
リージョンは SSH と VNC の前に選ぶ？
常にリージョンが先。プロトコルは二番手ですが、長いパスでは SSH の方が VNC より長く実用的です。
SSH 優先・必要時 VNC のチームに ProxyMac Mac mini M4 が合う理由
Apple Silicon M4 は高速な Neural Engine とメモリ帯域で sshd、ファイルインデックス、ときどきの画面共有エンコーダを、小型 x86 VPS で見がちな CPU スロットリングなしに回せます。HK / JP / KR / SG / US の実機 macOS 上では Gatekeeper、Xcode、自動化エージェントがデスクサイドと同じように動き — CapEx なし。日常は SSH、カーソルが要る macOS の瞬間だけ VNC。並列チームが専用ホストを要するときは カタログ でノードを増やします。
