QuoteBench、モデル出力を固定してコマンド実行経路をリプレイ――shell の解析層が1つ増えるだけで成功率が70ポイント超低下する可能性

コーディングエージェントが出力した Bash が一見正しくても、ツールインターフェースが文字列をシリアライズして wrapper に挿入し、さらに第2層の shell に渡す過程で意味が変わることがある。引用符、`$()`、バッククォート、glob、改行、空白を含むファイル名は、誤った層で早期に展開される可能性がある。評価が最終的なタスクの成否だけを見ている場合、モデルが最初から誤ったコマンドを書いたのか、harness が生成後に正しい出力を壊したのかを区別できない。

QuoteBench は、この境界を56件の単発 Bash タスクで測定する。実際のインシデントの発生メカニズムから整理した14種類の操作を網羅し、各問題をファイルのバイト列、argv、JSON、Git の状態、またはディレクトリの状態によって厳密に検証する。実験では2つの軸を交差させた。後続にもう1層のパーサーがあることをモデルに知らせるかどうか、そして同一の保存済み応答を `bash -c` に直接渡すか、エスケープされていないネストした wrapper を先に通すかである。固定した応答を再度リプレイすることで、「伝送による破損」と「契約の説明を受けたモデルがコマンドを書き換えることによる補償」を個別に算出できる。

同一期間に評価した8つのモデル設定では、生の応答を追加の解析に通すと、成功率が55.4～73.2パーセントポイント低下した。境界を明示すると、6つの設定は30.4～60.7ポイントを取り戻したが、残る2つには改善がなかった。GPT-5.6-sol の対応する総合スコアの差はわずかマイナス3.6ポイントだったが、実際には64.3ポイントの伝送時の破損と、60.7ポイントの補償が含まれていた。著者らはさらに、応答をローカル SSH 経由でリプレイした。7つの設定では、合成 wrapper による破損幅と結果が完全に一致した。一方、適切なエスケープを施すか一時スクリプトを使うと、448件の設定とタスクの組み合わせすべてで、ネストした経路に固有の失敗が解消された。

エンジニアリング上の結論は、より多くの quoting ルールをモデルに暗記させることではなく、アクション表現と解析境界をシステム契約に組み込むことだ。argv や型付き操作を渡せる場合、shell 文字列を繰り返し連結すべきではない。評価でも、生成形式、実行経路、最終状態の検証器を公開する必要がある。制約として、中心となるデータセットは56問のみで、単発の POSIX/Bash タスクを対象としており、PowerShell、ネットワークおよび認証エラー、対話型ターミナル、複数ターンでの修復は含まれない。そのため、coding agent のワークロード全体における故障率を推定することはまだできない。