TL;DR

機械的に確定できることは機械的にやれ。 5.8万行のうちLLMの判断が要ったのは数百行。先に規則で削る
データソースを信じすぎるな。 cmudictは用途違い、Wiktionary由来の参照は1割強が使えない、そして一番の誤報源は自分の検査プログラムだった（初期検出の96%が誤検出）
AIは組み合わせて使え。 1つに聞くと間違える。強い2系統を独立に走らせ、割れたら3つ目へ。突き合わせはラベルの一致ではなく「許容集合の積」で見る
迷ったら変えるな。 誤変更のコスト > 据え置きのコスト。この非対称を設計に入れる

結果: 220行を修正、音声165語を再合成。かかったのはおよそ1日。

その前に: この3ヶ月でモデルがだいぶ入れ替わった

前回「Gemini 3.5 Flash は本当にダメなのか？英単語の覚え方ヒント生成ベンチしてみた」で13モデルの盲検ベンチを書いたのが5月。3ヶ月でラインナップがかなり動いた。

OpenAI は GPT-5.6 シリーズが出た。Anthropic は Claude 5 世代になり、Opus 5 に加えて Fable 5 という新しい系統が増えている。オープン系も Kimi K3、DeepSeek V4 Flash、Qwen 3.8 あたりが順当に更新されている。

正直、前回のベンチ結果はもう賞味期限切れだと思っている。同じ条件で回し直したら順位はかなり変わるはずで、それはそれで別途やりたい。

なお今回、オープン系のモデルは使っていない。 Kimi K3 も DeepSeek V4 Flash も Qwen 3.8 も名前を出しておいてなんだが、今回の作業で実際に投入したのは次の3つだけだ。

用途	モデル
一次判定（独立した2系統）	GPT-5.6-sol / Claude Opus 5
判定が割れた分の最終裁定	Claude Fable 5

なぜこの3つで、なぜこの役割分担なのかは本文で書く。根っこにあるのは単純な話で、モデルの入れ替わりが3ヶ月単位で起きている以上、タスクごとに、そのときの最善のモデルを選び直すしかないということだ。前回の覚え方ヒント生成は「安くて速いモデルで足りるか」を測るベンチだったから13モデルを並べる意味があったが、今回のタスクは英語音声学の専門判断で、誤ると間違った音声がそのまま配信される。性質が違えば、選び方も変わる。

そして今回書くのは、**モデルの優劣ではなく「複数の不完全な情報源から、どう答えを確定させるか」**の話だ。実際に手を動かしてみると、最新モデルを並べても正解が出てこない領域というのが普通にある。発音記号がまさにそれだった。

結論を先に言うと、この3つは同じ問題で綺麗に判定が割れた。 どれか1つに聞いていたら間違えていた。

1語の誤りから始まった

英単語学習サイト「えいたんごクイズ」を運営している。最近はサイトの単語データをそのまま使って、YouTubeチャンネル（@eitanquiz）に単語紹介の動画も出している。動画のナレーションは音声合成で、発音記号(IPA)をSSMLの <phoneme> で強制適用して喋らせている。綴りを渡して読ませるのではなく、こちらが持っているIPAどおりに発音させる方式だ。

なぜ綴りだけ渡してはいけないか

同じ綴りでも、品詞や意味で発音が変わるからだ。

project  名詞 PRO-ject     動詞 pro-JECT     ← 品詞で変わる
present  形容詞 PRE-sent   動詞 pre-SENT     ← 品詞で変わる
lead     導く・先頭 /liːd/  鉛 /lɛd/          ← 意味で変わる

音声合成に lead とだけ渡したら、エンジンはどちらか一方に決め打ちするしかない。文章の中なら前後から推測できるが、単語紹介の動画は単語を単体で読み上げるので手がかりがない。

こちらの辞書は語義ごとに項目を持っていて、「導く」の lead と「鉛」の lead は別のエントリだ。どちらの発音で読ませたいかはこちらが知っている。だから綴りではなくIPAを渡す。

この「品詞や意味で発音が割れる」問題は、後で今回の監査における最大の難所として戻ってくる。

落とし穴

この方式には裏があって、IPAが間違っていると、間違ったまま忠実に発音される。しかも動画は一度公開すると差し替えが面倒だ。

