サーバー運用 · レンタル避坑 · 二〇二六
2026年 Mac mini サーバーレンタル避坑ガイド：借りたサーバーがいつもオフラインになる理由
2026.06.01
運用・避坑
約 9 分
想定読者：Xcode・CI・バッチ処理のために Mac mini をサーバーとして借りているのに、夜間や週末に SSH が切れ、ビルドが止まってしまう開発チームの方です。結論として、オフラインの多くは「Apple が不安定」ではなく、共有仮想 Mac・スリープポリシー・監視不足の組み合わせに起因します。本文では三つの痛点、業者タイプの判断表、六段階の安定化手順、引用メモ、MacWww の物理 M4 ノード購入導線を整理します。
00 オフラインが続く三つの理由：仮想化・スリープ・監視
- 「専用 Mac」と書いてあるが実体は共有仮想です。ピーク時に SSH が応答しなくなり CI がタイムアウトします。物理 Mac mini M4 を一台借りるかが最初の分岐です。
- macOS のスリープと無断再起動が許可されています。夜間ジョブ中にスリープへ入ると朝にはビルドが停止しています。ホスト側のスリープ無効と再起動通知を契約で確認してください。
- 稼働監視と SLA 通知がありません。利用者の ping だけでは障害が数時間放置されます。月間稼働率と通知チャネルを契約前に比較してください。
構成選びの基礎はM4 構成・選定ガイド、iOS 向けの接続分担はレンタル五手順をご参照ください。
01 レンタル業者タイプ判断表（2026年）
| 評価軸 | 格安共有仮想 | 中価格 VPS 型 | 物理 Mac mini 専用（MacWww） | 判断の目安 |
|---|---|---|---|---|
| 実体 | 仮想 Mac 共有 | 仮想＋一部専用 | Apple Silicon 物理機一台 | CI 本番は物理優先 |
| 夜間オフライン頻度 | 週複数回あり得る | 月数回 | SLA 管理下で稀 | ログで七日計測 |
| スリープ制御 | 利用者任せ | 一部ホスト設定 | ホスト側で無効化 | 契約書に明記 |
| SSH／VNC | SSH のみが多い | 帯域制限あり | SSH ビルド＋VNC 画面 | 実機操作は VNC 必須 |
| 障害通知 | なし | メールのみ | チケット＋稼働ページ | 無通知は避ける |
判断ルール：週一回以上の不意な切断がある時点で、共有仮想から物理専用ノードへの移行を検討してください。コスト差は、再実行と手戻りの時間で相殺されることが多いです。
02 オフラインを減らす六段階手順
- 七日間の接続ログを取ります。15 分ごとに
uptimeを記録し、切断時刻と曜日の相関を表にします。 - 契約で専用物理機とスリープ無効を確認します。曖昧な表現にはホスト ID の開示を求めてください。
- SSH keepalive を設定します。
ServerAliveInterval 60で NAT タイムアウトによる偽オフラインを減らします。 - 長時間ジョブは
caffeinateでラップします。ビルド中のスリープを防ぎます。 - 監視を一本化します。外形監視と
launchctlログを同一チケットに紐づけます。 - 改善がなければ物理 M4 へ切り替えます。24GB・固定リージョン・SSH と VNC 分担を決め SLA を再計測します。
接続手順はSSH／VNC ガイド、料金とノード一覧は料金表で確認できます。
03 社内共有に使える引用メモ
- Xcode 並列の実務下限は M4・24GB です。16GB は夜間ビルドで事実上オフラインになりやすいです。
- 共有仮想では SSH 遅延 30 秒超 で CI が失敗します。物理専用では稀です。
- 契約前は 専用物理・SLA・スリープ無効・通知・ポート の五項目で十分です。
- 移行目安は 七日で不意切断二回以上。それ以上は信頼性を優先してください。