Mac mini M4 Pro AIエージェント15分復旧Runbook

Mac mini M4 ProでAIエージェントを24時間回していると、停電や回線断で「朝見たら全部止まっていた」が普通に起きますよね。この記事は、そんな不安を減らしたい人に向けて書いています。読むと、UPS設定・自動再起動・通知・Claude Codeの再開まで、15分で戻すための手順をそのまま実装できます。僕は福祉事業のIT全般を担当しながら、AI×SaaS開発でも同じ課題に毎日向き合っています。

15分復旧Runbookは「定義」から始めるのが最短です

最初に決めるのはツール選定より基準です。ここが曖昧だと、障害時に「何から直すか」で時間を失います。僕が固定しているのは、RTO（復旧目標時間）を15分、RPO（失ってよいデータ量）を5分以内にすることです。つまり「15分で業務再開、5分以上のログは失わない」という共通認識を先に作るということです。

イメージとしては救急のトリアージです。全部を同時に直すのではなく、業務インパクト順に戻します。AIエージェント運用だと、優先順位は「電源」「回線」「プロセス」の順で十分回ります。ここを決めるだけで、現場の会話が「原因探し」から「復旧実行」に変わります。

停電対策UPSは「容量設計→自動停止→自動起動」で固めます

Mac mini (2024) M4 Proは最大連続消費電力が155Wです。ここにルーターやONU、スイッチの電力を足して、さらに20〜25%の余裕を載せると、UPS選定の目安が作れます。たとえば155W+30W=185Wなら、185×1.25で約231Wです。最低でも480Wクラス、余裕運用なら900Wクラスが現実的です。

実装はmacOS標準機能でかなり進みます。GUIならEnergy設定で「停電後の自動起動」「Wake for network access」「UPS Options」を設定できます。UPS停止条件はApple公式UPS設定の通り、時間と残量の両方を設定しておくのがおすすめです。

sudo systemsetup -setrestartpowerfailure on
sudo systemsetup -setrestartfreeze on
sudo systemsetup -setWaitForStartupAfterPowerFailure 30

pmset -g sched
sudo pmset repeat wake M 08:00:00
sudo pmset repeat cancel

-setWaitForStartupAfterPowerFailureは30秒単位です。復電直後はネットワーク機器がまだ上がっていないことが多いので、30〜60秒待機にしておくと再起動失敗が減ります。容量検討時はUPS選定ガイド、実運転時間の比較はAPC公開値やCyberPower公開値を確認しておくと判断しやすいです。

回線断は「心拍監視」と「通知」を分けると復旧が速くなります

回線断は、実は停電より気づきにくいです。そこで「エージェントが動いているか」を一定間隔で送る心拍監視を入れます。僕はHealthchecksの方式を採用しています。無料枠で20ジョブまで監視でき、14:00実行ジョブにGrace 30分を設定すれば、14:30未着でDown判定になります。検知が早いだけで、復旧時間は体感で半分になります。

• ジョブ実行側 — 正常終了時にHealthchecksへping送信
• 監視側 — Grace超過でDown判定
• 通知側 — Slack Incoming Webhookへ即時通知

#!/usr/bin/env bash
set -euo pipefail

./run-agent-batch.sh
curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/<uuid>

# 障害通知（別ジョブ）
curl -X POST -H "Content-type: application/json" \
  --data '{"text":"[ALERT] mac-mini agent heartbeat missing"}' \
  "$SLACK_WEBHOOK_URL"

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

プロセス停止・暴走はlaunchdとClaude再開コマンドで吸収します

AIエージェントは、回線やAPI都合でプロセスが落ちる日があります。ここで手動復旧だけに頼ると、夜間に止まったときに詰みます。macOSではApple推奨の常駐管理がlaunchdなので、KeepAliveで再起動を任せるのがシンプルです。ただし連続クラッシュ時は抑制が入るので、無限再起動前提の設計は避けます。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>com.masu.aiagent</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/zsh</string>
    <string>/Users/you/bin/start-agent.sh</string>
  </array>
  <key>RunAtLoad</key><true/>
  <key>KeepAlive</key><true/>
</dict>
</plist>

Claude Code側は、復旧の入口を固定しておくと速いです。セッション継続はclaude --continue、履歴選択はclaude --resume、非対話復帰はclaude --continue --print "Continue recovery"で揃えます。複数ペイン運用ならtmux/tmuxpでセッション構成を保存しておくと、OS再起動後でも再構築時間を短縮できます。

• 再起動直後 — tmux lsでセッション有無を確認
• セッション再開 — claude --continueで前回作業を復帰
• 自動実行系 — --print付きコマンドで非対話運転へ戻す

設計時はlaunchd公式とClaude Code公式ワークフローを並べて読むと、運用の抜けが減ります。

0〜15分で戻す実運用手順と月次演習チェックリスト

Runbookは「読める」より「回せる」が大事です。僕は障害発生から15分を3つに割って運用しています。これをチームで共有しておくと、誰が対応しても同じ品質になります。ここ、めっちゃ大事です。速度は気合いより手順で作れます。

障害発生から0〜15分のタイムライン

1. 0〜5分 — 障害分類（停電/回線/プロセス）を宣言し、Slackへ一次連絡。pmset -g battと回線疎通、launchctl listを確認します。
2. 5〜10分 — 停電時はUPS残量を確認しつつ自動起動待ち。回線断なら予備回線へ切替。プロセス停止ならlaunchd再読込とtmux再生成を実施します。
3. 10〜15分 — claude --continue --print "Continue recovery"で実行系を戻し、Healthchecksの最新ping時刻とSlack通知の収束を確認して復旧宣言します。

月次演習で確認する項目

• 停電模擬 — UPS給電へ切替後、自動停止と再起動が想定通りか
• 回線断模擬 — Heartbeat停止から通知到達までの分数
• プロセス模擬 — 強制終了後にlaunchdが再起動するか
• 定時演習 — pmset repeat wakeで演習ウィンドウを固定する

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

Runbookを持たないまま運用すると起きやすい損失

Runbookなしの運用は、1回の障害は小さく見えても、年間で見ると地味に重いです。「知らないままだと、戻し方を毎回ゼロから考える」状態になり、復旧時間が読めません。これは技術力より運用品質の問題です。

• 見えない停止時間が増える — 通知がないと、止まっている事実に気づくのが遅れます。
• 再現できない復旧が増える — 人によって手順が違い、次回に活かせません。
• 心理コストが上がる — 夜間や休日の不安が残り、集中して作業しにくくなります。

この記事を書いている理由

僕が実際に困ったポイントだけを残しているので、机上の空論ではなく、今日から試せる形になっているはずです。

次のアクション

まずは今夜、5分だけ使って「障害分類表」と「0〜15分タイムライン」をメモに作ってみてください。明日からの安心感がかなり変わります。