クラウド Mac 納品後の最初の1時間：SSH キーと Web VNC 接続チェックリスト

1時間の完了基準：2経路それぞれ1回ずつ通す

クラウド Mac を借りた直後に時間を溶かす最大の原因は、ソフトウェア導入より接続方式の未確定です。VNC だけ使うと CI スクリプトが回らない；SSH だけだとシステム拡張の承認や App Store ログインでデスクトップが必要——というパターンが頻出します。

「最初の1時間が完了した」と定義する条件は次の4項目すべてにチェックが付くこと：

• SSH 公開鍵ログイン成功、かつパスワード認証を無効化済み
• ブラウザ Web VNC で macOS デスクトップに入り、1回以上 GUI 操作を完了
• ローカル ~/.ssh/config に Host エイリアスを設定し、ターミナル再起動後 ssh jexmac-tokyo 等1コマンドで接続可能
• ノードのタイムゾーン、macOS バージョン、コンソール注文番号を記録（後続チケット用）

以降は「認証情報取得 → SSH 優先 → VNC → レイテンシ最適化 → 仕上げ」の順で進めます。実測環境は JexMac 日本（東京）ノードの Mac mini M4（16 GB ユニファイドメモリ、256 GB NVMe、1 Gbps 専有帯域）、2026年7月の検証ウィンドウ。コンソール「納品済み」表示から SSH 鍵ログイン成功までの中央値は約8分（鍵生成含む）。

コンソールで探す4項目：フィールド名を間違えない

ゲスト決済でも登録アカウントでも、納品後の認証情報の場所は同じです。コンソールにログインし、対象インスタンスを選択、「接続ターミナル」ブロックを確認。納品前は「接続情報を生成中」のアニメーション；ステータスが納品済みになると次の4項目が同時に表示されます。

よくある落とし穴：ゲスト注文の接続 URL をブックマークしたがアカウント未登録——ゲスト認証情報は現在のブラウザセッションのみ有効で、端末変更やキャッシュクリア後は決済メールアドレスで復元が必要です。チーム利用なら決済直後に登録し注文をアカウントに紐付け、Slack 等に生パスワードを流さない運用を。

Ed25519 キー：ローカル生成と ssh-copy-id

ローカル端末（macOS、Linux、Windows 11 標準 OpenSSH）で専用キーペアを生成。個人 GitHub 用キーの使い回しは避けてください——クラウド Mac の鍵漏洩は物理マシン全体の侵害に直結します。

1. 01
   Ed25519 キーペアを生成

   ssh-keygen -t ed25519 -C "jexmac-cloud-mac" -f ~/.ssh/jexmac_ed25519

   Passphrase 設定推奨——ノート PC 紛失時に鍵ファイル単体での悪用を防ぎます。

2. 02
   初回パスワードログインで公開鍵を配置

   コンソールから SSH コマンドをコピーし：

   ssh-copy-id -i ~/.ssh/jexmac_ed25519.pub -p <ポート> admin@<パブリックIP>

   ssh-copy-id が無い環境では手動：

   cat ~/.ssh/jexmac_ed25519.pub | ssh -p <ポート> admin@<IP> "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

3. 03
   パスワードレスログインを検証

   ssh -i ~/.ssh/jexmac_ed25519 -p <ポート> admin@<IP> "uname -a && sw_vers"

   Darwin カーネルと macOS バージョンが返り、パスワードプロンプトが出なければ OK。

4. 04
   ローカル SSH config にエイリアスを記述

   Host jexmac-tokyo
       HostName <パブリックIP>
       Port <ポート>
       User admin
       IdentityFile ~/.ssh/jexmac_ed25519
       IdentitiesOnly yes

   以降は ssh jexmac-tokyo のみで接続。

Windows では C:\Users\<ユーザー>\.ssh\config に同等設定。PowerShell 7 と Windows Terminal は上記構文をそのまま利用可能。WSL と Windows ホストで .ssh を共有しない場合、WSL 側で別途生成するか同一ディレクトリをマウント——「WSL で設定したのに PowerShell から繋がらない」ずれを防ぎます。

