背景

• 日本語のG2P（Grapheme-to-Phoneme、漢字仮名交じり文から読みへの変換）ライブラリを自作する機会があった
• 素朴なG2P（辞書引きベースの変換）は「明日」のような多音字・ヘテロニム（同じ表記で複数の読みを持つ語）を文脈から判定できない
• この課題に対して国内外でどんな研究・手法・OSSがあるかを調査した際のメモをまとめておく

ホモグラフとヘテロニムの違い

• ホモグラフ（Homograph）は、綴り（表記）が同じ語同士を指す上位概念で、発音が同じか異なるかによってさらに2つに分かれる
  • ヘテロニム（Heteronym）: 表記は同じだが発音が異なるもの（例: 英語の"lead"、金属の鉛／導くのlead）
  • 狭義のhomonym: 表記も発音も同じもの（例: 英語の"bat"、動物のコウモリと野球のバット）
• つまり、ヘテロニムと狭義のhomonymはどちらもホモグラフの部分集合であり、互いに排反（同時には成り立たない）

集合の関係で表すと、以下のようになる。

ヘテロニムと狭義のhomonymは排反で、かつ合わせるとホモグラフ全体になるため、以下のように直和で表せる。

• 日本語の「市場」（いちば/しじょう）のように、同じ表記で読みが複数ある語は、英語でいうヘテロニムに相当する
• 日本語ではこの現象を「多音字」（元は中国語由来の概念）や「同形異音語」と呼ぶことが多く、英語の論文では単に"homograph"と呼ばれることも多い。本メモでは、参照する文献の原語に合わせてホモグラフ・ヘテロニム・多音字を使い分けている

多音字・ヘテロニム判定という問題

• 例えば「市場」は「イチバ」にも「シジョウ」にも読める
• 辞書ベースのG2Pはどちらか一方を機械的に返すだけで、文脈による判定ができない
• 中国語圏では同じ問題が「多音字（Polyphone）」として研究されており、日本語より事例が多い
• 発想は大きく3つに分けられる
  • 候補を絞り込んでから文脈で判定する
  • 音声を使って実際の発話から読みを検証する
  • 辞書知識を後付けで注入する

pyopenjtalk

日本語のG2P・TTSでデファクトスタンダードになっているpyopenjtalkが実際にどう動いているか、パッケージ内のCythonバインディング定義を読んで確認した。

OpenJTalk

• pyopenjtalkの実体は、OpenJTalkという日本語テキスト音声合成エンジンのPythonバインディング
• OpenJTalk本体はC/C++で書かれており、テキストを入力すると形態素解析から音声波形の生成までを一貫して行う
• pyopenjtalkはこのOpenJTalk本体をCythonでラップし、Pythonから呼び出せるようにしたもの

MeCab

• OpenJTalkが内部の形態素解析エンジンとして使っている、汎用の日本語形態素解析器
• 工藤拓氏によって開発され、単語コスト・連接コストをCRF（条件付き確率場）などの機械学習手法で学習する設計が特徴
• 単体では辞書を差し替えて使う汎用ツールで、IPAdicやUniDicなど複数の辞書が使われる
• OpenJTalkはMeCabのライブラリをそのまま組み込み、辞書だけをTTS用に用意したものに差し替えて使っている
• 実際にpyopenjtalkに同梱されている辞書一式（sys.dic・matrix.bin・left-id.def・right-id.def・unk.dic・char.bin）のライセンス表記を確認すると、NAIST（奈良先端科学技術大学院大学）の辞書とUniDicの両方の著作権表記が含まれており、これらを元にした辞書が使われている

OpenJTalkの仕組み

テキストから音声波形まで、以下のパイプラインで処理する。

