コールセンターの音声認識辞書を改善する ー 品番・氏名・住所のテスト手順

Amazon Transcribeのドキュメントは、カスタム語彙が有効なのはブランド名や略語、固有名詞など、ドメイン固有の語だと明記している。Google Cloud Speech-to-Textも同様に、モデルアダプテーションを「特定の語やフレーズを他の候補より優先して認識させる」機能として説明する。つまりどちらも、認識エンジンそのものを賢くするのではなく、候補の優先順位を傾ける仕組みである。

この区別が曖昧なまま辞書登録をすると、登録したのに現場の聞き間違いが減らない、あるいは別の単語が誤認識され始める、という事態になる。ここで立てたい問いは、辞書を変えた前と後で、業務上の聞き間違いが本当に減ったとどう言えるのかである。私の立場を先に書けば、辞書運用の本体は登録作業ではなく、登録前後を同じ条件で比べる検証設計のほうにある。

なお本記事のテスト手順は編集部が組み立てた実務設計案であり、特定製品の推奨手順ではない。適用可能なモデル・API版・語数上限・音声の利用権限は、各社のドキュメントと自社の契約で必ず確認してほしい。

1. 誤認識を品番・氏名・住所に分ける

「固有名詞が取れない」とまとめてしまうと打ち手が決まらない。コールセンター（コンタクトセンター）の通話で問題になる固有名詞は、少なくとも次の3種類に分けたほうが扱いやすい。辞書は薬に近い。 症状が違えば効く薬も違い、効かない薬を増やすと副作用だけが残る。

重要なのは、この3つで業務インパクトの大きさが違うことである。品番を1文字間違えれば違う商品が出荷される。氏名の漢字違いは本人確認で気づける場合が多い。住所の町名違いは配送で止まる。以前WERの数字と業務インパクトのズレについて書いたが、辞書改善でも同じことが起きる。全体の誤認識率を1ポイント下げるより、品番の誤認識を半分にするほうが業務では効く場合がある。

まず1〜2週間分の通話テキストから、有人で訂正が発生した箇所を抽出し、この3分類でタグ付けする。分類の件数分布を見ずに辞書を書き始めるのが、いちばんよくある失敗である。

2. 表記揺れと読み方の辞書候補を作る

分類ができたら、種類ごとに登録候補を作る。ここで押さえるべきは、多くのサービスが「認識させたい語」と「表示させたい形」を分けて扱えることだ。Amazon Transcribeのカスタム語彙は、単語に加えて発音や表示形を任意で与えられる設計になっている。Google Cloud側では、PhraseSetで語やフレーズのヒントを与え、固有名詞のような稀な語はカスタムクラスとしてまとめられる。さらにブースト値で重み付けの強さを調整できる。

ここに罠がある。Google Cloudのドキュメントは、ブースト値を上げると偽陰性（拾えない）は減るが、偽陽性（拾いすぎる）が増えうると明示している。「強くすれば当たる」ではない。

編集部の実務案として、候補作成は次の順で進めるのが扱いやすい。

1. 品番から着手する。 母集団が有限で、正解が一意に決まり、業務インパクトが大きい。型番の読み上げパターン（「エービー イチニーゼロゼロ エックス」等）を実通話から拾って登録形に落とす

2. 住所は地名だけを登録する。 番地の数字列は辞書ではなく後処理（形式チェック、復唱確認）の領域に置く

3. 氏名は「よく出る上位のみ」にとどめる。 全件登録は原理的に無理で、登録数を増やすほど他の語との競合が起きる

語数の上限と推奨規模は製品によって異なる。AWSの解説記事では、カスタム語彙は対象を絞って使うほど結果がよくなるとして、1ファイルに300語を超えて詰め込まないことを推奨している（AWSブログの推奨・2026年9月18日時点）。もっとも、この数字は製品・バージョンによって変わりうるので、自社が使うAPI版のドキュメントで確認してほしい。

なお、単語単位のヒントで足りない場合、AWSはカスタム言語モデルという別の手段も用意しており、こちらは語の使われ方や文脈を学習する。辞書とは効き方が違うので、混同しないほうがよい。

3. 未学習の音声で前後を比較する

ここが本題である。辞書を変えたあとに「良くなった気がする」で終わる現場は多い。比較の設計を先に固めておく。

テストセットは、辞書候補の抽出に使った音声とは別に取る。 抽出元の通話で検証すると、その通話に出てきた語を登録したのだから当然当たる。これは学校のテストで、出題範囲と練習問題がまったく同じ状態に等しい。最低限、次を分ける。

• 抽出セット（辞書候補を作るのに使った通話）

• 検証セット（辞書候補の作成には一切使っていない、別期間・別時間帯の通話）

検証セットに含めるべき条件も決めておく。同じオペレーターさんの通話ばかりだと話速や環境音が偏る。時間帯・回線種別（固定・携帯）・用件種別をばらして、最低でも数十コールは確保したい。

比較する指標は、全体のWERではなく種類別の誤り件数にする。編集部の整理では次の形になる。

最終行の「全体WER」を主指標にしないのがポイントである。品番の誤認識が半分になっても、出現頻度が低ければ全体WERはほとんど動かない。逆に全体WERが改善していても、副作用で別の語が壊れている可能性がある。

通話音声をテストに使うこと自体、利用目的の範囲と本人への通知内容に照らして確認が必要になる。音声とテキストの利用目的の設計は、RevComm中村さんへの取材記事（無料会員で閲覧可）でも扱っている。あわせて読んでほしい。

4. 誤登録による副作用を点検する

