シーンとレーン分け
画面＝短時間のレビュー／ダイアログ、SSH＝ビルドと gitに分けると衝突が減ります。Screen Sharing は同一 GUI セッションに乗るため観察者でも画面露出は残ります。ユーザ分離が難しい場合はリポジトリ境界と credential 分離を先に（権限 FAQ）。
遅延と帯域
SSHはRTT中心、Screen Sharingは解像度・更新・可変ビットレートが支配的です。経路を混ぜると「SSH が遅い」誤診になりやすいので計測は分離します。画面席は短時間・低解像度、鍵ローテはSSH ローテの窓と干渉させないでください。
権限モデル（観察者・多ユーザ衝突）
観察者は入力争いを抑えますがファイル権限と画面露出は別です。共有ユーザではダイアログの責任者が曖昧になりやすいので、画面席＝チケット番号、SSH＝命名 tmuxでラベル統一（隔離マトリクス）。
並行ビルドロックとの連携
同一 DerivedData／作業木を画面と SSHで掴むと幽霊ロックが出やすいです。flock 等でヘッドレスを直列化し、画面はロック外へ（flock FAQ）。
defaults／ファイアウォールと席の規約
次を席ごとに記録します。
- ☐SSH：TCP 22 を意図ソースのみへ。
- ☐Screen Sharing：許可した 5900 系（ディスプレイでオフセット）が境界と一致するか。
- ☐アプリ FW：
sshdと画面共有が誤ブロックされていないか。 - ☐plist／defaults：リモート管理・画面共有の組織標準との差分をスナップショット化。
- ☐席：画面は予約・解像度・観察か操作を明記。SSH は Host 別鍵、credential は マトリクスに揃える。同一作業木に画面と自動ビルドを載せない。
※境界ルータと社内方針に従ってください。
対照早見（強い比較意図）
| 観点 | SSH 純端末 | Screen Sharing |
|---|---|---|
| 主な遅延要因 | RTT・暗号・DNS | 解像度・更新・エンコード |
| 典型ポート | 22（運用で固定） | 5900 系など（席で確定） |
| 席の先取り | tmux 名・ロックで緩和 | GUI 一系統。予約と観察者が要る |
| 権限の落とし穴 | 鍵・agent 転送・作業木 | 画面露出・同一ユーザ GUI |
切り分け FAQ
問 画面を閉じると SSH だけで十分ですか。
答 週次で GUI 手続きが無いなら十分なことが多いです。残るのは署名・notarize・デバイス実機などレーン分離の判断です。
問 観察者だけにすればセキュリティ監査は通りますか。
答 入力制御と機密の画面露出は別次元です。ログ・トークン表示ポリシーとセットで説明してください。
問 ポートを絞ったら片方だけ通りません／ビルドが壊れます。
答 接続は境界・ホスト・アプリの三層で切り分け（5900 系だけ開け 22 を閉める誤設定は典型）。ビルド不調は多く同一作業木と並行が原因で、画面よりロックと作業ディレクトリを先に疑います。
まとめ
GUI レーンと作業レーンを分け、ポート・席・ロックを運用表へ。
レーン設計を先に、接続は二の次で揃える
ノード追加やプラン比較はログイン不要で確認できます。接続手順はヘルプ、連載はブログ一覧からどうぞ。