英単語紹介のショート動画はYouTubeに山ほどあるが、音声合成で量産されたものを眺めていると、読み間違いが数％くらいの頻度で混ざっているものも珍しくない（数えたわけではなく体感だが）。固有名詞、同綴異音語、略語あたりで盛大に事故る。綴りをそのまま読み上げエンジンに渡していれば、そうなるのは避けられない。

ただ、こちらは教育系のコンテンツだ。発音を覚えるために見ている人がいる以上、読み間違いは単なる傷では済まない。間違った知識をそのまま届けることになる。 なので品質を最優先に置いていて、IPAの強制適用に加えて、生成の各段階に検査を挟むパイプラインを組んでいる。

その甲斐あって、読み間違いは 0.1% 程度まで落とせている——はずだった。

パイプラインの中身は別記事に書くつもりだが、先に言っておくと、この網は今回の誤りを構造的に捕まえられなかった。 読み上げた結果を検査して読み間違いを潰す仕組みと、そもそも渡している発音記号が正しいかを見る仕組みは別物だからだ。前者をどれだけ厳しくしても、後者は素通りする。

発覚したのは、出来上がった動画を自分で通しで見て品質確認していたときだった。TOEFL向けの回で、ナレーションが arbitrarily（恣意的に）を「アービトレラリ」と読んだ。第1音節に強勢が乗っている。正しくは ar-bi-TRAIR-uh-lee で、第3音節だ。

データを見たら /ˈɑːrbɪˌtrɛrəli/ になっていた。音声合成は何も悪くない。こちらが渡したIPAのとおりに、正確に間違えて発音していた。

公開前に気づけたのは運が良かった。テキストの誤字なら目で追えば分かるが、発音記号の誤りは、音になるまで気づけない。しかもIPAを強制適用している以上、合成エンジンが「常識的に補正してくれる」ことは期待できない。

1語の修正で済む話だと思って調べ始めたら、辞書全体で 220行を直すことになった。その過程で「発音記号の正解を機械的に決める」のがいかに厄介かを思い知ったので、まとめておく。

結論から言うと、cmudictもWiktionaryも主要LLMも、単独では信用できなかった。そして一番厄介だったのは、それらではなく自分が書いた検査プログラムだった。

犯人はcmudictだった

まず原因を特定した。過去に一度、発音記号の全量監査をやっている。会員から「この単語の音声がおかしい」と報告を受けて、cmudictと照合して3,557行を機械的に修正した。

cmudict（CMU Pronouncing Dictionary）はカーネギーメロン大学が公開している英語発音辞書だ。約13.5万エントリを ARPABET という表記でカバーしていて、数字で強勢を表す。

arbitrarily  AA1 R B IH0 T R EH2 R AH0 L IY0
undermine    AH1 N D ER0 M AY2 N
stratum      S T R AE1 T AH0 M

AA1 の 1 が第1強勢、2 が第2強勢、0 が無強勢。機械可読で網羅的、ライセンスも緩い（BSD）。発音データの決定版に見える。

そして変換プログラムは完全に正しく動いていた。cmudictが arbitrarily の第1音節に AA1 を置いているので、忠実に /ˈɑːrbɪˌtrɛrəli/ を生成しただけだ。

問題は cmudict のほうだった。Cambridge も Merriam-Webster も arbitrarily は第3音節に主強勢を置く。undermine も cmudict は AH1（第1音節）だが、辞書は un-der-MINE で語末強勢だ。

cmudictは音声技術向け（主に音声認識）の辞書であって、教材用の権威ではない。 強勢注記が教材水準であることは、どこにも保証されていない。しかしIPAを音声合成に強制適用する用途では、強勢の誤りがそのまま誤った発音になる。

変換前の値を確認したら、もっと悔しい事実が出てきた。

語	変換前	変換後(cmudict由来)	正解
arbitrarily	`/ˌɑːrbɪˈtrɛrəliː/`	`/ˈɑːrbɪˌtrɛrəli/`	第3音節
undermine	`/ˌʌndɚˈmaɪn/`	`/ˈʌndɚˌmaɪn/`	語末
stratum	`/ˈstreɪtəm/`	`/ˈstrætəm/`	streɪ を優先（両形とも実在）

