パソコンで日本語の文章書くのめんどくさいね！〜テキストデータ生成と新配列の実装にまつわるレイヤー問題
天キー7振り返りシリーズ。
今回も大岡さんと色々議論を戦わせたのでその話。
パソコンは文章を「便利に処理する」道具
つまり、
僕らが「字を書く」という、
紙とペンさえあればできることを、
こんだけ総力をかけてやらないといけないんだよね。
まず、これは半分暴論だと思っていて、だって、本来物語を作るのに道具なんか要らないじゃないですか。声で語ればいい。
それでは色々と不便なんで、我々人類は文字を生み出し、文章を記録することを発明した。紙とペン、あるいはタイプライター、そもそも文字だって、文章を記録する道具であって、作る道具ではない。
パソコンだって同じことです。紙とペンでは色々と不便なんで、先人は計算機を応用して、文章を電子的に記録することを発明した。便利だからです。
記録、編集、複製、送信。パソコンはこれを簡便に行うことを可能にし、そのために文章をデジタルデータに翻訳する。それは思考や物語を文章に翻訳することと変わりません。
「パソコンで文章を書く」ということは、そのプロセスをすっ飛ばしていきなりデジタルデータを作成するということ。それは色々と夾雑物があって当たり前で、いきなり文章を作成することにだって夾雑物はあるでしょう。紙の幅とか。
半分というのは、書記官を雇って口述することに比べれば、文字を手書きするほうが遥かに現実的なコストで実現可能ではあって、「創作」という行為を紙の上で行うという解答は、多くの書き手にとって優れたものでありえると思います。ここまで前置き。
「テキストデータ」を作る仕事は誰のものか
ここでいうテキストデータは、自然言語であってリッチテキストでないもの、いわゆるプレーンテキストであり、かつファイルではないとします。
パソコンは計算機であって、文章を処理するための道具ではありません。テキストデータはパソコンが扱う多様なデータの一種に過ぎない。
OSが直にテキストデータを処理すべきという論は、直にベクターデータを処理すべきというのと同じだと考えれば、無理がある主張であるように思われます。
ワープロ専用機はどうかというと、僕は詳しくないのですが、基本的には汎用機と同様のシステムの上で動いているようで、ポメラと似たようなものと考えればよいでしょうか。まあ紙だって、文字を記録するための専用の媒体ではないわけです。
しかしながら、文字入力はパソコンの操作全体に深く関わる機能でもあります。例えばCUIは文字入力によってあらゆる処理を実行するのですし、ファイル名も文字で、ウェブだって文字入力なしではマトモに利用できません。
そこで、パソコン操作のあらゆる局面で行われる文字入力を一括して処理するために、IME（インプットメソッドエディタ）というものが存在します。
パソコンのシステム構成において、「テキストデータ処理を一括して行う」プログラムとはIMEのことです。
ことに日本語を含むいわゆるCJK圏においては、漢字変換という機能が必須になります。これをIMEが一括して行うことによって、各々のアプリケーションは漢字変換を実装せずに済んでいるわけです。
漢字変換を含むIMEの「仕事」を整理すると、キーコードを文字コードに変換することだといえます。ざっくりこのへんの話
とはいえ、これは昨日の天キーで聞いた話なんですけど、QMKにはすでに文字コードを直接送信する機能が実装されているそうですね。
具体的に何をどうしたら文章が書けるのかはわかりませんが、、要するに、IMEの機能をキーボードに組み込むことが可能なわけです。
ディスプレイもつけてそこで漢字変換するようではなんの意味もありませんが、漢直だったら話は別です。漢直限定の話であれば、キーボードファームウェアがテキストデータを生成するシステムは現状でも組めるということになります。
が、漢字変換を利用する場合はやはりIMEが要といえるでしょう。
キーボードファームウェア：キーコードを送信
IME：キーコードを文字コードに変換
OS：文字コードを受け渡し
アプリケーション：文字コードを記録
おおまかにはこういう流れで、キーをたったか叩いた入力が、テキストデータとして記録されることになります。なので、テキストデータの生成はIMEの仕事です。ここまで一般論。
テキストデータ処理につきまとう問題
なので、キー入力をこねて日本語にするのはIMEに任せましょうや、というのが僕の基本的な考えではあるのですが、現実論としてはそうもいかない事情があります。
「文字列」の処理
まず、文字コードの生成は、事実上、文章の生成でもあるということです。
これはライブ変換がわかりやすいと思いますが、大岡さんも書いている通り、ライブ変換は思い通りの文章を書く邪魔になります。キーコードの連続を、意図しない文章として解釈されるからです。
漢字変換は文字列からの推測を交えて行われます。現実にIMEが食っているのはキーコードではなく文字列です。
文字列を扱うということは、キーコードと文字コードのみを扱うのに比べて遥かに複雑な仕事になります。その中には、例えば定型文入力が含まれるでしょう。
一応、単語登録機能を利用して定型文入力を行うことはできますし、実際に多くのユーザーが行っていると思います。しかし、必ずしも変換結果が一意に定まらないという問題がある。
そのため、定型文を入力するためのアプリケーションが存在するわけです。だいたいクリップボードマネージャー系かTextExpander系。txを確実にThanks!に変換することすらIMEにはできません。
編集をどう考えるかという問題もあります。例えば「一行削除する」ということは、行を管理しているのがアプリケーションであるから、IMEにはできません。
アプリケーションでやりゃいいじゃないかというと、まあそうなのですが、キーバインドを一元的に管理できないという問題があります。特に日本語IMEにおいては言語モードごとにキーバインドが異なる事情もあり、混乱が起きやすいといえます。
「かな文字コード」入力
これは要するに、かな入力をどうやって実装するかという問題です。
JISかな入力なら当然IMEだけでできますし、かなとキーのペアを変更することも大抵のIMEでできるはずです。しかし、「１キー１文字」のかな入力は必然的に５０近いキーを必要とし、２６キーで成立する英文入力に比べてタッチタイピングが困難になります。和文タイプライターよりは随分マシでしょうが。
そこで、いわゆる新配列では同時押しを駆使するわけですが、これが基本的にIMEに乗りません。MOZCではできないこともないらしいですが……
なので、多くの新配列が、キー入力をフックする常駐アプリケーションに実装されています。
キーボードのファームウェアに実装することもできるのですが、キーボードはIMEの言語モードを取得できません。
じゃあどうやって日本語モードになっていることを判断するのかというと、IMEモード切替とレイヤー切り替えを同時に行う、要するにかなキーとレイヤートグルをまとめて送信するわけです。
これはこれで色々利点もあるのですが、原理的に言語モードと連動しているわけではなく、パソコンの都合で言語モードが切り替えられる（Macでアプリケーションごとに入力ソースが管理されている場合とか）と普通に事故ります。やはり一元管理はできない。
なので決定版はない
という結論になります。
最も「一元管理」に近いのは、常駐アプリケーションによるエミュレーションでしょう。IMEのキーバインドは固定して、常駐アプリケーションでキーリマップを適宜行う形にすれば、テキスト入力に関するキーバインドは集約できます。
しかし、この手の常駐アプリケーション自体、バグや入力遅延と無縁ではいられない存在です。できればない方がいい。（ハードウェアとして独立しているのもまあ同じ）
何らかの理由で既にAutoHotkeyとか使ってるなら、テキスト入力もやらせちゃっていいと思いますけど。
最も素直なのは、IMEでやれる限りのことはやって、より高度な処理はテキストエディタなどのアプリケーションに任せる構成で、僕は基本的にこれがいいと思っています。日本語入力メソッドに関しては、IMEに実装できる範囲でやりたい。
ただ、漢字変換と直結することの負の面として、変換エンジンを変えたらやり直しという問題もあります。突き詰めると、MOZCとかのオープンソース変換エンジン使ってIME実装しろみたいな話になってしまうのですが、それはもうモノカキの分を超えているというか……
キーボードファームウェアで色々やるのは、僕はあまり筋の良い話とは思いません。日本語を扱う限り、IMEモードを検知できないのがでかすぎる。
ただ、パソコンが共有だとか、仕事用だから変なアプリ入れられないとか、WinとMac行ったり来たりするとか、あとiPadで書いてるとか、個別の事情によっては最適解にもなり得るでしょう。
本当に「執筆」に特化するのであれば、アプリケーションに集約すべきだという立場もあり得ると思います。さっきの行削除の問題にしても、記録としてのテキストデータを持っているのはアプリケーションなのだから、IMEやキーボードから直接干渉はできないわけです。
IMEと独立しているがゆえの問題として、延々解決しないvscodeのキモい変換候補表示とかもあって、こういうのはエディタが漢字変換持ってくれれば起こり得ない。
手書きをAIでテキスト起こしするほうが、実現性高いと思いますけどね。
この記事が気に入ったらサポートをしてみませんか？