ハクソク

世界を動かす技術を、日本語で。

MCPが世界を飲み込んでいる

338日前原文(stainless.com)

概要

Model Context Protocol (MCP) は、過去の試みに比べて革新的ではないが、 シンプルかつタイムリー に登場し、実用性が高いプロトコル。 モデル・プロトコル・ツール の三要素が「十分に良い」水準に達したことで、MCPの普及が急速に進行。 ベンダーニュートラル な設計と高い開発者体験により、ツール開発・運用の障壁が低減。 主要なモデルプロバイダーやエコシステムがMCPを採用し、 モメンタムの好循環 が形成。 今後も MCPの定着と発展 が期待される状況。

Model Context Protocol (MCP)は「十分に良い」から普及した理由

  • MCPは魔法ではなく、革命的でもない が、 シンプル で タイミングが良く、 実装も丁寧 なプロトコル。
  • Stainless社は MCPの将来性 に賭けている立場。
  • MCPはLLM上でエージェントや複雑なワークフローを構築 するのを支援するプロトコル。
  • 過去にもLLMと世界を繋ぐ自動化の試み が多数存在。
    • Function/tool calling： JSONスキーマ記述と関数選択 だが、毎回手動接続とリトライ実装の負担。
    • ReAct / LangChain： Action: string をモデルが出力し、自前でパースが必要でデバッグ困難。
    • ChatGPT plugins： OpenAPIサーバーのホスティングと承認が必須 で敷居が高い。
    • Custom GPTs： エントリー障壁は低い が、OpenAIランタイム依存。
    • AutoGPT, BabyAGI： 設定やループ、エラー連鎖が複雑 な野心的エージェント。
  • MCP自体も新しいわけではなく、Anthropicが2023年11月に仕様公開し、2024年2月に話題化。

なぜMCPは普及し、過去の試みは失敗したのか

  • モデルが十分に高性能になった

    • 以前は 信頼性が低く、エラー処理が必須 だったため、ツール利用が煩雑。
    • エージェント運用ではロバスト性が極めて重要 で、文脈汚染やエラー連鎖のリスクが高かった。
    • 新世代モデルは失敗から回復しやすくなり、統合コストが激減。
    • MCPは モデル性能の閾値突破のタイミングで登場 し、普及を後押し。

  • プロトコルが十分に優れている

    • 以前のツール連携は 特定スタック依存 で相互運用性が低かった。
      • OpenAIのfunction callingは OpenAI API限定。
      • ChatGPT pluginsは 独自ランタイム必須。
      • LangChainは プロンプトループ依存。
    • 各プラットフォームごとに個別対応が必要 で、JSON Schemaの方言やリトライ処理も異なる。
    • MCPは ベンダーニュートラルな共通プロトコル を提供し、 一度ツール定義すればどのエージェントからも利用可能。
    • 認証標準の未整備や互換性課題は残る が、 プロトコル設計の「適切な抽象度」 が開発効率を大幅向上。

  • ツール類が十分に整備されている

    • MCPの SDKは多言語対応 で、統合が容易。
    • 例： Python SDK
      • デコレータでツール定義
      • MCPサーバーの簡単起動
      • MCPクライアントでサーバー連携
    • ツール開発・共有の障壁が低く、CLI・IDE・Webサービス等で再利用可能。
    • 説明文の工夫や文脈管理は依然重要 だが、 初期導入の速さが魅力。
    • 開発者体験（Developer Ergonomics）の重要性 を示す好例。

  • モメンタムが十分に強い

    • クライアント側のMCP対応が急速に進行
      • OpenAIのagents SDK、Google Deepmindなど主要モデルプロバイダーが採用。
      • Cursor, Cline, Zedなど多数のエージェント統合。
    • サーバー側もAPI-first企業がMCPツール公開を競う状況。
      • サードパーティサーバーもギャップを補完。
    • エコシステムの拡大
      • レジストリ（awesome-mcp-servers, smithery.ai, postman, glama.ai）
      • サービス（Cloudflare, Vercel）
      • チュートリアルやコース、イベント等
    • Anthropicの積極的なエコシステム推進 により、良質なドキュメントやイベントが普及を後押し。
    • ツール・エージェントの好循環 がコミュニティ全体の加速を生む。

今後の展望と結論

  • MCPは一過性の流行で終わらない可能性が高い。
    • 「十分に良い」設計と実装 が、過去の技術と一線を画す。
    • API-first企業もMCPサーバーをコア技術として認識。
    • Stainless社としてもMCPの将来性に賭けている。
    • 今後、基盤モデル自体がMCPの利用パターンで学習し、さらなる進化が期待。

MCPは十分に良いプロトコルであり、今後も定着・発展する可能性が高い。

Hackerたちの意見

