ANSI 30 キー・順次打鍵の理論下限 — 新月配列の並び替えはもう終わっている

順次打鍵には計算できる下限がある

「ANSI 30 キー・順次打鍵」という条件のかな配列を、どこまで速くできるのか。この問いには、打鍵数の下限がはっきり計算できます。

標準 ANSI キーボードの英字 3 行は 30 キーです。前置シフト方式では、そのうち 1 キーをシフトキーに使うので、1 打鍵で打てるかなの枠は 29 個になります。残りのかなは「シフト → 文字」の 2 打鍵以上です。

公開コーパス（青空文庫『こころ』『坊っちゃん』+ Wikipedia 10 記事、150,024 かな）で頻度上位 29 のかなを数えると、全体の 72.7% を占めます。したがって理論下限は次のとおりです。

1 打 × 0.727 + 2 打 × 0.273 = 1.27 打/かな

参考までに枠数を変えると、28 枠で 1.29、30 枠で 1.26。この「1.27」前後という数字は、配置をどう工夫しても順次打鍵・30 キーでは越えられません。

（同じコーパスの頻度上位 29 は、いんうしたのかとにはてくなきっる、こ。せがでょをつすもじあです。句読点が上位に入る点に注意してください。）

新月配列はどこにいるか

同じ数え方（前置シフトを 1 打として数える）で、新月配列と月系配列を並べます。

配列	打鍵/かな（公開）	打鍵/かな（私的）	使用キー	備考
理論下限（29 単打枠）	1.27	—	30	計算値
月見草 v2	1.22	1.21	31	後置 3 キーが、。・を兼ねる（後述）
ぶな v2.0	1.25	1.25	33	がだでを単打。3 打のかなが無い
月配列 K	1.26	1.26	40	数字段にかなを追加
月配列 5-532	1.27	1.25	32
月配列 5-315	1.27	1.26	32
月配列 5-680	1.27	1.27	32
朧月	1.29	1.29	31
月林檎	1.29	1.27	36	中指後置シフト
月配列 3-226	1.30	1.31	32
月配列 2-263	1.30	1.30	33	ちれ・を JIS 余剰キーに
月配列 U9 完成版	1.31	1.31	32
ミズナラ	1.31	1.31	32
中指シフト月光	1.31	1.31	32
月配列 T	1.32	1.33	32
月配列 4-698 幸花	1.32	1.32	32
新月 8.6（analyzer 版）	1.33	1.33	33
新月（現行）	1.34	1.34	32	単打面は 2-263 と同一

（この表の打鍵/かなは eswai keyboard_analyzer 互換の数え方によるもので、56 方式ベンチマークの表とは丸めの位で 0.01 程度ずれることがあります。）

新月配列は、この表の中でキー数が最少に近く、打鍵数は最多です。 ただし理論下限 1.27 との差は約 5%、月配列 2-263（1.30）との差は約 3% しかありません。順次打鍵・30 キー前後の配列は、全部が下限から数 % の帯に固まっています。

月見草の 1.21〜1.22 について

表で唯一、月見草だけが理論下限を下回っています。これは「後置シフトの 3 キーが、（読点）。（句点）・（中黒）を兼ねる」という設計によるもので、「か、」のように文字の直後に読点を打つ並びが打てず、確定操作で解決する前提になっています。この確定操作を 0 打と数えているため、下限より小さい値が出ます。実効の打鍵数はこの帯に戻ります（見積もりで 2% 前後）。

既製の月系 10 配列を総当たりしても下限には届かない

「新月より速い順次打鍵配列が既にあるのでは」という疑問に答えるため、これまで未評価だった順次打鍵 10 配列（月 3-226 / 4-698 幸花 / 5-315 / 5-532 / 5-680 / 朧月 / ミズナラ / 中指シフト月光 / 月 T / U9 完成版）を配列 wiki と大岡俊彦氏の月配列一覧から定義して計測しました。

結果は上の表のとおりで、月見草（1.22）を下回るものは 1 つもありませんでした。最良の 5-532 / 5-315 でも 1.27（ぶな並み）です。

推定時間で見ても、これら 10 配列はすべて新月 ANSI30 案（1.815〜1.825）より後ろでした。詳しくは 56 方式ベンチマークを参照してください。

新月の構造を 30 キー内で無制限に組み替えたら

もう一方の攻め方として、新月配列の構造（前置 2 面 + 濁点後置）を保ったまま、30 キー内で配置を無制限に組み替える 探索を行いました。

