新配列と新ローマ字を考える話 - Effive配列とEffiveRoman（前）

出会い
新配列開発の過程

出会い

キー配列

今日も暇だな〜と思いながら最近始めたTwitterを開き、例の如くスマホ片手に寝そべる私。そんな中TLに流れたただ一つの記事が、全ての始まりだった。

ようやく完成。気づけば1時半を回りました。
色分けは諦めて一つ一つやったので、間違ったところあったら教えてくださいませ。
疲れたので考察は置いておいて、とりあえずQWERTYの圧倒的なゴミさが露呈する結果となりました。 pic.twitter.com/TOdFrr5QSL
— とみすけ (@_Tomisuke) 2022年7月9日

当時、QWERTY配列が決して打ちやすい配列でないということは何となく薄々知りながらも、数字で見るとこれほどまでに他と比べて酷いものなのかと衝撃を隠せなかった。

それに対してこの方はTomisuke配列という新しいキー配列まで考案し、他のものと比較した際の優位性を実証している。ぜひこのサイトも皆さんに見ていただきたいものだ。

tomisuke.hatenablog.com

ローマ字

ちょうど同じ頃、当時ハマっていたものにローマ字テーブルの開発があった。

私は、小学生時代からローマ字に興味を持っており、その熱意は小6夏の自由研究としてローマ字辞典を作成するほどのものであった。その後しばらく熱は冷めるものの、次は国際音声記号に興味を持ち、いつしか日本語の発音についても（素人ながら）考えるようになった。私は「ローマ字は実際の発音に忠実であるべきだ」という思想を抱き始め、自らローマ字表を作成した。

こうしたカスタマイズを柔軟にするのにGoogle日本語入力というツールがある。以下のサイトが大いに参考になったので載せておく。

pasokatu.com

ひらめいた

今まで紹介してきたこの「新しいキー配列」「新しいローマ字」の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が最高なものだとは感じていなかった。まだどこかに効率を高める要素が絶対にあると思っていた。では一体どうすればさらなる飛躍を目指せるのか。それを考えるべく、今までの成績を振り返ってみた。

英語は不思議の国のアリス第1章、日本語は北越急行ほくほく線 Wikipedia記事

上記はあくまでも一つずつの文章での比較に過ぎないが、他の文章で比較した際も、傾向として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配列を上回ることができた。

強敵あらわる

もう私はこれでいいと満足していた。しかし、再びその思いは打ち砕けてしまう。それはこのサイトに出会ったときのことである。

note.com

この記事を読んで目を疑った。世界、いや日本だけですらこの配列界隈というのは広かったのだ。いままで日本語の最高峰だと思ってた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文章がたまたま良かっただけという可能性もある。比較する文章によってこの結果は変わってきそうである。結局どの配列が最もいいのか一概に言えない状況になってしまった。
結論こうだろう。

日本語と英語の使用バランスにより、向き不向きは変わってきそうだ。

また、日本人開発配列に限り、それぞれの特徴（効率を良くしている原因は何か）を軽くまとめたので以下に示す。

*e-Reader約930万文字に基づく二文字組合せの頻度ランキングのうち、同じ指に割り当てられている組合せトップ5をそれぞれ示した。順位が低いほど良い。

上表より、Effive配列は同指連打の抑制がかなりできている配列であると言える（少なくとも英語では。日本語を調べるのは諦めた。誰かやってくれないかな…）。これがEffive配列の強みのようだが、英語となればColemakがそれ以上に同指連打を抑えていることもしばしば。そのため何だかんだ英語ではColemakに勝てなかったりする。

Effiveの弱点は指の移動距離だと思われる。日本語で大西配列、英語でColemakそしてAstarteに勝てなかったりする理由を考えるにあたり、先ほどの12文章での比較を通して総合的に見てみると、Effiveが割と長距離移動になっていることが明らかになった。

またこの度、Effive_6.0の画像をいくつか作成したのでお好きなものを以下のフォルダから選ぶことができる。ダークモードでカラフルなやつはアスペクト比が16:9となっているので、壁紙に最適（まあそんな物好きはいないか）。

drive.google.com

若干言い訳がましい部分もあったので記事が長くなってしまった。EffiveRomanなど入力方法関連をもう一つ別ページに回した。Effive配列の機能性の充実度をぜひ皆さんにご覧いただきたい。

3kyoson.hatenablog.com