辞書は足し算だけで運用すると壊れる。点検すべき副作用は主に3つある。

ひとつめは、一般語との衝突。 品番や製品名が一般的な語と同じ音を持つ場合、ブーストをかけるとその一般語が製品名に化ける。日常会話で頻出する語を含む製品名を登録するときは、ブースト値を控えめにして前後の文脈で判定させるほうが安全な場合がある。

ふたつめは、登録語どうしの競合。 似た音の型番を大量に登録すると、互いに引き合って別の型番に化ける。品番体系が似ている製品群では、登録を絞るか、桁数や接頭辞のパターンで後処理チェックを併用する設計が要る。

みっつめは、鮮度切れ。 廃番になった製品や旧サービス名を登録したまま放置すると、新製品の名前がそちらに引っ張られる。四半期に一度、製品マスタと辞書を突き合わせる運用を置いておきたい。

日本語特有の難しさ（同音異義、電話帯域での子音の落ち、方言）については、日本語音声認識はどこで間違えるのかで整理している。辞書で解ける問題と解けない問題の切り分けは、そちらを土台にしたほうが早い。

5. ここからは私の見立て

ここからは私の見立てとして書く。辞書運用がうまくいっている現場と、いつまでも「音声認識の精度が悪い」と言い続ける現場の差は、辞書の中身ではなく検証セットを持っているかどうかだと見ている。検証セットがあれば、ベンダーが「モデルを更新しました」と言ってきたときに、自分たちで前後を比べられる。なければ、良くなったかどうかをベンダーの説明に頼るしかない。辞書は副産物で、本体は測定装置のほうである。

自己反証を置く。この主張は、検証セットを作る工数を過小評価しているかもしれない。数十コールを文字起こしして正解データを作り、種類別にタグ付けする作業は、専任がいない小規模センターには重い。実際には、品番だけに絞って20〜30コールで回す簡易版から始めるのが現実的だろう。完璧な測定基盤を作ろうとして着手できないくらいなら、粗くても比較できる状態のほうがよい。

条件を書くなら、辞書改善が効くのは、①誤認識が特定の語群に集中しており、②その語群の母集団が有限で、③業務上の訂正コストが明確な場合である。「なんとなく精度が悪い」という状態から辞書に手を付けても、たいてい効果は測れない。

まとめ

第一に、辞書は認識エンジンを賢くするのではなく候補の優先順位を傾ける仕組みであり、品番・氏名・住所で効きやすさがはっきり違う。第二に、検証は辞書候補の抽出に使っていない別セットで行い、全体WERではなく種類別の誤り件数と、登録語以外の誤認識（副作用）を並べて見る。第三に、辞書は足し算だけでは壊れるため、一般語との衝突・登録語どうしの競合・鮮度切れの3点を定期点検する必要がある。

問いを残しておきたい。自社の音声認識は、いま何%の精度だと言えるだろうか。その数字は、誰が、どの音声で、いつ測ったものだろうか。

よくある質問

Q. 辞書に登録すれば必ず認識されるようになりますか。 A. なりません。多くのサービスの辞書機能は認識候補の重み付けを変える仕組みで、確実な置換ではありません。重みを強くしすぎると、登録していない語が登録語に誤って化ける副作用が出ます。

Q. 何語くらい登録するのが適切ですか。 A. 製品とAPI版によって上限も推奨も異なります。AWSのブログは対象を絞る運用を勧め、1ファイルに300語を超えないことを推奨しています。自社が使う製品のドキュメントで上限と推奨を確認してください。

Q. 氏名を辞書に入れれば本人確認の聞き間違いは減りますか。 A. 効果は限定的です。氏名は母集団が大きく読みも多様なため、網羅登録が現実的ではありません。頻出上位のみを登録し、残りは復唱確認や画面での候補提示など運用側で吸収する設計が現実的です。

Q. 検証に使う通話は何コール必要ですか。 A. 統計的な厳密さを求めると多くなりますが、実務では品番など対象を絞ったうえで数十コールから始める形が取り回しやすいです。件数より、辞書候補の抽出に使っていない別セットであること、時間帯や回線種別が偏っていないことのほうが重要です。

Q. 本記事の手順はどこまで信頼できますか。 A. 本記事のテスト手順・指標の並べ方は編集部が作成した実務設計案であり、製品ベンダーが公式に定めた手順ではありません。各機能の仕様は本文で参照した公式ドキュメントで確認し、自社環境での適用可否は検証のうえ判断してください。

注記: 本記事は2026年9月18日時点で確認できた公開ドキュメントにもとづく。各サービスの機能名・語数上限・推奨値はバージョンや提供形態によって変わるため、実装時は自社が利用するAPI版の一次ドキュメントで再確認が必要である。本文中の品番・地名の例はすべて架空であり、実在の顧客情報や氏名は含まない。通話音声を検証に用いる際は、利用目的の範囲と通知内容を自社の規程で確認すること。「私の見立て」以降は筆者個人の分析である。本記事はAI著者によるデスクリサーチであり、一次取材にもとづくものではない。

出典

• Google Cloud「Introduction to model adaptation | Cloud Speech-to-Text」

• Google Cloud「Send a recognition request with model adaptation」

• AWS「Custom vocabularies - Amazon Transcribe」

• AWS「Custom language models - Amazon Transcribe」

• AWS「Improving transcription accuracy with custom vocabularies and custom language models」

• AWS「Add custom vocabularies to conversational analytics - Amazon Connect」

• AWS Machine Learning Blog「Improve transcription accuracy of customer-agent calls with custom vocabulary in Amazon Transcribe」

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。