クラウド Mac の遠隔開発:VS CodeとJetBrains調整

深夜二時、家のノートパソコンからレンタルしているクラウド Mac mini に接続し、日中終わらなかったビルドを続けようとする。VS Code が「リモート拡張機能をインストール中」というプログレスバーを表示し、たっぷり40秒も回り続ける——拡張機能のリストは昨日とまったく同じなのに、また一からインストールされているのだ。この「毎回初対面のような」体験は、多くの人がエディタを初めてクラウド Mac に移した際に踏む最初の落とし穴であり、その後にはネットワークの揺らぎによるセッション切断やグラフィカルデバッグが使えないといった問題も待っている。この記事では、これらの課題を一度に整理する。

エディタをクラウド Mac に移す理由、ローカル開発ではダメなのか

たまにログインして xcodebuild を一回走らせるだけなら、SSH で直接入ってコマンドを打てば十分だ。しかし、クラウド Mac mini で長期的にコードを書き、デバッグし、テストを走らせるなら、素の端末 + vim では明らかにローカル IDE の体験に効率が及ばない——セマンティックジャンプもなく、ブレークポイントデバッグもなく、クリップボード同期も別途設定が必要になる。より合理的なやり方は、Mac mini には計算とコンパイルだけを担わせ、エディタのインターフェースはローカルに残し、リモートプロトコルで両者をつなぐことだ。これこそ「クラウド Mac」というサービスの本来の使い方でもある。マシンは占有できる物理リソースであり、データセンターに置いてある自分のパソコンとして扱うべきものであって、使い捨ての一時的なコンテナではない。

VS Code Remote-SSH でクラウド Mac をつなぐ

VS Code Remote-SSH の仕組みは単純明快だ。ローカル側は軽量なクライアントを動かすだけで、実際の言語サーバー、ターミナル、ファイルシステムはすべてリモートの Mac 上にある。初回接続時には vscode-server バイナリと拡張機能ホストがリモートの ~/.vscode-server ディレクトリにインストールされ、以降の接続はこの環境を再利用する。

SSH の設定と接続の多重化

デフォルトでは接続ごとに毎回完全な TCP + SSH ハンドシェイクをやり直すため、太平洋を越えてアジア太平洋や米国西海岸のノードにアクセスする場合、この遅延がそのまま「ファイルを開くのに一瞬待たされる」という形で現れる。ControlMaster による接続の多重化を使えば、ハンドシェイクのオーバーヘッドの大部分を省くことができる。

# ~/.ssh/config
Host omac-jp
    HostName <あなたのノードのIP>
    User devuser
    Port 22
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 10m
    ServerAliveInterval 30
    ServerAliveCountMax 3

ControlPersist 10m は、メイン接続が切れてウィンドウを閉じた後も、多重化用のチャネルを10分間保持することを意味する。この間に新しく開いたターミナルタブや VS Code の再接続はすべてこの既存チャネルを経由し、暗号化の再交渉にかかる時間を省ける。ServerAliveInterval は、一部の通信事業者の NAT がアイドル状態の接続を密かに切断してしまう問題への対策だ。

拡張機能のキャッシュとインデックスの高速化

先ほど触れた「毎回拡張機能が再インストールされる」問題は、多くの場合 VS Code 自体の問題ではなく、接続先のリモートホストが毎回変わっていることが本質的な原因だ——たとえばコンソールでシステムを再インストールした、あるいは別のインスタンスに切り替えたなど。同じマシンを固定して使い続ける限り、~/.vscode-server 内の拡張機能、言語サーバーのキャッシュ、TypeScript/Swift のインデックスはすべて保持され続け、2回目以降の接続は「一瞬で開く」はずだ。

プロジェクトのサイズが大きい場合(たとえば複数の target を含む Xcode プロジェクトなど)、事前にリモート側で一度フルインデックスを走らせてから切断し、キャッシュをウォームアップしておくとよい。

cd ~/Projects/MyApp
xcodebuild -project MyApp.xcodeproj -scheme MyApp -showBuildSettings > /dev/null

このステップは実行ファイルを生成するわけではないが、Xcode のインデックスデータベースを先に構築させておくことで、後でエディタ上で定義へジャンプする際に現場で再構築する必要がなくなる。

JetBrains Gateway の適用シーンと限界

チーム内で(Kotlin/Go で書かれた API のような)バックエンドサービスも同じクラウド Mac 上にデプロイしているなら、JetBrains Gateway もひとつの選択肢になる。ローカルには軽量なクライアントをインストールし、リモート側では完全な IDE バックエンド(IntelliJ IDEA、GoLand など)を動かし、レンダリング結果を独自プロトコルでローカルに転送する。純粋な Web IDE よりも、ローカルマシンに近い体験が得られる。

Gateway の境界は明確だ。対応する JetBrains IDE がある言語エコシステムにサービスを提供するものであり、Xcode プロジェクト、Interface Builder、Swift Playground といったアップル生態系専用のツールはカバーしていない。

