発音辞書はAI英会話の読み上げをどう直すのか。固有名詞の読み間違いを直す仕組みを公式仕様から分解した

公開日 2026年9月21日(月) 08:02更新日更新なし

AI英会話のお手本の声が、自分の名前や地名を明らかに違う読み方で発音したことがあるなら、それは聞き取り側ではなく読み上げ側で起きている事故だ。

発音の採点が甘いわけでも、マイクが悪いわけでもない。音声合成の担当が、その綴りをどう読むか知らないだけだ。

そして、この「読み方を知らない」を人の手で埋めるための仕組みが、部品を売っている側にはちゃんと用意されている。

それが発音辞書（カスタム辞書）だ。

発音辞書は概念ではなく、ファイル形式・容量上限・反映までの待ち時間まで公式ドキュメントに書かれている実装物である。

つまり、読み間違いは直せる場所が決まっていて、直せない場所も決まっている。

この記事では、マイクロソフトとグーグルの開発者向け公式ドキュメントの記述だけを材料にして、発音辞書が何をどこまで上書きできるのかを分解する。

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

TOC

【結論】AI英会話の発音辞書は、読み上げ側の読み方を単語ごとに上書きする外付けファイルだ

先に答えを置く。

発音辞書は、音声合成マークアップ言語（SSML）という仕組みの中にある1つの要素で、別ファイルとして置いた辞書を読み上げエンジンに読ませるものだ。

マイクロソフトの公式ドキュメントは、SSMLを、「ピッチ、発音、読み上げ速度、音量など」の出力属性を微調整するための「XML ベースのマークアップ言語」だと定義している（SSML の概要）。

発音まわりのページは、音素とカスタム辞書という2つの道具をSSMLに持ち込めば読み上げの発音を良くできる、と冒頭で宣言している（SSML を使用した発音）。

ここで大事なのは、この話が全部「出力オーディオ」の側にあるということだ。

向き	担当する部品	発音辞書は効くか
あなたが話す → 文字になる	音声認識（Speech to Text）	✕ この記事の発音辞書は関係しない
AIが文を作る	言語モデル	✕ 関係しない
文字 → お手本の声になる	音声合成（Text to Speech）	◎ ここだけを直す道具

⇒ 発音辞書は「AIの耳」を良くする道具ではなく、「AIの口」の読み癖を直す道具だ。

この向きを取り違えると、期待していた効果と実際の効果が最後までかみ合わない。

AI英会話の発音辞書はSSMLのどこに置かれているのか

発音辞書は、SSMLの lexicon 要素から参照される。

SSMLドキュメントの構造を示したページには、<voice> の中に置ける要素が一覧で並んでおり、そこに <lexicon uri="string"/> が含まれている（SSML ドキュメントの構造とイベント）。

同じページは lexicon の中に、文字も他の要素も置けないと書いている。

つまり、SSMLの側に書くのは「辞書の住所」だけで、中身は外部ファイルに置く設計になっている。

住所を指す uri 属性は必須で、その指す先は拡張子が .xml か .pls のXMLファイル、しかも外から取りにいける場所へ置かれていることが条件になる。

置き場所は Azure Blob Storage が推奨だが、必須ではない。GitHub の住所でも、誰でも取りにいける形で公開されたリンクなら受け付けると書かれている。
公開したくない場合は SAS を使えるとされている。
ただし同じページには、それ以外の公開URLだと相性が合わない場合がある、という但し書きも置かれている。

さらに、辞書が使えない経路も明記されている。

長い形式の読み上げを担う Long Audio API を通した場合、lexicon は効かないと公式ドキュメントが明言しており、代わりにバッチ合成 API へ乗せ替えるよう案内している。

⇒ 同じサービスでも、通す経路によって辞書が効く／効かないが分かれる。

AI英会話の発音辞書ファイルの中身は4つの部品でできている

辞書ファイルの構造は、W3Cの発音辞書仕様（PLS）バージョン 1.0 に沿っている。

公式ドキュメントの説明を、そのまま部品ごとに整理するとこうなる。

