MCPサーバーをホストするのに専用IPは必要ですか？

公開のHTTPSエンドポイントには、はい。NATプランは単一のSSHポートを転送し、ポート443をインターネットに晒しません。専用IPプランは、すべてのポートと、箱に直接向けられるドメインを与えます。

stdioとHTTP — どちらのトランスポートをホストしますか？

HTTP（SSEまたは新しいstreamable-HTTP）。stdioサーバーは同じマシン上のクライアントとしか話しません；ネットワーク越しに到達させたいものはURLの後ろでHTTPを話す必要があります。

一つのVPSで複数のMCPサーバーを動かせますか？

はい。各サーバーを別のローカルポートにバインドし、リバースプロキシで各々に独自のサブドメインを与えます。RAMが実際的な限界で、ツールサーバーはそれをごくわずかしか使いません。

MCPサーバーにどれくらいのRAMが要りますか？

たいてい少ない。ツールサーバーはI/Oバウンド — 数字を挽くのではなくAPIやデータベースを待つので、1〜2 GBで大半をこなします。答えを生成するためにモデルを動かすのは、別の、はるかに重い仕事です。

自分のMCPサーバーをVPSでホストする

あなたはMCPサーバーを書きました。ローカルでは問題なく動きます — エージェントが呼び、ツールが発火し、すべて配線済み。それからノートPCを閉じると、消えます。そのサーバーを、エージェントが必要とするときはいつでも到達できるようにしたいなら — 別のマシンから、チームメイトの構成から、午前3時のスケジュールジョブから — 安定したアドレスとHTTPSを備えた、常に稼働している場所に住む必要があります。それがVPSの用途です。

MCPサーバーをノートPCから外し、あなたが実際に制御する箱へ移す方法を、労力がどこに行くかの正直なメモとともに記します。

ローカル対リモート：「ホスティング」が実際に意味すること

MCPサーバーは二つの形で来ます。

stdio サーバーはローカルプロセスとして動き、同じマシン上のクライアントと標準入出力で話します。作っている間は完璧ですが — ネットワーク越しに何かから到達することはできません。

リモート サーバーはURL上でHTTP（Server-Sent Events、または新しいstreamable-HTTPトランスポート）を話します。URLを知り正しい資格情報を持つクライアントならどれでも呼べます。自分のMCPサーバーをホストするとは、リモート型をどこか公開かつ安定した場所で動かすことです。

なぜノートPCをトンネルするだけではだめか

技術的には家庭のマシンをトンネルで晒せますし、手早いデモにはそれで問題ありません。頼るものには、マシンの問題を引き継ぎます：スリープし、ISPがIPを回し、アップロードが遅く、そして今や実際のツールで一杯のサービスが、他のすべての隣で家庭ネットワークに座っています。VPSは固定の公開IP、実際のドメイン、適切な稼働時間、分離を与えます。月に数ドルで、「なぜエージェントが接続を失ったのか」という問いのカテゴリ全体を消し去ります。

スタック、具体的に

小さな箱を選ぶ。 MCPツールサーバーは大半I/O — API、ファイル、データベースを待ち、重い計算はしません。大半には1〜2 GBのRAMで十分。（答えるためにモデルをインラインで動かすのは別の話 — OllamaでLLMを自ホストを参照。）

サーバーをlocalhostにバインドして動かす、たとえばNodeやPythonが 127.0.0.1:3100 で待ち受ける。公開インターフェイスから直接離しておく — プロキシがそれを扱います。

リバースプロキシを前に置く ことで、あなたのドメインでTLSを終端します。Caddyはそれを約4行で行い、無料の証明書を自動で取得します：

mcp.yourdomain.com {
    reverse_proxy 127.0.0.1:3100
}

mcp.yourdomain.com をVPSのIPに向け、Caddyをリロードすれば、サーバーはstreamable-HTTPで https://mcp.yourdomain.com で稼働します。

常時稼働に保つ

最初のクラッシュや再起動で死ぬサーバーは「ホストされて」いません — 「今のところ動いている」だけです。systemdユニットで包み、クラッシュで再起動し、再起動後に戻るようにします：

[Unit]
Description=My MCP server
After=network.target

[Service]
ExecStart=/usr/bin/node /opt/mcp/server.js
Restart=always
RestartSec=2

[Install]
WantedBy=multi-user.target

systemctl enable --now my-mcp、これで本当に常時稼働です。（同じパターンがどのエージェントやボットも24時間365日生かします。）

人々が見落とす部分：到達可能なポートが要る

公開のMCPエンドポイントには、インターネットから到達できるインバウンドポート — 443 — が要ります。NATプランでは、SSH用に転送されたポートがちょうど一つ得られ、それ以外はありません；443を世界に開くことはできません。公開のHTTPS MCPサーバーをホストするには、すべてのポートがあなたのもので、ドメインを箱に直接向けられる専用IPプランが欲しくなります。それが「同じノートPC上の私のエージェントが到達できる」と「どこの誰のクライアントでも到達できる」の違いです。

締める — これは権限を持つAPIだ

MCPサーバーはたいてい、何かをするツールを公開します：ファイルを読む、有料APIに当たる、お金を動かす。それを裸で開いたインターネットに置かないこと。

すべての呼び出しにトークンを要求。 匿名リクエストを拒否；ツールが走る前にbearerトークンかAPIキーを確認。
443とSSHポート以外すべてをファイアウォール。
鍵のみのSSH、パスワードログインなし。 （10分のチェックリストはこちら。）

エンドポイントを、それがそうであるもの — 実際の権限を持つAPI — として扱えば、リスクの大半は消えます。

正直な限界

今やオペレーションはあなたのもの。 OSの更新、プロセスの健康維持、ログの監視。Caddyが証明書を更新しますが、残りはあなたのものです。マネージドのクラウド関数はこれを隠します；VPSは制御とはるかに低い請求と引き換えにあなたに渡します。
MCP仕様はまだ動いています。 トランスポートと認証パターンはリリースごとに変わります。SDKのバージョンを固定し、ときどき更新するつもりで。
CPUの箱はツールサーバーには適切で、ローカルモデルで答えを生成するのには不適。サーバーが応答のためにLLMを動かすなら、それは別の重いマシンです — Ollamaガイドを参照。
破壊的なツールを認証と確認ステップなしに決して晒さない。 物を消す開いたツールは、いずれすべてをスキャンするボットに出会います。

支払い

メールでサインアップし、USDCまたはUSDTで支払います — カードもIDもなし。そしてこれをエージェントのために配線しているなら、同じ種類の箱を私たち自身のMCPサーバー経由でプログラム的に注文し支払えます — エージェントが登録し、残高を入れ、自分で注文します。

サーバーを一度ホストすれば、エージェントが手を伸ばすときにはいつでもツールがそこにあります。

既製の構成： MCPサーバー向けVPS を参照 — 推奨プランと1分の暗号デプロイ。