この動画は、AI界で注目されているModel Context Protocol（MCP）エージェントの性能問題を深掘りした内容である。Salesforceの研究に続いて発表された学術論文「MCP 101」を詳しく解説し、7つのエラー分析フレームワークを用いてAIエージェントの失敗要因を分類・分析している。GPT-5が唯一50%を超える成功率を示したものの、最高でも60%程度という現状を明らかにし、各LLMの具体的な弱点を数値とグラフで示している。特にLlama 3.7 70Bの壊滅的な性能やGemini 2.5シリーズの期待外れな結果についても言及し、MCPエージェントの改善に向けた課題を浮き彫りにしている。
なんでこんなにAIエージェントは失敗し続けるんや？
みなさん、こんにちは。今日はMCP 101について話していきまっせ。たった2本前の動画で、SalesforceがMCPの災害について発見したことをお話ししたんやけど、LLMは単純にMCPエージェントを扱えへんっちゅうことやったんや。そん時に、この地球上でマルチターンMCP呼び出しに最も優れたLLMはどれやって教えたやろ。
今日はな、次のステップに進むで。学術界から新しい論文が出てきて、MCPエージェントの改善に向けた7ポイントエラー分析フレームワークの詳細な調査を提供してくれとるんや。見ていこうやないか。
今度は追加で全く新しい深層診断MCPエージェントツールがあるんや。これが何をできるか知っとるか？これらの7つのパラメータ全てを分析できるんやで。詳しく見ていこうと思うんやけど、できれば一緒にな、これが何を意味するか、そして各LLMがどんな性能を示しとるかを見ていこう。
これが全く新しい論文や。「live MCP 101: challenging queriesでMCP対応エージェントをストレステストする」。Yogi大学とZoom Video Communicationによるもんや。彼らが言うとるのはな、今日我々には、シンプルな1つのMCPクールなベンチマークから、多様なMCPツールと多様なMCPサーバーを使った多段階タスクがある実世界のAIエージェントまでの間に、ベンチマーキングにおいて大きなギャップがあるっちゅうことや。
前回の研究からたった1日後、2025年8月21日、今度はSalesforceからやなく学術界からの追加研究があるんやで。同じ発見、同じ洞察があるか、何が違うかを見てみよう。
既存ベンチマークの問題点と新しいアプローチ
著者らはSalesforceのMCPユニバースに同意しとるんや。既存のベンチマークは単純すぎる、単純すぎるんや。さらに、エージェントの具体的な弱点を理解する必要があるんや。
この新しい方法論があって、7つのパラメータの深層調査ができるんや。エージェントやLLMの成功率が40%しかない場合、この40%がどこから来とるかが分かるっちゅうわけや。失敗の25%がセマンティックエラーによるもんやって分かるんやで。
この深層調査が欲しいやろ。LLM、エージェント、MCP構成がどこで失敗しとるかを理解したいもんや。
彼らがやったのは単なるタスクの生成やない。創造し、設計し、もちろん科学的厳密さをもって愛情を注いだんや。OpenAIのO3を使って複雑なクエリを作成し、複数ラウンドのLLMリライティングを行ったんや。私がLLMと話すみたいに、彼らもLLMと話して、約120時間の博士課程学生の時間を投資したんやで。
結果として101のタスクになった。101のタスクや。30の簡単なタスク、30の中程度のタスク、41の難しいタスクがあるんや。複雑さレベルが段階的に上がっとるから、LLMのMCPエージェント性能をテストできるわけや。
革新的な評価システム
巧妙なやり方をしたんや。理解すればとてもシンプルやで。各クエリについて、人間チームがO3の少しの助けを借りて、詳細なステップバイステップの実行計画を作成したんや。
人間の博士が「これが解決する最良の方法や」と言うような、明確に定義されたツール呼び出しの順序や。これをエージェントプロセスのゴールドスタンダードと呼んどるんや。最終結果だけやなく、フローの完全な定義、大西洋経路の定義やで。
それから美しいアイデアが生まれたんや。2つのエージェントが同時に並列実行するっちゅうもんや。
最初のエージェントはロボットエージェントや。これはゴールデン実行計画を引用符付きで無思慮に従うエージェントやで。ツールを使ってステップバイステップで進む。定義済みのパスやから何も間違いが起こらん。このエージェントは使うツールやどこにジャンプするかを自分で決める必要がない。全て事前定義されとるんや。
シーケンスの線形実行があるだけや。これが完璧な時間同期動的グランドプルーフ性能として機能するんや。
そしてここが美しいところや。実際のテストエージェントがあるんや。このエージェントが評価対象になる。例えばGPT-5 LLMがこのエージェントに入っとるとしよう。
評価手法と結果の信頼性
エージェントはユーザークエリ、人間のクエリだけを受け取って、自分で行動せなあかん。自分自身の解決策を見つけなあかん。クエリの複雑さを考慮して、どのLLM、どのMCPが利用可能か、どのサーバーが利用可能かを調べなあかん。
すぐに分かるやろ、美しいで。理論的ゴールドスタンダード、運用ゴールドスタンダード、そしてテスト対象があるんや。
シンプルなタスクやけど、これがどれだけ強力かは今日のlive MCP 101で示されとるんや。チームはLLMを審査員として使っとって、最初はGPT-4.1を購入してスコア付けしたんやけど、あんまり満足してへんかったんや。でも最終的に人間も使って検証したんやで。
結果がここにあって、人間専門家からのスコアとLLM審査員のスコアを比較してこのアプローチを検証したと言っとる。そうや、これやで、絶対にそうや。
人間-LLM合意があって、どの審査員を使ってもGPT-5では結果が87%、軌道評価が80%になっとる。人間は「ああ、87%、88%、LLM審査員は良い仕事をしとった」と言っとるんや。Claude 4.1 O 拡張思考を使えば88%、88%、79%。Gemini 2.5 Proなら86%、78%。QN使えば85%、81%や。
このシステムが機能しとるのが分かるやろ。高度に整合した方法論やから、LLM審査員の結果を信頼できるんや。
結果分析：3つの評価指標
結果について話そう。科学的詳細は全部カットして、すぐに結果に行くで。3つの指標がある。覚えとるか、タスク成功率、解決策の全体的品質を反映するARS平均結果スコア、そしてATS平均軌道スコアや。
これは全タスクにわたって評価されたエージェントで、軌道の論理的一貫性、完全性、全体的美しさ、正確性を評価し、結果指標を補完する解決プロセスの品質をキャプチャしとるんや。
3つの指標があるわけや。もちろん本当に重要なのは成功率で、前回のMCPユニバースのビデオで見せた成功率みたいなもんや。平均軌道スコアも良いと思うで。解決への道筋の戦いの評価やからな。
前回のビデオで2人の購読者、いや1人の購読者と私のチャンネルに登録してへん1人の視聴者から叫び声があったんや。「MCPユニバースにClaude Opus 4.1がないやないか。OPUS 4.0しか見せてくれてへん」って。
ほら、ここにあるで。Claude 4.1や。OPUSの拡張同期版とClaude Opus 4.1の非同期版もあるんや。
LLM性能ランキングと詳細分析
これが、Llama 3 70Bみたいに使うべきLLMと使うべきやないLLMの完全な結果やで。MCP 101で定義された101タスクに対する最高のLLMがトップダウンで並んどる。これがTSRで、残りはここにあるんや。
ビデオの最初に7つのカテゴリがあると言ったやろ。ここにまた見えとる。1、2、3、4、5、6、7や。正しかった場合、それが何やったかが分かるんや。シンタックスエラーやったか？いや。セマンティックエラーやったか？ああ、GPT-5を見てみい。主な失敗原因はセマンティックエラーやったんや。
Llama 3 70Bを見てみい。まだLlama 3 70Bをエージェント作業に使っとるなら、やめとけ。全体性能が2%以下やないだけやなく、シンタックスエラーがあるんやで。全エラーの約50%がシンタックスエラーや。それからセマンティックエラーがあって、ツールを一切使わずに過信して自己解決しようとするんや。
美しい洞察やろ。これは華麗やで。全タスクの割合も色分けされとるんや。
別の視点で見ることもできるで。x軸にARS、y軸に成功率があって、色分けされとる。ここがATSや。暗いほどATSが高いんや。性能は60%近くのGPT-5が見えて、それから結構な差があって20%のO3もOpenAIから。それからClaude 4.1とOpusグループ、そして3.7があって、ここにGemini 2.5 Flashがあるんや。
フラッシュよ、10%って何しとんねん。こんなことあり得へんで。まだGPT-4 Omniをエージェントタスクに使っとるなら、これ見てみい。20%をかろうじて上回っとるだけや。気をつけなあかん。
Gemini 2.5 Proにはちょっと失望したで。20%台の高い方におるんや。MCPユニバースのデータは正確に22%やった。ここでも27%や。どうしてこんなことが可能なんや？Gemini、マルチターンMCP会話をもっと最適化せなあかん。
GPT-5がこれを達成したんや。50%を超える唯一のモデルや。他の全てのモデルは50%以下やで。
トークン効率と数値データ
平均トークン数を見たら、GPT-5が分かるで。そうや、そうや、そうや。美しいんや。素晴らしいで。Llama 3.3が推論にほとんどトークンを使わへんのは良いけど、性能を見てみい。2、3%以下やで。
そうや、18,000トークンをGPT-5に使わせて、60%近くを出してもらおうやないか。分かったか。
純粋な数値データが欲しいなら、ここにあるで。モデルがあって、美しいやろ。ちょっと色分けコーディングをしたんや。これが簡単ブロック、成功率や。最初の黄色いのが成功率やで。
LLMが簡単なMCP作業しかしない場合、このデータを見てみい。これが重要な線やで。「GPT-4 Omni」と言うなら、40%や。これで行くなら、美しいで。Gemini 2.5 Proなら36%や。
ここで面白いのは何か知っとるか？これ見てみい。Claude 4.1 Opus拡張同期。Claudeの最高モデルがO4 Miniと同程度の性能に達しとるんや。O4 Miniがこの美しい惑星のあなたの大陸にあるかどうか分からへんけど、まだ無料版やのに、とても良いんや。
O4 Miniは巨大な作業に素晴らしかったんや。完全版でも、難しいタスクで29対27になっとる。ああ、これはクールやで。O4 Miniはエージェント作業の隠れた宝やったんや。
そしてGPT-5 Pro、GPT-5が全体的に最高の性能を示しとるんや。素晴らしいで。
難しいタスクではゼロ、101クエリの1つも解決できへんかった。これはGemini 2.5 Flash、QN3B、Llama 70Bのグループやと言えるやろう。冗談やろ？Llama 70B。MCP呼び出し1つもなし。災害やで。
7つのエラーカテゴリの詳細説明
7つのカテゴリを覚えとるか？要件無視、これや。過信自己解決は、エージェントが要件を認識するけど、パラメトリック知識や独自の推論能力からの知識プールから答えようとして、ツールを呼び出さへんっちゅう意味や。
どうしてこんなことが可能なんや？それからLLMによる非生産的思考がある。エージェントはツールが必要やと認識して、計画やツールのパラメータについて議論するかもしれへんけど、ツール呼び出しを開始しなかったり、要件に対処する解決策を提案せえへんかったりするんや。非生産的思考でループするんや。
AIがこんなことどうやってできるんや？それから間違ったツール選択。信じられへん。ツールを呼び出すけど、MCPで不適切なものを選ぶんや。こんなことどうして可能なんや？
シンタックスエラー。ツールに提供されるパラメータが不正な形式で、不正な型、フィールド名の不足や間違い、完全に無効なスキーマなどがあるんや。これらのエラーによってMCPサーバーがリクエストを正しく解析できず、完全な失敗モードに至るんや。
セマンティックエラー。パラメータは正しい形式やけど、タスクの意図と合わへん。一般的なケースには、誤ったスコープのクエリ文字列、間違った識別子やエンティティ参照、不正なコンテキスト制約がある。これらのエラーはパラメータを生成するのに使われる中間推論の間違いから生じることが多いんや。
深い推論、これは最高の最高のモデル向けやで。セマンティックエラーがあるんや。
出力解析エラー。正しい結果を返すけど、エージェントが解析中に誤って処理して、最終回答の不正な中間状態を引き起こすんや。素晴らしいやろ。
これで7つの要件が分かったやろ。今説明したから、エージェントのコアとして使っとる特定のLLMの性能が正確に分かるんや。賢く選択して、Llama 3 70Bとそれ以外は忘れることやな。
結論と今後の課題
これはAIツール使用のためのLLMをどう訓練するかの知識が誰もなかった時代のもんやったんや。
結論、とても短いビデオや。これがそれや。MCPモデルコンテキストプロトコルの新しい美しいベンチマーク、live MCP 101を紹介したんや。美しく洗練された101の多様なタスクがあって、最高のLLMでも成功率は60%以下やで。
1つを除いて全員が50%以下やから、MCPエージェントには現在まだ大規模な重要課題があることを強調しとるんや。a）ツールオーケストレーション、b）適応的推論、c）トークン効率や。
何を言いたいか分かっとるで。分かっとるんや。「ちょっと待てよ。あの101クエリは」って言うやろ。いや、あのクエリは本当に適切な出力処理による異種MCP呼び出しの多段階構成が必要なんやで。
見てみい、とてもシンプルや。簡単は簡単、中程度はまだ簡単、難しいは大丈夫や。あまりにシンプルやから、私の因果推論テストにも入れへんやろう。
だからここの質問が難しすぎるとか、MCPやAIエージェントがMCPで解決できへんもんやなんて言わんといてや。サムがAGIと博士レベルについて言ったことを覚えとるか？
ユーザーから質問があって、「100回以上のMCP呼び出しを含んでたか？それならシステムは失敗するやろ」って言うとった。冗談やろ？何個のツールチェーンがあるか見せたるで。3、4、5、6や。これだけや。何百のMCPって何の話や？何もない。1、2、3、4、5や。これだけや。
これがlive MCP 101実行計画のツールチェーン長の分布のツールチェーンの長さやで。3、4、5のMCPサーバーが必要やっちゅうことや。これだけや。10は1つの質問だけ、12も1つの質問、13も1つの質問やで。
忘れてまえ。MCPサーバーの数の些細な領域におるんやで。
最終的な考察
私の側からの最終的な思考や。絶対に魅力的やと思ったで。同じトピックについて2日以内に2番目の論文があって、MCP LLMエージェントシステムの性能を評価しとるんや。今までの全てのベンチマークは単純すぎる、知られてへんか些細すぎて、タスクに適してへんっちゅうことも示しとるんや。
両方の論文を同時に読めば、MCPエージェントの状態を進歩させるための研究のための強力なチャンスを提供してくれると思うで。MCPユニバース論文はテストする美しい世界を定義しとるんや。今日のこの論文MCP 101は、LLM MCPツール使用エージェント相互作用で何が間違っとるかを正確に理解するための7つの基準、7つの非常に詳細な基準を診断するためのツールキットを提供してくれとるんや。
これ見てみい。これらの論文は興味深いと思ったし、MCPエージェントで何を改善せなあかんかを理解する方法やで。楽しんでもらえたら嬉しいわ。チャンネル登録して、次回でまた会おうや。
コメント