先頭の2語は、変換前のほうが正しかった。 stratum は両形とも米国で実在する変種だが、教材の優先形としては変換前の /ˈstreɪtəm/ を採るべきものだった。「機械的で網羅的な辞書に寄せれば品質が上がる」という発想が裏目に出た形だ。

被害範囲を測ったら、その変換で書き換えた3,557行のうち 940行で主強勢の音節位置が動いていた。

Wiktionaryを参照にしようとしたら、まず403で殴られた

正解を照合する参照先が要る。Cambridge US か Merriam-Webster を見に行くのが筋だと思ってHTTPで取りに行ったら、全滅した。

辞書	結果
Cambridge Dictionary	403 Forbidden
Merriam-Webster	403
Oxford Learner's Dictionaries	403
Collins	403

主要な辞書サイトはほぼ自動取得を拒否する。当然といえば当然だ。UAを偽装すれば通るかもしれないが、それは相手が明示的に拒否しているものを迂回する行為なのでやらない。

残ったのが Wiktionary だった。ここは API があって、しかも生の wikitext を取れるのが大きい。

* {{IPA|en|/ˌʌn.dəˈmaɪn/|a=RP}}
* {{IPA|en|/ˌʌn.dɚˈmaɪn/|a=GA}}

a=GA が General American（米国式）、a=RP が Received Pronunciation（英国式）。レンダリング済みのHTMLだとこのアクセント種別が読み取りにくいが、wikitextなら確実に取れる。しかも1リクエストで50語まとめて引ける。

約4.9万の見出し語を問い合わせて、2.9万語でGenAm表記が取れた（59%）。残りは項目自体が無いか、英語のIPAが載っていない。ここから強勢記号の無い表記などを弾くので、行の照合に実際に使えた参照はもう少し減る（内訳は後述）。

Wiktionaryも当てにならなかった

参照が手に入ったので、現行データと突き合わせて不一致を洗い出した。そして中身を見て青くなった。

another     参照 /ˈə.nə.d̪ɜ(r)/     ← 歯音記号付きの謎表記
canada      参照 /kəˈnɑːdə/         ← カナダは「キャナダ」では
motivation  参照 /ˈmoʊ.tə.veɪ.ʃən/ ← 主強勢が veɪ にない
repair      参照 /ˈriːpɛɚ/          ← これ re-pair（組み直す）では

原因を切り分けると、これは1種類の問題ではなかった。

本当にWiktionary側が誤っているもの。 motivation はGAとラベルされた表記の主強勢が第1音節にある。教材辞書はどれも veɪ に置く。
GA表記が無く、別方言の表記で代用されたもの。 another の歯音記号付き表記は南アジア英語の変種だ。こちらの取得側が「GAが無ければ無ラベルの表記で代用する」というフォールバックをしていて、それが拾ってきた。
同じ綴りの別語。 小文字の canada はWiktionaryでは国名ではなく液量の単位で、repair は「修理する」ではなく「もう一度ペアにする」の re-pair の発音が返ってきている。見出し文字列だけで照合すると、大文字小文字や語義の違いは吸収できない。

つまりWiktionary自体の誤りは一部で、残りは見出し文字列だけで機械照合すれば必ず踏む構造的な罠だった。ただ、機械的に採用すれば改悪になるという意味ではどれも同じだ。放っておけば「リペア」が「リーペア」になり、another の発音に歯音が混ざる。

洗い出した不一致から74件をサンプルし、まず1系統目のLLM（GPT-5.6-sol）に「現行と参照のどちらが正しいか」を判定させて、規模感を実測した。

	割合
参照側が使えない（現行が正しい）	13.5%
現行が誤り（参照が正しい）	16.2%
どちらも正しい（許容変種）	70.3%

この数字が今回の全てだと思っている。1モデルの一次判定なので絶対値は幅を持って見るべきだが、あとで対象を辞書全体に広げて二重裁定にしても、「不一致の大半は変種で、参照側にも一定の使えない値が混ざる」という構図は最後まで変わらなかった。

まず、不一致の7割は単なる変種だった。「食い違っている＝どちらかが間違い」ではない。英語には複数の許容される発音が普通に存在する。