部品	担当していること
`lexicon`	辞書のいちばん外側の箱。中に `lexeme` を1つ以上抱え、どのロケール向けかを `xml:lang` で名乗る
`lexeme`	見出し語1件ぶんの箱。`grapheme` を最低1つ持ち、そこへ `grapheme`・`alias`・`phoneme` のどれかを足していく
`grapheme`	画面に出てくる綴りそのもの。読みを変えたい文字列をここへ書く
`alias`	頭字語や略語を、別の文字列として読ませたいときの受け皿
`phoneme`	その見出し語をどう読むかを、発音記号の文字列で与える欄

公式ドキュメントが挙げている例は分かりやすい。「BTW」は alias で「By the way」と読ませ、人名「Benigni」は phoneme にIPAの bɛˈniːnji を与えて読ませる。

同じ例には絵文字の行もあり、😀 に対して「test emoji」という alias を当てている。

ここで、実務でいちばん引っかかる仕様が2つある。

大文字と小文字は別物として扱われる。 lexeme はケースを見分ける仕様で、”Hello” にだけ音素を与えた辞書は “hello” を素通りさせると明記されている。
同じ grapheme に alias と phoneme の両方が付くと alias が勝つ。 先に立つのは alias のほうだと書かれている。

そしてもう1つ、設計思想が分かる制限がある。

語のつながりに対して読みを直に指定する使い方は、辞書ではできないと公式ドキュメントが書いている。

複数語のまとまりに読み方を与えたいときは、いったん alias で1語に畳んでから、その alias に phoneme を結びつけるという二段構えになる。

⇒ 発音辞書は、あくまで「単語の辞書」であって「文の読み上げ台本」ではない。

AI英会話の発音辞書で使える発音記号と、ロケールの縛り

読み方を書き込む記号にも、選べるものと選べないものがある。

辞書ファイルの alphabet 属性に入れられる値は2つきりで、ipa と x-microsoft-sapi が挙げられている。

そのうえで、国際標準という理由からIPAを選ぶよう勧める一文が添えられている。

IPAを選んだときの作法も具体的だ。音節の切れ目はピリオド . で表し、phoneme の中には空白を1つも入れてはいけないとされている。

文字コードの話にも踏み込んでいて、辞書が受け付ける Unicode は分解された形のものに限ると書かれている。

そして、いちばん見落とされやすいのがロケールの縛りだ。

公式ドキュメントによれば、1本の辞書が受け持てるロケールは設計上1つきりで、それ以外のロケールへ当てても働かない。

⇒ 米国英語向けに書いた辞書は、英国英語の音声にそのままでは効かない。

sapi のふりがなセットが定義されているロケールも一覧で公開されている。英語は en-US と en-CA の2つ、あとはフランス語・ドイツ語・スペイン語系の各ロケールと、ja-JP や中国語系のロケールが並ぶ。

英語でこの一覧に入っているのは米国とカナダの2つだけだ。

音声そのものの制約もある。SSMLの構造ページは、音声によっては「SSML タグが一部しかサポートされていないことがあります」とし、該当するものとして「ニューラルテキスト読み上げHD音声、個人用音声、埋め込み音声」を名指ししている。

言語サポートの表の脚注にも「音素、カスタム辞書、口形素はサポートされていません」という但し書きが置かれている（Azure AI Speech の言語サポート）。

⇒ 声を変えただけで辞書が効かなくなることがある、という話だ。

AI英会話の発音辞書には容量と反映時間の上限がある

辞書は無限に育てられるものではない。

公式ドキュメントは制限事項を2つ、数字つきで挙げている。

ファイルサイズ＝1ファイルにつき 100 KB が上限。これを超えると合成の要求そのものが通らないとされ、辞書を分けて複数読ませる形になる。
キャッシュ＝同じ住所から読み込んだ辞書は、15分のあいだ取り直されない。だから直した中身が効き始めるまで、最長で15分の待ちが入ると書かれている。

この15分という数字は、辞書を直したのに読み方が変わらないという現象の説明になる。

公式ドキュメントによれば、辞書はURIをキーにしてキャッシュされる。だから同じ住所のファイルを書き換えても、しばらくは前の版が読まれ続ける。

なお、マイクロソフトは辞書ファイルの検証ツールも用意している。

