MCPの生みの親が語る、MCPの起源、アーキテクチャの利点、そして将来像
TechFlow厳選深潮セレクト
MCPの生みの親が語る、MCPの起源、アーキテクチャの利点、そして将来像
MCPについて読む価値のある最も優れた記事。
Web3業界の深掘り報道に専念し潮流を洞察著者：FounderPark
去年Anthropic发布的MCPプロトコルは、今年ManusやAgentのブームを受けて、AI分野で最も注目を集めるプロトコルとなった。OpenAI、マイクロソフト、Googleといった大手企業が続々とこのプロトコルをサポートし、中国国内でも阿里雲百錬、騰訊雲が迅速に対応し、プラットフォーム構築の高速化を実現している。
しかし議論も多く、MCPとAPIとの違いがあまりないのではないか、Anthropicのエンジニアがインターネットプロトコルに詳しくない、シンプルすぎる設計によるセキュリティリスクなどの指摘もある。
こうした疑問に答えるには、MCPプロトコルの生みの親に聞くのが最適だろう。
最近のポッドキャスト「Latent Space」では、AnthropicチームによるMCPプロトコルの開発者であるJustin Spahr-Summers氏とDavid Soria Parra氏をゲストに迎え、MCPの起源や彼らの考えについて深く語った。なぜMCPを開発したのか、既存のAPIとの違い、ツールの活用方法など、非常に多くの示唆に富んだ内容となっている。ぜひ保存してじっくり読むことをおすすめする。
対談ゲスト紹介：
-
Alessio Fanelli（司会）：Decibel パートナー兼CTO
-
swyx（司会）：Small AI 創業者
-
David Soria Parra：Anthropic エンジニア
-
Justin Spahr-Summers：Anthropic エンジニア
TLDR:
-
MCPというアイデアは、「LSP（Language Server Protocol）」というAnthropic内のプロジェクトから閃いたもの。二人のエンジニアはLSPの発想をヒントに、「AIアプリケーションと拡張機能間の通信」を標準化できないかと考えた。
-
MCPの核心的な設計思想とは、「ツール」という概念は単なるツールそのものではなく、クライアントアプリケーション、ひいてはユーザーとも密接に関連しているということ。MCPを通じて、ユーザーは完全なコントロール権を持つべきであり、モデルによるツールの呼び出しとは、あくまでモデルが自ら判断して起動するものであり、ユーザーが特定ツールを明示的に選ぶことは（プロンプト目的を除き）想定していない。
-
オープンAPIとMCPは対立関係ではなく、むしろ補完的。重要なのは、タスクに最も適したツールを選ぶこと。AIアプリ間の豊かなインタラクションを目指すならMCPが適しており、一方でモデルがAPI仕様を簡単に読み取り解釈できるようにしたいなら、オープンAPIの方が優れている。
-
MCPサーバーの迅速な構築には、AIによるコーディング支援が非常に有効。開発初期段階では、LLMのコンテキストウィンドウにMCP SDKのコードスニペットを投入し、LLMにサーバー構築を手伝わせることが良い方法だ。細部は後から調整すればよく、基本機能の早期実装と反復改善につながる。また、AnthropicのMCPチームは、LLMが参加しやすいよう、サーバー構築フローの簡素化にも力を入れている。
-
AIアプリ、エコシステム、Agentの将来の方向性は「ステートフルネス（状態保持）」に向かうだろうが、これは同時にAnthropicのMCPコアチーム内で最も議論が分かれるテーマでもある。何度も議論・反復を重ねた結果、ステートフルネスの未来を肯定しつつも、既存のパラダイムから逸脱してはならないという結論に至った。つまり、ステートフルネスの理念と運用の複雑さのバランスを取ることが必要だ。
Founder Parkは現在、開発者コミュニティの構築を進めています。新しいモデルや技術を積極的に試している開発者、起業家の方々のご参加をお待ちしています。以下のQRコードをスキャンし、製品／プロジェクト情報を詳しく記入してください。審査通過後、スタッフより招待いたします～
コミュニティに入ると、以下のような機会があります：
-
DeepSeekなどの主流モデルに関する高密度な開発交流；
-
リソースマッチング、API、クラウドベンダー、モデルベンダーとの直接的な意見交換の場；
-
便利で面白いプロダクト／事例については、Founder Parkが積極的に宣伝します。
01 MCPはどのように生まれたのか？
swyx（司会）：まず、MCPとは何ですか？
Justin：モデルコンテキストプロトコル（Model Context Protocol）の略です。AIアプリケーションが自身を拡張したり、プラグインエコシステムを統合したりするのを助けるために設計されたものです。具体的には、AIアプリケーション（「クライアント」と呼ぶ）とさまざまな外部拡張（「MCPサーバー」）が協働できる通信プロトコルを提供します。「拡張」とは、プラグイン、ツール、あるいは他のリソースを指します。
MCPの目的は、AIアプリケーションの開発者が外部サービス、機能、さらなるデータを簡単に導入できるようにすることで、アプリの能力を豊かにすることです。「クライアント-サーバー」という概念を名前に含めているのは、インタラクションのパターンを強調するためですが、本質的には「AIアプリをより拡張しやすくする」ための汎用インターフェースです。
ただし一点強調したいのは、MCPはモデルそのものではなく、AIアプリケーションに焦点を当てている点です。これはよくある誤解です。また、MCPをAIアプリケーションのUSB-Cポートに例えることに賛同しています。それはまさに、エコシステム全体をつなぐ共通インターフェースだからです。
swyx（司会）：クライアントとサーバーという特性は双方向性を意味し、まさにUSB-Cのように興味深いですね。多くの人々が研究やオープンソースプロジェクトを始めています。私は、Anthropicが他の研究所よりも開発者獲得に積極的だと感じます。これは外部からの影響によるものでしょうか、それともあなたたち二人が部屋の中で突然思いついたのでしょうか？
David：実際、ほとんどが私たち二人が部屋の中で閃いたものです。大きな戦略の一部ではありませんでした。2024年7月、私はAnthropicに入社したばかりで、主に内部開発者ツールを担当していました。当時、従業員が自社のモデルをより深く統合できるようにすることを考えていたのです。これらのモデルは優れており、今後さらに良くなっていくので、当然ながら自社モデルを多く使ってもらいたかったのです。
業務の中で、私のツール開発の経験からすぐに不満を感じました。Claude Desktopの機能が限られており拡張できず、一方IDEにはClaude Desktopの便利な機能がなく、両者の間で内容をコピーするのが面倒でした。次第に、これはM×Nの問題、つまり多数のアプリケーションと多様な統合の難題だと気づきました。これを解決するには、プロトコルを使うのが最適です。ちょうどその頃、私はLSP（Language Server Protocol）に関連する内部プロジェクトを進めていましたが、あまり進展していませんでした。これらすべてを組み合わせて数週間考えた結果、あるアイデアが浮かびました。LSPのようなものをつくって、「AIアプリと拡張機能間の通信」を標準化できないか？
そこで、私はJustinに相談し、幸運にも彼も興味を持ってくれました。こうして二人で開発を開始しました。
アイデアから約1か月半かけてプロトコルを構築し、初回の統合を完了しました。JustinはClaude Desktopへの初回統合で多くの作業を担い、私はIDEでのプロトタイプ検証を行い、IDE内でのプロトコル利用を示しました。正式リリース前にコードベースを見れば、多くのディテールが確認できます。これがMCPの大まかな誕生の物語です。
Alessio（司会）：タイムラインはどうなっていますか？11月25日が正式リリース日であることは知っています。このプロジェクトを始めたのはいつ頃ですか？
Justin：7月頃、Davidがアイデアを出した後、私はすぐに彼と一緒にMCPの構築を始めました。最初の数ヶ月は、クライアント、サーバー、SDKを含む通信プロトコルの基礎作業が多く、進捗は遅かったです。しかし、プロトコルを通じて通信できるようになった瞬間から、とてもワクワクするようになりました。さまざまな素晴らしいアプリケーションを構築できるのです。
その後、社内でハッカソンを開催したところ、同僚たちが3Dプリンターを制御できるサーバーや「メモリ機能」を実装する拡張機能を作りました。これらのプロトタイプは大変好評で、このアイデアが大きな可能性を持っていると確信しました。
swyx（司会）：MCPの構築に戻りますが、私たちが見るのは最終成果だけです。明らかにLSPの影響を受けているとお二人も認めています。構築時の工数について教えてください。大量のコードを書く作業が中心だったのか、それとも設計作業が多かったのか？私は設計作業の割合が大きいと感じますが、例えばJSON-RPCの採用、LSPからの借用度合い、特に難しい部分はどこだったのでしょうか？
Justin：私たちはLSPから多くのインスピレーションを得ました。Davidはツール開発においてLSPに精通しており、私は主に製品やインフラの仕事をしてきたので、LSPは私にとって新しい存在でした。
設計原則として、LSPはDavidが述べたM×N問題を解決しました。以前は、異なるIDE、エディタ、プログラミング言語がそれぞれ独立しており、VimでJetBrainsの優れたJavaサポートを使うことも、JetBrainsでVimの優れたC言語サポートを使うこともできませんでした。LSPは共通言語を作り、各当事者が「会話」できるようにし、プロトコルを統一することで、「エディタ-言語」の組み合わせごとに一度だけ実装すればよくなりました。私たちの目標も似ており、ただ舞台が「AIアプリ-拡張機能」の接続に変わっただけです。
詳細な点では、JSON-RPCと双方向通信の概念を採用した後、私たちは別の方向へ進みました。LSPは機能提示に重点を置いており、さまざまな基本要素を考えて提供する一方で、セマンティクスの原則にはあまり注力しませんでした。私たちはこれをMCPに応用しました。その後、MCPの各基本要素とその差異の理由について多くの時間を費やしました。これは膨大な設計作業でした。当初、TypeScript、Python、Zed統合用のRustの3つの言語をサポートする予定で、クライアントとサーバーを含むSDKを構築し、内部実験用のエコシステムを整備し、ローカルMCPの概念（サブプロセスの起動などを含む）を安定させました。
私たちはLSPに対する多くの批判を参考にし、MCPではそれを改善しようと努力しました。例えば、LSPがJSON-RPC上で行っているいくつかの処理は複雑すぎると感じたため、より直接的な実装方法を採用しました。MCPを構築する際、特定の領域で革新を行う一方で、他の面では成熟したパターンを借りることを選択しました。JSON-RPCのような選択肢は重要ではなく、基本要素などの革新に重点を置きました。このような先人の成果を借りることは、私たちにとって非常に役立ちました。
swyx（司会）：プロトコル設計に興味があります。ここには掘り下げられる内容がたくさんあります。すでにM×N問題に触れましたが、開発者ツールの仕事をしている人なら誰もが直面する「ユニバーサルボックス（Universal Box）」問題ですね。
インフラエンジニアリングの基本的な課題と解決策は、多くのものをN個の異なるものに接続するために「ユニバーサルボックス」を作ることです。Uber、GraphQL、私がかつて勤務したTemporal、Reactなどもこの問題を持っています。フェイスブック時代にN×Nの問題を解決した経験はありますか？
David：ある程度はありました。非常に良い例です。私はバージョン管理システムなどで多くの類似問題を扱ってきました。問題を皆が読み書きできるものにまとめて、「ユニバーサルボックス」で解決するのです。開発者ツールの分野では、このような問題が至る所にあります。
swyx（司会）：興味深いのは、「ユニバーサルボックス」を作る人々はみな同じ問題に直面する点です。つまり、合成性、リモートとローカルの問題などです。Justinが指摘した機能提示の問題も、本質的に同じものがあるのに、提示方法を明確に異なるものにする必要があります。
02 MCPの核心概念：ツール、リソース、プロンプト、三つ揃ってこそ
swyx（司会）：MCPのドキュメントを読んでいるときに疑問に思いました。なぜこれら二つに違いが必要なのでしょうか？多くの人がツール呼び出しを万能解と見なしていますが、実際には異なる種類のツール呼び出しには異なる意味があり、時にはリソース、時には操作実行、時には他の用途です。あなたたちがどの概念を近いカテゴリに分類したのか、そしてなぜそれが重要だと強調するのか知りたいです。
Justin：私たちはアプリケーション開発者の視点から各基本概念を考えました。IDEでも、Claude Desktopでも、Agentインターフェースでも、開発する際、ユーザーが統合から得たい機能が明確になります。ツール呼び出しは必須ですが、異なる機能を区別する必要があります。
そのため、MCPの最初の核心となる基本概念（後に追加されました）は次の通りです：
-
ツール（Tool）：核心です。モデルに直接ツールを追加し、モデルが自らいつ呼び出すかを決定します。アプリケーション開発者にとっては「関数呼び出し」のようなものですが、呼び出し主体がモデルである点が異なります。
-
リソース（Resource）：基本的に、モデルのコンテキストに追加可能なデータや背景情報のこと。アプリケーション側で制御可能です。例えば、モデルが自動的に関連リソースを検索し、コンテキストに含めることを希望する場合もあれば、アプリケーション内で明示的なUI機能を設定し、ユーザーがドロップダウンメニュー、クリップ型メニューなどを通じてLLMへのメッセージの一部にする場合もあります。これらがリソースの使用シーンです。
-
プロンプト（Prompt）：意図的にユーザーが発信または置き換えるテキストやメッセージとして設計されています。たとえばエディタ環境であれば、スラッシュコマンドやオートコンプリートのようなもので、使いたいマクロを直接挿入するようなイメージです。
MCPを通じて、これらの異なる表現方法に対する私たちは一定の見解を持っていますが、最終的にはアプリケーション開発者が決定します。アプリ開発者にとって、異なる形で表現されるこれらの概念を持つことは有用であり、それに基づいて適切な体験方法を決め、差別化を図れます。アプリ開発者の立場では、アプリが皆同じになることを望んでおらず、オープンな統合エコシステムに接続する際にも、独自の方法で最高の体験を創出したいと考えています。
二つの観点があると思います。第一に、現在ツール呼び出しは統合の95％以上を占めていますが、私はもっと多くのクライアントがリソース呼び出しやプロンプト呼び出しを使うことを期待しています。最初に実装されたのはプロンプト機能で、非常に実用的です。ユーザー主導のインタラクションが可能になり、情報の導入タイミングをユーザーが決定できるため、モデルの処理を待つより優れています。また、多くのMCPサーバーがツールの使い方をプロンプトで示してくれることを願っています。
第二に、リソースにも大きな可能性があります。MCPサーバーがドキュメントやデータベースなどのリソースを公開し、クライアントがそれらに基づいて完全なインデックスを構築するシナリオを想像できます。リソースの内容は豊かであり、モデルが駆動して公開するものではないため、コンテキストウィンドウで実際に使える以上のリソース内容を持つことができます。今後数ヶ月間、アプリケーションがこれらの基本概念をよりうまく活用し、より豊かな体験を提供することを期待しています。
Alessio（司会）：ハンマーを持っていると、すべてを釘と見なしてツール呼び出しで解決したくなる。例えば、多くの人がデータベースクエリにツールを使い、リソース呼び出しを使わない。API（データベースなど）がある場合、ツールとリソースの使用にはそれぞれどのような利点と欠点がありますか？SQLクエリにはいつツールを使うべきですか？データ処理にはいつリソースを使うべきですか？
Justin：ツールとリソースを区別する方法は次の通りです。ツールはモデルが発信して呼び出し、モデルが適切なツールを見つけ適用すると判断します。LLMにSQLクエリを実行させたい場合は、それをツールとして設定するのは妥当です。
リソースはより柔軟ですが、現在多くのクライアントがサポートしていないため、状況は複雑です。理想的には、データベーステーブルスキーマなどの内容に対してリソース呼び出しを行うべきです。ユーザーはこれを使ってアプリに情報を伝え対話を開始できるし、AIアプリが自動的にリソースを検索することもできます。エンティティの列挙や読み取りが必要な場合、リソースとしてモデリングするのは合理的です。リソースはURIで一意に識別され、汎用コンバーターと見なせます。たとえばMCPサーバーがユーザー入力のURIを解釈する場合。Zedエディタでは、プロンプトリポジトリとMCPサーバーがやり取りしてプロンプトを埋める例があり、双方がURIとデータ形式で合意する必要があります。これはリソース利用の非常に面白い交差点の例です。
再びアプリ開発者の視点に戻ると、ニーズを考え、それを実際の状況に適用してみてください。例えば、既存のアプリ機能を見て、この方法を採用すればどの機能を分離し、MCPサーバーで実現できるか。基本的に、添付ファイルメニューを持つIDEは自然にリソースとしてモデル化できます。これらの実装方法はすでに存在しています。
swyx（司会）： そうですね、Claude Desktopで@記号を見たとき、すぐにCursorの機能と同じだと気づきました。今は他のユーザーもこの機能を利用できるようになりました。この設計目標は素晴らしいです。機能自体はすでに存在するため、人々が理解しやすくて使いやすい。あなたたちもその価値を認めているでしょう。非常に役立つと思うので、ドキュメントのトップページに掲載すべきだと思います。これはとても良い提案です。
Justin：PR（Pull Request）を送ってくれませんか？この提案はとても気に入っています。
swyx（司会）：わかりました、送ります。
開発者リレーション担当として、常に人々に明確なガイドラインを提供しようとしています。たとえば、まず要点をリストアップし、その後2時間かけて詳細を説明する。そのため、一枚の図で核心内容を網羅することは非常に役立ちます。プロンプト（Prompt）の重要性を認識している点を高く評価しています。ChatGPTやClaudeの初期段階では、GitHub上にプロンプトリポジトリやプロンプトマネージャーライブラリを作ろうとする動きがありましたが、最終的には本当に流行りませんでした。
確かに、この分野ではさらなる革新が必要です。人々はプロンプトに動的性を求めており、あなたたちはその可能性を提供しています。多段階プロンプト（multi-step prompt）の概念を高く評価しています。これは、モデルを正常に動作させるために、多段階のプロンプト方式や制限の突破が必要な場合があることを示しています。プロンプトは単なる一回の会話入力ではなく、時には一連の会話プロセスであることもあります。
swyx（司会）： 私はこれがまさにリソースとツールの概念が融合するポイントだと思うのですが、あなたが今言ったように、時には一定程度のユーザー制御やアプリケーション制御が必要で、他の時にはモデルに任せるべきです。つまり、現在はツールのサブセットを選んでいるだけなのでしょうか？
David：はい、それは合理的な懸念だと思います。根本的には、これはMCPの核心設計原則の一つです。つまり、「ツール」という概念はツール自体だけでなく、クライアントアプリケーションと密接に関連し、ひいてはユーザーとも密接に関連しているということです。MCPの操作を通じて、ユーザーは完全なコントロール権を持つべきです。ツールがモデルによって制御されるとは、モデルのみが呼び出すということであり、ユーザーが特定のツールを使用すると明示的に指定することは含まれません（もちろん、プロンプト目的を除きますが、これは通常のUI機能としては想定されていません）。
しかし、クライアントアプリケーションやユーザーが、MCPサーバーが提供する内容をフィルタリング・最適化することも完全に合理的だと考えます。たとえば、クライアントアプリはMCPサーバーからツールの説明を取得し、それを最適化して表示できます。MCPのパラダイムでは、クライアントアプリが完全なコントロール権を持つべきです。また、私たちにはもう一つの初期のアイデアがあります。プロトコルに機能を追加し、サーバー開発者がプロンプト、リソース、ツールといった基本要素を論理的にグループ化できるようにする。これらのグループは異なるMCPサーバーと見なされ、ユーザーが自分のニーズに応じてそれらを組み合わせて使用できます。
03 MCPとOpenAPI：競合か補完か？
swyx（司会）：MCPとオープンAPI（Open API）の比較について話したいです。これは明らかに非常に注目されている問題の一つです。
Justin/David：根本的に、オープンAPI仕様は非常に強力なツールであり、私はAPIおよびそのクライアントの開発時に頻繁に使用しています。しかし、大規模言語モデル（LLM）の使用シナリオでは、オープンAPI仕様は過度に詳細すぎて、AI特有のより高次の概念、たとえば先ほど述べたMCPの基本概念やアプリ開発者の思考パターンを十分に反映していません。REST APIを提供してモデルに自由にやらせるだけと比べて、モデルは専用に設計されたツール、リソース、プロンプト、その他の基本概念からより多くの利益を得られます。
一方、MCPプロトコルを設計する際、意図的にある程度のステートフルネス（状態保持）を持たせました。AIアプリケーションとインタラクションは本質的にステートフルネス志向であるためです。ステートレス（無状態）が常に一定の場所に留まるとはいえ、ビデオ、音声などのインタラクションモードが増えるにつれ、ステートフルネスはますます好まれるようになり、そのためステートフルネスを持つプロトコルも特に有用になります。
実際、オープンAPIとMCPは相互に対立するものではなく、互いに補完し合います。それぞれに強みがあり、非常に補完的です。重要なのは、特定のタスクに最も適したツールを選ぶことです。AIアプリケーション間の豊かなインタラクションを実現することが目的なら、MCPの方が適しています。一方、モデルがAPI仕様を簡単に読み取り解釈できるようにしたいなら、オープンAPIの方が良い選択です。すでに初期段階から、両者の間に橋をかける動きがあり、オープンAPI仕様をMCP形式に変換して公開するツールやその逆もあり、これは素晴らしいことです。
Alessio（司会）： AGI Studioで共同主催したハッカソンがありました。個人Agent開発者として、有人がAPI仕様のURLを入力するだけで対応するMCPサーバーを生成できる個人Agentを構築しているのを見ました。この現象についてどう思いますか？これは、ほとんどのMCPサーバーが既存のAPIの上に層を追加しているだけで、独自の設計が少ないということを意味しているのでしょうか？将来的には、AIが既存のAPIを接続するだけの状態が続くのか、それともまったく新しい、前例のないMCP体験が登場するのでしょうか？
Justin/David：両方のケースが存在すると考えます。一方で、「コネクタを通じてデータをアプリケーションに導入する」需要は常に価値があります。現在は主にツール呼び出しがデフォルトで使われていますが、将来的には他の基本概念がこの問題を解決するのに適しているかもしれません。たとえそれがコネクタやアダプタ層であっても、異なる概念をアダプトすることで価値を高められます。
他方で、アダプタとして機能するだけではない、興味深いユースケースの機会もあります。たとえば、メモリMCPサーバーはLLMが異なる会話で情報を記憶できるようにし、順序思考MCPサーバーはモデルの推論能力を向上させます。これらのサーバーは外部システムとの統合ではなく、モデルに新たな思考方法を提供するものです。
いずれにせよ、AIを使ってサーバーを構築することは完全に可能です。実装したい機能が他のAPIにアダプトするものではなく、独創的なものであっても、モデルは通常実現方法を見つけることができます。確かに、多くのMCPサーバーはAPIラッパーとなり、これは合理的で効果的であり、大きな進展をもたらします。しかし、私たちはまだ探索段階にあり、実現可能な可能性を探り続けています。
クライアントがこれらの基本概念をより完全にサポートするにつれ、豊かな体験が湧き出るでしょう。たとえば、「Redditの版面内容を要約する」MCPサーバーはまだ誰も構築していませんが、プロトコル自体は完全にそれを実現可能です。人々のニーズが「自分が関心のあることをLLMに接続したい」から「本当にワークフローを実現したい、本当に豊かな、モデルが深くインタラクションできる体験を望んでいる」に変わったとき、こうした革新的なアプリが次々と登場すると考えます。ただし、現在、クライアントのサポート能力とサーバー開発者が実現したい機能の間には、「卵が先か鶏が先か」という問題があります。
04 どうやってMCPサーバーを速く構築するか：AIプログラミング
Alessio（司会）： MCPにはもう一つ、あまり議論されていない側面があります。それはサーバーの構築です。MCPサーバーの構築を始めたい開発者にアドバイスはありますか？サーバー開発者として、モデルに理解させやすい詳細な説明を提供することと、モデルが後で自動処理できる生データを直接取得することの間で、最適なバランスを見つけるにはどうすればよいでしょうか？
Justin/David：いくつかアドバイスがあります。MCPの利点の一つは、簡単な機能を構築するのが非常に容易で、約30分でセットアップできることです。完璧ではないかもしれませんが、基本的なニーズは満たせます。ベストな入門方法は、好きなプログラミング言語を選んで、該当するSDKがあればそれを使うことです。モデルがやり取りできるツールを構築し、MCPサーバーを構築し、そのツールをサーバーに追加します。ツールの説明を簡単に書いて、標準入出力プロトコルを通じて好きなアプリケーションに接続し、モデルがそれをどのように使うかを観察します。
開発者にとって、モデルが自分の関心事に作用する様子をすぐに見られることは非常に魅力的で、情熱をかき立て、さらにどのようなツール、リソース、プロンプトが必要か、効果をどう評価し最適化するかを深く考えさせます。これは深く探求できるプロセスですが、まずは簡単なことから始めて、モデルが自分の関心事とどのようにインタラクションするかを見るだけでも非常に楽しいものです。MCPは開発に楽しさを加え、モデルを迅速に機能させるものです。
私はAI支援コーディングも推奨します。開発初期段階では、MCP SDKのコードスニペットをLLMのコンテキストウィンドウに入れ、LLMにサーバー構築を手伝わせることがわかりました。結果は往々にして非常に良く、細部は後からさらに最適化できます。これは基本機能を迅速に実装し、反復改善する良い方法です。当初から、LLMが参加しやすいようにサーバー構築プロセスの簡素化に非常に注力してきました。過去数年間、MCPサーバーの起動には100〜200行のコードしか必要なく、本当に簡単です。もし既存のSDKがなければ、関連する仕様や他のSDKをモデルに与えて、部分的な機能の構築を手伝わせることもできます。好きな言語でのツール呼び出しは通常非常に直接的です。
Alessio（司会）：サーバー構築者が最終的に返すデータ形式と内容を大きく決定していることに気づきました。たとえばツール呼び出しの例で、Google Mapsの場合、返す属性は構築者が決定します。ある属性が欠けていれば、ユーザーはそれを上書きしたり修正したりできません。これは私がいくつかのSDKに不満を感じる点と似ています。人々がAPIラッパーのSDKを構築する際、APIに追加されたパラメータを漏らしてしまうと、私はその新機能を使えません。この問題についてどう思いますか？ユーザーはどれくらいの介入能力を持つべきか、それとも完全にサーバー設計者に委ねるべきでしょうか？
Justin/David：Google Mapsの例に関しては、我々にもある程度の責任があるかもしれません。なぜなら、これは我々が発表したリファレンスサーバーだからです。一般的に、少なくとも現時点では、ツール呼び出しの結果については、構造化されたJSONデータである必要もなく、特定のスキーマに一致する必要もない、という意図的な設計になっています。代わりに、テキスト、画像など、直接LLMに入力できるメッセージ形式で提示されます。つまり、大量のデータを返すことを好み、LLMがその中から関心のある情報をフィルタリング・抽出できると信じています。この点について多くの努力をしており、モデルの強みを最大限に発揮できるようにし、過度に制限したり指定したりしないことで、モデルの改善に伴って拡張性が損なわれるのを避けたいと考えています。したがって、リファレンスサーバーでは、理想はすべての結果タイプが呼び出されたAPIからそのまま渡されることで、APIが自動的にデータを伝達します。
Alessio（司会）： どこに境界線を引くかは、非常に難しい決断です。
David：ここでAIの役割を少し強調したいと思います。多くのリファレンスサーバーはClaudeによって書かれています。これは驚くべきことではありません。現在、人々は伝統的なソフトウェア工学のアプローチで問題を処理する習慣がありますが、実際には、LLM向けにシステムを構築する方法を再学習し、その能力を信頼する必要があります。LLMは毎年著しい進歩を遂げており、データ処理を得意とするモデルに任せることは賢明な選択です。これは、過去20年、30年、あるいは40年にわたる伝統的なソフトウェア工学の実践を手放す必要があるかもしれないことを意味します。
別の視点からMCPを見ると、AIの発展速度は驚異的であり、ワクワクする反面、不安でもあります。モデルの次の能力向上における最大のボトルネックは、おそらく外部世界とのインタラクション能力、例えば外部データソースの読み取り、ステートフルネスのアクションなどです。Anthropicで働いている際、安全なインタラクションを非常に重視しており、それに応じたコントロールと較正措置を講じています。AIの発展とともに、人々はモデルにこれらの能力を期待するようになり、モデルを外部と接続することはAI生産性向上の鍵となります。MCPはまさに、将来の方向性とその重要性に対する私たちの賭けです。
Alessio（司会）：その通りです。私は「フォーマット済み（formatted）」という属性を持つAPIはすべて削除すべきだと思います。すべてのインターフェースから生データを取得すべきです。なぜ事前にフォーマットする必要があるのでしょうか？モデルは十分にスマートで、住所などの情報を自分でフォーマットできます。そのため、この部分はエンドユーザーが決定すべきです。
05 MCPはより多くのツールをどう呼び出すか？
swyx（司会）： もう一つ質問があります。あるMCP実装がサポートできる関連機能の数はどれくらいですか？これは広さと深さの問題に関係しており、先ほど議論したMCPのネストとも直接関係しています。
2024年4月、Claudeが最初の100万トークンコンテキストの例を発表した際、250のツールをサポートできると述べましたが、多くの実際の状況では、モデルはこれほど多くのツールを実際に効果的に使うことができません。ある意味で、これは広さの問題です。ツール呼び出しのツールがないため、モデルと平面上の一層のツール階層構造しかないため、ツールの混同が起きやすくなります。ツールの機能が似ていると、モデルは間違ったツールを呼び出し、結果が不満足なものになります。特定の時点で有効化できるMCPサーバーの最大数について、何かアドバイスはありますか？
Justin：正直に言えば、この問題には絶対的な答えはありません。一方では使用するモデルに依存し、他方ではツールの名前と説明がモデルが正確に理解できるほど十分に明確で、混同を避けることができるかによります。理想的には、すべての情報をLLMに提供し、すべてを完全に処理させることが、MCPが描く将来のビジョンです。しかし、現実のアプリケーションでは、クライアントアプリケーション（つまりAIアプリ）がいくつかの補足作業を行う必要があるかもしれません。たとえば、ツールセットをフィルタリングする、あるいは小型で高速なLLMを使って最も関連性の高いツールを先にフィルタリングし、その後大型モデルに渡すなどです。また、他のMCPサーバーのプロキシとして一部のMCPサーバーを設定することでフィルタリングすることもできます。
Claudeの場合、数百のツールをサポートするのは比較的安全です。しかし、他のモデルの場合はまだ不明です。時間が経つにつれて状況は改善していくはずなので、制限に対しては慎重である必要があります。サポートできるツールの数は、大きくは説明の重複度に依存します。サーバーの機能が異なり、ツール名と説明が明確でユニークであれば、GitLabとGitHubサーバーを同時に接続するような類似機能のサーバーがある場合よりも、多くのツールをサポートできるでしょう。
また、これはAIアプリの種類にも関係します。高度にインテリジェントなアプリを構築する際は、ユーザーに質問する回数やインターフェースの設定可能性を減らすかもしれません。しかし、IDEやチャットアプリのようなプログラムを構築する際は、すべての機能を常に有効にするのではなく、ユーザーが異なるタイミングで必要な機能セットを選べるようにするのは完全に合理的です。
swyx（司会）：最後に、順序思考サーバー（Sequential Thinking MCP Server）について重点的に話しましょう。それはブランチ機能を持ち、「より多くの作成スペース」を提供する能力も非常に興味深いです。また、Anthropicは先週新しいエンジニアリングブログを発表し、彼らの思考ツール（Thinking Tool）を紹介しました。コミュニティでは、順序思考サーバーとこの思考ツールの間に重複があるかどうか疑問を持っています。実際、これは異なるチームが異なる方法で似たことをしているだけです。実装方法は多様です。
Justin/David：私の知る限り、順序思考サーバーとAnthropicの思考ツールには直接の共通の起源はありません。しかし、これは一般的な現象を反映しています。LLMにより周到な思考をさせ、幻覚を減らす、あるいは他の目標を達成するために、多くの異なる戦略があり、複数の次元でより包括的かつ信頼性の高い効果を示すことができます。これがまさにMCPの強みです——異なるサーバーを構築したり、同じサーバー内で異なる製品やツールを設定したりして、多様な機能を実現し、LLMに特定の思考パターンを適用させて異なる結果を得ることができます。
つまり、理想的な、規定されたLLMの思考方法は存在しません。
swyx（司会）： 異なるアプリには異なる用途があり、MCPはまさにその多様性を実現できる、ということですね？
Justin/David：そうです。いくつかのMCPサーバーが採用するアプローチは、モデルが当時持っていない能力の空白を埋めていると感じます。モデルのトレーニング、準備、研究には時間がかかり、能力を徐々に向上させる必要があります。順序思考サーバーは見た目は簡単かもしれませんが、実際にはそうではなく、数日で構築できます。しかし、モデル内部でこのような複雑な思考機能を直接実装しようとすれば、数日で終わるものではありません。
たとえば、私が使うモデルが信頼できない、あるいは誰かが現在のモデルが生成する結果全体が信頼できないと感じる場合、私はMCPサーバーを構築して、あるクエリに対してモデルに3回結果を生成させ、その中から最良のものを選ぶことを想像できます。MCPを使えば、このような再帰的で合成可能なLLMインタラクションを実現できます。
06 複雑なMCPとAgentの違いは何ですか？
Alessio（司会）： 次に、合成性について聞きたいと思います。あるMCPを別のMCPに導入するという概念についてどう思いますか？これに関する計画はありますか？たとえば、Redditの版面内容を要約するMCPを構築したい場合、これはRedditAPIに対応するMCPと、要約機能を提供するMCPの両方を呼び出す必要があるかもしれません。このような「スーパーマルチMCP」をどうやって構築すればよいでしょうか？
Justin/David：これは非常に興味深い話題で、二つの視点から見ることができます。
一方、要約機能のようなコンポーネントの構築を考慮します。それはLLMを呼び出すかもしれませんが、特定のモデルに依存しないようにしたいと考えています。ここにMCPの双方向通信機能が関係してきます。Cursorを例にすると、LLMとのインタラクションループを管理しています。サーバー開発者はCursorを通じてクライアント（つまりユーザーが使うアプリケーション）に、特定のタスクを実行するよう要求できます。たとえば、クライアントにユーザーが現在選択しているモデルを使って要約させ、結果を返すように指示できます。これにより、要約モデルの選択はCursorに委ねられ、開発者がサーバー側に追加のSDKやAPIキーを導入する必要がなくなり、特定のモデルに依存しない構築が実現できます。
他方、より複雑なシステムをMCPで構築することは完全に可能です。CursorやWindsurfのようなサービスを提供するMCPサーバーを想像できます。このサーバー自身がMCPクライアントとしても機能し、他のMCPサーバーを呼び出してより豊かな体験を創造します。これは再帰的特性を示しており、仕様の許
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
