同じAI出力でも、実行経路で64.3ポイント壊れる。QuoteBenchが暴いた評価の盲点
AIコーディングエージェントが、Bashコマンドの94.6%を正しく作れたとします。
かなり信頼できそうです。ところが、その出力をリモート実行用のラッパーへ通した瞬間、成功率が30.4%まで落ちる場合があります。
モデルは同じです。質問も同じです。生成済みのコマンドも一文字も変えていません。違うのは、実行前にパーサーを一つ通したことだけです。
2026年8月13日に公開された論文「QuoteBench: How Matched Scores Can Hide Command-Path Failures」は、この境界を56件の実行検証付き課題で測りました。
8種類すべてのモデル構成で、同じ出力にパーサーを一つ加えると成功率が55.4から73.2ポイント低下しました。それでも、モデルへ事前に実行経路を伝えると、6構成は30.4から60.7ポイントを取り戻しました。
その結果、通常の評価では「ほとんど差がない」ように見えることがあります。GPT-5.6-solの二つの対応した経路を比べると、差はわずか3.6ポイントでした。しかし内側では、実行経路が64.3ポイントを壊し、モデルの適応が60.7ポイントを埋め戻していました。
QuoteBenchが示したのは、モデル評価の単位がモデルだけでは足りない、ということです。生成契約、シリアライザー、ラッパー、パーサー、実行環境、検証器まで含めて、初めて実際のエージェント性能になります。
正しいコマンドが、途中で別の意味になる
Bashでは、引用符、ドル記号、バッククォート、改行、ワイルドカードが特別な意味を持ちます。モデルがそれらを正しく扱っても、後段のラッパーが文字列をもう一度解釈すると、意味が変わることがあります。
たとえば、モデルが「$HOMEという文字列をそのままファイルへ書く」コマンドを生成したとします。直接Bashへ渡せば、適切な引用でドル記号を文字として保存できます。
しかし、そのコマンド全体を別のbash -cの二重引用符へ埋め込むと、外側のシェルが先に$HOMEを展開する可能性があります。モデルが作ったコマンド単体は正しくても、運搬中に意味が変わります。
同じ問題は、次のような場所で起こり得ます。
- SSHでリモートコマンドを文字列として渡す
- コンテナ内の
sh -cへコマンドを埋め込む - CIの実行ステップへ複数行コマンドを渡す
- JSONやテンプレートを経由してコマンド文字列を復元する
- エージェントのtool callを別のランナー形式へ変換する
重要なのは、各部品が単独では正しく見える点です。モデル出力は正しい。JSONも正しい。ラッパーも構文上は正しい。それでも、境界をまたぐと引用の責任範囲が変わります。
56件の課題で、生成と運搬を切り離す
QuoteBenchは56件の一発Bash課題で構成されています。14種類の操作があり、それぞれに一つの安全な対照と三つの危険な文字列があります。
対象には、次の操作が含まれます。
- 正確なバイト列をファイルへ書く
- 引用符や先頭ハイフンを含むファイル名を扱う
- 正規表現やglobを文字として渡す
- 複数行のheredocを作る
- 引数と環境変数へ値を渡す
- JSONやGitの状態を変更する
- 二段目のシェルを模した経路を通す
採点はコマンド文字列の一致ではありません。実行後のファイル内容、引数列、JSON、ディレクトリ状態、Git履歴が目的どおりかを確認します。別の書き方でも、最終状態が正しければ合格です。
この設計は重要です。失敗した実行の23.4%から47.0%は終了コードが0でした。つまり、プロセスだけ見れば成功なのに、成果物は間違っています。
エージェント評価で「コマンドがエラーにならなかった」を成功条件にすると、最大で半分近い失敗を見落とす設定がありました。
四つのマスで、壊した側と直した側を分ける
QuoteBenchの核心は、生成契約と実行経路を別々に動かすことです。
生成契約とは、モデルへ「どの形式で、どの経路へ向けてコマンドを作るか」を伝える条件です。実行経路とは、生成された文字列が実際にどのパーサーを通ってBashへ届くかです。
研究では、四つの組み合わせを作りました。
- 通常経路向けに生成し、そのまま実行する
- 通常経路向けに生成し、追加パーサーを通す
- 追加パーサーを伝えて生成し、その出力を通常経路で実行する
- 追加パーサーを伝えて生成し、実際にその経路で実行する
一番大切なのは2番です。1番で使った生成済みの返答を固定し、実行経路だけ変えます。結果が変われば、原因はモデルの生成能力ではなく、その後の運搬にあります。
4番と2番の差は、同じ追加パーサー上で、実行経路を知らされたモデルがどれだけ生成方法を変えたかを表します。
3.6ポイント差の中に、二つの巨大な変化が隠れた
GPT-5.6-solの固定構成を見ると、通常向け出力をそのまま実行した成功率は94.6%でした。
同じ出力を追加パーサーへ通すと30.4%です。差は64.3ポイントで、生成後に壊れた分です。
一方、モデルへ追加パーサーの存在を一文で伝え、その経路で実行すると91.1%まで戻りました。壊れた30.4%から60.7ポイントを補償したことになります。
通常経路の94.6%と、経路を伝えた追加パーサーの91.1%だけを比べると、差は3.6ポイントです。
この二つだけを見れば、「ラッパーを変えても性能はほぼ同じ」と結論したくなります。しかし実際には、ラッパーが64.3ポイントを壊し、モデルが60.7ポイントを補っていました。
この相殺は、評価を危うくします。
モデルがラッパーへ適応している間は問題が見えません。ところが、別のランナーへ移行する、SSHの書き方を変える、引用符の階層を増やすといった変更で補償が効かなくなると、突然性能が崩れます。
実際、8構成のうち6構成は30.4から60.7ポイントを補償しましたが、Qwen3.5-27Bは0ポイント、Gemini-3.1-Flash-Liteは5.4ポイント悪化しました。経路を説明するだけで全モデルが同じように直るわけではありません。
さらに、あるラッパー向けに適応したコマンドは、別の文法へ安定して移りませんでした。補償は一般的なBash能力というより、伝えられた境界への条件付き適応です。
構文が正しいことと、実行結果が正しいことは別
静的解析や構造化tool callなら防げるのでしょうか。
QuoteBenchでは、ShellCheckが検出できたnested-only failureは34.6%でした。およそ3分の2は見逃されています。
理由は、モデルが出したコマンド単体には構文上の問題がない場合があるからです。壊しているのは、後段でそのコマンドを別の文字列へ埋め込む操作です。解析対象を生成物だけに限定すると、境界の問題は見えません。
構造化tool callも万能ではありません。六つのprovider-hosted modelを調べたキャンペーンでは、tool callの形式遵守率は98%から100%でした。それでも、最終状態の正解率は85.7%から98.0%です。
正しいtoolを選び、schemaに合う引数を送っても、その引数に入ったBash文字列が目的の状態を作れるとは限りません。
構造化呼び出しは外側の封筒を守ります。封筒の中にさらにシェル言語が入っているなら、内側の意味は別に検証する必要があります。
単純な修正が、問題の所在を証明した
この研究の価値は、新しい引用アルゴリズムを発明したことではありません。修正自体は驚くほど単純です。
追加パーサーへ埋め込む地点で正しくエスケープすると、448組すべてで通常経路の結果を再現しました。生成済みの返答を一時スクリプトへ書き、そのファイルを実行する方法でも、公開448組と非公開126組すべてで同じ結果を再現しました。
モデル出力を変えず、境界の扱いだけ直して損傷が消えた。だからこそ、原因が生成能力ではなく運搬経路にあると分かります。
ただし、一時スクリプトなら何でも安全という意味ではありません。生成コードを実行する以上、ネットワークを切ったコンテナ、時間制限、作業ディレクトリの分離、生成物の検証は必要です。
研究の公開ハーネスも、固定したGNU/Linuxコンテナを使い、ネットワークを無効化し、毎回新しいfixtureで実行しています。
実務ではモデル名より、行動経路を版管理する
ここからは、論文結果を基にしたAICompanyの実務的な解釈です。
エージェントの本番評価では、モデル名と成功率だけを記録しても再現できません。少なくとも、次の情報を一組で残す必要があります。
- モデルIDと推論設定
- モデルへ見せた生成契約
- tool callのschema
- JSON、テンプレート、SSH、コンテナなどの運搬経路
- 途中で何回パースされるか
- OS、シェル、主要utilityの版
- 終了コードではなく最終状態を確認する検証器
同じモデルへ切り替えただけでも、SDKやrunnerが違えば別のシステムです。逆にモデルを更新しても、経路が固定されていれば変化の原因を切り分けやすくなります。
運用上の対策は、次の順で考えられます。
不要な文字列埋め込みを減らす
コマンド全体を何重にも引用するより、引数配列や型付き操作で値を渡せるなら、その方が境界を明示できます。
境界で一度だけ正しく変換する
エスケープ責任をモデル任せにせず、シリアライザーやexecutorの一か所へ集めます。同じ値を複数層でそれぞれ再解釈しない設計が重要です。
実行経路と同じ条件で評価する
ローカルのbash -cで通ったコマンドを、実際にはSSHやCIで使うなら、評価も同じ経路で行います。モデル単体のベンチマークは予備測定であり、出荷判定ではありません。
最終状態を検証する
終了コード0、tool call成功、commit作成だけでは不十分です。ファイル内容、引数、テスト、差分、デプロイ状態など、タスクが求めた結果を確認します。
経路変更を回帰テストにする
SDK、MCP server、shell runner、CI image、SSH wrapperを更新したら、モデルを変えていなくてもエージェント評価を再実行します。
小さな確認実験を自分の環境で作る
QuoteBench全体を動かさなくても、考え方は小さく試せます。
まず、引用符、ドル記号、バッククォート、改行を含む固定文字列を用意します。次に、エージェントが作ったコマンドを直接実行する経路と、普段使うSSH、CI、コンテナの経路で実行する経路を作ります。
比較するのは出力ログではなく、生成されたファイルの正確なバイト列です。モデルの返答を固定したまま経路だけ変えれば、失敗が生成前か生成後かを切り分けられます。
さらに、モデルへ実行経路を説明して再生成し、同じ経路で実行します。そこで回復しても安心し過ぎず、別の引用形式へ変えたときに補償が移るか確認します。
これはQuoteBenchの数値を再現する実験ではありません。自社のagent harnessに、見えないパーサー境界があるかを調べるための回帰テストです。
この研究だけでは分からないこと
QuoteBenchは原因を切り分ける力が強い一方、対象は狭く設計されています。
第一に、POSIX/Bashのコマンド生成だけを扱います。PowerShellとWindows CMDは対象外です。
第二に、一発のコマンドです。計画、リポジトリ探索、対話的な端末状態、失敗後の複数ターン回復は測りません。
第三に、認証、ネットワーク障害、本物の分散環境は対象外です。SSHを使った再現はlocalhostでのパーサー境界確認です。
第四に、14種類は実際の事故から選ばれていますが、意図的に構成した有限集合です。55.4から73.2ポイントという値を、世の中のagent command全体の失敗率へ広げることはできません。
第五に、モデルごとのbest observed設定は、測った推論設定から最良の一行を選んだ記述的な表です。provider間で同じeffort名が同じ計算量を意味するわけでもありません。
第六に、型付き操作の実験は一部の操作と二モデルに限られます。シェルの解析問題を減らしても、型表現や変換ロジックの別の誤りは起こり得ます。
公開資料は充実しています。公式リポジトリ、実行コマンド、12,999件のロールアウト、manifest、checksumが公開されています。一方、Hugging Faceのinteractive viewerは現在schema cast errorを表示します。
AICompanyは公開commitを取得し、CLIが起動することを確認しました。Windowsでのlocal validationは、ベンチマークが意図的に作る*.txtというファイル名をOSが拒否して停止しました。Docker DesktopのLinux daemonも停止していたため、固定GNU/Linux環境での全検証は独立再実行していません。
これは論文が明示したPOSIX/Bash限定という範囲と整合しますが、再現済みと表現できる状態ではありません。
エージェント性能は、モデルと経路の掛け算で決まる
QuoteBenchは「Bashの引用符は難しい」というだけの研究ではありません。
同じ生成物でも、届くまでの経路が違えば結果が変わります。モデルが経路へ適応すると、その損傷が表面上のスコアから消えることもあります。
GPT-5.6-solの94.6%と91.1%だけを見れば、3.6ポイントの差です。しかし固定出力を追跡すると、64.3ポイントの損傷と60.7ポイントの補償が見つかりました。
この分解が実務に突きつける問いは明快です。
「どのモデルが強いか」だけでなく、「その出力を、どの契約で作らせ、どの経路で運び、何をもって成功としたか」を測っているか。
エージェントの能力は、モデルの中だけにありません。モデルから実世界へ出る最後の1メートルに、性能を壊す仕組みも、隠す仕組みもあります。
参考資料
- QuoteBench論文概要と書誌情報
- QuoteBench論文HTML全文
- QuoteBench公式project page
- QuoteBench公式GitHubリポジトリ
- QuoteBench公開ロールアウト
※本記事は論文、公式project page、公開リポジトリ、公開データの一次情報を基に、AICompanyが実務への適用方法を独自に整理したものです。AICompanyは論文の全評価を独立再現していません。