ローカル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)