1. text2mecab: 入力テキストを正規化し、MeCabに渡せる形式に変換
2. MeCabによる形態素解析: 文をラティス（考えられる分割・品詞の候補を網羅したグラフ構造）として展開し、各形態素の単語コスト（辞書由来）と形態素間の連接コスト（matrix.bin、左右の文脈IDで定義）の合計が最小になる経路を探索する。これが最終的な分かち書き結果になる
3. mecab2njd: MeCabの出力をNJD（Natural Japanese Dictionary）というノードのリンクリストに変換
4. njd_set_pronunciation: 辞書に登録された発音をノードにセットする。多音字の読みはここで辞書エントリの値がそのまま採用される
5. njd_set_digit: 数詞・助数詞の読み処理
6. njd_set_accent_phrase / njd_set_accent_type: アクセント句の切れ目とアクセント型を規則ベースで付与
7. njd_set_long_vowel / njd_set_unvoiced_vowel: 長音化・母音の無声化などの音韻規則を適用
8. njd2jpcommon: NJDを「単語→モーラ→音素」の階層構造に変換し、音声合成エンジン向けのフルコンテキストラベルを生成
9. htsengine: フルコンテキストラベルと統計モデル（htsvoice）から波形を合成

ポイント:

• 重要なのは、多音字の読みはMeCabが選んだ辞書エントリの発音フィールドがそのまま使われるという点
• 文の意味を理解して読みを判定しているわけではなく、あくまで形態素の連接コスト（品詞列としての自然さ）に基づく分割の副産物として、結果的に読みが決まる
• したがって「上手」のように品詞そのものが変わる語はある程度読み分けられる
• 一方、「市場」のように品詞も分割位置も変わらない同形異音語は原理的に判定できない
• これが、このメモで挙げた各種の先行研究が対応しようとしている限界そのものにあたる

ビタビアルゴ

• MeCabの形態素解析ラティスから最小コスト経路を求める探索に使われている動的計画法
• ラティスの各ノード（形態素候補）は、文頭からそのノードまでの累積コスト（辞書の単語コスト＋直前ノードとの連接コスト）を持つ
• 各位置で、直前になりうる全ノードとの連接コストを比較し、累積コストが最小になる経路だけを残しながら文末まで進む
• 全経路を総当たりで比較するのではなく、途中の最小コストだけを保持して使い回すため、計算量を抑えられる
• 実際にpyopenjtalkが使っているMeCabの内部構造体（mecab_node_t）にも、単語コスト（wcost）と文頭からの累積コスト（cost）というフィールドがあり、この累積最小コストの構造がそのままビタビアルゴリズムのDPテーブルに対応している

Google Mecari: 商用の日本語Text-to-Pronunciationモデル

• Google社内で2020年から、サーバー・オンデバイス問わず全ての日本語音声合成に使われている、テキストから発音を推定するモデルの名称が「Mecari」
• Mazovetskiy, KudoによるData processing for Japanese text-to-pronunciation models（JLR2024発表資料）で、その設計が公開された
• 前述のMeCab/Viterbiと同じ「ラティス＋Viterbi探索」という設計思想を採用しているが、いくつかの点でさらに発展させている

設計の要点

• 数詞などのsemiotic classや外来語のG2Pも含め、あらゆる語彙・生成エントリを1つのラティスに含め、分割と発音推定を同時に解く1つの問題として扱う。分割してから発音推定するパイプライン方式では最適にならない、と明言されている
• 各ラティスノードは、そのノード・入力全体・ラティス構造にアクセスできるMLモデルによって、他のノードとは独立にスコアリングされる
• ノードを独立にスコアリングする設計により、部分的にしかアノテーションされていないデータからでも学習できる（正解が分かっている部分にだけ勾配を伝播し、不明な部分は無視する）
• スコアリング後、MeCabと同様にViterbi探索で最良パスを求める
• 最後に、別モデルがラティス構造を使ってピッチアクセントを割り当てる

読み（Reading）と発音（Pronunciation）の違い

• 辞書やコーパスに振られる「読み」（ふりがな等）と、実際の「発音」は同じではないという指摘がある
  • 例: 「女王」の読みは「じょおう」だが、実際の発音は音が伸びる「じょおー」であり、「じょーう」ではない
