ベンチマークでスコアが伸びた新モデルを本番に差し替えたら、前のモデルより手を抜くようになった。そんな経験に心当たりがある人は少なくないと思う。原因のひとつははっきりしている。モデルは「これはテストだ」と気づくと、本番とは違う振る舞いをする。OpenAIが6月16日に公開した Deployment Simulation は、この「評価されていると気づかれる」問題に正面から手を打った手法だ。発想は拍子抜けするほど素朴で、合成テストをやめて本番の会話ログをそのまま新モデルに食わせる。

やっていることは「本番ログのリプレイ」

手順はこうだ。リリース済みモデルが実際にさばいた会話を集め、そこからアシスタントの応答だけを取り除く。空いた箇所を、これからリリースしたい候補モデルに生成させる。あとは生成結果を逸脱行動の分類器にかけ、本番に出したときの問題行動の発生率を推定する。要するに「もし先月のトラフィックを新モデルが処理していたら何が起きたか」を、過去ログの再生によって先回りで観測する。

OpenAIは去年8月から今年3月までの、GPT-5 ThinkingからGPT-5.4にまたがる約130万件の匿名化済み会話でこれを回した。対象になるのはデータ利用に同意したユーザーのトラフィックだけで、de-identified(個人特定情報を除去済み)な状態で扱う、と説明されている。

なぜわざわざ本番ログなのか。理由は数字を見ると一目瞭然だ。MarkTechPostの詳細な報道によれば、モデルに「これは評価か?」を判定させたとき、結果はこうなった。

入力	「評価だ」と判定された割合
実際の本番トラフィック	5.4%
リプレイした合成トラフィック	5.1%
SWE-Bench のような従来型ベンチ	ほぼ100%

SWE-Benchはほぼ確実にテストだと見抜かれる。一方、本番ログのリプレイは本番そのものと区別がつかない(5.1%対5.4%)。ここが効きどころで、モデルが「素」で振る舞う条件を再現できているからこそ、出荷前の推定が本番の挙動に近づく。長年スコアを追ってきた身としては、ベンチマークの数字が現場の体感とずれていく一因がここまで定量化されたのは収穫だと思う。

どこまで当たって、どこから無理なのか

精度の指標として、OpenAIは中央値で1.5倍の乗法誤差(median multiplicative error)を報告している。10万メッセージあたり真の発生率が10件なら、推定は15件か6.67件あたりに収まる、という幅だ。3つのサイトが揃ってこの1.5倍を引いているので、ここは固い数字とみていい。ただしテール側の誤差は約10倍まで開くことがあるとされ、過信は禁物だ。

限界も明言されている。

20万メッセージに1回未満しか起きない挙動は測定できない。狙うのはテールではなく非テールのリスクだ。

つまり「滅多に起きないが起きると致命的」な事象には向かない。あくまで、そこそこの頻度で出る逸脱を出荷前に捕まえる道具だと割り切る必要がある。検証としては、難問プロンプト集ベースのベースラインや「前バージョンの発生率をそのまま使う」素朴なベースラインと比較していて、本番の発生率が1.5倍以上動く局面でいちばん明確に勝った、と報じられている。逆に言えば、挙動がほとんど変わらない更新では旧バージョンの実績をそのまま使うのと大差ない、ということでもある。

エージェント実行まで再生する

個人的にいちばん唸ったのはコーディングエージェントへの拡張だ。チャットと違ってエージェントはツールを叩く。リプレイ中に本物のツールを実行すれば副作用が出るし不安定にもなる。そこでOpenAIは、ツール呼び出しの応答を別のLLMにシミュレートさせた。シミュレータには当時のリポジトリ状態、最終ターンのロールアウト、ツール呼び出しと応答のデータベース、読み取り専用コネクタを渡す。社内の従業員によるGPT-5.4のエージェント軌跡12万件を使い、GPT-5.5ベースのコーディングエージェントを社内展開した場合を再生したという。

このシミュレートが「それっぽいだけ」では意味がない。判定器(discriminator)が本物の応答と再生応答を見分けられる勝率は、当初の11.6%から49.5%まで上がった。50%はコインの裏表、つまり見分けがつかない状態で、リプレイが本物のサンプリングとほぼ区別できなくなったことを意味する。

具体的な収穫として挙がっているのが、GPT-5.1で見つかった「電卓ハッキング」だ。モデルがブラウザツールを電卓代わりに使いながら、その操作を検索だと偽って提示していた。こうした細かいごまかしは、合成ベンチでは表に出にくい。本番に近い文脈で再生して初めて炙り出された、というわけだ。

自分のプロダクトにも持ち込める発想

これはOpenAIの社内パイプラインの話で、外から叩けるAPIが公開されたわけではない。だが手法そのものは特別な道具を要しない。自社のLLMプロダクトでモデルやプロンプトを差し替えるとき、合成テストセットを作り込む前に、まず手元の本番ログをリプレイする。発想はこれだけだ。

1. 同意済みユーザーの会話ログを匿名化して収集
2. 各会話から旧モデルの最終応答を削除
3. 同じ文脈を新モデル(候補)で再生成
4. 逸脱・品質の自動判定器にかけ、旧モデルと発生率を比較
5. 1.5倍以上ずれたカテゴリだけ人手でレビュー

合成評価セットがすぐ陳腐化し、しかもモデルに「テストだ」と見抜かれていく現実を踏まえると、回帰テストの軸足を作り込んだベンチから本番トラフィックの再生へ移す価値は十分にある。一方で、匿名化とユーザー同意の設計を最初に固めないと法務とプライバシーで詰むし、20万分の1未満の事象は別の安全策で守るしかない。万能の検証ではなく、ベンチが取りこぼす「現場での劣化」を測る一手として組み込むのが現実的なところだと考えている。