🐙
MCPの深堀りとAI Toolingの未来についてメモ

2025/03/23に公開
Model Context Protocol
LLM
AIエージェント
tech
https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

の記事の内容が非常に良さそうだったので、訳をメモとして残しておく。

 MCPの深堀りとAI Toolingの未来について
 はじめに2023年にOpenAIが関数呼び出し（function calling）をリリースして以来、エージェントとツール使用のエコシステムを実現するために何が必要かを考えてきた。基盤モデルがより知能化するにつれて、エージェントが外部ツール、データ、APIと相互作用する能力はますます断片化している：開発者はエージェントが操作し、統合する各システムに特殊なビジネスロジックを実装する必要がある。
実行、データ取得、ツール呼び出しのための標準インターフェースが必要であることは明らかだ。APIはインターネットの最初の大きな統一要素だった—ソフトウェアが通信するための共通言語を作り出したが、AIモデルにはそれに相当するものがない。
Model Context Protocol（MCP）は2024年11月に導入され、開発者とAIコミュニティの間で潜在的な解決策として大きな注目を集めている。この記事では、MCPとは何か、それがAIとツールの相互作用をどのように変えるのか、開発者がすでに何を構築しているのか、そしてまだ解決すべき課題について探る。

 MCPとは何かMCPはシステムがAIモデルにコンテキストを提供するための、統合間で一般化可能な方法を可能にするオープンプロトコルだ。このプロトコルは、AIモデルが外部ツールを呼び出し、データを取得し、サービスと対話する方法を定義する。具体例として、Resend MCPサーバーが複数のMCPクライアントとどのように連携するかがある。
この考え方は新しいものではない。MCPはLSP（Language Server Protocol）からインスピレーションを得ている。LSPでは、ユーザーがエディターで入力すると、クライアントは言語サーバーに自動補完の提案や診断を照会する。
MCPがLSPを超えて拡張している点は、そのエージェント中心の実行モデルにある：LSPは主に反応的（ユーザー入力に基づくIDEからのリクエストに応答する）だが、MCPは自律的なAIワークフローをサポートするように設計されている。コンテキストに基づいて、AIエージェントはどのツールを使用するか、どの順序で、そしてそれらをどのように連鎖させてタスクを達成するかを決定できる。MCPはまた、人間が追加データを提供し、実行を承認するための人間参加型の機能も導入した。

 現在の人気ユースケース適切なMCPサーバーのセットを使用すると、ユーザーはすべてのMCPクライアントを「なんでもアプリ」に変えることができる。
Cursorを例に取ると：Cursorはコードエディタだが、同時に優れたMCPクライアントの実装でもある。エンドユーザーはSlack MCPサーバーを使用してSlackクライアントに、Resend MCPサーバーを使用してメール送信者に、Replicate MCPサーバーを使用して画像生成ツールに変えることができる。MCPをより強力に活用する方法は、1つのクライアントに複数のサーバーをインストールして新しいフローを実現することだ：ユーザーはCursorからフロントエンドUIを生成するサーバーをインストールし、さらにエージェントに画像生成MCPサーバーを使用してサイトのヒーロー画像を生成するよう依頼することもできる。
Cursor以外では、今日の大部分のユースケースは、開発者中心のローカルファーストのワークフロー、またはLLMクライアントを使用した新しい体験のいずれかに要約できる。

 開発者中心のワークフロー毎日コードの中で生活し呼吸している開発者にとって、よくある感想は「xをするためにIDEを離れたくない」というものだ。MCPサーバーはこの夢を実現する素晴らしい方法である。