• この違いを埋めるため、辞書の各単語について「読み→発音」の対応を、EMアルゴリズム（線形アライメント制約付きのIBM Model 1）で教師なし学習している

表記ゆれに対するFuzzy Matching

• 「ぐぁば」「ぐゎば」「ぐあば」のように、同じ発音でも長音・拗音・歴史的仮名遣いなどによる表記ゆれが起こりうる
• 人手で構築した100組以上の表記ゆれ対応表と、ピッチアクセント情報を伝播させながらコーパスのアノテーションをラティスのノードに対応づけるFuzzy Alignmentアルゴリズムで対応している

seq2seqを採用しなかった理由

• 部分アノテーションデータからの学習が難しい
• 制約のないseq2seqモデルは「馬鹿げた誤り（silly errors）」を起こしやすい
• モデルサイズ・学習時間・保守コストの懸念がある
• Mecariはこれらを回避しつつ、学習が速く（約30分）、低スペックなCPU（オンデバイス）でも高速に動作するとされている

商用の実例が、本記事で扱っている候補制限型・分類ベースの設計思想（辞書・ラティスによる出力空間の制約）を裏付けているのは興味深い。

中国語・多言語の先行研究

多音字判定の研究は、CPP（Chinese Polyphone Prediction）というベンチマークを軸に中国語圏で活発に進んでいる。

Dict-TTSの結果は興味深く、辞書の意味知識だけに頼るニューラル手法でも、日本語では既存のルールベースG2Pに勝てないという結果になっている。表語文字と表音文字が混在し、音読み・訓読みという体系を持つ日本語特有の難しさが背景にあると考えられる。

なお、Logit Adjustmentは自分の手元でも試しており、具体的な数値は内部実験の記録になるためここには書かないが、感触として有効そうだった。

日本語特化の先行研究

日本語を直接対象にした研究は中国語ほど多くないが、いくつか重要な先行事例がある。

非公開の商用モデル（参考記録）

論文やOSSではないが、多音字判定という点で無視できない先行事例としてParakeet社のParayomi v1.0.0がある。

• 自社の日本語読み推定モデルで、JKYB-Parakeet（後述のベンチマーク）でAccuracy 99.808%を公開している
• 同ベンチマークでGPT-5.5と同率、Gemini 3.1 Proの99.749%を上回る
• Parakeet社自身の説明では、大規模言語モデルのような重いモデルは使わず、外部APIも使わずCPUでも高速に動作するとされている
• モデルの重み・アーキテクチャ・学習データ・パラメータ数は公開されておらず、公開されているHugging Face Spaceもフロントエンドのみでバックエンドは非公開
• 公開情報はZenn記事とベンチマーク数値に限られる

精度そのものは高いが再現性のある手法として参照はできず、あくまで「ここまでの精度が実用レベルで達成可能」という目標値としての位置づけになる。

英語圏のヘテロニム研究

英語の"read"（過去形/現在形）のようなホモグラフも同種の問題として研究されている。

学習手法・評価基準に関する研究

多音字判定そのものではなく、長尾分布データの学習や早期打ち切り基準という周辺の学習手法に関する研究も参考になる。

seq2seq型G2P（候補制限型とは異なる系譜）

ここまでの手法の多くは「候補を絞り込んでから分類する」（g2pW系）という設計だが、文字列を直接生成するseq2seq型という別の系譜もある。未登録語にも原理上対応できる一方、現状の公開実装は候補制限型より精度が低い傾向にある。

ByT5自体はG2P専用ではなく、汎用のバイト単位T5だが、その後継となるバイト単位言語モデルの系譜もG2Pの設計を考える上で参考になる（いずれもG2Pへの直接応用は未確認、一般的な言語モデルアーキテクチャとして）。

KWJAが使っているretrieva-jp/t5-base-longのように、日本語事前学習済みT5にはいくつか系統がある。

