MCPサーバーのホスティング：MCPサーバーを実際にどこで動かすべきか

「MCPサーバーをホスティングする」ことの真の意味

MCPサーバーとは、単なる一つのプロセスに過ぎません。本質はそれだけです。 Model Context Protocol（MCP） は、クライアントがそのプロセス上のツールをどのように発見し呼び出すかを定義していますが、それがどこに存在し、誰が稼働させ続けるかについては何も規定していません。そのため、これは純粋なインフラストラクチャの問題となり、トランスポート層によってアプローチが分かれます。

Stdioサーバー は、標準入力（stdin）と標準出力（stdout）を介してMCP通信を行います。これらはCLIスタイルのプログラムであり、通常はクライアント自身がnpxやuvxを使って起動します。ポートもURLもネットワークリスナーも存在せず、クライアントが同一マシン上で子プロセスを生成し、パイプを通じて通信します。

HTTP/SSEサーバー は、HTTPエンドポイントを直接公開します。ポートで待機し、既存の他のWebサービスと同様の運用が可能です。

TrueFoundryのドキュメントでも同様の線引きがなされており、重要な結論が示されています。HTTPサーバーは追加のラッパーなしでデプロイできますが、stdioサーバーはstdioをHTTPに変換するためにmcp-proxyでラップする必要があります。また、新規に開発する場合、セキュリティとデプロイの容易さの観点からHTTPベースのサーバーが推奨されると明記されています。

現実的な3つのホスティングオプション

オプション1：ラップトップでのローカルstdio実行

ほぼすべての人がここから始めます。個人利用であればこれで十分です。CursorやClaudeの設定にブロックを貼り付けると、クライアントが必要に応じて npx -y @some/mcp-server を実行し、APIキーは環境変数マップから読み込まれます。

この方法はうまく機能しますが、チームでの運用には適していません。共有可能なURLはなく、認証情報はコピー＆ペーストで配布されます。各開発者が個別に実行するため、インストール環境が異なり、バージョンが乖離する可能性があります。また、呼び出しがネットワーク境界を越えないため、誰がどのツールを呼び出したかを中央で記録することもできません。ローカルのstdioは開発用モードであり、ホスティング戦略とは呼べません。

オプション2：ベンダーのマネージドクラウド

一部のMCPサーバーは開発元によってホストされたエンドポイントとして提供されており、また一部のゲートウェイベンダーはユーザーに代わって自社クラウド上でサーバーを実行しています。URLが提供されるため、インフラ管理の手間を省くことができます。

これは最も迅速な方法であり、公開されている読み取り専用の低機密サーバーであれば、通常はこれが正解です。ただし、プロセスがどこで実行されるかというトレードオフがあります。ホスト型サーバーが社内システムにクエリを投げる場合、ベンダーの出口IP範囲に対してシステムを開放するか、自社で管理していないインフラに認証情報を渡す必要があります。本番データベースを読み取るような用途では、多くの場合、この時点で選択肢から外れることになります。

オプション3：自社インフラでのセルフホスティング

独自のKubernetesクラスター、独自のVPC、独自のネットワークポリシー配下でプロセスを実行します。サーバーが社内システムに触れるようになる段階で、チームが検討すべき選択肢です。

セルフホスティングは、一般的に考えられているほど難しいものではありません。MCPサーバーは小規模なステートレスHTTPサービスであり、プラットフォームチームであれば誰でもその運用方法を心得ています。実際に手間がかかるのは、安定したURLの確保、アクセス権限の管理、イメージに埋め込まない形での認証情報の注入、そして実行ログの記録といった周辺レイヤーの構築です。

ローカル環境から移行する際に変わること

サーバーをラップトップから移行することは、単なる「リフト＆シフト」ではありません。安定したURLの確保以外にも、ラップトップ環境では不要だった4つの要素が必要になります。

バインドアドレス stdioサーバーは何もバインドしませんが、HTTPサーバーはlocalhostではなく0.0.0.0をバインドする必要があります。そうしなければ、コンテナ内では正常に起動しても、クラスターの他の場所からはアクセスできません。ドキュメントにこの警告が記載されているのは、それだけ多くの人がこの問題に直面しているからです。

双方向の認証 ローカル環境では、設定ファイルにある自分のキーという1つの認証情報だけで済みました。しかしリモート環境では、呼び出し元がサーバーに対してどのように身元を証明するか、そしてサーバーが下流のサービスに対してどのように身元を証明するかという、2つの異なる課題にそれぞれ回答する必要があります。

