鶴田研究所 Tsuruta Laboratory

調査ノート 2026-09-15

ツール応答への7種の障害注入3,200エピソードにおける、エージェント成績の低下要因の分析

4Bのローカルモデルで3,200エピソード。7種の障害のうち、成績を下げたのはエラーと空だけで、値の誤りは下げなかった

要旨

ローカルで動く40億パラメータのモデルにツールを使わせ、ツールの返答を7種類に壊して3,200エピソードを走らせた。壊し方をまとめて見ると成績はほとんど動かず、独立に壊した条件で5.4ポイント、連続して壊した条件で3.2ポイント下がるだけだった。種類ごとに分けると、下がったのは利用制限・時間切れ・空の返答の3つで、1件あたり14.5・10.7・8.4ポイントだった。形式は正しく値が誤っている返答、途中で切れた返答、鍵の名前が変わる返答、壊れたJSONは、どれも0と区別がつかなかった。障害を1件だけ受けたエピソードで見ても同じ順序になった。理由は、エラーを見たエージェントが、すでに成功している呼び出しをやり直すことにある。時間切れの直後に同じ呼び出しを繰り返す割合は25.0%で、障害のない手の4.7%の5倍だった。空の返答では、ツールを呼ばずに文章で答えて終わる割合が15%に上がった。値が誤っているだけの返答は、やり直しも中断も起こさなかった。この結果は、注入器がツールの実行結果ではなくエージェントに見せる表示だけを壊し、採点が最終状態で行われることに強く依存する。

