クラウドMac miniにMCP Serverをデプロイ：stdioから本番安定まで完全実践ガイド

MCPアーキテクチャ / stdio vs SSE / 環境設定 / ツール登録と権限 / launchd常駐 / SSHトンネル / SSEマルチクライアント / 本番安定性 / FAQ

Cursor、Claude Desktop、OpenClawを触っていると、やがて同じ問いにたどり着きます：MCP Serverはどのマシンで動かすべきか？メイン機で動かせばShellとファイルシステムがAgentに直接晒される。リモートLinuxに置けばmacOSツールチェーンとの齟齬が生まれる。クラウドMac miniはちょうどその中間に位置します——Unix環境、スナップショット隔離、ネイティブmacOSツールが揃っています。このガイドはstdioサブプロセスの基本から、SSEマルチクライアント、launchd常駐、7×24稼働の本番構成まで順を追って説明します。

MCPアーキテクチャの3役割：Host・Client・Server

作業前に3つの役割を整理します。

• Host — UIを持つアプリ（Cursor、Claude Desktop、OpenClawなど）。1つ以上のClientのライフサイクルを管理します。
• Client — Host内部のプロトコルアダプター層。Serverを発見し、接続を維持し、ツール呼び出しを転送します。
• Server — 独立して動くプロセス。標準化されたプロトコルでツール（Tools）・リソース（Resources）・プロンプト（Prompts）を公開します。

Host (Cursor)
  └─ Client
       └─ [stdio / SSE] ──── Server (MCPツールプロセス)

設計原則：Serverプロセスは最小権限で動作させる——現タスクに必要なツールだけを登録し、「万能Agent」アンチパターンを避けてください。

転送層の選択：stdio vs SSE vs WebSocket

以前の 各統合ごとにRESTグルーレイヤーを書く アプローチは、MCPの統合ツール発見プロトコルに置き換わりました。Hostは起動時にServerからtools/listを自動取得し、統合ごとのカスタムHTTPクライアントが不要になります。この転換でツール統合は「毎回ゼロから書く」から「宣言するだけで使える」に変わり、個人開発者でも午後一つで十数個のMCPツールを接続できます。

転送層用語集

stdio転送

HostはServerをサブプロセスとして起動し、stdin/stdoutでJSON-RPCメッセージを交換します。プロセスはHostと共に終了し、自然に隔離されてネットワーク露出はありません。

SSE（Server-Sent Events）

ServerはHTTPポートを待ち受け、Clientは持続的な接続でイベントを受信します。複数クライアント同時接続に対応しますが、ネットワークセキュリティ設定が必要です。

ツール発見（tools/list）

MCPのハンドシェイクフェーズ：Host起動時にServerへtools/listをリクエストし、ツール名・パラメータスキーマ・説明を取得してから必要に応じて呼び出します。

HITL（Human In The Loop）

センシティブな操作でツール呼び出しを一時停止し、人間の確認を待つパターン。モデルに完全な自律判断を委ねません。

ステップ1：クラウドMac環境の準備

ノードの選択

レイテンシと地域

日本・シンガポールノードはGitHub・npmへのレイテンシが通常20–60 msで、依存関係を頻繁に取得するMCPツールに最適です。

メモリと推論

MCP Server＋ローカル小型モデル（Ollama 7Bクラス）を同時に動かす場合はM4 + 16GB以上を推奨します。

推奨構成対照表

環境の初期化

# Homebrewのインストール（未インストールの場合）
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Node.jsのインストール
brew install node@20
echo 'export PATH="/opt/homebrew/opt/node@20/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc

# 確認
node -v && npm -v

ステップ2：filesystem MCPサーバーのデプロイ（stdioモード）

# filesystem Serverを起動（ワークスペースを/Users/agent/workspaceに限定）
npx -y @modelcontextprotocol/server-filesystem /Users/agent/workspace

Cursorのmcp.json設定（~/.cursor/mcp.json）に追加：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/agent/workspace"]
    }
  }
}

設定のポイント：Ctrl + Cでローカルstdio Serverを停止できます。リモートノードではSSHセッション終了後もServerが落ちないようlaunchdでプロセスを管理してください（ステップ4参照）。

ステップ3：SSHトンネルでリモートCursorと接続

# リモートポート3000をローカルにマッピング（SSEモード用）
ssh -L 3000:127.0.0.1:3000 user@cloud-mac.zekvps.com

# リモートマシンにSSHしてServerを起動（stdioモード）
ssh user@cloud-mac.zekvps.com "npx -y @modelcontextprotocol/server-filesystem /workspace"

長期安定稼働にはTailscaleでMesh VPNを構築し、手動SSH転送を置き換えることをお勧めします。

ステップ4：launchdデーモンで7×24稼働を実現

~/Library/LaunchAgents/com.zekvps.mcp-filesystem.plistを作成：

<?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.zekvps.mcp-filesystem</string>
    <key>ProgramArguments</key>
    <array>
        <string>/opt/homebrew/opt/node@20/bin/npx</string>
        <string>-y</string>
        <string>@modelcontextprotocol/server-filesystem</string>
        <string>/Users/agent/workspace</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>
</plist>

launchctl load ~/Library/LaunchAgents/com.zekvps.mcp-filesystem.plist
launchctl start com.zekvps.mcp-filesystem
launchctl list | grep mcp

セキュリティ境界と権限管理

1. 最小ディレクトリ権限——server-filesystemのパスは必要なディレクトリのみに絞る。~や/全体は渡さない。
2. 環境変数でシークレットを注入——APIキーはenv注入、plistやmcp.jsonには書かない。
3. SSEポートの認証——SSEを開放する場合はBearer Token＋リバースプロキシ＋TLSを必ず設定。
4. スナップショットによるロールバック——大きな変更前に手動でスナップショットを取得。

まとめ：デプロイパスの選択

サイト内のOpenClawコラムでは、OpenClawとMCP Serverの協調デプロイの実践例を紹介しています。