MCP: （偶然の）汎用プラグインシステム

 (worksonmymachine.substack.com)
30 ポイント 投稿者 GN⁺ 2025-06-29 | 4件のコメント | WhatsAppで共有
  • USB-C は単なる充電・ファイル転送用ではなく、さまざまな用途へ拡張できる 汎用性 に価値がある
  • MCP(Model Context Protocol) はもともとAIアシスタント向けに設計されたが、実際には あらゆるデータソースとツール をつなぐ 汎用プラグインシステム になり得る
  • NFT Base64 の事例のように、プロトコルは本来の目的を超えて、現実のデータを直接保存・活用する形へ 拡張 できる
  • MCPサーバー が増えるほど、各アプリは個別の連携なしでも 多様な機能 を簡単に取り込める
  • USB-CのようにMCPも「何でもつなげられる可能性の空間」として、予想外のイノベーション を生み出す土台になるだろう

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

USB-Cと予期せぬ汎用性

  • USB-Cは誰もが充電やファイル転送のためのものだと考えていたが、その構造のおかげで多様な用途 へ拡張できる
  • 筆者の友人Rexがトースターをモニターにつないで、トースターに HDMI出力 機能を持たせた事例は、USB-Cの 無限の可能性 を示している
  • これはUSB-Cが 電力やデータ規格 を意識せず、端子さえ合えば何でも接続できる構造だからだ

車のシガーソケットの原理

  • 車の シガーソケット はもともとタバコの点火用だったが、今ではさまざまな 汎用電源ポート として使われている
  • シガーソケットのように プロトコル は利用者の選択を制限せず、多様な用途を許容する
  • MCPも これに似た拡張性 を持っている

MCPの再発見: 偶然に汎用プラグインシステムへ

  • 一般に MCP(Model Context Protocol) はAIアシスタント（例: Claude）などがデータを活用するためのものだと知られている
  • 公式ドキュメントにも「AIモデルを複数のデータソースやツールに標準的につなぐ」と明記されている
  • しかし AI要素を取り除いて みると、MCPは「何であれ」異なるデータソースやツールへ接続する手段になる
  • つまり本来の目的とは無関係に、汎用接続プロトコル になるということだ
広告

The NFT Base64 Revelation

  • NFTはもともと画像を 参照 するためのものだったが、ある時点から 参照そのものがデータになった
  • プロトコル本来の趣旨が変わることで、図書館カードが実際の本の役割 を果たすようになった
  • 本来の意図よりはるかに広い現実のデータを直接扱うツール へと変貌した

誰も予想しなかったネットワーク効果

  • AI向けにMCPサーバーが増えるほど、誰でも追加開発なしに あらゆるアプリが新機能 を獲得する効果が生まれる
  • たとえば誰かが Spotify MCPサーバー を作れば、運動アプリがMCPを通じて 自動でプレイリストを生成 できる
  • 互いを知らない開発者やアプリ が自然につながり、皆が利益を得るネットワーク効果が発生する
  • 各MCPサーバーは 汎用プラグイン として再利用できる
  • 誰も計画していなかったのに、偶然の汎用プラグイン生態系 が生まれる

USB-Cの意味とMCPの哲学

  • MCPはしばしば AIのUSB-C にたとえられるが、USB-C が特別なのは 単なるポート ではなく、何でも接続できる可能性の空間 だからだ
  • USB-Cが電力、データ、映像、その他の未知の機能を受け入れるように、MCPも「AI用」ではなく「機能のためによく設計された穴」として、誰でもどんな機能でも接続できる
広告

The Part Where I Tell You I'm Building Something

  • 筆者は APM(Actions Per Minute) という作業管理アプリを開発中だ
  • APMはプラグインシステムとして 完全にMCPサーバーだけ を使って動作する
  • 利用者は欲しい機能を追加するたびにMCPサーバーを接続するだけでよい（例: スペルチェック、コーヒー自動注文、ゲームキャラクターのリアクションなど）
  • これはアプリ自体が 流動的で多様な形 に変身できる構造だ

The Toaster Protocol Principle

  • すべての 偉大なプロトコル は、最初の意図とは異なり、予想外の用途で使われること でイノベーションを生む
    • HTTP: 学術論文用 → 文明のインフラ
    • Bluetooth: ハンズフリー → 玄関ドアの解錠など
    • USB: 入力機器 → 携帯扇風機の充電など
  • MCPもまた、もともとはAIコンテキスト伝達用だが、本質的には あらゆるもの同士をつないでくれるプロトコル だ
  • 予測不能なイノベーションを生み出す プラグイン生態系 の基盤であることを強調する
  • まったく意図されていなかったが、トースターとモニターをHDMIでつなぐ時代 にぴったりの方式だ