いずれも汎用の日本語T5であり、G2P専用に設計されたものではない。KWJAのように読み推定を含む複数タスクを1つのT5でこなす場合はこうした汎用モデルをファインチューンする一方、ByT5 G2PやMixedG2P-T5のように、そもそもサブワードではなくバイト・文字単位で扱う設計にすることで、日本語特有の未知語・混在スクリプト問題を回避しようとする流れもある。

ハイブリッドG2P設計（規則ベース＋ニューラルの併用）

候補制限型・seq2seq型のどちらでもなく、規則的に決まる部分は軽量な手法に任せ、未知・不規則な部分だけニューラルモデルに回すという設計も、低〜中資源言語のG2P研究では繰り返し見られる。

「既知・規則的な部分は軽量な手法に任せ、未知・不規則な部分だけ重いモデルに回す」という設計は、パシュト語・タガログ語・リトアニア語などのRNN低資源G2P研究にも共通して見られる。データが潤沢でない言語ほど合理的な設計とされ、逆に英語のような高資源言語では、候補制限・ハイブリッドを介さないフルニューラルのend-to-endが主流になる傾向がある。

手法の見取り図: BERT系・seq2seq系・ハイブリッド系

ここまで挙げた手法をアーキテクチャの系統で整理すると、大きく3つに分かれる。

BERT系（候補制限型・分類ベース）

候補を絞り込んだ上で、BERT等のエンコーダでどれが正解かを分類する設計。

• g2pW
• yomikata／tsqyomi
• Sony 日本語TTS front-end
• NHK技研 Transformer+BERTハイブリッド
• DLM
• Logit Adjustment
• CVTE-Poly

seq2seq系（文字列を直接生成）

候補を絞らず、文字列から読みを直接生成する設計。未登録語にも原理上対応できる一方、現状の公開実装は候補制限型より精度が低い傾向にある。

• Seq2Seq G2Pの起源（Yao & Zweig）
• KWJA
• ByT5によるG2P
• NVIDIA NeMo G2Pモジュール
• MixedG2P-T5

ハイブリッド系（規則ベース＋ニューラルの併用）

規則的に決まる部分は軽量な手法に任せ、未知・不規則な部分だけニューラルモデルに回す設計。低〜中資源言語で繰り返し見られるパターン。

• Fast, Not Fancy（HomoFast eSpeak）
• ブルガリア語のFST+seq2seq
• タイ語の辞書引き+ニューラルフォールバック
• モンゴル語のハイブリッドアプローチ

どちらにも分類しづらい例外

• LLM生成型（Ant Group、CyberAgentのLLMベンチマーク）: 広い意味ではseq2seq（生成）寄りだが、専用に学習した小型モデルではなく汎用LLMをプロンプトで使う点が異なる
• furigana_whisper_small_jsut: テキストではなく音声を条件に使うWhisperベースのseq2seqで、入力モダリティが他と異なる

2系統の境界は実は曖昧

BERT系とseq2seq系は、設計思想としては対照的だが、どちらも辞書知識を使って出力を制約できるという点では収束する。

• BERT系（g2pW）は、対象語ごとにありうる読みだけを残すハードマスクで、共有出力層の分類先を辞書から絞り込んでいる
• seq2seq系でも、デコーダの各生成ステップで辞書に無い文字列を候補から除外する制約付きデコーディング（lexically constrained decoding）を使えば、同じように辞書で出力を絞り込める
• つまり「候補を絞ってから分類するか、生成しながら絞り込むか」という違いであって、辞書知識を使うこと自体は両系統に共通する選択肢
• 逆に言えば、seq2seq系の最大の弱点である未知語へのハルシネーション（辞書に無い読みをもっともらしく生成してしまう問題）も、制約をかければ候補制限型と同じ土俵に戻ってきてしまうため、seq2seq本来の強み（辞書に無い語にも対応できること）とのトレードオフになる

OSS・公開モデル

日本語NLP全般のcuratedリストであるtaishi-i/awesome-japanese-nlp-resourcesも一通り確認したが、上記に挙げた以外で多音字・ヘテロニム判定に直接効く新規のツールは見当たらなかった。