探索の条件

使用キーは q〜p / a〜; / z〜/ の 30 キーのみ。物理 - [ ] は一切使わない（現行の新月は 32 キー使用）
★ = 物理 d / ☆ = 物理 k / ゛= 物理 l に固定。順次打鍵のみ
「」を空いていた ★, / ★. に、ーを ★; に収める
濁音 = 清音 + ゛ / 半濁音 = + ゛゛ / 小書き = 親 + ゛（例外なし）
変更予算は無制限、目的関数は推定時間/かなのみ
16 シード × 30 分 × 3 モード
学習は私的コーパス（9.2 万かな）、検証は公開コーパス（15 万かな）

結果

案	キー	学習時間/かな	現行比（学習）	検証時間/かな	現行比（検証）	月見草比	打鍵/かな	変更数
現行の新月	32	1.914	—	1.888	—	+4.7%	1.36	0
ANSI30（効率のみ）	30	1.810	−5.4%	1.839	−2.6%	+1.9%	1.41	43
ANSI30（でを単打）	30	1.809	−5.5%	1.823	−3.5%	+1.0%	1.39	48
ANSI30（ぶげを単打）	30	1.802	−5.8%	1.833	−2.9%	+1.6%	1.39	50
月見草 v2（参考）	31	—	—	1.804	—	—	1.22	—

30 キーに閉じて全面的に組み替えても、検証コーパスでの改善は −2.6〜−3.5% でした。 月見草との差は 1〜2% に縮まり、月見草の句読点衝突（実効 2% 前後）を考えれば実質は並びます。

ただし 43〜48 か所の入れ替え が必要で、現行の面影はまったく残りません。「覚え直しの費用に対して 3%」という取引です。

学習と検証のギャップ

学習コーパスで −5.4〜−5.8% だった改善が、検証コーパスでは −2.6〜−3.5% に落ちています。差は私的文章への過学習 です。しかも学習で最良だった案（ぶげ単打、学習 −5.8%）が検証では 3 案中 2 位（−2.9%）で、案どうしの 1〜2% の差はこの誤差の中に沈みます。

小さい変更予算での探索でも同じ傾向でした。

変更数	学習現行比	検証現行比
4	−1.8%	−1.3%
8	−2.8%	−1.4%
13	−3.5%	−1.7%
20	−4.5%	−1.6%
48	−5.4%	−2.3%

変更数を 4 から 48 に増やしても、検証での改善は −1.3% から −2.3% にしか伸びません。

低頻度のかなで見えた 3 つの落とし穴

1. 最適化器は打鍵数を増やしてでも労力を減らす

現行の新月は 1.356 打/かなですが、最適化された案はどれも 1.38〜1.41 打/かなと打鍵数が増えています。それでも推定時間は下がる。最適化器は「小指・下段・同指連続を避けるためなら、打鍵を 1 回増やしてよい」と判断しています。打鍵数の最小化と時間の最小化は別物です。

同時に同指指標が改善しています（現行 SFB 5.3% / SFS 9.8% → 案では SFB 2.7〜3.5% / SFS 6.7〜8.3%）。時間の改善の実体は、打鍵数ではなくここです。

2. 濁音を単打に格上げしても、得が出るのは一部だけ

「頻出する濁音を単打にすれば速くなる」と考えたくなります。実際に探索器へ「濁音を最大 3 個まで単打枠に置いてよい」と許可したところ、選ばれたのは ぶとげ でした。頻度上位ので・が・じは選ばれていません。

理由は明快で、得が出るのは「基底のかながシフト面にあって 3 打になっている濁音」だけ だからです。で・が・じの基底（て・か・し）は単打なので、濁音でも 2 打で済んでおり、単打に格上げしても 1 打しか減りません。一方ぶ・げの基底（ふ・け）はシフト面にあり、3 打から 1 打へ 2 打減ります。

なお 3 個目（ぜ）の寄与は 0.04% で、実質ゼロでした。

3. 「小指と下段は重い」という仮定が改善の正体

重みセットを 5 通り振ると、キー労力を平坦にした条件（E 平坦）では全案が現行より +0.2〜+0.8% 悪化 します。