細かいエラー文つきで不備を洗い出せる検証ツールが配られており、運用に乗せる前に一度通すよう勧められている。

⇒ 読み間違いの多くは「辞書に書いてあるのに効いていない」側の問題で、その切り分け手段まで公開されている。

AI英会話の発音辞書を使わずに読み方を直す3つの方法

辞書ファイルを作らなくても、SSMLの中に直接書いて読み方を変える手が3つある。

公式ドキュメントは、複数のエンティティをまとめて定義したいときに辞書ファイルを作る、という順序で説明している。逆に言えば、単発なら本文に書けば足りる。

要素	何をする要素か	公式ドキュメントの例
`phoneme`	単語の読み方を発音記号で直接指定する	`<phoneme alphabet="ipa" ph="tə.ˈmeɪ.toʊ"> tomato </phoneme>`
`sub`	囲んだテキストの代わりに `alias` の文字列を読ませる	`<sub alias="World Wide Web Consortium">W3C</sub>`
`say-as`	数字や日付など「内容の型」を指定して読み方を決める	`<say-as interpret-as="fraction">3/8</say-as>` → “three eighths”

phoneme 要素で使えるアルファベットは、公式ドキュメントに ipa、sapi、ups（Universal Phone Set）、x-sampa が挙げられている。

ここには、ミスをしたときの挙動まで書いてある。

読めない音素が1つでも混ざっていれば、読み上げ側はそのSSMLを無効とみなし、http 400 を返すとされている。

⇒ 発音記号の書き間違いは、黙って無視されるのではなくエラーとして跳ね返る。

強勢（ストレス）の置き方にも、記号ごとの作法の違いが書かれている。

IPA＝1音節だけを立てたいときは、その単語の音節を全部マークしておく。そうしなかった場合、強く読まれるのは記号の手前にある音節だとされている。
sapi＝全音節をマークしたかどうかは問われない。立てたい音節の後ろへストレス記号を置く決まりで、IPAとは前後が逆になる。
公式ドキュメントは同じ tomato を ph="tə.ˈmeɪ.toʊ" と ph="təmeɪˈtoʊ" の2通りで例示している。

say-as のほうは、対応範囲にはっきり差がある。

読み上げのどのロケールでも通る値は characters と spell-out の2つだけで、残りは列挙された言語群に限られるとされている。

duration には個別の但し書きが付いていて、このタグが通るのは英語とスペイン語だけだ。

固有名詞まわりで面白いのは name 型だ。

ドキュメントは <say-as interpret-as="name">ED</say-as> が [æd] と読まれる例を挙げ、中国語の姓についても「仇先生」が [chóu] ではなく [qiú] と読まれる例を示している。

⇒ 読み間違いの原因が「綴り」ではなく「役割の取り違え」であることは珍しくない。 名前を名前として扱わせるだけで直ることがある。

AI英会話の発音辞書に当たる仕組みはグーグル側にもある

同じ発想は、部品を売っている別の会社のドキュメントにも載っている。

グーグルのText-to-Speechは、SSMLのリファレンスで <phoneme> について単語の読み方を本文の中でその場で上書きするための要素だと説明している（Cloud Text-to-Speech の SSML リファレンス）。

受け付ける発音記号の体系は、IPAとX-SAMPAの2つだとされている。

ただし例外の指定が細かい。日本語は yomigana、中国語系は pinyin または jyutping を指定しなければならないと書かれている。

そして、マイクロソフト側と同じ「単語単位」の制限がここにも書いてある。

<phoneme> タグを1回書いて読み方を決められるのは1語だけ、という設計になっている。

書き方の指針まで具体的で、英語学習の観点から見ても示唆がある。

強勢は3段階＝第一強勢は IPA で /ˈ/、X-SAMPA で /"/。第二強勢は /ˌ/ と /%/。無強勢は記号を置かない。
転写は細かくしすぎない＝米国英語の butter は ˈbʌɾɚ ではなく ˈbʌtɚ と書けとされている。
例外は音の実態に合わせる＝dogs は ˈdɑːgs ではなく ˈdɑːgz。有声化がそのまま表記に出る。
音節には必ず母音を1つ入れる＝kitten は ˈkɪtn ではなく ˈkɪtən と書く。

 要素も同じように用意されていて、W3C のほか、日本橋 という日本語の例まで載っている。

