過日、某ブログで興味深い記事を発見しました。ブログの作者はkenichiro_ayakiさんという方で、ブログ名が「紅皿のサポートブログ」、名前からわかるようにキーボード配列エミュレーションソフトウェア「紅皿」、作者さんのブログです。わたしはあまり他人のブログやSNS発信には目を通さない人なので、記事が書かれた2023年8月12日から1年近くこの記事の存在に気づきませんでした。記事の内容はタイトル通り親指シフト関連の特許出願について作者さんが調べたものですが、私にとってはとても有益な情報でした。本来の親指シフト(つまりOASYSの親指シフト)を実現したロジックが、原資料によって明快に解き明かされた点が大きいと思います。表記を変更してみる2000年NICOLA規格の状態遷移表が正しかった先か後かでなぜ違う?衝撃の画像を発見してしまった件キーボード同時打鍵シフト処理方式ということで今回は「紅皿のサポートブログ」で教えていただいたいくつかの資料のなかで、1985年に特許を取得した「キーボード同時打鍵シフト処理方式」特公平6-82314号を取り上げます。これを取り上げた理由は他の資料より文章が全体的に平明でわかりやすいと感じたからです。ロジカルに説明してあるので直接読んでもらったほうが早いくらいなものですが、ここでもポイントだけ取り上げたいと思います。62-37405号(昭和53年(1978年)出願)などにも、基本的には同じことが書かれています。同時打鍵判定の仕組みまず[概要]の冒頭から(この発明は)「シフトキーを含むキーボードのキーを同時に打鍵した場合、シフトキーがきくキーときかないキーを判断し処理する方式」と、いきなり明快に始まります。そのあと現状のシフト方式の問題点と、同時打鍵シフト方式の優れた点が平明な文章で過不足なく説明してあります。親指シフトと表記せずに同時打鍵シフトと書いてあるのは、従来の(古典的な)Shiftキーと比較したい意図があったのか、あるいは日本語ワードプロセッサOASYSの場合ふつうの(小指を使う)シフトキーにも同時打鍵の機能をもたせ半濁音入力を行う仕様だった(はず)なので、より汎用的な言い方に変えたのか、といったところでしょうか。親指シフトであることが強調されています。「親指以外の他の指で該文字キーを操作するのと同時に該指と同じ側の手の親指で操作できるように上記文字キー下方位置のキーボード上にシフトキーを配置し」と、親指シフトとは文字キーと同じ側の親指キーを同時打鍵するキーボード、つまり同手シフトを使った入力方式であることが明言されています。古事記によると、まず天地のはじまりに天之あめの御中主みなかぬしの神が高天原にあらわれた、とあります。親指シフトにかんして言えばまずはじめに同手シフトを軸とした入力スタイルが生まれ、それをあらわす器として親指シフトキーボードが創られた、という経緯だったようです。このサイトでも幾度となくお伝えしていますが、ヒトが物を掴むときの動きをタイピングに持ちこんだ同手シフト、親指シフトは究極これにつきると思います。特許情報プラットホームの特公平6-82314号「キーボード同時打鍵シフト処理方式」を開くと「詳細な説明」の項目のなかに親指シフトの実施例を示す図と表が掲載されています。(14)の部分が親指シフト判定の決め手、3キー分岐処理です。(14)の場合、T1はB3のキーが押されてからB2のキーが押されるまでの間、T2はB2のキーが押されてからB1のキーが押されるまでの間を示し、T1>T2の場合B3のかな文字キーがB2のシフト付きで出力され、T1<T2の場合はB3のかな文字キーが出力後B1のかな文字キーがB2のシフト付きで出力される。単純に、ここは記述ミスではないかなあ、と思えます。新たにキーが押下されるたびにその内容はシフトされ、最新の押下データを常にバッファB1に入れるように構成される。あるので、上の文章をまともに解釈すると、文字キーと親指キーの組み合わせのうち押した時間差の短いほうが「シフトなし」になってしまいます。正しくはT1<T2の場合B3(=先に押したキー)のかな文字キーがB2のシフト付きで出力され、T1>T2の場合はB3のかな文字キーが出力後B1のかな文字キーがB2のシフト付きで出力される。同時打鍵ステートマシンの説明」などを参照してください。キーの押し上げ処理がないところで第一表ですが、いきなり「あれれ?」と思ったことがありました。それは何かというとキーの押し上げ処理がない、ということです。文献には以下のような記述があります。以上、という感じで処理するイベントのなかにキーの押し上げ処理がないんです。たしかにキーの押し上げ処理がなくても、理屈上は親指シフトを実現できます。文字キーを単独打鍵のつもりで押して、かつタイマー動作中(200mSec以内)に親指シフトキーを押した(同時打鍵になった)としても問題はありません。親指シフトキーを単独打鍵することはない建付けなので、(あきらかなミスタイプでさえなければ)通常は上述した「3キー分岐処理」に移行することになるからです。結果、ノンシフトタイム>シフトタイムが成立して意図した通り最初に押した文字キーの単打が成立します。謎のタイムアウト処理じつはこれで長年の謎が溶けた気がしました。2000年NICOLA規格の状態遷移表にあるタイムアウト処理、ずっとひっかかっていたのです。タイムアウト処理を入れた意図がいまひとつわからないなあ、という感じだったのです。なにを言っているのかというとタイムアウト処理不要論、というのがけっこうむかしからあったのですよ。曰く、キーのリリース処理をしているんだからタイムアウト処理なんて不要である。無意味なだけでなく、タイマーを短く設定しすぎると同時打鍵の判定精度を悪化させてしまう。タイムアウト処理はない方がいいんじゃないか、云々。理屈上はたしかにそのとおりだと思います。問われたら「理屈の上では必要ありません」というのが原則的な答えになります。謎のタイムアウト処理だったのですが、原資料を目にしてようやく理由がわかりました。キーのリリース処理をしているんだからタイムアウト処理なんて不要であるが正論ならばタイムアウト処理をしているんだからキーのリリース処理なんて不要であるという理屈も成り立ってしまうからです。NICOLA規格の状態遷移表でタイムアウト処理が記載されていたのは、第一表を基準にした処理を引き継いたときのなごりだったのだろうと想像がつきます。ちなみにですが私自身はタイムアウト処理不要論を採りません。タイマーが適切な時間にセットされていたら、「キーを押したときにキーを押した気分を味わえる」という演出効果は期待できると考えているからです。NICOLA規格ではタイマーを100msecに設定しています。個人的にはもう少し短くしてもセーフだと思いますが、個人差が現れる部分であり、ここにこだわるのは本質ではないので当サイトも100msecを「押しの設定」にしたいと思います。表記を変更してみるところで第一表は数字やアルファベットだけなのでちょっととっつきにくい感じもしますね。そこで表の構成はそのまま(ただし右側はカット)で表記だけを書き改めたものが以下の表です。第一表をNICOLA規格の状態遷移表の表記に合わせてみた2000年NICOLA規格の状態遷移表が正しかった第一表を「親指シフト・いんぷりめんと」のページにある状態遷移表(2000年NICOLA規格と同等な表)とくらべたらどうでしょうか。キーリリース処理以外にも、細部において若干の違いはあります。NICOLA規格の状態遷移表では、親指キーセット状態でタイムアウトなら原則「出力あり」ですが、第一表の場合は(ワープロ専用機OASYSの処理なので)もちろん「出力なし」です。これはどちらでもかまいません。親指シフトの処理は「シフトキーを含むキーボードのキーを同時に打鍵した場合、シフトキーがきくキーときかないキーを判断し処理する方式」だからです。文字キーが押されたときのシフト有無を判定しているだけなので、文字キーが押されていないときに親指キーの単独打鍵を認めるかどうかは判定に影響しません。親指キーが押された状態で文字キーが押されたら即同時打鍵確定、シフト側の文字出力...(10)。それとは逆に、文字キーが押された状態で親指キーが押されたら確定、文字出力はせずに文字キー親指キーセット状態へ移行...(7)。その状態でタイムアウト(もしくはキーの押し上げ)は同時打鍵確定、シフト側の文字出力...(13)文字キー親指キーセット状態で新たな文字キーが押されたら3キー分岐処理...(14)どちらの処理も共通していることがわかります。現在は別の内容に書き変えられてしまいましたが、かつて日本語入力コンソーシアムの公式サイトで参照できた2000年NICOLA規格・状態遷移表こそは本来の親指シフトであり、富士通がコンソーシアムに公開した技術の中核をなすものだと考えていました。今回まさしくそのとおりであったことが確認できました。先か後かでなぜ違う?ところで第一表において、親指キーが先に押されたときと、後から押されたときとで、処理が異なる点に「あれ?」と思われた方もいるかもしれません。同時打鍵は確定しません。親指キーが先に押されて同時打鍵になったとき文字キーが押された段階で即、シフト側の文字が確定し、出力。同時打鍵が確定します。親指キーが先に押されたか後で押されたかで処理が違っていますね。ここの部分で「なぜに?」と疑問に感じる方がおられるようです。ここは「なぜに?」で済ましておかずに一歩前に踏み出してしまいましょう。いうことで「試験に出る親指シフト」、補足です。親指キーが先に押されたか後から押されたかでで処理が違ってしまう理由、それは親指シフトにおいては親指キーが基準、指標だからです。丁寧に言うと親指シフトキーを押した時間を基準として、「シフトキーがきくキーときかないキーを判断し処理する」からです。既出ではありますが、親指シフト同時打鍵判定のかなめ、3キー分岐処理の図をあらためて出しましょう。文字キー、親指キー、文字キーの順番で3つのキーが同時に押されたときの処理です。親指シフトキーが押された時間を基準点として、文字キー・オンから親指キー・オン、あるいは親指キー・オンから文字キー・オン、という組み合わせのうち時間差の短い方を「シフトあり」にする処理です。親指シフトキーが先に押された場合には基準軸が(下図でいうと)左端に移ります。最初に親指シフトキーが押され(ここが基準点)、つづけて文字キーが押されて同時打鍵になるまでの時間をXとするならば、Xよりも短い時間差で親指キーと他の文字キーの同時打鍵が成立することは理屈上ありません(分岐処理の条件が成立しません)。この段階で「シフトあり」が確定し、文字出力へ、となります。ちなみに、仮にこの段階でウェイトをかけてしまうと、その後の処理によっては「ゴールポスト(指標)を動かす」結果につながる可能性が出てきます。具体的には「確実にシフトしているはずなのにシフト側の文字が打ち込めない」みたいなことになりえます。なると、もはや親指シフトという仕組みそのものの破綻といえます。親指キーが先に押されて同時打鍵になったときにはウェイトは掛けずに即、確定してシフト側の文字を出力します。これが親指シフト、開発陣が特許を取得した技術です、というより、実務の現場で数字(実績)をだしてきたワープロ専用機OASYSの親指シフトなんですね。いえ親指キー先押ししたときの考え方としてはむしろシンプルと言えるかもしれません。シフトキー押しながら文字キー打ったんだから「シフトあり」にするよ、と言っているだけなので。ある意味「コロンブスの卵」、でしょうか。それにしても最初にこの仕組みを考えついた人って「冴えていたなあ」と思います。いうことでこの歴史に埋もれつつある技術を使って親指シフト再生、超スローペースの当サイトもぼちぼち実装編に移行するフェーズかなあと考えています。あいも変わらずのマイペースは今後も変わりませんが。紅皿のサポートブログ、前述の記事には「オラびっくら仰天しただよ」と言いたくなるような画像が掲載されていたのでした。PDFの方を開くとこの画像が出てきます。親指シフトキーボードのプロトタイプです。なんと、親指シフト配列は50音配列だった!エクスクラメーションマークを27年に一度くらいしか使わないわたしが使ってしまいましたが、じつはその話ではありません。神田泰典さんの著作「コンピューター知的道具考」(NHKブックス)のなかにも50音配列のキーボードのイラストが掲載されていたので、それ自体は知ってはいたのです。厳密に言うと「コンピューター知的道具考」のイラストと上の画像では「かな」の配置は違いますが、どちらも50音配列であることは共通しています。親指シフトが50音配列であったことは知っていたよ、という方もいらっしゃるでしょう。驚いたのは「コンピューター知的道具考」のイラストにはなかった部分です。専用の濁音シフトキーがついているのですよ。ついているだけでなく、原文を読むとどうやら濁音もキホン同手シフトで打つ構成のようなのです。知らない方のため念のために説明しておくと、親指シフトというのは基本的に文字キーと同じ側にある親指シフトキーを同時打鍵することでシフト側の文字を入力します。それに対して濁音は文字キーとは反対側の親指シフトキーを同時打鍵することで打ち込みます。ハンムラビ法典の定め。ところが私はNICOLA配列に少々手を加えただけではなく、濁音を専用の濁音シフトキーを使って同手シフトで打ち込んでいるのです。親指、それなりに暴れます。親指が暴れても私にはこのやり方のほうが快適なのですが、正統派NICOLAユーザーさんから見たらおそらく看過できない所業でしょう。濁音を同手シフトで打ちこむなどは邪道の果ての邪道、「ヒトとしてどうなのよ」的な背徳行為、こ奴を許すまじと全国の親指シフターさんから石もて追われ放浪する身に成り果てたと思い込んでいた矢先にこの画像と遭遇したのです。これが驚かずにいられますかっていう話です。ちなみに私の濁音シフトキーのポジションは上の画像とまったく同じだった時期もありましたが、現在は画像とは異なりメインのシフトキーの外側に設定しています。正規の親指シフトキーボードのほうはその後濁音シフトキーを取り去ってしまうことになります。その理由は親指が連続して異なるキーを打つことを避けたのか、それとも富士通の主要な納入先が官公庁や大企業なので通常のキーボードと極端に違う構成を避けたのか、といったところでしょうか。親指シフトキーと濁音シフトキー、親指で押すシフトキーがふたつもあったら、さらにそれとは別に[Space]キーや[変換]キー(もしくは文節区切りキー)なども確保しなければならず、「ふつうの英語キーボードに近いものを」という方針からは大きくかけ離れたハードウェア構成になってしまいます。(補足すると、現在のように[Space]キーを使って変換するという発想が出てくるのは1980年代以降の話です。詳しくは「ローマ字入力はいかにして鉄板になったか」を参照してください)親指シフトをデファクトスタンダードにしたいのであれば濁音シフトキーを取り去ったのは正解だったと私も思います。わたしが濁音を同手シフトで打ち込んでいるのは単なる思いつきではなく、数年の歳月を経て試行錯誤をつづけてきた結果これがいいと判断したからです。いって私のやり方が正しいと主張する気も、他人に勧める気もまったくありませんのでご心配なく、ウヒヒ。それにしても世界の果てまでやってきたと思っていたのにふと気がついたら故郷に戻っていた、という感じで今回の”衝撃の”経験はとても楽しく心躍る発見でもありました。Comments表示できるコメントはありません。