Mac miniをClaude Codeの常駐サーバにする ― 母艦を占有しないための機材と停電対策

Claude Code（cc）を使っていると、「対話しながら手伝ってもらう」だけでなく、バッチやループで作業を回し続けたい場面が出てきます。定期的な処理や検証、地道な一括作業などを cron / loop で夜通し走らせるとなると、当然ながら PCを点けっぱなしにしておく必要があります。

ここで困るのが、その作業を自分のメイン機（母艦）でやると、母艦を占有し続けてしまうこと。スリープさせられないし、再起動もしづらい。作業中はファンも回るし電気も食う。

そこで「メイン機とは別に、点けっぱなしで loop / cron を担わせる常駐専用機がほしい」という発想になります。この記事は、その常駐機として Mac mini を選ぶ構成と、実際に必要になる機材（停電対策・ヘッドレス運用まわり）を、自分が組むつもりで整理したものです。

常駐機に求める4つの要件

専用機に何を求めるかを先に言語化しておくと、機材選びがブレません。

1. 常時起動できる／スリープしない ― loop を止めないために、ディスプレイを切ってもマシンは動き続ける設定にする
2. 停電で落ちない ― 突然の停電でプロセスが飛んだり、SSDが壊れたりしないよう電源を守る
3. 母艦から遠隔操作できる（ヘッドレス） ― モニタ・キーボードを常設せず、画面共有やSSHで触る
4. 母艦から独立している ― 母艦を再起動しても、専用機の作業は止まらない

この4つを満たすのに、Mac mini はかなり素直な選択肢です。

なぜMac miniか

• 省電力：24時間つけっぱなしにするので、消費電力は地味に効いてきます。M4 の Mac mini はアイドル時で数W〜、負荷時でも常識的な範囲で、常時稼働の電気代が軽い。
• 静音・小型：ファンがほぼ聞こえず、机の隅やモニタ裏に置ける。常駐機は「存在を忘れられる」ことが正義です。
• 性能：cc 自体の推論はクラウド側で動きますが、手元では node / vite のビルド、テスト（Playwright など）、Docker といった実作業が走ります。ここが意外とメモリを食う。

構成の選び方（重要）

現行の Mac mini は Apple M4 世代（2024年10月〜）です。M5 世代は2026年後半に出る見込みですが、本記事執筆時点（2026年7月）ではまだ未発売。なお2024年の登場時より2026年6月に値上げされ、16GB/256GBの基本構成で $799〜（日本では実売価格を要確認）になっています。急ぎでなければ M5 を待つ手もありますが、「今すぐ常駐機がほしい」なら M4 で十分実用的です。

常駐サーバ用途では、基本構成のままだと少し心許ないので、次を意識するとよいです。

• メモリは 24GB 以上を推奨（できれば 32GB）。私の環境ではランキングサイトのビルドがメモリ不足（OOM）で落ちた経験があり、ビルドやテストを並列で回す常駐機ほどメモリが効きます。
• 内蔵SSDは 512GB 以上。基本の 256GB は、リポジトリ・ログ・ビルド成果物を溜めるとすぐ苦しくなります（後述の外付けSSDで補うのも手）。

クラウドでもいいのでは？（自宅機 vs クラウドの損益分岐）

「わざわざMac miniを買わなくても、AWSのLightsailやEC2みたいな小さいインスタンスを立てて、SSH＋tmux で繋いで作業すればいいのでは？」——当然の疑問です。結論を先に言うと、機能的には全然アリ。ただ「24時間回し続ける」前提だと、長く使うほどクラウドが割高になります。

前提として、cc が消費するのはどこで動かしても同じサブスク枠なので、判断は純粋にインフラのコストと手間の話です。ビルドやデプロイも Linux で同じように動くため、機能的にクラウドで困る点はありません。

分かれ目は累計でどれだけ動かすか。クラウド（オンデマンド）は動かした時間だけ課金される一方、一度買ったMac miniは電気代を除けばほぼ固定費です。なので「本体代 ÷ クラウドの時間単価」で出した累計稼働時間を超えると、Mac miniの方が安くなります。本体を¥90,000として計算すると、回収ラインはこうなります。

比較するクラウド	時間単価	回収する累計時間	24時間フル稼働なら
16GB相当（t3.xlarge）	約¥34/時	約 2,600 時間	約 108 日（約3.6か月）
8GB相当（t3.large）	約¥17/時	約 5,300 時間	約 221 日（約7.3か月）

つまり24時間回しっぱなしなら、およそ3〜7か月でMac mini本体の元が取れ、以降はほぼ電気代だけになります。loop や cron を常時回したい今回の用途では、この分岐点をあっという間に超えるので、長い目で見ればMac miniが有利です。

逆にクラウドが向くのはこんなケースです。

• 24時間ではなく「作業するときだけ」動かす（＝累計時間が短い）。オンデマンドEC2なら使った分だけの課金で済む。
• ハード・電源・UPSの面倒を一切持ちたくない（停電も再起動もAWS任せにできる）。
• どこからでも触りたい／使い捨てたい／初期費用を出したくない。

※ 上はざっくりした概算です。実際にはMac miniの電気代（月¥300前後）とクラウドの固定費（ストレージ・IPアドレスで月¥800前後）があり、むしろクラウドの固定費の方が大きいぶん、Mac miniは上の目安より少し早く元が取れます。t3系はバースト型なので、ビルドを長時間ぶん回す用途では実質単価が上がり、回収はさらに早まります。

スリープさせない設定