そして参照側が使えないケースが1割強ある。もし「不一致は参照に寄せる」という素朴な処理をしていたら、この判定に従う限り52件を無意味に書き換えたうえ、10件を改悪していた。監査したせいで品質が下がるという最悪の結果だ。

Wiktionaryはクラウドソースなので誤りが混ざるのは当然だが、規則的なパターンが見えたのも興味深い。-ation -ization -ality -ologist といった規則的な派生語で、主強勢を語幹側に戻す表記が繰り返し出てくる。原因までは追っていない。

念のため書いておくと、これはWiktionaryを腐す話ではない。無料で機械可読でアクセント種別まで付いている英語発音データは他にほぼ選択肢がなく、今回の監査はWiktionaryなしには成立しなかった。「唯一使える参照の1割強が当てにならない」という条件下でどう確定させるか、が問題なのだ。

LLMも正解を持っていなかった

参照が信用できないなら、LLMに判定させればいい——とはならなかった。

先に書いておくと、5.8万行を全部LLMに読ませたわけではない。時間もコストも現実的でないし、そもそもその必要がない。

参照と主強勢の位置が一致している → 変更不要（参照が取れた行の98%がこれ）
英国式の任意表記 (r) を、rを常に発音する米国式（rhotic）で確定する → 方針が決まっていれば一意
音節ドットなど表記規約から外れた文字を除去する → 判断の余地なし

機械的に確定できるところを削っていくと、本当に判断が要るのは数百行まで落ちる。LLMに聞くのはそこからだ。

残った数百行の判定は「英語音声学の専門判断」で、誤ると音声に直結する。安いモデルを並べて多数決を取るより、強いモデル2系統で独立に判定させて、割れたら3つ目に投げる構成にした。幸い Codex も Claude もサブスク枠があったので、一次判定の2系統（GPT-5.6-sol と Opus 5）は追加課金を気にせず何百件でも回せる。バッチを組み直して2周走らせたりもしたが、費用は考えなくてよかった。

そこで2系統目として Opus 5 を足し、較正に使った74件を独立に判定させた。並べた結果がこれだ。

判定	GPT-5.6-sol	Claude Opus 5
どちらも許容	52	19
現行が正しい	10	23
参照が正しい	12	32

綺麗に割れた。 GPT-5.6-sol は「どちらも許容」に倒し、Opus 5 は「参照が正しい」に倒している。同じ入力、同じ選択肢で、傾向がここまで違う。

どちらかが優秀という話ではなく、判定の閾値が違うのだと思う。GPT-5.6-sol は変種の存在に寛容で、Opus 5 は代表発音を1つに絞ろうとする。どちらの態度にも理がある。

つまり LLM単独でも決まらない。cmudictも決まらない、Wiktionaryも決まらない、LLMも決まらない。ではどうするか。

技法1: 許容集合の積を取る

2系統に投げたのだから「2票一致したものだけ採用」が素直に見える。実際そう実装しかけた。

しかしこれは厳しすぎる。GPT-5.6-sol が「どちらも許容」、Opus 5 が「参照が正しい」と答えたケースを考えてみると、

GPT-5.6-sol の主張: 現行も参照も許容できる
Opus 5 の主張: 参照が正しい

両者とも「参照は許容できる」と言っている。 食い違っているのは「現行も許容か」だけで、参照を採用してよいかについては一致している。これを保留にするのは情報を捨てている。

そこで、判定ラベルではなく各判定が含意する「許容できる答えの集合」の積で行動を決めることにした。

判定	許容集合
current_correct	{現行}
reference_correct	{参照}
both_acceptable	{現行, 参照}
both_wrong	{推奨形}

（both_wrong の場合は、判定側に代わりの推奨形を出させてそれを集合とする）

{R} ∩ {C,R} = {R}  → 参照を適用してよい
{C} ∩ {C,R} = {C}  → 現行維持
{C} ∩ {R}   = {}   → 真の衝突。保留

both_wrong を除いた3値の間では、真に衝突するのは current_correct × reference_correct の組み合わせだけになる（both_wrong が絡む場合は、推奨形どうしが一致するかを別途見る）。