方法BFCL v4の多ターン課題200問を、Qwen3-4B-Instruct-2507をllama.cppで動かしたエージェントに解かせた。エージェントとツールの間に注入器を置き、ツールが返した結果をエージェントに見せる前に7種類のいずれかに壊した。壊す時間構造は4つで、無し、各手を独立に確率0.16、平均5手続く塊と平均20手の休みを繰り返すもの、途中から鍵の名前が変わり続けるものである。乱数の種を4つ使い、合計3,200エピソードを走らせた。採点は公式の採点器で、エージェントの呼び出しを新しい実体に再実行し、最終状態を正解と比べる。種類ごとの寄与は、1エピソードに複数の種類が混ざるため、種類ごとの件数と手数を説明変数にしたロジスティック回帰で分けた。
結果障害なしの成功率は29.5%だった。同じ課題と同じ種で対応をとった差は、独立に壊した条件が−5.4ポイント(95%区間−7.4〜−3.4)、塊で壊した条件が−3.2ポイント(−5.1〜−1.3)、鍵の名前が変わり続ける条件が+0.6ポイント(−0.8〜+2.1)だった。回帰による1件あたりの寄与は、利用制限−14.5ポイント、時間切れ−10.7、空の返答−8.4で、いずれも区間が0を含まない。壊れたJSON−4.5、途中で切れた返答−3.3、値が誤っている返答−2.7、鍵の名前が変わる返答−2.1は、いずれも0を含む。障害をちょうど1件だけ受けたエピソードでは、値が誤っている返答が36.4%、途中で切れた返答が34.7%、鍵の名前が変わる返答が32.8%、壊れたJSONが33.3%で、いずれも障害なしの29.5%を下回らなかった。一方、空の返答は21.3%、時間切れは20.0%、利用制限は15.3%だった。
知見返答が中身を持っているかどうかが、エージェントの成績を分けた。中身を運ばない返答、つまりエラーと空は成績を下げ、中身を運ぶが正しくない返答は下げなかった。下げる経路は二つある。一つはやり直しで、時間切れの直後に同じ呼び出しを繰り返す割合は25.0%、利用制限では19.4%で、障害のない手の4.7%を大きく上回る。ツールは実際には成功しているので、やり直しは同じ操作を二度当てることになる。もう一つは中断で、空の返答と時間切れの後にツールを呼ばず文章で終える割合が15%と14%に上がった。障害ありのエピソードのうち、やり直しが起きたものの成功率は14.5%、起きなかったものは24.8%だった。
限界注入器はツールの実行結果ではなく、エージェントに見せる表示だけを壊している。採点は最終状態で行うので、値が誤った返答は、エージェントが誤った数を文章で報告しても状態は正しいままとなり、点に出にくい。実際の運用では、返答が誤っているとき世界の側も誤っていることが多い。課題はBFCLの多ターン1種類、モデルは4Bを1つ、成功率は29.5%で、これより強いモデルや別の課題で同じ順序になるかは測っていない。
ツール障害の種類ごとに、成功率をどれだけ下げたかを見た図同じエピソードに複数の種類が混ざるので、種類ごとの件数を説明変数にしたロジスティック回帰で分けた。横棒は2,000回のブートストラップの95%区間。上の3つは0を含まず、下の4つは含む。-20.0-15.0-10.0-5.00+5.0障害1件あたりの成功率の変化(ポイント)利用制限利用制限 -14.5 [-24.3, -7.5]-14.5時間切れ時間切れ -10.7 [-20.0, -3.8]-10.7空の返答空の返答 -8.4 [-16.0, -1.8]-8.4壊れたJSON壊れたJSON -4.5 [-11.8, +1.8]-4.5途中で切れた返答途中で切れた返答 -3.3 [-10.6, +3.5]-3.3形式は正しく中身が誤り形式は正しく中身が誤り -2.7 [-8.8, +2.4]-2.7鍵の名前が変わる鍵の名前が変わる -2.1 [-9.3, +4.4]-2.1
障害の種類ごとに、1件あたり成功率をどれだけ下げたか。複数の種類が同じエピソードに混ざるので、件数を説明変数にした回帰で分けた。横棒は95%区間で、上の3つだけが0を含まない。
障害の直後に同じ呼び出しをやり直した割合障害を見た直後3手以内に、まったく同じツール呼び出しを繰り返した割合。縦の破線は障害のない手での同じ割合。ツールは実際には成功しているので、やり直しは同じ操作を二度当てることになる。0%5%10%15%20%25%障害なし 4.7%直後3手以内に同じ呼び出しを繰り返した割合時間切れ時間切れ 25.0%25.0%利用制限利用制限 19.4%19.4%壊れたJSON壊れたJSON 10.4%10.4%鍵の名前が変わる鍵の名前が変わる 8.2%8.2%途中で切れた返答途中で切れた返答 6.9%6.9%空の返答空の返答 5.0%5.0%形式は正しく中身が誤り形式は正しく中身が誤り 3.4%3.4%
障害を見た直後3手以内に、まったく同じ呼び出しを繰り返した割合。破線は障害のない手での割合。ツールは実際には成功しているので、やり直しは同じ操作を二度当てることになる。
失敗予測の精度を、使った手がかりごとに見た図エピソードが最後に失敗するかを、途中の手から予測したときのAUROC(左)と、正常の5%が誤報する閾値での検出率(右)。内部の迷いを足しても、外から見える記録だけとほとんど変わらない。0.50.60.70.80.9エピソード単位のAUROC誤報5%での検出率外から見える記録だけ外から見える記録だけ AUROC 0.8460.84663%4Bの内部の迷いだけ4Bの内部の迷いだけ AUROC 0.7510.75114%両方両方 AUROC 0.8510.85161%
失敗予測の精度。外から見える記録だけで足りていて、4Bの内部の迷いを足しても変わらない。捕まえるべき信号がツールのエラーそのものだからである。

背景と現状の課題

ツールを呼ぶ大規模言語モデルは、外の世界からの返答を読んで次の手を決める。返答は常に正しいとは限らない。通信が切れる、利用制限に当たる、返答が途中で切れる、鍵の名前が変わる、そして値そのものが誤っている。こうした障害にエージェントがどれだけ耐えるかは、実運用で最初に問われる性質である。

この分野の記述には一つの共通した強調がある。明示的なエラーよりも、形式は正しいが中身が誤っている返答の方が危険である、というものである。エラーは見れば分かるが、正しい形をした誤りは見分けられないからだ、という理屈である。筆者もこの前提で実験を設計した。本調査の元になった計画書には、注入する障害のうち「形式は正しいが内容が間違っているtool response」を主戦場と書いている。

その前提が、自分の実験で否定された。本調査はその報告である。

先行研究