機材の前に、常駐機として使うためのmacOS側の設定を押さえておきます。ここを外すと、せっかく機材を揃えても loop が途中で止まります。

• システム設定 → バッテリー／省エネルギーで、「ディスプレイをオフにしてもスリープさせない」を有効に（電源接続時にスリープしない設定）。
• 「停電後に自動的に起動」を有効に。これが無いと、UPSで一時的に耐えても、いざ電源が復帰したときにマシンが上がってこず、loop が止まったままになります。
• 念のため、ターミナルで caffeinate -s を噛ませておくと、特定のプロセス実行中はスリープを抑止できます。

停電で落ちない：UPS（無停電電源装置）

常駐機の一番の弱点が停電です。作業中に電源がブツっと切れると、走っていたプロセスが飛ぶだけでなく、書き込み中だとSSDやファイルシステムが壊れることもあります。

ここで UPS（無停電電源装置） を挟みます。UPSはバッテリーを内蔵した電源で、停電したら一定時間だけ給電を続けてくれます。ポイントは「無限に動かす」ためではなく、停電を検知して安全にシャットダウンするまでの時間を稼ぐこと。

macOS は USB接続のUPSを標準で認識し、バッテリー残量に応じて自動シャットダウンを設定できます（システム設定にUPSの項目が現れます）。オムロンなどの国内メーカーは専用ソフトも用意しており、Mac との組み合わせ実績が豊富です。選ぶときは、正弦波出力（矩形波より機器にやさしい）で、Mac mini + 周辺機器をまかなえる容量（350〜500VAあれば十分）のものを選べば安心です。

ヘッドレス運用：モニタ無しで動かす

常駐機にモニタ・キーボード・マウスを常設するのは場所の無駄です。母艦から画面共有（Screen Sharing）や SSH で触るのが基本になります。

ここで地味に効くのが HDMIダミープラグ。Mac mini はモニタを繋いでいないと、GPUが「画面なし」と判断して画面共有の解像度が低く固定されたり、挙動が不安定になることがあります。ダミープラグを挿すと仮想的にモニタが接続されている状態になり、画面共有が正しい解像度で映ります。数百円のパーツですが、ヘッドレス運用の快適さがまるで違います。

ネットワークは、可能なら有線LANを推奨。Mac mini は有線イーサネットを内蔵しているので、Wi-Fi より安定して常駐機に向きます。

ストレージ：外付けSSDに逃がす

常駐機はログもビルド成果物もどんどん溜まります。内蔵SSDの空きと書き込み寿命を温存するため、リポジトリ・ログ・バックアップは外付けSSDに逃がすのがおすすめです。USB-C接続のポータブルSSDなら十分な速度が出ますし、母艦への差し替えバックアップにも使えます。

信頼性重視なら、実績のあるブランド（SanDisk など）を選ぶと安心です。バックアップ用途は「安さ」より「壊れにくさ」を優先したいところ。

【コラム】課金の「別枠」を当てにしていいか

この構成を考えるとき、「非対話（バックグラウンド）の利用は別枠のクレジットになるから、常駐機で回し続けた方が得」という話を聞いたことがあるかもしれません。前半の「別枠のクレジットになる」は（発表ベースでは）事実です。ただ、ここで大事なのは——「別枠になる」＝「お得になる」ではない、ということ。ここを取り違えると、常駐機を持つ判断そのものを誤ります。

なぜ得にならないのか。発表された制度の中身を見ると、この別枠はプラン料金と同額の固定クレジット（Max 20xで$200相当／月）で、繰り越し不可。使い切ったら停止か API 従量課金に流れる設計でした。要するに「無から湧く追加の無料枠」ではなく、払った金額ぶんの上限が、対話用とは別のバケツに分けられているだけです。

• 別枠の主眼はバックグラウンド処理が対話セッションの枠を食い合わないようにする「隔離」であって、回した量に応じて得が増える仕組みではない。
• 固定・繰越なしなので、常駐機で24時間回し続けても「別枠を余計に引き出せる」わけではない。むしろ重いループなら固定枠を早く食い潰し、あとは停止か API 課金。回し続けるほど電気代はかかるのに、得は増えません。
• 対象は非対話のみ（claude -p／Agent SDK など）で、ターミナルやIDEでの対話利用は対象外。
• さらに言えば、この別枠制度は2026年6月15日の予定で発表されたのち現在は保留（paused）されており、公式ヘルプには「現時点では従来どおりサブスク上限にカウントされ、別枠クレジットの仕組みは無い」と明記されています。

結論として、サーバ化がもたらすのは「課金の得」ではなく、「母艦を占有せず、24時間 loop / cron を担わせられる常駐基盤」そのものです。動機をそこに置けば、別枠制度が復活しようが保留のままだろうが、構成の判断はブレません。

まとめ

Claude Code に作業を回し続けさせたいなら、母艦とは別の常駐専用機を用意するのは理にかなっています。Mac mini はそのための省電力・静音・小型な選択肢で、揃える機材は次の通りでした。

• Mac mini（M4） ― メモリ 24GB 以上・SSD 512GB 以上を推奨
• UPS（無停電電源装置） ― 停電で落とさない。正弦波・macOS自動シャットダウン対応
• HDMIダミープラグ ― モニタ無しヘッドレス運用で解像度を確保
• 外付けSSD ― ログ・リポジトリ・バックアップの逃がし先

課金の「別枠」は当てにせず、常駐基盤そのものの価値で構成を組むのが、いちばん揺らがない考え方だと思います。