MCPはちょっと過剰に宣伝されてる気がする。MCPを使うと、自分がコントロールしてないエージェントにツールを持っていけるんだ。すごいけど、すべての問題に合うわけじゃないよね。XやLinkedInの盛り上がりを信じてると、MCPがどこでも解決策になると思っちゃうかも。ローカルのClaudeクライアントにツールを持っていくのはすごいけど、MCPにはまだ解決すべき課題があるし、技術全般に言えることだけど、普遍的に使えるわけじゃない。トークンを燃やすレシピになっちゃうしね！

└

… 自分がコントロールしてないエージェントにツールを持っていけるんだ。すごい … ソフトウェア開発でコントロールを失うことが「すごい」って呼ばれる時代になったのか。

└

トークンを燃やすだけじゃなくて、MCPサーバーの運用や管理も資源の無駄遣いだよね。単一のAPIを呼ぶために、全体のDockerコンテナを立ち上げるなんて？小さなCLIユーティリティを呼びたいときに、別のDockerコンテナを立てろって言われるのもなんだかな。モノリスの方がいい気がする。

└

すべての問題の解決策ではないけど、あまり使わないアプリの代わりにはすごくいいと思う。UXがイマイチなアプリがほとんどの世界のアプリに当てはまるかもしれないし。

└

MCPはちょっと過剰に宣伝されてる気がする。MCPはかなりクールだけど、すべてのAIインフルエンサーが同時にMCPを持ち上げる投稿を始めたのは、ちょっとげんなりするよね。普段は盛り上がりのサイクルを無視できるけど、ここ数ヶ月でMCPに関するインフルエンサーのコンテンツが大量に押し寄せてきて、あの3文字を見るたびに疲れちゃう。

└

MCPはOpenAIとAnthropicにとって大事なライフラインだね。彼らが大手の縦型AI統合業者と競争するためには、「コミュニティ」が統合の大変な作業を全部やるしかないから、MCPがあるんだと思う。最初は盛り上がるけど、結局はまたメンテナンスの負担になるんじゃないかな。

└

同じことを3回言っただけで、理由を説明してないじゃん。

いや、MCP自体も新しくはないんだ—仕様は11月にAnthropicからリリースされたけど、2月に突然盛り上がったんだ。ソフトウェアの「新しさ」って、いつもすごく短命だけど、最近は本当に何が新しいのか疑問に思うよね。

└

そう考えると、claude 4が出てからまだ1ヶ月しか経ってないのが信じられないよね。前のバージョン3.7は2月に出たばかりだし！でも、面白いのは、MCPがローンチされた後すぐにみんなが飛びつかなかったことだね。2月までほとんど気づかれなかった感じ。AI技術としては珍しいよね。サーバーが構築されるのに時間がかかったり、クライアントがプロトコルをサポートするのに時間がかかったり、プロトコル自体が何度か改訂される必要があったから、みんながその価値を本当に理解するまで時間がかかったんだろうね。

└

そうだね、これがJavascriptエコシステムだったら、3ヶ月後には元の実装がメンテナンスモードに移行して、これからはセキュリティアップデートだけになるだろうね。みんなできるだけ早く置き換えに移行しなきゃいけない。

MCPはまだまだ初期段階って感じがする。良くなってきてるけど、「システムにnpxをセットアップして、隠れたディレクトリのJSONファイルを編集する」から、「MCPサーバーの名前とURLを設定する」っていう風に進化したんだ。でも、MCPサーバーのURLを見つけるのも、ほとんどの人には難しいよね。最適な形ってどんなのだろう。AIがサービスに接続することを「提案」できたらどうかな？AIがサイトをブラウジングして、「公式」のMCPサーバーを見つける（例えばllms.txt経由で）。それからユーザーに「Xプロバイダーを通じてデータにアクセスしてもいい？」ってプロンプトを表示するんだ。ユーザーが「はい」をクリックすると、OAuthリダイレクトが行われて、必要なツールにすぐアクセスできるようになる。OAuthフローを通じて特定の権限を与えられるのもすごくいいよね。

また「新しい技術」が「すべてを変える」とか言ってる、クリックベイトな見出しだね。これを書いてるのはその「新しい技術」を売ってる会社だし。

└

8年以上のMCP経験を求める求人を見たんだけど。

└

誰でも使える基本的なプロトコルをどうやって売るの？

MCPを使ってollamaとopenwebuiからカスタム関数を実行してみたけど、あんまり良い体験じゃなかった。LLMを使うのはデバッグというより、むしろ議論してる感じがする。でもこれが本当にシュールだった：LLMがリクエストしたパラメータで関数を呼び出してるのが見えるのに、返り値をくれずに「その関数は知らない」って言って、名前から結果を推測しようとするんだ。プロトコル自体もすごく変で、基準に基づいてるようで、実はそうじゃない。あるベンダーが一つの問題を解決するために作ったものだから。存在することには意味があるけど、果たして称賛に値するかは分からないな。

