ハードウェア選定編、起動記に続く、パゴスの開発記録です。今回は、日本語変換をめぐる実験の話をまとめます。
「見えないと編集にならないのでは」という疑問
パゴスは、電源投入から執筆、送信までを閉じた空間で完結させる設計にしています。漢字変換は、Ctrl+Gを押した瞬間に文章全体をAIにまとめて投げる、という一括変換方式です。これはこれで割り切った設計のつもりでした。
ですが、実際に文章を書いてみると、「変換されるまで自分が何を書いたか正確には分からない」という感覚がずっと引っかかっていました。だったら、mozcのような普通のライブ変換IME(打った側から順番に変換候補が出てくる、あれ)を使えばいいのでは、と考えるのは自然な流れでした。
ただ、これは一度きちんと確かめる必要がありました。電子ペーパーは全画面書き換え・低速という制約があり、最初にSKK辞書方式(候補をメニューから選ぶやり方)を諦めたのも同じ理由だったからです。同じ壁にもう一度ぶつかるだけかもしれないと分かっていながら、それでも一度手を動かして確認したいと思いました。
結論から言うと、案の定同じ壁にぶつかりました。fcitx5-mozcの候補選択UIはX11(GTK)の描画に乗っていて、電子ペーパー用の自作の描画の仕組みとはまったくの別物です。候補選択という操作自体も、低速なe-paperには根本的に不向きでした。意外性のない結果ではありましたが、「本当に無理なのか」を実際に動かして確かめられたのは大きな収穫でした。頭の中だけで「たぶん無理だろう」と判断するのと、実際にHDMIモニターとキーボードを繋いで動かしてみて「やっぱり無理だった」と確認するのとでは、納得感がまったく違います。
どこまで時間をかけるべきか、という迷い
一番悩んだのは、この実験にどこまで時間をかけるべきか、という判断でした。画面が真っ暗になる、日本語入力がまったく反応しない、といった一つ一つのトラブルには必ず理由があり、一つずつ潰していけば前進はします。ですが、「これは本当に最終的に使う技術なのか」という問いが常について回っていました。
途中で「HDMI出力ってそこまで重要なんだっけ」と自問した瞬間がありました。この装置は最終的にモニターを使わない設計なので、テレビとの相性問題を潰すこと自体には価値がありません。むしろ「見ながら変換できると編集しやすい」という体験の答えは、普段のMacやiPhoneでのライブ変換入力の感覚からもう分かっているはずでした。
それでも最後まで実験を続けたのは、単に「見ながら編集できるかどうか」だけでなく、「mozcという変換エンジン自体がこのRaspberry Pi上で本当に動くのか」を確かめたかったからです。GUIというUIの形は捨てても、エンジンだけ持ち帰れるかもしれない、という直感がありました。
次々に起きたつまずき
技術的なつまずきは数え切れないほどありました。
- テレビの画面が真っ暗になる問題：
vc4-kms-v3d(フルKMS)という新しめのグラフィックドライバとテレビの相性問題でした。vc4-fkms-v3d(旧来の互換性重視モード)に切り替えたら直りました。コンソールの文字は正常に映るのに、Xに切り替わった瞬間だけ真っ暗になる、という症状で原因調査が長引きました。 - キーボードレイアウトの不一致：物理キーボードの製品名に「JP」と書いてあるのに、OS側の設定は「us」のままでした。
~や-が別の記号に化けるという症状で気づきました。 - fcitx5がまったく日本語に変換してくれない問題：原因は拍子抜けするほど単純でした。
.xinitrcの中でsource ~/.xprofileと書いていたのですが、/bin/sh(Debianではdash)はsourceをサポートしていません。エラーは出るもののスクリプト全体は止まらずに次の行へ進んでしまうため、.xprofile(fcitx5の起動を含む)だけが静かにスキップされ続けていました。POSIX互換の.に直したら一発で直りました。 - openboxの
chainQuitKeyという予約キーが、たまたま自分で割り当てたCtrl+Gと衝突していた：標準の設定ファイルの中に埋もれている一行に気づくまで、キーバインド自体が無視されているとしか思えませんでした。
深夜の検証、そしてGPIO競合の落とし穴
そんな最中、実機に触れない状態でmozcのローカル変換を実装する必要に迫られました。実機なしでコードだけ書いて「たぶん動くはず」で終わらせるのは無責任だと感じたので、Dockerで実機とまったく同じDebian trixie環境を作り、emacs-mozc-binを入れて、実際にプロトコルを叩いて検証することにしました。
ここでも予想外のつまずきがいくつかありました。mozc_serverはroot権限では起動を拒否します(セキュリティ上の設計)。~/.configディレクトリが存在しないと初期化に失敗します。ひらがなを1文字ずつ送って変換を試したところ、最初はコマンド名を誤ってダブルクオートで囲んでいたせいで応答が返ってこず、次は起動直後に流れてくる挨拶メッセージ(バージョン情報)をコマンドへの応答と誤読していました。一つずつ潰していったら、最終的に「きょうはいいてんきですね」が「今日はいい天気ですね」に正しく変換される瞬間が来ました。
翌朝、実機で試してもらったところ、同じ入力で同じ結果が返ってきました。Dockerでの検証がそのまま実機でも通用した、という手応えは、久しぶりに気持ちのいいものでした。
最後にもう一つ、地味だけれど厄介なつまずきがありました。Ctrl+Dで電子ペーパーが更新されない、という報告があり、配線を疑って電子ペーパー単体のベンダーテストまで走らせました。結局のところ原因はハードウェアではなく、自動起動していた別のzen_editor.pyプロセスがGPIOを掴んだままになっていた、ただの多重起動でした。テスト用に手動でSSHから起動したプロセスと、tty1で自動起動していたプロセスが、同じGPIOピンを取り合っていたわけです。
技術的に面白かったところ
技術的に一番面白かったのは、mozc_emacs_helperという、本来はEmacsの日本語入力のために作られたプロセスを、GUIもEmacsも使わずに直接叩いたことでした。これはS式(Lispの構文)で標準入出力越しに会話するプロトコルで、(1 CreateSession)のようなコマンドを送ると(emacs-session-id . 1)のような応答が返ってきます。
ひらがなをそのまま1文字ずつSendKeyで送り、spaceで変換、enterで確定すると、変換候補の先頭が自動的に確定されます。ローマ字を経由する必要はなく、ひらがな入力をそのまま受け付けてくれることも、実際に動かして初めて分かりました(公開されている一次情報だけでは確信が持てなかった部分です)。
これによって、Gemini APIのようにクラウドに文章を送る必要がなく、ネットワーク接続もAPIキーも要らない、完全にローカルで完結する漢字変換が実現しました。決定論的な変換エンジンなので、大規模言語モデル特有のハルシネーション(内容を勝手に書き換えてしまう現象)のリスクも原理的にありません。
Ctrl+Gを押した時の流れは、AIバックエンドがGeminiからmozcのローカルエンジンに変わっただけで、ユーザーから見た操作感は何一つ変わっていません。UIの言葉づかいだけ「AI変換」から「変換」に直しました。中身が変わっても、使う人の手癖は変えたくありませんでした。
—
まだ本当に電子ペーパー上で実用に耐えるかは、これから確かめていきます。ロジックとしては通しで動くことを確認できたので、あとは実際に日々の執筆にどれだけ馴染むか、という段階に来ています。
コメント