同時実行数とリソース これまでは1つのプロセスが1人のクライアントに対応していましたが、これからはチーム全体をサポートすることになります。そのため、他のサービスと同様に、CPUやメモリのリクエスト、制限値、レプリカ数を設定する必要があります。

エグレス（外部通信） サーバーは、オフィスのWi-Fiに接続されたラップトップからではなく、ネットワーク内部から外部への呼び出しを行うようになります。通常はそれが目的ですが、これによりサーバーのネットワーク上の位置付けは、偶然の結果ではなく、セキュリティ上の意思決定事項となります。

チームがMCPサーバーのホスティングで陥りやすい間違い

開発者全員が依然として個別にコピーを実行している 最も多い失敗は技術的なものではありません。ローカルの設定がそのまま残っているため、チームの半分はゲートウェイURLを使用し、残りの半分は依然として個人のトークンを使ってローカルでnpxを実行しているという状況です。これは中央集権化ではなく、単に経路が2つに分かれているだけです。

環境変数ではなく引数にトークンを含める stdioコマンドをマニフェストに移行する際、CLI実行時に指定していたトークンをそのままインラインで記述したくなる誘惑に駆られます。しかしドキュメントには「引数にトークンを含めてはならない」と明記されています。引数はマニフェスト内にプレーンテキストで保存され、プロセス一覧に表示される可能性があるためです。認証情報は、シークレットストアで管理された環境変数に含めるべきです。

パッケージのバージョンが固定されていない npx -y some-packageは、コンテナ起動時に最新のバージョンを解決するため、1週間ずれて起動した2つのレプリカで異なるツールセットが実行される可能性があります。引数でバージョンを明示的に固定してください。

URLの確保をゴールと見なすこと アクセス制御のないデプロイ済みサーバーは、ネットワーク内の誰でも呼び出せるツールエンドポイントに過ぎません。ホスティングは「到達可能性」を解決しますが、誰がアクセスを許可されるかという、より困難な課題は解決しません。

Skip the plumbing.

Deploy an MCP server on your own cluster and put a governed URL in front of it in one sitting.

Get started free

TrueFoundryでのMCPサーバーホスティングの仕組み

TrueFoundryは、ホスティングとガバナンスを別々のシステムではなく、一つのシステムとして統合すべきだと考えています。サーバーは、他のワークロードと同様のワークスペース、シークレット、オートスケーリング、ログを備えた、お客様のKubernetesクラスター上の通常のサービスとしてデプロイされます。その後、URL、認証、アクセスモデルを管理するMCPゲートウェイの背後に登録されます。開始地点に応じて、3つのルートが用意されています。

ルート1：ソースコードからデプロイ

自作のサーバーや、ビルド可能なリポジトリからデプロイする場合に使用します。

標準的なサービスデプロイの手順は以下の通りです。 Deployments → New Deployment → Serviceを選択し、ワークスペースを指定してから、 Git Repo または Code From Laptop をソースとして選択します。FastMCPで構築されたPython HTTPサーバーでDockerfileがない場合、設定項目はビルドコンテキストパス、requirements.txtのパス、Pythonバージョン、コマンド（python server.py）、およびポート8000となります。

ソースがstdioサーバーの場合は、ラップする必要があります。推奨される方法は、mcp-proxyをインストールし、CMDを mcp-proxy --port 8000 --host 0.0.0.0 --server stream python server.py のように設定したDockerfileを使用することです。Dockerfileを使わない場合は、Pythonビルドオプションを使用し、mcp-proxyを依存関係として宣言した上で、同じコマンドを直接設定してください。

ポート設定はどちらの場合も共通です。ポート8000、プロトコルTCP、アプリプロトコルhttpとし、クラスター内からのみアクセス可能にする場合はexposeをfalseに設定します。機密情報はTrueFoundry Secretsに保存し、tfy-secret://your-workspace:your-secret-group:API_KEY の形式で参照します。

ルート2：npxまたはuvxパッケージからデプロイ

サーバーが公開パッケージとして存在し、変更の必要がない場合に使用します。これは、現在お使いのCursor設定にあるブロックをそのまま移行するようなものです。どちらのバリエーションもDockerイメージからデプロイされ、コマンドによって実行されます。

For npm packagesの場合、ベースイメージはnode:24で、コマンドは以下の通りです。

npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y <package-name>

最初の npx -y mcp-proxy でプロキシをインストールして実行し、2つ目でサーバーパッケージを実行します。例えば Notion サーバーの場合は、npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server となります。