つまり、クラウド Mac 上で純粋な iOS/macOS 開発を行う場合、主力のツールチェーンは依然として VS Code Remote-SSH(コードを書き、スクリプトを走らせ、ログを見る)とターミナル上の xcodebuild の組み合わせであり、Gateway はチーム内で「同じ Mac を使ってついでにバックエンドサービスも動かす」というシーンにより適している。

tmux でセッションを保持し、ネットワークの揺らぎに対応する

どのリモート編集方式を使うにしても、下層の接続が SSH である限り、切断のリスクは常に存在する——出張中に Wi-Fi を切り替えたり、自宅のルーターが再起動したりすれば、接続は瞬時に切れてしまう。ちょうど40分かかるビルドを走らせている最中に切断されれば、ビルドプロセスが強制終了され、それまでの作業が水の泡になる。

解決策は、時間のかかるタスクをすべて tmux セッション内で起動することであり、SSH セッションに直接紐づけないことだ。

ssh omac-jp
tmux new -s build
xcodebuild -workspace MyApp.xcworkspace -scheme MyApp \
  -destination 'generic/platform=iOS' build 2>&1 | tee build.log

切断された後に再接続し、tmux attach -t build を実行すれば先ほどの端末出力にそのまま戻ることができ、ビルドプロセスはまったく影響を受けていない。この習慣はビルドだけでなく、長時間実行するモデルのファインチューニング、ログの監視、fastlane のパッケージングスクリプトなども、すべて tmux の中に入れておくべきだ。

シーン	推奨ツール	理由
日常のコーディング、ログ確認	VS Code Remote-SSH	セマンティックジャンプ + ターミナル一体化、接続多重化で応答が速い
チームのバックエンドサービス(Xcode 以外)	JetBrains Gateway	完全な IDE 体験だが、Xcode プロジェクトには対応しない
長時間タスク(ビルド/トレーニング)	tmux / screen	切断してもプロセスは中断されず、いつでも復帰できる
グラフィカルインターフェースが必要(Instruments、Interface Builder)	画面共有 / VNC	実際の GUI を見られる唯一の方法

グラフィカルデバッグはどうするか:VNC/画面共有のトレードオフ

コマンドラインでほとんどのシーンは解決できるが、一部の作業はグラフィカルインターフェースを避けられない。Instruments でメモリのタイムラインを見る、Interface Builder で制約を調整する、あるいは単に実際のレンダリングでの UI の見え方を確認したい場合などだ。このときは画面共有(VNC)に切り替える必要があり、体験はコマンドラインとはまったく異なる——遅延がより敏感に影響するため、解像度は実際に必要な範囲まで下げる(4K ではなく、たとえば 1440×900)ことを推奨する。色深度も「数千色」段階に調整すれば、リージョンを越えたアクセス時の滑らかさが明らかに改善する。日常の開発では SSH + エディタを主体とし、グラフィカルインターフェースは必要に応じて一時的に開き、VNC を常時稼働させて帯域を占有させないようにするべきだ。

チェックリストと落とし穴の記録

このワークフローを実際に導入する前に、以下の項目を確認しよう。

SSH config で ControlMaster/ControlPersist を設定し、重複したハンドシェイクによる遅延を減らす;
同じインスタンスを固定して使い続け、システムの再インストールを頻繁に行わない。そうしないと拡張機能のキャッシュとインデックスが繰り返し再構築されてしまう;
数分以上かかるタスクはすべて tmux の中に入れ、素の SSH セッションに直接紐づけない;
Xcode 関連の作業では Gateway の境界をしっかり認識し、グラフィカルなアップルのツールチェーンを引き継げると期待しない;
グラフィカルデバッグは必要に応じて VNC を起動し、解像度と色深度を下げて滑らかさを優先する;
実際に選択できる機種とノードについては、コンソールで現在選べる構成を基準にし、それに基づいて帯域幅とレイテンシの見込みを計画する。

よくある質問

VS Code Remote-SSHで再接続すると拡張機能が毎回再インストールされるのはなぜ?

拡張機能はリモート側の ~/.vscode-server に保存されるため、同じインスタンスに接続し続け、そのディレクトリを削除しない限り保持される。再インストールが起きるのは別のサーバーに切り替えたりOSを再構築した場合が多いので、契約期間中は同一インスタンスを固定するとよい。

JetBrains GatewayはXcode関連の開発に使える?

GatewayはJVM、Node、Go、Pythonなど対応するJetBrains IDEがある言語向けで、Xcodeプロジェクトには対応していない。Swift/Objective-Cの開発は依然VS Code Remote-SSHとターミナル上のxcodebuild、またはXcodeのGUIが必要な場合は画面共有で行う。

通信が不安定だとSSH経由のビルドは中断される?

ビルドプロセスをtmuxやscreenのセッション内で起動していれば、SSHが切れてもプロセスは動き続け、再接続後にtmux attachで出力を引き続き確認できるため再実行は不要。

クラウド Mac で組む遠隔開発ワークフロー:VS Code Remote-SSH と JetBrains Gateway の実践調整