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