MENU

AI英会話で専門用語が通らない理由を分解した。社名・製品名が崩れる原因と、部品側に用意された対処

AI英会話で仕事の話をした瞬間に、自分の会社名と製品名だけが別の英単語に化ける。

日常会話はきれいに通っているのに、専門用語のところだけが崩れる。

これは発音の問題として片づけられがちだが、仕組みのうえでは別の原因が先に立っている。

AI英会話の入口にいる音声認識は、無限の語彙を持っているわけではないからだ。

そして部品を売っている側は、この問題への対処をはっきり用意している。

この記事では、グーグルとマイクロソフトとOpenAIの開発者向けドキュメントの記述だけを材料に、専門用語が落ちる理由と、用意されている対処を1つずつ開けていく。

サービスの順位づけはしない。仕組みの話だけをする。

TOC

【結論】AI英会話の専門用語は「語彙の外」にあるから落ちる

先に答えを置く。

グーグルの音声認識のベストプラクティスには、この一文がそのまま書かれている。

「The recognizer has a very large vocabulary, however terms and proper names that are out-of-vocabulary will not be recognized.」(認識器は非常に大きな語彙を持つが、語彙の外にある用語や固有名詞は認識されない)という記述だ(Cloud Speech-to-Text の Best practices)。

⇒ 語彙の外にある言葉は、どれだけ正しく発音しても出てこない。

つまり「通じなかった」のではなく、「候補として存在しなかった」という事故が起きている。

そして認識器は、黙って落とすのではなく、似た音の一般語に置き換えて出す。だから画面には、意味の通らない英文が平然と表示される。

崩れ方何が起きているか対処がある場所
社名・製品名が別の単語になる語彙の外の固有名詞フレーズセット/関連テキスト
業界の専門用語だけが毎回変わる一般語での出現頻度が低いブースト値/カスタムモデル
語は合っているが表記が違う表示形式の処理書き換えルール(カスタム表示形式)
数字や住所の書かれ方が想定と違う逆テキスト正規化カスタムITNルール

この4つは原因が違うので、打てる手も違う。以下で分ける。

AI英会話の専門用語が落ちる仕組み|認識は「確率の選択」で動いている

音声認識は、音を聞いて「もっともありえる語の並び」を選ぶ装置だ。

グーグルのモデル適応のドキュメントは、この性質を weather と whether の例で説明している。

同じ音に対して複数の候補があり、どちらを出すかは確率で決まる。だから頻度の低い語は、頻度の高い語に押し負ける(Improve transcription results with model adaptation)。

専門用語は、この「押し負ける側」に構造的に置かれている。

同ドキュメントは、モデル適応が役に立つ場面として、「such as proper names or domain-specific words」(固有名詞やドメイン固有の語のように)一般的な言語使用では珍しい語を音声データが含む場合を挙げている。

マイクロソフト側も同じ整理をしている。Custom Speech の概要には、基本モデルは「さまざまな一般的なドメインを表す方言と発音で事前トレーニングされています」とあり、一般用途に最適化されたものであることが明示されている(Custom Speech の概要)。

⇒ 既定の状態は「一般会話に強く、業務の語彙に弱い」ように作られている。 これは欠陥ではなく設計だ。

さらにマイクロソフトのトレーニング解説には、この現象を誤りの種類まで分解した記述がある。

  • 置換エラー=別の語に置き換わる。専門用語で起きるのは基本的にこれ。
  • 挿入エラー=言っていない語が増える。
  • 削除エラー=言った語が消える。

そして同ドキュメントは「カスタム音声では、単語のコンテキストのみをキャプチャして、挿入エラーや削除エラーではなく置換エラーを減らすことができます」と限定して書いている(トレーニングとテストのデータセット)。

⇒ 手を打って直るのは「別の語にすり替わる」型であって、語ごと消える型ではない。 ここを混同すると、設定をいじっても手応えが出ない。

AI英会話の専門用語を通す方法①|フレーズセットで候補の重みを変える

いちばん軽い対処が、認識器に「この語が出るぞ」と先に渡しておくやり方だ。

グーグルではこれをモデル適応と呼び、PhraseSet という入れ物に語や語句を並べる。