Python パッケージの場合、 Python パッケージベースイメージは public.ecr.aws/docker/library/python:3.11-slim で、コマンドで最初にツールをインストールします：

sh -c "pip install uv mcp-proxy && mcp-proxy --host=0.0.0.0 --port=8000 uvx <package-name>"

python:3.11-slim ベースイメージと、uvx MCP パッケージをラップする mcp-proxy を使用した Docker イメージからのデプロイフォーム

環境変数はローカル設定からそのまま引き継がれます（NOTION_API_KEY、GITHUB_TOKENなど）。機密情報は「Secrets」に移動してください。注意点として、初回起動時は npx や uvx によるパッケージのダウンロードが発生するため時間がかかります。コールドスタートが問題になる場合は、カスタムイメージにあらかじめインストールしておいてください。

ルート3 — ゲートウェイで実行されるホスト型 stdio

3つ目の方法は、サービスデプロイを完全にスキップするものです。ユーザーが stdio サーバーをラップしてデプロイするのではなく、ゲートウェイがプロセスを実行し、リモートサーバーと同じ URL で公開します。 MCP Servers → Add Serverから、 Hosted Stdio-based MCP Serverを選択します：

コマンド commandと、 arguments、および 環境変数、またはエディタ形式のJSON（CursorやVS Codeと同じ単一エントリのmcpServers形式）を貼り付けると、フォームが自動的に入力されます。ファイルシステム参照サーバーの場合、コマンドは「npx」、引数は「-y, @modelcontextprotocol/server-filesystem, /tmp」となります。

ゲートウェイは、ステートレスモードのサンドボックス環境でmcp-proxyライブラリを介してこれを実行し、クライアントはストリーミング可能なHTTP POST経由で接続します。環境変数は以下のように設定可能です。 グローバル （全員がダウンストリームの認証情報を共有）または ユーザーごと（各値には、呼び出し元の認証オーバーライドから解決されるテンプレート化されたプレースホルダーが1つだけ含まれます）。注意点として、ドキュメントではIDEでのローカル開発にこの方法を推奨しています。これはCLIスタイルのサーバーを介して共有・管理されたURLを素早く取得するためのものであり、高負荷な本番環境向けのパターンではありません。

次に、ゲートウェイの背後に登録します

サーバーのデプロイ方法に関わらず、最後のステップは共通です。サービスのエンドポイントURLを取得し、 サーバーを追加 → リモートMCPサーバーに接続に移動して、名前、説明、URL、コラボレーター、認証データを入力します。

ここでインバウンドのアクセス制御を行います。コラボレーターにはユーザーまたはチームを指定し、 MCPサーバーマネージャー （設定権限をすべて付与）または MCPサーバーユーザー （設定を変更せずにツールを呼び出す権限のみ付与）を割り当てます。

アウトバウンド認証（ゲートウェイがデプロイしたサーバーに対して自身を証明する方法）には、APIキー、OAuth2、AWS SigV4、またはトークンパススルーのいずれかを使用します。APIキーは以下に分類されます。 共有認証情報、1つのキーを全員で共有する場合、そして 個別認証情報、ヘッダー値に Bearer {{API_KEY}} のようなプレースホルダーを含め、各ユーザーが「認証オーバーライド（Auth Overrides）」を通じて自身のキーを入力する場合：

自社でホストするサーバーであれば、共有認証情報でも問題ないことがほとんどです。アクセス制御はすでにゲートウェイ側で行われているためです。ユーザーごとのデータを扱う場合は、OAuth2が本番環境での推奨構成となります。スコープの設定が可能で、ユーザー自身が認可を取り消すことができ、アクセス範囲を各ユーザーの許可されたデータのみに制限できるためです。

認可コードおよびクライアント認証情報グラントタイプを使用した、MCPサーバーのOAuth2設定

登録が完了するとツールが表示され、プレイグラウンドから呼び出せるようになります：

実践例：ローカル環境のコピーを廃止する

8人の開発者がそれぞれCursorの設定にNotionのnpxブロックを追加し、個人のNotionキーを使用しているとします。これをホストされた1つのコピーに統合したい場合の手順です。

ステップ1 — デプロイする 「新規デプロイ」→「サービス」→「Dockerイメージからデプロイ」を選択します。ベースイメージは node:24、コマンドは npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server、ポートは 8000、プロトコルは TCP、アプリプロトコルは http とします。パッケージのバージョンは固定してください。NOTION_API_KEY は環境変数フィールドに平文で記述せず、「シークレット」に設定してください。

