Claude Code MCP運用設計ガイド｜Mac miniで24時間安全化

Claude Code MCPを触って「便利だけど、怖い」と感じる人は多いですよね。Mac miniで複数AIエージェントを24時間回すなら、機能追加より先に認証・権限・監査の設計が必要です。この記事では、MCPサーバー 運用を実装できる形でまとめます。

Claude Code MCPを24時間回す前に決める設計原則

24時間運用で最初に決めるべきなのは、連携ツール数ではなく責任分界です。ここが曖昧だと、障害時に「どこで止めるか」が決まらず復旧が遅れます。家の鍵を分けるように、MCPサーバー 運用も鍵を分けるほど被害を局所化しやすいです。

軸は「認証」「権限」「監査」の3層分離です。認証はMCP仕様に沿って通し、権限はClaude Code側で止め、監査はネットワーク経路まで追える形にします。2025年6月18日版Transport仕様ではStreamable HTTP中心、Origin検証、127.0.0.1バインド推奨が示されています。

• 認証 — OAuth 2.1/PKCE/HTTPS要件を満たす
• 権限 — allow/ask/denyとHooksで実行可否を制御する
• 監査 — 誰が何を実行したか時系列で追跡する

まずこの3つを固定すると、後からMCPを増やしても設計が崩れにくいです。接続仕様はClaude Code MCP公式を基準にすると迷いません。

認証設計の実装ポイント（OAuth 2.1/PKCE/HTTPS）

2025年11月25日版のMCP Authorization仕様では、Bearerトークンを毎HTTPリクエストに付与、URLクエリへの埋め込み禁止、失効時401応答が明確化されました。つまり認証は「通ればOK」ではなく、送信方法と失敗時挙動まで設計対象です。ここを曖昧にすると、ログ経由の漏えいリスクが上がります。

僕が最初に入れるのは、HTTP transportでのMCP登録、MCP_TIMEOUT明示、PKCE検証のチェックリスト化です。起動遅延や再試行ループを潰せるので、夜間障害の切り分けが楽になります。

# MCPサーバー登録（HTTP推奨）
claude mcp add --transport http notion https://mcp.notion.com/mcp

# 起動待ちタイムアウト（10秒）
MCP_TIMEOUT=10000 claude

# 毎リクエストでBearerを付与
Authorization: Bearer <access-token>

仕様原文はMCP Authorization 2025-11-25です。導入を早めたい人は、先にMac mini公式構成ページ（PR）でハード構成を決めておくと判断が速くなります。

権限分離と監査ログを1本化する実践手順

認証が通っても危険操作は実行できます。なので次は権限です。Claude Codeでは.claude/settings.jsonのallow/ask/denyで宣言的に制御できます。僕の基本はdefaultMode: askで、最初は確認必須にします。さらにdisableBypassPermissionsMode: trueを有効化して、バイパス前提の運用を防ぎます。「止められる自動化」を先に作ることが重要です。

{
  "permissions": {
    "allow": ["Read(./docs/**)", "mcp__notion__search"],
    "ask": ["Bash(git push *)", "mcp__prod-db__query"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(rm -rf *)"],
    "defaultMode": "ask",
    "disableBypassPermissionsMode": true
  }
}

監査はHooksとTailscaleでつなぎます。PreToolUseでpermissionDecisionを記録し、traceIdでOTelに結合、接続経路はTailscale監査ログで照合します。監査ログは90日保持で、設定変更起点の事故を追いやすいです。

詳細はsettings、hooks、Tailscale監査ログを合わせて確認すると理解しやすいです。

Mac mini AIエージェントを止めない運用とRunbook

Mac mini AIエージェント運用では、性能比較より「止まらない設定」を先に作るのが実務的です。僕はMac mini M4 Pro（24GB）でGhostty+tmux+Claude Codeを常時起動しています。Apple公式値はM4がIdle 4W/Max 65W、M4 ProがIdle 5W/Max 140Wです。平均15Wで計算すると、24時間×30日で10.8kWh、31円/kWh換算で約335円です。

• スリープ抑止 — 夜間ジョブ停止を防ぐ
• Runbook常設 — 検知→遮断→復旧→再発防止を固定化

# スリープ抑止の例
sudo pmset -a sleep 0
sudo pmset -a displaysleep 10

# 高リスクノードの再認証
"action": "check", "checkPeriod": "5m"

Runbookは4手順です。1. deny急増や401連発を検知。2. 問題MCPを停止しACLを絞る。3. トークン再発行と設定再読込。4. 原因を「設定・実装・運用」に分類して再発防止策を追記。運用は気合いより手順書です。電力情報はApple Support、SSH checkはTailscale SSHを基準にします。

設定を曖昧にしたまま運用した先のリスク

認証・権限・監査を後回しにすると、最初は速く進みます。でも1年単位で見ると、障害調査の時間が積み上がって開発速度が落ちる可能性があります。とくに「誰が許可したか」を追えない状態は、人に依存した運用になりやすいです。この情報を知らないままだと、自動化が逆に足かせになることがあります。だからこそ、最初に制約を設計しておく価値があります。

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

僕はMac mini M4 Proを24時間稼働し、Node.js+TypeScript+tmuxで複数エージェントを運用しています。運用を続ける中で、機能連携より統制設計が先だと痛感しました。権限と監査を明文化してから夜間障害の切り分けが速くなったので、同じ不安を持つ人に届けたいんです。

次のアクション

ここまで実装できれば、MCPサーバー 運用は安定します。詰まった点はコメントで教えてください。