orthography2ipa は、純粋なデータで構成された Python パッケージです。宣言的な JSON、薄くプラグ可能なロジックからなり、訓練済みの重みは一切ありません。綴りを IPA に対応づけ、それらの音素が文脈の中でどのように表出するかをモデル化します。20以上の語族にわたって、820の言語をカバーする909の言語仕様（加えて分類専用の系統ノード89個）を同梱しています。インストールし、データを読み、データを fork してください。checkpoint の中に隠されているものは何もありません。
これは下流のすべてを支える音韻論の層です。それが生成する候補ラティスは、アラビア語 TTS フロントエンドの arbtok、ポルトガル語の TugaPhone と silabificador のスタック（ポルトガル語の音節と音素のための古典的NLP を参照）、バランケーニョ語の音素化器、ミランダ語の音素化器、そして ジャガイモでも動くTTS の音素的基盤によって消費されます。
1つではなく2つのマップ
決定的な区別があります。グラフェムマップは、ある綴りがどの音素を表し得るかを教えてくれます。異音マップは、ある音素が文脈の中でどのように表出するかを教えてくれます。この2つを混同することが、G2P システムにおける最も一般的な失敗モードです。
import orthography2ipa
en = orthography2ipa.get("en-GB")
en.graphemes["th"] # ['θ', 'ð'] — one spelling, two possible phonemes
en.allophones["t"] # ['t', 'tʰ', 'ʔ', 'ɾ'] — one phoneme, four realisations英語の ⟨th⟩ は /θ/ と /ð/ の間で本当に曖昧です。これは綴りから音素への事実です。英語の /t/ は、それがどこに位置するかに応じて、単純な閉鎖音、有気閉鎖音、声門閉鎖音、あるいは弾き音として現れます。これは音素から表出への事実です。この2つを分けておくことで、転写のためにはテキスト → 音素候補へ、発音モデリングのためには音素 → 表面的表出へと進むことができ、一方が他方を汚染することがありません。TTS にとってそれは、信じられるアクセントとロボット的なアクセントの違いです。ASR にとってそれは、人々が実際に話す内容に一致する語彙集と、辞書に一致する語彙集との違いです。
各言語が持つもの
各言語は凍結された LanguageSpec データクラスであり、音素のリストよりもはるかに多くのものを持っています。グラフェム（二重字や三重字を含む）、異音マップ、文脈依存の上書きのための位置的グラフェム（語頭、母音間、/i/ の前）、重み付きで複数の祖先を持つ系統、語をまたぐサンディ規則、任意の声調目録、そして来歴です。来歴には、stub → skeleton → research → production と進む QualityTier、ScriptType（アルファベット、アブジャド、アブギダ、…）、そしてページ指定付きの書誌的な出典が含まれます。
包含のルールは厳格であり、はっきりと述べる価値があります。公式な正書法と文書化された文法に裏付けられた対応づけのみが採用されます。恣意的な部分文字列規則は除外されます。 ポルトガル語の ⟨lh⟩、ドイツ語の ⟨sch⟩、英語の ⟨th⟩ が含まれているのは、それらが標準的な正書法上の単位だからです。便利ではあるが捏造された発見的手法は含まれません。ある仕様がグラフェムを宣言していながら明示的な異音マップを持たない場合、基準となる恒等マップが導出されます。すべての音素は少なくともそれ自身の表面的表出となるため、何も静かに消えることはありません。
地域的な変種は、親に対するフラグではなく、それぞれ独自の仕様を持ちます。ブラジルのポルトガル語とヨーロッパのポルトガル語は体系的に分岐するため、系統によって結びつけられた別個の LanguageSpec オブジェクトです。
pt_br = orthography2ipa.get("pt-BR")
pt_br.graphemes["t"] # ['t', 't͡ʃ'] — palatalisation before /i/方言ツリーが保守可能であり続けるのは、JSON ファイルが graphemes_base / allophones_base の継承をサポートするからです。変種は親と異なる点だけを宣言します。系統は重み付きで複数の祖先を持ちます — 親、基層、上層、傍層 — これは、純粋な子孫ではなく接触の産物である言語をモデル化する誠実な方法です。
幅広さだけでなく、地に足のついた深さ
820という数字は幅広さです。しかし作業が注がれているのは深さです。仕様は、方言学の文献が踏み込むところまで方言ごとに踏み込み、そのそれぞれが、音素表からパターンマッチされたのではなく、ページ指定付きでその文献に引用づけられています。
イベリアのカバレッジが最も明快な例です。半島の言語群のための 100以上の仕様があります。スペインのあらゆるロマンス語 — カスティーリャ語、カタルーニャ語/バレンシア語、ガリシア語（RAG と再統合主義の両方の規範）、アストゥリアス語、アラゴン語とその谷ごとの変種（Ansotano、Chistabín、Benasqués…）、エストレマドゥーラ語 — に加えて、バスク語、イベロ・ロマンス系のクレオール語、そしてほとんどのリソースが完全に飛ばしている歴史的な層、すなわち アンダルス・アラビア語 と モサラベ語です。アラビア語側は 34の方言（Najdi や Hejazi からレバント、マグレブ、半島の変種まで）を、ルゾフォニア側は 46のポルトガル語およびポルトガルの言語の方言を、Rionorese、Guadramilese、そしてミランダ語の下位方言に至るまで抱えています。
私たちの知る限り、これらのうちのいくつかは、その変種のために publish された 史上初の機械可読な音韻論です — つまり、方言学の文献の中で散文としてのみ記述された音素目録ではなく、プログラムが照会できる構造化されスキーマ検証された書記素/異音仕様である、という意味です — Rionorese と Guadramilese がそれにあたります。下流の作業は、バランケーニョ語とミランダ語のための史上初の IPA 辞書を同梱しています。
単一の推測ではなく、候補ラティス
綴りはきれいな分割問題ではないため、旗艦となるアーキテクチャは 候補ラティスです。PhonetokTokenizer は maximal-munch グラフェムトークナイゼーションを行い — 最も長く一致する正書法上の単位を貪欲に優先し — 仕様のグラフェムテーブルの上で、脆い単一の出力ではなく、位置ごとに順位付けされた IPA 候補のラティスを生成します。
from orthography2ipa.phonetok import PhonetokTokenizer
tok = PhonetokTokenizer(orthography2ipa.get("en-GB"))
tok.ipa_best("through") # 'θɹɔː'
for path in tok.ipa_beam("through", beam_width=8):
print(path.ipa, path.score) # θɹɔː 0.0, ðɹɔː 1.0, θɹoʊ 1.0, …このラティスは、下流のファミリー全体が構築の土台とする契約です。言語固有のエンジンは共有ラティスを消費し、静的なテーブルでは表現できない音韻論だけを追加することで、すべての消費者を同じ地に足のついたコアの上に保ちます。
- arbtok は、ラティスの上にアラビア語 TTS の音韻論を構築し、太陽文字の同化、hamzat al-waṣl の脱落、重子音化、合字の処理を追加します — そして、無母音符号の方言テキストに欠けている短母音を復元する新規の rawi-ラティス融合 を追加します。これは、自由な生成器を信頼するのではなく、要求された方言の許容に基づいてアンサンブルの文字ごとの分布をスコアリングします。
- TugaPhone、mwl_phonemizer（ミランダ語）、および g2p_barranquenho は、いずれもそのルゾフォニア変種のために同じ lattice-core を消費します。
言語間の距離を測定する
データが重みに焼き込まれるのではなく構造化されているため、言語を直接比較できます。距離の指標は目録、グラフェム、異音、系統の各次元にわたり、さらに別個の文字体系距離のファミリーも備えています。
from orthography2ipa.distance import phonological_distance
d = phonological_distance(orthography2ipa.get("pt-BR"), orthography2ipa.get("pt-PT"))
d.combined # 0.0515 — near-identical
d.inventory.feature_mean # phoneme-inventory distance
d.grapheme.mean_ipa_distance # grapheme-mapping divergence
d.allophone_sim # allophone-overlap similarity特徴ベクトルも公開されているため、2つのポルトガル語標準のようなほぼ同一のペアは 0.0515 に落ち着き、一方で本当に距離のあるペアははっきりと分離します。これは転移学習の判断、低リソース言語のブートストラップ、方言計量学のいずれにも役立ちます。
データが良質であるとどうして分かるのか
信頼できる G2P の「ゴールド」はほとんど存在しません。公開データセットの大半は、ある音素化器自身の出力を参照として再利用したものであり、それに対する誤り率の低さは「正しい」ではなく「そのツールと一致する」を意味します。私たちはこの点を明示し、単一の見栄えの良い数字を報告するのではなく、それを踏まえた検証方法論を構築しました。
私たちが最も重視する変種については、ゴールドはスクレイピングされたものではなく、作成されたものです。方言ごとのエンジン固定の文セットを、盲検ペアで判定し、ページ指定された文献に照らして裁定し、修正クラスを通じてエンジンのフィードバックループへ折り返します — エンジンの出力と修正された形との不一致は、実際の仕様バグへの手がかりです。エンジン固定の TTS ゴールドと一次資料の実証を合わせて、数千行の検証済みデータがあります。この枠組みは来歴について意図的に誠実です。それしか存在しない場合には合成および文献裁定によるものであり、存在する場合には本物の人間によるゴールドです — ネイティブ話者によるミランダ語の mirandese_g2p セット、ページ指定された一次資料の実証、そしてネイティブによる寄稿です。精度の主張は人間によるゴールドに対してのみ行われます。エンジン自身の草稿に対する完璧なスコアは、何の意味も持たないでしょう。
これらの数字は、方向性を示すものとして読み、常にその出典に引用づけられています（docs/scoreboard.md、docs/benchmarks.md、および下流リポジトリのベンチマーク文書）。
- アラビア語の方言、無母音符号の素の入力 — 困難で、デプロイの現実に即したケースです。arbtok の素の入力による TTS ゴールド（33方言）において、方言の許容の下での rawi-ラティス融合は 平均 PER 0.189 に達し、同じアンサンブルを自由な生成器として動かした場合（0.193）を上回ります。その差は、MSA から最も分岐する方言に集中しています。ほとんどの方言において、arbtok は素の入力で espeak-ng を上回ります。MSA そのものにおいては、MSA 向けに調整された espeak が依然として勝ちます（espeak 0.176 対 arbtok 0.245）。
- アラビア語の方言、母音符号付きの入力 — 符号が存在する場合、arbtok の PER は方言ごとに 0.01–0.08 に位置し、espeak の単一の MSA ボイスを大きく下回ります（例: Najdi 0.009 対 espeak 0.221、Egyptian 0.027 対 espeak 0.287）。espeak には方言ボイスがないため、これは正直に言えばリンゴとオレンジの比較です — しかし、その差こそが要点です。
- ポルトガル語、専門家の人間によるゴールドに対して — リスボンのヨーロッパ・ポルトガル語は、ページ指定された一次資料において PER 0.029（88% の完全一致）に達し、ネイティブ話者によるミランダ語のゴールドは 0.146 です。
これらのいずれもが、リーダーボードのトロフィーではなく、ブートストラップ信頼区間と相互参照されたデータの現状の特性です。区間が広い、あるいはサンプルが小さい場合には、スコアボードがそう述べます。
CLI
上記のすべては Python を書かずに到達できます。orthography2ipa コンソールスクリプトには list、info、transcribe、distance が付属し、各サブコマンドはパイプラインへ流すための --json を受け付けます。
orthography2ipa list --family Romance
orthography2ipa info pt-BR --graphemes
orthography2ipa transcribe en-GB "through" --beam 8
orthography2ipa distance es-ES it-IT --jsonなぜ純粋なデータが重要なのか
仕様セット全体がスキーマ検証済みです。pydantic 風の凍結されたデータクラスが整合性テストスイートによって走査され、SCHEMA.md がその形を文書化しています。静的なテーブルでは規則を本当に表現できない場合には、言語固有のロジックがデータの周囲にプラグインされます。音節分割器はエントリーポイントグループを通じて登録され、より重いエンジンは共有ラティスの上に下流で構築されます。
ユーザーの言語がどう聞こえるかを決める不透明なモデルは存在しません。対応づけは監査可能であり、出典はページまで引用されており、言語を追加することは検証済みの JSON ファイルを1つ書くことです — docs/adding_a_language.md と getting-started ガイド から始めてください。TTS、ASR、あるいは音声学的 NLP を構築していて、自らの音韻論をブラックボックスに外注することを拒む人 — そしてそれを自分自身のハードウェア上で動かしたい人 — にとって、それがこの取り組みの要点です。これは Apache 2.0 であり、あなたが検査し、拡張し、セルフホストするためのものです。