Kristopher Baker iOSを土台に · プロダクトシステム · AI支援ワークフロー
← Aoede

shipped · 2026.07.02 · 約3分

二種類の間違ったふりがな

ふりがなは、読み方がわかるようにAoedeが漢字の上に振る小さなかなのことですが、私のふりがなは目に見える形で間違っていました。厄介なのは、その「間違い」が実はまったく別の二つの問題だったことで、両者を区別できるようになるまで、どちらも直せませんでした。そこでリーダーに手を入れる前に、FuriganaQAという検証ハーネスを作りました。Aoedeの本物のふりがなパイプラインを青空文庫の作品コーパスに対して走らせ、すべての読みを、作者自身が付けたルビと突き合わせます。食い違いは二つの山のどちらかに振り分けられます。私が直すべきバグか、どんな解析器にも当てられない読みか。

一つ目の山はジェネレーターです。Aoedeは漢字をOpenJTalkで読んでいて、避けられるはずの間違いをしていました。長音が、表記どおりではなく音のとおりに出ていたのです(方がほうではなくほおと出る)。読みを音声用のフィールドから取っていたためで、正書法どおりの読みに切り替えると、話す音声はそのままに、表記だけが直りました。位置もずれていました。木の葉のような並びで、こを木に、はを葉に振る代わりに、かなを語全体の上にひとかたまりで置いていたのです。いまは既定でモノルビ、それぞれの読みをその漢字の上に中央寄せし、実際にぶつかるときだけ二つの読みを一つのグループにまとめます。さらに辞書の層を足しました。JmdictFuriganaデータセットが漢字ごとの配置と、あり得ない読みを捕まえてJMdictから修復するバリデーターを与えてくれるので、這入るははいる、行衛はゆくえに解決します。

二つ目の山が面白いところで、こちらはどれだけ工夫しても直せません。日本語には、作者がただそう決めた読みが溢れています。地球にほしと振って「地球」を表したり、硝子をがらすと読ませたり、本気をマジと読ませたり。どんな解析器もそれらを生み出せません。文字ではなく、作者の意図の中にあるからです。唯一の正しい出どころは作者なので、Aoedeはいま、本に同梱されたルビを保存します。青空文庫の《》記法やEPUBの<ruby>タグから直接ふりがなを読み取り、OpenJTalkが推測するどんな読みよりも優先して漢字の上に描き、そして最終フェーズでは、それを話します。本気《マジ》は紙面では本気と見せて、声ではマジと言い、硝子《がらす》はがらすと発音されます。

このアップデートで気に入っているのは、QAハーネスが単に直しを測っただけでなく、やるべき仕事そのものを定義したことです。その役割は、「ジェネレーターが当てるべきだった」ものと「ジェネレーターには知りようがない、作者が意図したもの」との線を引くことで、その線こそが上の二つの山です。いまAoedeで語の上に見える読みは、作者がそう言ったときは作者から、決定的な答えがあるときは辞書から、そして他の誰にもより良い答えがないときにだけOpenJTalkから来ています。