ローカルMCPとリモートMCPの使い分け

MCP Serverは、手元のPCで動くローカル型と、サービス提供者の環境へ接続するリモート型に大きく分けられます。どちらが優れているかではなく、データと責任の置き場所が違います。

比較表

| 観点 | ローカルMCP | リモートMCP |
|—|—|—|
| 代表Transport | stdio | Streamable HTTP |
| 実行場所 | 自分のPC・サーバー | サービス提供者・クラウド |
| 認証 | 環境変数、ローカル資格情報 | OAuth、Bearer tokenなど |
| データ経路 | 原則ローカル内で処理可能 | ネットワークと提供者サーバーを通る |
| 更新 | 自分で配布・再起動 | 提供者が更新する場合が多い |
| 可用性 | 端末とプロセスに依存 | 回線と外部サービスに依存 |
| 向く例 | ローカルファイル、社内専用処理 | SaaS、公式クラウドデータ |

ローカルMCPが向く場合

• ローカルのMarkdownや専用Python処理を使う
• 外部へ送れないデータを扱う
• 独自の入力検証や監査が必要
• ネットワークポートを開けず子プロセスで動かしたい

ただしローカルだから自動的に安全ではありません。同じOSユーザー権限で動けば、Serverが読める範囲は広くなります。固定パス、実行ユーザー、環境変数の渡し方を制限します。

リモートMCPが向く場合

• SaaS提供者が公式MCPを提供している
• OAuthで利用者権限を委譲したい
• クラウドにしかないデータを扱う
• Serverの更新と運用を提供者へ任せたい

PLAUDのように公式リモートMCPがある場合、独自API解析より保守しやすい一方、データがどの地域のサーバーを通るか、保存されるか、ログへ残るかを確認します。

混在構成が現実的

実際の個人AI基盤では、NotionやPLAUDはリモート、Obsidianや専用変換はローカル、と混在します。HostであるHermes Agentが両方のToolを集約します。

Server間が直接つながっているわけではありません。Hostがどの情報をどのToolへ渡すかを管理します。音声全文をNotionへ送る必要がないなら、ローカルで要約してタスク名だけを送る構成にできます。

選定チェック

• データはどこを通るか
• 誰がServerを更新するか
• 認証は失効・更新できるか
• 最小権限にできるか
• 障害時にどこまで止まるか
• ログへ何が残るか
• 代替経路と切断方法があるか

まとめ

ローカルMCPは制御しやすさ、リモートMCPは公式サービスとの保守しやすい接続が強みです。Toolの便利さだけでなく、データ経路と停止方法で選びます。

参考にした一次情報

• [MCP Transports](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports)
• [MCP Architecture](https://modelcontextprotocol.io/specification/2025-11-25/architecture)
• [PLAUD MCP公式ドキュメント](https://docs.plaud.ai/plaud-mcp-cli/mcp)