NIK-Codeを超えて

NIK-Codeは、連想系で覚えやすい、音連想ではなく字形連想なのでリズムに影響を与えない、キーに対応する「アルファベット」が存在するため位置表記に英字配列を頼らなくて良い、、ローマ字入力の併用が上手に組み込まれている、などの特徴がありますが、使わない組み合わせ多数、結果打鍵数がやたら多い、運指最悪っぽい、漢直なのに確定が必要、字形の変遷に合わせて追従していく必要がある、こじつけっぽい字が出てくる、などの欠点もあります。
それでも実験配列、お遊び配列、気分転換配列、とにかく非実用の配列としては面白いよなあ、ぐらいの感触で、しばらく私も忘れ去っていたのですが、正月にみのりさんが記事を書いてくださいましたので、NIK-Codeを超える字形連想の漢直配列を考えてみようかな、という気になりました。単純な奴です私。
ミッション:以下の条件を満たす字形連想の漢直配列の雛形を妄想せよ

  • だいたい4打鍵程度でひとつの文字が出せる
  • 多少の字形の変更にはびくともしない
  • 確定不要
  • 運指もまぁそこそこには考慮する

打鍵数を減らすには、省略を用いる方法と、使わない組み合わせを出さないように、同じキーに大量のかつ同じ箇所には来ることが無い部品を複数割り当てる方法があります。NIK-50では前者を採用しましたが、ヌヌヌで桑のように、最後の木を打つ必要があるかどうかは、画面を見ていないといけないのが若干木に、じゃなくて気にかかっていました。今回は後者で考えてみたいと思います。
字形の変更に耐えるためには、青と、青の下が円の字など、成り立ちが同じものを、同じものとして扱う必要があります。つまり細かい字形はともかく青(成り立ちからすると下が円のほうが正統ですが)で、ひとつのパーツとしてしまわねばなりません。また、単純にそうすると異体字文字コード上に存在してしまっている字を打ち分けられなくなりますので、打ち分けの手段も考えます。
確定不要としたい場合に困るのは、能と熊、態のような、ある字に更に書き足す字が存在するケースです。これは、スペースで確定としてスペースを4打鍵の計算に含めてしまう方法のほか、能の最後のヒだかヒヒだかを、確定するヒと確定しないヒに分けてしまう方法を思いつきました。つまり部品とキーの一対一対応は崩します。後の画を右に続けるか下に続けるかを打ち分けられるなら、同じ部品列で組み立て方が違うというケースも排除できます。せめて同じ部品は同じ指に割り当てるぐらいの努力はしたいです。
運指は、左手で打ち始めて、なるべく交互になるように。あと確定は最下段、が左上から右下へと書く漢字らしくてよいと思います。
案1(ボツ)
最初に考えたのが、このように、字の分割形態に着目して部品を当てはめる場所によってキーの領域を固定するというものです。

□□□□□│11111
□□□□□│11111
□□□□□│11111
平仮名(シフトで片仮名)、記号類

□□□11│□□□□□
□□□□□│□□□□□
□□□□□│□□□□□
かまえかこいたれ

 □□□□□│□□□□□
 222□□│□□□□□
 222□□│□□□□□
 たれ
 圧庵

 □□□□□│22222
 □□□□□│22222
 □□□□□│□□□□□
 かまえ
 闇

 □□□□□│□□□□□
 □□□□□│□□□□□
 □□□□□│22222
 かこい
 或

111□□│□□□□□
□□□□□│□□□□□
□□□□□│□□□□□
冠

 □□□□□│22222
 □□□□□│22222
 □□□□□│□□□□□
 上下二分割
 逢茜葦芦宛安杏

 □□□□□│□□□□□
 22222│□□□□□
 □□□□□│□□□□□
 上下三分割または複雑
 悪哀愛葵粟案

 □□□□□│□□□□□
 □□□□□│□□□□□
 22222│22222
 部首単独
 亜

□□□□□│□□□□□
11111│□□□□□
11111│□□□□□
へん

 □□□□□│□□222
 □□□□□│□□222
 □□□□□│□□□□□
 左右二分割
 唖娃阿挨姶穐握渥旭鯵梓斡扱姐虻飴絢綾鮎袷按暗鞍

 □□□□□│22□□□
 □□□□□│22□□□
 □□□□□│□□□□□
 左右三分割

