研究が明らかにしたマルチモデル査読パイプラインの参照ずれ：検証モデルが正しいロールバックを誤りと判定する可能性

マルチモデルによる「ドラフト作成—検証—修訂」は、単発の生成よりも信頼性が高いと考えられることが多い。最初のモデルが回答を提示し、2番目のモデルが誤りを探し、3番目のモデルが判定して修正する。しかし、新たな研究によると、パイプライン自体が「参照ずれ」を引き起こす可能性がある。たとえば、デプロイ指示に「Previous Version」と「Current Version」が併記されている場合、ドラフト作成モデルはロールバック先を、アップグレード前に稼働していた current バージョンだと解釈する。一方、検証モデルはフィールド名に従い、さらに古い previous バージョンへ戻すべきだと主張する。どちらの言語的解釈にも妥当性はあるが、実際の運用時系列に合致するのは一方だけだ。

研究では、この種の衝突を10件の基本ケースにまとめ、各ケースに3つの条件を設定し、合計30件の合成刺激を作成した。そのうえで、6モデルを21種類の推論設定で評価した。バランス精度（balanced accuracy）は0.156からほぼ満点まで大きくばらついた。GPT‑5.2は、推論を無効にした場合の0.156から、最高の推論強度では0.942まで向上した。Gemini 3 Proはすべての設定で0.94を上回り、低推論設定でも、GPT‑5.2の最高推論設定の約5%という1回当たりのコストで、それを上回った。エラー分析では、モデルがフィールドラベルや検証モデルによる誤分類に引きずられやすいことが示された。正しい運用ロジックをすでに説明できている場合でも、最終的には誤った判定を受け入れるケースがあった。

エンジニアリング上の直接的な教訓は、ステージ間で内容を受け渡す際に、視点によって意味が変わる「前の」「現在の」「元の回答」といった語を残すべきではないということだ。代わりに、バージョン番号、タイムスタンプ、オブジェクトID、明示的な状態遷移を使用すべきである。また、検証モデルは単なるエラーラベルだけでなく、参照している対象も出力する必要がある。研究チームは、刺激、集計結果、図表を再構築するためのコードを公開している。ただし、サンプルは10種類のシナリオに限られ、ベンダーから得た元の応答や推論トレースの一部はリポジトリに含まれていない。そのため、すべてのエージェント型ワークフローで同程度の失敗率が生じると結論づけることは、現時点ではできない。