ツールを使うエージェントの頑健性は、この一年で複数のベンチマークが扱っている。Zhang らの ReliabilityBench は、時間切れ、利用制限、途中で切れた返答、鍵の名前の変化という4種類の障害を混沌工学の要領で注入し、4領域1,280エピソードで測った。利用制限が最も損害が大きいと報告している。Yang らの ToolRobustBench は、ツールの説明、利用者の意図、ツールの出力、実行環境という4つの family に摂動を分け、16のローカルなツールと7つのモデルで15,456件を測り、ツールの出力への摂動が最大の律速だと報告している。

値の誤りの破壊力については、より強い報告がある。Don't Blindly Trust It は、検索結果を入れ替えるという操作で、Qwen2.5-7B の F1 が 44.8 から 4.7 に落ちることを示した。ツールを与えない条件の 22.3 すら下回る。道具があることが害になる、という現象である。

本調査は、この三つと同じ種類の障害を、同じように注入する。違いは二つある。第一に、7種類を同じエピソードの中で混ぜたうえで、種類ごとの寄与を回帰で分けた。第二に、成績が下がる経路を、エージェントの行動の記録から辿った。

仮説

実験の前に書いた予想は次のものである。

  • 形式は正しく中身が誤っている返答が、最も成績を下げる。明示的なエラーより見分けにくいからである。
  • 塊で続く障害の方が、独立に散らばる障害より成績を下げる。復帰する暇がないからである。
  • 鍵の名前が変わり続ける障害は、一度気づけば対応できるので、途中から効かなくなる。

結果は一つ目が逆、二つ目も逆、三つ目だけが当たった。

技術解説

ここで扱うエージェントは、一手ごとに次を繰り返す。これまでの会話とツールの一覧をモデルに渡し、モデルが呼び出すツールと引数を返し、それを実行し、結果を会話に足す。ツールを呼ばずに文章を返したら、その turn は終わりである。

注入器はこの輪の中で、ツールの実行とモデルへの提示の間に入る。ツールは常に本当に実行される。壊すのは、実行の結果をエージェントに見せるときの表示だけである。ファイルを移動する呼び出しに時間切れを注入しても、ファイルは移動している。エージェントだけが、移動に失敗したと信じる。

この設計は意図したものである。ツールの実行そのものを壊すと、失敗したのがツールなのかエージェントなのかを採点で分けられない。表示だけを壊せば、状態は常に正しく進むので、成績の差はすべてエージェントの反応から来る。ただしこの設計は結果の意味を限定する。後の「限界」で述べる。

対象と方法

課題とモデル

課題は BFCL v4 の多ターン基本課題200問である。ファイルシステム、投稿、切符、取引、旅行予約、車両制御などの模擬 API を複数またぎ、一つの課題が4つ前後の turn からなる。採点は公式の採点器で行う。エージェントが出した呼び出しを新しい実体に対して再実行し、正解の呼び出し列を実行した後の状態と比べる。文章の一致ではなく、最終状態の一致で採点する。

モデルは Qwen3-4B-Instruct-2507 を8ビット量子化し、llama.cpp で RTX 3060 の上で動かした。温度は0である。思考を出す版ではなく指示版を選んだのは、思考のトークンが後述する不確実性の測定を濁すからである。

壊し方

種類エージェントに見せるもの中身を運ぶか
時間切れ{"error": "timeout"}運ばない
利用制限{"error": "rate_limit", "status": 429}運ばない
空の返答{} または空文字列運ばない
壊れたJSON途中で切った生の文字列半分運ぶ
途中で切れた返答配列の後半、辞書の後半の鍵を落とす半分運ぶ
鍵の名前が変わる鍵を改名し数値を文字列にする。一度決めた改名は続く全部運ぶ
形式は正しく中身が誤り型と鍵を保ったまま値を変える。数値を1〜10%ずらす、配列の要素を入れ替える、日付を1日ずらす、IDを隣の値にする運ぶが誤り

壊す時間構造

条件内容1手あたりの注入率
無し壊さない0
独立各手を独立に壊す0.16
塊2状態のマルコフ連鎖。平均5手続く塊と平均20手の休み。塊の中では0.8で壊す0.16
持続乱数で決めた手以降、鍵の名前の変化だけが続く—