⇒ 読み間違いを人手で上書きするという発想は、会社をまたいで共通している。 名前が違うだけだ。

AI英会話の発音辞書は「聞き取り側」には効かない

ここは、期待値をいちばん外しやすいところだ。

SSMLの発音辞書は、あくまでテキスト読み上げの仕様として書かれている。あなたの声を文字に変える側とは、別のドキュメントで別の仕組みが用意されている。

聞き取り側にも「発音データ」という名前のものはある。ただし形式がまったく違う。

カスタム音声のトレーニングデータのページは、認識側の発音ファイルについて、1行の先頭に表記、続けてタブ、その後ろに空白で区切った読みを並べる形だと書き、3CPO three c p o のような例を挙げている（Custom Speech のトレーニングとテストデータ）。

比べる点	読み上げ側の発音辞書	聞き取り側の発音データ
目的	AIの声の読み方を直す	AIが単語を聞き取れるようにする
形式	PLS準拠のXML（`.xml`／`.pls`）	1行1発音のテキスト（タブ区切り）
上限	100 KB	1 MB（Free レベルに 1 KB）
反映	SSMLから参照。最大15分のキャッシュ	モデルのトレーニングが要る

⇒ 名前が似ているだけで、置き場所も形式も効く向きも別物だ。

学習者の側から見ると、この区別はそのまま「何が直るか」の区別になる。

お手本の声が自分の名前を変な読み方をするのは、読み上げ側の辞書の話だ。自分が発音した固有名詞が違う単語として文字起こしされるのは、聞き取り側の話になる。

AI英会話の発音辞書に関するよくある質問

Q. 発音辞書を入れると、自分の発音の採点が良くなるのか。 A. 採点は聞き取り側の機能なので、ここで扱った発音辞書とは別系統だ。発音辞書が変えるのは、公式ドキュメントの言葉どおり「出力オーディオ」＝AIが読み上げる側の音になる。

Q. 辞書を直したのに読み方が変わらない。 A. 辞書は住所をキーに溜め置かれ、同じ住所のものは15分たたないと取り直されない。反映まで最長15分、というのが公式ドキュメントの説明だ。

Q. 英単語の綴りをそのまま辞書に書けば必ず効くのか。 A. 大文字と小文字が区別されると明記されている。”Hello” に指定した音素は “hello” には適用されない、という例が公式ドキュメントに載っている。

Q. イギリス英語の音声にも同じ辞書を使い回せるか。 A. 辞書1本が担当できるロケールは設計上1つきりと決まっており、別のロケールへ当てても働かないとされている。ロケールごとに用意する前提の仕組みだ。

Q. 文まるごとの読み方を辞書で指定したい。 A. 語のつながりへ読みを直に与える書き方は、辞書側では認められていない。alias で1語に畳んでから phoneme を当てる二段構えが、公式ドキュメントの示す手順になる。

Q. SSMLを書き足すと課金は増えるのか。 A. SSMLの概要ページによれば、SSMLの記述そのものは課金の対象に入らない。ただし音素やピッチのように読み方を調整する任意の要素は、課金対象の文字として数えられる。

まとめ｜AI英会話の発音辞書は「AIの口」だけを直す道具

もう一度、要点だけ並べる。

発音辞書はSSMLの lexicon 要素から参照する外部ファイルで、効く先は音声合成＝AIが読み上げる側だけだ。
中身は lexeme／grapheme／alias／phoneme の組み合わせ。大文字と小文字は区別され、alias が phoneme より優先される。
制限は数字で公開されている。ファイルは最大100 KB、変更の反映は最大15分、辞書は1つにつき1ロケール。
辞書を作らなくても phoneme・sub・say-as で単発の読み方は直せる。発音記号を間違えるとhttp 400 エラーが返る。
同じ発想はグーグル側にもあり、IPAとX-SAMPAを受け付ける。日本語は yomigana、中国語系は pinyin か jyutping という例外が明記されている。