最初の照合（cmudict変換で書き換えられた3,557行の突き合わせ）では不一致が65件出ていたが、この規則で 62件が決着し、真の衝突は3件だけだった。ラベル一致を条件にしていたら大半が保留に落ちていたので、効果は大きい。

真の衝突は、たとえばこういうものだ。understatement に対して、GPT-5.6-sol は「主強勢は state。under 側に置く現行形は代表的なGAではない」、Opus 5 は「MW も Cambridge も第1表記は under 側に強勢を置く形」——同じ辞書群を根拠に挙げながら、正反対の結論を出してくる。こうなるとLLMを何往復させても決まらないので、根拠ごと保留として記録した。

複数のLLMに判定させて突き合わせる場面は多いと思うが、ラベルの一致ではなく「行動が確定するか」で見るのは他のタスクにも効くはずだ。

技法2: ゲートを非対称にする

もう一つ入れたのが非対称ゲートだ。

今回、誤って変更するコストと、直さないコストは等価ではない。IPAは音声合成に直結するので、間違った値を入れると誤った発音が生成される。一方で直さなければ、既存の問題がそのまま残るだけだ。悪化はしない。

なので判定を対称にしなかった。

据え置き … 根拠が弱くても許容（リスクは現状のまま）
変更     … 積極的な合意が要る

迷ったら現行維持。これで「監査したせいで悪化した」が起きる確率を大きく下げられる。2系統が同時に同じ誤り方をする共通モード故障までは防げないが、単独モデルの癖による誤変更はここで止まる。

前述の「不一致の7割は変種」という実測値があるので、この設計は数字の裏付けもある。変種を律儀に「優先形」へ書き換えて回っても、品質は上がらないのに音声再生成のコストだけかかる。

技法3: 手元のデータを読ませる

2系統が割れた分と、「語義が分からないと決められない」とされた語は、3つ目の Claude Fable 5 に回した。

一次判定の2系統と違って、Fable は単価が高く、使用量もかなり厳しく制限されている。 AI界隈の人ならご存知のとおりで、全件に使えるような枠ではない。なので2回に分けて計40件、ここぞという一点だけに絞って投入した。結果的にこの配分は正解で、Fable に回ってきたのは先行2モデルが手詰まりになった難所ばかりだった。安いモデルを大量に回して解ける問題ではなかった。

そしてここで効いたのは、モデルの賢さよりアプローチの差だった。先行2モデルは語の綴りとIPAだけを見て推論していたが、Fable 5 は（エージェントとして動かし、DB照会を許可していたので）こちらのDBに入っている日本語訳と語義説明を読みに行った。

coruscant  語義「きらめく」を確認 → 形容詞と確定 → /kəˈrʌskənt/
aba        語義「アバ布」を確認 → 頭字語ABAではない → /əˈbɑː/
arete      語義から哲学のアレテーと確定 → /ˈærəˌteɪ/
doucet     姓と確定 → 現行維持

arete は山稜の arête（アレート）なのかギリシャ哲学の aretē（アレテー）なのかで発音が変わる。語義が確定しないと発音は決まらない。そして語義は自分のDBに書いてある。（採用した発音はあくまで教材としての優先形で、語ごとの根拠と変種の有無は台帳に記録してある）

当たり前の話だが、最初から入力に含めておくべき情報だった。2周分の判定を無駄にした。LLMに何かを判定させるとき、「自分が持っている文脈を渡し切れているか」は先に確認したほうがいい。

一番の敵は自分の検査プログラムだった

ここからが本題かもしれない。

辞書照合とは別に、外部ソース抜きで判定できる欠陥も探した。「主強勢は1語に1つ」のような、定義から言える話だ。これならレア語でも決着する。

検査を書いて回したら、こう出た。

主強勢が2つ以上ある行        : 1,351 (2.33%)
英国式表記の混入             :   724 (1.25%)
多音節なのに主強勢記号なし   :    77
不正な音節頭                 :    54
表記規約外の文字             :    10

「主強勢の重複1,351行が最大の発見です」と報告した。辞書照合で直した数十行より2桁大きく、しかも音声への影響が直接的だ。

全部間違っていた。

誤検出1: 複数語見出し（1,351 → 13）

ˈ が2つある行を並べてみたら、こうだった。