Supabaseに切り替えてデータベースの状態を確認する代わりに、開発者は今ではPostgres MCPサーバーを使用して読み取り専用のSQLコマンドを実行し、Upstash MCPサーバーを使用してIDEから直接キャッシュインデックスを作成および管理できる。コードを繰り返し作成する際、開発者はBrowsertools MCPを活用してコーディングエージェントにライブ環境へのアクセスを提供し、フィードバックとデバッグを行うこともできる。
開発者ツールと対話するワークフロー以外にも、MCPサーバーが解放する新しい用途として、ウェブページをクロールしたり、ドキュメントに基づいてMCPサーバーを自動生成したりすることで、コーディングエージェントに高精度のコンテキストを追加することが可能になる。統合を手動で配線する代わりに、開発者は既存のドキュメントやAPIから直接MCPサーバーを立ち上げ、AIエージェントがツールに即座にアクセスできるようにすることができる。これは定型作業に費やす時間を減らし、実際にツールを使用する時間を増やすことを意味する—リアルタイムコンテキストの取得、コマンドの実行、またはAIアシスタントの能力をその場で拡張するなど。

 新しい体験CursorのようなIDEは、MCPが技術的なユーザーに強く訴求するためほとんどの注目を集めているが、唯一利用可能なMCPクライアントではない。非技術的なユーザーにとって、Claude Desktopは優れたエントリーポイントとなり、MCP搭載ツールをより一般的なオーディエンスにとってアクセスしやすく、ユーザーフレンドリーにする。近い将来、顧客サポート、マーケティングコピーライティング、デザイン、画像編集などのビジネス中心のタスク向けの専門的なMCPクライアントが登場する可能性が高い。これらの分野はAIのパターン認識と創造的なタスクにおける強みと密接に一致している。
MCPクライアントのデザインとそれがサポートする特定の相互作用は、その機能の形成に重要な役割を果たす。例えば、チャットアプリケーションはベクターレンダリングキャンバスを含む可能性は低く、デザインツールはリモートマシン上でコードを実行する機能を提供する可能性は低い。最終的に、MCPクライアント体験が全体的なMCPユーザー体験を定義する — そして私たちはMCPクライアント体験に関してまだまだ多くのことを開発する余地がある。
これの一例は、HighlightがクライアントでMCPサーバーを呼び出すために@コマンドを実装した方法だ。結果として、MCPクライアントが生成されたコンテンツを任意の下流アプリに送る新しいUXパターンが生まれた。
もう一つの例はBlender MCPサーバーのユースケースだ：今では、Blenderをほとんど知らない素人ユーザーでも自然言語を使用して構築したいモデルを説明することができる。コミュニティがUnityやUnrealエンジンなどの他のツール用のサーバーを実装するにつれて、テキストから3Dへのワークフローがリアルタイムで展開されている。
サーバーとクライアントについて主に考えるが、プロトコルの進化とともにMCPエコシステムは徐々に形づくられている。このマーケットマップは今日最もアクティブな領域をカバーしているが、まだ多くの空白がある。MCPがまだ初期段階にあることを考えると、市場が発展・成熟するにつれてマップにより多くのプレーヤーを追加することが期待される。
MCPクライアント側では、今日見る高品質なクライアントのほとんどがコーディング中心だ。開発者は通常新しいテクノロジーの早期採用者であるため、これは驚くことではないが、プロトコルが成熟するにつれて、よりビジネス中心のクライアントが見られるようになるだろう。
私たちが見ているMCPサーバーのほとんどはローカルファーストで、シングルプレーヤーにフォーカスしている。これはMCPが現在SSEおよびコマンドベースの接続のみをサポートしていることの症状だ。しかし、エコシステムがリモートMCPを第一級にし、MCPがストリーム可能なHTTPトランスポートを採用するにつれて、より多くのMCPサーバーの採用が見られると予想される。
また、MCPサーバーの発見を可能にするMCPマーケットプレイスとサーバーホスティングソリューションの新しい波も登場している。MintlifyのmcptやSmithery、OpenToolsなどのマーケットプレイスは、開発者がMCPサーバーを発見、共有、貢献しやすくしている—JavaScriptのnpmがパッケージ管理を変革したり、RapidAPIがAPI発見を拡大したりしたのと同様だ。このレイヤーは高品質のMCPサーバーへのアクセスを標準化し、AIエージェントがオンデマンドでツールを動的に選択し統合できるようにするために重要になるだろう。
MCPの採用が拡大するにつれて、インフラストラクチャとツールはエコシステムをよりスケーラブル、信頼性が高く、アクセスしやすくするために重要な役割を果たす。Mintlify、Stainless、Speakeasyなどのサーバー生成ツールはMCP互換サービスの作成の摩擦を減らし、CloudflareやSmitheryなどのホスティングソリューションはデプロイメントとスケーリングの課題に対処している。同時に、Toolbaseのような接続管理プラットフォームがローカルファーストMCPのキー管理とプロキシをスムーズに流れさせ始めている。

 将来の可能性しかし、私たちはエージェントネイティブアーキテクチャの進化の初期段階にある。そして、今日MCPに対する多くの興奮があるが、MCPで構築し出荷する際に解決されていない多くの問題もある。
