新配列と新ローマ字を考える話 - Effive配列とEffiveRoman（後）
前回の記事ではEffive配列がどのようにしてできたのかを取り上げた（ぜひそちらも併せて読んでね）。
続いて、具体的な導入方法と使用方法について紹介する。と、そのまえに何点か…
成長記録
ここまでブログを読んで、疑問に思いそうなこと。
- 会社や学校のパソコンではEffive配列を使えないけど、Effive配列に慣れたら、共用のPC使用時に必要なQWERTYで打つ能力が衰えてしまうのでは？
大丈夫、心配ご無用。
e-typingでの実績
有名なタイピング練習サイト「e-typing」にて日々QWERTYとEffiveで一度ずつ記録をとっている。Effiveでの記録が日々ぐんぐん伸びていくのに対し、QWERTYには何の影響もなかった。むしろそっちも日々記録を取るにつれて徐々に成長した。
ショートカットキーの扱い
ここまでブログを読んで、疑問に思いそうなことその2。
- QWERTYはCtrlキーとのショートカットが使いやすいのに…あれEffiveになったらバラバラになっちゃわない？
Ctrlキー（Windows）および⌘キー（Mac）利用時について
これらは全てQWERTYにおいて左下に位置しているからこそ便利なのであって、Effiveになった途端ZXCVやASDF…はバラバラになってしまう…
新しい配列での操作は、慣れ以前にその不便さを拭い切れない。
ここで例えば、Ctrl + Z操作において、大事なのはその左下端という「立地の良さ」にあり、その操作に「Z」を使うことに意味やこだわりはないと思われる。既にすっかり覚えて無意識に操作している方は、なおさらそう思うことだろう。文字ではなく、位置で覚えているだから。
こうしたショートカットキーの便利さは残したかったため、Tomisuke配列等を参考にし、「Ctrlキーを押している間はQWERTY配列に戻る」という機能をつけることで対処した。
この機能が不要だという人が一定数でてき次第、この機能を除いたものも配布するつもりではある（その場合のリリースは早くても来春になるかもしれない）。
動画サイトで活躍するJ,K,L
Ctrlキーなど何もない文字だけのショートカットキーは無論、新配列で操作せねばならない。
とりわけ、YouTubeやニコニコ動画でのJ（10秒戻し）・K（再生・一時停止）・L（10秒送り）は、個人的ではあるが割と使う。これが新配列においてバラバラだと操作しづらいので、どうにかして隣り合うように頑張った。右手小指でK、手前にズラしてJ、奥にズラしてLといった具合で押せるので、これは大変便利である。
Effive配列を実装する
お待たせして申し訳無かった。以下、Effive配列及びEffiveRomanの導入方法
Windowsユーザー
- AutoHotKeyをインストール
- GoogleDriveからEffive_6.0.ahkをダウンロード
- エクスプローラでダウンロードしたファイルを見つけ、右クリック→Run Script
- 画面右下（タスクバーのインジケーター？）に[H]が出ていればEffive配列が使えるはず（OFFは、その[H]の部分を右クリック→Suspend Script→[S]に変わる）
Macユーザー
- Karabiner-Elementsをインストール
- GoogleDriveからEffive_6.0.jsonをダウンロード（GitHubじゃなくて悪かったな）
- Karabiner-Elementsを起動→Misc→Open Config Folder
- でてきたFinderのフォルダ内に先程のjsonファイルをペースト
- Karabiner-Elementsソフトに戻り、Complex Modification→Add Rule→Effive_6.0をEnableに
- Command + Control + Option + 1 でEffive配列利用可能（OFFはCommand + Control + Option + 0）
※もし一部の文字の出方が変な場合は、Mac設定→キーボードから、お使いのキーボードが日本語キーボードとして登録されていることを確認する。
ChromeOS
ァア゙？See Run Pet Pay! 知らんガーナ！大人しくChromebookを置け！
というのは冗談で、こちらに関しては単純にやり方がないようだった。もしあったとしても、とても私の手で開発できないと思われる。
Linux
ごめんな。私には分からない…
EffiveRomanを実装する
Effive配列用に最適化したローマ字テーブル、EffiveRoman（詳細は後述）の導入方法を説明する（WindowsもMacも両方いける）。
- Google日本語入力をインストール
- GoogleDriveからEffiveRoman_6.0.0.txtをダウンロード
- どうにかしてGoogle日本語入力の設定画面を開く（Windowsは、タスクバーのⒿ→Google日本語入力→レンチマーク🔧→プロパティ）（Macは、Launchpad→Google日本語入力のうちConfigDialogの方）
- ローマ字テーブル「編集」→編集→インポート…
- 先程のテキストファイルを選択
- 適用→OK（もし有効にならない場合はセキュリティ面で引っかかっているおそれあり）
EffiveRomanの機能紹介
EffiveRomanに切り替えることで何ができるのか。以下にまとめた。
拡張母音
これこそEffiveRoman最大のメリットと言って良いと思う。
そもそもローマ字入力は、基本的には子音字の打鍵後に母音字を組み合わせることにより実現される。例えば子音字として「S」を選ぶことでサ行を指定、その後に母音字として「U」と打つことで「す」を入力することができる。
ローマ字の概念上、母音字としての役割を果たすのは「A,I,U,E,O」のみであり、皆は自然とこの5種の中から選択し、文字を入力している。
では、母音字として使える文字、言い換えれば子音字を指定したあとに打てる文字を増やしてみるのはどうだろうか。この考えを拡張母音といい、有名なものにはAZIK（エイズィック）がある。
AZIKを例に説明すると、例えば「Z」を子音字としてはザ行のままでありながら、母音字においては「A+ん」と振る舞うものとする。これにより「かん」という二文字を「KANN」ではなく「KZ」のみで入力することが可能となるのである。
ただこの規則に従うとなれば「ZZ」は従来の「っｚ」ではなく「ざん」が打てるものとする必要があるため、促音「っ」に関してこれまでの子音字重ねとは別の打ち方を考えなくてはいけない。AZIKの場合、「；（セミコロン）」で「っ」を入力する。
また、「Z」の「A+ん」としての振る舞いは何らかの子音字が指定された状態で打たれることで起きるため、「Z」単体で「あん」と直接入力できることはなく、ザ行の指定という子音字としての役目を果たす。拡張母音を用いた「あん」の入力には、その前にア行であることを指定する子音字のような概念を入力されている必要がある。AZIKをアレンジしたAZITでは、これを無音子音と呼称した上で「V」を割り当てている。
Effive配列が母音横並びにこだわった理由は拡張母音の導入にある。EffiveRomanの場合、左手下段で「撥音拡張」、左手上段で「二重母音拡張」、左手数字段で「ク拡張」が容易に実現可能となっているのだ（但し「エ段+ク」は圧倒的に使用頻度が低いため例外的に「エ段+ツ」とした）。
その他補足
促音は「；」で入力するが、拡張母音に用いている文字で「Z」以外は子音字に用いられていないので基本的に子音字重ねでも機能する。
無音子音には「”」を採用した（遠いと感じる方は使わなくていい）。
単音拡張
C,J,L,Qを始め、F,V,Xなどはローマ字入力ではいわゆる特殊音担当のため、通常の日本語入力においてあまり用いられない。そこで思い切ってこれら7文字をそれぞれ仮名1文字に置き換えてみようという試みである。代表的なものにJacql（ジャックル）がある。そしてそれを参考に使用文字を拡大したかなりの単音入力推進派であるRGTもあるので興味のある方はぜひご一読を。
私はこれを単音拡張と名付け、先ほどの七文字のみを頻出の仮名に割り当てた。なるべく使用するアルファベットと関連性のある割り当てを心がけた。
| イ | 14269024 |
| ウ | 12775155 |
| ル | 12178888 |
| ン | 10996690 |
| ノ | 8067242 |
| カ | 7375401 |
| ス | 6940888 |
| ト | 6837378 |
| シ | 6744323 |
| タ | 6724055 |
| ク | 6454080 |
る…L 「L」自体にラ行のイメージがあるのでかなりふさわしい
の…V ギリシャ語で「Ν」の小文字は「ν」となるので、どれかというと「V」が望ましい
か…Q 例えば「カタール」は「Qatar」と綴り、関連性がある。また疑問文は文末を「か」とする為「Question」を連想させるという点でも適当
す…J 消去法。こじつけるならば「す」の形状に最も似ているのは「J」であろう。「ジュース」で覚えといて
と…C 消去法。こじつけるならば「と」の形状に最も似てい（略） うーん覚え方は「チョコレート」とか？
し…X 中国語「謝謝」は「Xie Xie」と綴るため、「シャ行」と関連性がある。
た…F こいつこそキングオブ消去法。全く関連性がない。「ファンタ」で覚えといて
これには違和感を覚えるのも無理はない。例えば一見「J」を完全に「す」として用いるのは、今までJによる恩恵を受けていた「ジャ行」を全て「ZY」とすることになり、大損なのではないかと感じるであろう。しかし、現代日本語書き言葉均衡コーパスによると、「す」はジャ行全ての文字の出現回数の2~3倍にもなり、圧倒的な差であることがわかった。つまり、Jはジャ行に構うより「す」として使われた方が理論上お得なのだ。
とはいえ、この単音拡張は一般的なローマ字の概念からかけ離れており（どちらかというとかな入力に近い考え方）、習得にもかなりのエネルギーを必要としそうである。現に私は慣れておらず、「る」は「L」でなく単に「RU」で入力している。
リリースしている中で申し訳ないが、まだ検証段階なのでこれが効率を良くするものと感じられるかは未知数であるのが正直なところではある。もし「慣れない」「CやF,Jが使えなくて不便だ」という私の感想もしくは周囲からの意見が出た場合、これを廃止してちゃんとした行（Fならファ行など）に割り当て直す予定である。これを理由にローマ字テーブルを変更する際は、AZITを参考に
- Q：キャ行
- X：シャ行
- C：チャ行
- F：ファ行
- L：リャ行
- J：ジャ行
- V：ヴァ行
とする。ひょっとしたらこちらの方が使いやすいという可能性は否定できない。当分は様子見。
語尾拡張
今回の研究で日本語の使用傾向を調べて分かったのが「です」「ます」の頻度の多さである。これをどうにかできないかと思った私は、右手での実現を試みた。
| g | t | n | s | k | |
| D | でしたら | でして | でした | です | でしょう |
| M | ましたら | まして | ました | ます | ましょう |
| H | すれば | して | した | する | しよう |
| R | あれば | あり | あった | ある | あろう |
| P | でございましたら | でございまして | でございました | でございます | でございましょう |
| B | ませんでしたら | ませんでして | ませんでした | ません | ませんでしょう |
| W | なれば | なり | なった | なる | なろう |
表は大文字が一文字目、小文字が二文字目を示す。
右手上下段で活用させたい語を選び、右手中段で活用の仕方を選択といった具合だ。
問題は、DGとDSにおいて既存の子音と被ってしまう点だ。語尾拡張での利便性を考慮し、DGによるヂャ行とDSのヅァ行は拗音や拡張母音を使えないものとした（だってどうせヂュヮとかヅェイなんて使わんだろ？）。DGやDSの後にA,I,U,E,Oが来ない場合は語尾拡張におけるDG,DSであると判断し入力が進行することとなる。
例えば「DS.」と打つと、これまでの拡張母音の規則では「づぁん」が入力されるはずだが、ここではDSを語尾拡張によるもの（→「です」）と見なされ、「.」と合わせて最終的に「です。」と入力されるのである。
こそあど拡張（指示語拡張）
語尾拡張と同様の理由で明らかとなったのは「これ」「その」などの指示語の多さである。こちらも右手での実現を考案した。
| c | d | m | n | r | p | b | l | |
| K | ここ | こいつ | こんな | この | これ | こなた | こっち | こちら |
| S | そこ | そいつ | そんな | その | それ | そっち | そなた | そちら |
| G | あそこ | あいつ | あんな | あの | あれ | あなた | あっち | あちら |
| T | どこ | どいつ | どんな | どの | どれ | どなた | どっち | どちら |
これは語尾拡張と反対に、まず右手中段で此其彼何を選び、二文字目に右手上下段から語の種類を選択する。
中段にこだわったため、「あ」と「ど」が実態とは違う文字になっているのは申し訳ない。「ど」は「D」だと「です」の拡張と被ってしまうので対応する清音「と」の子音である「T」とした。そして全体的に遠い場所を示す指示語となる「あ」は、実際に人差し指を伸ばす必要のある「G」に割り当てた。
特殊音
特殊音の定義は様々だが、ここでは捨て仮名や通常簡単には入力できない仮名のことを意味する。といってもそれだけじゃ定義として不十分かもしれない。申し訳ないが、お詫びとして早速例を挙げる。
捨て仮名
いわゆる小文字のこと。ヵやヶを入力するために考慮せねばならないものである。あとは、滅多にいないかもしれないがアイヌ語を頻繁に打つという方にとっては便利に思うであろう。
通常、小文字はXやLを用いると思うが、今回は「”」を用いることとした。そして、アイヌ語入力者にも向けて全ての捨て仮名に対応した。
"KAで「ヵ」と打てるのはさながら、"ROで「ㇿ」や"Pで「ㇷ゚」なども実現可能となった。
アに濁点行の実現
ネットならではだが、時折SNSなどであ゙ の文字を見かける。大抵の人がコピペ、もしくは辞書登録と思われるが、今回はこのア゙ 行に対応する子音を新たに考えてみることとした。それに用いたのは…なんと「?」である。そう、「?A」と打つだけで簡単に「あ゙」と打つことができるのだ。
しかしこれには若干の迷いがある。まず、「?」を割り当てた理由としては
- Effive配列ではシフト無しで入力可能
- IPAの世界で「あ゙」にあたる子音の発音記号は「ʕ」となっており「?」と形状が似ている
- ?のあとに母音を続けて打つことがない（？は大抵文末に来るのでだいたいそこで変換し、?の直後に続けて母音を打つ機会が考えにくい）のでそこまで支障がない
の3点が関係している。ところがやはり、そうは言ってもやはり…3点目に関しては全員がそうとは言い切れないのが実情なのだ。人によってはこの機能により使いづらさを感じてしまう可能性もある。そのため、「『?』はちょっと…」という声が割と上がった場合は代わりに「KH」などに子音字を変更するつもりである（KHはあくまでも例なので、もし実際に変わるともなれば、他にいい子音字がないか募集しようと思う）。
踊り字・濁点
佐々木の「々」をラクに打ちたいと思ったことはないだろうか？（あってください）
初心者やその場での応急処置としてはコピペ、玄人にもなれば「おなじ」と打ってからの変換技など色々方法はあるが、今回はこちらも拡張入力の暴力が味方してくれた。
踊り字全般を「R」との二文字連続で実現させた。
一部を紹介すると、「RC」で「々」、「RD」で「ゞ」などが可能だ。
また、それに合わせて「RB」で「゙ 」、「RP」で「゚ 」といった濁点までをも打てるようにした。
隠しコマンド
さらに、電話番号など数字羅列の読みがな「例）ぜろいちにいぜろ」や、→また※などのよく使われる記号も簡単に打てるようにした。
以上で紹介しきれなかった分や隠しコマンド全般の細かい入力方法は以下の表にまとめているので、興味のある方はご覧いただければと思う。
また、取扱説明書のように各自が活用してくださればなおありがたい。
使いづらい点などは今後の数多くの方々による長期的な使用を通して見えてくるであろうから、そういったのが出れば適宜、今後も改良していきたいEffiveRomanである（尤も、2023年度現在私は忙しいため即座に対応できないと思われるが）。Effiveは、一番の配列でないかもしれない。しかしEffiveRomanは、私が思いつく限りのアイデアを詰め込んだ最強のローマ字テーブルであると思っている。そんなパワフルな武器を兼ね備えている入力方法なので、ぜひ一人でも多くの方々にEffive配列を愛用してほしいところである。そうなれば何よりである。
ここまで長文申し訳なかったが、読んでいただいた方そしてEffive配列を使用してくださっている方々に感謝申し上げる。
新配列と新ローマ字を考える話 - Effive配列とEffiveRoman（前）
出会い
キー配列
今日も暇だな〜と思いながら最近始めたTwitterを開き、例の如くスマホ片手に寝そべる私。そんな中TLに流れたただ一つの記事が、全ての始まりだった。
ようやく完成。気づけば1時半を回りました。
— とみすけ (@_Tomisuke) 2022年7月9日
色分けは諦めて一つ一つやったので、間違ったところあったら教えてくださいませ。
疲れたので考察は置いておいて、とりあえずQWERTYの圧倒的なゴミさが露呈する結果となりました。 pic.twitter.com/TOdFrr5QSL
当時、QWERTY配列が決して打ちやすい配列でないということは何となく薄々知りながらも、数字で見るとこれほどまでに他と比べて酷いものなのかと衝撃を隠せなかった。
それに対してこの方はTomisuke配列という新しいキー配列まで考案し、他のものと比較した際の優位性を実証している。ぜひこのサイトも皆さんに見ていただきたいものだ。
ローマ字
ちょうど同じ頃、当時ハマっていたものにローマ字テーブルの開発があった。
私は、小学生時代からローマ字に興味を持っており、その熱意は小6夏の自由研究としてローマ字辞典を作成するほどのものであった。その後しばらく熱は冷めるものの、次は国際音声記号に興味を持ち、いつしか日本語の発音についても（素人ながら）考えるようになった。私は「ローマ字は実際の発音に忠実であるべきだ」という思想を抱き始め、自らローマ字表を作成した。
こうしたカスタマイズを柔軟にするのにGoogle日本語入力というツールがある。以下のサイトが大いに参考になったので載せておく。
ひらめいた
今まで紹介してきたこの「新しいキー配列」「新しいローマ字」の2つを組み合わせることで、英語にも日本語にも強くするのはさることながら、日本語においてはさらに画期的なローマ字入力を実現できるようにそこんとこを良い感じに調節した配列ができれば、未だかつてないほど便利な入力方法が誕生するのではないかという考えに至った。
名称
ここで、私が開発する新キー配列をEffive配列（エファイブはいれつ）とし、新ローマ字テーブルはEffiveRoman（エファイブローマン）と命名した。
こちらはもともと私の所属する研究グループにF5という識別番号が割り当てられていたことによるもので、"ef"&"five"をくっつけた造語である。
のちに"Effive"という綴りが、「効果的な」の意を示す英単語"Effective"から3文字脱落しただけのものでもあることも判明し、より少ない文字数で効果的に打てるそのスピーディーさもアピールできているとして、この名称は理にかなっているのである（これはこじつけ）。
完成したやつ
Effive配列は下の画像の通りになった。
Effive配列は開発の過程を残すため、ここぞというときで個人的にチャプターのようなものを設け、ヴァージョン記号のようにして記録した。Ver.6.0となるEffive_6.0（エファイブろくてんぜろ）をもって完成となった。
新配列開発の過程
ここでは実験の流れとともにEffive配列の変遷を説明する。
以下かなり長い内容なので急いでいる人向けに簡単に説明すると、
- 英語における指の移動距離を抑えてみる《英語短距離型》
- 英語での同指連打をできるだけ避ける《英語連打抑制型》
- 日本語の使用傾向を見る《日本語考慮型》
- 英語面で改良を加える《英語強化型》
- 日本語で改良を加える《日本語強化型(Ⅰ)》
- 先行研究と戦う《日本語強化型(Ⅱ)》
といった流れで研究は進んだ。詳細は以下のとおり…
実験方法
他の配列考案者も実践していることなので「知っている人は知っている」でおなじみ、Keyboard Layout Analyzerを私も使用した。そのスコアを比較することによって結果を調べた。
予想する
実験など全てを行う前、私は根拠なく何となくこんな感じになるのではと予想した。
結果はことごとく惨敗。不思議の国のアリスChapter.1でやるとご覧の結果。
| 1 | P. Dvorak | 66.11 |
| 2 | S. Dvorak | 65.86 |
| 3 | Colemak | 65.83 |
| 4 | Effive_β | 56.62 |
| 5 | QWERTY | 46.66 |
やはり論理的なデータに基づいて改善していく必要がありそうだ。
英語を考える
まず英語の文字の使用傾向を調べた。サンプルの英文はなるべくたくさん欲しいので、英語の長文が多数掲載されているe-Readerからネイティブ向け（レベルC1およびC2）の文章72個をかき集めた。
英字26文字に限らず、キーボードから一回（Shiftはノーカウント）の打鍵で入力できる文字にまで検索範囲を広げ、一つずつ調べた結果がこちらになる。
| # | Frequency | Percentage |
| E | 1089288 | 11.927% |
| T | 778172 | 8.520% |
| A | 707054 | 7.741% |
| O | 667301 | 7.306% |
| N | 580136 | 6.352% |
| I | 574984 | 6.295% |
| H | 552689 | 6.051% |
| S | 525503 | 5.754% |
| R | 485666 | 5.318% |
| D | 405584 | 4.441% |
| L | 357536 | 3.915% |
| U | 241423 | 2.643% |
| W | 225458 | 2.469% |
| M | 223759 | 2.450% |
| C | 195244 | 2.138% |
| Y | 185682 | 2.033% |
| G | 181506 | 1.987% |
| F | 168418 | 1.844% |
| . | 164778 | 1.804% |
| P | 136668 | 1.496% |
| B | 132127 | 1.447% |
| , | 124369 | 1.362% |
| K | 96748 | 1.059% |
| 93189 | 1.020% | |
| V | 78166 | 0.856% |
| " | 62814 | 0.688% |
| ? | 17389 | 0.190% |
| J | 15253 | 0.167% |
| - | 15131 | 0.166% |
| X | 12772 | 0.140% |
| ! | 7712 | 0.084% |
| Q | 6287 | 0.069% |
| Z | 6170 | 0.068% |
| ; | 4011 | 0.044% |
| : | 3023 | 0.033% |
| 0 | 2010 | 0.022% |
| 1 | 1792 | 0.020% |
| 9 | 1013 | 0.011% |
| ) | 1013 | 0.011% |
| ( | 1010 | 0.011% |
| 2 | 820 | 0.009% |
| 5 | 650 | 0.007% |
| 3 | 604 | 0.007% |
| 4 | 541 | 0.006% |
| 8 | 541 | 0.006% |
| 7 | 407 | 0.004% |
| 6 | 347 | 0.004% |
| / | 252 | 0.003% |
| * | 152 | 0.002% |
| $ | 118 | 0.001% |
| = | 11 | 0.000% |
| & | 8 | 0.000% |
| [ | 5 | 0.000% |
| % | 5 | 0.000% |
| ] | 4 | 0.000% |
| + | 4 | 0.000% |
| @ | 1 | 0.000% |
| _ | 0 | 0.000% |
| { | 0 | 0.000% |
| } | 0 | 0.000% |
| # | 0 | 0.000% |
| ` | 0 | 0.000% |
| ^ | 0 | 0.000% |
| < | 0 | 0.000% |
| > | 0 | 0.000% |
| | | 0 | 0.000% |
| ~ | 0 | 0.000% |
| ¥ | 0 | 0.000% |
| 0 | 0.000% | |
| 9133318 | ←合計文字数 |
距離を短く
最も指の移動距離を短縮すべく、まずそれぞれのキーがホームポジションから何ミリかかるかを計測した上で、同じ移動距離となるキーは打ちやすい順に枝番を振った。
それに応じて左右それぞれでランクづけを行い、
先ほど出した英語の使用頻度ランキングに対応させた。
その結果がEffive_1.0である。
ただ順位に応じて割り当てたに過ぎないので、見ての通り数字の順序もバラバラで使いづらい（丸括弧に至っては狂ったように離れている）。
しかし先ほどのe-Reader長文データを全て入力する場合、従来のQWERTY配列で要していた指の移動距離を55%にまで短縮することに成功した。ところがこの状態でまた試すも、他の配列を上回ることはなかった。
| 1 | P. Dvorak | 66.11 |
| 2 | S. Dvorak | 65.86 |
| 3 | Colemak | 65.83 |
| 4 | Effive_1.0 | 63.46 |
| 5 | QWERTY | 46.66 |
こうなった原因として、同じ指による連打の頻発が考えられる。
英語の場合、"Go"や"We"などの単語がよく使われるのは何となく分かるだろう。そういった際に同じ指での連続打鍵が発生しているというのはかなり効率が悪いことにつながってしまうと見た。
ではどうしたら良いか。
二文字で頻度調査
次にやったことは、英字を対象とした二文字毎の頻度調査である。これを行うことで、ある文字を打った後の次にくる文字の傾向を知ることができる。頻度が高いものを優先的に同じ指に割り当てないように調整することで、同指連打を避けるという算段だ。
その結果がこちらになる。
| a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z | |
| A | 64 | 15375 | 25404 | 38231 | 280 | 6369 | 13626 | 1869 | 34275 | 230 | 10281 | 51726 | 19265 | 138184 | 135 | 12391 | 33 | 67907 | 71546 | 84384 | 8554 | 16587 | 7108 | 1007 | 22612 | 1015 |
| B | 13389 | 1119 | 25 | 17 | 42922 | 5 | 2 | 7 | 5471 | 312 | 0 | 12921 | 40 | 8 | 19296 | 9 | 0 | 8581 | 1071 | 521 | 18159 | 361 | 22 | 0 | 6054 | 0 |
| C | 31174 | 340 | 2486 | 144 | 27998 | 7 | 1 | 31938 | 8738 | 0 | 18949 | 7899 | 3 | 112 | 35367 | 18 | 78 | 8017 | 468 | 12774 | 5045 | 0 | 2 | 0 | 991 | 27 |
| D | 13427 | 264 | 137 | 4938 | 39346 | 319 | 1607 | 174 | 25088 | 65 | 109 | 3344 | 810 | 5864 | 26877 | 35 | 37 | 10631 | 8286 | 54 | 3064 | 651 | 572 | 0 | 5920 | 10 |
| E | 52808 | 1727 | 17587 | 98125 | 32991 | 8912 | 5071 | 2109 | 8591 | 87 | 1765 | 39930 | 18800 | 83710 | 4577 | 9718 | 674 | 143867 | 55247 | 31817 | 859 | 17779 | 10421 | 9000 | 17961 | 395 |
| F | 11894 | 54 | 28 | 0 | 15672 | 8174 | 4 | 1 | 15766 | 0 | 1 | 4027 | 12 | 10 | 30032 | 6 | 0 | 14852 | 94 | 8531 | 6157 | 0 | 49 | 0 | 230 | 0 |
| G | 12266 | 80 | 8 | 62 | 24419 | 14 | 1859 | 25242 | 8558 | 0 | 2 | 3706 | 100 | 2055 | 17263 | 5 | 0 | 9184 | 3536 | 612 | 4624 | 0 | 34 | 0 | 616 | 4 |
| H | 90668 | 222 | 27 | 180 | 267876 | 94 | 21 | 35 | 70025 | 0 | 3 | 472 | 424 | 1063 | 42425 | 25 | 31 | 6297 | 1003 | 17399 | 5288 | 19 | 222 | 0 | 3392 | 0 |
| I | 7912 | 3029 | 25273 | 34881 | 21249 | 13608 | 18030 | 99 | 46 | 55 | 6701 | 29147 | 25029 | 152302 | 17638 | 3071 | 187 | 20083 | 59568 | 68005 | 474 | 12165 | 32 | 1340 | 32 | 2413 |
| J | 2612 | 0 | 0 | 1 | 2333 | 1 | 0 | 1 | 148 | 0 | 1 | 0 | 0 | 0 | 4390 | 3 | 0 | 23 | 4 | 0 | 5629 | 0 | 0 | 0 | 28 | 0 |
| K | 1790 | 154 | 22 | 21 | 31930 | 242 | 65 | 181 | 12256 | 21 | 6 | 1607 | 48 | 9621 | 901 | 61 | 0 | 341 | 3749 | 85 | 405 | 0 | 279 | 0 | 821 | 1 |
| L | 28829 | 847 | 568 | 27674 | 56340 | 5124 | 204 | 148 | 37691 | 193 | 4857 | 53683 | 2167 | 501 | 33031 | 1990 | 1 | 1019 | 6374 | 5115 | 4147 | 1549 | 1796 | 0 | 30338 | 110 |
| M | 33683 | 4652 | 431 | 7 | 62277 | 553 | 11 | 86 | 17424 | 0 | 1 | 392 | 2942 | 546 | 22595 | 7989 | 6 | 4066 | 4141 | 77 | 7032 | 27 | 99 | 0 | 13056 | 9 |
| N | 12577 | 354 | 13741 | 95938 | 56275 | 2338 | 77555 | 448 | 17293 | 949 | 8210 | 5152 | 438 | 6876 | 40081 | 243 | 284 | 415 | 16132 | 48208 | 4279 | 2234 | 331 | 243 | 8597 | 93 |
| O | 3894 | 4680 | 6638 | 13154 | 2835 | 44165 | 3840 | 2076 | 7778 | 135 | 13963 | 20157 | 39164 | 82236 | 34625 | 13411 | 3 | 69814 | 16453 | 33886 | 105170 | 11518 | 34556 | 874 | 2696 | 349 |
| P | 15911 | 90 | 116 | 67 | 28887 | 104 | 0 | 3997 | 7431 | 0 | 76 | 14141 | 190 | 36 | 12696 | 9480 | 0 | 13136 | 3418 | 5130 | 5553 | 0 | 48 | 0 | 1208 | 0 |
| Q | 2 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 6218 | 0 | 0 | 0 | 0 | 0 |
| R | 26385 | 951 | 4015 | 14391 | 106858 | 1670 | 4680 | 1077 | 37351 | 10 | 6700 | 6341 | 7064 | 11834 | 43055 | 2137 | 41 | 10566 | 26151 | 17280 | 7008 | 2523 | 1041 | 19 | 16954 | 7 |
| S | 30137 | 735 | 5948 | 354 | 53306 | 524 | 174 | 40938 | 25332 | 8 | 7492 | 4929 | 4605 | 3224 | 27161 | 9446 | 397 | 95 | 19504 | 62870 | 13181 | 60 | 3312 | 0 | 1878 | 72 |
| T | 26617 | 171 | 3203 | 87 | 62986 | 396 | 62 | 244658 | 40321 | 0 | 18 | 8527 | 1166 | 663 | 88784 | 146 | 0 | 17734 | 10751 | 14229 | 10427 | 106 | 5625 | 0 | 7833 | 371 |
| U | 3913 | 2597 | 7443 | 4840 | 5830 | 1098 | 13683 | 158 | 5808 | 13 | 221 | 24032 | 4498 | 24665 | 216 | 10366 | 9 | 32166 | 29503 | 39458 | 8 | 50 | 2 | 158 | 809 | 548 |
| V | 3897 | 0 | 6 | 1 | 59024 | 0 | 14 | 0 | 10721 | 0 | 1 | 1 | 0 | 60 | 3104 | 1 | 0 | 34 | 42 | 0 | 63 | 1 | 1 | 0 | 560 | 0 |
| W | 60518 | 47 | 32 | 487 | 35367 | 220 | 12 | 33316 | 28690 | 0 | 142 | 1441 | 15 | 7833 | 23264 | 28 | 0 | 2740 | 2423 | 193 | 137 | 0 | 8 | 0 | 519 | 0 |
| X | 1309 | 31 | 1573 | 0 | 710 | 93 | 0 | 164 | 1254 | 0 | 0 | 4 | 2 | 0 | 39 | 2904 | 12 | 0 | 3 | 2382 | 75 | 0 | 0 | 0 | 38 | 0 |
| Y | 1167 | 1366 | 385 | 167 | 10807 | 51 | 49 | 142 | 3183 | 2 | 65 | 601 | 541 | 512 | 37192 | 578 | 0 | 232 | 6036 | 2631 | 66 | 9 | 771 | 1 | 3 | 39 |
| Z | 698 | 2 | 1 | 2 | 2416 | 0 | 5 | 48 | 966 | 0 | 0 | 189 | 27 | 5 | 235 | 43 | 0 | 17 | 0 | 0 | 52 | 1 | 26 | 0 | 419 | 419 |
これに基づきEffive_2.0を考案した。
この後あと、順序なんかどうでもよくね（"ab"も"ba"も、必要とする指の動きの大変さは変わらないのではないか）ということで順列から組合せに考えを変更し、Effive_2.1、2.2と改良を加えた。
CK値
キーを並べ替えるにあたり、ある問題が生じた。それは、頻出のキーを特等席に置こうとすると、それと同じ指が担当する位置のキーの割り当てが上手くいかなくなるという点である。
例えば、「E」は英語において頻出なので、ぜひ中段の打ちやすい位置に置いておきたい。するとEと同じ縦列に位置するキーたちは、Eと同じ指で打つ必要がある。しかしE自体が頻出のため、同指連打を避けようとするとEと同じ指担当のキーに置ける文字がQやZなどほぼ使わないキーしか置けなくなってしまう。よく使われるキーを打ちやすい場所に持っていくと、その上下隣は滅多に使わないキーを置かざるを得ないのだ。
これは大変バランスが悪いので、相対的に考える必要が出てくる。
例えば、ある文字αが、一文字だけで見たときは使用頻度が他の英字よりかなり高い結果だったとする。この時、一般にαは他のどの文字との二文字組合せにおいても、二文字毎の頻度調査ランキング全体では頻出となることが多い。ところが、もう一つのある文字βから"βα"という二文字の組を調べたら、その使用頻度が少なかったとする。これは「普段頻出のαにしてはβと組み合わせたときには使用頻度が一気に減るのだな」ということを意味する。
まさに「普段誰とも仲良くできるαくんでもβさんを前にすると会話が一気に減るのだな」みたいな感じで、それぞれの文字の他との相性を確かめているのである。
まだ理解しづらいという方に向けて具体例も挙げる。Qという文字はみなさんご存知の通り登場回数はレアである。そしてQが登場する際は大抵後ろにUがくっつく。Quarter,Queen,Quietなどから「普段滅多に登場しないQはほとんどUの隣にいる」と考察できる。すると、Q自体はレアなため「Qと同じ指に割り当てて良いのはU以外なら何でも良い」と考えることができるし、逆に「Uと同じ指にQがあってはならない」とも言える。こうした考えのもと、CK値（連続打鍵指数、英: Consecutive Keystroke）という相対的指標を求めた。
一文字の英字Eからみた二文字の英字組erのCK値は以下のように求める。但し私はこういったデータ処理に関して数学的に正確な知識を持ち合わせていないため、ここは素人考えになってしまうこと、ご了承いただきたい。
- まず一文字単位でのそれぞれの英字の使用回数を並べてそれぞれの偏差値を求める。Eの登場回数について、A~Zの登場回数の平均値を元に求めた偏差値はT_Eとおく。
- 二文字の組を、特定の文字基準で比較してそれぞれの偏差値を求める。erの登場回数について、Eを含む全ての2文字組合せ（ae,...,de,ee,ef,...,er,...,ez）の登場回数の平均値を元に求めた偏差値はT_Erとおく。
- ②の偏差値から①の偏差値を引き、両者の差を求める。ここでT_Er > T_Eとなった場合、「rはEの隣にある可能性が高い」という判断が下され、逆の場合「erという組合せはEの使用頻度の割にはレアだ」といった感じの意味になる。
- ③で出てきた差に50を足して、再び偏差値チックな数値にする。
- ④にerの登場回数（f_erとおく）をかけ、その値を10^(-5)倍する。
まとめると、
f_er * { 50 + ( T_Er - T_E ) } / 10^5
といった具合だ。
このとき、すべてのCK値を見た時に1を境に篩い分けできそうだったので、二文字のいずれからも見た時にCK値が1未満となる場合を「相対的に頻度が低い組合せ」と見なし、これらがなるべく同じ指に割り当てられるように配慮した。
そんな具合でEffive_2.3、2.4が考えられた。結果はご覧のとおり。
| Effive_2.3 | 69.73 |
| Effive_2.4 | 69.28 |
| Effive_2.2 | 67.91 |
| Effive_2.1 | 66.15 |
| P. Dvorak | 66.11 |
| S. Dvorak | 65.86 |
| Colemak | 65.83 |
| Effive_1.0 | 63.46 |
| Effive_2.0 | 61.13 |
| QWERTY | 46.66 |
めでたいことに、英語において今まで1位だった配列（Programmer Dvorak）を上回った！
日本語を考える
ここで日本語も考えることにした。といってもなかなか長文は集められなかった。そこら中にいっぱいあるじゃないか、母国語なのに何やってんだと思うだろうが、そもそも日本語のデータは
- 漢字を含む文章を全てひらがなもしくはカタカナに変換、統一
- それを文字ごとに一対一対応でローマ字に置き換える
ということをして初めて取得できる。そしてなんと1.の工程を行ってくれるツールがあまりないのだった。あるにはあるが厳しい字数制限が設けられている。英語は1000万文字ほど集まったというのに日本語ではそれに及ばない状況となりそうだった。
しかしそんなとき、あるページに出会った。それが「現代日本語書き言葉均衡コーパス」である。こちらは1976~2005年の30年間に及ぶ出版物に基づいたビッグデータである。調査対象となっているジャンルもさまざまで、各冊で一部分を無作為に抽出し、その部分の日本語が記録に使われるといった具合でデータが蓄積されていくらしい。
今回はそのうち、研究目的であれば無償で使えるという語彙表を使用した。
| ◤ | A | B | C | D | E | F | G |
| 1 | rank | lForm | frequency | ア | イ | ウ | エ |
| ︙ | ︙ | ︙ | ︙ | ︙ | ︙ | ︙ | ︙ |
| 16 | 15 | ノ | 1112283 | 0 | 0 | 0 | 0 |
| 17 | 16 | アル | 956900 | 956900 | 0 | 0 | 0 |
| 18 | 17 | デス | 804504 | 0 | 0 | 0 | 0 |
| 19 | 18 | イウ | 803148 | 0 | 803148 | 803148 | 0 |
| 20 | 19 | コト | 740949 | 0 | 0 | 0 | 0 |
これは表の一部だが、例えばD17には
=IF(COUNTIF($B17,"*"&D$1&"*")>0,$C17,0)
と入力する。各単語にどの文字を含むか確かめ、該当する文字があればその単語の登場回数を足し、一番下に合計の行でも作っておけば回数を数えられる。そう思った私はその方法で調査した。
しかし、いろいろこの研究が一段落して片付いたのちにこの方法は間違っていたことがわかった。なぜなら、同一文字が複数回出てくる単語があった場合もその文字が一回しか出現しなかった体で計算されてしまうからである。そのためか本来5億字ほどあるデータのはずなのに私が合計文字を計算すると2億字ほどしかなかった。実は、D17の場合は以下の通りにすべきだったのだ。
=(LEN($B17)-LEN(SUBSTITUTE($B17,D$1,"")))*C17
こうすることで正確に計算できたはずだ。
しかし今更これでやり直すのは相当大変（そもそもデータが重いから計算作業が果てしなくかかる）なので私はこの方法での調査を行っていない（もしこのデータを扱って文字頻度の分析をしたい場合はこの後者の手法を推奨する）。
英語を改良する
私はこのバージョン、3.0が最高なものだとは感じていなかった。まだどこかに効率を高める要素が絶対にあると思っていた。では一体どうすればさらなる飛躍を目指せるのか。それを考えるべく、今までの成績を振り返ってみた。
上記はあくまでも一つずつの文章での比較に過ぎないが、他の文章で比較した際も、傾向としてEffive_2.3が好成績であることが分かってきた。
もうEffive_3.0台からこれ以上更新を続けてもそこから良いやつは生まれないと考えたので、2.3に戻ってそれを元にアレンジを決めていくことにした。こうしてできたのが、Effive_4.0台に続くこととなる。
4.0開発後も4.1~4.5まで更新し続け、結果は以下の通り（4.1は配列データ消失）。
| Effive_4.2 | 69.74 |
| Effive_2.3 | 69.73 |
| Effive_4.3 | 69.41 |
| Effive_4.4 | 69.28 |
| Effive_4.5 | 68.92 |
| Effive_4.0 | 65.64 |
| Effive_4.1 | - |
もう英語がここから伸びることはないだろうと、目処がついた私は、これにて開発を一旦完了とみなした。なぜなら、4.5が（英語改良を目的とした配列なのにもかかわらず）日本語で割といいスコアを記録したからである。当初の目標である、日本語にも英語にも強い配列が完成したと思った。4.5はこのような配列となった。
日本語を改良する
冷静になる
しかしまだ課題は残っていた。他に日本語の文章を6つ追加して比較してみたところ、実はかなりの確率でTomisuke配列に負けていたのだ。
私は、当初はQWERTYを塗り替える、世界共通で新しい効率の良い配列を作ることにより世界は更に作業効率が良くなりさらなる発展につながるのではないかと期待していた。（今振り返れば絶対に有り得ないと思うが）私が開発するEffive配列が世界から愛されることも（味付きいろはすを20倍ほど薄めたぐらい）超淡い希望ながら視野に入れたので、割と英語にウエイトを置いてきた。しかしそんな心は次第に消失してしまう。まず私が日本人である以上日本語を打つ機会が圧倒的に多い。これは、グローバル化の進行により英語の重要性がいくら増したとしても（余程のことがない限り）覆ることのない事実であろう。だったら幾分か日本語を打ちやすくするべきなのではないか。
さらに言えば、もう既に数多くの人が数多くの配列を世に送り出している。そんな中世界のデファクトスタンダードとなることを狙って新しい配列を考えるのか？いやそんなことはできるはずもない。なぜならこんなちっぽけな一日本人の手によって仮にそれらを打ち負かし、世界最強の配列が発明されたとなったところで、それが理由でEffive配列なんてものが世界標準になるなんて余程の富と名声のない限り起こり得ないおかしな話なのである。私達を含め全世界がQWERTY配列に慣れている。とりわけタイピストやプログラマなどからしたら、それがどんなに効率が良いものであっても、その新しい配列に移行するというのは苦痛でしかない（そりゃそうだ）。
要は身の程を知れということだ。そうやって自分に厳しく叱られた私は大人しく日本語を打ちやすくし、自分が満足する配列を実現させることに徹するのだった。
とりあえず、Tomisuke配列を追い越すことを目標とさせていただいた。こうして改良の結果Effive_5.0が誕生した。
その6つの文章で比較した結果、ほとんどの場合においてTomisuke配列を上回ることができた。
強敵あらわる
もう私はこれでいいと満足していた。しかし、再びその思いは打ち砕けてしまう。それはこのサイトに出会ったときのことである。
この記事を読んで目を疑った。世界、いや日本だけですらこの配列界隈というのは広かったのだ。いままで日本語の最高峰だと思ってたTomisuke配列をさらに上回るものがひしめき合っている。それも1つとかじゃなくて複数…
中でもこのブログの編集者が開発した大西配列というのには驚かざるを得なかった。今までに見たことのない数字（スコア）のオンパレードなのだ。78？！二度見した。
はじめにこれらひしめき合っている強つよ配列たちの凄い点として、これが論理配列の枠内で展開されているということである。キー配列はそもそものキーの形状であったり構造（左右で切り離して用意するなど）の違いを考える「物理配列」と、その物理配列は決められた状態の中でキーの並び順やレイアウトの違いを考える「論理配列」の2種の概念に大きく分けられる。一度Effiveなんかより凄い配列たちがまとめられたサイトを見かけたが、それは物理配列自体が違っており、ノーパソの範囲で実現するように無理やり収めてその配列を比較すると効率はかなり良くなかった。つまり物理配列も入力効率を考えるうえでは不可欠な概念であるのは確かだ。
しかし、私はあくまでも一般的なラップトップやデスクトップについてるキーボードで気軽に実現できるものを目指したかったので、その規格内で論理配列を考えていた。
大西配列を始め他のどの配列も、ノーパソで実現できるものだったため、私は何も言えなかったのだ。大西氏がその検証に用いていた日本語の文章を引用し、同じ土俵でEffive配列を戦わせるも、その結果はそれはそれは無惨で目を覆いたくなるほどであった。
さきほど取り上げたブログを見ていて、大西配列と同じぐらい個人的に気になったのがAstarte配列である。こちらは英語にも強く、そのオールマイティさを発揮していた。
私の野望は再び始まった。どうにかしてこの配列たちに追いつけないか。ということで2つの配列を観察してみることにする。とはいえその際「新配列を考えるうえで他者の研究成果を参考にするのは、真の自分で考えた配列とは言えないのではないか」という葛藤がどこかにあった。けれど先行研究からさらに良いものが生まれるのだという考えに落ち着き、厚かましくも参考にさせていただいた。
両者を見ると、母音の文字が横一列ではなく一つはみ出す形で並んでいるのだ。大西配列考案の過程から考えるに、その配置のほうが、とりわけ日本語での入力効率を底上げするものだと推測される。
ここで私は、どんなに改良を加えたところでこの配列を上回ることができないことに気づいた。理由は私が勝手に定めた条件にある。私は、前述の（すっごい最初の方で書いた）通り「ローマ字拡張を必要に応じて取り入れられること」を条件に研究を進めた。分かりやすい拡張母音の仕組みを導入するには、母音A,E,I,O,Uを横一列に並べざるを得なくなるのである（詳細は別記事）。
ローマ字拡張により入力効率がどう変わるかは現在まで議論が別れている。拡張母音の導入が入力効率にどう作用するのかをKLAで確かめることはできない（なぜならそもそも入力に使われている文字が違い、文字数も異なるため両者は事実上違う文章となるため同時に比較はできない）。ここで私はあくまでも、打鍵数を減らせる特徴を持つローマ字拡張は日本語入力の効率を高め、それを使えるような配列にしておくことは大事なことだと考えた。そのため、どれだけ効率を良くしようと配列を変えていっても、少なくともローマ字拡張を使えない配列にだけはならないようにしたかった。
この状態で日本語の入力効率を高めるには、Kをホームポジションに持っていく他なかった。Kは英語ではあまり使われる文字ではなく、それをホームポジションに置くことは英語面での低下を招くリスクがあることを意味する。このリスクを最小限に抑えるため、小指に持っていった。
その他よく使う二重子音が打ちやすくなるようにした。特にこだわったのは「*h」となるものである。ch,gh,ph,sh,th,wh,...などはスムーズに打てるようにした。
こちらがEffive_6.0である。
スコアは以下の通り。
| アパホテル新宿歌舞伎町中央ホテルからのお知らせ | |||||||||
| 日本語 | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 51.74 | 54.95 | 64.18 | 63.79 | 72.73 | 69.5 | 66.96 | 74.74 | 70.32 |
| 移動距離(cm) | 11602.2 | 6201.2 | 6355.7 | 6353.6 | 57.2 | 5528.6 | 5824.8 | 6468.1 | 6164.6 |
| 同じ指回数 | 236 | 369 | 114 | 138 | 121 | 151 | 187 | 140 | 155 |
| 同じ手回数 | 1427 | 997 | 1388 | 1404 | 683 | 567 | 609 | 562 | 686 |
| Prime Video登録について | |||||||||
| 日本語 | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 44.52 | 58 | 61.64 | 63.75 | 74.59 | 71.17 | 66.26 | 75.52 | 71.16 |
| 移動距離(cm) | 6418.1 | 3655.2 | 3576.8 | 3750.5 | 33.5 | 3377.4 | 3590.8 | 3839.9 | 3554.2 |
| 同じ指回数 | 213 | 152 | 81 | 78 | 53 | 66 | 95 | 72 | 74 |
| 同じ手回数 | 830 | 499 | 797 | 720 | 322 | 293 | 325 | 309 | 358 |
| セブンイレブン社員行動規範（抜粋） | |||||||||
| 日本語 | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 51.32 | 55.79 | 65.22 | 65.22 | 75.1 | 69.28 | 67.44 | 74.97 | 69.54 |
| 移動距離(cm) | 10168 | 5285.6 | 5116.5 | 5052.4 | 44.3 | 4256.9 | 4463.9 | 5161.9 | 4927.6 |
| 同じ指回数 | 211 | 261 | 69 | 90 | 71 | 119 | 141 | 97 | 148 |
| 同じ手回数 | 1217 | 924 | 1243 | 1187 | 659 | 576 | 608 | 549 | 664 |
| 走れメロス - 青空文庫 | |||||||||
| 日本語 | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 54.38 | 66.47 | 67.96 | 69.5 | 77.52 | 75.18 | 71.71 | 80.8 | 75.85 |
| 移動距離(cm) | 29456.5 | 14258.3 | 13198.3 | 13539.2 | 13451.8 | 12372.1 | 12984.8 | 13783.1 | 12736.1 |
| 同じ指回数 | 533 | 518 | 152 | 151 | 164 | 205 | 301 | 137 | 227 |
| 同じ手回数 | 3523 | 1575 | 3308 | 3185 | 914 | 804 | 932 | 737 | 929 |
| 北越急行ほくほく線 - Wikipedia | |||||||||
| 日本語 | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 47.49 | 56.65 | 61.38 | 61.52 | 69.36 | 67.21 | 64.4 | 71.09 | 68.14 |
| 移動距離(cm) | 38620 | 21875.1 | 22148.1 | 22214.5 | 21188.2 | 19619.6 | 20562.4 | 22855.7 | 22060.9 |
| 同じ指回数 | 858 | 916 | 418 | 461 | 388 | 489 | 580 | 405 | 478 |
| 同じ手回数 | 4455 | 3018 | 4469 | 4291 | 2196 | 2033 | 2109 | 1925 | 2155 |
| WESTER会員規約 | |||||||||
| 日本語 | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 52.58 | 58.83 | 65.03 | 65.96 | 73.49 | 70.34 | 68.2 | 76.62 | 70.33 |
| 移動距離(cm) | 34033.4 | 16949.8 | 17225.6 | 17038.7 | 15661.4 | 14884.3 | 15634.2 | 17223 | 16339.4 |
| 同じ指回数 | 672 | 859 | 385 | 347 | 425 | 449 | 486 | 334 | 506 |
| 同じ手回数 | 4122 | 2896 | 3992 | 3886 | 2212 | 1814 | 1896 | 1729 | 2263 |
| Anki ホームページ | |||||||||
| English | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 44.42 | 56.31 | 58.52 | 55.34 | 59.3 | 55.66 | 48.87 | 55.43 | 59.18 |
| 移動距離(cm) | 9615.1 | 6605.3 | 5845.8 | 6154.7 | 6980.7 | 6469.2 | 6509.8 | 6415.3 | 6031.9 |
| 同じ指回数 | 251 | 199 | 169 | 205 | 149 | 226 | 300 | 222 | 178 |
| 同じ手回数 | 1094 | 777 | 987 | 1044 | 816 | 873 | 931 | 922 | 833 |
| Desmos What's New | |||||||||
| English | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 45.6 | 60.56 | 61.78 | 59.62 | 61.91 | 58.58 | 53 | 56.26 | 61.9 |
| 移動距離(cm) | 33446.5 | 22170.3 | 20478.7 | 21658.1 | 24447.6 | 22726.4 | 22713.3 | 22296.5 | 20599.3 |
| 同じ指回数 | 810 | 564 | 431 | 490 | 426 | 673 | 875 | 835 | 578 |
| 同じ手回数 | 3871 | 2420 | 3456 | 3438 | 2482 | 2728 | 2891 | 3116 | 2564 |
| Musescore 利用規約 | |||||||||
| English | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 46.92 | 61.94 | 64.57 | 61.24 | 62.74 | 59.72 | 53.14 | 59.91 | 62.32 |
| 移動距離(cm) | 169355.2 | 111108.7 | 97380.9 | 105008.6 | 122038.9 | 109510.5 | 110634.3 | 107853.6 | 100613.9 |
| 同じ指回数 | 3493 | 2135 | 1667 | 2243 | 1730 | 2862 | 4185 | 2700 | 2381 |
| 同じ手回数 | 16415 | 10755 | 13808 | 14746 | 11166 | 12747 | 13372 | 13504 | 12012 |
| Introducing OpenAI ※OpenAI社最初のブログ | |||||||||
| English | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 49.66 | 63.17 | 66.16 | 63.39 | 64.31 | 59.66 | 53.17 | 62.51 | 64.27 |
| 移動距離(cm) | 11917.2 | 7277.2 | 6694.4 | 6955.2 | 7850.1 | 7336.7 | 7389 | 6733.7 | 6427.5 |
| 同じ指回数 | 269 | 184 | 124 | 165 | 161 | 276 | 369 | 220 | 213 |
| 同じ手回数 | 1274 | 912 | 1131 | 1214 | 970 | 1020 | 1093 | 1063 | 962 |
| UK economy will avoid recession despite no growth in February ※BBCニュース記事。特に意図はないです | |||||||||
| English | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 47.06 | 62.61 | 64.84 | 61.84 | 64.19 | 60.32 | 52.72 | 62.02 | 66.55 |
| 移動距離(cm) | 12062.9 | 7542 | 6729.9 | 6873.6 | 81 | 7574.6 | 7585 | 7236.7 | 6795.9 |
| 同じ指回数 | 289 | 191 | 127 | 186 | 153 | 232 | 368 | 207 | 138 |
| 同じ手回数 | 1419 | 845 | 1231 | 1233 | 880 | 1035 | 1062 | 1047 | 897 |
| Apple Privacy Policy - PDF | |||||||||
| English | QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte |
| スコア | 47.97 | 63.2 | 65.81 | 61.38 | 64.12 | 59.33 | 53.32 | 60.66 | 62.95 |
| 移動距離(cm) | 74386.6 | 47234.3 | 40821.6 | 44627.4 | 51741.2 | 46991.7 | 46937.4 | 45183.2 | 41059.6 |
| 同じ指回数 | 1756 | 1137 | 868 | 1119 | 914 | 1642 | 2232 | 1571 | 1449 |
| 同じ手回数 | 8981 | 5472 | 7370 | 8229 | 6179 | 6751 | 7062 | 7165 | 6055 |
簡単に言えば日本語では大西配列、英語ではColemak配列が概ね1位であった。
肝心のEffive配列はというと、1位に着けたのはセブンイレブン社員行動規範のみで、他は大抵先ほど挙げた2つの配列に負けてしまうこととなった。日本人開発の配列で比べると、日本語ではAstarte以上大西未満、英語では大西以上Astarte未満のような微妙な立ち位置となった。悪く言えば帯に短し襷に長しである。
ちなみに無理やり12文章でのスコアを足してみると
| QWERTY | S. Dvorak | Colemak | Workman | Effive_6.0 | Tomisuke | Eucalyn | Onishi | Astarte | |
| スコア | 583.66 | 718.48 | 767.09 | 752.55 | 819.36 | 775.95 | 719.19 | 810.53 | 802.51 |
日本語でも英語でも大体2位をキープしていたこともあり、総合1位はEffiveとなった。とはいえ、今回選んだ12文章がたまたま良かっただけという可能性もある。比較する文章によってこの結果は変わってきそうである。結局どの配列が最もいいのか一概に言えない状況になってしまった。
結論こうだろう。
日本語と英語の使用バランスにより、向き不向きは変わってきそうだ。
また、日本人開発配列に限り、それぞれの特徴（効率を良くしている原因は何か）を軽くまとめたので以下に示す。
上表より、Effive配列は同指連打の抑制がかなりできている配列であると言える（少なくとも英語では。日本語を調べるのは諦めた。誰かやってくれないかな…）。これがEffive配列の強みのようだが、英語となればColemakがそれ以上に同指連打を抑えていることもしばしば。そのため何だかんだ英語ではColemakに勝てなかったりする。
Effiveの弱点は指の移動距離だと思われる。日本語で大西配列、英語でColemakそしてAstarteに勝てなかったりする理由を考えるにあたり、先ほどの12文章での比較を通して総合的に見てみると、Effiveが割と長距離移動になっていることが明らかになった。
またこの度、Effive_6.0の画像をいくつか作成したのでお好きなものを以下のフォルダから選ぶことができる。ダークモードでカラフルなやつはアスペクト比が16:9となっているので、壁紙に最適（まあそんな物好きはいないか）。
若干言い訳がましい部分もあったので記事が長くなってしまった。EffiveRomanなど入力方法関連をもう一つ別ページに回した。Effive配列の機能性の充実度をぜひ皆さんにご覧いただきたい。
