AIエージェントを作る現場では、LLMが必要な場面でツールを呼ばずに答え切ろうとして失敗したり、逆に簡単な質問にまで外部ツールを使って遅く高くなったりします。University of Marylandの2026年5月13日公開論文「 Model-Adaptive Tool Necessity Reveals the Knowing-Doing Gap in LLM Tool Use 」は、この現象を『Knowing-Doing Gap』として定義し、認知と実行のズレをhidden state probingで分解しました。
2026年8月時点でも、この論文の示唆は古びていません。MCPやResponses API、Copilot系のコーディングエージェントなど周辺基盤は整ってきましたが、『いつ道具を使うべきか』の失敗は依然としてプロダクション課題です。この記事では、論文の主張をそのまま要約するのではなく、現場で何が役に立つのかに寄せて整理します。
この論文がなぜ重要か
最近のエージェント基盤は、ツール接続そのものよりオーケストレーションのしやすさに価値が移っています。だから実務のボトルネックは『呼べるか』ではなく『呼ぶべきときに呼べるか』です。論文が重要なのは、この判断ミスを単なるプロンプト不足やモデル癖として片付けず、内部認知と最終アクションの分離として観測した点にあります。
特に運用者にとって大きいのは、失敗を一段深く分類できることです。モデルがそもそも必要性を理解していないのか、それとも理解しているのに実行に移せていないのかで、改善策はまったく変わります。前者なら知識や判定材料の不足、後者なら制御層や実行ポリシーの設計不足です。
たとえば社内検索エージェントで『最新の価格表を見て答えて』と依頼したのに、古い埋め込み記憶だけで返すケースは、知識不足の問題に見えて実はツール判断の問題であることが多いです。モデルは外部参照の必要性をうっすら認識していても、その信号が最終出力に勝てず、もっともらしい文章生成へ流れてしまいます。論文は、この現象を観測可能な構造として示しました。
従来研究のギャップ: モデル非依存なツール必要性の限界
従来のベンチマークは、『天気取得はツール必要』『言い換えはツール不要』のようにクエリへ静的ラベルを付ける発想が中心でした。しかし現実には、同じクエリでも強いモデルなら自力で解け、弱いモデルではツールが必要、という差が起きます。論文はここを正面から扱い、ツール必要性はクエリ固有ではなくモデル能力境界に依存すると置き直しました。
この再定義は、エージェント評価を現実寄りにします。社内の軽量モデルと高性能モデルで同じルールを使っている場合、誤差のかなりの部分はモデル差ではなくラベル設計の粗さから来るからです。『必要性』をモデル依存で測るだけで、過剰利用と過少利用の診断がかなり明確になります。
この観点は評価ベンチマークだけでなく、モデル切り替え戦略にも効きます。安価なモデルへ寄せるほどツール必要性の境界は内側へ縮み、同じ業務フローでも外部参照の必須率が上がります。モデル能力を無視して静的に『この問い合わせはツール不要』と決めてしまうと、コスト最適化と品質維持を同時に外しやすくなります。
提案: モデル適応的ツール必要性 (Model-Adaptive Tool Necessity)
著者らは、ツールなし推論を複数回回して毎回正解できるならそのクエリはそのモデルにとってツール不要、1回でも外すならツール必要、と定義しました。経験的な能力境界に基づいて必要性を決めるため、同じ質問でもモデルごとにラベルが変わります。評価設計として素朴ですが、実務上はかなり筋が良い考え方です。
さらに、ツール使用を『必要性の認知』と『実際のツール実行』に分けたのが効いています。エンドツーエンドの成功率だけを見ると、なぜ失敗したのかがぼやけます。二段階に分けることで、モデル内部では必要だと分かっていたのに、その信号が最終トークン生成まで届いていない可能性を検査できるようになりました。
実務に引き寄せると、これは『モデルごとにツール方針のデフォルトを変えるべきだ』という話です。高性能モデルでは自力回答を多めに許し、軽量モデルでは検索や計算を早めに強制する、といった差分設計の正当化になります。同一プロンプトを全モデルに配るだけでは、Knowing-Doing Gapの大きさが違うため最適化しきれません。
計測結果: 必要性とアクションの食い違いは 26.5-54.0%
論文では、算術タスクで26.5%から54.0%、事実QAで30.8%から41.8%の必要性アクション不一致が観測されました。つまり、4分の1から半分近いケースで、モデル能力に照らすと不適切な判断をしているわけです。ここが重要なのは、単なる『たまに外す』ではなく、運用コストや信頼性に直結する頻度でズレが出ていることです。
また、モデルごとにズレ方が違う点も見逃せません。あるモデルは算術でツールを呼びすぎ、別のタスクでは逆に呼ばなさすぎる、といった振れ方をします。したがって『このモデルは保守的』『このモデルは攻め気味』の一言で片付けるのは危険で、タスクとモデルの組み合わせごとに診断し直す必要があります。
さらに重要なのは、ズレがコストと品質の両方を悪化させる点です。不要なツール呼び出しは待ち時間と課金を増やし、必要なときに呼ばない失敗は誤答や幻覚を増やします。片方だけ減らすのでは足りず、『過剰利用も過少利用も同時に下げる』という設計目標が必要になります。
診断: hidden state プロービングで認知と実行を切り分ける
論文の中核は、hidden stateから認知方向と実行方向を別々に読み出したことです。認知プローブは『このクエリではツールが必要だとモデルが分かっているか』を、実行プローブは『次トークンとして実際にツール呼び出しへ向かうか』を推定します。両方がある程度線形に読めるという結果は、モデル内部に必要性の表現自体は存在することを示しています。
にもかかわらず、後段層・最終トークン付近では認知方向と実行方向がほぼ直交するという観測が出ました。論文の図では、多くの失敗が cognition-to-action の遷移で起きており、認知そのものではありません。ここが『知ってるけど呼ばない』という名前の由来です。
late-layerで方向が直交するという観察は、プロンプト設計万能論への反証にも見えます。もし失敗の大半が認知不足なら、注意喚起プロンプトやfew-shot追加でかなり改善してもよいはずです。しかし実際には、理解した信号を行動へつなぐ部分が弱い。だからこそ、外部ガードレールや補助分類器の価値が残ります。
AIエンジニアへの実務的示唆
第一に、ツール呼び出し評価は一枚岩では足りません。プロダクション監視では、1) 本来必要だったのに呼ばなかった件数、2) 不要なのに呼んだ件数、3) 呼んだが結果を使い切れなかった件数、を分けて見るべきです。これだけで、プロンプト改善、ポリシー改善、実行レイヤ改善のどこに時間を使うべきかが見えやすくなります。
第二に、LLMへ全権委任しない設計が現実的です。たとえば高コストAPIや高リスク操作では、軽量な補助分類器やルールで『この条件なら強制的に検索』『この条件なら必ず確認』を差し込む方が安定します。Responses APIやMCPの時代でも、最終判断を完全自律にしないという保守的設計は十分価値があります。
2026年の現場では、特に高コストな長文推論、ブラウズ、コード実行、社内システム更新でこの考え方が有効です。『誤って呼ぶと高い』『呼ばないと危険』なツールほど、LLM単体の気分に任せず制御を重ねた方が運用は安定します。論文の知見は学術的に見えて、実際には権限制御や予算統制の設計にも近いところがあります。
批判的視点と限界
もちろん限界もあります。論文が扱うのは主にオープンモデル4種と比較的限定されたタスクで、複雑なマルチツール計画やUI操作系エージェントまでは直接カバーしていません。閉じた商用モデルでも同じ形で再現するかは未確定です。
また、モデル適応的必要性の測定には繰り返し推論が必要で、そのまま本番評価へ持ち込むとコストが重いです。実務では完全再現より、失敗ログを教師として近似的な必要性判定器を育てる、あるいは高額ツールだけ絞って計測する、という割り切りが必要になります。
また、エージェント監視のダッシュボードも変わります。単純な成功率ではなく、ツール未使用で正解した割合、ツール使用で正解した割合、必要だったのに未使用だった割合を分けて出すと、モデル更新やプロンプト変更の影響が見やすくなります。ここまで切ると『賢くなったのか、ただ高くなったのか』も判別しやすくなります。
関連論文と次の一歩
この論文を読んだ次にやるべきことは、自分たちのエージェントにもKnowing-Doing Gapがあるかを測ることです。まずは代表タスクを20から50件ほど作り、ツールが必要なケースと不要なケースを分け、呼び出しログを見て過少利用と過剰利用を数えます。その上で、プロンプト修正だけで動くのか、外側の制御が必要なのかを判断すると、改善サイクルが速くなります。
論文自体は研究寄りですが、メッセージはかなり実務的です。エージェントの品質問題を『モデルが賢くなれば自然に解ける』と期待するのではなく、認知と実行のズレを前提に制御面を設計する。その姿勢が、2026年のエージェント実装ではいちばん再現性の高い学びだと思います。
AIエージェント実装の壁打ちは /contact/ へ。eval設計、ツール呼び出し方針、フォールバック設計まで実装寄りに相談できます。