独立と塊の注入率は、定常分布の計算で0.16に揃えた。揃えないと、塊が難しいのか注入が多いのかが分かれない。塊の連鎖は定常分布から始める。0から始めると、短いエピソードでは塊が来る前に終わってしまう。実測の連続長は、塊で2.72手、同じ率の独立で1.18手だった。

比較対象

本調査には、次の三つの対照を置いた。

  • 障害なしの同じ課題・同じ種。成功率の差はすべて対応をとって測る。課題の難しさは200問で大きく違うので、対応を取らないと種類の差が課題の差に埋もれる。
  • ちょうど1件だけ障害を受けたエピソード。回帰は複数の種類が混ざった状態から寄与を分けるので、仮定が要る。1件だけのエピソードは仮定が要らない代わりに数が少ない。二つが同じ順序を出せば、どちらの弱点も補える。
  • 障害のない手でのやり直し率。やり直しは障害がなくても起きる。障害の直後の割合だけを見ると、エージェントがもともとやり直す癖があるだけかもしれない。障害のない16,639手で同じ測り方をして、比べる相手にした。

また、種類ごとに選ばれ方が違わないことを先に確かめた。ある種類を1件以上受けたエピソードの平均手数は10.2から11.2手、平均の障害件数は2.6から3.0件で、7種類の間でほぼ同じだった。長いエピソードほど障害を受けやすいという偏りは、種類の間では働いていない。

評価指標

  • 成功率。公式の採点器が最終状態の一致を認めた割合。
  • 対応をとった差。同じ課題・同じ種での、障害あり条件と障害なし条件の差。95%区間はエピソードを取り直す2,000回から4,000回のブートストラップで出した。
  • 1件あたりの寄与。成功を、種類ごとの障害件数と手数で説明するロジスティック回帰の係数を、平均のところで成功率の変化に直したもの。区間は2,000回のブートストラップ。
  • やり直し率。ある手の直後3手以内に、まったく同じツール呼び出しが再び現れた割合。
  • 失敗予測の精度。エピソードが最後に失敗するかを、途中の手から予測したときのAUROCと、正常なエピソードの5%が誤報する閾値での検出率、および最初の警報から終わりまでの手数。課題番号で学習と検証と試験に分け、試験は640エピソードである。

結果

まとめて見ると、ほとんど動かない

3,200エピソード、31,405手、クラッシュは0件だった。1エピソードは平均9.4手、ツール呼び出しは平均6.1回である。

条件成功率障害なしとの差(95%区間)
障害なし29.5%—
持続(鍵の名前)30.2%+0.6(−0.8〜+2.1)
塊26.4%−3.2(−5.1〜−1.3)
独立24.1%−5.4(−7.4〜−3.4)

注入率を揃えた独立と塊を比べると、独立の方が強く下げた。予想と逆である。鍵の名前が変わり続ける条件は、障害なしと区別がつかなかった。

種類ごとに分けると、二つに割れる

1エピソードに平均2.8件の障害が混ざるので、まとめた条件の差は種類の平均でしかない。種類ごとの件数を説明変数にした回帰で分けると、はっきり二つに割れた。

種類1件あたりの寄与95%区間1件だけ受けたときの成功率
利用制限−14.5−24.3〜−7.515.3%
時間切れ−10.7−20.0〜−3.820.0%
空の返答−8.4−16.0〜−1.821.3%
壊れたJSON−4.5−11.8〜+1.833.3%
途中で切れた返答−3.3−10.6〜+3.534.7%
形式は正しく中身が誤り−2.7−8.8〜+2.436.4%
鍵の名前が変わる−2.1−9.3〜+4.432.8%
(障害なし)——29.5%

単位はポイントである。上の3つは区間が0を含まず、下の4つは含む。右の列は回帰とは独立な確認で、障害をちょうど1件だけ受けたエピソード(各48件から61件)の成功率である。二つの測り方が同じ順序を出した。下の4つは、1件だけ受けたとき、障害なしの29.5%を下回っていない。

割れ方は、返答が中身を運ぶかどうかで説明できる。エラーと空は中身を運ばない。残りの4つは、半分だったり名前が違ったり値が誤っていたりするが、中身は運んでいる。

下げる経路は、やり直しと中断である

障害を見た直後3手以内に、まったく同じツール呼び出しを繰り返した割合を数えた。