└

まあ、ollamaで動かせるLLMって、だいたいクソみたいなやつが多いよね。

└

どのモデルをollamaで使ってるか分からないけど、4bモデルを選んでChatGPTみたいになることを期待する人が多いけど、サイズの0.2%しかないからね。4bモデルはほとんどおもちゃだと思う。最新の8bモデルは時々役に立つけど、まだまだ笑っちゃうくらいバカなことも多い。14bは可能性が出てくるし、30bはかなり良い。でも、ホスティングされてるフロンティアモデルはこれらと比べるとまだ巨大で、いつもバカなミスをするから気をつけて。

└

DeepSeek/OpenAI/Anthropicのモデルを使ってないなら、あなたのLLMは複雑さに苦しむと思う。とはいえ、Puppeteerとusebrowserを除いて、私が試したMCPは全部クソだった。実際に機能しないし、あなたのLLMを混乱させるだけ。

ここでのコメントを見る限り、MCPの主なユーザーはclaudeやvscodeなどを使ってるエンドユーザーだと思ってる人が多いみたい。確かにこれは大きな利点で、使うのも超クールだけど、私的には主な利点は複雑なツールへのアクセスを中央のエージェントに与えることだと思う。MCPサーバーを使うことで、カスタムな深いリサーチができるエージェントを構築できるんだ。私たちは社内でこれを導入していて、ビジネスユーザーが20件のjiraチケットのリストを渡して、説明やコメントにあるあいまいな文脈に基づいて要約や分類を頼んでる。Jiraやconfluenceをいじりながら50回以上のツール呼び出しをして、数秒で返答するから、手動でやるのに何時間もかかることができる。MCPを裏で使ってるってことは全く関係ないけど、私たちビルダーの仕事をずっと楽にしてくれる。

└

同じことができたよ！1〜5のツールがどれだけ強力か、ちゃんとドキュメントを作って、LLMがスレッドの上の方で他のツールのレスポンスから引数を渡せることを知っていれば、意外と驚くよね。

└

私が概念的に悩むのは、MCPなしでもうまくいくってこと。CLIツールを作って、外部サービスにアクセスするのも含めて、エージェントCLIツール（またはCursorやIDEツール）にそのツールを使わせればいいだけ。もっとシンプルで、確立されたセキュリティモデルがあるし。

└

今、同じことをやってるよ（エージェントとのやり取りにSlackを使ってる）--- でもMCPじゃなくて、普通のツールコールAPIを使ってるだけ。

└

ソフトウェア配信の新しい形として、すごく素晴らしいと思ってる。企業では、何かカスタムソリューションが必要だけど、全体のフロントエンドUIを作るほどの規模やリソースがないっていう中間的なニーズがよくあるよね。今は、非技術的なエンドユーザーが必要とすることを正確にやるMCPツールをちょっと書くだけで、それをローカルにインストールされた「プラグイン」として、彼らがすでに使っているエージェントツールに提供できるんだ（Claude Desktopとか）。Smitheryを使えば、デスクトップソフトウェアの古いアップデートの心配もいらないし、ユーザーはホストアプリケーションを起動するたびに最新のツールを手に入れられるよ。

└

両方やってる者として言わせてもらうと、私がMCPのことを書く理由は、ユーザー側のツールがそれをサポートしているからだけなんだ。業界として何かまともなものに落ち着いた瞬間、全部引っこ抜いてそれを採用するつもりだよ。MCPは「適切な」APIを使って完全に標準的なツールでできることを何も提供していないからね。それに、EDIやEnterprise JavaBeans時代からいろいろやってきたから、XML-RPCとかも含めて、業界が新しいAPIの表面や意味を作り出すのが好きなのは知ってる。最初からちゃんと設計せず、開発者の時間を無駄にしないレベルの再利用を目指さないから、私は「新しい計算の分野」の人たちが確立された知恵を無視して独自のAPI「慣習」を作るのに慣れてる。でも、もっと自然で統合しやすいものが出てきたら、喜んで全部削除して移行するし、企業分野の多くの人も同じ気持ちだよ。私たちは数十年にわたって適切な管理ができるAPI管理ソリューションを構築してきたから、MCPはそれを全部台無しにしてる。

現在のMCPは、楽しいし利益も出るリモートエクスプロイトの手段として機能してる。なぜなら、セキュリティコントロールが不十分で、自然言語の文脈に大きく依存していて、信頼できないサーバーがモデルの挙動を操作できるから。MCPはAIのツール統合を標準化して簡素化しようとしてるけど、セキュリティ機能が半端だし、アーキテクチャの選択もリスクが高いプロトコルになってる。特に追加の安全策なしで展開すると危険だよ。OAuthトークンとか、送信レート以外ではアラームを作るのがほぼ不可能なもの（自分でLLMを運用してるの？APIコールを2倍にするメタMCPはどう？）とか、信頼できる入力を前提にして、サーバーがツールの説明を通じて悪意のある指示を注入できるから、プロンプトインジェクションやデータの流出、リモートコード実行につながることもある。ユーザーが明示的にツールを使わなくてもね。

