AIのコードが正しくても、実行経路で壊れる——QuoteBenchが見つけた『見えない失敗』

01 / QUICK GUIDE

まず、30秒でつかむ

01
QuoteBenchは、AIが一度だけ作るBash命令を56課題で試し、回答を直接実行する場合と、追加の解析処理を一つ通す場合を比べた研究です。
02
同じ回答を追加処理へ通すと、8構成すべてで成功率が55.4〜73.2ポイント低下しました。境界を事前に説明すると、6構成は30.4〜60.7ポイント回復しました。
03
論文は査読前で、Bashの文字処理を切り出した制御実験です。Windows、認証、実ネットワーク、対話しながらのやり直しは対象外です。

02 / KEY WORDS

ここだけ押さえれば、残りの本文はスムーズに読めます。

03 / THE FACTS

研究チームは、14種類の操作を各4件に分け、合計56件の一回実行型Bash課題を作りました。各種類には普通の文字列が1件と、引用符や改行など壊れやすい文字を含む3件があります。

AIの回答をそのまま実行する経路と、遠隔操作やコンテナ実行をまねて解析処理を一つ追加する経路で比べました。追加側は、同じ命令がもう一度読み直される境界を意図的に作っています。

8つの同時期構成で、同じ回答を追加経路へ移すと成功率は55.4〜73.2ポイント下がりました。境界があるとAIへ知らせて書き直させると、6構成は30.4〜60.7ポイント回復し、2構成は回復しませんでした。

GPT-5.6 Solでは、普通の比較だけだと差はマイナス3.6ポイントでした。しかし内訳は、経路による64.3ポイントの損失と、説明を受けた書き直しによる60.7ポイントの回復が打ち消し合った結果です。

失敗した実行の23.4〜47.0%は終了コード0を返していました。処理が『成功』と表示されても、ファイルの中身やGitの履歴など最終状態は間違っていたため、研究では結果そのものを検査しています。

THE CONCLUSION

QuoteBenchは、AIモデルの回答が正しくても、製品側が包み直して実行する途中で壊れる可能性を数字で示しました。同じ回答を追加パーサーへ通すだけで、大きな低下が出ています。

つまり、モデルの点数をそのまま製品の信頼性だと思ってはいけません。AI、受け渡し形式、実行環境、最後の確認を一つの仕組みとして試す必要があります。

04 / THE CONTEXT

開発用AIは、文章を提案するだけでなく、端末や遠隔サーバーへ命令を送るようになりました。回答が道具へ届くまでに、構造化、保存、引用符の追加、再解析が重なる場面が増えています。

従来の比較では、AIが答えた命令と実行環境を一組にして点数を出すことが多く、どこで壊れたかが見えませんでした。QuoteBenchは同じ回答を再生し、AIと経路の責任を分けました。

この違いは運用に直結します。モデルを入れ替えなくても、受け渡し方法を直すだけで改善する場合があり、逆にモデル更新だけでは消えない失敗もあります。

05 / WHAT IT MEANS FOR YOU

非エンジニアにも、住所を正しく書いたのに、転記用の表が記号を消して配送先が変わる場面だと考えると分かりやすいでしょう。書き手だけでなく転記の仕組みも検査対象です。

会社がAIエージェントを選ぶときは、提供元の点数だけでなく、自社で使う画面、権限、端末、遠隔実行まで通した試験が必要です。最後のファイルや設定を正解と照合してください。

一方、55.4〜73.2ポイントという数字を、AI開発ツール全体の失敗率に置き換えてはいけません。これは追加パーサー一つを意図的に置いた56課題での低下幅です。

研究対象はPOSIX/Bashで、PowerShell、Windowsの命令、認証、実ネットワーク、長い対話による復旧は含みません。査読前でもあり、別環境で同じ幅になるとは限りません。

07 / NEXT ACTION

BOTTOM LINE