辞書

候補生成器の辞書側（表記にどんな読みがあり得るか）を補強する語彙辞書群。文脈に応じた読みの判定はしておらず、あくまで候補の網羅性を上げるためのデータになる。

JMdict・JMnedict・jmdict-furiganaなどはCC BY-SA 4.0のShare-Alike条件があり、派生データやモデルを外部公開する場合は帰属表示・同一ライセンス継承が必要になる点に注意。UniDic-cwjもNew BSD選択時に「営利目的利用は要問い合わせ」という注記があり、商用利用前の確認が推奨される。

データセット・ベンチマーク

同じ京都大学系列のKyotoCorpus（1995年毎日新聞約4万文への構文注釈、読みも付与）も読み付きコーパスとして存在するが、原文は毎日新聞1995年版CD-ROMを別途入手する必要があり、GitHub上ではアノテーション情報のみが公開されているため、手軽に使えるデータではない。

データ収集のアイデア

既存の読み付きコーパスが足りない場合、以下のような発想で新たに読みデータを集められる。

点字からの読み抽出

• 日本語の点字（六点点字）は仮名・モーラ単位で書かれる表音文字であり、どんな漢字仮名交じり文でも、点字に翻訳された時点で読みの曖昧性がすでに人手で解消されている
• つまり、同じ原文の「通常の印刷版」と「点字版」がペアで存在すれば、両者を章・文単位で対応づけるだけで、読み付きコーパスを半自動的に作れる
• Sato, Yoshinaga, Kitsuregawa（LREC 2022）はまさにこの発想で、青空文庫のテキストと、視覚障害者向け点字図書サービス「サピエ（SAPIE）」が提供する同一作品の点字データを、章単位→文単位で対応づけ、さらに形態素辞書による単語単位のアラインメントを経て読み付きコーパスを構築した
  • Book Titleコーパス: 国立国会図書館の書誌データ（タイトル＋読み）と著者名辞書を組み合わせ、336M文字（1,640万タイトル）
  • Aozora Bunkoコーパス: 青空文庫の本文＋サピエの点字データから、52M文字（2,044作品・120著者）
  • 203種類の常用ヘテロニムの読み分布を分析し、93語・223通りの読みでBERTベースの分類器を学習、平均精度0.939を報告している
• 動機として、スクリーンリーダーでのヘテロニム誤読（「表」を「おもて」ではなく「ひょう」と読んでしまう等）が挙げられており、2019年の視覚障害者等の読書環境整備に関する法律も背景にある
• 前述のhuriganacorpus-aozoraは、この論文と同じ国立国会図書館によるデータセットで、手法的にも直接つながっている
• 同じサピエは、点字だけでなく「音声デイジー」（視覚障害者向けの音声図書）も提供しており、後述のhurigana-speech-corpus-aozoraはこちらの音声版を使っている。つまり、点字（テキストの表音表現）と音声（実際の発話）という異なるモダリティで、同じサピエ由来のデータから2種類の読み付きコーパスが作られていることになる

青空文庫の原文ルビ

• 青空文庫自体は約17,840作品を公開しており、原文には｜漢字《かんじ》という独自記法のルビがそのまま残っている
• これはhuriganacorpus-aozoraのような「全ての漢字に機械的に読みを付与した」データとは性質が異なり、あくまで底本の著者・出版社が実際にルビを振った箇所だけが対象になる
• つまり、読みの網羅性では劣るが、「どの語に対して人間がルビを振ろうと判断したか」という、ルビ付与そのもののタイミング・傾向を学習したい場合にはむしろ価値がある

法人番号公表サイトのフリガナ

• 国税庁の法人番号公表サイトは、全国の法人の基本3情報（商号・所在地・法人番号）に加えて、商号のフリガナも公開している。「フリガナの公表」という専用のFAQカテゴリがあるほど、フリガナ提供自体が明示的な機能になっている
• 全件データはCSV（Shift-JIS/Unicode）・XML形式でダウンロード可能。利用時は「国税庁の著作物であることを明記」する必要がある
• 会社名は、一般的な辞書ではカバーしづらい固有名詞の読みの宝庫であり、この種の政府公開データは貴重な情報源になる