案	交互 1.0	既定	E 平坦	小指 2.4	同指 2.0
ANSI30 効率のみ	−5.0%	−5.4%	−0.4%	−4.8%	−6.2%
ANSI30 で単打	−5.2%	−5.5%	−1.1%	−5.6%	−6.1%
ANSI30 ぶげ単打	−5.5%	−5.8%	−1.6%	−5.5%	−6.4%

つまり得られる改善の大半は「小指と下段は重い」というモデルの仮定に依存しており、遷移（交互・同指）だけでは現行を超えられません。

短縮符号を足しても 2% に届かない

配置の並び替えではなく、「2〜4 かな連続を 1 符号で打つ」短縮符号でどこまで縮むかも試算しました。

枠	個数	学習コーパスでの節約	公開コーパスでの節約
3 打の空き枠（現行規則内）	20 / 41	−3.2% / −5.1%	−0.7% / −1.7%
2 打の同手前置（規則を破る仮定案）	20 / 26	−5.5% / −6.6%	−3.8% / −4.3%
規則で作れる族「拗音 + う」	15〜17	−0.6% / −1.5%	−0.9% / −2.2%

学習コーパスで上位に来る短縮は、その人固有の頻出語ばかりで、公開コーパスでは効果が 1/3 に落ちます。両方で安定して効く語はわたし・よう・じょう・せい・ゅう・から・どう・んで・ほうの 9 語（公開コーパスで −3.2%）程度で、これも丸暗記が必要です。現行の規則内（3 打の空き枠）に収めるかぎり、公開コーパスでの節約は 2% に届きません。

結論: 配置の並び替えは終わっている

順次打鍵・ANSI 30 キーには 1.27 打/かな という理論下限がある
既製の月系配列も新月も、この下限から 数 % の帯に全部入っている（新月は 1.34、下限比 +5%、月配列 2-263 比 +3%）
新月の構造を 30 キー内で無制限に組み替えても、検証コーパスで −2.6〜−3.5%。しかも 43〜48 か所の変更が必要で、56 方式ベンチマークの基準では 有意差なし（同格グループ内の移動）
短縮符号を足しても、現行規則内なら公開コーパスで 2% 未満
改善幅の大半は「小指と下段は重い」というモデルの仮定に依存する

したがって 新月配列は現行のまま継続 という判断です。1〜3% の改善のために 40 か所以上を覚え直す価値は、少なくとも現在のデータでは示せません。次に伸びしろがあるのは配置ではなく、同時押し化・辞書化といった「打鍵方式そのものの変更」の側です。

参考: 新月配列 vs 月見草・ぶな — 順次打鍵の上位 3 つを比べる

データと再現方法

項目	内容
評価器	統一評価器 `evaluate.py`（Python）／最適化器は Rust 実装（`shingetsu_rs`）。時間モデルは両者で同一
コスト関数	キー労力 E（ホーム 1.0 / 小指 ×1.6 / 上段 +0.4 / 下段 +0.5 / 内側列 +0.5 / 数字段・周辺キー 2.2）× 遷移 T（交互 0.9 / 同指 1.6 / 同手 1.1 / はさみ +0.4）+ スキップグラム同指 + 指別負荷・左右差ペナルティ
打鍵の数え方	前置シフトを 1 打として数える（eswai analyzer の「動作」は前置を本体に束ねるため不採用）
学習コーパス	私的 92,082 かな（重複除去済み・内容非公開）
検証コーパス	公開 150,024 かな（青空文庫『こころ』『坊っちゃん』+ Wikipedia 10 記事）
探索設定	ANSI30 探索: 1 チェーン 1,800 秒 × 16 シード × 3 モード／変更予算つき探索: 1 チェーン 5,400 秒 × 6 シード
固定条件	★☆ と゛の位置、濁点後置、拗音 2 打、符号一意。★, / ★. / ★/ は記号用に予約
重み感度	既定 / 同指 2.0 / 交互 1.0 / 小指 2.4 / E 平坦の 5 セット
理論下限の計算	公開コーパスの頻度上位 29 かなが 72.7% を占めることから 1×0.727 + 2×0.273 = 1.2728
月系 10 配列の出典	配列 wiki および大岡俊彦氏の月配列一覧。月配列 2-263 の物理鍵・指配置テンプレートに `conversion` のみ差し替え。各配列表に明記のない濁点・半濁点・稀少仮名（ゔ・ゎ・ヶ・ゐ）は 2-263 の位置にフォールバック
測定日	2026-09-13

新月配列の定義データ・設定ファイルは GitHub リポジトリ（MIT）で公開しています。