夏まっ盛りというところですが、いかがお過しでしょうか。暑いのは中々避けようがないですね。

何回かに分けて、現在自分で利様している日本語入力方式について書いていこうと思います。今回はその1ということで、概要からとなります。

Kanzenではないkanzen - chokan

https://github.com/derui/chokan

repositoryとしては上記となっています。まず名前としては、 chotto-kanzen ということで命名しています。ちょっとだけ、なのは、元々のkanzenで実装されていた機能をカバーしきっていないためです。

Kanzenとは

https://www.nue.org/nue/tao/kanzen/wdj.html

Kanzenは、漢字変換システムの一種です。Kanzen自体の特徴としては、

というものがあります。文節区切りのコントロールをユーザーが行う点などは、SKKと類似していると感じる方もいると思いますが、これは偶然ではなく、SKKの元々の開発者がKanzenを参考にしたと書かれています。

https://ja.wikipedia.org/wiki/SKK

再実装を試みたのか

元々はSKKを使っていたのですが、ふとしたことでかな入力に戻したのです。そのとき改めて、、SKKの課題である QWERTYに仕様が最適化されすぎていて、かな入力などでは使いずらい というのが利用上のネックとなりました。

chokanでも完全に対策できているというわけではないのですが。

なにかしら方策がないかな、と探していたところ、SKKが参考にしたというKanzenを発見し、 新JISに対応できている ということから、実装してみようとなった次第です。

chokanのアーキテクチャ

オリジナルのKanzenは、1986年（！）に発表されていることもあり、そもそもEmacsですらなく、TAO/ELISというシステムで動作していたEmacsライクなeditorであるZenで動作するように開発されていました。

元々zenというeditorには、構文解析のフロントエンドが実装されていたようですが、仕組みとしては、ZenからELISのマイクロプログラムを呼び出す、という方式だったようです。今でいうと外部プロセスの起動か、内部の関数呼び出しに相当するというところでしょうか。 chokanでも同様にemacs上ですべて実装することもできましたが、ロジックの再利用性を一定考慮して、次のようにしています。

frontend
Emacs
  • これはシンプルに実装コストとの兼ね合いからEmacsだけ実装したためです
backend
Rust
network protocol
Websocket
front-to-back interface
JSON-RPC

Rustで構築されたJSON-RPCサーバーとフロントエンドが、Websocketで通信する、というモデルにしています。JSON-RPCを選択したのは、EmacsがLSP対応(Eglotによる)を公式に行ったことにより、emacsからのWebsocket/JSON-RPC実行が非常にやりやすくなったためです。

当初はprotobufなどでなんとか生成したり・・・とか考えてましたが、Emacs向けの実装とかを考えると、もっとシンブルでいいじゃん、ということに気付いたので

辞書の管理

chokanでは 品詞解析が必要 ということから、当然辞書が必要になります。辞書の形式としてはSKKを参考にしつつ、品詞を設定することが出来るようにしています。

はがゆ	歯痒	/形容詞/
じゅん	殉	/ザ行上一/

<read><tab><word><tab>/品詞(/...)/ となっています。同一の読み、単語で複数の品詞、というのも存在しうるので、それを表現できるようになっています。

辞書は大きく 標準 付属 ユーザー の3種類があり、用途が異なります。

性能について

日本語入力ということで、当然ですが既存のシステムと比較されるのは当然ではあると思います。が、そもそもの思想が異なるため、同一条件における比較は難しいので、現状の主観での評価を書いておきます。

実行速度

かな漢字変換では、当然ですが変換にかかる時間がどれだけ短いか？というのも体験として重要です。chokanは、Rustで実装した/解析が限定されている、ということもあり、 候補が少ない場合は1～2ms、多い場合でも3～6ms という時間で候補を出すことができています。

Emacs側の実装でも、そこまで複雑なことをしないようにしているので、mozc + overlayのようなチラつきなどはほぼ発生せず、快適に利用できるようにできています。

変換精度

chokanは第一文節のみを考慮して変換しているため、SKKというよりはGoogle日本語入力などと感覚は似ています。しかし、区切りの指定があるものの、SKKと違って変換の区切りを指定しているというわけではないため、SKKよりはShiftなりの頻度は低くできます。

ただ、品詞まで考慮しているものの、どうしても現代的なATOK/Google日本語入力などによる精度を出すことは難しいです。特に1文字単語などにおける煩雑さは、SKKと類似しています。

現代の日本語入力は、ほぼほぼ統計的なやりかたになっていて、下手に品詞解析するよりもそっちの方が性能が出るとのことです。莫大なデータが必要になるので、個人では大分難しいですね。

next

chokanの概要について紹介しました。次は利用しているアルゴリズムなどを書いていこうと思います。