コールセンターの通話録音や社内会議、地域ニュースの音声を文字化するシステムを運用していて、固有名詞だけ毎回間違う、という悩みを持つエンジニアは少なくないはずです。人名・地名・組織名・イベント名といった固有名詞（プロパーノウン）は、汎用の音声認識モデルの学習データに十分含まれていないことが多く、認識精度が落ちやすい領域です。
バルバドス（カリブ海の島国）のラジオ音源を使った実験では、イベント名「Rise Together」がGPT TranscribeとGPT Audio 1.5では「Rice Together」と誤認識され、Qwen3.5-Omni Plus/Flashでは正しく認識されたという結果が報告されています。この記事では、こうした「地域固有名詞の誤認識」にSRE・インフラの立場からどう対処するかを、コンテキスト辞書方式とドメイン適応ファインチューニング方式の選び方として整理します。
なぜ固有名詞だけ精度が落ちるのか
音声認識は音響的な情報だけでなく、言語的な文脈も使って文字列を確定させています。クリーンな音声で頻出語なら音響情報だけで十分ですが、実運用の音声は圧縮されノイズが混じり、話者ごとにマイクや発話速度も違います。
そこで認識エンジンは「弱い音響的証拠 + 言語モデルの文脈 → 選ばれる文字列」という形で最終的な出力を決めています。固有名詞が学習データに乏しいと、この文脈側の手がかりが弱くなり、似た音の一般語に引っ張られてしまいます。バルバドスの例で言えば、Kensington Oval（クリケット競技場）やCrop Over（収穫祭）のような地域特有の語彙が、汎用モデルの言語的事前知識にほとんど存在しないことが誤認識の背景にあります。
判断軸1：辞書で足りるか、モデルの知識を変える必要があるか
この誤認識に対する対処法は大きく2系統あります。1つは推論時に固有名詞リストを与える「コンテキスト・バイアシング」です。もう1つは学習データそのものに地域知識を追加する「ドメイン適応事前学習」です。
コンテキスト・バイアシングは、認識対象の音声に出てきそうな固有名詞のリストを推論時に渡す方式です。Pundakらの研究「Deep Context」では、この方式で語彙誤り率（WER, Word Error Rate）が最大68%改善したと報告されています。後続のtrie構造を使ったdeep biasing手法でも19.5%の相対改善が報告されており、特に長尾（ロングテール）の低頻度語に効果があるとされています。
ドメイン適応ファインチューニングは、地域のニュース記事などのテキストコーパスをモデルに追加学習させ、固有名詞や人物・組織間の関係性を言語モデルの事前知識として埋め込む方式です。バルバドスの実験では、現地新聞のアーカイブから抽出した5160万トークンを使い、Qwen3-Omniの「Thinker」コンポーネントに追加学習を行っています。
判断軸2：固有名詞の入れ替わり頻度
対象ドメインの固有名詞リストが安定しているか、頻繁に変わるかも重要な判断軸です。学校名や競技場名、政治家の名前など固定的な語彙は、辞書に追加するだけで運用できます。
一方でイベント名や新しい組織名が毎月増えるようなドメインでは、辞書更新の運用コストが積み重なります。この場合、ある程度まとまった単位で再学習する運用のほうが管理しやすくなることがあります。
判断軸3：運用できるML基盤があるか
コンテキスト・バイアシングは推論APIのパラメータやプロンプトに語彙リストを渡すだけで実装できることが多く、既存のSTT（Speech-to-Text）APIをそのまま使い続けられます。追加のGPUリソースや学習パイプラインは不要です。
ドメイン適応ファインチューニングは、学習データの収集・前処理、学習ジョブの実行、評価パイプラインの構築が必要になります。Qwen3-Omni-30B-A3B-Instructのようなモデルを対象にする場合、Mixture-of-Experts構成のThinker（テキスト生成を担う約30億パラメータのアクティブ推論部分、全体では約300億パラメータ）とTalker（音声トークン生成用の別の30億パラメータMoE）を分離して扱う必要があり、model.disable_talker()のようなAPIでテキストのみの学習経路を選ぶといった実装判断も発生します。これを継続的に運用するには、学習ジョブをIaC（Infrastructure as Code）で管理し、GPUインスタンスのプロビジョニングやコスト管理まで含めた基盤が前提になります。
判断軸4：精度改善をどう検証するか
どちらの方式を選んでも、改善したかどうかを客観的に測る仕組みが要ります。バルバドスの実験では、地域知識を問う予備的なプローブ（人物・組織に関する質問セット）でのスコアは向上した一方、汎用知識の小規模コントロールセットではわずかに低下したと報告されています。さらに重要な点として、この時点では「音声の書き起こし精度そのものが上がったかは、まだ示されていない」と明記されています。
これは、知識ベンチマークの改善と実際のWER改善が別物であることを示す教訓です。運用に導入する前に、実際の音声サンプルに対するWERを事前・事後で比較する評価パイプラインを用意し、SLO（Service Level Objective、サービスレベル目標）としてWERの許容範囲を定義しておくことをおすすめします。
選択肢の比較
| 観点 | コンテキスト・バイアシング | ドメイン適応ファインチューニング |
|---|---|---|
| 実装コスト | 低い（推論時パラメータ） | 高い（学習パイプライン必要） |
| 固有名詞更新の柔軟性 | 高い（リスト差し替えのみ） | 低い（再学習が必要） |
| 報告された改善幅 | WER相対改善19.5〜68% | 知識プローブは改善、WER改善は未検証 |
| 必要な基盤 | 既存STT APIのまま | GPU学習基盤・IaC・評価パイプライン |
ケース別の推奨
固有名詞のリストが数百語程度で、更新頻度が月次以下であれば、コンテキスト・バイアシングから始めるのが妥当です。多くのSTT APIやフレームワークが対応しており、導入コストが低く、効果測定も比較的すぐに行えます。
地域全体の言語的文脈（人物と組織の関係性、頻出する話題の言い回しなど）まで含めて認識精度を上げたい場合や、辞書に列挙しきれないほど固有名詞の組み合わせが多様な場合は、ドメイン適応ファインチューニングを検討する価値があります。ただしこれは学習基盤とオブザーバビリティ（学習ジョブの進行状況・損失・評価指標を可視化する仕組み）への投資が前提になります。
自組織で音声認識基盤を持たず、SaaS型のSTT APIをそのまま使っているなら、まずAPI側がコンテキスト・バイアシングやカスタム語彙機能を提供しているか確認するのが最初の一歩です。多くのクラウドSTTサービスには「フレーズヒント」「カスタム語彙」といった名称の機能があります。
あえて見送るべき条件
ドメイン適応ファインチューニングは、次のような条件では見送るべきです。まず評価用の音声サンプルとその正解書き起こし（グラウンドトゥルース）が十分に用意できない場合、改善したかどうかを判定できません。
また学習を1回実行して終わりにできる体制がない場合も注意が必要です。バルバドスの実験自体、当初計画した801ステップのうち500ステップで一度停止しており、コーパス抽出も並行して進行中の暫定結果だったと明記されています。継続的な再学習・再評価のサイクルを運用できないなら、投資対効果が見えにくくなります。
さらに、汎用知識の性能低下（キャッチストロフィック・フォゲッティング、既存知識を上書きしてしまう現象）が業務要件上許容できない場合も、慎重な検証が必要です。実験でも汎用知識のコントロールセットでわずかな低下が見られており、ドメイン特化と汎用性能はトレードオフの関係にあることを踏まえる必要があります。
まとめ
固有名詞の音声認識誤りへの対処は、まず既存STT APIのコンテキスト・バイアシング機能の有無を確認することから始めるのが現実的です。設定画面やAPIドキュメントで「custom vocabulary」「phrase hints」に類する項目を探してみてください。
それでも精度が足りない、かつ固有名詞が長尾で辞書化しきれないという場合は、ドメイン適応ファインチューニングを検討する段階です。その際は学習前にWERの評価基準をSLOとして明文化し、汎用知識への影響も含めた比較評価を必ず行ってください。
どちらを選んでも、改善の有無を測る評価パイプラインなしに本番投入するのは避けるべきです。知識ベンチマークの向上と実際の書き起こし精度向上は別の指標だという点を、判断の起点に据えてください。