開発者ガイドでは、Model Context Protocol (MCP) サーバーをワークステーション上で実行する場合と、共有HTTPサービスとしてホストする場合のトレードオフについて説明しています。著者は、この選択がレイテンシ、認証情報の露出、およびチームがいかに容易にAI駆動のデータアクセスレイヤーをスケールできるかを決定づけると主張しています。
なぜこの決定が重要なのか
MCPは、ClaudeやCursorのような大規模言語モデル（LLM）アシスタントが、パスワードを一切知ることなくデータベースに対してSQLを発行できるようにするための架け橋です。アシスタントがツールを呼び出し、そのツールがリクエストをMCPサーバーに転送し、サーバーがクエリを実行します。サーバーが開発者のノートPC上にある場合、ラウンドトリップは実質的にローカルの関数呼び出しとなります。一方、中央のホスト上で動作している場合、すべてのリクエストはネットワークを経由し、ホストの認証およびロギングメカニズムの対象となります。単独の開発者によるプロトタイプから本番環境へと移行するチームは、自社のセキュリティ体制、パフォーマンスへの期待、および運用オーバーヘッドにどのモデルが適合するかを決定しなければなりません。
2つのデプロイモデル
ローカル (stdio)
クライアントはMCPサーバーを子プロセスとして起動し、標準入出力（stdio）を介して通信します。ネットワークスタックは介在しません。
- 向け: 個々の開発者、迅速な実験、およびローカル専用のテストデータベース。
- 利点: レイテンシは実質的にゼロです。プロセスがユーザーの環境を継承するため、パスワードがマシンから外部に出ることはありません。
- 欠点: 各ユーザーが独自の構成ファイルや環境変数を維持する必要があります。中央の監査証跡がありません。複数ユーザーへのスケールには、すべてのワークステーションでセットアップを複製する必要があります。
リモート (HTTP)
サーバーは、HTTP経由でアクセス可能なホスト上で継続的に動作します。クライアントは通常、OAuthスタイルのフローで認証を行い、既知のエンドポイントにリクエストを送信します。
- 向け: チーム、CIパイプライン、および複数のユーザーやサービスからアクセスする必要がある本番データ。
- 利点: 監査ログ、ロールベースのアクセス制御（RBAC）、およびコネクションプーリングのための単一の接点となります。認証情報は、管理されたヴォルト（保管庫）に一度だけ保存されます。
- 欠点: プロビジョニングと維持のための追加インフラが必要です。ネットワークレイテンシにより、ラウンドトリップごとに数ミリ秒が加算されます。
直接比較
| 項目 | ローカル | リモート |
|---|---|---|
| 想定される用途 | 単一ユーザー | 複数ユーザー |
| 認証 | 環境変数またはローカル構成 | OAuth互換のトークンフロー |
| 監査 | 標準機能なし | 中央ログですべてのリクエストを記録 |
| セットアップの複雑さ | 最小限 | サーバーのプロビジョニング、TLS、トークン管理が必要 |
| レイテンシ | ほぼゼロ | ネットワークホップにより高い |
| 認証情報の露出 | 開発者のマシン内に限定 | 中央集約されるが、侵害から保護する必要がある |
実用的なハイブリッドアプローチ
ほとんどの組織は、一つのモデルを選んで永遠に使い続けるわけではありません。本ガイドでは、段階的な展開を推奨しています。
- ローカルで開発する – サンドボックスデータベースに対してローカルのMCPサーバーを立ち上げます。スピードにより迅速なイテレーションが可能になり、機密情報をバージョン管理から遠ざけることができます。
- リモートへ移行する – コードベースが共有されたら、サーバーを中央のホストに移動します。クライアント構成をHTTPエンドポイントに向くように切り替え、OAuthを有効にします。
- 本番環境を保護する – 本番データベースは、監査可能なリモートゲートウェイの背後に配置します。AIアシスタントには読み取り専用のロールを強制し、本番用のパスワードはリモートサーバーがアクセスできるシークレットマネージャーにのみ保存します。
避けるべき一般的な落とし穴
- 本番用のパスワードを開発者の
.envファイルやその他のローカル構成に保存すること。マシンが侵害された場合、データベースが露出してしまいます。 - OAuthまたは同等のトークンシステムなしでリモートMCPサーバーをデプロイすること。プレーンテキストの基本認証（Basic Auth）や静的なAPIキーは漏洩しやすいです。
- AIアシスタントに本番テーブルへの書き込み権限を付与すること。偶発的な
DELETE文でもデータ損失を引き起こす可能性があります。読み取り専用ロールにすることで、そのリスクを排除できます。
ローカルが依然として理にかなう場合
チームのワークフローが単一のマシンから離れない場合（例：個人のノートPCでプロトタイプを作成している単独のデータサイエンティストなど）、ローカルデプロイは引き続き最もシンプルで高速な選択肢となります。短期間の実験であれば、TLS証明書、トークンの発行、およびロギングパイプラインのセットアップにかかるオーバーヘッドは正当化されないかもしれません。
結論
純粋なスピードを求め、かつユーザーが自分一人だけであれば、ローカルのMCPサーバーが最も手軽な選択肢です。監査可能性、共有アクセス、または本番環境レベルのセキュリティが必要な場合は、リモートHTTPサーバーが唯一の現実的な手段となります。ほとんどのチームは、利便性のためにまずはローカルから開始し、本番データを取り扱う前に、トークンで保護されたリモートゲートウェイへと移行していきます。デプロイモデルは、プロジェクトの段階と、公開するデータのリスクプロファイルに合わせて選択してください。