└

残念ながら、「プロトコル」には今のところセキュリティに関する強調がないね。HTTPからHTTPSへの繰り返しみたいなもんだ。でも、MCPの周りに作られたツールはかなり便利で、作業が楽になると思う。今のところの理想的な使い方は、ローカルで動かしているMCPサーバーを使ってコードを実行したり、ローカルファイルを操作したりすることかな。[1] コードランナー - Appleコンテナ上でLLMコードをローカルで生成・実行するツール（https://github.com/BandarLabs/coderunner）（私も著者の一人です）

└

そうだね。マイクロコンピュータ時代の始まりの頃にも、誰かが同じことを言ってたかもしれないね。世界が崩壊するまで待ってて。

ステンレス社では、MCPはここに残ると賭けてるよ。MCPの売り手によると。MCPの問題は、取引ごとにLLMを通過させる必要があること。単純なプロトコルを交渉して、後のクエリが安くなるわけじゃないから、トラフィックが増えるとコストが大きく上がるんだ。

└

「取引ごとにLLMを通過させる必要がある」ってどういう意味か、ちょっとわからないな。普通の「プロダクションソフトウェア」の場合、APIコールのために真ん中にLLMを入れるのは避けたいよね。それはおかしいから、できるなら決定論的にAPIコールをするコードを書けばいい。チャット体験でLLMと話していて、そのLLMに外部システム（つまりAPIを叩く）とやり取りさせたいなら、LLMにそのAPIコールの仕方を教える方法が必要だよ。MCPはその一つの方法で、今のところは一番簡単かもしれない。MCPを通すとプロキシサーバーのせいでちょっと遅延が出るけど、真ん中に追加のLLMは入らないよ。（免責事項：私はStainlessで働いています。実際にStainlessではSDKを販売していて、MCPジェネレーターは無料です。）

└

MCPコールを通じてシンプルなプロトコルに切り替えるようにシステムを設計できない理由はないよ。具体的な状況に合った方法次第だからね。すべてのリクエストやトランザクションがLLMを経由する必要があるっていう設計上の決まりはないし。

FastMCPの著者です -- （驚くかもしれませんが）ここでの多くの観察に同意します。FastMCPは、元の仕様とSDKが混乱していて複雑だと感じたから存在しています。特に多くの優れた開発ツールがこのクライアントインターフェースを採用しているので、エージェントネイティブAPIをキュレーションすることには大きな価値があります。でも、仕様はまだ若くて、ハイプ（ポジティブもネガティブも）に取り込まれるリスクが高いです。みんなが建設的に改善に参加することをお勧めします。最後に：この記事は明らかにAI生成で、from mcp import toolは完全に幻覚です。ここにいる「AIは私の複雑なREST APIを理解できるべきだ」という人たちへのちょっとした考えの材料です。

└

みんなが建設的に改善に参加することをお勧めします。どうやって参加すればいいですか？私はいくつかのMCPサーバーを書いて（FastMCPを基にして - 素晴らしい仕事です！）、Anthropicのリストに一つを貢献しました。コアMCP仕様の維持や改善に実際にどう参加すればいいのでしょうか？Anthropicが主導していると思っていました。

└

（著者です）あなたが言う通り、そのスニペットはAI生成で、修正するためのTODOを忘れていました。私の不注意でしたので、許してもらえると嬉しいです。今、それを修正中です。修正してくれてありがとう！

今日、ほとんどすべての公開MCPサーバーは、GitHub、Jira、Linear、SlackなどのB2Bワークフローをターゲットにしています。最近の講演で、Andrej Karpathyは「LLMは新しいオペレーティングシステムだ」と主張しました。そのアナロジーが成り立つなら、これまでに作った「アプリ」はそのOSの企業向けの四角にしか存在しません。消費者向けのMCP体験もすぐに続くと思います。どんなものになるかはまだわからないけど、ゲームや他のインタラクティブなコンテンツかもしれませんが、インフラは整いつつあります。OpenAIはChatGPTがカスタムMCPコネクタをサポートすると言っているし、ElevenLabsの11AIはすでにMCP統合を搭載して出荷しています。そしてClaudeもリモートMCPサポートを追加しました。これらのチャネルが一般ユーザーに届くと、日常的なLLMユーザーはよりリッチな体験を求め始め、MCPは開発者がそれを提供する方法になるでしょう。