他の政府公開データのフリガナ

法人番号公表サイトと同じ発想で、他省庁の公開データにもフリガナが付いていることがある。

• 学校コード（文部科学省）: 幼稚園から大学まで全学校種の学校コード・学校名・フリガナを、Excel/CSV形式で無料公開している。登録不要で即ダウンロード可能、定期的に更新されている。学校名も辞書化しづらい固有名詞の読みとして有用
• 商標の「称呼」（特許庁）: 商標登録では、その商標がどう読まれるか（称呼）を出願時に届け出る決まりになっている。特許庁の「特許情報の一括ダウンロードサービス」でTSV形式の商標データを取得でき、称呼もそこに含まれる（要ユーザー登録）。ブランド名・商品名という、これも辞書に無い読みの多い領域をカバーできる
• 選挙候補者名簿の音声読み上げ用データ: 一部の都道府県選挙管理委員会が、視覚障害者向けに候補者名＋よみがなを選挙ごとに公開している。ただし総務省による一元的な一括ダウンロードではなく都道府県サイトに分散しており、選挙ごとに数百件規模とデータ量は小さい
• 医療機関コード（厚生労働省）: 「医療情報ネット」オープンデータが、e-Govデータポータル経由で全国の病院・診療所・歯科・助産所・薬局の施設ID・施設名・フリガナをZIP形式で一括ダウンロード提供している。CC BY 4.0、APIキー不要、無料
• 無形文化遺産総合データベース（東京文化財研究所）: 伝統芸能・工芸技術・祭礼行事など無形文化遺産のCSV出力機能に「名称ふりがな」が含まれる。寺社・伝統芸能名は辞書に載りにくい固有名詞の代表格で、これも有用（なお、より広く有形文化財も扱う「国指定文化財等データベース」の方はCSV出力にふりがなが含まれるか未確認）
• JPX（日本取引所グループ）の上場銘柄一覧: JPXデータポータルの「企業・銘柄」ページに「全件CSV取得」ボタンがあり、銘柄名のカナ読みを含むデータが取得できる模様。ただし実際のページがボットアクセスをブロックしており、ライセンス・利用規約の詳細までは未確認

以下は確度が低いものも含めて、確認できた・できなかったものを記録しておく。

• メディア芸術データベース（旧文化庁、現・国立アートリサーチセンター）: マンガ・アニメ・ゲーム・メディアアートの作品情報データベースで、テレビアニメについてCSV/Excelデータセットが教育用に公開されている。アニメタイトルは辞書に無い独特な読みが多い領域だが、作品名によみがなフィールドが含まれるかどうかまでは確認できなかった

検討したが見送ったものも記録しておく。

• 国土数値情報 鉄道データ（国土交通省）: 駅名のデータはあるが、実際にスキーマを確認したところ属性にフリガナ・読みのフィールドが無く、駅名の表記のみだった。「三田駅」のような読みの地域差（前述のGoogle Mecariの例）を扱うには使えない
• 戸籍統一文字情報（法務省）: 読みからの文字検索はできるが、これは文字（グリフ）単位の異体字データベースであり、公式な一括ダウンロード形式が確認できなかった。同種の役割は既存のKANJIDIC2で代替できる
• NHK NEWS WEB EASY（やさしい日本語ニュース）: 全ての漢字にひらがなのルビが振られたニュースサイトで、フリガナの存在自体は確認できた。しかし政府系オープンデータと違い、NHKの著作物を一括収集・データセット化してよいかを認める利用規約が見つからず、ライセンス面がグレーなため見送り
• GBizINFO（経済産業省）: 法人番号・商号・所在地・資本金等のAPIデータ項目は確認できたが、ふりがな／よみがなフィールドの有無は確認できなかった
• 農林水産省 地理的表示（GI）保護制度データベース: 地域特産品の名称は読みが難しいものも多いが、登録産品数が170件程度と小規模な上、よみがなフィールドの有無も確認できなかった
• data.go.jp / e-Govデータポータルの横断検索: 「ふりがな」「よみがな」「カナ」で検索してみたが0件だった。このポータルの検索対象はデータセットのタイトル・タグ単位のみで、列（フィールド）レベルの説明までは検索できない仕組みのよう