種類やり直し率ツールを呼ばず文章で終える割合
時間切れ25.0%14%
利用制限19.4%2%
壊れたJSON10.4%0%
鍵の名前が変わる8.2%5%
途中で切れた返答6.9%9%
空の返答5.0%15%
形式は正しく中身が誤り3.4%3%
障害のない手4.7%6%

右の列は、障害を1件だけ受けたエピソードのうち、失敗の理由が「ツールを呼ばずに文章で答えて終わった」だった割合である。障害なしでは6%である。

時間切れと利用制限はやり直しを起こす。ツールは実際には成功しているので、やり直しは同じ操作を二度当てることになる。ディレクトリを作る、投稿する、切符を買うといった操作では、二度目が状態を壊す。空の返答はやり直しを起こさない代わりに中断を起こす。エージェントは情報を得られないまま、ツールを呼ぶのをやめて文章で答える。値が誤っているだけの返答は、やり直しも中断も起こさない。エージェントは誤った値をそのまま受け取り、次に進む。

障害を受けたエピソードのうち、やり直しが起きたものの成功率は14.5%、起きなかったものは24.8%だった。

失敗予測に、内部の迷いは足さない

途中の手からエピソードの失敗を予測する器を作った。外から見える記録だけを使うと、エピソード単位のAUROCが0.846、正常の5%が誤報する閾値での検出率が0.63、最初の警報から終わりまでが中央値7手だった。4Bの生成トークンの entropy だけを使うと0.751で、両方を使っても0.851にしかならなかった。上乗せは0.005である。

係数を見ると、効いているのは累積のツールエラー数と、状態が変わらない手の連続である。上で見たとおり、成績を下げるのはエラーが見えている場面なので、捕まえるべき信号はもともと外から見えている。内部の迷いを測る意味は、ここでは小さい。

考察

先行研究の強調と本調査の結果が食い違う理由は、採点が何を見ているかにある。

Don't Blindly Trust It が測ったのは、検索結果を根拠にして答える課題である。そこでは誤った証拠が答えそのものになるので、値の誤りは直接に点を奪う。本調査が測ったのは、模擬 API を操作して最終状態を作る課題である。値の誤りは、エージェントが誤った数を文章で報告しても、状態を変えない。採点は状態を見るので、点に出ない。

言い換えると、値の誤りが害になるかどうかは、その値が何に使われるかで決まる。報告に使われるなら害になる。次の操作の引数に使われるなら害になるが、今回の課題では引数の多くが利用者の指示から直接来るので、ツールの返答から引数を組み立てる場面が少ない。

一方、エラーの害は課題に依存しない。エラーは、エージェントに「この操作は起きなかった」と信じさせる。信じたエージェントは操作をやり直す。ここで、ツールが実際には成功していたなら、やり直しは二重適用になる。これは実運用でも起きる。通信が切れたが要求は届いていた、という場合である。冪等でない操作を再送してよいかという古い問題が、そのままエージェントにも出ている。

この観察は、計算資源の配分にも関わる。安いモデルと強いモデルを切り替える制御器を作るとき、何を根拠に切り替えるかが問題になる。本調査の範囲では、根拠になるのはツールのエラーそのものであり、それは外から見える。安いモデルの内部状態を読む必要はない。予測器の上乗せが0.005だったのは、そういうことである。

限界

  • 注入器はツールの実行結果ではなく、エージェントに見せる表示だけを壊している。実際の運用では、返答が誤っているときに世界の側も誤っていることが多い。その場合、値の誤りは状態を通じて点に出るはずで、本調査の結論は当てはまらない。
  • 採点は最終状態の一致である。エージェントが利用者に誤った数を報告しても、状態が正しければ成功と数える。報告の正しさを採点に入れれば、値の誤りの害は大きくなる。
  • 課題はBFCLの多ターン基本課題1種類、モデルは4Bを1つである。障害なしの成功率が29.5%と低いので、より強いモデルでは別の順序になりうる。強いモデルほどツールの説明に従うので、エラーへの反応も変わる可能性がある。
  • やり直しの測定は、同じ文字列の呼び出しが3手以内に再び現れたかで数えている。引数を少し変えた再試行は数えていない。
  • 「ツールを呼ばず文章で終える」割合は、障害を1件だけ受けたエピソードで測っており、各48件から61件と少ない。
  • 失敗予測は線形の器で、特徴も窓つきの単純な統計である。系列を学習する器なら内部の迷いがもっと効く可能性は残る。

