2000年6月アーカイブ

(2000-06-12)

「漢ナビ2」について

 「漢ナビ2」は、「漢ナビ」に、漢直と“速記入力”の組み合わせという新しい入力方法を導入した大幅な改訂版です。漢直と速記を組み合わせようと考えた経緯については、「G-Code」で速記をのページを御一読ください。

 今はまだ構想を練っている段階ですが、随時、このページで途中経過を公表していきます。


“熟語補完”の拡張で“速記入力”

 「漢ナビ」には“熟語補完”という機能がある。これは、漢字の最後のキーをシフトしながら打つと、その漢字の後に続く漢字のグループを仮想鍵盤に表示するというものだ。仮想鍵盤に表示された漢字は1打鍵で入力できる。このときもシフト打鍵すると、さらに次の漢字グループが表示される。

 補完できる漢字はあくまでも1字ずつだ。熟語補完を使って「漢字」を入力しても、次に「直接入力」が1打鍵で入力できるというようなことはない。これは漢字の第1打鍵を覚えるための補助的な機能だから仕方ないけれども、ちょっと不便な感じもする。

 スペースとの同時打鍵を第1打とする2ストロークを“速記入力”に利用しようと考えていたときに、このことを思い出した。

  1. 2ストロークの“速記入力”を覚える場合も、打鍵ガイドを表示した方が便利だろう
  2. 打鍵ガイドの表示タイミングは、スペースを押し下げた時が適当だろう
  3. スペースを押したまま候補を選択した場合は、その後に続く仮名文字列のグループを表示してはどうか
  4. それならば、単漢字や熟語を打った後にスペースを押し下げた場合にも、それに続く仮名文字列の候補を表示するのが自然だ
  5. 候補が多いときは、スペースを再度打って次の面に進めばよい
  6. 打鍵ガイドを見なくても入力できるように、同じ文字列は同じキーに割り当てるべきだ
  7. 一定の文字列が常に同じ打鍵で確定するのだったら、わざわざ2ストロークにする必要はない

 こうして、“熟語補完”の拡張(超多段シフト的な操作方法)で“速記入力”ができるという考えに至った。

辞書の内容

 以下のような6種類の変換を行うための辞書が必要だ。

  1. 漢字文字列→漢字文字列群
  2. 仮名文字列→漢字文字列群
  3. 漢字文字列→仮名文字列群
  4. 仮名文字列→仮名文字列群
  5. 空文字列→仮名文字列群
  6. 仮名文字列→打鍵位置

 1と2は接頭語から変換する場合や漢字文字列を一気に補完する場合、5は接続詞や副詞などを単独で入力する場合に使う。

 1~5は、任意の文字列から任意の文字列(群)に変換する辞書に統合できる。この辞書の中に打鍵位置も入れておけば、6の変換を個別に行う必要がなくなって変換時間を短縮できる。

ドライバの動作

 ドライバは、以下のような動作を行う。

  1. スペースが押されたら、IMEの未確定文字列を検索用のキーにコピーする
  2. キーを使って検索し、候補群(文字列群と打鍵位置)を受け取る
  3. 仮想鍵盤に候補群を表示する
  4. 文字キーが打鍵されたら、該当する文字列を確定入力する
    (スペースが押された状態なら、確定した文字列をキーにコピーして2へ)
  5. スペースが押されたら、次の候補群に進める(3へ)

 本当は「取り消し」や「前候補群」などの処理も必要だが、細かい説明は省略した。また、候補群の数は仮想鍵盤8面程度、文字列の長さは5文字程度までに制限しておいた方がいいだろう。

(2000-06-12)


付記

 Windows XP が出たころからWindows用のIMEがどんどん減っていき、95~Meとは全く別のXPに「漢ナビ」を移植するのも難しそうだったので、この数年間はJava用のInput Methodをコツコツと作っています。

 もちろん、最初から漢直を前提とした仮名漢字変換方式で、これまで考えてきたような“速記入力”にも対応しています。Input Method本体と仮名漢字変換辞書と“速記入力”辞書を並行して作っているわけですが、まあだいたい「こんなものを作ろうとしています」という感じを伝えるためのサンプル版ができたかな、といった段階です。

 このJava用のInput Methodと“速記入力方式”は、近いうちに公開したいと思っております。

(2007-10-07)


[ 「漢ナビ」 | 漢字直接入力 | m(as)m's home position ]

(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-codeTUT-code超絶技巧入力などの2ストローク系漢直と自由に組み合わせて使えるようにするわけだ。

今後の計画

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

(2000-06-12)


別の方法

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

(2001-09-10)


[ (裏話) | (目次) | 錬金術師の実験室 | m(as)m's home position ]

カレンダー

<   2000年6月   >
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

最近のツイート

最近のブログ記事

最近のコメント

このページについて

このページには、2000年6月に書かれたブログ記事が含まれています。

前のアーカイブは2000年2月です。

次のアーカイブは2000年8月です。

最近の記事はメインページで、過去の記事はアーカイブで閲覧できます。

Creative Commons License
このブログはクリエイティブ・コモンズでライセンスされています。
Powered by Movable Type 4.261