MCPを足しても賢くならない。GUIエージェントの「使う」と「使いこなす」を分けた研究
PCを操作するAIエージェントにMCPツールを渡せば、クリックより速く、正確に仕事を片づけてくれそうだ。ところが、同じツール、同じ検索器、同じ実行環境を使っても、あるモデルでは成功率が4.0ポイント上がり、別のモデルでは5.9ポイント下がった。
さらに意外なのは、ツールで処理できる230タスクが用意されていたのに、成績が上がったモデルでさえツールを使ったのは55タスクだけだったことだ。到達可能なタスクに限っても採用率は23.9%。道具箱を置くだけでは、エージェントは職人にならない。
今回取り上げるのは、arXiv論文「Screenshots or Tools? Eliciting Tool Use and Managing Multimodal Context in Hybrid GUI-MCP Computer-Use Agents」だ。研究チームはGUI操作とMCPツール呼び出しを同じエージェントに持たせ、「ツールを選ぶ判断」と「正しく使い切る能力」を切り分けた。さらに、MCP実行後に重複しやすいスクリーンショットを減らし、マルチモーダル文脈のコストまで調べている。
この記事では、論文の報告とAICompanyの解釈を分けながら、実務で何を測ればよいかまで掘り下げる。
これまでの問題は、ツールの有無だけを比べがちだった
コンピュータ操作エージェントには、大きく2つの行動経路がある。
1つはGUI経路だ。スクリーンショットを見て、座標を決め、クリックや入力を繰り返す。対応アプリを選ばない一方、画像トークンを使い、画面が変われば古い座標や視覚情報が役に立たなくなる。
もう1つはツール経路だ。MCP、CLI、アプリ固有APIなどを呼び、セルへの値入力や文書編集を構造化された引数で実行する。正しいツールと引数を選べれば、複数回のGUI操作を1回にまとめられる。ただし、ツールが存在しない操作もあり、実行結果だけでは画面上の状態を確認できないこともある。
従来の比較では「GUIのみ」と「GUIにツールを追加」を比べ、最終成功率の差を見て終わることが多い。だが、それでは次の原因が混ざる。
- 役立つツールが候補に出ていない
- 候補に出てもモデルが選ばない
- 選んでもツール名や引数を間違える
- 実行自体は成功しても、タスクの意味では失敗する
- 成功したのに確認や終了判断を誤る
この論文の価値は、最終点だけでなく、その途中を計測したところにある。
同じMCPが、Thinkingではプラス、Instructではマイナスになった
研究チームは、同じ8B backboneを持つQwen3-VL-8B-ThinkingとQwen3-VL-8B-Instructを比較した。前者は明示的なreasoning traceを出し、後者は出さない。ただし著者ら自身が注意しているとおり、2つのcheckpointにはreasoning trace以外の差も含まれる。
評価にはOSWorld-MCPのインターネットアクセスを使わない構成を採用した。対象は309タスク。MCP側には9つのアプリ名前空間にまたがる120ツールがあり、現在のアプリに応じてBM25で上位18ツールを提示する。1ステップにつきツール呼び出しは1回、最大50ステップ、greedy decoding、各条件5回という設定だ。harness、retriever、prompt template、tool setは固定されている。
論文Table 2の全309タスク平均は次のようになった。
- Thinking: GUIのみ30.5%、GUIとMCPで34.5%。4.0ポイント上昇
- Instruct: GUIのみ25.4%、GUIとMCPで19.5%。5.9ポイント低下
論文では両方の差が2 standard errorsを超えたとしている。重要なのは「MCPは効く」でも「MCPは邪魔」でもないことだ。同じ注入方式でも、モデルのtool-decision behaviorによって効果の符号が反転した。
Instructでは、ツールを無視する、存在しないツール名を出す、成功していないのに終わったと判断する、といった失敗が多かった。Table 3ではfalse-success rateがThinkingの21.7%に対しInstructは33.0%。存在しないツール名はInstructで97回、2タスクに集中していた。
一方、Thinkingはツールを比較的うまく扱ったが、積極的に使ったわけではない。ツールで処理可能な230タスクに対し、実際の利用は55タスクだった。全体では17.8%、到達可能タスク内でも23.9%にとどまる。著者らはこの差をadoption gapと呼んでいる。
「使わせる」学習で変わったのは行動であり、能力ではない
では、ツールを使うたびに報酬を与えればよいのか。研究チームはmulti-turn RLでそれを試した。
単に最終成功報酬へ小さなbonusを足すと、長いtrajectoryで平均化され、正規化や各stepへの配分を経て信号がほぼ消えてしまう。そこで、実行に成功した新しい非read-only tool callに対し、正規化後のstep-level advantageへ直接bonusを加えた。同じ引数の繰り返しや副作用のない呼び出しでは報酬を稼げない設計だ。
結果はきれいに二分した。24タスクのsubsetではspreadsheet tool adoptionが0.03から0.33へ上がり、greedy decodingでも0.02から0.29へ移った。step-level usageは4.7倍になった。つまり、ツールを選ぶ方針は学習で動かせた。
しかし、48 held-out tasksのaccuracyは改善しなかった。ツールを多く呼ぶようになっても、正しい引数を組み、実行結果をタスクの意味へ接続し、必要ならGUIへ戻る能力までは手に入らなかった。
ここは実務で見落としやすい。tool-call数が増えると、導入が進んだように見える。だが、呼び出し回数はadoptionの指標であり、competenceの指標ではない。利用率の上昇だけをKPIにすると、賑やかな失敗を量産する可能性がある。ボタンを押した回数を数えても、仕事が終わった回数にはならない。AIも会議も、だいたい同じ罠に落ちる。
スクリーンショットを半分にすると安くなるが、そのままでは精度が落ちた
ハイブリッドエージェントのもう1つの課題は文脈コストだ。MCPでセルへ値を書き込んだ直後、tool resultがテキストで返り、次のスクリーンショットにも同じ変化が映る。この画像は確認には役立つが、情報が重複することも多い。
論文は画像履歴の深さと、tool success後の画像保持を別々のknobとして扱った。
- window-4: 直近4枚のスクリーンショットを保持
- window-2: 直近2枚だけ保持
- drop-on-success: MCP実行成功後の次画像をtext placeholderへ置換
ThinkingのGUIとMCP条件では、accuracy重視のwindow-4が34.5%、1タスクあたり累積inputは337.1K tokensだった。window-2とdropを組み合わせるとinputは219.5Kへ減ったが、accuracyは30.6%へ下がった。約3分の1の入力削減と引き換えに3.9ポイントを失った計算だ。
著者らは、この低下を単純な能力不足ではなく、observation distributionのずれだと仮説化した。学習中は豊富な画像を見ていたpolicyに、本番だけ少ない画像を渡せば、入力形式が変わる。そこで学習、評価、本番を同じ圧縮observation ruleにそろえて再学習した。
Abstractで報告された圧縮checkpointは37.8%に達し、比較対象のuncompressed operating point 33.0%を上回りながら、入力costは53%だった。事前登録した13タスクのdegraded subsetでもrich observationとlean observationの差が0になった。
ただし、ここを「圧縮すれば精度も上がる」と読むのは危険だ。5.3節では、held-out accuracyはbaseとfinal checkpointで変わらなかったと明記されている。training bandの上昇はobservation consistency固有の効果ではなく、optimization recipeの影響が大きい。rich-observation controlの方が学習自体は速かったが、出力tokenと入力costが大きく、同じ費用点では比較できない。
AICompanyの解釈。導入テストは5段階に分ける
ここからは論文の直接主張ではなく、AICompanyの実務向け解釈だ。
MCPや社内toolをエージェントへ追加するとき、最終成功率だけでA/B testをすると、どこで壊れたか分からない。最低でも次の5段階を分けたい。
- Supply: そのタスクに使えるtoolが存在したか
- Retrieval: 必要なtoolが候補へ提示されたか
- Adoption: モデルがGUIではなくtoolを選んだか
- Semantic competence: tool名、引数、対象、順序が正しかったか
- Task verification: 実行後の状態を確認し、正しく終了できたか
さらにcontext costとして、累積input、peak input、output、step数を同時に取る。成功率が同じでも、画像履歴の持ち方で費用とlatencyは変わる。
この分解をすると、改善方法も変わる。Retrievalが低ければtool descriptionや検索器を直す。Adoptionが低ければpromptやpolicy learningを検討する。Semantic competenceが低ければschema、argument examples、error feedback、実行前validationが必要だ。Task verificationが弱ければ、重要操作のあとだけscreenshotを残すなど、確認policyを設計する。
小さく再現するなら、2かける2の比較から始める
大規模RLをいきなり再現する必要はない。手元のエージェントでも、次の2かける2で問題の位置をかなり絞れる。
行動空間を「GUIのみ」と「GUIとtool」、観測を「画像履歴4枚」と「画像履歴2枚 plus tool成功後drop」に分け、同じ20から50タスクを複数回流す。各taskで次を記録する。
- 最終成功、失敗
- tool-reachableか
- toolが提示されたか
- toolを呼んだか
- execution successか
- semantic successか
- false successまたは早すぎる終了があったか
- inputとoutput token、step数
ここでtool adoptionだけ上がり、semantic successが横ばいなら、論文のaction-level probeと似た状態だ。圧縮条件だけ精度が落ちるなら、同じobservation ruleをfew-shot example、finetuning data、評価にそろえる余地がある。
もう1つ重要なのは、execution successとsemantic successを分けることだ。たとえばfind-and-replace APIが正常終了しても、置換対象が0件ならタスクは進んでいない。論文のdrop ruleはexecution-level successで画像を捨てるため、この種の意味的失敗を見逃すことがある。重要操作では、結果の件数や対象状態を検証してから画像を落とす方が安全だ。
公開実装は充実しているが、再現は軽くない
研究チームは公式GitHub repositoryをApache-2.0で公開している。RL orchestrator、training worker、BM25 tool retriever、prompt、120 toolのregistry、実験config、task split、改変OSWorld、結果provenanceが含まれる。
Hugging Faceにはoutcome-onlyとcontext-RLの2つのQwen3-VL-8B checkpointも公開されている。論文の主張をコードなしで説明するだけでなく、どの設定でどの数値が出たかを追える点は評価できる。
一方、完全再現にはOSWorldのVM、アプリ環境、MCP server、GPU、長いmulti-turn rolloutが必要だ。checkpointをdownloadできることと、論文全体を低コストで再実行できることは同じではない。
この研究がまだ証明していないこと
第一に、reasoning modelならMCPで必ず伸びるとは証明していない。比較した2 checkpointは同じbackboneだが、reasoning trace以外も異なる。著者らも、MCP効果の符号をreasoning capability一般に帰属できないとしている。
第二に、tool adoptionを増やせばheld-out accuracyが上がるとは言えない。今回のRLでは利用行動は動いたが、48 held-out tasksの成績はついてこなかった。
第三に、画像圧縮は常に安全ではない。表計算やslide編集では、実行後の視覚確認が必要な場面が残る。成功判定がAPI levelだけなら、意味的失敗の証拠を消すこともある。
第四に、結果はQwen3-VL-8B、OSWorld-MCP、特定のtool retrievalとharnessに依存する。他model、WindowsやmacOSの実環境、権限管理を含む企業運用で同じ数値になる保証はない。
結論。MCP導入の本体は、接続ではなく経路選択の設計にある
この論文が示した最も実用的な教訓は、tool availabilityとtool competenceを混同しないことだ。
MCPを接続しても、モデルがGUIという慣れた経路を選び続ければ使われない。報酬で呼び出しを増やしても、引数や終了判断が弱ければ成功率は上がらない。スクリーンショットを削れば安くなるが、学習時と本番時の観測がずれれば精度を失う。
だから導入時に見るべきなのは「何個toolをつないだか」ではない。使える場面で提示されたか、選ばれたか、意味的に成功したか、確認して終われたか、そのうえでtokenとstepを減らせたかだ。
道具箱は必要だ。しかし、どの道具をいつ選び、結果をどう確かめるかまで学習と評価に組み込んで、初めてエージェントの経路になる。