get up      /ˈɡɛt ˈʌp/
sit down    /ˈsɪt ˈdaʊn/
stand up    /ˈstænd ˈʌp/

句動詞だ。複数語の見出しでは、辞書表記上、構成語それぞれに語強勢の記号が付くので、ˈ が複数あるのが正常。「主強勢は1語に1つ」は単語には成り立つが、句の表記には成り立たない。

1,351行のうち1,338行（99%）がこれだった。真の欠陥は13行。

誤検出2: r音性オフグライド（77 → 30）

「多音節語なのに強勢記号がない」で引っかかった行にこれがあった。

bare   /bɛɚ/
flair  /flɛɚ/

ɛ と ɚ を別々の母音として数えて2音節と判定していた。実際には ɛɚ でひとつの音節核（r音性の二重母音）だ。単音節語に強勢記号がないのは正常。

誤検出3: 実在する音節頭（54 → 23）

「英語にありえない子音連続」で引っかかったもの。

whirlwind  /ˈhwɜːrlˌwɪnd/  頭=hw
knesset    /ˈknɛsɛt/        頭=kn
pueblo     /ˈpwɛbloʊ/       頭=pw
exclusive  /ɪkˈskluːsɪv/    頭=skl

hw は wine-whine 合流前の発音として実在するし（which と witch を発音し分ける話者は今もいる）、skl は sclerosis で普通に出てくる。kn pw は外来語・固有名詞。外来語は英語の音素配列則を外れるのが正常で、それを「不正」と判定するほうが間違っている。

誤検出4: 部分一致（724 → 17）

「英国式の混入」は ɪə eə ʊə といった英国式の中舌二重母音を探していた。が、これが /ˈhaɪər/（higher）や /səˈsaɪəti/（society）の aɪə に部分一致していた。単なる正規表現のミス。

教訓

5つの検査の初期出力は合計2,216行。精査後に残った真の欠陥は 93行（13+30+23+17+10）。初期検出の96%が誤報だった。正確だったのは、一番地味な「表記規約外の文字: 10行」だけだ。

壊れていたのはデータではなく検査器だった。 しかも自分は検査器を書いた直後に数字を報告している。サンプルを目視してから出していれば全部防げた。

「正解が自明でないものを大量に判定する作業では、検査器そのものを先に検証する」——書いてみると当たり前すぎるが、実際にはデータの異常のほうに目が行って、自分のコードを疑うのが後回しになる。今回のようにもっともらしい数字が出てしまうと特にそうだ。

米国式に固定しないと、そもそも比較が成立しない

もう一つ、地味だが重要だったのが基準の固定だ。

英語の発音は方言差が大きい。同じ語でも米国式と英国式で強勢位置すら変わることがある。基準を決めずに「正しい発音」を議論しても収束しない。

今回は最初から General American（米国式）に統一すると決めていた。これがないと、

ballet      米 /bæˈleɪ/        英 /ˈbæleɪ/       ← 主強勢の位置ごと変わる
undermine   米 /ˌʌndɚˈmaɪn/    英 /ˌʌndəˈmaɪn/   ← rの響きが変わる

参照のどれを採るかで永遠に揉める。Wiktionaryのアクセント種別（a=GA）を読んでいるのはこのためで、RP限定の表記しか無い語は「GenAmの根拠にならない」として判定不能に落としている。

表記の細部も基準が要る。今回のデータは ɹ を使わず r を使い、音節ドットを使わず、長音符 ː は使う、という慣行だった。Wiktionaryは逆に ɹ とドットを使う。LLMに推奨形を出させると当然Wiktionary風の表記が返ってくるので、取り込む前に自分の表記規約へ正規化する工程が必要になる。

これを怠ると、直したつもりで表記が混在した辞書ができあがる。

品詞と語義で発音が割れる

機械処理を難しくしている最大の要因がこれだった。

品詞で変わる

project   名詞 /ˈprɑdʒɛkt/    動詞 /prəˈdʒɛkt/
present   形容詞 /ˈprɛzənt/    動詞 /prɪˈzɛnt/
misfire   名詞 /ˈmɪsˌfaɪɚ/     動詞 /mɪsˈfaɪɚ/