ドキュメントには、複数語のフレーズを渡すとその並びで認識されやすくなるだけでなく、フレーズの一部(個々の単語)の認識確率も上がると書かれている。

ベストプラクティス側にも、「Use word and phrase hints to add names and terms to the vocabulary」(語彙に名前や用語を足すために単語・語句のヒントを使え)という一行がある。

語彙は固定ではなく、リクエストごとに足せる。

ここで実務的に効くのが、長いフレーズを1本だけ入れても効かないことがある、という但し書きだ。

ドキュメントは、長いフレーズで結果が出ないときの手として「add all bigrams (2-words, in order)」=そのフレーズを構成する2語の組み合わせを全部足し、それぞれに重みを付けることを勧めている。例として「American Museum of Natural History」「blue whale」のような部分列を足す形が示されている。

⇒ 自社の正式名称を丸ごと1行入れるより、「正式名称」「略称」「製品名だけ」を別々に入れたほうが当たりやすい。

もう1つ、グーグルにはクラスという仕組みがある。

住所の番地のように「値は毎回変わるが種類は同じ」ものをまとめて扱うための道具だ。

ドキュメントの例では $ADDRESSNUM というクラストークンが使われ、「123 Main Street」も「987 Grand Boulevard」も同じ扱いで拾えるようになる。

さらに、ここには読み飛ばせない注意が付いている。クラストークンをフレーズの中に埋め込むだけでは、似ているが一致しない言い回しには効かないので、トークン単体も併せて入れておくべきだ、という指摘だ。

また、無効な形のクラストークンを書いた場合、エラーを出さずに黙って無視されると明記されている。

⇒ 設定したのに何も変わらないとき、そもそも読まれていない可能性がある。

数百件規模の固有名詞(ドキュメントの例では地域のレストラン名)をまとめて扱いたい場合は、CustomClass という自前のクラスを作る形が案内されている。

AI英会話の専門用語とブースト値|どこまで強く押せるのかが公開されている

ここがいちばん具体的な数字の出る場所だ。

まず前提として、ドキュメントは「By default model adaptation provides a relatively small effect, especially for one-word phrases.」(既定ではモデル適応の効果は比較的小さく、特に1語のフレーズで顕著)と書いている(モデル適応のドキュメント)。

⇒ 語を登録しただけでは、たいして変わらないことがある。 そこで重みを付けるのがブーストだ。

ブーストの仕様は、そのまま数字で書かれている。

項目ドキュメントの記述
値の範囲「Boost values must be a float value greater than 0.」=0より大きい浮動小数点数
実用上の上限「The practical maximum limit for boost values is 20.」=実用上の上限は20
決め方「experiment with your transcription results by adjusting your boost values up or down」=上下に振って試す
上げすぎの副作用false negatives は減るが false positives が増える=言っていない語が文字起こしに現れる
複数語への適用フレーズ全体にだけ適用される(部分一致には効かない)

⇒ ブーストは「上げれば上げるほど良い」設定ではない。

強く押した語は、音が似ているだけの場面でも出てくるようになる。会議の文字起こしで、言っていない製品名が混ざるのはこの副作用だ。

ドキュメントの fair と fare の例が分かりやすい。両方を登録したうえで、実際の出現頻度が高いほうに高いブースト値を割り当てるという使い方が示されている。

そしてブースト値を付けなければ、認識器は両者を等しい確率で扱うとも書かれている。

⇒ 専門用語の対処は「登録するか/しないか」の2択ではなく、「どれをどれだけ強く押すか」の配分問題になる。

AI英会話の専門用語が「表記」で崩れるとき|語は合っているのに形が違う

語自体は当たっているのに、書かれ方が想定と違う、という崩れ方がある。

これは認識の問題ではなく、認識のあとに走る表示テキストの書式設定の問題だ。

マイクロソフトの表示形式のドキュメントには、いくつかの処理が並んでいる(音声テキスト変換での表示テキストの書式設定)。

  • 逆テキスト正規化(ITN)=話し言葉を記号の形に直す。ドキュメントの例では「よん」という音声が「4」という記述形式になる。
  • 大文字化=「文の先頭にある固有名詞と単語を自動的に大文字にします」と明記されている。
  • 不要な言葉の除去=「えーと」「あー」のようなつなぎ言葉を表示テキストから落とす。
  • 句読点の自動付与=読みやすさのために句読点を補う。

