「G-Code」で速記を

(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ストロークで仮名文字列を入力するやり方よりも優れている。

 文字列とキーの位置の関係は固定するが、スペースの打鍵回数は既入力の文字列によって変わるようにする。例えば単独の「思」と熟語の「意思」とでは全く異なる候補群になるからだ。できるだけ打鍵数を減らすという狙いもある。この点が、本家の「風」とは若干異なっている。

 もう一つの本家「POBox」との主な違いは、キーボード入力を前提にしていること、ユーザーの入力結果を学習しないこと、文節単位で個別に変換することだ。

 ここまでくると、G-Codeを拡張するだけでは勿体ない。そこで、「風」を見習って、前段階の入力方式には依存しないようにする。つまり、G-Codeだけでなく、T-codeTUT-code超絶技巧入力などの2ストローク系漢直と自由に組み合わせて使えるようにするわけだ。

今後の計画

 このようなわけで、辞書データと入力ソフトの開発を同時に進めなくてはならなくなってしまった。詳しいことは、「漢ナビ2」のページで引き続き検討する。

(2000-06-12)


別の方法

 「漢ナビ」のバージョンアップには時間がかかりそうなので、もっと簡単な方式を考えてみた。詳しくは「G-Quick」のページで。

(2001-09-10)


[ (裏話) | (目次) | トップページ ]