Qwerty配列より簡単で効率的なOnik配列を作った話。
タッチタイピングが永遠にできないのでキー配列を変えちゃえ！と思いまして、、
1. 経緯
1-1 Qwerty配列への不信感
ノートパソコンを手に入れてタイピングをするようになってから、Qwerty配列でのタイピングにいらつきを感じていた。
ほとんど使わないのに真ん中に居座る F と J 。
一度も守ったことのない運指。
変換して確定するたびにホームポジションから離れる右手。
そして一生身につかないタッチタイピング。
しまいには標準運指などフル無視で手元をちらちら見ながらタイピングをするようになった。それである程度の速度は出るので満足していた。
しかし３年が経ったころ、ひょんなことから世の中には「キーボードの配列を変えて使用している人達」がいることを知った。そんな人達のブログを読み漁り始めた私は、人生で初めて沼らしい沼にはまってしまった。
1-2 様々な種類のキーボード
調べれば調べるほどキーボードの多様さに圧倒されたが、その根っこに「現状のキーボードまじ使いにくい！」という課題意識があるのは同じだった。現行のキーボードへの具体的な評価は
・よく使うキーがホームポジションに納まっていない
・そもそも打ちやすさを目標にしていない
・姿勢が巻き肩になりやすいので首・肩まわりがきつい
などなど。
それらの課題への解決策として、キーボードの物理配列にアプローチする人と論理配列にアプローチする人に大別できる。
①物理配列へのアプローチ
左右分離型やカラムスタッガードなどがある。物理配列はサリチル酸さんのブログに丁寧にまとまっている。とりあえず「見慣れないキーボードだ！」と思ったらこのアプローチをしていると考えてよい。
（例：Keyball61, Corne Cherry, 7sPro, etc）
②論理配列へのアプローチ
Qwertyという配列に疑問を抱き、各々あたらしい配列を考えている。「くぁｗせｄｒｆｔｇｙふじこｌｐ」が打てない人たち。
（代表的な配列： Dvorak, Colemak, Carpalx, Workman, けいならべ, M式, 大西配列, カタナ式, Eucalyn配列, Tomisuke配列, etc）
このように２種ある。私が今からやろうとしているのは②の論理配列の考案である。
論理配列の考案は既に少なくない人がやっているが、②を考える人はすでに①（見慣れない形状のキーボード）に手を出しており、それに合わせて配列の考案をしていることが多い。それゆえ一般的なキーボード（ロウスタッガード型*）に向けて作られた論理配列はほとんど無いのが現状である。
さらにそこに目を瞑ったとしても、既存の論理配列は「zxcv固定*」や「左右交互打鍵*」といった信頼のおけない哲学に取り憑かれており、納得のいく論理配列が出てこない。
・ロウスタッガード型
row=行、スタッガード=ずれ。 横にずれている形状で、最も一般的なキーボードの形状。
大抵のロウスタッガード型において１列目と２列目は0.25unitしかずれてないが、２列目と３列目は0.5unit（半マス）ずれている。目の錯覚で「すべて均等に斜めにズレている」と思いがちだが、そうではないことに注意したい。ほとんどのキーボードがこのズレ方をしている（例外は日本語配列のHHKBと一部のノーパソ、mint60など）。
・zxcv固定
論理配列を変更する際、ショートカットキーとしてよく使われる左下の zxcv は変えずに残しておこうという考え方。左右交互打鍵で母音を左手に集める配列と相性がよい。そのままがっちり固定せずとも片手操作性を失わなければ良いと思われる。
・左右交互打鍵
タイピングはなるべく左右の手を交互に使った方が効率的だよね、という考え方。特に日本語入力においては母音と子音が交互に連なることが多いので、母音と子音を左右の手で分担させることで交互打鍵を促す論理配列は多い。
個人的には、左右交互打鍵信仰の配列はもれなく「右手で捌く子音多すぎやろ問題」を内包するのであまり好みではない。またアルペジオ打鍵に代表されるように同じ手を連続で使用しても打鍵が速くなる事例が散見されることなどから、「同じ手」より「同じ指」の連続使用さえ避ければタイピングに大きな遅延はないと私は考える。「交互打鍵の有効性はDvorakが実証している」という人はこちらを参考に。
1-3 課題設定
ざっと調べたところ
①一般的なキーボードに合わせて効率化されている
② Enter と BS が押しやすいよう配慮されている
③ zxcv固定や左右交互打鍵に囚われていない
これらすべてを満たす論理配列は見当たらなかった。理想のものがないなら自分で作るしかない。
暇をもて余した学生である内にやってしまおう。
・留意事項
日本語入力そのものの効率化を目的とするなら、そもそもの入力方式を見直す必要がある。かな入力、フリック入力、音声入力、ステノグラフィーなどなど。（「～です。」って毎回打つより「desu。」と出力される💀ボタン作った方が速いとかね。）
今回は一般的なローマ字入力に絞って考える。
2. 論理配列を考える前の準備
2-1 日本語の文章の頻度分析
入力の効率化を考えるにあたって、日本語の文章を集めてローマ字化*し頻度を分析する必要がある。
もとにする文章はQuoraの回答から50,103字（原文）、Twitterの人気ツイートから20,392字（原文）の計７万字*程度。ローマ字化すると約14.5万字。
頻度分析の結果は、高いほうから「 a o i n u t e k s r m h d g y , w z . b - j p c f l x v q 」となった。
zxcv を除いた*各アルファベットの頻度のレベル分けを
１軍 a o i n u t e k s (打鍵割合5.0%以上)
２軍 r m h d (2.5~4.0%)
３軍 g y , w . b (0.8~2.0%)
圏外 - j p f l q (0.3%未満)
として制作に取りかかる。
・ローマ字化
集めた文章を ひらがな、ローマ字変換ツール を用いてひらがな化し、ローマ字への変換はwordの置換を用いて手動で行った。その際「てぇ→the, tele」など複数の打ち方があるものは打鍵の少ない方に揃え、「じ→zi, ji」など同じ打鍵数で複数の打ち方があるものは頻度が偏るように置換した。「ん」に関しては後に母音、な行、や行が続く場合は「ん→nn」、続かない場合は「ん→n」とした。
・計７万字
データの収集は７万字が体力的に限界だった。量は少ないかもしれないが、私は書いている人が少ないと文章に偏りが生じる（文末のクセや言葉選びが影響する）と思っているので、青空文庫からの引用などはせずになるべく色んな人（計300人くらい）の短い文章をSNSから集めた。webスクレイピングが出来ないので丸２日かけてtwitterとquoraからコピペした。もしもこの行為がなにかの法律や規約に引っかかっていたら本当にごめんなさい。許して。なんかあったら怖いので基データの公開はしません。
・zxcvを除いた
当初はzxcv固定に準拠するつもりだったため、zxcvを除いてレベル分けをしている。
2-2 ホームポジションと運指の決定
ここはかなり重要である。いくら論理配列を最適化したからといって、その土台となるホームポジションと運指が崩れれば元も子もない。
まず現状のホームポジションと運指を確認する（濃いオレンジが人差し指のホームポジ）。
ここで気を付けたいのが、キーは均等に斜めにズレている訳ではないという事実である。
よく見てみると１列目と２列目のズレより、２列目と３列目のズレの方が大きい。２列目のキーとキーの真ん中に３列目のキーがくる形だ。
言い換えれば「F→CとF→Vの距離は等しいが、F→RとF→Tの距離は異なる」という形状である。
なのにこの運指はおかしくない？と思い、２,３列目の運指を左右対称にする。
さらにEnterやBSを押しやすくするため右手のホームポジションを右に寄せる。
なかなか良さげ。しかし「人差し指下段」という押しやすい位置を C と V というほとんど使わないザコキーが占領しているのが不服。
色々考えた末、ショトカキーの片手操作性を維持しながら人差し指下段を開放できる以下の配置に落ち着いた。
このホームポジションと運指をベースにして論理配列を考えていく。
3. 論理配列の決定
配列の決定ではタイピングが明確に遅くなる ”同じ指の連続使用” を避けることを意識して進めていく。
＜補足＞
簡単に言えば ～です は desu と打つので、「 d と e 」「 e と s 」「 s と u 」はそれぞれ違う指に担当させた方がいいよね、みたいな事（この場合ｄとｓは同じ担当指でもOK）。
だからアルファベット同士の繋がりやすさを１つ１つ調べる必要があるんだけど、
「子音+子音は基本つながらない」
「母音+母音はそこそこつながる」
「子音でもＮは例外的に他の子音につながるよね」
「拗音化するのに用いるｙｈは他の子音につながるよね」
あたりを押さえておくとラク。
3-1 整理
前述のベースマップの中で色がついており、かつアルファベットのいないマスは２４マス。
そこに割り振るのはアルファベット２６文字ー４(zxcv)と +α(,.-/) の計２６こ。
ここでアルファベットのレベル分けにおいて圏外となった「 - j p f l q 」の中でも、英語ですらめったに使わない q, f の２つを白マスに仮置きする。
これで残り２４つの色つきマスに２４つのキーを割り振ればOK。その際に頻度の高いキーを押しやすい位置に配置したいので、前もって各マスの押しやすさを５段階で評価しておく。人差し指は下段が押しやすく、中指や薬指は上段が押しやすいことに気付く。
3-2 「、。ー /」の配置
私は日本語の文章を打つときに「、。」を押した後にスペースを押して一気に文を変換したい派だ。なのでスペースを押す親指がラクに出てくるように「、。」の下段への配置は避ける。また人差し指は担当マスが６つもあり大変なので、あまり使わないキーも担当させて指の労力を分散したい。ゆえに「、。」は左手人差し指に配置する。右手におくと次の Enter が打ちにくいので左手に配置した。
「ー」は子音にも母音にもつながるキーである。同じ指の連続使用はなるべく回避したいので、ルームメイトの多い人差し指（オレンジ色）には置きたくない。「ー」は頻出レベル圏外であることなどから右手薬指下段が適切だと思われる。
「/?」も圏外であり、あまり使わないので一番押しにくい場所に置いておく。
3-3 １軍 + j の配置
１軍（ a o i n u t e k s ）の９つは頻度がとくに高いため、ホームポジションに配置したい。
しかし指は親指を除いて左右で８本しかないため、どれか２つを同じ指で担当する必要がある。
タイピングが遅くなる "同じ指の連続使用"（以下 : 指連）を避けるため、９つの中で最もつながりにくいペアを探し、同じ指に担当させる必要がある。ゆえに１軍の中でも母音＋母音でつながりにくいペアを探す。
・なぜ母音＋母音？
母音＋子音はつながりやすいので却下。子音＋子音はつながりにくいがここで子音２つを中指（どう考えても中指一択）で担当すると、後々nを人差し指に入れざるを得なくなる。nは例外的に子音母音両方につながる文字なので、指連の観点からルームメイトの多い人差し指への配置は避けたい。よってここでは母音+母音に絞って考えることで、後々人差し指にn以外の子音を配置することが可能になる。
母音５つのペアは１０通り（5C2）あるが、その中でも ue ペアが一番つながりにくい事がわかった。このペアはルームメイトの多い人差し指や動かしにくい薬指・小指ではなく、中指（黄色）に担当させる。
ここで ue ペアを中指の左右どちらに置くかだが、これは「 ”Z” と "ー" のどちらの方が ue ペアとつながりにくいか」を評価することで定まる。調べた結果感覚と違わず "ー" の方がつながりにくかったので、ueペアは右手の中指に割り当てる。
u, e の頻度差は日本語入力ではそんなに無いが、英語入力においては e が圧倒的に頻出なので e をホームポジに据える。
１軍の残りは a o i n t k s の７つ。
先ほどの表をみると ou, ai の連続がとくに多いことがわかる。母音のアルペジオはできるだけ踏みたいので、右手薬指に o を、左手に a, i を担当させる。
左手の a, i をこのように置くのは
①わりと使うctrl+Aが押しやすい
②”じ”を指連を避けつつ”zi”と打てるので、 i と同じ担当指に j を置ける
といったことを考慮した結果である。
残りの n t k s の配置だが、ルームメイトの多い人差し指に n は置けない（nは例外的に子音にもつながり指連を起こす可能性が高いため）。ゆえに人差し指枠は t k s で争ってもらう。
ここで子音が連続する打ち方をする拗音（しゃ、きゅ、ちゅ、etc）について考える。
多くの拗音は y を用いて打つ（sya, kyu, tyu）が、例外的に「しゃ行」は h を用いて拗音化できる（sha, shu）。
ゆえに t k s のうち「 t k 」は y と、「 s 」は h と同じ指担当にならないように注意したい。
以上のことを踏まえると下のように配置が決定する。ここで y は右手側、h は左手側に配置することも決まる。
3-4 ランク圏外と y, h の配置
ランク圏外の方でまだ配置されていないのは p, l の２つのみ。空きマスの中で押しにくいのは右手薬指（緑色）上段と、右手人差し指上段の左側。p, l では l の方が o とつながりにくいので、 l を o の上に置く。
y,h の配置だが、t, kとつながり拗音化する y は右手側、sとつながり拗音化する h は左手側に配置することが決まっている。
y はそこまで頻度が高くないので、右手の中でも押しにくい上段に配置する。
h は２軍でありそこそこ頻出なので、左手の中でも押しやすい左手下段に配置する。
ここでふと、英語入力において頻出の「 th 」ペアは指連なしで打ちたいことに気付く。先ほど h を人差し指担当にしたため、hとつながりやすい t は人差し指範囲から追いやる必要がある。よって t, k の配置も確定する。
3-5 残りの配置
残ったキーは r g b m d w の６つ。その中で y と連なり拗音を作りやすいのは r, g, b である。
ゆえに r g b を左手に、m d y を右手に配置していく。
２軍である r m d は押しやすい人差し指下段に配置する。この操作には「人差し指は担当が６つもあって大変なので、頻度の高いキーを中段～下段に集めることで労力を軽減したい」という思惑もある。
m, d の配置は逆でも良いが、こうすると「desu」が楽しく打てるのでこの配置にした。
4. 最終的なキー配列
白枠を調整し、最終的なキー配列は ↓ となった。
onik（おにく）配列という名前にする。
なお、じ は zi 、しゃ行は sh 、ちゃ行は ty 、じゃ行は J 、小文字のあ行の ぁ～ぇ は L 、ぉ は x を用いることを想定。
ctrl+A を含めたショートカットキーの片手操作性は維持しつつ、指連を頑張って避けたのでかなり打ちやすい配列になったのではないかと思う。また左右交互打鍵信仰にありがちな「右手で捌く子音多すぎやろ問題」を回避したことについても満足している。
さらに英語入力において頻度の高い文字のペア top30 （ページ下部のpairs.jsonの部分）についても、すべての場合において指連を回避している。また英語の単体頻度 top10 である e t a o i n s h r d に関しては、そのすべてが打ちやすい人差し指下段かホームポジションにおさまっている。
ゆえに英語もそこそこ打ちやすい配列であると言えよう。
5. 比較
onik 配列は他の自作キー配列とホームポジションや運指が異なるため、Keyboard Layout Analyzer (KLA)をはじめとしたメジャーな尺度では評価できない*。だからといって独自の評価指標を作っても「自分のキー配列が高いスコアを出すように優遇している」感が拭いきれない。
なのでキー配置の過程におけるロジックの納得度でもって評価してもらえると嬉しい。
・メジャーな尺度では評価できない
厳密には評価できるがしたくないだけである。というのも自作キー配列で主流な KLA の評価は「どれだけ左右の手で交互打鍵をしたか」というナンセンスな指標により総合スコアの１/３が決まる。これでは母音を左手に集めた人が勝つ出来レースに相違ない。入力速度に直結するのは「同じ指の連続使用をどれだけ回避したか」である。同じ手の連続などさほど重要ではない。さらにスコアのもう１/３を決める "distance" はホームポジションからの距離を測るのみであり、たとえば「人差し指で下段を押すことは容易だが、薬指で下段を押すのは難しい」といった指による移動コストの違いを無視している。これだけずさんな分析でもスコアを ばばんっ と出されると信じたくなるのが私含め人間の弱さだよね。
とはいえ何もないと寂しいので、いくつかの論理配列＋onik配列の Heat Map を置いておく（私が集めた文字データで作成）。
onik配列に関しては、特に人差し指のとこ（khr, smd）の頻度の分散がお気に入り。タイピングの女王と言われるmiriさんの運指からもわかるように、人間って人差し指はものすごい動くけど、薬指や小指はあまり動かない。Enter押すときも小指じゃなくて手首を動かしてたりする。なので人差し指に活躍してもらう配列を作ろうとしたが、人差し指が上段から下段までせわしなく動くようでは効率がいい配列とは言えない。ゆえに人差し指に関しては中段と下段に頻度の高いキーを密集させる。そのような哲学が一目で感じられる Heat Map になったと思う。なかなかに美しい。
そして指連の回数をまとめた表も置いておく。
onik 7040
大西 7249
Colemak 8330
Workman 8337
Tomisuke 8644
Eucalyn 9945
CarpalxQ 11959
Dvorak 15096
AZERTY 17263
QWERTY 17277
一応１位だが２位の大西配列との差は誤差の範囲。
左右交互打鍵と覚えやすさ（清濁隣接）を重視するなら大西配列。
右手でそんなに子音捌き切れないよ！という人はonik配列。という感じかな。
ただ、
①指による移動コストの違い
②ロウスタッガード型に合わせたホームポジションと運指
この２つに配慮しているのはonik配列だけかな、と思う。
一応「 KLA を使って自分で配列の評価をしてみたい」という人のために配列データを置いておく。
この配列で年内にコスメティック田中越え（e-typing 腕試し R410）したい。
6. 経過
23/06/21
onik配列完成
23/08/12
qwertyとonikわりと使い分けできる。頭の中でごっちゃにならない。
23/10/23
経験則的にbrは近い方がいい事がわかったので b と , を入れ替える。
23/10/27
なぜかもう一つ配列を作ってしまった。やばい。
この記事が気に入ったらサポートをしてみませんか？