手元で動くMCP〜ローカルで閉じた環境で固められるのか｜MCP 第3回

2026年8月14日

手元のパソコンでAIを動かしているのは、速いからでも安いからでもなく、自分のデータを外に出したくないからという面が大きいと思っています。せっかくローカルで動かしているのに、拡張機能のほうが外部のサーバへ全部送っていたら、意味が薄れてしまいます。

MCP（Model Context Protocol）のサーバには、手元で動くものと、他人のサーバで動くものの2種類があります。見た目の使い勝手はほとんど変わらないのに、中で起きていることはまるで違います。

手元だけで閉じた環境は、いまのMCPで本当に固められるのでしょうか。どちらの型がどれくらいあるのかを、公式の登録所から2,500件ぶん取得して数えてみました。

2026年7月時点の内容です。MCPの仕様は、最新の 2026年7月28日版（2026-07-28）を参照しています。

目的：見た目が同じ2つを、数字で見分けられるようにする

MCPサーバを追加するとき、設定に書くのは数行です。手元で動くものも外部で動くものも、書き方の手間はほとんど変わりません。だからこそ、意識しないまま外部へつないでいることが起こりえます。

この回でやりたいのは2つです。ひとつは両者の違いを整理すること。もうひとつはいまの比率を実際に数えることです。感覚ではなく数字にしておけば、次に選ぶときの判断が変わります。

2つの型は、どこが違うのか

呼び方は資料によって揺れますが、中身は「どこでプログラムが動くか」の違いです。

用語としては、ローカル型が stdio（標準入出力）、リモート型が streamable-http や sse と表記されます。設定ファイルにこの単語が出てきたら、どちらの型かを見分ける手がかりです。

なお sse は古い方式で、2026年7月28日版の仕様で正式に「非推奨」に分類されました。設定にこの単語を見つけたら、そのサーバは新しい方式へ移っていない、と読めます。

実験内容：公式レジストリから2,500件を取得して分類する

MCPの公式登録所は、誰でも取得できる形でデータを公開しています。ここから100件ずつ、25回に分けて合計2,500件を取得しました。

分類の基準は単純です。登録データには「配布物（packages）」と「接続先（remotes）」という項目があり、前者があれば手元に入れて動かす型、後者があれば外部につなぐ型です。両方持っているものもあります。

登録順に先頭から取得しているため、全件を代表しているとは限りません。あくまで2,500件ぶんの傾向として見てください。

結果：7割がリモート型だった

数えてみて、正直なところ意外でした。手元で動かすものが主流だと思い込んでいたのですが、実際は逆です。

配布方法と通信方式の内訳も取れました。

考察：なぜリモート型が増えたのか

公開する側の立場で考えると、理由はいくつか思い当たります。

まず、利用者に何もインストールさせずに済みます。ローカル型は利用者側で Node.js や Python の環境を整える必要があり、そこで脱落する人が出ます。リモート型なら接続先を書くだけです。

次に、提供側が中身を差し替えられます。不具合の修正も機能追加も、利用者に更新してもらう必要がありません。

そして、事業として提供するなら、利用状況が手元で分かるほうが都合がよいはずです。実際、取得したデータの中には、既存のサービスがそのまま接続口を用意したものが多く見られました。

通信方式で streamable-http が 2,080 に対し sse が 96 だったのも、この流れを裏づけています。そしてこの読みは、あとから仕様の側で裏が取れました。

数えた数字の意味が、直前の仕様改訂で変わりました

集計した数字を眺めていて気づいたのですが、データを取る前日にあたる2026年7月28日、MCPの仕様が大きく改訂されていました。この改訂は、上の 71.4% という数字の読み方を変えるものでした。

変わったのは、つなぎっぱなしを前提にしなくなったことです。これまでリモート型のサーバは、つないだ相手を Mcp-Session-Id という札で覚えておく必要がありました。今回この札と、最初の挨拶（initialize）が廃止され、1通ごとに必要事項を書いて出す形になりました。

これが何を意味するか。相手を覚えておく必要がなくなると、サーバは常時起動しておかなくてよくなります。依頼が来たときだけ立ち上がって、返したら消えてよい作りにできます。いわゆるサーバーレスやエッジと呼ばれる、安く薄く置ける場所に載せられるということです。

