検出器の精度ではなく誤検知時の体験で仕様を書く
リアルタイム AI アプリで、映像からの動き・イベント検出を作っていました。フレーム差分ベースの検出器は誤検知と取りこぼしだらけで、取りこぼしを減らせば誤検知が増え、誤検知を減らせば無反応になるため、閾値を調整する精度チューニングに終わりが見えません。
チューニングをやめて検出結果の「使い方」を信頼度で二層に分ける設計にしたら、低信頼側の検出器は雑な実装のまま出荷できました。
設計: 検出を二層に分ける
高信頼シグナル（明示的なユーザー操作、確度の高い入力）には、断定的な反応と記録への書き込みを許します。
低信頼シグナル（フレーム差分・輝度変化のような雑な CV）には、次の制約を課します。
- 出力は「お、始まったか!?」のような疑問形の先走り反応のみ
- 間違っていたら自己訂正するか、ユーザーの訂正を無条件で受け入れる
- 数値・履歴・成績のような後に残る記録には書かず、記録の更新は高信頼側だけに任せる
- 先走り反応をセッション N 回までに抑える頻度予算を設ける。同じ先走りを何度も繰り返すと飽きられて演出として成立しなくなるからです
この制約の下では、低信頼検出器の誤検知は「間違い」ではなく「早とちり」になります。AI のキャラクターが早とちりして違っていたら引っ込むやり取りが、そのまま会話のきっかけになります。
実証: 約 30 行のフレーム差分で 6 サイクル
映像を見て実況する音声 AI に、この二層設計でシーン遷移の検出を組み込みました。低信頼側の検出器は 64x48 のグレースケールに縮小した画像のフレーム差分で、実装は約 30 行、閾値は勘で決めた値のままです。
この検出器でシーン遷移の進行がハンズフリーで 6 サイクル回りました。途中の誤検知は疑問形の先走りとして出るだけで、記録には確定イベント（高信頼側）だけが書き込むため正確なままです。recall も precision も測らなくても出荷できる設計にしたので、どちらも測っていません。
機構: 仕様の書き方が精度要求を作っていた
検出器の要求仕様を precision / recall で書くと、その数値に到達するまでチューニングが終わりません。しかも「何 % なら十分か」は体験から逆算しにくく、根拠の薄い目標値になりがちです。
仕様を「誤検知したとき、ユーザーは何を体験するか」で書き換えると、精度要求そのものが消えます。誤検知しても反応が疑問形で終わり、ユーザーが訂正でき、記録に誤りが残らないなら、検出器は雑でかまいません。逆に、体験コストを下げられないシグナル（記録への書き込みなど）には明示的な操作を割り当てます。
LLM のキャラクターと組み合わせる場合は、訂正されたときの受け答え（「そうか、まだだったか」）までキャラクター設計に含めるのが要点で、そうしておくと誤検知がユーザーの発話を誘発するきっかけにすらなります。黙って正確な検出器よりよく喋る早とちりの方が、対話の総量は増えます。
誤検知を演出にできない検出には使えない
- この設計が使えるのは、誤検知を先走りの演出として見せられるプロダクトに限られます。記録・課金・安全に直結する検出は疑問形の先走りで済ませられないため、従来どおり精度が要ります
- 低信頼シグナルは仕様として記録に書けないままで、「検出したのに何も残らない」ことを設計として受け入れる必要があります
- 頻度予算の N は体験を見て勘で決めた値で、根拠のある算出方法は持っていません
雑な検出器を出荷するための 4つの決まり
- 検出器の要求仕様を精度（recall / precision）ではなく、誤検知時の体験で書く
- 低信頼シグナルの出力は疑問形に限定し、記録には書かせない
- 訂正の受け方までキャラクター設計に含める
- 先走り反応には頻度予算を付け、同じ先走りの繰り返しで演出が飽きられるのを防ぐ
「精度が足りないから出荷できない」と思っていた検出器で問題だったのは、その出力に断定と記録を許していた仕様でした。仕様を直したら、勘で閾値を決めた約 30 行の検出器で足りました。