まとめ

  • PS: もしMCPサーバーで焼きたてのパンの香りを出すコンピューターを作ったら、ぜひ連絡してほしい
  • PPS: APMのアーリーアクセス を公開しており、奇抜な試み と 創造的な実験 を歓迎している
  • （どこかではプロトコルが本来の目的どおりに使われている。これはとても疑わしい）

関連記事

4件のコメント

 
a1eng0 2025-06-30

MCPサーバーの応答は、決まったスキーマがなく自然言語である場合が多いです。

この自然言語の応答を、LLMなしにプログラミング的に処理するのは難しいでしょう。
 
winterjung 2025-06-30

参考までに、mcp 2025-06-18 仕様に新たに structured tool output が追加されたことで、レスポンススキーマの記述が可能になりました。既存実装の mcp ツールはおっしゃるとおり大半が unstructured だと思いますが、今後の mcp ツールには期待できそうです。
 
a1eng0 2025-07-01

Winterさん、ここでもまたお見かけしましたね（笑）

250618の仕様をフォローできていませんでした。ありがとうございます！
 
GN⁺ 2025-06-29
Hacker Newsの意見

  • 私はこの記事とMCPプロトコルが本当に気に入っている。ただ、MCPを見るとどこかマイクロサービスやSOAを思い出す。新たな障害点を生み出す悪夢の再来にならないか心配でもある。一方で、エージェント導入のおかげで信頼性の向上がより自然に実現できるのではという期待もある

  • 私はこの記事の考えに共感しているし、著者がMCPの使い方を少し外し気味に使っている点もとても面白いと思う。この発想の本当の核心は、これまでになかった新しいことを可能にするプロトコルが現れたこと自体ではない。実際、ほかのコメントにもあるように、MCPそのものは特別新しいわけでも興味深いアイデアでもない。本当に面白いのは、AIエージェントブームのおかげで相互運用性（Interoperability）が注目され、ベンダーロックインの問題が時代遅れのものとして扱われつつあることだ。この流れがどれくらい続くかは分からないが、今はかなり気分がいい

    • これを見ると、Winsock導入当時を思い出す。Windowsではネットワーク関連のあらゆる作業が、かつてはそれぞれ独自の私的インターフェースを使っていた。だがある日、複数のベンダーが一堂に会し、みんなに利益のある共通標準を作ることを決めた、という話を覚えている。WinsockのWikipedia 参照
    • 重要なのは、単に相互運用性が流行したとか、簡単に接続できるようになったという点ではない。本当の革新は、LLM自体がツールの扱い方を学んだことだ。バックエンドさえ作れば、フロントエンドはもはや自分の仕事ではなく、AIが勝手に解決してくれるという変化だ。ClaudeやGeminiも、目的だけ提示すればツール活用を自力でこなしてくれる。以前は、望む結果を得るために毎回ステップごとの明確な手順を組まなければならなかったが、今では固定的なプログラムよりもLLMの方が流動的な状況にずっと適応できる。これは非常に大きな変化だ
    • かなり過熱した期待感がある状況だとは思う。それでも、AIエージェントが相互運用性への強い動機を作ったのは確かだ。以前は、みんなが自分のシステムの中でゆっくり働くことが安定した雇用の保証になっていたが、今では誰もがあらゆるものを接続しようとしている。CEOがハッカソンにピザの使い走りとして自ら動いた方が安上がり、という変化に近い。エージェントは連携性に依存している。過去のAPI連携の波を実際に経験した立場からすると、ようやく世界が追いついてきたという感じがする。この雰囲気が長く続いてほしい
    • AIエージェントブームが相互運用性ブームを引き起こし、ベンダーロックインを時代遅れにしたという指摘には完全には同意しない。最近注目されているCursorのようなツールも、MCPを一方向にしか使っておらず、会話履歴やコンテキストを外に出してはいない。私はCursorが好きだが、オープンソースではないVS Codeフォークである時点から、こうした「返さない」姿勢は開発者の信頼に悪影響を与えると思う。結局のところ、ロックインは依然として強固だという現実がある
    • 皮肉なことに、最近のAPIアクセス制限はAI学習データをめぐってさらに厳しくなっている。実際には、こうしたAPIのロックダウンはずっと以前から存在していたし、新しい開放のトレンドが過熱した期待に追いつけなければ、いつでも再び閉じる可能性があるという懐疑的な見方もある

  • 著者はMCPの汎用性に大きな期待をかけているが、正直、APIという概念そのものと何が違うのか疑問だ。MCPをRESTに置き換えても、記事の内容はそれほど変わらないのではないか。OS APIやPOSIX、Unixパイプとも類似している。もちろんMCPはそれらすべてよりずっとシンプルで汎用的だ。しかし本当の解決策は、その都度新しい抽象化を作ることではなく、基本に忠実でシンプルなソフトウェアを作ることではないかと思う

    • MCPはRESTとは違う。むしろ、MCPはランタイムでRESTエンドポイントを動的に発見できるようにし、ユーザーがどのRESTエンドポイントを使うかを自分で設定できるプロトコルのようなものだ。たとえば、アプリでSpotifyの曲を再生するなら、当然Spotify APIを使う。後からSonofmの曲もサポートしたくなれば、従来のやり方ではコード修正、条件分岐追加、新バージョンの配布、更新案内などが必要になる。一方MCPでは、こうした作業をランタイムで設定できるため、拡張性がずっと高いように感じる
    • 核心的な違いは、MCPでは自己記述が最初から必須であることだ。RESTにもOpenAPIはあるが、これは後付けで、標準の活用度も低い。これに対してMCPは、まず記述を公開することを要求するので、アクセスしやすさが違う
    • 私には、MCPが本当に新しいと感じられた点は、プロトコルレベルでスキーマ提供を必須にしたことだけだ。もちろん、リクエストとレスポンスの構造が一貫しているのは、動的型を静的型で包むライブラリの立場からも管理しやすい。実際にはみんなAPIで似たことをすでにやっていた。ただ、そのenvelope形式について合意できていなかっただけだ。そもそもスキーマ提供が必須であり、AIモデルがそれを即座に活用できるという利点があるから注目されているのだと思う
    • MCPとRESTの大きな違いは、list-tools という組み込みコマンドが存在することだ。REST APIではリソース一覧化にさまざまな方法があるが、MCPでは一つの標準化された方法だけが提供される
    • もう一つの大きな違いは、MCPにはdiscovery（発見）の手順がプロトコル自体に組み込まれていることだ。RESTには、どんなリソースが利用可能か、クライアントにAPIの機能そのものを知らせる仕組みがまったくない

  • MCPをすごいと言う人は多いが、実際にすばらしいものを作っている例はあまり見たことがない。ブロックチェーンブームの時と似た気分だ。結局、MCPもAIがもっと賢くなるまでの間に使う暫定策なのではないかと思う。2年もすれば、MCPの代わりにツールのドキュメントやOpenAPIをそのまま与え、AIが全コンテキストを直接処理する形へ自然に進化していくのではないか

    • たとえば、Ableton Liveのドキュメントだけ与えても、Claudeが直接曲作りをするのにどれほど役立つのか疑問だ
    • モデル性能がどれだけ上がっても、結局は決定的なツールアクセスと世界の状態に関する情報を直接与えなければ、活用度は大きく制限される。そしてセキュリティの問題も考えると、制御なしにモデルが本番環境で勝手にリクエストを出せるようにはできない。MCPをめぐる過熱はやや行き過ぎだと思うが、それでもここで語られている問題自体は本当に重要だ。もしこのプロトコルのおかげで開発者が機能を明確なAPIとして公開するようになるなら、それは非常に期待できることだ
    • ブロックチェーンブームとMCPはかなり違う。私も最初は懐疑的だったが、実際にMCPサーバーを少し実装してみると、まったく違う体験だと分かる。対話型/音声AIと現行のLLM、さらにMCPや各種ツール、関数機能をAPIやプライベートデータ/サービスと組み合わせられるようになり、まったく新しいフロンティアに入った感覚がある。100%完璧ではないが、ほとんどの実用ケースには十分であり、今後はアプリの作り方そのものが大きく変わるだろう
    • 実際、私は州の議員たちが今週どんな活動をしたのか知りたかったのだが、関連情報を簡単に探す手段がなかったところ、MCPとcongress.gov APIが魅力的だと聞いてMCPサーバーを作ってみた。コードはこちらで公開している。今では米国議会の動きをリアルタイムで追う用途で本当にうまく使えている
    • AIモデルの構造が進化し続ける限り、中間のミドルウェア層、つまりMCPは簡単には消えないと思う

  • 私は、Microsoftがこれまで何度もやってきた "Embrace, Expand, Extinguish" 戦略がここでも適用されているのではないかと思う。システムの安定性とセキュリティを理由に、エージェントが管理なしで動的にツールを発見できるようにすると衝突リスクが高まるからだ。PydanitcAIなどの代替もあるが、結局MicrosoftはMCPを "Build 2025" で正式に推し出し、自分たちのペースで業界を主導している。Anthropicはツールが弱くガバナンスも不十分な状態で標準を出したので、Microsoftにとっては掌握しやすい構図だ。次の段階は、Microsoftが自社レジストリを業界標準にし、Windows特化のコマンドと結びつけるシナリオだろう。最後には、「セキュリティ」基準を自社に有利な形で左右し、競合を排除する絵が見えてくる

  • AI要素を完全に取り除いたらどうだろうか。もしAIミドルウェアなしでMCPサーバーに直接依存するようになると、すぐに後方互換性の問題に突き当たるのではという懸念がある。なぜなら、MCPサーバーは呼び出し側がAIアルゴリズムであることを前提にしており、ツールや入出力スキーマに基づく破壊的変更がいつ起きてもおかしくないからだ

  • 私も似たように考えたことがあるが、実際にはMCPサーバーの多くは既存APIの新しいクライアントにすぎないのではないかと思う。たとえばKagi MCPサーバーはKagi APIを呼んでいるだけだ。それなら結局APIを直接使う方がよいのではないか。また、システム上にはMCPサーバーの数だけPythonインタープリタが増えていくことになるが、それらをまとめて一度にブリッジしてくれる「ホスティング」サービスが今後出てくるのではないかと気になる

    • 私の理解では、MCPというのは既存APIに /list-tools というエンドポイントを一つ追加するようなものだ。すべてのクライアントはまず /list-tools にアクセスして利用可能なツールの一覧を受け取り、その後それぞれのAPIを呼び出す
    • 私のアプローチはこうだ。すでにOpenAPI仕様があるAPIなら、FastMCPでそのままラップすればいいのではないかという考えだ。実際、認証リクエスト処理などを行いつつGooseに連携してみたが、結局はGooseが既存のAPIルートに curl コマンドを投げるだけで済むという結論になった。OpenAPI仕様が十分によくできていれば、MCPは必須ではないかもしれない。もちろん既存APIがないなら、MCPサーバー自体が中核動作を実現する方向に進化すると見ることもできる

  • コメント欄には懐疑的な見方が多くて共感する。先週MCPサーバーを自分で実装してみたが、正直「よく設計されている」とまで持ち上げるのは過大評価だと思う。MCPの目標の一つは「簡単に作れるようにすること」だが、実際にやってみるとそれほど簡単ではない。それでも重要なのは、今とても多くの開発者の視線が一方向に向いていることだ。こういうモメンタムの中では問題解決のスピードが非常に速くなりうる。また、何かに対してクリティカルマスが形成されてはじめてエコシステムが整うが、今まさにその変曲点が来ているように感じる。みんなに忍耐と幸運があることを願う

    • MCP Pythonライブラリを使うだけなら本当に簡単だ。関数にデコレータを付けるだけでツールがすぐ完成する。私もMCPプロトコルのことはまったく知らなかったが、そのやり方で問題なく動いている。もちろんプロトコル自体を直接実装しなければならないなら話は別かもしれない
    • MCPサーバーは「既存の公開または準公開API」を再公開するだけでよい。元のエンドポイントを可能な限り最小限の変更で実装できるべきだ、という見方には説得力がある
    • 過去にもこうした試みはあったが、結局数年たつとアプリ側がエンドポイントを閉じてしまい、chatgptやclaudeなど特定のサーバーからしかアクセスできないようにする。相互運用性は実質的にはユーザーの移動性でもあり、現実には多くの技術企業が移動性よりもロックインと独占を志向している

  • 技術の採用と普及のために参入障壁を下げることが、歴史を通じて重要な役割を果たしてきた点を強調したい。MCPもその延長線上にあり、軽視すべきではない。私たちのチームでも、技術的バックグラウンドがまったくない人がファイル共有作業を自動化するエージェントを自分で使えた。もちろん以前なら、何百ものプログラミング言語やライブラリ、APIがなければ実現できなかったが、MCPのおかげで非専門家でも意識せずにすぐ解決できる時代になった。性能面で最高ではないし、最適な実装でもないが、こうした新しいやり方がもたらす価値は、現在のリソースと技術水準では前例がない。その点こそが本当の核心だ

    • 技術者ではないチームメンバーがファイル共有の整理を一人でうまくやれたという話は、誇張だと思う。数千ファイルの整理ならまだしも、私の経験では、ほぼすべてのファイル共有整理の試みで、関係部門の協力を得ることすら難しかった。担当者たちですら自分の仕事ではないとして嫌がる。上級役員まで巻き込んでようやく説得したり、一緒に座ってファイル構造だけを1時間ひねり出すのも大変だった。作業量の50%は部門間の政治、20%は手順更新、20%は教育で、技術的な問題は10%にすぎない。大小の災害や終わりのない混乱まで経験してきたので、AIツールが簡単にしてくれるとしても、現実がそんなに単純なはずはないと思う。数か月後にはバックアップの復元作業をすることになるのでは、という懐疑的な予想だ

  • 「AIエージェントがWarcraft 3でPeonみたいに命令を受けて返事してくれたらいいのに」という冗談に対して、私はむしろヨットに乗っていたいと答えたい

    • "I'd rather be sailing" はWarcraft 2のセリフで、Warcraft 3では "I'd rather be flying" と返す、という点は指摘しておきたい