ここで効いてくるのが、ITNについての一文だ。

同ドキュメントは、ITNについて「音声テキスト変換サービスがこのプロセスを完了し、これは構成できません」と書いている。既定の経路では設定で変えられない、ということだ。

⇒ 社内での書き方のルール(型番の書式・略号の大文字小文字)は、標準の状態では通らない。

そのための出口が、カスタム側に用意されているカスタム表示テキスト フォーマットだ。

トレーニングデータの解説には、「書き換えルールを追加して特定の単語を大文字にして再定式化したり」「数字、日付、メール アドレスなどの特定のパターンの高度な ITN ルールを定義したり」できると書かれている。

さらに「一部のフレーズを保護し、どの表示プロセスからも除外することもできます」という機能まである。

⇒ 自社の表記をそのまま守らせたいときは、認識側ではなく表示側のルールを触るのが筋になる。

AI英会話でカスタムモデルを作る場合|専門用語を覚えさせるデータ量の実数

フレーズセットで足りないとき、モデルそのものを拡張する道がある。

Custom Speech の概要は、この目的をはっきり書いている。「モデルをトレーニングするテキスト データを提供することによって、ベース モデルを拡張し、アプリケーションに特有のドメイン固有のボキャブラリの認識を向上させることができます」だ。

どのデータを使えば何が直るのかも、目的別に整理されている。

直したいこと(ドキュメントの表記)使うデータ
「医療用語や IT 用語などの業界固有の語彙や文法に対する認識精度を向上させる」プレーンテキスト/構造化テキスト
「製品名や頭字語など、発音が標準ではない単語または用語の表音および表示形式を定義する」発音データ
「読み上げのスタイル、アクセント、または特定の背景ノイズの認識精度を向上させる」オーディオ+人間がラベルを付けたトランスクリプト

⇒ 専門用語の問題は、多くの場合いちばん軽い「テキスト」で足りる。

ドキュメントも「プレーンテキスト データまたは構造化テキスト データから始めます」と順番を指定しており、テキストでの学習はオーディオより「はるかに高速です (分単位と日単位)」と書いている。

データ量の目安も、表のかたちで公開されている。

データ型トレーニングに推奨される量
プレーンテキスト1 – 200 MB の関連テキスト
構造化テキスト最大 4,000 の項目、最大 50,000 のトレーニング文を含む最大 10 個のクラス
発音1 KB から 1 MB までの発音テキスト
表示形式ITN は最大 200 行、書き換えは 1,000 行、不適切なフィルターは 1,000 行
オーディオ+人間ラベル1 から 100 時間のオーディオ

構造化テキストのほうは、さらに細かい上限まで書かれている。

ファイルは拡張子 .md、最大ファイル サイズは 200 MB、エンコードは UTF-8 BOM。リストは最大 20 個、リストあたり最大 35,000 項目。発音は最大 15,000 個のエントリで、単語あたり最大 2 個の発音まで。

⇒ 社内用語の一覧を流し込む、という運用が数字のうえで成立する規模になっている。

書き方の注意も具体的だ。「製品名などの用語の重みを増やすには、その用語を含む複数の文を追加します。ただし、コピーしすぎないでください。これが全体的な認識率に影響する可能性があります」とある。

同じ語を貼り続ければ強くなる、という話ではない。

ドキュメントは「文字、単語、または単語のグループを 3 回より多く繰り返すことは避けます」と回数まで指定しており、繰り返しが多すぎると音声サービス側で削除される可能性があるとしている。

発音の与え方にも面白い記述がある。専門用語や造語について「単語をより小さく分割して発音できる場合は、これらを認識できます」とし、Xbox を「エックス ボックス」と分けて発音する例が挙げられている(訳文のまま)。

ただし同じ箇所に「この方法では、全体的な精度は向上しませんが、このキーワードや他のキーワードの認識を向上させる可能性があります」という限定も付いている。

なお、カスタムモデルは作れば使えるわけではない。

Custom Speech の概要には、バッチ文字起こしを除いてカスタム エンドポイントをデプロイする必要があると書かれている。運用の器まで用意して初めて動く仕組みだ。