この辺りまで来ると、クリーンにライセンスされた大規模なフリガナデータは概ね掘り尽くした感触がある。

動画・字幕×ふりがなWhisper

• 前述のfurigana_whisper_small_jsut（Parakeet Inc.）は、音声と書記素列（テキスト）のペアを入力に、実際に発話された読みをWhisperベースのモデルで書き起こす手法だった
• 元々の学習・想定用途はJSUTやROHANのような、クリーンな読み上げ音声コーパスだが、この手法自体は「音声とテキストがペアで存在する」という条件さえ満たせば適用できる
• 字幕（テキスト）付きの動画は、この条件を満たす音声・テキストペアを大量かつ多様なドメインで提供してくれる情報源になりうる。ニュース・講演・実況など、読み上げ音声コーパスにはない話し言葉・固有名詞・時事語の読みを収集できる可能性がある
• ただし、字幕は必ずしも実際の発話を一字一句書き起こしたものではなく（要約・意訳されている場合がある）、音声品質やノイズの影響も受けやすいため、前述のN-best編集距離によるクロスチェックのような、生成された読みの信頼度を測るフィルタリングが一段と重要になる

他の固定読み・文脈マイニングの発想

• 点字・法人番号・動画字幕以外にも、「既に読みが一意に定まっている情報源から、読みを間接的に抽出する」という同系統の発想がいくつかある
• 常用漢字表付表のように文脈に関係なく読みが1つに固定されている語であれば、その語を含む実例文をそのまま抽出するだけで学習データになる（前述のTatoebaマイニング）
• Wikipediaのように、かな表記と地の文が同じ記事内に共起する箇所を大規模にマイニングし、前後文脈と漢字候補を対応づける手法もある（前述のkatsukiono/kana-kanji-context）
• 共通しているのは、人手で読みを1件ずつアノテーションするのではなく、既存の別形式のデータ（点字・フリガナ付き公的データ・音声字幕・かな表記・固定読み語彙）を手がかりに、読みを半自動的に「逆算」する発想であること

IME（かな漢字変換）の変換ログ

• ここまでは「公開データ」を対象にしてきたが、発想を変えると行動ログにも読みの情報が眠っている
• ユーザーがひらがなで入力し、漢字に変換する操作そのものが、暗黙の読みラベルになる
• Takahashi & Mori（2014年、情報処理学会研究会報告）は、この変換ログをノイズはあるが大量に得られる読み付きデータとして活用した研究例がある
• ただし、これはGoogle日本語入力・ATOK・Microsoft IME等、各IME提供企業が保有する内部ログであり、外部に公開されているデータではない。研究の前例はあるが、一般に入手可能なデータソースというわけではない点に注意

まとめ

• ルビ、辞書、点字、音声と漢字の読み方に対するヒントは結構多かった
• 多音字・ヘテロニム判定の海外研究は中国語（CPPデータセット）が主戦場で、g2pWのConditional Weighted Softmaxが1つの到達点
• その後もLLM活用、長尾分布対策、評価指標の精緻化という方向で改良が続いている
• 日本語特化の研究は数が少なく、Sony、NHK技研、Sarashina2.2-TTS、CyberAgentのLLMベンチマークが主な直接的先行事例
• 発想は「候補を絞り込んでから文脈で判定する」「音声を使って読みを検証する」「辞書知識を後付けで注入する」の3つの軸に大別できる
• 辞書の意味知識だけに頼る手法は日本語では既存のルールベースG2Pに劣るという報告もあり、既存G2Pの出力を文脈で補正するアプローチの妥当性を支持する結果が多い