なにぶん最初ですのではりきってこのような図まで描いたのですが、あっさりボツとなりました。理由は、部首の多さです。NIK-Codeのように画ごとに分解するなら辛いこじつけを混ぜる必要はあっても無理やり大体はカバーできますが、この方式は部首をひとつのキーとしなければならないため、偏だけでも軽く30種類以上は出てくる物量の前に敗れ去りました。図の偏なんて10個しか領域取ってません…。
なお、辞典の部首一覧には、漢字の代表部分とされるいわば部首認定されている部首しか載っていませんが、配列とするには部首認定されていない、例えば旁がその漢字の代表部分とされ偏はなんか変な形である場合も考慮しないといけないため、収録しなければならない部品点数は辞書よりもぐっと増えるのです。
甘すぎました…。
書き取りの宿題で、ひとつの字を一気に完成させるよりも疲れずに済むと、部品ごとに上から下まで書いて手を抜いていた人間と、同一の人間とは思えないぐらい、漢字変換頼みの今の私は甘いです…。
案2
手書き感ということで考え直します。
「ー」を書く労力は、果たして「龍」の1/16なのか?…否!
画数の少ない字はバランスに気を遣う!画数の多い字は汚くても読める!
そして、案1のように、ある画が、部首単独だの囲いだのは鉛筆の先が紙に接触するまでは意識しない!そんなのは書き始めてからえーと次の画に続けるには、あ、バランスおかしくなっちゃった、まぁいいやごまかしちゃえ、えへ☆、と考えるのが漢字の書き方というものです。(テンション変です)
となれば、第1打鍵は…第1画そのものです。
そして、第1画だけであれば、左手15キーに収まらないことも無いでしょう。漢字の第1画になる線の種類なんてそんなに多くありません。いきなり一筆で☆なんて画から書き始める漢字なんて存在しませんから。
とすると、第2打鍵は、第1打鍵を受けて、最初の部首を完成させる打鍵です。
第1打鍵はそれぞれ別の画ですから、第2打鍵は絡みを考えることなく、15×30をフルに使えることになります。つまり最初の部首の種類は450までOKです。二桁では心許ないですが、流石にこれぐらいあれば充分ではないでしょうかね…甘いかな。あと、上の方のキーに冠、左のほうのキーに偏、右のほうのキーにかこいやかまえを集めるようにすれば、感覚的にも自然かも、とか。山冠は山偏のすぐ上にしたいな、とか。そうすると上段が冠、中段が偏、下段が確定として単体の字、が基本形かな。「一」のような一角の字には、第2打鍵に止めを含めることとします。
最初の部首が確定したら、後のバリエーションは、魚偏などの特定の部首を除いてそんなに多くありませんので、第3打鍵でほとんどの字を確定できそうです…ただし同じ部品は同じ指、という原則を考えないならの話。実際には覚えて無くても打てるようにしたいので、第2打鍵で特定する部首と同じ部品を続ける場合は、第2打鍵のキーを使いたいと思います。ああ、そうすると第2打鍵も15×30をフルに使えませんね…。後に同じ部首に続くふたつの部品は同じ位置に置けませんので制約がかかってきます。
残りのストロークとしては…漢字がひとつに絞れたら確定式の省打鍵でてこずらせてくれた、「熱」「勢」のように最後まで行かないと特定できない字をどうするか。この例でいくと、土冠、あし、非確定の土(土ル土の字はUnicodeにしか無いですが)、非確定の丸いや九と点?、ラストに確定の四つ点か確定の力か。うん、NIK-Codeよりも部品粒度が粗いため省略無しでも5〜6打鍵程度に収まりそうじゃないですか。…やはり凄く甘い気がしてきた。
異体字は、なるべく常用とされる字形を中段に置いて、同じ指の上下位置に配置、かな。そうすると、最悪3回試せば出せますから。変に1ストローク増やすよりもスマートっぽいです。
…こんなに理想っぽく配置できるのか本当に?
テーブルはこんな感じ?

亜	よこ	亜
唖	たて	左口	亜
娃	く	左女	圭
阿	フ	左β	可
哀	たて	上亠	上口	化
愛	ひだり	上受	上心	久
挨	よこ	左手	矣
姶	く	左女	合
・
・
・

圭や矣を土土やム矢にばらすかどうかは、読みが甘いかどうかに因るかと…。
えーと、えーと…諸々の条件を考えると、配列そのものはCPU様に最適っぽい配置を探索させるのが一番かな。最適以前に条件を満たす配置は可能なのかも含めて。
続くかどうかは不明。