Failures

AzooKeyKanaKanjiConverterの開発上、明確に失敗だったと考えている実装や仕様をまとめます。これらは将来的に修正できるかもしれないし、できないかもしれないです。

このドキュメントの目的はAzooKeyKanaKanjiConverterの判断ミスを明確にして、今後AzooKeyKanaKanjiConverterのフォークを作成する方や、新たな日本語入力ソフトウェアを作ろうとする方に向けて知見を残しておくことです。

コストの設計

辞書データのコストはざっくり言って対数尤度です。azooKeyの開発初期、コストは対数尤度をそのまま使っていました。これを続けてしまったため、普通はIntなどにするのですが、azooKeyのコストはFloat16になっています。

Float16の現実的に不便な点は以下の通りです。

今から作り直すなら、UInt16かUInt8にしています。サンプリングを工夫することで、UInt8でも十分な表現ができる可能性があります。

なお、今後のバージョンアップでこの変更を行う場合、ユーザ側でもマイグレーションが必要になります。

逆にいうと、気合と正しいマイグレーションの実装ができれば今からでも修正可能ではあります。

LOUDS検索を高速化するため、LOUDSのラベルは文字コードそのものではなく、それに対応するCharIDにしています。

しかし、このCharIDをかなり雑に決めたところがあり、なぜか入っている文字やなぜか入っていない文字があります。

この辺りは一度再設計したいのですが、これもやはり上記のマイグレーションが必要になります。

品詞IDは「ipadic+独自拡張」という形になっています。具体的には、かな漢字変換上分離したほうが良い3つの品詞を追加しています。

しかし、ipadicはさまざまな点で難しい面のある品詞体系です（参考）。もし最初から作り直すのであれば、品詞IDはUnidicのものを用いていたのではないかと思います。

上の2つと違って、品詞IDの変更は現実的でないと考えています。というのも、辞書生成モジュールを含む無数のコードでipadicが前提となっており、作業量が膨大になりすぎるからです。もちろんマイグレーションも必要になります。