ツールを持たせたエージェントを運用していると、地味に効いてくる二種類の失敗がある。「2+2は?」にまで検索APIを叩いてレイテンシと課金を無駄にする過剰呼び出しと、逆に外部知識が要る質問に手元の知識だけで答えてしまう過小呼び出しだ。どちらもプロンプトで「必要なときだけツールを使え」と書いて調整することになるが、この手のプロンプトチューニングは脆く、モデルやタスクが変わると崩れる。

ここに、2026年5月に相次いで出た三本の解釈可能性(mechanistic interpretability、モデル内部の表現を機械的に読み解く研究分野)の論文が、そろって同じ方向を指す答えを出した。要点を一言で言うと、エージェントは「いつ・どのツールを・どういう順で呼ぶか」を、生成する前の隠れ層(hidden state、モデルが次のトークンを吐く前に内部で持っている数値ベクトル)にすでに書き込んでいる。しかもその情報は、線形プローブ(hidden stateに対する単純なロジスティック回帰など、ほぼ直線的な読み取り器)で取り出せるほど素直な形で入っている。

呼ぶべきかは内部でわかっている、なのに出力で外す

一本目は UC San Diego と Amazon AWS のグループによる LLM Agents Already Know When to Call Tools — Even Without Reasoning。タイトルがそのまま主張になっている。

彼らは Qwen(1.7B〜32B)と Llama 3.1-8B・3.3-70B の計6モデルで、入力最後のトークンの hidden state を取り出し、L2正則化つきロジスティック回帰を900例だけ学習させて「このクエリはツールが要るか」を二値で当てさせた。結果は AUROC 0.89〜0.96。注目すべきは、モデル自身が思考(chain-of-thought)で判断させると完全に失敗するような難易度でも、プローブは高い精度を保った点だ。つまりモデルの中には正しい判断材料が入っているのに、実際に文章を生成する段で活かしきれていない。内部表現と出力行動のあいだにズレがある、というのがこの論文の核心だ。

面白いのはここからで、この読み取りを推論の前段(prefill)に差し込む Probe&Prefill という手法を組むと、ツール呼び出しを48%減らしても精度低下はわずか1.7%に収まった。比較対象の既存手法は、同じ精度なら6%しか減らせないか、同じ48%減なら5倍の精度劣化を払う。論文本文によればプローブ自体の追加コストは1タスクあたり1ミリ秒未満で、通常の prefill フォワードパスに乗せるだけだ。ツール1回が外部API課金と往復レイテンシに直結する実運用では、この差はそのまま請求書に効く。

論文の手法を最小化するとこうなる。ポイントは「モデルを追加学習しない」ことだ。

from sklearn.linear_model import LogisticRegression

# h: 各クエリで取り出した「入力最後のトークンの hidden state」(N, d_model)
# y: そのクエリがツールを必要とするか(0/1)。900例程度で足りる
probe = LogisticRegression(C=1.0, penalty="l2").fit(h_train, y_train)

# 推論時: 生成を始める前に呼ぶ/呼ばないを判定する
score = probe.predict_proba(h_query)[:, 1]
call_tool = score > tau   # tau で 呼びすぎ⇄呼ばなさすぎ のトレードオフを制御

どのツールを選ぶかは一本の方向で決まる

二本目、Tool Calling is Linearly Readable and Steerable in Language Models は「呼ぶか否か」から一歩進んで「どのツールを選ぶか」を扱う。Gemma 3(270M〜27B)、Qwen、Llama 3.1 の12モデルで調べたところ、二つのツールのどちらを選ぶかは活性空間の中のたった一本の線形方向に対応していた。

だから読めるだけでなく操作できる。生成中にその方向ベクトルを足し込むと、モデルが選ぶツールが切り替わる。4B以上の instruct モデルで成功率83〜100%、実タスク寄りの τ-bench(航空券)でも77〜94%。個人的にいちばん驚いたのは、ツール名を無理やり差し替えると、出力される JSON の引数スキーマがスキーマ情報を与えていないのに差し替え先のツールの形に組み替わったという観察だ。モデルは「ツールという概念」を、名前と引数がひとまとまりになった構造として内部に持っているらしい。

幾何も効率的で、15個のツールの区別が約10次元に圧縮され、200個のAPIに広げても必要なのは36方向(ランダムなベクトルなら167本要る)。そしてモデルが二つのツールで迷っている「自信のないクエリ」は、自信のあるケースより21倍の頻度で失敗した。これは実行前にエラーを予知するシグナルとして使える、というのが実務的な含意だ。

呼び出しの依存グラフまで読めるが、単発では消える

三本目、Tianda Sun と Dimitar Kazakov による Tool-Call Dependency Structure is Linearly Decodable in LLM Agent Residual Streams は、さらに抽象度を上げる。エージェントが「先に呼んだツールの出力を、後のツールの引数に渡す」とき、そこには有向の依存グラフができる。この論文は Qwen3-32B の residual stream に低容量のエッジプローブをかけ、そのグラフ構造をランダムや位置ベースのベースラインを上回って復元できることを示した。読み取っているのは識別子の値そのものではなく、実行の抽象トポロジだという。

ただし境界条件が正直で興味深い。呼び出しの順番だけで依存が説明できてしまうタスクではシグナルが薄れ、単発のプランニング(依存関係が存在しない)では消えた。裏を返せば、モデルが依存構造を内部に持つのは、本当に多段の依存があるときだけ。これは前の二本の「常に読める」という話とは温度差があり、三本を並べると解像度が上がる。

論文	内部から読むもの	実務での効き目
Already Know When to Call	ツールが必要か(二値)	呼び出し48%減・精度-1.7%、1ms未満で判定
Linearly Readable and Steerable	どのツールを選ぶか	選択の操作、迷いから失敗を事前検知(21倍)
Dependency Structure Decodable	呼び出し間の依存グラフ	多段依存の把握。ただし単発では消える

エンジニアとして持ち帰るもの

三本に共通するのは、サンプリングされた出力よりも hidden state のほうが、ツール利用について豊かで構造化された情報を持っているという一点だ。解釈可能性というと「なぜそう答えたかを後から覗く学術的な営み」の印象が強いが、ここで起きているのはもっと実利的な転換だと思う。数百例で数秒学習する線形プローブという安いレイヤーが、ツールルーティングのコスト削減・オーバーコール検知・エラー予知・依存構造の可視化という、これまで大きなプロンプトや別モデルで無理やりやっていた仕事を肩代わりし始めている。

もちろん万能ではない。プローブはモデルごと・タスク分布ごとに学習し直す必要があり、依存グラフの例のように内部にそもそも情報が無い場面では読めない。それでも、自前のエージェント基盤を持っているなら、まず「呼ぶ/呼ばない」の線形プローブを prefill に一枚差すのは、費用対効果がかなり良い実験だ。モデルはもう答えを知っている。あとはそれを聞き出す配線をこちらが用意するかどうか、という段階に来ている。

一次ソース(いずれも本文全文が公開されている):