MCPの責任過多
よくある批判として、MCPには過剰な責任が課せられているという点が挙げられます。著者は、MCPは主にLLMが外部リソースにアクセスし、やり取りするためのゲートウェイとして機能すべきだと主張しています。単なる「入り口」や「橋」と見なすことで、その目的と限界が明確になります。
偶発的なデータ漏洩、プロンプトインジェクションの脆弱性、コスト管理の不備などの問題をMCPに直接帰することは、責任の所在を誤っています。これらは、開発者が制御可能な範囲内で対処すべき問題です。開発者は、使用するプロトコルに関係なく、レート制限を実装し、使用状況を監視する必要があります。これを速度違反を道路のせいにするのと同じだと考えるのは適切です。インフラストラクチャは個々の行動に責任を負いません。
結局のところ、提起された懸念の多くは、AIエージェントへのタスク委譲に関連するより広範な問題です。開発者は、API自体にすべてを処理させるのではなく、特定のアプリケーション内でこれらの課題を管理する責任を負わなければなりません。
LLMとプロンプトインジェクションの両刃の剣
MCPに関する最近の議論は、鋭利なナイフの本質的な危険性についての警告に似ていることがよくあります。扱いを誤ると切れてしまうからです。プロンプトインジェクションは重大な懸念事項ですが、LLM自体の性質の結果です。プロンプトインジェクションのリスクを排除しようとすると、LLMの価値を高めている能力が低下する可能性があります。
従来のシステムで一般的な「制御対データ」の分離は、LLMには自然には存在しません。LLMは、この厳格な分離がないからこそ、その力と汎用性を獲得します。この本質的な特性により、プロンプトインジェクション攻撃に対して脆弱になります。
リモートMCPがサービスとしてリスクをもたらす可能性はありますが、責任はプロトコル自体ではなく、機密性の高いタスクを信頼できない第三者に委託することにあります。この類推は、ナイフを不安定なルンバにダクトテープで貼り付けるという考え方にまで及びます。問題はナイフ自体ではなく、予測不可能なデバイスに取り付けるという決定です。
「注意してください」という訓戒や、保護具の提案は、技術的には正確ですが、根本的な問題を見逃しています。それは、鋭利なツールを制御されていないシステムと組み合わせるという不適切な決定です。
拡張性の課題
セキュリティ上の懸念を超えて、MCPは基本的な拡張性の制限に直面しています。著者は、LLMの信頼性と提供される指示コンテキストの量との間に負の相関関係があることを強調しています。これは、より多くのデータと統合を追加すると、問題が自動的に解決するという一般的な考え方に異議を唱えています。ツールと統合の数が増えるにつれて、エージェントのパフォーマンスが低下する一方で、各リクエストのコストが同時に増加する可能性があります。
著者は、MCPは特定のしきい値を超えて拡張できないことを強調しています。エージェントのコンテキストに無制限の数のツールを追加しようとすると、その機能に必然的に悪影響が及びます。この制限はMCPの概念に固有のものであり、認証の問題よりも注意が必要です。
ユーザーは、より多くのMCPサーバーを有効にすると、パフォーマンスの低下を経験する可能性があり、サーバー間で干渉が発生します。これは、非干渉が基本的な特性である典型的なパッケージ管理システムとは対照的です。
MCPの根本的な問題は、その実際の動作がユーザーの期待から逸脱していることです。MCPは、結果なしに無制限の数のツールをシームレスに統合するプラグアンドプレイソリューションではないことを認識することが重要です。
UIとツール管理による制限への対処
MCPの制限に対する提案された解決策の1つは、ユーザーインターフェイスを改善することです。ツールが意図せずに実行された場合、UIはそれを無効にするか、その意図された使用法を明確にするために説明を変更する簡単な方法を提供する必要があります。
著者はまた、コンテキストの成長はパフォーマンスの向上と実際の使用能力につながることが多く、厳密な負の相関関係という概念と矛盾していると指摘しています。ただし、特定のユースケースや不適切に設計されたコンテキストでは、パフォーマンスの低下が発生する可能性があることを認めています。
圧倒的なツールの選択に対処するために、「分割統治」アプローチが提案されています。これには、特定のタスクに最も関連性の高いツールを選択するために特別に設計されたツールを追加することが含まれます。この「ツール選択ツール」は、別のLLM呼び出しであり、利用可能なツールのサブセットを「親」エージェントに返すようにタスクが割り当てられます。この階層化されたアプローチにより、複雑さを管理するために追加のレベルの間接参照が追加されます。
ただし、コンテキストにツールを含めるだけで、モデルの出力が大幅に変わる可能性があります。（検索拡張生成またはRAGのようなテクニックを通じて達成された）文脈的に関連性のあるツールは有益ですが、すべてのツールを「get_tools」リクエストの背後に隠すと、有害になる可能性があります。
輸送および認証レイヤーとしてのMCP
MCPは主に輸送およびワイヤ形式として機能し、リクエスト/レスポンスライフサイクルを備え、ツールレベルの認証に焦点を当てています。エッセイでは、MCPの最大の問題は、AIエージェントがツールを機能的に構成できるようにできないことであると主張しています。
著者は、LLMはOpenAPI仕様を使用して文書化されたAPIとすでにやり取りできるため、MCPはそもそも不要である可能性があると仮定しています。不足している要素は認証です。つまり、AIがアクセスできるAPIを制御する機能です。MCPの代わりに、著者はAIがHTTPリクエストを行うことを許可しながら、特定のエンドポイントに認証を適用することを提案しています。このアプローチは、既存のAPIを薄いMCPツールでラップするという現在の傾向と一致しています。
MCPの特に煩わしい点は、ツール呼び出し結果のストリーミングをサポートしていないことです。単一のリクエスト/レスポンスペアにより、クライアントはページネーションのためにツールを繰り返し呼び出す必要があり、長期実行プロセスが妨げられます。おそらくgRPCを使用してストリーミング機能を実装することで、MCPの効率を大幅に向上させることができます。
機密データの公開の容易さ
MCPに関する重大な懸念は、機密データが簡単に公開される可能性があることです。さらに、MCPは本質的にAIエージェントの信頼性を高めるわけではありません。単により多くのツールへのアクセスを許可するだけであり、特定の状況ではパラドックス的に信頼性が低下する可能性があります。
著者は、MCPがこれらのすべての問題を解決したり、責任を負ったりすることを期待していません。むしろ、MCPはこれらの問題の表面積を大きくするため、アプリの開発者とユーザーは警戒する必要があります。
類推と都市計画
著者は、都市計画の類推を使用して問題を説明しています。MCPを制限速度が25mphの6車線の都市道路と比較すると、設計と意図された使用との間の乖離が強調されます。単に罰金を科したり、表面的な「修正」を追加したりするだけでは、設計不良という根本的な問題に対処できません。
効果的な都市計画には、自然に制限速度の遵守を促す道路の設計が含まれます。同様に、MCPは潜在的なリスクを本質的に軽減するように設計されるべきであり、外部制御のみに依存するべきではありません。
LLMによる不要なアクションの実行
この記事は、LLMがサービスに対してアクションを実行できるようにするプロトコルのより広範な批判に移行します。著者は、LLMがユーザーが意図しないアクションを実行する可能性があるという根本的な問題を特定しています。LLMが独立して実行できるアクションと、ユーザーのプロンプトを必要とするアクションを区別します。
最終的な目標はLLMにビジネス全体を管理させることかもしれませんが、この技術はそのような自律性に対応できるほど成熟していません。現在、ユーザーはAIが事前にレビューせずにメールを送信することさえ望んでいない可能性があります。
著者は、ユーザーに確認を求めるという解決策を拒否し、ほとんどのツールが無害に見える場合、ユーザーが自動確認（「YOLOモード」）のパターンに陥るリスクを挙げています。これは、人々が現金よりもカードでお金を多く使うという心理的な現象に似ています。テクノロジーではなく、人間の行動に根ざした問題です。
根本的な疑問：APIを直接使用しないのはなぜですか？
MCPに関する議論で繰り返し提起される質問は、APIを直接使用しないのはなぜかということです。
MCPを使用すると、ユーザーが直接制御しないLLMクライアント（たとえば、Claude、ChatGPT、Cursor、VSCode）がAPIとやり取りできます。MCPがない場合、開発者はLLM APIを使用してカスタムクライアントを構築する必要があります。これは、既存のクライアントをサブスクリプションで使用し、特定のツールの使用方法を教えるよりもはるかにコストのかかる作業です。
ある開発者は、USB経由でFMハードウェアシンセサイザーに接続するためにMCPサーバーを構築した経験を共有し、AI駆動のサウンドデザインを可能にしました。
LLMクライアントの統合と標準化
根本的な問題は、すべてのLLMクライアントがAPIの直接対話をネイティブにサポートしているわけではないことです。ChatGPTカスタムGPTアクションは注目すべき例外です。Anthropic、Google、およびOpenAIは、Claude、ChatGPT、CursorなどのLLM駆動クライアントのプロセスを合理化するために、共有プロトコルとしてMCPを採用することに合意しました。
MCPは、LLMクライアントを構築する人のプロセスを簡素化します。LLMにAPIとやり取りさせたい場合、APIキーを提供するだけでは機能しません。エージェントを作成する必要があります。
MCPは、APIを文書化し、その呼び出し方法を記述する方法と見なすことができます。また、そのドキュメントを公開し、呼び出しを容易にするための標準化されたツールも備えています。不要な複雑さを加えずにAPIをラップするのに十分な抽象化を提供しますが、この単純さがユーザーを「自分で撃つ」ことにつながる可能性もあります。
MCPの効率と再利用性
MCPがない場合、開発者はツールが呼び出されるたびに、LLMにツールの使用方法を繰り返し説明する必要があります。これには、情報が忘れられたり、APIの動作が標準から外れたりするために、LLMがツールを正しく使用できないというリスクが伴います。
この絶え間ない説明と重複により、コンテキスト内のトークンが無駄になり、コストと時間がかかります。MCPは、必要なすべての情報をバンドルすることでこのプロセスを合理化し、ツールの使用効率を高め、ツールの共有を容易にします。
APIドキュメントとともに「これは使用できるツールです」とLLMプロバイダーに伝えることで、ユーザーは繰り返しリマインダーなしに、複数のチャットでそのツールを再利用できます。これにより、デスクトップLLMクライアントはローカルで実行されているプログラムに接続することもでき、OS固有の実行プロセスに関する問題に対処できます。
MCPとローカルリソースアクセス
MCPは、LLMのファイル、環境変数、ネットワークアクセスなどのローカルリソースへのアクセスを容易にします。ローカルで実行するように設計されており、LLMにこれらのリソースへの制御されたアクセスを許可します。
標準のLLMツール呼び出し「形状」は、MCPツール呼び出し「形状」を密接に反映しており、ツールをエージェントに接続するための簡単な標準になっています。
MCPは、AIモデルに公開されている関数呼び出しスキーマと、基盤となるAPIの間のブリッジとして機能します。関数呼び出しをツールに変換し、シームレスな通信を可能にします。
ツールプロバイダーの場合、MCPはAIエージェントフロントエンドがツールに接続するための標準化されたプロトコルを提供します。これは、標準プロトコルがHTTPとOpenAPIにすぎない理由という質問に答えます。
MCPは、エンドポイントとそれらの運用上の詳細を仕様に組み込んだメタAPIであり、LLMがより効果的にやり取りできるようにします。
特定のシナリオでのMCP
MCPは、ユーザーが質問したり、どのアラームを使用するかがわからない場合に問題を解決できます。また、以前のメッセージに基づいてリクエストを処理することもできます。
あるユーザーは、ユーザーの「X」を取得してエンドポイントに送信したいという経験を共有しました。彼らはMCPがそのような単純なタスクには過剰であると感じ、基本的なAPIインタラクションには必ずしも必要ではないことを示しました。
MCPは、ネットワーク上で通信できるソフトウェアを構築するためのFastAPI Webアプリケーションフレームワークに似ており、特にエージェントエクスペリエンス向けに設計されています。AIエージェント開発のための標準化されたフレームワークを提供する「Rails-for-Skynet」と見なすことができます。
プロバイダー制御に関する懸念
MCPがシステムに対するプロバイダー側の制御を高めるために推進されているという懸念があります。LLMプロバイダーは、GoogleがGmailでIMAP/SMTPの使用を困難にしたのと同様に、最終的にAPIアクセスを制限する可能性があります。
OpenAPIを使用すると、エージェントは/openapi.jsonからAPI仕様を取得できます。
MCPは迅速なやり取りを可能にし、ユーザーは入力データの準備、APIへの送信、出力の解析、メッセージごとにプロセスの繰り返しに時間を費やすことなく、数秒でタスクを完了できます。
サンドボックス化とセキュリティリスク
最大の問題の1つは、1つのMCPサーバーツールの出力が同じメッセージスレッド内の他のツールにどのように影響するかです。これには、意図しない結果を防ぐために、ツール間のサンドボックス化が必要です。Invariant Labsはツール記述でこれに対処しましたが、他のツールはMCPリソースアタッチメントを使用しました。サンドボックス化の欠如は、プロンプトインジェクションのリスクを悪化させます。
これはSQLインジェクションに似ています。脆弱性が最小限の可観測性でいつでも悪用される可能性がある、寄せ集めのシステムです。
プロンプトインターフェイスは、モデルがプロンプトの信頼できる部分をユーザーが汚染した入力から区別できないため、SQLインジェクションの形式にも影響を受けやすくなっています。これを解決するには、エンコード、デコード、およびモデルトレーニングに根本的な変更が必要です。
これにより、プロンプトインジェクションとツールインジェクションの両方が可能になり、信頼できないコードの実行につながる可能性があります。
コンテナ化と制御されたアクセス
ある開発者は、プロジェクトコードがマウントされたDockerコンテナを起動するMCPサーバーを作成しました。このアプローチにより、LLMはサンドボックス化された環境内でUnixツールセット全体とプロジェクト固有のツールにアクセスできます。
チャットベースのインターフェイスを通じて駆動されるこのエージェントワークフローは、従来の方法よりも効果的であることが証明されています。
重要なのは、MCPエージェントに必要なものだけへのアクセスを許可することです。コンテナ化と透過的なツールUXは、セキュリティリスクを軽減するために非常に重要です。
仮想マシンとインターネットアクセス
エージェントに最小限のLinuxインストール（VMまたはコンテナとして）を備えたコンピューターを提供すると、より良い結果が得られ、インターネットから情報を取得できるようになります。ただし、これは悪意のある指示やデータ流出に関するセキュリティ上の懸念を高めます。
信頼できるWebサイトへのアクセスを制限すると、一部のリスクを軽減できますが、信頼できるソースでも悪意のあるコンテンツをホストする可能性があります。悪意のある指示に遭遇する可能性と、生産性の向上とのトレードオフを慎重に検討する必要があります。
従業員とAIエージェントの違いは大きいです。従業員は法律および契約の対象となる法人であり、説明責任を提供します。AIエージェントにはこの法的枠組みがないため、信頼がより困難になります。
MCP開発の初期段階
MCPは2024年11月に発表されたばかりで、RFCは積極的に進化しています。
一部の人々は、MCPを含むAIパーソナルアシスタントの概念全体が根本的に欠陥があると見なしています。
1990年代後半から2000年代初頭のAIアシスタントへの最初のプッシュは、垂直統合と大量購買力を持つコンテンツアグリゲーターの方が効果的であることが証明されたため、失敗しました。これにより、ExpediaやeBayなどのプラットフォームが台頭しました。
マルチエージェントシステムでは、プログラマーがエージェントの状態に影響を与える必要があり、これは困難なプログラミングタスクです。
無料の価値の限界
「駐車場可用性で結果をランク付けする」という要望は、有料APIまたは広告サポート付きフロントエンドの背後にあるデータにアクセスするという問題を強調しています。企業は、APIを介してデータセット全体へのアクセスを無料で提供する可能性は低いです。
すべての企業がデータをAIエージェントに統合するわけではありませんが、さまざまなツールを組み合わせてワークフローを強化する可能性は依然として大きいです。
データの堀を維持することを優先する企業は、その堀を脅かす新しい技術に抵抗する可能性があります。
booking.comにAPIがある場合、Webサイトと同じ結果を返す可能性があり、JSONまたはXML形式で表示される可能性があります。
中間業者をバイパスする
booking.comのような中間業者が、ユーザーがサービスを完全にバイパスできるようにするのは意味がありません。
ただし、個々のホテルは、booking.comをバイパスする方が有益であると考えるかもしれません。これは、多くの場合嫌いな中間業者です。
Deep Research AIは、特定の基準に基づいてホテルをスキャンし、個々のホテルが実行するHotel Discovery MCPサーバーとやり取りし、booking.comのインターフェイスと広告をナビゲートする必要を回避できます。
実用的なユースケース
MCPは、Elasticsearchからログを取得したり、データベースをより構造化された方法でクエリしたりするなどのタスクを容易にすることができます。
新しいサーバーで.jsonファイルを編集してアプリを再起動する必要があるMCPサーバー構成の静的な性質は、制限される可能性があります。
微調整されたモデル
MCPは、多数のMCPツールを理解し、会話ごとに適切なツールを選択する、小さくて微調整されたモデルと見なすことができます。
状況に応じてツールを動的に調整する必要があるシナリオもあります。
オープンエンドの会話とビジネス上の問題
MCPは、定義済みのフローがない、一般的でオープンエンドの会話システムに適しています。ただし、すべてのビジネス上の問題に対応できる万能のソリューションではありません。LangChainのようなフレームワークを置き換えることを意図したものではありません。
MCPに代わるオープンなコミュニティ主導の標準は、断片化され、独自の技術であり、ベンダーロックインされたプロトコルです。欠陥はあるものの進化する標準は、標準がないよりも好ましいです。
MCPを表示する最良の方法は、個々の開発者がAPIの周りにクライアントラッパーを構築することから、APIプロバイダーまたはコミュニティが維持するラッパーを構築することへの移行です。これにより、NPMまたはPyPiと同様の大きなツールボックスが提供されます。ただし、オーケストレーション、セキュリティ、および使用状況の定義は依然として必要です。
次世代のLangchainsはこの大規模なツールチェストからメリットを得られますが、イノベーションは依然として必要です。
ユーザー固有のツール
場合によっては、アップロードされたCSVファイルをスライスして操作するためのツールなど、ツールがユーザーデータに固有である場合があります。
見落とされがちな問題の1つは、MCPがモデルコンテキストに多くのオプションを詰め込みすぎる可能性があることです。無駄なトークンの使用と不安定なモデルの動作を回避するには、優先順位付けとメタデータの公開が非常に重要です。
標準と進化するテクノロジー
新しい標準は時間の経過とともに登場し、標準が本当に重要になってから時間が経っているため、人々はその開発方法を忘れてしまっています。
ランダムな開発者から小さなサーバープログラムをダウンロードして、LLMクライアントに「ツール」を追加することは危険な場合があります。
提起された問題は、MCPエコシステムが対処する必要のある正当な問題です。一部のソリューションはMCP仕様内にあり、他のソリューションは外部にあります。
Claudeコードと実際の使用状況
MCPの成功については相反する意見があります。一部の人々は、MCPと統合している企業の物語を聞いたことがありますが、他の人々は、それが期待外れだったと感じたユーザーから聞いたことがあります。
これは、誇大広告と早期採用の欠点を浮き彫りにしています。
一部の開発者は、ほとんどのユースケースでHTTP APIの方がMCPよりも優れていると考えています。彼らは、「ツール」の使用は機能と機能のAPIエンドポイントに要約されると主張しています。
APIはデフォルトでは自己記述型ではなく、RESTおよびHATEOAS支持者がアプローチを紹介する機会を逃しています。
LangChainの代替としてのMCP？
MCPは、「LangChainの臭い」がある、つまり、差し迫った問題を解決しない、過度に抽象的である、その利点を説明するのが難しいと説明されています。
おそらく、それは「END OF LINE」と言って、ハッカー志望者をゲームグリッドに追放する必要があります。
重要な質問は、「一般的な」チャットボットパラダイムが存続するかどうかです。独自のツールを備えた専門的なアプリは、MCPを必要としない可能性があります。
逆に、LLMの能力が向上するにつれて、外部ツールは必要なくなる可能性があります。LLMが画像を直接編集できるのに、なぜPhotoshopを駆動するMCPが必要なのでしょうか。
SFのロボットアシスタントの夢は実現しない可能性があり、特殊な言語操作ツールの方が役立つ可能性があります。
ユーザーベースとセキュリティ意識
MCPのユーザーベースには、技術力の低い個人が含まれており、セキュリティの問題が特に関連しています。セキュリティのベストプラクティスに関する認識を高めることが非常に重要です。
結果スキーマの定義が必要なOpenRPCに基づいてXopsを構築すると、出力が入力にどのように接続されるかを計画するのに役立ち、複雑なワークフローの信頼性が向上します。
このテクノロジーは進化し、時間の経過とともに落ち着く可能性が高いです。
冗長性とクラウドインフラストラクチャ
OpenAPI標準よりもMCPを使用することの利点に疑問を抱き、冗長であると見なす人もいます。
LLMはOpenAPIシステムを呼び出すために何を使用しますか？どのようにシェルにバインドしますか？LLMのホストはそれをどのように調整しますか？
MCPは、LLMがツール呼び出しを行うための構造化された方法を提供します。
MCPサーバーはすでにHTTPサーバーです。
MCPの最大の利点は、アプリケーション開発者ではなく、OpenAIのようなLLMプロバイダーにあります。
LLMはツールなしの頭脳であり、ツール呼び出しはそれらを強化します。ただし、通常のAPIでは、LLMプロバイダーはこれらのツールにアクセスできません。MCPはそれらにアクセス権を付与し、それらをAIへのゲートウェイとして位置付けます。
CLI対API
LLMは自然言語でトレーニングされており、CLIは人間が読み書きできる一般的なソリューションであることを考えると、CLIを直接使用しないのはなぜですか？
MCPはあまりにも急速に出現し、成熟する時間が必要です。従来の標準化機関による精査がなく、誇大広告によって推進されています。
実際のアプリケーションが不足しています。
MCPの主なアプリケーション
MCPは、Claude DesktopおよびニッチなAIチャットアプリ、コード自動化ツール、およびエージェント/LLM自動化フレームワークで使用されています。
これは、次の誇大宣伝可能な頭字語が登場すると破棄される可能性が高い、もう1つの急ぎ足のテクノロジーです。
言語モデルツール呼び出しプロトコルには、人々が不満を言うものと、誰も使用しないものの2種類があります。
Anthropicは、この「標準」を真空状態で開発し、セキュリティ上の問題につながりました。
JSON-RPC 2.0
MCPは、JSONを使用してクライアントとサーバーの通信を可能にする軽量プロトコルであるJSON-RPC 2.0に基づいて構築されています。
普遍性を主張するが、それを得ることなく、特定の生態系向けに設計された集中型仕様のように感じられます。
MCPは、役立つことをするのに十分強力であり、セキュリティ上の懸念を高めます。
成熟した標準ではなく、安全になるように設計されていませんでした。
推奨事項はありますが、強制または実装されていません。
Langchainとツール呼び出し
Langchainは、「ツール呼び出し」パターンを実装する多くのフレームワークの1つです。
MCPは、ツール呼び出し、テンプレート化された入力、キャンセル、進捗状況の追跡、およびツールサーバーのステートフルなど、外部情報が言語モデルのコンテキストウィンドウに入る方法の仕様です。
詳細を標準化して、すべてのアシスタント/統合の組み合わせが互換性を持つようにするのに役立ちます。
MCPには正当な問題がありますが、批評家は議論を洗練させる必要があります。
認証は非常に重要であり、初期バージョンから省略すべきではありませんでした。
複雑すぎる点が多くあります。