【要約】壊れ方には家系がある — 6 モデル×修復器 3 世代の実測で tool call 修復の限界に触れた話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がLLMを用いたエージェントを構築・運用する際、モデルが生成する不適切なTool Callがシステム全体の停止や誤動作を招く。著者は以下の技術的課題を特定した。
- モデルごとに異なる「壊れ方の家系」が存在する。モデルファミリーごとに、Python風やRuby風といった特有の構文エラーが発生する。
- 構文のラップ形式が多様である。XMLタグやJSONオブジェクトで関数呼び出しが包まれるケースがあり、パースを困難にする。
- 修復不可能なエラーが存在する。モデルが空の応答を返した場合、テキストベースの修復器では対応できない。
- モデルごとに異なる「壊れ方の家系」が存在する。モデルファミリーごとに、Python風やRuby風といった特有の構文エラーが発生する。
- 構文のラップ形式が多様である。XMLタグやJSONオブジェクトで関数呼び出しが包まれるケースがあり、パースを困難にする。
- 修復不可能なエラーが存在する。モデルが空の応答を返した場合、テキストベースの修復器では対応できない。
// Approach
開発者がCodeRouterを用いて、構文の「形」を修復しつつ「意味」の破壊を防ぐ多層防御アプローチを採用した。具体的には以下の手法を実装した。
- R4修復器による3つの新クラスの実装。nested-XML、JSONエンベロープ、および「呼び出し構文族（name(...)形式）」を単一のパーサで処理する。
- 偽陽性（False Positive）を0%に抑える設計。許可リスト（allowed_tool_names）との照合を必須とし、未知の関数名は修復対象から除外する。
- 空応答に対するFallbackChainの導入。コンテンツが空の場合、同一リクエストを即座に別のプロバイダーへ再ディスパッチする。
- R4修復器による3つの新クラスの実装。nested-XML、JSONエンベロープ、および「呼び出し構文族（name(...)形式）」を単一のパーサで処理する。
- 偽陽性（False Positive）を0%に抑える設計。許可リスト（allowed_tool_names）との照合を必須とし、未知の関数名は修復対象から除外する。
- 空応答に対するFallbackChainの導入。コンテンツが空の場合、同一リクエストを即座に別のプロバイダーへ再ディスパッチする。
// Result
開発者がCodeRouterの各世代を用いてベンチマークを実施した結果、Tool Callingの成功率が劇的に向上した。主な成果は以下の通りである。
- 特定モデルの成功率向上。qwen2.5-coderは0%から100%へ、mistralは80%から100%へ、phi4-miniは20%から80%へと改善した。
- 空応答問題の解決。gemma4における20%の空応答を、フォールバック機構により100%回収することに成功した。
- 高い信頼性の実証。修復器の強化後も、偽陽性は0件を維持し、テストケース1553件をパスした。
- 特定モデルの成功率向上。qwen2.5-coderは0%から100%へ、mistralは80%から100%へ、phi4-miniは20%から80%へと改善した。
- 空応答問題の解決。gemma4における20%の空応答を、フォールバック機構により100%回収することに成功した。
- 高い信頼性の実証。修復器の強化後も、偽陽性は0件を維持し、テストケース1553件をパスした。
Senior Engineer Insight
> 実戦投入において、構文の「形」と「意味」を分離する設計思想は極めて合理的である。偽陽性を0%に抑える設計は、誤った関数実行による副作用を防ぐために不可欠だ。また、エラーをモデル単位ではなく「構文族」として捉えるアプローチは、モデル追加時の保守コストを劇的に下げる。ただし、引数内容の改変（意味の崩壊）は修復不能であり、その境界を明確に定義している点も、システムの予測可能性を高める上で高く評価できる。