2026 クラウドMac共有SSHセッション運用：同時ログイン、引き継ぎと監査チェックリスト

複数エンジニアが1台のレンタルApple SiliconクラウドMacを交代で使う—iOSリリース列車や共有ビルドエージェントでよくある—場面では、SSHが衝突を招きやすいです。古いtmuxがファイルロックを保持したり、他者のxcodebuild中に誰かが再起動したり、監査で「02:14 UTCに誰がシェルを持っていたか」と聞かれても答えられない、といった事態です。本チェックリストの結論：共有クラウドMacのSSHは有人オペレーションデスクのように扱い、コンソール担当を公開し、引き継ぎチケットを徹底し、コンプライアンスレビュー前にセッション証跡を集めましょう。

アカウント戦略はマルチユーザーMacガバナンス、身元衛生はSSH鍵ローテーションと2FA、リース終了時はエンタープライズオフボーディングのデータ消去と併用してください。セッション中に信頼が崩れたらリモートログイントラブルシューティングに戻ります。

共有SSHセッション運用が必要なケース

• プラットフォームチームが1台のMacLoginノードをAPACとUSのタイムゾーンを跨いだ「コンパイルホットシート」として運用する場合。
• 請負ユニットで、ディスク状態について2名の専門家が食い違った認識を持ってはならない場合。
• 規制業界で、ベンダー側ログだけに頼らずインタラクティブアクセスの時間帯を証明しなければならない場合。

同時SSHリスクマトリクス（2026）

パターン	主なリスク	緩和策
共有管理者アカウント	アトリビューション不可	別アカウント、またはセッションログ付きの名前付きsudoers
同一Gitリポで並列シェル	インデックスロック／マージ破損	チケット＋.lock規約で直列化
長寿命tmux	隠れた特権コマンド	セッション名をuser-date-ticketにし、引き継ぎに一覧を貼る
未告知の再起動	ビルド損失／CIフレーク	sudo reboot前にチャットで#incidentまたはメンテタグを必須に

ログイン前チェックリスト（毎回）

1. 告知：このノードに紐づくチームチャンネルにチケットIDとETAを投稿。
2. セッション確認：who -uとps -ax | grep sshdを実行。不明なPTYはkill前にオンコールへ。
3. ディスク：df -h—ビルドボリュームの空きが15%未満なら大容量転送を中止。
4. 鍵の確認：プロバイダメンテ後はホスト鍵信頼チェックリストに沿う。

シフト中の衛生

tmuxまたはscreenのセッション名にエンジニアエイリアスとJIRAキーを含めます。チケットに記載のない/tmpのPIDファイルなしnohupジョブは避けます。GUI寄りの作業ではVNCウィンドウを調整し、2名が同じセッションを奪い合わないようにします。

切断前の5ステップ引き継ぎ

1. 書き込み停止：ロックを持つパッケージマネージャと同期クライアントを終了。
2. 状態スナップショット：tmux list-sessionsの出力をチケットに貼付。
3. ポート：次シフトに必要なssh -Lフォワードを記載。
4. シークレット：トークンを含むスクロールバックは消去。漏洩時はローテ。
5. サインオフ：UTCタイムスタンプ付きで「引き継ぎ完了」とコメント。

FAQ

他のSSHセッションを強制切断してよいか？ 文書化されたランブック権限がある場合のみ。それ以外は共有チャンネルで調整し、本番ビルドを中断しないこと。

MacLoginは社内ログを代替するか？ いいえ—ヘルプの接続情報に加え、SOC2系証跡用に自前のコマンド記録を使ってください。

ノード追加はどこで？ 料金でリージョンを比較し、RTTに有利なサイトを選んでから共有フリートを拡張してください。