プロトコルの次のイテレーションで解決すべきいくつかの事項：

 ホスティングとマルチテナンシーMCPはAIエージェントとそのツール間の1対多の関係をサポートするが、マルチテナントアーキテクチャ（例：SaaS製品）は複数のユーザーが一度に共有MCPサーバーにアクセスする必要がある。デフォルトでリモートサーバーを持つことがMCPサーバーをよりアクセスしやすくする短期的な解決策になる可能性があるが、多くの企業は自社のMCPサーバーをホストし、データプレーンと制御プレーンを分離したいと思うだろう。
大規模なMCPサーバーのデプロイメントとメンテナンスをサポートする合理化されたツールチェーンが、より広範な採用を可能にする次のピースだ。

 認証MCPは現在、クライアントがサーバーで認証する方法の標準認証メカニズムを定義しておらず、MCPサーバーがサードパーティAPIと対話する際に認証を安全に管理し委任する方法のフレームワークも提供していない。認証は現在、個々の実装とデプロイメントシナリオに委ねられている。実際には、MCPの採用はこれまでのところ、明示的な認証が常に必要ではないローカル統合に集中しているようである。
より良い認証パラダイムは、リモートMCPの採用に関して大きな解放の一つになる可能性がある。開発者の観点からは、統一されたアプローチは以下をカバーするべきだ：
クライアント認証：クライアント-サーバー間の相互作用のためのOAuthやAPIトークンなどの標準メソッド
ツール認証：サードパーティAPIでの認証のためのヘルパー関数やラッパー
マルチユーザー認証：エンタープライズデプロイメント用のテナント認識認証

 認可ツールが認証されていても、誰がそれを使用でき、その権限はどれだけ詳細であるべきか？MCPには組み込みの権限モデルがないため、アクセス制御はセッションレベルだ—つまり、ツールはアクセス可能であるか完全に制限されているかのどちらかである。将来の認可メカニズムがより細かい制御を形作る可能性があるが、現在のアプローチは認証後にセッション全体のアクセスを付与するOAuth 2.1ベースの認可フローに依存している。これにより、より多くのエージェントとツールが導入されるにつれて複雑さが増加する—各エージェントは通常、固有の認可資格情報を持つ独自のセッションを必要とし、セッションベースのアクセス管理のウェブが拡大する。

 ゲートウェイMCPの採用が拡大するにつれて、ゲートウェイは認証、認可、トラフィック管理、ツール選択のための中央集中型レイヤーとして機能する可能性がある。APIゲートウェイと同様に、アクセス制御を強制し、適切なMCPサーバーにリクエストをルーティングし、負荷分散を処理し、効率を向上させるためにレスポンスをキャッシュする。これは特に、異なるユーザーとエージェントが個別の権限を必要とするマルチテナント環境で重要だ。標準化されたゲートウェイはクライアント-サーバーの相互作用を簡素化し、セキュリティを向上させ、より良い可観測性を提供し、MCPデプロイメントをよりスケーラブルで管理しやすくする。

 MCPサーバーの発見可能性と使いやすさ現在、MCPサーバーを見つけてセットアップすることは手動プロセスであり、開発者はエンドポイントまたはスクリプトを見つけ、認証を構成し、サーバーとクライアント間の互換性を確保する必要がある。新しいサーバーの統合は時間がかかり、AIエージェントは利用可能なサーバーを動的に発見したり適応したりすることができない。
しかし、先月のAIエンジニアカンファレンスでのAnthropicの講演に基づくと、MCPサーバーレジストリと発見プロトコルが登場しつつあるようだ。これによりMCPサーバーの採用の次のフェーズが解放される可能性がある。

 実行環境ほとんどのAIワークフローは複数のツール呼び出しを順序立てて必要とするが、MCPにはこれらのステップを管理するための組み込みワークフローの概念がない。すべてのクライアントに再開性と再試行性を実装することを求めるのは理想的ではない。今日では開発者がInngestのようなソリューションを探索してこれを機能させているが、ステートフル実行を第一級の概念に昇格させることで、ほとんどの開発者のための実行モデルが明確になるだろう。

 標準クライアント体験開発者コミュニティから頻繁に聞かれる質問は、MCPクライアントを構築する際にツール選択をどう考えるべきかということだ：誰もが自分のツール用のRAG（検索拡張生成）を実装する必要があるのか、それとも標準化されるのを待っているレイヤーがあるのか？