結論

ツールの返答を壊したとき、40億パラメータのエージェントの成績を下げたのは、中身の誤りではなく中身の不在だった。エラーと空の返答は1件あたり8から15ポイント下げ、値の誤り・途中で切れた返答・鍵の名前の変化・壊れたJSONは0と区別がつかなかった。下げる経路は、すでに成功した操作をやり直すことと、情報を得られないまま中断することの二つである。ここから、エージェントを守る設計は、見分けにくい誤りを見破ることよりも先に、エラーを見たときに何をするかを決めることだと言える。とりわけ、冪等でない操作をやり直してよいかを、エージェントの外で決めておく必要がある。

参考文献

  1. S. Yan et al. (2024). Berkeley Function Calling Leaderboard. https://gorilla.cs.berkeley.edu/leaderboard.html
  2. ReliabilityBench: Evaluating LLM Agent Reliability Under Production-Like Stress Conditions. arXiv:2601.06112 (2026).
  3. ToolRobustBench: Stage-Wise Perturbation Evaluation and Failure Diagnosis for Tool-Calling Agents. arXiv:2608.23635 (2026).
  4. Don't Blindly Trust It: How Unreliable Feedback Breaks Tool-Using LLM Agents. arXiv:2606.21409 (2026).
  5. ToolFailBench: Diagnosing Tool-Use Failures in LLM Agents. arXiv:2607.04686 (2026).
  6. Real-Time Detection and Repair of LLM Agent Failures. arXiv:2608.02464 (2026).
  7. TACIT-Switch: Cost-Aware Model Escalation for LLM Agents from Censored Supervision. arXiv:2608.27911 (2026).
  8. The Intervention Paradox: Accurate Failure Prediction in Agents Does Not Imply Effective Failure Prevention. arXiv:2602.03338 (2026).
  9. Qwen Team (2025). Qwen3 Technical Report. arXiv:2505.09388

付録

再現の手順

公開した zip に、注入器、エージェントの輪、採点、集計、図を作るコードと、3,200エピソード31,405手の生ログが入っている。次の順で再現できる。

  1. llama-server に Qwen3-4B-Instruct-2507 の8ビット量子化を読ませ、1つのスロットに16,384トークンの文脈を与えて2並列で起動する。
  2. tools/smoke.py と tools/smoke_controller.py を走らせる。全部通らなければ先へ進まない。
  3. tools/run_baseline.ps1 を走らせる。2つの作業者が4つの時間構造と4つの種を順に回す。途中で止めても同じ命令で続きから走る。
  4. src/eval/metrics.py、src/predictor/train.py、tools/report.py の順に走らせる。

検算に使ったわざと通らない値

注入器と制御器には、正しい値での成功と素通りを見分けるための検算を入れてある。注入率を1にすると全手に障害が出る。0にすると1件も出ない。乱数の種を揃えると障害の記録が一致する。制御器の閾値を1.01にすると一度も切り替わらず、0にすると最初の手で切り替わって戻らない。ヒステリシスの幅に負の値を渡すと、実行が止まる。これらが期待どおりでなければ、本走行はしない。

entropy の近似について

生成トークンの entropy は、上位20個の対数確率から計算している。全語彙を使っていないので下振れする。31,405手で、上位20が占める確率の平均は0.999969、中央値は0.999994、最小は0.9875だった。0.99を下回る手は0.003%である。取りこぼす質量が1000分の1なら、entropy の下振れは高々0.012 nat で、成功したエピソードと失敗したエピソードの差(0.052 対 0.076)より一桁小さい。

この調査が置かれている文脈

本調査は、覚醒状態の安定化に着想を得た計算資源の制御器を、ツールを使うエージェントに入れる研究の最初の段である。制御器を作る前に、制御器が効く余地があるかを測った。結果として、障害がエージェントを壊す幅は本調査の設定では狭く、壊す信号はもともと外から見えていることが分かった。次の段は、安いモデルと強いモデルの差そのものを測ることになる。

資料