この動画では、Salesforce AIが発表したMCP Universe benchmarkについて詳しく解説されている。モデルコンテクストプロトコル（MCP）を使用したエージェントAIシステムの実際のパフォーマンスを、GPT-5やClaude 4.0 Sonnetなどの最新LLMで測定した結果、最高性能のGPT-5でさえ成功率が43.7%に留まることが明らかになった。この研究は、現在のAIエージェントシステムが複雑なリアルワールドタスクにおいて重大な性能制限を抱えていることを示している。
MCPの夢と現実
こんにちは、コミュニティの皆さん。今日はMCPの世界に飛び込んでいこうやないか。今日は全く新しい研究があるんや。でもな、全ては夢から始まったんや。
俺らは約束されたんや。「想像してみいや、どこの会社が作ったんでも、どんなに小さくても、すべてのAIモデルがあらゆるツールに、あらゆるAPIコールに、あらゆるデータソースにシームレスに接続できる世界を」ってな。
これはまさに、どんなUSB-CデバイスでもどんなUSB-Cポートにも差し込めるみたいなもんや。これがもちろん、今日のエージェントAIシステムの主要な通信レイヤーであるモデルコンテクストプロトコル（MCP）やったんや。
そんで、ある会社が言うたんや。「おい、でも実際に俺らの洗練された視覚言語モデルがこの新しいユニバーサルプラグを使うのが上手いかどうか、本当に分かってるんか？」てな。確かに各会社のマーケティング資料はあるけど、ほんまに現実世界のツールの複雑さをナビゲートできるんか、それとも単に事前定義された単純な学術テストに最適化されてるだけで、すべての評価者に知られてるような問題なんかって話やな。
複雑なタスクの例
ほんで、俺が見せたい例がここにあるんや。長くて複数ステップの使用例で、いくつかのサーバーコール、MCPクライアント・サーバーコール、数値比較なんかがある。そや、PythonやC++を使って二つの数値を組み合わせなあかんかもしれんな。簡単や。
あんたがレストランにいるとしよう。中間点タスクっちゅうやつや。あんたがここのホテルの一つに住んでて、同僚が別のホテルにいるとする。そんで単純に「おい、俺らのホテルからの運転時間が最小になるレストランを見つけて、評価が4.2以上のレストランを見つけてくれ」って言うんや。簡単やろ？
いや、エージェントシーケンスはもちろんこうなる。ホテルの住所があるか、ジオコードがある。ええな。中間点周辺の場所を検索して、それぞれの候補に対してここで距離マトリックスを実行する。ホテルの正確な位置からの運転時間を出すんや。そんで絶対時間差を計算して、この円の中のすべてのレストランの評価でフィルタリングを完了する。
そんで、名前とプレイスID、選択されたレストランを返すんや。そや、それだけや。予約する必要もないんや。「おい、中間地点にレストラン見つけたで」って返すだけや。これは最高やな。
研究の実施
これがまさに今日の論文の著者らがやったことなんや。彼らは「おい、俺はドバイのどこかのシェラトンに住んでる。同僚もいる」って言うて、全く同じタスクをやったんや。
そんでエージェントがあって、複数のエージェントでGPT-4oだけでなく、GPT-5も使ったんや。これが興味深いとこやけど、まずはここに留まろう。彼らにはたくさんのMCPサーバーがある。ええな。そんで「おい、レストラン見つけて」って言うんや。分かったな。
同じプロセスがある。いや、ジオコーディング用のMCPコードがここにある。そんで、AIシステムが呼び出した両方のホテルの座標がここにあるんや。そんで「おい、ええな。中間点で評価のついたいくつかのレストランを見つけた」って言う。そんで距離を正確に計算するんや。
二つのセットがあって、交点がどこかすぐに分かって、答えが出る。答えはここの特定のレストランで、GoogleマップとMCPサーバーで場所を特定できるんや。ええな。簡単や。複雑なことは何もない。「この波動関数を崩壊させろ」なんて計算することもない。いや、これは可能な限り簡単なんや。
既存ベンチマークの問題
今日の論文の著者らは言うたんや。「おい、分かったで。俺らが発見したんは、LLMエージェントの既存ベンチマークが、マルチターンの複雑さに対して不十分やってことや。単一のエージェントコールがあるのはええけど、これは現実ちゃうで。」
そんで彼らは言うた。「おい、俺らがLLMとエージェント、エージェント、MCP、相互接続で見つけた既存ベンチマークは、あまりにも単純すぎることが多いんや。単一のスキルを分離することに焦点を当ててるだけや。非現実的や。現実世界とは全然違うシミュレーション環境を使ってるし、評価が不十分や。なんでかって？一つのLLMがタスクの複雑さ全体の審判として機能してて、これが本当に正しい評価なんかどうか全然分からんねん。」
Salesforce AIの新しいベンチマーク
ここでSalesforce AI、これが今日の論文や。2025年8月21日、8月の日や。これが俺がこの動画を録画してる今日なんやけど、彼らはベンチマーク、MCP Universeベンチマークを構築して、実世界のマイルコンテクストプロトコルサービスでLLMをベンチマークしたんや。
彼らは言うた。「ええな、理論テストはいいけど、俺は現実世界に住んでるんや。現実世界のサーバーでの実際のパフォーマンスデータが必要や」って。そんで実世界のMCPサーバーに接続して、133個のツールでテストしたんや。彼らは「ええな、6つのコアドメインにわたって103の異なるツール」って言うたんや。
ここにあんたが見るドメインがあるんやけど、これは本当に普通のユーザーとして使えるもんや。Googleマップのメールサーバー、オーダーやイシュー、プルリクエストを管理するGitHub MCPサーバー、ファイナンスMCPサーバー。一番簡単なYahoo、もうな。
コンピューターの何かをやりたかったら、デザイン、多分Blenderやけど、これを使う必要はない。ブラウザーオートメーション用には、Playwright MCPで行こう。ウェブ検索用には、何やと思う？GoogleサーチとフェッチMCPサーバーがあるんや。絶対に標準的なMCPサーバーや。
複雑なタスクの定義
俺は言うた。「分かった、俺らのベンチマークに231のタスクを定義するで。でもこれらは特別なタスクや。挑戦的なタスクや。これは一回のコールだけやない。いや、タスクが含まれるなら、本当に複雑でなあかん。」
LLMはツール使用なしでは解決できへん。LLMはその内部知識に依存してはあかん。LLMは「よし、外の世界に出て行かなあかん。このデータを見つけなあかん。ツールを使わなあかん」って言わなあかん。
そうでなかったら、LLMは単に内部の知識を使って、ツール使用を評価することは決して起こらん。挑戦的なタスクや。なんて美しくて素晴らしいアイデアやろう。なんで今まで誰もこれをやらんかったんや？そや、推測や。
MCP Universeの構造
ここにMCP Universeと評価フレームワークの完全な構造がある。これはまさに俺らが話してることや。ホテルの例のようなユーザー指示がある。
そんで彼らは「分かった、俺らは今、使用するLLMを切り替えることができる設定を構築する」って言うた。GPT-4o、Claude 4.0ここ、GPT-5、そんでエージェントビルダーがある。一番簡単なのでいこう、リアクトかexplore reactか、カーソルでいこか、他の企業で作られたやつでいこか。そや、これは重要や。これは無料やない。企業グレードのソフトウェアでいく。だから「そや、これは動いてる」って確信できる。MCP、分かったな。MCP、何が欲しいか選択する。ええな。そんで最終状態があって、これを評価するんや。
評価方法
評価については、彼らは「俺らはAIシステムがAIシステムやMCPを評価することを信頼せん」って言うた。だから「分かった、最初に3つの評価者、専用評価者を持つ。俺らは単一LLM審判パラダイムを拒否する。なんでかって、もうな、洗練された実行ベース評価者のスイートが欲しいねん」って言うたんや。
だから彼らはフォーマット評価者から始める。一番簡単やない。「必要なJSON構造が本当にそこにあるんか？」驚くことに、彼らは多くのモデルがここでさえ苦戦してるのを発見した。この単純なベンチマークで。
そんで「よし、これを時不変答に使おう」って言う。「おい、いつワーテルローの戦いがあったか」みたいな。いや、この日付は変わらん。これはどこかのインターネットサーバー、ウィキペディアに保存されてる時不変の数値や。分かるやろ。だから何も変わることはない。これはユニークな識別子や。
そんでダイナミック評価者に行こう。今、面白くなってきた。これがゲームチェンジャーや。彼らは「分かった、評価時にリアルタイムの正解を取得するためにコードを実行しなあかん」って言う。特定の瞬間の特定の株価を探してるとか、分かるやろ。
発見された問題
俺が見せたい多くの問題の一つだけを示すで。彼らは「MCPクライアント・サーバーアーキテクチャがあって、すべてが正常に動作するはずなのに、なんでこんな問題があるんや？すごいな、俺らがまだこんな問題を抱えてるなんて」って言うた。
なんでこんな問題があるんや？いや、彼らは言語モデルがMCPサーバーによって提供されるツールを正しく使うのにしばしば苦戦してるのを発見したんや。これがどうやって可能なんや？
彼らが提供する簡単な例がここにある。人間ユーザーがいて「おい、これを探してる。これを俺のためにやってくれ」って言う。そんで簡単にできるはずやのに、いや、ユーザーが「おい、2023年12月1日」って言うと、エージェントがそれについて考えて、JSONで定義する。そんでサーバーが「開始と終了が同じやから何が欲しいか分からん」って返すんや。
そんで、また古い古い古い古典的な問題がある。リトリーバーストック価格は開始日と終了日の指定が必要で、それらが異なってなあかんのに、LLMは頻繁にそれらを同一に設定して、実行エラーにつながるんや。2025年8月のエージェントシステムで、どうやってこんなことが可能なんや？
エクスプロレーション段階の解決策
俺らは再びMCPクライアント・サーバープロトコルでこんなシステムに遭遇してる。コミュニケーションが取れてない。理解してない。そんで分かるやろ、そのアイデア。
だから彼らは「分かった、俺らはこれに解決策がある。解決策があるで」って言う。追加のステップがある。エクスプロレーション段階って呼んでる。彼らは「聞いてくれ、俺らのLLMは賢いんや。GPT-5や、すごいな。サムが言うたPhDレベルを解決できるんや。問題ない。時間を与えるで」って言う。
だからLLMは今、仕事を得る前に、MCPサービスによって提供されるツールと自由に対話できるんや。LLMは遊ぶことができる。プロトタイプを送って「おい、何が返ってくるか見てみよう。探索してみよう。何か制限はあるんか？」って言える。
これによってLLMは、ツールの使い方を学び、動作方法を学び、能力の知識を構築する機会が得られるんや。あんたは人間として、「LLMに時間を与える。俺はこれに金を払う。高度に知能的で、うまくいけばMCPサーバーとの対話方法を理解するLLMが欲しいだけや」って言うやろ。
でも、彼らはこれをツールプロービングとも呼んでる。「そや、LLMはしばしばすべてのパラメータ制約の明示的な知識を欠いてるから」って言う。そんで解決策は簡単や。「いや、エージェントがMCPサービスにいくつかのプローブを発行して、ツールを発見し、レスポンスをサンプリングし、一般的なエラーモードを検出し、完璧な解決策を見つける自由探索状態があるだけや。」
エクスプロレーション結果
そんで彼らは以下を発見した。ここでローカルナビゲーションMCPサーバープロトコルで、GPT-4oのエクスプロレーションなし（青い方）とエクスプロレーションありを見ると、これは素晴らしく動く。そや、ええな。これを見てみいや。
でもファイナンシャル分析タスクでは違いがない。「おい、ファイナンシャル分析してみよう。」そや、ここでは役に立つ。Sonnet 4.0ゼロは本当にエクスプロレーションで、パイプラインの実際の仕事の前にこのツールをテストできるんや。だから遊ぶことができて、この特定のMCPの理解を最適化できる。
でも、ブラウザーオートメーションの結果をここで見てみいや。4.0でエクスプロレーションありが非エクスプロレーション段階を下回ってる。どうやってこんなことが可能なんや？
だから彼らは「信じられん。分かったで、俺らが発見したことは？発展する一貫した構造がないってことや。時々動く。時々何も起こらん。時々エクスプロレーション段階をやったらパフォーマンスを失うことさえある。ええな」って言うた。
全体的なパフォーマンス結果
よし、シートベルトを締める時やと思う。別のMCP結果を見せたる。彼らは「6つのベンチマークドメインで4時間。これが全体的な結果や」って言う。
位置情報で45タスク。パフォーマンス合計19.5%や。ウェブ検索で、MCPは23.8%を達成。ブラウザーオートメーションで、MCPですべて16%。これを言わせてもらえるか？39タスクで16.9%。リポジトリ、GitHubの何でも14%。今日俺らがどこにいるか感じが掴めるやろ。
「そや、でもめちゃくちゃ複雑なタスクやろ？」って言うかもしれんな。いや、見てみいや。これはブラウザーオートメーションタスクや。これはリポジトリ管理タスクで、これはファイナンシャル分析タスクや。2つの連続する四半期がある。AIにとってのこの複雑さを想像してみいや。
詳細なLLM MCP パフォーマンス
よし、でも今やろう。詳細なLLM MCPパフォーマンスデータを見よう。「そや、でも特定のLLM、OpusやGPT-5、ここでオープンソースLLMはどうや？MCPはどうや？企業で作られたCourseraエージェントはどうや？reactはどうや？他のフレームワークはどうや？どうやって対話するんや？」って言うかもしれん。
組み合わせの美しさがあるんや。全体の仕事で最高のLLMを教えたる。それはGPT-5やった。GPT-5は他のすべてのLLMをそれらのタスクで総合的に上回った。
だから全体的な成功率は、何やと思う？タスクを見たら推測できたやろう。簡単やもん。これは複雑なことは何もない。背景に物理的な世界モデルを持つ必要もない。いや、これは単に算術で、多分整数を引くだけや。
だからもうな。80-90%の成功率やろ？現実を知ってるか？43.7や。ここで見てみいや。これが今、位置情報、リポジトリ、国民分析、ブラウザー、ウェブ検索のためのもんや。そんでここで最終的な全体成功率の割合がある。この美しいロックされた黄色のDisappropriatorモデルでここで見てみいや。
何やと思う？GPT-5全体成功率43.7%。Grok 4ちょうど3分の1。そんでSonnet 4、o3、o4 mini、Gemini 2.5 Proで30%以下に下がってく。どうやってこんなことが可能なんや？22%や。
特定のカテゴリーを見て理解してみいや。ファイナンシャル分析50%。うわ。そや、でも他を見てみいや。だから「興味深いな」って言える。これはLLMを使う場合の指標を与えてくれる。どのMCPを使うかについては後で来るけど、エージェントAI用にLLMを使うなら、これは非常に良いベンチマークを教えてくれる。
GPT-4 Omniとオープンソースモデル
俺の視聴者の多くが「おい、俺はまだGPT-4 Omniを使ってる」って言うのを知ってる。本当にGPT-4 Omniのパフォーマンス15%を見てみいや。最初のオープンソース、オープンウェイトモデルGLM 4.5が、画面の最後の行で見えるように、ここでほぼ25%を達成してるのを知ってるか？
俺の視聴者のかなり多くが「おい、俺はGPT-4 Omniにこだわる」って言うのを知ってる。エージェントタスクにはやめとけ。正直言って、適切なLLMを選ぶだけでパフォーマンスの違いを見てみいや。
そんでオープンソース、オープンMCP Universeを見てみよう。そや、GLM 4.5、ええな24、19、Qwen 3、Qwen Coda、Kim K2、ええけど、そんでDeepSeek、これは新しい3.1やない、3か月前の古いバージョン3や14、もうええ加減にしてくれや。
そんで俺らはOpenAIのオープンソースモデルに来る。サムがユニークな偉大さの行為で古いものに寄付したOpenAI。そんで120B、1200億の自由に訓練可能なパラメータ、非量子化バージョンを見る。
パフォーマンスを見てみいや。これが何を意味するか分かるか？MCPで最良のケースでも11%のパフォーマンスしかない。敵対的攻撃はない。外部環境からの問題は全くない。これが達成できる最良のケースや。データを見てみいや。
だから11%のパフォーマンスでMCPツール用に最適化されたオープンワイドオープンウェイトOpenAI GPT 100b非量子化クラウドを使うべきかって？考えてみいや。
パフォーマンスの公式化
だから公式化してみよう。現在、俺らのAI、エージェントAIシステムにはいくつかの重大なパフォーマンス制限がある。最高の全体パフォーマンスはGPT-5の43.7%、Grok 4ちょうど33.3%、そんでClaude Sonnet 4でMCPでの成功率30%以下になって下がってくんや。
そんで彼らは「分かった、今反対側を見よう」って言うた。これはLLMやけど、Atlanticフレームワークはどうや？今、さまざまなエージェントがたくさんある。エージェントの構築方法やけど、無料版にいかへん。月20ドル版にもいかへん。月200ドル版にもいかへん。企業グレードレベルサービスエージェントフレームワーク比較にいこう。
Cursorエージェントの結果
彼らはCursorエージェントを使った。俺はこの企業版の経験がない。だから論文の結果を教えるだけや。彼らは「よし、統合MCP付きCursorがあって、製品を強化するために素晴らしい」って言うた。そんでSonnet 4.0バックボーン上に構築されたCursorエージェントを取って、ここで直接評価して、さまざまな組み合わせでエージェントアーキテクチャのエージェントフレームワークでのパフォーマンスを実行した。
でも再び与えるために、フレームワークがあって、位置ナビゲーション、リポジトリ、ファイナンス、設計、ブラウザーの自動化、ウェブ検索。だからまた他のカテゴリー。そんでClaude 4.0 Sonnetバックボーンかo3バックボーンのどちらかがある。
彼らは、Cursorエージェント企業創作版を比較すると言うた。だからこれは特別なもんで、すべてのカテゴリーで結果が無料で持ってる最もシンプルなreactフレームワークを下回ってるんや。
これは本当にすごかった。Cursorにお金を払ってたのを覚えてるし、無料のものより良いパフォーマンスが得られると確信してたんや。だから学ばなあかん。
そんで彼らは「分かった、今、一つのグローバル企業のLLMと同じ同一のグローバル企業のエージェントフレームワークを組み合わせたら、改善があるんか、それとも俺らはクロス互換性があるんか？」って理解したかったって言うた。
そんで彼らはo3バックボーンで再びreactを見た。だからここで違いを見てみいや。Claude 4.0 Sonnetでreact 29.44%。そんでo3でreact。o3は今GPT-5でもう存在しないかもしれん。でもテストをやった時はまだそこにあった。だから26。Claude 4.0より少し少ない。
そんで「でもOpenAIモデルをOpenAIエージェントフレームワークと組み合わせたら何が起こるんか？」って言うた。何やと思う？31.6%に跳ね上がった。これは驚きか？そんなことない。いや、これは彼らが使うLLMとエージェントフレームワークの共進化やから。
2025年8月のエージェントAI
これは俺らのエージェントAIすべてが、2025年8月末、つまり俺にとって今日は、最高でも30%にあるってことを意味する。2つを除いてすべて大幅に下回ってる。それはGPT-5とGrok 4や。Grok 4で33%。残りはこれを下回ってる。
これは最高で、数千億の自由に訓練可能なパラメータモデル、多分1兆近くの自由に訓練可能なパラメータモデルが来るかもしれん状況で、非量子化、フル精度、クラウドバージョン、地球上のデータセンターで動作するデータセンターモデルを使って、ここでほぼすべてが30%を下回ることを意味する。
これが2025年8月のエージェントAIのパフォーマンスデータや。そんで俺は想像した。俺のローカルPCで、他の同僚より少しいいPCを持ってることを既に誇りに思ってて、ローカルPCで量子化されたLLMバージョンを使う。4ビットバージョンにまで下げて、そのLLMでエージェントパフォーマンスのためのMCPクライアント・サーバーを持とうとする。外部データストリームに接続したいからや。
だからエージェントや複数エージェントを構築して、何やと思う？そんときのパフォーマンスは？分からんけど、Salesforceがここでコードを公開するから、俺のローカルPCで4ビット量子化LLMを実行して、結果を教えたる。せめて一桁の結果であることを期待してる。いや、0.8%やないけど、せめて2%か3%であることを。分からんけどな。
現状への失望と洞察
俺はちょっと失望してるけど、このベンチマークデータがあるのは素晴らしいと思う。今日MCPで俺らがどこにいるかのアイデアを与えてくれるからな。すべてが素晴らしいか？すべてが完璧に動作してるか？全然近くもない。
この特別な洞察が非常に興味深いと思うんや。各会社が「おい、俺らは他のすべてと互換性がある。クロス機能性がある。すべて素晴らしい」って言うから。いやいや。
これらの結果、著者らは「エージェントフレームワーク設計がベンチマークでのパフォーマンスに大きく影響することをハイライトする」って言う。そんで企業レベルのエージェントでさえ、俺はこれについての経験がない。だから企業レベルエージェントとその力についてもっと知ってるなら、コメントを残してくれ。Cursorみたいに本当に違うんか。彼らは明示的にCursorをテストした。特定のドメインでは優れるかもしれんけど、Reactのようなシンプルなフレームワークをアウトパフォームしない。
これについて考えると、俺はちょっと失望してる。何かにお金を払ったら、無料バージョンより少しはましでなあかんと思ってたから。結果、そうやなかった。そんで俺はちょっと嬉しい。「おい、素晴らしい、これは無料でもシンプルなフレームワークが、俺らがお金を払わなあかんプロプライエタリでグローバル企業に属する解決策をアウトパフォームできるってことや」って思うから。
興味深い、現在俺らがどこにいるかを見るのが興味深い。彼らは「o3とReactの間、そしてもしコヒーレントなOpenAI o3とOpenAIエージェントSDKが欲しいなら、OpenAIのo3とSDKによる最適なエージェントモデルペアリングが複雑なタスクでのパフォーマンス最大化に重要であることを実証する」って言う。
企業間の互換性について
これは、グローバル企業が言ってることが本当かってことを意味する。「おい、俺らは完全にクロス機能的でクロス互換性がある」って。この会社が彼らのLLM、OpenAI o3をエージェントSDK、エージェントフレームワークに最適化してるように本当に見える。もちろん理にかなってる。これは彼らの製品やし、自分の製品の相互作用を最適化する。
だから次回LLMやエージェントフレームワークにお金を払うかどうか、どの会社に払うかを決めなあかんときに考えるべきことや。他の人らはここでこの文章を教えてくれる。
「OpenAI o3とOpenAIエージェントSDK設定は、テストされたすべてのLLMバックボーン組み合わせの中で最高の全体パフォーマンスを達成し、特化されたエージェントアーキテクチャがそれらのLLM能力を効果的に活用できることを示唆する」
なんという驚きや。ログインや。
悲しい真実
だから、ここまで来た。このビデオの最後に悲しい真実がある。俺らの現在のLLMはエージェントを扱えない。エージェントシステムのようなものは何もない。そんで俺のところに来て「おい、俺にはエージェントシステムがある」って言うなら、いや、俺らが発見したように、すべてが50%を下回ってる。これはエージェントシステムやない。これは多分運が良かったり悪かったりするだけや。
論文著者の公式結論
論文著者による公式結論に来よう。彼らは「おい、俺らのMCP Universeベンチマークは現在のLLM能力の重要なギャップを暴露する。長いコンテキストハンドリング、ツールの不慣れ、ドメイン間パフォーマンス格差への挑戦を含む。Cursorのような企業レベルエージェントは、MCP駆動タスクの複雑さに苦戦する」って言う。
代わりに、トンネルの終わりの明るい光があって、彼らは「分かった、もっと研究しなあかん」って言う。この発見は、LLMモデル設計とエージェント統合に関連するすべてにおいて、より的を絞った進歩の必要性を強調する。
だから彼らは希望、希望のきらめきを残してくれる。「分かった、もっと良いモールを構築しなあかん。もっと良いエージェントネットワークを構築しなあかん。そしたら多分、50/50に近づくパフォーマンスを達成できるかもしれん」
終わりに
だから俺はこの特別な言葉であんたらを残す。素晴らしいと思う。俺らの前にはたくさんの仕事がある。もっと良いモデルを構築しなあかん。もっと良いエージェントを構築しなあかん。もっと良い互換性のあるフレームワークを構築しなあかん。すべての異なるプラットフォーム間でクロス機能的でなあかん。そんで登録してくれたら、俺のチャンネルですぐに別のビデオを見つけられるで。またな。
コメント