北京大学と中国の美団（Meituan）のチームが、AI エージェントの失敗を種類ごとに測る評価セット MCPHallu を11月5日に arXiv で公開しました。対象は、MCP で外部の道具を呼び出すエージェントです。358問を14のモデルに解かせた結果、平均の合格率は47.8%でした。12のモデルが一番苦手にしていたのは、もともと達成できない依頼でした。できないと伝えずに作業を続けた回は、517回のうち1回も合格していません。
背景と文脈
MCP（Model Context Protocol）は、AI のモデルにファイル操作や Git、外部サービスの API などの道具をつなぐための共通の決まりです。Anthropic が2024年に出し、いまは多くのエージェントの道具がこの形で配られています。エージェントは、モデルが道具を呼んで結果を読み、次の手を決める動きをくり返すプログラムです。
これまでの MCP の評価は、最後に作業が終わったかどうかで点をつけるものが中心でした。失敗の理由は、終わったあとに記録を読んで分類していました。これだと、同じ70点のモデルでも、どんな場面で失敗するのかがわかりません。
MCPHallu: Benchmarking Reasoning, Execution, and Memory Hallucinations in MCP Agents の著者たちは、問題を作る段階で、わざと失敗しやすい仕掛けを1つずつ入れました。そのうえで、仕掛けの種類ごとに点を出しています。論文のいうハルシネーション（AI がもっともらしい誤りを出すこと）は、指示や道具の中身と食い違うものを、エージェントが正しいと思いこんで使うことを指します。
技術/ビジネス面
仕掛けは4種類あります。道具の結果しだいで進む道が2つ以上に分かれる問題では、間違った道に進むかを見ます。どの道具を使っても達成できない問題では、できないと報告するかを見ます。似た名前の道具が2つ以上ある問題では、取り違えるかを見ます。最初に取った値のあとに紛らわしい情報を流す問題では、最後の答えが元の値とずれるかを見ます。
問題は358問で、一般・コーディング・分析・事務作業・金融の5分野に分かれます。道具は実際に使われている36の MCP サーバーの約300個です。1回ごとに新しい Docker のコンテナで動かすので、前の回の影響は残りません。モデルには ReAct（考える・道具を呼ぶ・結果を見る、をくり返す基本のやり方）で解かせ、道具を呼べるのは20回までです。
採点は、ほとんどを機械的な確認で行います。別の AI に点をつけさせる部分は、問題の種類によって2〜3割だけです。14モデル・5,012回の実行にかかった API の費用は、合わせて約3,200ドルでした。
総合点の上位は、Claude Opus 4.6 が0.728、Claude Sonnet 4.5 が0.710、Claude Opus 4.5 が0.696 でした。14モデルの平均は0.642で、40問で試した人間の専門家は0.88 でした。種類ごとの順位はモデルによって大きく入れかわります。DeepSeek-V4 は分かれ道の問題で0.853と高い一方、達成できない問題では0.302にとどまりました。
開発者として試すなら
自分のエージェントで一番まねしやすいのは、できない依頼のときの止め方です。論文の表では、途中で止まって「達成できない」と伝えた回の合格率が48.0%でした。伝えずに作業を続けた回は0.0%です。最後の返事が「完了しました」だけの回は2.1%しか合格していません。GPT-5 に「達成できないときはそう伝える」とシステムプロンプトで指示すると、この種類の点は0.45から0.56に上がりました。ただし総合点は0.67から0.69で、著者は指示だけでは埋まらない差だと書いています。
| モデル | 総合 | 分かれ道 | 取った値を忘れる | 達成できない依頼 | 道具の取り違え |
|---|---|---|---|---|---|
| Claude Opus 4.6 | 0.728 | 0.755 | 0.730 | 0.576 | 0.885 |
| Claude Sonnet 4.5 | 0.710 | 0.766 | 0.655 | 0.567 | 0.880 |
| Claude Opus 4.5 | 0.696 | 0.867 | 0.612 | 0.492 | 0.849 |
| DeepSeek-V4 | 0.606 | 0.853 | 0.533 | 0.302 | 0.788 |
| GLM-5.1 | 0.539 | 0.621 | 0.457 | 0.413 | 0.688 |
道具の取り違えの例も、そのまま参考になります。論文では、GPT-5 がコミットの中身を見る場面で git_git_show ではなく git_git_diff を呼んでいました。同じ MCP サーバーの中に役割の近い道具が並んでいると、モデルは名前と説明文だけで選びます。自分で MCP サーバーを書くなら、説明文の1行目に何を返す道具なのかをはっきり書いておくと、こうした取り違えを減らせます。
値を保存させる作業にも注意が要ります。取った値を答えるだけの問題では59.2%が合格しました。その値を状態に書き戻す必要がある問題では、24.6%まで下がっています。
評価を自分の環境で動かすときは、GitHub の J1zz/mcp_hallu の README に手順があります。Docker Desktop（メモリ8GB以上）、uv、Python 3.10〜3.13、jq が必要です。主な流れは次のとおりです。
cd mcp-atlas
cp env.template .env
docker pull ghcr.io/scaleapi/mcp-atlas:1.2.5
docker tag ghcr.io/scaleapi/mcp-atlas:1.2.5 agent-environment:latest
make -C mcp-atlas run-docker
cd task_generation
uv run hallu-eval --input final_tasks/confusion_tasks.jsonl --model gpt-4o-2024-08-06 --docker-snapshotREADME と論文には食い違いがあります。採点の配分が論文の数字と違い、採点役の AI の初期設定も論文の GPT-4o ではなく Gemini 2.5 Pro になっています。道具の数も README は302、論文の付録は296です。論文と同じ点数を出したいなら、設定を論文に合わせてから動かしてください。ライセンスも、GitHub の表示は Apache-2.0、README は MIT と分かれています。
これからどうなるか
この論文は査読前の第1版で、README によると NeurIPS 2026 に投稿中です。道具は英語の、主に欧米の SaaS のものに限られ、問題ごとに道具の一覧は固定されています。著者は、採点役にも公開モデルを使う形に変えたいと書いています。
開発者がすぐ使えるのは、総合点が近いモデルどうしでも、自分の用途に関わる種類の点を見て選べることです。たとえば社内の Git や課題管理を MCP でつなぐなら、道具の取り違えと、できない依頼の点を優先して比べられます。手元のエージェントには「達成できないときは理由を書いて止まる」という指示を足し、ログで「完了しました」だけの返事を探すと、失敗の見落としを減らせます。
まとめ
MCPHallu は、MCP エージェントの失敗を4種類に分けて測る評価セットです。14モデルの平均合格率は47.8%で、一番の弱点は達成できない依頼でした。できないと伝えずに続けた回の合格は0%です。システムプロンプトの指示で少し上がりますが、モデルを選ぶときに種類ごとの点も見ておけば、用途に合わないモデルを避けられます。