英語には名詞前部強勢・動詞後部強勢という強い傾向があって、同綴りで品詞が違えば強勢が動く語が多い。参照にはこの区別が付いていないことが多いので、動詞の行に名詞の発音が返ってくる。品詞を見ずに適用すると逆方向に壊す。

副詞と形容詞でも変わる

nearby   副詞 near-BY     形容詞 NEAR-by
offshore 副詞 off-SHORE   形容詞 OFF-shore

これは厄介だった。同じ綴り・似た品詞なのに、行ごとに逆の結論になる。しかも辞書によって両形の載せ方が割れる語もある。見出し語（綴り）単位で一括置換するコードを書いていたら確実に壊していた。

品詞が同じでも意味で変わる

とどめがこれだ。冒頭で挙げた lead がこれにあたる。

lead  /liːd/ 先頭    /lɛd/ 鉛
bass  /bæs/ 魚       /beɪs/ 低音
bow   /baʊ/ お辞儀   /boʊ/ 弓

どれも両方とも名詞である。品詞では区別できない。「同じ見出し語・同じ品詞なら同じ発音のはず」という整合性チェックを書いたら、これらが「不整合」として引っかかった。当然、正常なのはデータのほうだ。

さらに単数形と複数形は別の見出しなので、superconductor と superconductors で強勢が食い違っていても、見出し語単位のチェックでは検出できなかった。かといって単複ペアをチェックすると、今度は indoor（形容詞 IN-door）と indoors（副詞 in-DOORS）が誤検出される。正しく違うからだ。

整合性チェックは、書けば書くほど例外が出てくる。

そもそも正解が存在しない語がある

最後に、レア語の話。

頻出語なら辞書間で見解が一致するが、レア語や固有名詞はそもそも統一見解が存在しないことがある。

3つのモデル全てが「決められない」と答えた語がいくつかあった。

kua    語義欄がカタカナのみ。中国語の「卦」か、マオリ語か、人名か
vali   北欧神話の神か、オスマン帝国の知事か。前者なら前部強勢、後者なら後部強勢
pata   主要な英米辞書に見出しが無い

こういう語に無理に値を入れると、もっともらしいが根拠のない発音が辞書に載ることになる。しかもそれが音声合成されて配信される。

なので出力に undecidable を許可した。「確定できないなら正直にそう言え、現行を変えないコストのほうが低い」と明示的に指示している。結果として保留になった語がいくつか残ったが、これは失敗ではなく正しい出力だと思っている。

全件を無理に決着させると、決着の質が下がる。 保留を一級の出力として扱えるかどうかは、この種の作業では結構重要な設計判断だ。

結果: 5.8万行を調べて220行

最終的に修正したのは 220行だった。見出し語は約4.9万だが、辞書は語義・品詞ごとに行を分けているので、IPAを持つ行は5.8万ある。母数からの絞り込みはこうなる。

IPAを持つ行                     57,886
├ 参照が使えた                  27,910  (48.2%)
│  ├ 主強勢が一致               27,431  (参照が使えた分の 98.3%)
│  └ 不一致                        479  (同 1.7%)
└ 参照が無い / 使えない         29,976  (51.8%)
   ├ Wiktionaryに項目なし       21,331
   ├ 参照に強勢記号なし          6,541
   └ 米国式の表記なし            2,104

最終的に修正                       220  (全体の 0.38%)

参照が使えたのは半分弱で、そのうち 98.3%は最初から一致していた。見出し語ベースでは59%取れていたのが行ベースで48.2%に下がるのは、項目はあっても強勢記号や米国式表記が無いものを照合から外しているためだ。Wiktionaryに項目が無い語が2万行以上あるのは、固有名詞・専門語・活用形が多いため。ここは今回未着手で残している。

不一致479行も、そのまま修正候補になるわけではない。

不一致479行の内訳	行数
複数語見出し（`ˈ` が複数あって正常）	101
参照側が壊れている	16
現行が別の変種と一致している（品詞・方言違い）	83
ヘテロニム（同綴で発音が異なる語）	3
実際に裁定へ回した	276

479件中203件（42%）は、そもそも直す必要がなかった。 検出した時点では全部「不一致」に見えるが、切り分けるとこうなる。

