代理工具
QuoteBench:Shell 解析を1層追加するだけで、同一のエージェント指示の成功率が55.4~73.2ポイント急落
QuoteBenchはモデル出力を固定し、Bashコマンドの転送および再解析経路だけを変更することで、エージェントインターフェースに起因する障害を直接測定した。その結果、形式上の適合率がほぼ満点でも、大量の quoting と escaping のエラーが隠れている可能性が示された。

プログラミングエージェントが生成するBashコマンドは、通常、モデルからshellへ直接送られるのではなく、まずJSON tool call、文字列補間、ラッパー、または別の解析層を経由する。QuoteBenchは、見過ごされがちなこの「コマンド転送経路」を独立した評価変数として扱った。56件の単一コマンドタスクは、実際に発生した14種類のインシデントから抽出されている。各問題では文字列の一致を比較せず、隔離コンテナ内で最終的なファイルとプロセスの状態を検証するため、異なるものの正しいquoting手法はいずれも合格できる。
研究ではまず、元の契約下でモデルが生成した応答を保存し、その後、まったく同一の応答に、意図的に正しくescapeされていない二重引用符による解析層を1つ追加した。同時期の8種類のモデル設定すべてで、成功率は55.4~73.2パーセントポイント低下した。これは、損失がモデルの再サンプリングによるものではないことを証明している。この境界を事前にプロンプトで開示すると、6種類の設定では30.4~60.7ポイントを回復できた。一方、Qwen3.5-27Bは回復せず、Gemini 3.1 Flash-Liteはむしろわずかに悪化した。GPT-5.6-solは、平均スコアがいかに誤解を招き得るかを特によく示している。表面上のmatched-pathの差はわずかマイナス3.6ポイントだが、実際にはマイナス64.3ポイントの転送による損失があり、それを生成によるプラス60.7ポイントの補償が相殺していた。
別のネイティブツールテストでも、schema adherenceは98~100%を維持した一方、実際の正解率は86~100%にとどまった。有効なJSONと正しいツール名は、shellが受け取ったコマンドの意図が維持されていることを意味しない。エンジニアリング上は、モデル、生成契約、serialization方式、解析層、GNU/BSD userland、最終状態のvalidatorをまとめてバージョン管理されたテストに組み込むべきだ。著者らは、修正方法自体は目新しいものではないとも指摘している。補間箇所で正しくescapeするか、一時スクリプトを介して渡せば、この影響は解消できる。制約として、コアセットは56問にすぎず、主要な因果的結論は8種類の設定から導かれている。また、ほかのshell、長いコマンドチェーン、複数ターンにわたる自己修復はまだ対象に含まれていない。