ひとつ補っておきます。この改訂は「1回のやりとりで全部終わる」と紹介されることがありますが、実際にはそこまで単純ではありません。通知を受け取るための長く維持する通信も、複数回のやりとりを前提とした仕組みも、仕様の中に残っています。覚えておく内容そのものが消えたわけでもなく、サーバが発行した札を依頼文の中に書いて渡す形へ移っただけです。やりとりが無くなったのではなく、置き場所が移ったと捉えるのが正確なところです。

また、切断への強さが上がったわけでもありません。途中で切れた通信を再開する仕組みは、この改訂で削除されました。切れた場合は処理中の依頼が失われ、番号を変えてもう一度出し直す決まりです。つなぎ直しの回数は減っても、切れたときの扱いは厳しくなった形です。

ローカルで動かしたい人は、何を見ればよいのか

7割がリモート型ということは、何も考えずに選ぶと外部につながる確率が高いということでもあります。手元で完結させたい場合は、意識して選ぶ必要があります。

見分け方は、設定に書く内容です。コマンドを起動する形（command が書かれている）ならローカル型、URLを指定する形ならリモート型です。前者は npm か PyPI から取得するものが大半でした。

手元のLLMと組み合わせる場合の話

ローカルLLMとローカル型のMCPサーバを組み合わせれば、理屈のうえでは何も外に出ない構成が組めます。実際に試してみると、動くには動くものの、道具の呼び出しをうまく扱えるかはモデル次第でした。

手元の環境では、道具を渡す数を絞ったほうが安定する傾向がありました。10個渡すより3個に絞るほうが、意図した道具を選んでくれます。このあたりは、モデルごとの差も含めてあらためて実測してみたいところです。

ここで、7月28日の改訂による変更をひとつ挙げておきます。サンプリング（Sampling）という仕組みが非推奨になりました。これはMCPサーバの側から「あなたのAIを少し貸してください」と頼めるもので、手元のモデルをサーバに使わせる道でした。公式に示された移行先は「LLMの提供元のAPIに直接つないでください」というものです。

手元で完結させたい立場からすると、惜しい変更です。とはいえ手元のLLMは localhost のAPIとして呼べるので、サーバ側から直接そのAPIを叩く形に書き換えれば、外に出さない構成は維持できます。手間が増えるという話で、道が閉じたわけではありません。非推奨になった機能は最低12か月残ると定められているため、慌てて作り替える必要もなさそうです。

まとめ：便利さと引き換えに、どこへ渡すかを選んでいる

• 公式レジストリの2,500件を数えたところ、リモート型のみが 71.4%、ローカル型のみが 15.3%、両対応が 12.0% だった
• リモート型が多いのは、利用者に入れさせなくて済み、提供側が中身を差し替えられるためと考えられる
• ローカル型の配布は npm 565 / PyPI 269 が中心。リモート型の通信は streamable-http が 2,080 で主流
• 手元で完結させたい場合は、意識して選ばないと外部につながる。設定にURLが出てきたらリモート型
• ローカル型でも中で外部を呼んでいれば外に出る。「手元で動く」と「外に出ない」は別の話
• データ取得の前日（2026年7月28日）に仕様が改訂され、つなぎっぱなしをやめた。常時起動が不要になり、リモート型には追い風。7割という比率は広がるほうに見込みがある
• 古い通信方式（sse）は非推奨に分類された。今回の集計では 96 件が該当
• サンプリングも非推奨になった。手元のモデルをサーバに貸す道は細くなったが、localhost のAPIを直接叩けば閉じた構成は維持できる

この3回で、MCPが何なのか、どれくらいあるのか、どちらの型を選ぶことになるのかまでを見てきました。手元で動かすことにこだわるなら、選ぶ段階から気にしておくと後で困りません。

検証に使用した機材

データの取得と、手元のLLMとの組み合わせの確認に使った機材です。

GMKtec EVO-X2 (Ryzen AI Max+ 395 / 128GB / 2TB)

¥583,999 Amazon・2026-07-24調べ¥724,586 楽天市場・2026-08-14調べ

公式サイトのみ ¥5,000引きクーポン配布中　クーポンコード A82608（2026-10-31まで）

Amazon楽天市場Yahoo!公式サイト

参考にしたサイト

確認日 2026年7月30日（データ取得は7月29日）。仕様の参照版は 2026-07-28（現行）。登録件数と比率は日々変動します。