AI英会話の専門用語に一般ユーザーが打てる手|プロンプトとキーワード

ここまでは開発者側の話だった。触れる範囲と触れない範囲を切り分けておく。

フレーズセット、ブースト値、カスタムモデル、カスタムエンドポイントはすべてアプリを作る側の設定で、アプリの画面には出てこない。

一方で、文章で渡すタイプの手当ては、仕様として公開されている。

OpenAIの音声認識ガイドは、「Use a prompt to improve recognition of names, acronyms, formatting, or recording-specific vocabulary.」(名前・頭字語・書式・その録音に固有の語彙の認識を上げるためにプロンプトを使え)と書いている(OpenAI Speech to text ガイド)。

役に立つ場面として最初に挙がっているのが「Correctly transcribing product names, technical terms, and acronyms.」=製品名・技術用語・頭字語を正しく文字起こしすることだ。

同ガイドには、渡し方の役割分担も整理されている。

  • prompt=「unstructured context about the recording」=その録音についての背景情報を文章で。
  • keywords=「literal terms you expect to hear」=出てくると分かっている語そのもの。
  • languages=想定される入力言語。

そしてここにも、ブーストと同じ副作用の警告が付いている。

「Keywords are hints, not required output.」(キーワードはヒントであって、必ず出力される語ではない)とあり、関係のある語だけを入れ、話されていない語が現れていないか確かめるべきだと続く。

古いモデルには容量の上限もある。whisper-1 について「prompts have a 224-token limit」と明記され、汎用テキストモデルのようには指示に従わないとも書かれている。

⇒ 用語集を丸ごと貼る、という使い方は、モデルによっては入り切らない。

同ガイドは、その逃げ道として「あとから直す」型も示している。

文字起こしを言語モデルに渡して綴りの誤りを直させるやり方で、「A text model can correct misspellings and handle longer terminology lists than Whisper’s 224-token prompt window.」=テキストモデルのほうが長い用語リストを扱えると書かれている。

ただし同じ文に「Evaluate corrections against the original audio to avoid changing what the speaker said.」=話者が言っていない内容に書き換わっていないか元の音声と突き合わせろ、という条件が付く。

⇒ 一般ユーザーが自分でできるのは「話し始めに文脈を渡す」「出てきた表記を自分で直す」までだ。

AI英会話で専門用語が通らないとき、設定より先に疑う音の条件

語彙の話をする前に、入力側で落ちている場合がある。

グーグルのベストプラクティスは、録音条件を具体的な数字で指定している。

  • サンプリングレートは 16,000 Hz 以上で録る。低いと精度が落ちる可能性がある。
  • リサンプリングは避ける。電話系のように元が 8000 Hz なら、その値のまま送る。
  • 可逆コーデックを使う。mp3・mp4・m4a などの非可逆な形式は精度を下げる可能性がある。
  • マイクは話者に近づける。特に背景ノイズがあるときに効く。
  • ノイズ低減処理は切る。送信前にノイズリダクションをかけると、通常は認識精度が下がるとされている。
  • 自動ゲインコントロール(AGC)は使わない。

⇒ 「良かれと思ってかけた処理」が、専門用語のような弱い語からまず削っていく。

ストリーミングについては、フレームサイズはどの大きさでも受け付けるとしたうえで、100ミリ秒が遅延と効率の折り合いとして推奨されている。

マイクロソフト側にも、似た方向の注意がある。オーディオファイルは録音の前後に少なくとも 0.5 秒の無音部分を入れることが勧められている。

⇒ 言い終わった瞬間に切る操作は、最後の単語を削る。専門用語が文末に来る業務会話では、ここが効く。

AI英会話の専門用語が直ったかどうかを、どう測るか

手を打ったあと、効いたかどうかを感覚で判断しないための指標も用意されている。

Custom Speech の概要には、「さらにトレーニングが必要かどうかを判定するために使用できる定量的な単語誤り率 (WER) が用意されています」と書かれている。

手順も示されている。基本モデルが出した文字起こしと、人間が同じ音声から書き起こした文字起こしを比べ、WERを取る。値が高ければ、誤って識別された語を認識するようにカスタムモデルを学習させる、という流れだ。