SSH セキュリティベースライン：パスワード停止、フィンガープリント、接続元管理

公開鍵ログインの動作確認後にサーバー側設定を変更——順序を逆にするとロックアウトし、VNC デスクトップ経由の復旧のみが残ります。

1. 01
   authorized_keys のパーミッション確認

   chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

   権限が緩いと OpenSSH は公開鍵を無視し、パスワードログインにフォールバック——初回接続失敗の高頻度原因です。

2. 02
   パスワード認証を無効化（sudo 必要）

   /etc/ssh/sshd_config を編集：

   PasswordAuthentication no
   PubkeyAuthentication yes
   PermitRootLogin no

   保存後 sudo launchctl kickstart -k system/com.openssh.sshd で反映。変更前に別ターミナルで鍵ログインが生きていることを必ず確認。

3. 03
   known_hosts にフィンガープリントを固定

   ssh-keyscan -p <ポート> <IP> >> ~/.ssh/known_hosts

   初回接続時の MITM 警告を機械的に yes してしまう習慣を防ぐ。チーム Wiki に fingerprint を共有する運用も有効。

ブラウザ Web VNC：クライアント不要の初回接続

Web VNC は初回デスクトップ確認、App Store ログイン、システム拡張承認に最適——純 SSH では完結しない場面です。JexMac コンソールからワンクリック起動、noVNC によるブラウザ描画で RealVNC Viewer 等のインストールは不要。

1. 01
   コンソールからセッション開始

   インスタンス詳細の「Web VNC」または右側 dock の「リモートデスクトップ」。新タブで vnc.html が開き「macOS デスクトップに接続中」のローディング表示。

2. 02
   初回フレーム待機とパスワード入力

   初回画面は通常12秒以内（東京ノード、国内フレッツ系 1 Gbps 実測）。VNC 認証を求められたらコンソール「接続ターミナル」のパスワード——SSH 初期パスワードと同一。

3. 03
   GUI 受け入れテストを1回実行

   「システム設定 → 一般 → 情報」でチップ Apple M4、メモリ 16 GB を確認。ターミナルで hostname を実行し SSH 側と一致すれば同一インスタンスへのデュアル経路が確立。

4. 04
   セッション終了

   HUD 左上「コンソールに戻る」でタブを閉じるだけ。macOS 側でログアウト不要。長時間アイドルで切断される場合あり——コンソールから再オープン即可。

推奨ブラウザ：Chrome / Edge / Safari 最新安定版。Firefox も可だが WebGL ソフトウェアデコード時はフレームレートがやや低下。社内ネットワークが WebSocket を遮断すると「接続中」のまま停止——スマホテザリングで切り分け、HTTPS アウトバウンド許可をネットワーク管理者に依頼。

サードパーティ VNC クライアント：レイテンシ調整の要点

Xcode UI の長時間ドラッグや Instruments タイムライン操作では、ブラウザ VNC のフレームレートが不足することがあります。SSH が安定した段階で RealVNC Viewer や Jump Desktop の設定に進む価値があります。管理者権限があるため、macOS「画面共有」の有効化や RealVNC Server の導入（未プリインストール時）も可能です。

経験則（東京ノード、国内 100 Mbps 回線）：

Jump Desktop は Apple Silicon 向けトラックパッドジェスチャー映射が充実；RealVNC は Windows ホストからの接続が軽量。いずれも macOS グラフィカルセッションで一度「画面収録 / アクセシビリティ」許可が必要——推奨順序は SSH 検証 → Web VNC でデスクトップ → サードパーティ設定です。

国際回線トラブルシュート：拠点選定と経路診断

「SSH タイムアウト」「VNC 真っ黒」の半数はインスタンス障害ではなくルーティング問題。JexMac の5拠点——シンガポール、日本（東京）、韓国（ソウル）、中国香港、米国東部——はハードウェアと料金が同一で、差は RTT と夕方ピークのパケットロスに現れます。