形式的欠陥のほうはもっと極端で、検査の初期出力 **2,216行（3.8%）が、精査後は93行（0.16%）**まで落ちた。前述のとおり、この落差はほぼ全部が自分の検査器の誤検出だった。93行のうち24行は辞書照合フェーズの修正で既に直っていたので、残り69行を処理した。フェーズ表の「71」は、これに複合語への第二強勢付与といった表記規約の適用ぶんを足した行数で、保留は3モデルとも判定不能だった kua 1件だけだ。

内訳はこうなる。

フェーズ	行数
報告された語の周辺（最初の照合）	35
辞書全体の照合	97
3モデル目（Fable 5）による裁定	17
形式的欠陥（強勢の重複・欠落・表記の混在）	71

全体の 0.38% と書くと少なく見えるが、主強勢の誤りは1語でも音声になれば分かる種類の欠陥だ。しかも今回の220行には arbitrarily undermine electricity halfway のような普通に出てくる語が含まれている。率ではなく、どの語が壊れているかが問題になる。

音声は、修正220行のうち音声配信対象の165語を再合成した（残り55行は検索・クイズから除外済みで音声を配っていない語）。ここにも罠が1つある。使っている合成エンジンでは、SSMLのIPAが不正だと400が返るのだが、生成パイプラインはそれを捕まえて綴り読みで作り直して埋める造りになっている。つまり黙って落ちる。「直したつもりがIPAは無視されていた」が起こりうるので、フォールバック件数を必ず数える。今回は0件で、全語がIPA指定のまま受理された。

白状すると、うち43語は再合成の母集団から漏れていたのがこの記事のレビュー中に発覚して埋めた分だ。最後まで「検査器を疑え」だった。

ブラウザが音声を長期キャッシュするので、URLのバージョン番号も上げている。

ところで、これは1日ぶんの作業だ

身も蓋もない話をすると、ここまで書いた一連の流れは、せいぜい1日ぶんの作業量だった。

約4.9万語をWiktionaryに問い合わせて参照コーパスを作る   30分（放っておくだけ）
5.8万行の照合                                          数秒
数百件のLLM二重裁定                                    並列で回して数分
対象語の音声再合成とアップロード                       十数分

少し前なら、辞書1冊ぶんの発音を人手で照合するなんて、専門家を雇って何週間かかけるプロジェクトだ。それが1日で終わる。しかも自分は音声学の専門家ではない。

ただ、速くなったのは「量をこなす」部分だけだというのも同時に実感した。今回いちばん時間を食ったのは、判定規則をどう設計するか（許容集合の積、非対称ゲート）と、自分の検査器が吐いた誤報に気づくところだ。ここは量の問題ではないので、LLMを足しても速くならない。

むしろ処理が速い分、間違った判断を高速に大量適用できてしまう危険のほうが増している。1,351行を「欠陥」と判定したまま機械修正に流していたら、1日で1,338行を壊せた。不一致を機械的に参照へ寄せていたら、10行を改悪していた。

効率化は、正しい方向を向いているときだけ効率化だ。向きを間違えたまま高速化すると、ただ速く壊れる。

LLMを使った業務効率化、便利だが素直に恐ろしい。

おわりに

1語の修正のつもりが、辞書全体の監査になった。

技術的に面白かったのは、信用できる情報源が一つも無い状態で、どう確定させるかという問題設定に落ちたことだ。cmudictは用途が違い、Wiktionary由来の参照は不一致箇所の1割強で使えず、LLMは判定が割れる。それでも組み合わせ方を工夫すれば、大半は機械的に決着できた。

一方で一番痛かったのは、外部のデータではなく自分の検査プログラムの検出の96%が誤報だったことだ。測定器を疑うのは、測定対象を疑うより難しい。

えいたんごクイズでは、こうやって直した発音記号をそのまま音声合成に流して、サイトの単語音声とYouTubeの単語紹介動画を作っている。地味な作業だが、発音が間違っている教材はさすがにまずいので、今後も定期的に回していくつもりだ。

ちなみに今回の修正220行のうち音声配信対象の165語は、修正後に音声を作り直してサイトに反映済みだ。動画のほうは作り直さず、これから作る回に反映していく方針にした。過去分を全部差し替えるより、新しいものの品質を上げていくほうが現実的だと判断している。

同じように発音データを扱っている人の参考になれば。