⇒ 「専門用語に弱い」は感想だが、WERは数字になる。

もう1つ、モデルを分けるという設計の話も書かれている。

ドキュメントは、語彙が領域ごとに違うなら複数のカスタムモデルを使うことを勧めており、オリンピックの競技ごとに用語が大きく異なるため、競技に固有のモデルを作ると精度が上がるという例を挙げている。

理由の説明が明快だ。関連性のないデータをふるいにかける必要がなくなるからだという。

⇒ 業務の英語を1つのモデルで全部まかなうより、分野を絞ったほうが有利だ、というのが部品側の設計思想になっている。

逆に、範囲を広げすぎることへの警告もある。トレーニングデータの解説には「モデルで文字起こしする必要があるデータのみを含めます。カスタム モデル認識の要件の範囲内ではないデータを含めると、全体的な認識品質に悪影響を及ぼす可能性があります」とある。

AI英会話の専門用語に関するよくある質問

Q. 発音を直せば専門用語も通るようになるか。 A. 通るようになる部分と、ならない部分がある。グーグルのベストプラクティスは「語彙の外にある用語や固有名詞は認識されない」と書いている。語彙の外にある語は、発音の問題とは別の層で落ちている。

Q. 自分の会社名をアプリに覚えさせられるか。 A. 一般ユーザー向けの画面では触れないことが多い。ただしOpenAIのガイドは、プロンプトやキーワードで名前・頭字語の認識を上げる方法を示している。会話の冒頭で固有名詞を文脈として渡すのは、仕様に沿った使い方だ。

Q. 用語を登録すれば必ずその通りに出るのか。 A. そうはならない。OpenAIのガイドは「Keywords are hints, not required output.」と明記している。グーグル側も、ブーストを上げると言っていない語が現れる false positives が増えうると書いている。

Q. 専門用語のために学習データを用意するなら、どれくらい要るのか。 A. マイクロソフトの表では、プレーンテキストは「1 – 200 MB の関連テキスト」、オーディオと人間によるラベル付きは「1 から 100 時間のオーディオ」が推奨量として示されている。テキストから始めるのが順番として案内されている。

Q. 社内の表記ルール(略号の大文字小文字など)は守らせられるか。 A. 標準の表示形式では、大文字化やITNがサービス側で自動的に走り、ITNは「構成できません」と書かれている。カスタム表示テキスト フォーマットの書き換えルールを使えば、特定の語の表記を定義できる。

Q. 仕事の英語の練習に、AI英会話は向いていないということか。 A. そう結論する必要はない。崩れるのは固有名詞と業界語という限られた層で、文の組み立てや発話量の練習はそのまま成立する。固有名詞の部分だけ、出てきたテキストを自分で読み替える前提で使うのが仕組みに合っている。

まとめ|AI英会話の専門用語は「部品の設定」で決まっている

最後に整理する。

  • 専門用語が崩れる第一の理由は語彙の外。「out-of-vocabulary な用語や固有名詞は認識されない」と公式が書いている。
  • 対処はまずフレーズセット(モデル適応)。長いフレーズが効かないときは、部分列に分けて足すことが勧められている。
  • ブースト値は0より大きい浮動小数点数で、実用上の上限は20。上げすぎると、言っていない語が現れる副作用がある。
  • もっと深く覚えさせるならカスタムモデル。推奨量はプレーンテキストで「1 – 200 MB の関連テキスト」、構造化テキストで「最大 4,000 の項目、最大 50,000 のトレーニング文を含む最大 10 個のクラス」。
  • 表記だけがずれているときは認識ではなく表示形式の層。標準のITNは構成できず、カスタム表示形式の書き換えルールが受け皿になる。

⇒ 「AIが専門用語に弱い」のではなく、既定の設定が一般会話に合わせてあり、業務語彙は別途渡す前提で作られている。

そこが分かっていれば、崩れた画面を見て発音のせいにして落ち込む必要はなくなる。

直せる層と、自分では触れない層を切り分けたうえで、触れる層だけを触る。それがこの問題の扱い方だ。

※本記事の一次ソースはすべて2026-09-11に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。

Let's share this post !

Author of this article

Comments

To comment

TOC