(2000-06-12)
G-Codeで速記するには
G-Code(に限らず、2ストローク系漢直)を使うと、漢字の打鍵数が少なくなった分だけ入力速度が上がる。しかし、現状のままでは速記できるほどではない。
速記するには、漢字仮名交じり文を分速300~350字で入力できる必要がある。これは、全ての文字を2ストロークで入力できると仮定しても、毎分600~700打鍵という超人的な打鍵速度に相当する。超人でない人が2ストローク系の漢直で速記しようとすれば、打鍵数を減らすしかない。
仮名入力が漢直共通の弱点
漢字が2打鍵で入力できるのはいいけれど、仮名の入力にも2打鍵以上必要になってしまうことが、2ストローク系漢直に共通する弱点だ。G-Codeの仮名配列は他の漢直ほどには最適化していないので、特にこの弱点が目立ってしまう。これは何とかして改善したいところだ。
また、漢直と仮名漢を併用していると、文節の先頭に変な仮名があってうまく変換できないことがある。例えば「目から鱗が」の「目」を直接入力した後に「からうろこが」をまとめて変換すると「目空鱗が」となってしまうのだ。これを防ぐには「から」を打った後に確定キーを叩けばいいのだが、ついうっかり忘れてしまう。
もしも「から」のような仮名文字列を2ストロークで“速記的”に直接確定入力できたら、どんなに快適だろう。つまり、漢字だけではなく、変換対象以外の仮名文字列(送り仮名や付属語など)も直接入力できるようにするわけだ。これは、本来の速記とは少し目的が異なるかもしれないが、試してみる価値はある。
利用可能な打鍵パターン
以前、親指シフトとG-Codeの組み合わせを試したことがある。仮名の入力を楽にしようと思ったからだ。親指シフトは普通通りに(無変換/変換キーを親指シフトキーとして)打鍵し、漢字はG-Codeで(第1打鍵をスペースと同時打鍵して)直接入力する。確かに仮名の入力は楽になったが、漢字の入力が少し重くなることと、G-Codeで仮名と記号を割り当てた中段・上段の左右交互打鍵が遊んでしまうのが難点だった。
この関係を逆転させて、G-Codeは元のままで、スペースとの同時打鍵を“速記的”な入力に流用してはどうだろうか。スペースとの同時打ちを第1打鍵として、2打鍵目で仮名文字列を直接入力するのだ。この方法ならば、本来のG-Codeを一切変更することなく、新しい2ストロークの打鍵パターンを追加することが可能になる。
割り当てる文字列の選び方
打鍵パターンが確保できたので、その打鍵パターンで入力する文字列を考える。実際に効果のある割り当て方をするには、使用頻度と入力コストのほかに、話し言葉と聞き打ちに特有の事情も考慮しなくてはならない。そもそも頻度を調べようとしても、どこで区切るのかを決めておかなくては、数えることさえできない。
例えば「しなければならないだろうというようなことも」というような極端に長い文字列を2ストローク化しても、実際には末尾の「ことも」を聞くまで打つことができず、待期時間が増えるだけだ。むしろ単純に「しなければ」「ならない」「だろう」「という」「ような」「ことも」のように、聞いた端から反射的に打っていった方が入力速度は上がるだろう。人間の作業記憶の容量が「7プラスマイナス2」と言われていることからも、適当な長さに区切ったものを数回に分けて打った方が入力者の負担は少なくなると考えられる。
たまたま手元に3,887,660文字分の国会の議事録のテキストデータ(漢字含有率は32.9%)があったので、2文字以上の仮名文字列がどの程度入っているかを調べてみた。その結果、90,711種類(テキスト全体の54.0%)の仮名文字列が抽出できた。
単純に頻度順に並べるだけでは実用的ではない(表1)ので、頻度と文字列の長さの積を基準にして(表2)、さらに別の文字列に含まれる場合を加算した(表3)。ついでに、漢字と仮名の組み合せを抽出したところ、246,078種類(80.0%)だった(表4)。
| (表1) | (表2) | (表3) | (表4) |
| 頻度 | 文字列 | 頻度*長さ | 文字列 | 頻度*長さ | 文字列 | 頻度*長さ | 文字列 |
| 8136 | その | 16272 | その | 1329488 | その | 13192 | 思います |
| 6578 | この | 13156 | この | 1309314 | して | 7830 | 非常に |
| 5201 | する | 13143 | これは | 926888 | つて | 7472 | 思うのであります |
| 4764 | から | 11439 | います | 733534 | には | 5467 | 考えております |
| 4761 | して | 10836 | につきましては | 495912 | これは | 5244 | 私は |
| 4381 | これは | 10585 | であります | 477750 | という | 4940 | 思いますが |
| 3813 | います | 10402 | する | 467584 | この | 4389 | 或いは |
| 3521 | つて | 9528 | から | 452739 | であり | 3948 | 次第であります |
| 2708 | として | 9522 | して | 426082 | する | 3459 | 対して |
| 2526 | には | 9196 | において | 401980 | において | 3327 | 対する |
| 2299 | において | 8922 | でございます | 359284 | について | 3156 | 関する |
| 2117 | であります | 8136 | それから | 329628 | まして | 3116 | 場合には |
| 2034 | それから | 8124 | として | 328431 | として | 3032 | 次第でございます |
| 1912 | について | 7648 | について | 300778 | これ | 2975 | 思つております |
| 1882 | そういう | 7528 | そういう | 299672 | から | 2925 | 思うのです |
| 1873 | いは | 7259 | におきましては | 253464 | ます | 2826 | 先ほど |
| 1660 | こういう | 7042 | つて | 219004 | そういう | 2628 | 思うのでありますが |
| 1598 | という | 6657 | うのであります | 218750 | では | 2582 | 申し |
| 1548 | につきましては | 6640 | こういう | 200103 | ついて | 2472 | 場合に |
| 1487 | でございます | 5788 | あるいは | 191346 | やはり | 2400 | 思うのですが |
本当に話す速度で入力できるのか
大雑把な見積りだが、1文字を平均1打鍵で入力できれば、分速300~350字も無理ではないだろう。
例えば、「短縮できるように」の「できる」と「ように」を、それぞれ2ストローク化すれば、8文字を8打鍵で入力できる計算になる。これは8文字中6文字(75%)が短縮できる場合だが、漢字が2文字増えて「短縮入力できるように」となると、短縮できるのは10文字中6文字(60%)となるため、「できるように」をまとめて2ストローク化する必要がある。
| (表5) |
短縮できる 部分の比率 | 短縮する 文字列の長さ |
| 100.0% | 2字 |
| 75.0% | 3字 |
| 66.7% | 4字 |
| 62.5% | 5字 |
| 60.0% | 6字 |
| 58.3% | 7字 |
| 57.1% | 8字 |
| 56.3% | 9字 |
| 55.6% | 10字 |
| 55.0% | 11字 |
| 54.5% | 12字 |
| 54.2% | 13字 |
| 53.8% | 14字 |
表5のように、短縮できる部分が少なくなるほど、長い文字列を2ストローク化しなければならなくなる。前記の議事録のデータのように短縮できる部分が54%しかない場合は、13~14文字を2ストロークで入力しなくてはならない。さらに減って50%以下になると、1文字平均1打鍵で入力するのは不可能になってしまう。
仮名文字列の長さは、平均すると5.4文字で、10文字以上続くことは滅多にない。本当に話す速さで入力しようとするならば、短縮できる部分を60%以上は確保しなくてはならない。そのためには、漢字を含む文字列(平均5.8文字)も、ある程度は2ストローク化する必要があるだろう。ただし、漢字の使用頻度は仮名に比べて分野や時期によるばらつきが多いと思われるので、注意しなくてはならない。
文字列の割り当て方
基本的には、「頻度*長さ」が大きいものから、打ちやすい順に割り当てればよい。しかし、共通点のある文字列をグループ化するなどして覚えやすくした方がいいだろう。また、漢字を含む文字列を割り当てる場合には、漢字のストロークとの関係も考えなければならない。
上・中・下段の30鍵の2ストロークなら900パターン、最上段を加えて40鍵の2ストロークにすれば1,600パターンになる。それでも足りなければ、第2打鍵もシフトして3ストロークに拡張するか、第1打鍵のシフトキーに「変換」や「無変換」も使うことで拡張できる。「だ」「である」「です」のような文体の違いを3個のシフトキーに振り分けるのもいいかもしれない。
2ストローク方式だけでは足りなかったら、坂元正剛さんの「新ワープロ速記法」のように略語変換を活用する方法もある。語頭や語尾のバリエーションが多いような場合、任意の長さの読みで登録できるのは都合がいい。G-Codeは平仮名と片仮名の打ち分けができるので、片仮名の読みで略語登録すれば、通常の仮名漢字変換に悪影響が出る心配もなくなる。ただし片仮名の入力にも2打鍵を要するため、本来の速さには及ばないだろうけれども。
今、基本的な900パターンの割り当てに取りかかっているが、これは予想以上に手間のかかる作業だ。最初の「その」にしても、「そのとき」「そのため」「そのような」「そのほか」「そのまま」「そのときに」などとの関連をどうするか、「その結果」のように抽出したデータには含まれていないものをどうするか、こんなことまで考え始めると、なかなか結論が出せない。この調子では、当分完成しそうにない。
(2000-06-10)
漢字だけなら追いつける
文字列の割り当てもできないうちに練習のことを考えるのも気の早い話だが、練習方法を視野に入れて設計することは悪いことではない。
ところで、(話し言葉でも書き言葉でも)日本語の文章中の漢字含有率が50%以上になることはほとんどない。普通は30~40%程度だろう。300~350字/分の30~40%といえば90~140字/分だから、通常の2ストローク漢直でも、漢字の部分だけなら話す速度で打てるということだ。
これは、聴き打ちの練習に応用できる。録音テープを聴きながら、漢字の部分を打てば漢直の練習、仮名の部分を打てば仮名2ストローク速記の練習になる。仮に漢字含有率が40%だとすると、漢字は40%の速度、仮名は60%の速度で打てればよい。これならば目標が高すぎて挫折するおそれも少ないだろう。また、何度も小刻みにテープを「停止→巻き戻し→再生」しなくてもよいし、録音せずに放送などを聴きながら練習することもできる。
打鍵ガイドへの応用
もっと面白い応用方法も考えられる。打った漢字をキーとして、その漢字の後に続く仮名文字列の候補を仮想鍵盤上に表示するのだ。
これは、G-Codeの“熟語補完”の延長だと考えれば分かりやすいかもしれない。“熟語補完”と同じように入力ソフトに依存することになるけれども、そういう機能を想定して仮名文字列を割り当てるのも悪くはないと思う。ある漢字を打った後にスペースを押すと、例えば図1や図2のような打鍵ガイドが表示されるようにする(図は説明のために適当に並べたものだが、実際は様々な条件を考えて調整する)。
(図1)「私」を打った後に表示するガイド(左手側)
+―――――+―――――+―――――+―――――+ +―――――+
| | | | | | |
+―――――+―――――+―――――+―――――+ +―――――+
|たち |たちは |どもも |としては | |から |
+―――――+―――――+―――――+―――――+ +―――――+
|からは |どもと |どもは |ども | |どもの |
+―――――+―――――+―――――+―――――+ +―――――+
|としても |どもに |のほう |には | |からも |
+―――――+―――――+―――――+―――――+ +―――――+
(図2)「思」を打った後に表示するガイド(右手側)
+―――――+ +―――――+―――――+―――――+―――――+
| | | | | | |
+―――――+ +―――――+―――――+―――――+―――――+
|いまして | |いますから|って |いましたが|うわけで |
+―――――+ +―――――+―――――+―――――+―――――+
|うのです | |うので |います |いますが |いました |
+―――――+ +―――――+―――――+―――――+―――――+
|われるので| |うが |われます |わない |えない |
+―――――+ +―――――+―――――+―――――+―――――+
ここで(スペースを離して)候補が表示されている位置のキーを打つと、該当する仮名文字列が確定入力されるわけだ。スペースを押したまま打鍵した場合は、その後に続く仮名文字列の候補群が表示されるようにする。
漢直+「風」+「POBox」
考えているうちに、冨樫雅文さんの「風」と増井俊之さんの「POBox」を合わせたように感じになってきた。この入力方法は、以下の点で、当初考えていたような2ストロークで仮名文字列を入力するやり方よりも優れている。
- 多様な仮名文字列を限られた打鍵パターンに割り当てる必要がない
- 候補となる仮名文字列が絞りこまれるため、規則性を導入しやすい
- スペースの打鍵回数とキーの位置だけを覚えればよい
- 漢字の2ストローク入力との干渉が起きにくい
- 打鍵数の削減によって入力速度の上昇が見込める
文字列とキーの位置の関係は固定するが、スペースの打鍵回数は既入力の文字列によって変わるようにする。例えば単独の「思」と熟語の「意思」とでは全く異なる候補群になるからだ。できるだけ打鍵数を減らすという狙いもある。この点が、本家の「風」とは若干異なっている。
もう一つの本家「POBox」との主な違いは、キーボード入力を前提にしていること、ユーザーの入力結果を学習しないこと、文節単位で個別に変換することだ。
ここまでくると、G-Codeを拡張するだけでは勿体ない。そこで、「風」を見習って、前段階の入力方式には依存しないようにする。つまり、G-Codeだけでなく、T-code/TUT-code/超絶技巧入力などの2ストローク系漢直と自由に組み合わせて使えるようにするわけだ。
今後の計画
このようなわけで、辞書データと入力ソフトの開発を同時に進めなくてはならなくなってしまった。詳しいことは、「漢ナビ2」のページで引き続き検討する。
(2000-06-12)
別の方法
「漢ナビ」のバージョンアップには時間がかかりそうなので、もっと簡単な方式を考えてみた。詳しくは「G-Quick」のページで。
(2001-09-10)
[ (裏話)
| (目次)
| 錬金術師の実験室
| m(as)m's home position
]