評価スクリプト・ベンチ・受入ゲートが、本番で使う設定値（閾値・タイムアウト・並列度・サンプリング率）と違う既定値で動いていると、本番で起きている不具合が合格として通る。しかもこの食い違いは、数値そのものが正しく見えるため気づきにくい。

観測した失敗

検出モデルの合格判定スクリプトが既定の信頼度閾値で動いており、製品側の閾値はそれより高かった。長期間この差に気づかず、判定は「合格」を出し続けていた。製品側の閾値で測り直したところ、同じモデルが評価軸の大半で不合格になり、実機で報告されていた症状はすべて軸に現れていた。見えていなかったのは軸が足りなかったからではなく、出荷しない条件で測っていたからだった。

判断基準

• 評価側と製品側に同じ意味のパラメータがあるなら、評価側の既定は製品側の値をそのまま既定にする。片方だけ変えられる作りにしない
• どうしても分けるなら、両者が同じ値であることを機械的に検査するか、少なくとも評価出力に使用値を必ず印字する
• 「甘い条件でも測っておく」ことに価値はある（余裕の把握）が、それは追加であって既定ではない

確認方法

合格しているゲートを、現行の本番設定値でもう一度走らせる。結果が変わるなら、そのゲートはこれまで何も保証していなかった。新しい軸を足す前にこれをやる。

一般化

同型の失敗は、負荷試験を本番と違う並列度で回す、リトライ有効な経路をリトライ無効で検証する、サンプリングを外して観測する、などにも起きる。測る条件が出荷する条件と一致しているかは、指標の値より先に確認する。