指差呼称の音声をブラウザだけで自動チェックできないかと考え、まずwhisper-tinyで実測してみました。結果は「今回の用途・基準では不採用(NO-GO)」でした。判定に至った実測データ(SNR別recall、暴走生成の実例など)を共有します。
実際に行った測定条件・判定基準・集計結果はこちら:
https://ai-edge-lab.com/edge-ai-benchmarks/whisper-tiny-asr-nogo/?utm_source=qiita&utm_medium=referral&utm_campaign=w5-qiita-1&utm_content=article
1. 何を作ろうとしたか
指差呼称(指差喚呼)は、現場で「○○ヨシ！」と声に出して安全確認を行う手法です。この発話をブラウザ内で認識し、決められた呼称が正しく発声できているかを自動チェックできれば、記録や研修のチェックに使えるのではと考えました。サーバーを立てずブラウザだけで完結させたかったため、transformers.js経由でwhisper-tinyをブラウザ内推論させる方式で実測しました。
2. 測定条件
- モデル: whisper-tiny(ブラウザ内でtransformers.js経由により推論。ONNX Runtime Webはv1.27.0を使用)。一次データの実行設定より: モデルはonnx-community/whisper-tiny、dtypeはencoder int8 / decoder fp16の混合精度(一律int8指定はロードエラーになったため採用された構成)、transformers.js(@huggingface/transformers)はv4.2.0、実行デバイスは既定のwasmでした
- 実行環境: Chromium(Playwright 1.61.1のバンドル版をheadlessモードで制御)上でCPU/WASM実行(GPUは不使用)。サーバーサイドでの処理ではありません。CPU型番・OSはハーネスのログに記録がなく特定できないため、以下のレイテンシ値はこの検証環境固有の参考値として読んでください
- 実行日: 2026-07-17
- 音声条件: 静音(quiet)／SNR10dB／SNR5dBの3条件。雑音の種類・音源やSNRの算出方法の詳細はカルテ①ページにも記載がなく、本記事でも特定できません
- 発話セット: 呼称フレーズ10種と雑談(誤受理チェック用)10種を用意し、edge-tts合成音声の2話者(ja-JP-KeitaNeural／ja-JP-NanamiNeural)に読み上げさせました。1条件あたり20発話、3条件で合計60発話です
- 照合方法: ASR出力と正解フレーズをかな読みに変換し、rapidfuzzの正規化indel比で類似度を算出。類似度60以上を「一致」と判定(感度確認として50・70でも計測)。かな変換器や文字正規化の実装、RapidFuzzの関数バージョン、雑談フレーズをどの呼称候補と比較したかまではカルテ①ページに記載がなく、本記事でも特定できません
雑音生成方法・かな照合の実装詳細はカルテ①ページの記載範囲を超えるため、以下の数値はこの検証環境・ハーネス固有の実測値として読んでください(詳細な確認は冒頭のリンク先まで)。
事前に置いた判定基準は次の通りです。
| 指標 | 基準 |
|---|---|
| recall(静音) | 90%以上 |
| recall(雑音下: SNR10dB・SNR5dB) | 80%以上 |
| 誤受理率(雑談を呼称と誤判定) | 5%以下 |
| p95レイテンシ(発話終了→判定) | 2500ms以下 |
3. 結果
条件別の実測値です。
| 条件 | recall | 誤受理率 | p95レイテンシ |
|---|---|---|---|
| 静音(quiet) | 80%(基準90%に未達) | 0% | 1539ms |
| SNR10dB | 50%(基準80%に未達) | 0% | 1537ms |
| SNR5dB | 0%(基準80%に未達) | 0% | 22981ms(基準2500msに未達) |
| 雑音下合算(SNR10+SNR5、しきい値60) | 25%(基準80%に未達) | - | - |
類似度のしきい値を変えたときの雑音下recallと誤受理率です。
| しきい値 | 雑音下recall | 誤受理率(全条件) |
|---|---|---|
| 50 | 45% | 6.7%(基準5%を超過) |
| 60(採用値) | 25% | 0% |
| 70 | 25% | 0% |
4. NO-GO判定の理由
基準と実測を突き合わせると、recallが静音・雑音下のどちらも基準に届いていません。静音recallは基準90%に対し実測80%、雑音下recall(SNR10+SNR5合算)は基準80%に対し実測25%でした。数値の未達に加え、以下の2点が「不採用」の判断を後押ししました。
1点目は、意味が変わってしまう誤認識です。静音条件でも、正解フレーズ「電源オフヨシ」に対してASR出力が「電源を増やし」になるケースがありました(同じ発話のSNR10dB条件では「電源を強し」)。音自体は近い形で拾えていても、「オフ」という指示の意味が変質してしまっており、安全確認の記録用途としては見過ごせない誤りです。
2点目は、SNR5dB条件での暴走生成です。呼称フレーズ10件のうち2件で、デコーダが同じ音の生成を繰り返して停止せず、応答までに1件あたり約23秒(22979〜23021ms)かかりました。これは通常時(1.3〜1.5秒)のおよそ15倍にあたります。試行数が少ないため発生率(2/10)を母比率として扱うことはできませんが、応答が約23秒間返らない状態が実際に計測されました(推論スレッドの構成やUI操作自体への影響までは今回計測していません)。
なお、生成トークン数の上限(max_new_tokens=16)を設定すると暴走自体は解消し、SNR5dBの最大レイテンシは23021msから1792msまで短縮しました。ただしこの設定を入れてもrecallの値は変化せず、しきい値60のまま静音80%・SNR10dB 50%・SNR5dB 0%という結果でした。生成の打ち切り方を変えるだけでは、今回の構成での認識精度は改善しませんでした。
5. しきい値調整で解決しない理由
recallが足りないなら一致判定のしきい値を緩めれば改善するのではと考え、50・60・70の3水準で試しました。しきい値を50まで下げると雑音下recallは45%まで伸びますが、引き換えに誤受理率が6.7%まで上がり、基準の5%以下を超えてしまいます。逆に70まで上げても雑音下recallは25%のまま変わりません。
つまりrecallと誤受理率はトレードオフの関係にあり、しきい値という1つのパラメータの調整だけでは両方の基準を同時に満たせない、というのが今回の実測結果でした。
6. その後どうしたか
whisper-tinyがNO-GOだったことを受け、同じ試験セット・同じ照合方法のままモデルをwhisper-baseに切り替えて再測定しました。recall・誤受理率は全条件で基準を達成し、レイテンシもCPU実行では基準超過だったもののWebGPU実行に切り替えることで全条件・全指標が基準内に収まりました。条件別の数値や初回モデルロード時間の実測結果は、以下の解決編にまとめています。
→ 実測カルテ②(whisper-base + WebGPU): https://ai-edge-lab.com/edge-ai-benchmarks/whisper-base-webgpu/?utm_source=qiita&utm_medium=referral&utm_campaign=w5-qiita-1&utm_content=article
7. まとめ
今回の試験セット・基準では、whisper-tinyによるオープン語彙の全文文字起こしは、指差呼称の記録・判定用途に対して「今回の用途・基準では不採用(NO-GO)」という結果になりました。理由は、雑音下でrecallが基準に届かないこと、意味が変わってしまう誤認識が確認されたこと、そしてしきい値調整だけではrecallと誤受理率を両立できないことです。
一方で、同じ試験セット上でモデルをwhisper-baseに切り替えると基準を満たせたため、ブラウザ内ASR自体の否定ではありません。使用したモデルはonnx-community/whisper-tiny(dtype: encoder int8 / decoder fp16)で、精度不足はこの構成での実測に基づく結果です。fp32等の異なるdtype構成では結果が変わる可能性があるため、「今回検証した構成(このモデル・量子化・実行環境・雑音条件を含む)ではこの用途の基準を満たせなかった」という範囲で読んでください。試験セットも合成音声2話者・呼称10種のみでの実測なので、実際の現場の肉声・訛りなどでは結果が変わるかもしれません。検討時は自分たちの発話条件・実行環境で同様の実測をおすすめします。