ツール選択を超えて、ツールを呼び出すための統一されたUI/UXパターンもない（スラッシュコマンドから純粋な自然言語まであらゆるものが見られている）。ツールの発見、ランキング、実行のための標準的なクライアント側レイヤーは、より予測可能な開発者とユーザー体験を作り出すのに役立つ可能性がある。

 デバッグMCPサーバーの開発者は、同じMCPサーバーをクライアント間で簡単に機能させることが難しいことをしばしば発見する。多くの場合、各MCPクライアントには独自の癖があり、クライアント側のトレースは見つからないか見つけるのが難しく、MCPサーバーのデバッグが非常に難しいタスクになる。世界がよりリモートファーストのMCPサーバーを構築し始めるにつれて、ローカルとリモート環境全体で開発体験をよりスムーズにするための新しいツールセットが必要だ。

 AIツールの意味MCPの開発体験は、2010年代のAPI開発を思い出させる。パラダイムは新しくエキサイティングだが、ツールチェーンはまだ初期段階だ。今から数年後、MCPがAI駆動のワークフローの事実上の標準になった場合、何が起こるだろうか？いくつかの予測：
開発者中心企業の競争優位性は進化するだろう：最高のAPIデザインを提供することから、エージェントが使用するためのツールの最高のコレクションも提供することへ。MCPがツールを自律的に発見する能力を持つようになれば、APIやSDKの提供者は、彼らのツールが検索から簡単に発見でき、特定のタスクのためにエージェントが選びたくなるほど差別化されていることを確認する必要がある。これは人間の開発者が探すものよりもはるかに細かく具体的になる可能性がある。
すべてのアプリがMCPクライアントになり、すべてのAPIがMCPサーバーになれば、新しい価格モデルが登場するかもしれない：エージェントはスピード、コスト、関連性の組み合わせに基づいて、ツールをより動的に選択するかもしれない。これにより、最も広く採用されているツールではなく、最もパフォーマンスが高く最もモジュラーなツールを選ぶ、よりマーケット主導のツール採用プロセスにつながる可能性がある。
ドキュメントはMCPインフラストラクチャの重要な部分になるだろう：企業は明確な機械可読フォーマット（例：llms.txt）でツールとAPIを設計し、既存のドキュメントに基づいてMCPサーバーを事実上のアーティファクトにする必要がある。
APIだけでは十分ではなくなるが、優れた出発点になる：開発者はAPIからツールへのマッピングがめったに1対1ではないことを発見するだろう。ツールはタスク実行時にエージェントにとって最も意味をなす高い抽象化だ—単にsend_email()を呼び出す代わりに、エージェントはレイテンシーを最小化するために複数のAPI呼び出しを含むdraft_email_and_send()関数を選ぶかもしれない。MCPサーバー設計はAPI中心ではなく、シナリオとユースケース中心になるだろう。
すべてのソフトウェアがデフォルトでMCPクライアントになれば、新しいホスティングモードが生まれるだろう：ワークロードの特性が従来のウェブサイトホスティングとは異なるからだ。すべてのクライアントは本質的にマルチステップであり、再開性、再試行、長時間実行タスク管理などの実行保証が必要だ。ホスティングプロバイダーは、コスト、レイテンシー、パフォーマンスを最適化するために異なるMCPサーバー間でリアルタイムの負荷分散も必要とし、AIエージェントが任意の時点で最も効率的なツールを選択できるようにする。

 結論MCPはすでにAIエージェントエコシステムを再形成しているが、次の進歩の波は基本的な課題をどのように解決するかによって定義されるだろう。適切に行われれば、MCPはAIとツールの相互作用のデフォルトインターフェースになり、自律的でマルチモーダル、そして深く統合されたAI体験の新世代を解き放つ可能性がある。
広く採用されれば、MCPはツールの構築、消費、収益化の方法を変化させる可能性がある。マーケットがこれらをどこに持っていくか興味深い動向だ。今年は重要な年となるだろう。
Discussion

ログインするとコメントできます