ざっくり選定指針（日本在住・日本向け開発者向け）：

• 国内ユーザー・App Store JP テスト：日本（東京）、RTT 通常 5〜20 ms
• 東南アジア API や多言語 QA：シンガポール
• 韓国ローカライズ・K-RPC デバッグ：韓国（ソウル）
• 中国本土向け配信テスト：中国香港（東京より中国側 RTT が有利な場合あり）
• 北米ユーザー・米国 API：米国東部——日本から 150〜220 ms は正常、東京ノードと比較しない

ローカルで実行する診断コマンド：

ping -c 20 <パブリックIP>
mtr -rwzc 50 <パブリックIP>
ssh -vvv jexmac-tokyo

ping ロスが5%超が続く場合、まず回線をテザリング等に切替え ISP 国際出口の混雑を除外；mtr で特定ホップからロスが始まるなら隣接拠点への変更が再起動より効くことが多い；ssh -vvv が Connecting で止まるのはポート不一致かローカル FW——コンソールの SSH ポートとコマンドを再照合。

詳細 FAQ はヘルプセンター · リモート接続；復旧しない場合はコンソールからチケット——mtr スクショ、ブラウザバージョン、注文番号を添付。

1時間の仕上げ：タイムゾーン、更新、チーム運用

接続経路が安定したら、最後の10分で後工程の手戻りを減らすベースライン設定：

1. 01
   タイムゾーンと locale 確認

   sudo systemsetup -gettimezone

   CI ログとローカル開発機の TZ 不一致は「ビルド時刻が9時間ずれる」誤解を招く。必要なら sudo systemsetup -settimezone Asia/Tokyo 等。

2. 02
   メジャー OS アップグレードを延期

   「システム設定 → 一般 → ソフトウェアアップデート」で major upgrade を一時停止。Runner 実行中の自動再起動を防ぐ。セキュリティパッチはメンテ窗口で手動適用。

3. 03
   コマンドラインツール（未プリインストール時）

   xcode-select --install

   GUI 確認ダイアログが必要——SSH のみ環境で失敗したら Web VNC で「インストール」を1クリック。

4. 04
   チーム共有ルール

   Host エイリアス、拠点、注文番号を内部 Wiki へ。鍵はメンバー各自——秘密鍵をリポジトリに置かない。ゲスト注文は早めにアカウント紐付け。

ここまでで1時間チェックリストは閉環。以降 Xcode 導入、GitHub Actions Runner 登録、OpenClaw サンドボックス有効化はすべて「SSH 自動化 + VNC 救済」の上に載る——どちらか欠けるとトラブルコストが指数関数的に増えます。

ローカル Mac がない場合：プロジェクトのペースに合わせたリモート環境

クラウド Mac を借りる動機の多くは、リリース週だけ安定 macOS が欲しく、普段はハードウェアを維持したくないというものです。Mac mini 自社調達は購入・設置・証明書ローテ時の現地作業が発生；同僚 PC の借用は Xcode バージョン衝突と sleep によるビルド中断を招きます。

JexMac は専有 Mac mini M4 物理マシン（VPS 仮想化ではない）を提供。16 GB ユニファイドメモリ、256 GB NVMe、1 Gbps 専有帯域、日額 $21.5〜・週 $57.9・月 $107.3、決済後1〜5分で SSH / VNC 認証情報、契約縛りなし。5拠点は利用者の地理に合わせて選択——日本国内開発なら東京、北米 TestFlight なら米国東部。

リモートデスクトップ SaaS 共有プールと比べ、物理マシン専有は CPU / メモリが隣テナントに奪われず xcodebuild や Instruments の所要時間が他 job に左右されない。クラウド VM とも異なり、完全 macOS 管理者権限で画面共有・キーチェーン・Homebrew の挙動がローカル Mac と一致。短期スプリント、長期 CI、OpenClaw 実験すべて本記事 SOP をそのまま新インスタンスの標準手順にできます。