ステップ2 — 検証する DEPLOY_SUCCESS と表示されるまで待ち、サービスのエンドポイントURLを確認して curl でリクエストを送ります。HTTP経由でMCPプロトコルのメッセージが返ってくるはずです。登録作業の前にこれを行うことで、「コンテナが起動しない」のか「ゲートウェイから到達できない」のかを切り分けることができます。この2つは、トラブルシューティングにかかる時間が大きく異なります。

ステップ3 — 登録する 「サーバーを追加」→「リモートMCPサーバーに接続」を選択し、エンドポイントURLを貼り付けて名前を付けます。エンジニアチームを MCPサーバーユーザー として、自分自身を MCPサーバー管理者として追加し、認証データを設定します。

ステップ4 — ゲートウェイURLを配布する。 使用方法 タブには、Cursor、VS Code、Claude Code、Windsurf、Codex、およびPythonとTypeScriptのSDK向けのテナント固有の接続スニペットが用意されています。さらに、 CursorにMCPを追加 ボタンをクリックすると、開発者用の設定が自動的に書き込まれます。

ステップ5 — ローカルブロックを削除する。 多くのチームが見落としがちですが、これこそが他の4つのステップを価値あるものにする重要な工程です。各ユーザーの設定からnpxのエントリを削除しない限り、サーバーは1つではなく9つも実行されている状態になります。

得られるメリット：サーバーのバージョンの一元管理、8台のノートPCではなくシークレットストアでの認証情報管理、ツールごとの可視化、そして個別に依頼することなく中央からツールをオフにする機能。

Ready to host your first one?

Deploy from a repo, an npx package, or a stdio command, and put it behind a governed URL.

Start free on TrueFoundry

知っておくべき注意点

インストールがスタックすると、サーバーもスタックしたように見えます。 ホストされたstdioサーバーの場合、パッケージのインストールに失敗してもエラーとして表示されません。パッケージマネージャーからMCPプロセスへの引き渡しが行われないため、サーバーはmcp_server_startingの状態で停止したままになります。主な原因は、固定されていないgit URL、npmパッケージURLに埋め込まれた認証情報（npmによって正規化され削除されます）、または初回実行が強制終了された後にnpxキャッシュが破損したことなどが挙げられます。引数を変更するとサンドボックスが再生成され、クリーンな状態で開始されます。

レスポンスストリーム外の通知は破棄されます。 ゲートウェイはstdioサーバーをステートレスモードで実行するため、リクエストのレスポンスストリーム外でサーバーから送信される独立した通知は配信されません。プッシュ型のメッセージを送信するサーバーを移行する前に、プロトコルのサポートマトリックスを確認してください。

バインドアドレスの設定には落とし穴があります。 localhostにバインドすると、コンテナは起動してヘルスチェックには合格しますが、クラスターからは見えない状態になります。ドキュメント内のすべてのstdioラップコマンドに --host 0.0.0.0 が含まれているのは、まさにこの理由によるものです。

npx/uvxではコールドスタートが発生します。 コンテナ起動時にパッケージがダウンロードされるため、開発用サーバーであれば問題ありませんが、レイテンシに敏感な用途ではストレスになる可能性があります。

関連資料

• MCPゲートウェイとは — ホスティング環境の前面に配置するレイヤー
• Slack MCPサーバー — サードパーティ製サーバーとその管理方法
• Datadog MCPサーバー — 可観測性ツールに適用されるパターン
• Snowflake MCPサーバー — プライベートデータを取り扱うため、セルフホスティングが標準となるケース
• 仮想MCPサーバーの解説 — 複数のホスト型サーバーのツールを1つのエンドポイントに統合する

結論

MCPサーバーのホスティングは、決して特殊な課題ではありません。ラップトップ上で動作するプロセスを、チームが信頼できるサービスへと昇華させるという、馴染み深い作業です。つまり、URLの発行、ID管理、リソース制限、シークレット管理、そして実行ログの記録といったプロセスを整えることです。

これを慎重に行うべき理由は、MCPサーバーがツールエンドポイントであるためです。アクセス制御のない接続性は、成果ではなくリスクでしかありません。Kubernetes上にデプロイし、同一プラットフォーム内のゲートウェイ経由で登録することで、これら二つの側面を一つのタスクに集約できます。ネットワークポリシーが適用された環境でプロセスを実行し、その前面にあるURLが呼び出し元を識別できるようになるからです。

Deploy and govern your first MCP server on TrueFoundry

Free to start