ログやイベント列から導出する推定量（時間内訳・件数・コストなど）を、同じログ内の参照値（ground truth）と突き合わせて採用可否を決める設計では、参照値が (1) 疎（全区間の一部にしか存在しない）かつ (2) 一部が汚染されている（推定したい量と異なる意味を含む）場合、推定量の総和と参照値の総和を直接比較する検算は構造的に成立しない。差が「推定の誤り」なのか「参照値の欠落・意味差」なのか分離できず、正しい推定器でも恒常的に不合格になる（fail 側に倒れる欠測が系統化する）。

判断基準

• 検算は「参照値が存在し、かつ意味が推定量と一致する clean な部分窓」に限定し、分子（窓内の推定量）と分母（clean 窓の参照値合計)の両方を同じ窓集合で揃える。汚染された窓は分子・分母の双方から除外する（分母にだけ残すと恒常乖離、分子にだけ残すと検算が自己肯定化する）。
• 窓が clean かどうかは、汚染の混入を示す決定的なイベント（例: 参照値が覆う区間の内部に別の開始イベントが挟まる）で機械判定できる形に定義する。ヒューリスティックな「だいたい合う窓」を許すと検算自体が信用できなくなる。
• clean 窓がゼロのログは「検算合格」でも「不合格」でもなく「検算不能（null）」として第三の状態に分離し、採用判定の別条件（パース品質指標など）へ委ねる。0 と null を区別しないと、検算不能が合格または欠測として黙って集計される。
• 検証されるのは clean 窓の内側だけで、窓の外は推定規則の妥当性を外挿して信頼している。この検知不能域と推定規則のバイアス方向（過大か過小か）を契約・ドキュメントに明記する。

適用条件と落とし穴

• 参照値が全区間を密に覆い意味も一致するなら、総和比較のほうが強い検証になる。この手法は密な参照値が得られない場合の次善策。
• 汚染窓が大きいほど clean 窓が減る構造（重い作業ほど検算不能になる）を持つ場合、検算不能ログの比率や窓カバレッジ（clean 窓の参照値合計 対 推定量総和）を併記しないと、検証の空洞化に気づけない。
• 導入時は、旧検算で恒常不合格だった実データの時点を再現し、新検算での乖離と、故意に汚染窓を混ぜた検体での除外動作の両方を確認する（合格側・除外側の両方向を実測する）。

背景例（一般化）

エージェントセッションのイベントログから「待ち時間を除いた実働」を推定し、クライアントが記録するターン所要時間を参照値として検算するケースで、参照イベントが全ターンの一部にしか出力されず、委譲待ちを内包する長大ターンの所要時間は実働と意味が一致しなかった。総和比較では正しい推定器が数百%乖離で恒常欠測になり、clean 窓限定の検算に変えることで実データ再現の乖離が 0% になった。