Mac mini M4 ProでAIエージェント監視基盤を作る実践手順

Mac miniでAIエージェントを回し始めたけど、「止まっていたのに朝まで気づけなかった」で悩んでいる人に向けて書きました。この記事では、Mac mini AIエージェント 監視を現場で回せる形にするために、SLOの決め方、Claude Code 24時間運用の設計、自動復旧までを整理します。僕は福祉事業のIT全般を担当しながら複業でAI×SaaS開発もやっているので、現場で使える粒度でまとめます。

目次

• Mac mini AIエージェント監視で最初に決めるSLO
• Claude Code 24時間運用を支える監視スタック設計
• Uptime Kuma Slack 通知を最短で実装する手順
• 自動復旧と週次レビューで運用品質を上げる方法

Mac mini AIエージェント監視で最初に決めるSLO

監視ツールを入れる前に、まずSLOを決めます。SLOは「どれくらい動いていれば合格か」を数字で決めるルールです。ここが曖昧なままだと、通知だけ増えて安心感は増えません。僕の環境では最初に稼働率99.5%（月の停止許容3時間39分）を置きました。いきなり99.99%を狙うと、個人運用や少人数チームでは対応負荷が上がりやすいからです。

最初に定義する項目は次の3つです。

• 対象範囲 — Claude Code実行ワーカー、キュー、Webhook受信口のどこを守るか
• 判定間隔 — 30秒で見るのか、1分で見るのか
• 復旧目標 — 15分以内に一次復旧できるか

「なるべく止めない」のような測れない目標は置かないのがポイントです。つまり、監視はツール選びより先に、合格ラインの言語化から始めるということです。

Claude Code 24時間運用を支える監視スタック設計

Claude Codeを24時間回すと、プロセスは生きているのに成果物が出ない、という半停止が起きます。なので監視を1つに任せず、僕は「プロセス」「エンドポイント」「業務」の3層で分けています。1つの監視に全部乗せしないだけで、見逃しが減ります。

さらに、外部監視を1本足すと「家の回線ごと落ちた」も拾えます。僕は外からの死活確認だけ小型VPSに逃がしていて、ConoHa VPSのような低コスト環境で十分回せています。つまり、Claude Code 24時間運用は、強い単体ツールより役割分担した3レイヤー設計が安定しやすいです。

Uptime Kuma Slack 通知を最短で実装する手順

ここから実装です。Mac mini M4 ProならDockerで十分動くので、まずUptime Kumaを立ち上げてSlack通知をつなぎます。作業は「起動」「監視追加」「通知先設定」の3ステップだけです。最小構成なら1時間で運用開始できます。

1. 起動 — 永続ボリューム付きでUptime Kumaを起動する
2. 監視追加 — /health とジョブ完了Webhookを登録する
3. 通知設定 — Slack Webhook URLを入れてテスト送信する

version: "3.8"
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./kuma-data:/app/data

Slack通知は最初から細かく分けすぎないほうが回ります。僕は次の3種類に絞っています。

• Down通知 — 即時送信
• 復旧通知 — 即時送信
• 再通知 — 10分継続時のみ送信

運用チャネルと雑談チャネルを分けるだけでも見逃しが減ります。イメージとしては、救急連絡を通常連絡と同じ部屋に置かない、という設計です。

自動復旧と週次レビューで運用品質を上げる方法

通知だけだと、深夜は「気づいたけどすぐ触れない」が起きます。なので一次対応を自動化します。僕の設定は「3回連続失敗で再起動」「20秒後に再チェック」「失敗ならSlackで手動対応依頼」です。100点の復旧を狙うより、60点の応急処置を最速で返す設計のほうが全体運用は安定します。

#!/bin/zsh
HEALTH_URL="http://127.0.0.1:8080/health"
SERVICE_NAME="com.masu.agent.worker"

if ! curl -fsS "$HEALTH_URL" >/dev/null; then
  launchctl kickstart -k "system/$SERVICE_NAME"
  sleep 20
  curl -fsS "$HEALTH_URL" >/dev/null || \
    curl -X POST -H "Content-Type: application/json" \
    -d '{"text":"[agent] 自動復旧失敗。手動確認お願いします"}' "$SLACK_WEBHOOK"
fi

週次レビューでは、MTTD（検知時間）・MTTR（復旧時間）・誤検知率の3指標だけ見ます。僕の直近4週間では、MTTDが12分→4分、MTTRが27分→8分、誤検知率が22%→9%まで改善しました。関連する初期構築は、Mac miniクラスター初期構築の記事と合わせると流れがつかみやすいです。

監視を後回しにすると1年で積み上がる見えない損失

監視を入れないまま運用すると、障害そのものより「止まっていたのに気づかない時間」が増えます。例えば月2回、各45分の停止を見逃すだけで、年間18時間が消えます。監視を知らないままだと、止まることより放置時間が長くなる可能性があります。SLOと通知導線を決めるだけでも、未来の事故コストを大きく下げられます。

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

僕はSES、教育、人事を経て、今は福祉領域のIT運用とAI開発を並行しています。550名以上のキャリア面談をしてきた中で、技術が高い人ほど「運用の言語化」で詰まる場面を何度も見てきました。だから監視を専門用語だけで語るのではなく、非ITメンバーとも共有できる形で残したいんです。エンジニア×コミュニケーション×AIを非ITに持ち込む価値は、こういう運用設計でこそ活きると思っています。

次のアクション

ここまで読んだら、30分でSLOを1行書いてみてください。回る最小構成を先に作ります。必要ならMac mini冷却スタンドも確認してみてください。