ローカルで動いているMCPツールをチームにも使わせたいのに、どの接続方式にすべきか決められない状態ですか。
共有や一元管理が目的ならStreamable HTTP、端末内の開発環境と連携するならstdioを選びます。2026年7月28日版の無状態化はプロトコル層の変更であり、業務データや認可の管理を不要にする変更ではありません。
個人開発者は、ローカル接続を維持するか遠隔サーバーへ移すかを判断できます。
小規模チームは、複数のクライアントでツールを共有する構成を検討できます。
技術責任者は、プロトコル更新と既存クライアントの互換性、業務状態の管理範囲を整理できます。
最終更新：2026年10月25日。プロトコルの変更はMCP公式の2026年7月28日版リリース情報、接続方式と現在の互換資料は公式トランスポート仕様およびSDKの移行サポート資料で確認しています。
まず接続先でstdioとStreamable HTTPを選び分ける
「MCPサーバーを立てる」こと自体を目的にせず、ツールをどこで実行し、誰が利用するのかを先に決めます。個人の端末にあるファイルや開発環境へアクセスさせる場合は、ローカルの子プロセスとして起動するstdioが適しています。一方、複数の利用者が同一のツールを使うなら、サーバー側で運用するStreamable HTTPが候補になります。
| 選択肢 | 向いている場面 | 先に確認する点 |
|---|---|---|
| stdio | ローカルファイルや開発環境との連携、個人利用 | クライアント端末でプロセスを起動できるか、必要な環境や権限が端末ごとにそろうか |
| Streamable HTTP | 複数クライアントでの共有、サーバー側での一元管理 | 認証、接続元の制限、サービスの稼働監視、障害時の復旧方法を決めているか |
stdioを選ぶと、ツールの実行環境や設定を利用者の端末ごとに管理することになります。チーム共有が必要になった段階で、環境差や更新漏れが運用負担になっていないかを確認してください。
Streamable HTTPは遠隔接続の方式ですが、誰でもアクセスできる形でインターネットに公開することを意味しません。接続元や認証の条件を決め、必要な利用者だけが到達できる運用経路を選びます。方式の違いは公式TypeScript SDKのHTTPサーバー文書でも確認できます。
新版の無状態化で変わるのはプロトコル層です
2026年7月28日版の仕様では、プロトコル層のinitialize／initializedハンドシェイクとMcp-Session-Idによるセッション管理がなくなりました。詳細は同版のトランスポート仕様に記載されています。これはリクエストを扱うプロトコルの変更であり、サーバー上の業務処理が自動的に無状態になるという意味ではありません。
たとえば、ツールが利用者ごとの認可情報を参照するなら、その認証・認可の仕組みは引き続き必要です。処理が長時間に及ぶ、書き込みを伴う、あるいは失敗後に再開する必要がある場合も、進行状況や結果をアプリケーション側で保存し、再試行時の重複実行を防ぐ設計が必要です。
無状態化だけを理由に、性能向上や多重化の効果を見込んで構成を変えるのは避けてください。実際の処理時間や同時利用の上限は、ツールの内容、データベース、認証処理、サーバー資源などに左右されます。プロトコルの変更からリクエスト量や処理速度を推定することはできません。
移行前に旧クライアントとの組み合わせを照合する
旧クライアントが新版サーバーへそのまま接続できるかは、クライアント、SDK、サーバーの対応状況を組み合わせて判断します。プロトコル仕様だけから、すべての既存環境の互換性を断定しないでください。
公式TypeScript SDKの移行サポート資料と、使用中のSDKに対応するHTTPサーバー文書を照合し、現在の実装や例を確認します。バージョンやサンプルコードは更新されるため、公開時点の公式資料を基準にしてください。
まず検証環境で移行を確かめる手順
本番を一度に切り替えるのではなく、利用するクライアントと代表的なツールを絞って確認します。次の項目を順に進めれば、プロトコルの互換問題とアプリケーション側の状態管理漏れを分けて調べられます。
- [ ] 利用中のクライアント、SDK、サーバーのバージョンと対応するプロトコルを記録します。公式の仕様・SDK文書に差がある場合は、実装側の互換資料も確認します。
- [ ] 移行後に必要となる接続方式を決めます。端末内の環境が必要ならstdioを維持し、共有やサーバー側での集中管理が必要なサービスだけをStreamable HTTPへ移します。
- [ ] 検証用クライアントから接続し、ツールの一覧取得、代表的な読み取り処理、エラー時の応答を確認します。旧クライアントを残す場合は、従来の握手やセッションに依存する動作も個別に試します。
- [ ] 書き込みや長時間処理を実行し、タイムアウト後の再試行で重複実行されないか、処理状態や結果を復元できるか確認します。
- [ ] サーバーログに接続失敗、認証エラー、ツール実行エラーが記録されることを確かめ、障害時に誰が何を調査するかを決めます。
- [ ] 問題がなければ利用者やツールを限定して切り替えます。旧構成と設定を残し、接続失敗や業務処理の不整合があれば元へ戻せる状態を保ちます。
FAQ：接続方式と新版への移行
チーム用サーバーは必ず公開インターネットに置く必要がありますか？
必要ありません。Streamable HTTPはリモート接続に使う方式ですが、到達可能範囲をどう設定するかは別の設計判断です。利用者の認証と接続経路を決め、対象のクライアントだけが使える形で運用してください。公開範囲を広げる前に、ログ確認と障害時の対応手順も用意します。
新版ならリクエストごとの状態保存はすべて不要ですか？
不要になるのは仕様で定めるプロトコル層のセッション機構であり、ツールが扱う状態ではありません。認可、業務データ、長時間処理の進行状況、再試行時の重複防止はアプリケーション側で管理します。どの状態を保存するかは、ツールの処理内容と復旧要件に応じて定めてください。
個人利用のstdioを新版に合わせて遠隔方式へ移すべきですか？
複数の利用者と共有する必要がなく、端末内のファイルや開発環境に接続しているなら、stdioを使い続ける判断ができます。新しい仕様になったことだけを移行理由にする必要はありません。共有、集中管理、端末ごとの設定負担のいずれかが課題になった時点で、遠隔方式の利点と運用作業を比較してください。
旧クライアントの互換性はどのように確認しますか？
使用しているクライアントとSDKの対応プロトコルを確認し、新版サーバーとの組み合わせを検証環境で試します。特に、旧方式の初期化やセッション動作に依存する処理、エラー時の再接続を確認してください。互換性を公式資料だけで判断できない場合は、本番切り替えを保留し、旧設定へ戻せる状態を維持します。
サーバーへ移す前に利用者数と運用負担を整理する
自分だけが使い、ローカル環境へのアクセスが必要なツールなら、個人端末でのstdio運用が適しています。チームで共用する、利用者ごとの環境差を減らしたい、複数のコンテナと一緒に継続運用したい場合は、サーバーへ集約する価値があります。ただし、共有化すると認証、ログ確認、更新、障害対応もサーバー運用側の仕事になります。
特に業務データを扱う場合は、保存先とアクセス権限、バックアップ方法、復旧時に必要な情報を導入前に決めます。遠隔サーバーを使うことだけで、データの取り扱いや保護が自動的に解決するわけではありません。サーバーへの接続方法を整理する際は、SSH接続の案内とデータの取り扱いに関する案内も確認してください。
共有用MCPサービスを継続運用し、他のコンテナと同じ環境で管理するなら、共有型VPSではCPU資源の共有状況やストレージ、構成上の制限が運用条件に影響する場合があります。実行環境を自分で管理したい場合は、独占利用のAMD物理サーバーも比較対象になります。ただし、個人の軽い利用や一時的な検証だけなら、ローカル実行や小さな共有環境のほうが手間に見合うことがあります。
MCPサーバーのプロセス数だけで必要な構成を決めず、同時に動かすコンテナ、データの保存先、ログ量、復旧要件を先に整理してください。その条件をもとにOVN Cloudのサーバー構成を確認し、実際の負荷に合う選択肢があるか照合できます。2026年のMCPサーバーのセルフホスト構築では、まず接続方式と状態管理を決め、その後で独占サーバーが必要か判断する順序が安全です。
よくある質問
- チームで共用するMCPサーバーはどの方式で公開すればよいですか？ 複数の利用者やアプリケーションが同じツールを使うなら、サーバー側で運用するStreamable HTTPを候補にします。利用者ごとの認証、接続元の制限、ログの扱いを決めてから接続経路を設計してください。リモート方式を選んでも、誰でも到達できる公開サーバーにする必要はありません。
- 新版ではプロトコルのセッションを保存しなくてもよいのでしょうか？ 2026年7月28日版の変更でなくなるのは、プロトコル層の初期化ハンドシェイクとセッションIDの仕組みです。ツールが扱う認可情報、業務データ、長時間処理の進行状況まで不要になるわけではありません。再試行や障害復旧が必要な処理は、アプリケーション側で状態を保存する設計にしてください。
- ローカル接続とStreamable HTTPはどう使い分けますか？ 利用者の端末にあるファイルや開発環境へ直接アクセスするなら、クライアントがローカルで子プロセスを起動するstdioが適しています。同じツールを複数の利用者やアプリケーションから使い、サーバー側で一元管理したい場合はStreamable HTTPを検討します。移行は共有の必要性がある場合に限って進められます。
- 以前のMCPクライアントから新版のサーバーへ接続できますか？ 一律に接続できるとは判断できません。クライアント、SDK、サーバーそれぞれの対応プロトコルと実装状況を公式の互換資料で照合し、旧方式の握手やセッション動作が必要か確認してください。まず検証用クライアントで接続とエラー処理を試し、問題がない場合に限って本番へ段階的に切り替えます。