AIエージェントが使うツールの説明や引数の形が、運用中に変わると呼び出しを誤る。この問題に、再学習なしで対処する手法の論文がarXivに公開されました。提案手法「SchemaShield-Lite」は、出力の検証とやり直しを組み合わせた軽い修復層です。Qwen3.5-9Bで試したところ、関数呼び出しの評価セットで正答率が0.580から0.805に上がりました。ツールが増え続ける実運用のエージェントに、すぐ取り入れやすい内容です。
背景と文脈
いまのAIエージェントは、関数呼び出し（Function Calling：モデルがツール名と引数をJSONなどの形で出力し、プログラム側が実際の処理を実行する仕組み）で外部の機能を使います。モデルは、ツールの名前、説明文、引数のスキーマ（どの項目にどんな型の値を入れるかの定義）を見て、どれをどう呼ぶかを決めます。
問題は、このツール定義が運用中に変わることです。説明文が書き直される、引数の名前が変わる、似たツールが追加される。ツールの中身の動きは同じでも、モデルから見える情報が変わります。論文はこれを「インターフェースドリフト」と呼んでいます。MCP（Model Context Protocol：AIとツールをつなぐ共通規格）でツールを外部から取り込む構成が増え、ツール定義が自分の管理外で変わる場面は珍しくなくなりました。
対策として、変更のたびにモデルを追加学習する方法もあります。ただ、手間とコストがかかり、ツールの変更に追いつくのは現実的ではありません。そこで著者らは、モデルには手を加えず、出力の後ろに修復の処理を挟む方式を選びました。
技術/ビジネス面
Aniruddha Chattopadhyay氏らの論文Robust Function Calling for LLM Agents Under Interface Driftは、NGEN-AI 2026に採択されています。SchemaShield-Liteは3つの部品でできています。1つ目は、モデルが出した呼び出しがスキーマに合っているかの検証です。2つ目は、存在しないツール名を出したときに、候補のツール一覧を示して選び直させる再試行です。3つ目は、制約をかけたうえで1回だけ修正させる処理です。
評価には、9B（90億パラメータ）のオープンモデルQwen3.5-9Bを使いました。BFCL（Berkeley Function Calling Leaderboard：関数呼び出しの正確さを測る代表的なベンチマーク）から作った200問のBFCL-200では、正答率が0.580から0.805に改善しています。300問のDICE-300でも0.717から0.813に上がりました。ドリフトが原因の失敗のうち、BFCL-200では45件中33件、DICE-300では22件中19件を立て直しています。修復によって新たな失敗が生じた例は観測されていません。
どの変化が一番効くかを調べた分析も実用的です。説明文やスキーマの書き換えだけなら、影響は比較的小さく収まりました。最も大きく精度を下げたのは、候補のツール一覧の変化、特に紛らわしいツールが追加される場合です。似た名前や似た説明のツールが並ぶと、モデルは選択を誤りやすくなります。なお、コードは公開されていません。
これからどうなるか
この論文の価値は、仕組みの単純さにあります。スキーマ検証も再試行も、多くの開発者がすでに部分的に書いている処理です。それを体系立てて組み合わせるだけで、9B級のモデルでも大きく精度が回復することを数字で示しました。一方、検証は1つのモデルと2つの評価セットに限られます。大型モデルや実際のサービスで同じ効果が出るかは、今後の確認が必要です。
開発者が今日から活かせる点は2つあります。まず、ツールの出力をJSON Schemaで検証し、失敗時は候補一覧を添えて1回だけ再生成させる処理を入れることです。次に、エージェントに渡すツールの数を絞り、名前や説明が紛らわしいものを並べないことです。MCPサーバーを複数つなぐ構成ほど、この2点が効いてきます。
まとめ
ツール定義の変化で関数呼び出しが崩れる問題に、再学習なしの修復層で対処した論文です。Qwen3.5-9BでBFCL-200の正答率を0.580から0.805へ上げ、失敗の多くを立て直しました。最大の敵は紛らわしいツールの追加で、ツール一覧の管理が精度を左右します。
参考リンク
- arXiv: Robust Function Calling for LLM Agents Under Interface Drift
- Berkeley Function Calling Leaderboard
アイキャッチ画像: Photo by Matthieu Joannon on Unsplash
