空飛ぶ親指シフト
文章創生のツール
試験に出る親指シフト

なぜ親指シフトは忘れ去られたのか

基準をなくした親指シフト

1980年代初頭には熱狂的なファンを軸に使い手が多かった親指シフト、いずれは日本語入力の標準になるのではないかとさえ言われたこともある親指シフト。

それも今では昔の話になってしまいました。

「デファクトスタンダードにはならなかったから」という趣旨のもと、2020年には富士通が40年間販売をつづけていた親指シフトキーボードからの撤退を表明しました。

じつをいうとこの部分にかんしては私も富士通の考えに同感ではあります。

親指シフトキーボードがデファクトスタンダード?

いやいや、それふつうに無理っしょ、とココロから思います。

富士通だからこそ2020年までつづけてこられたのであって、ナミの企業であれば前世紀の段階で手を引いていたのではないかとさえ、思います。デファクトスタンダードを目指すなら、という意味です。

それにしても……、

親指シフトキーボードは全盛期においてさえもマイナーな存在でしたが、現在はデファクトスタンダードどころかマイナーを通り過ぎて、世間からは忘れ去られた存在になってしまいました。

「しょせん親指シフトなんてその程度のものだったのさ」

という意見もあることでしょう。

そういう意見を100パーセント否定する気はありません。

ただ問題は「その程度のもの」である親指シフト、人によって違うものを指しているのではないかなあ、そう感じることが多い点です。

ブッポウソウ、というきれいな鳥がいますが、じつはべつの鳥の鳴き声とまちがえられて、この名がつけられたとか、

ぜんぜん違うものを指してブッポウソウ、とか、親指シフトとか言っている。

そんな感じ。

それをいうならば、私が親指シフトだと思っているものがじつはぜんぜん違うものだった、という可能性だってあるわけですね。

それを前提にしたうえで、

なぜ親指シフトはここまで忘れ去られたのか

というのが今回のテーマです。

私の意見は、

基準が崩れてしまったから

です。

というわけで「試験に出る親指シフト」

今回も心おきなく重箱の隅を突き、攻めてまいりましょう。

変換キー共有型NICOLAとは

変換キー共用型NICOLAってなんでしょうか。

NICOLAというのは、親指シフトを規格にした配列の名前だと、ざっくりと思ってもらって大丈夫です。

OASYS100Gのレイアウト
ワープロ専用機OASYSの親指シフトキーボード

そして変換キー共用型というのは、もともと物理的に別の存在だった親指シフトキーと変換キーを同じキーにしてしまおう、親指キーのポジションで変換もできるようにしてしまおう、という考え方から生まれた方式です。

富士通が最後に出した親指シフトキーボード・FMV-KB232もこの方式を採用していました。

FMV-KB232のレイアウト
親指キーと変換キーを共用するFMV-KB232

親指シフトのJIS化を目的に制定された、NICOLA規格の骨子ともなった手法でもあります。

さて、変換キーと親指キーを兼用して使うことになったとき、OASYSキーボードには存在しなかったひとつの問題が生じました。

それは

「素早く変換キーを押した時に、変換しないで同時打鍵が成立しまう。シフト側の文字が入力されてしまう」

という現象です。

これがローマ字入力であればそういうことはありません。押した順番に入力は決まりますから、変換キーを素早く打つと別の文字に化けたりすることは、(順番さえ間違えなければ)ありませんよね。

とうぜん親指キーを変換キーとして使ったときも、期待しているのは入力した文字を漢字かな混じり文に変換することです。

にゅうりょく【変換】 → 入力

みたいな。

ところが困ったことに、親指シフトというのは文字キーの先押しを認める入力方式です。

変換キー共用型の親指シフトでは

文字キーが離れないうちに親指キーが押されたら「変換」ではなくシフトが効いて

にゅうりょく【右親指】 → にゅうりょる

になるのです。

危険です。

前のキーが離されないうちに[変換]キーを押してしまうことはごくふつうにあるからです。

NICOLAの場合「く」のシフト側の文字は「る」です。

その場合、入力、とは入力できず、にゅうりょる、と入力することになるわけです。

きわめて危険です。

そこで

先に押した文字キーが離されないうちに親指キーを押したとしても、先に押した文字キーがすぐに離されたら親指キーの単独打鍵とする、という処理を取り入れることにしました。親指キーの単独打鍵とする、というのは正確な表現ではないのですが、要は、そういうことです。

それが変換キー共用型NICOLA固有の処理、「文字キーリリース処理」です。

文字キーリリース処理を図示

これによって変換したつもりなのに同時打鍵になってしまうという現象を回避できる確率が高くなりました。

ただいつでもどんなときでも、ローマ字入力とおなじタイミングで変換できるようになったわけではありません。

親指シフトだから、です。

いつでもどんなときでも、ローマ字入力とおなじタイミングで変換できるようにしたら、その時点で親指シフトする余地がなくなります。親指シフトという入力方式そのものが成立しなくなります。

ここに矛盾が発生します。

今度は親指シフト視点から、つまりシフトするつもりだったときに「文字キーリリース処理」がどう働くかをみていきましょう。

文字キーリリース処理を図示

上述のように本来の親指シフトキーボードならtime2のどこの時点で文字キーを離そうと同時打鍵(シフトあり)になるのです。

でも変換キー共用型NICOLAの場合は、time2の時間を切り取って単独打鍵(シフトなし)に割り当てています。

変換キーの押し下げを検知しやすくなったということは、逆にいうと

OASYSの親指シフトとくらべて

  • 本来なら同時打鍵なのに、タイミングによっては同時打鍵にならない、
  • シフトしているのに、タイミングによってはシフトにならない、

ということになります。

親指シフトの側に引き寄せて、操作の安定性という観点にフォーカスしてみると、これはあきらかに一歩後退ですね。

その一方で変換キー共用型NICOLAは、ハードウェアの選択肢が増えるのでOASYSの親指シフトとくらべて汎用性が高いという大きなメリットがあります。

ちなみにですが、文字キー押し上げの分岐点を変更したところで「正解」が出てくることはありません。

分岐点Xを伸ばしてやれば変換しやすくなり(同時打鍵しにくくなり)、逆に縮めてやれば同時打鍵しやすく(変換しにくく)なります。

ようするに

あちら立てばこちら立たず、中途半端、であることに変わりはありません。

「文字キーリリース処理」を取り入れている限り、理屈上は「親指シフト・マイナス」というほかはないのです。

変換キー共用型NICOLAは非実用的なのか?

変換キー共用型NICOLAは、OASYS方式にはない固有の処理、「文字キーリリース処理」を組み込んでいることを説明しました。

本来の親指シフト(つまりOASYSの親指シフト)では、親指キーと文字キーが同時に押された段階で、親指キーの単独打鍵になることは絶対にありません。

なぜか?

だってシフトしているんだから、です。

親指シフトの処理というのはキョクロン文字キーが押されたときのシフトありかなしかの判定(つまり二者択一)をしているだけであって、「うーん、ここはタイミング的にシフトキーの単独打鍵ですわ」みたいな要素が入ってきたら、感覚的にも、そして理屈としても変な話になってしまいます。

文字キーリリース処理を図示

ただ、上述したようにそもそも日本語入力コンソーシアム設立の背景が「変換キー共用型NICOLAの推進」にありました。そしてあくまでも親指シフトのデファクトスタンダード化を目指していた富士通も最終的に変換キー共用型NICOLAを選択していくことになるわけですが、良し悪しは置いといて少なくとも筋は通っていた、とは思います。

それならなぜ富士通は最後の親指シフトキーボードとして変換キー共用型NICOLAを選択したのでしょうか。

FMV-KB232のレイアウト
親指キーと変換キーを共用するFMV-KB232

まず汎用性の高さがあります。

変換キー共用型NICOLAは、ハードウェアの選択肢が増えるのでOASYSの親指シフトとくらべて汎用性が高いというメリットがあります。(ただ一部の方が主張するほど汎用性が高いわけではないですが、これにかんしては「ふつうの日本語キーボードで親指シフトしてはいけない、たったひとつの理由」に書いたので興味のある方は参照してみてください)

もう一つの理由が歴史的背景です。1980年代固有の政治・経済的な背景をもとに親指シフトの向かうべき路線が、1989年の日本語入力コンソーシアムの設立で定まった、というのが私の考えです。(具体的には「新JISキーボードの時代」とか「親指シフトは新JIS配列の夢を見るか」などに書きました)

社会全体としてみればまだまだ一部でしょうが、最近では自分好みのキー配置でキーボードを自作する、などという人たちも出てきました。しかし1980年代にはそんなことは夢のそのまた夢、親指シフトはただ富士通一社にすがるしかない、という感じだったのです。

OASYSのキーボードレイアウト

そこに登場したのがいわゆる親指シフトエミュレーターです。

富士通の親指シフトキーボード以外の「ふつうの」日本語キーボードで親指シフトできる変換キー共用型という発想は、とてもインパクトがあったのです。私も当時はぶっ飛びました。

変換キー共用型の考え方は好意的に受け入れられ、これを基軸として日本語入力コンソーシアムが設立されたのは上述のとおりです。

ただ理屈上は矛盾をはらんだ方式であることに変わりはありません。

黄色ライン

矛盾をはらんだ方式と書きましたが、それならば変換キー共用型NICOLAは実用性の低い入力方式なのでしょうか。

そうは思いません。

ふたつの点で変換キー共用型NICOLAは実用性を確保していると考えています。

まず第一にNICOLAは、同手シフト主体の入力方式です。

と、ここで「そうかあ、NICOLAは同手シフトだったのかあ」とパツンと膝を打って椅子から立ち上がり、腕組みをして心から納得できる方、あんまりいらっしゃいませんよね、きっと。

なので、ちょっとだけ説明します。

そもそも同手シフトとは?

ヒトがものをつかむ動き(の延長線上)で、親指とほかの指を同時に押して文字入力できたら自然だよね、というのが親指シフトキーボードの考え方です。

でもちょっと考えるとわかることですが、古典的なShiftキーだとうまく対応できないことに気がつきますよね。

同時のつもりで押しても、もし親指シフトキーではなく文字キーのほうが先に押されてしまったら、Shiftは効きません。うまくはいかないですよね。

じゃ文字キーが先に押されてもShift効いたことにしちゃえばいいんじゃね、というのが「同手シフト」の考え方なんです。

コロンブスの卵ともいうべき大胆な発想だと思います。ですが、もちろんこれで完全無欠・非の打ち所がない入力方式が誕生したわけではありません。

たとえば、シフトキーを押しっぱなしにして文字入力することはできない、といったウィークポイントも存在します。無理に押しっぱなしでの文字入力を有効にしてしまうと、シフトしていないにもかかわらずシフト側の文字が打ち込まれてしまう、という悲惨な結果が待ちうけていることになるからです。

でも、そういうウィークポイントと引き換えに得られる大きなメリットが、(打鍵の順序を気にしなくていいので)シフトキー押してる感が薄い、「かな」キーをダイレクトに打ち込んでいるような感覚(錯覚?)が得られる、ということになるでしょうか。

シフトキー押してる感が薄い、というのはあくまで主観レベルの話ですが、物理的に(時間的に)みると、こういう現象が見られます。

同時打鍵(同手シフト)した時と、逐次打鍵した結果としての「同時押し」、になったときの時間差を比較すると、前者のほうが圧倒的に間隔が短くなります。

同時打鍵と逐次打鍵の違い

つまり同手シフトの場合、下図のtime1が(意識しなくても)極端に短くなるのがふつうです。

文字キーリリース処理を図示

シフト側の文字を打った(つもりの)ときに
time1 ≧ time2 という式が成立してシフト側の文字が打ち込めない(文字キーの単独打鍵になってしまう)ことは、理屈の上ではありえても実態としてはほぼない、といえるのではないかと思います。

この点が、変換キー共用型NICOLAが実用性を獲得している理由のひとつ目です。

親指キーリリース処理はない

上述のように、文字キーが押されたまま親指キーが押されても、すぐに文字キーが離されたらシフトなしにする。結果として”変換”キーの押し下げを検出する、といいうのが文字キーリリース処理です。

文字キーリリース処理を図示

でもこれはあくまでも文字キーが先に押された場合であって、親指シフトキーが先に押されたときにはリリース処理などというものはありません。

親指キーリリース処理はない、のです。

ちょっと考えると親指キーの単独打鍵に意味を持たせているのだから、親指キーのリリース処理があってもいいのじゃないか、と思う方がいるかもしれません。

しかしこれをやってしまうと、シフトの否定になってしまいます。

親指キーは親指シフトキーです。

いまシフトキーを押しました。そしてシフトキーを離さないうちに文字キーも打ち込みました。

でもタイミングによってはシフトキーの単独打鍵とします、みたいなことを言われたら、

は? なにそれ? みたいな話ですよね。

下の表を見てください。

現在はべつの内容に書き換えられてしまいましたが(後述)、かつて日本語入力コンソーシアムの公式サイトで参照できた状態遷移表(2000年バージョン)は、親指シフト本来の処理を伝えるものだと考えてます。

同時打鍵遷移表

親指キーが押されている状態(3のOオン状態)で、文字キーが押されたら(文字Mオン)、その段階で問答無用にシフトあり(OM出力)が確定しています。

なのでリリース処理もへったくれもないわけです。

一方、変換キーを打ちやすくする、という視点からこの処理をみたらどうでしょうか。

親指キーリリース処理がなくても、やはり問題はないと思います。

これは個人的な意見ではありません。

変換キー共用型NICOLAを実装して親指シフトエミュレーターの代名詞ともいえる「親指ヒュンQ」、以下はそのインストールディレクトリにあるドキュメント「同時打鍵ステートマシン」からの引用です。

引用元 親指ひゅんQの「同時打鍵ステートマシン」より
引用元 親指ひゅんQの「同時打鍵ステートマシン」より

E33というのが親指キーを押しながら文字キーの打鍵を検知したときの処理です。

変換キー共用型NICOLAを実装していた親指ひゅんQでしたが、親指キーを押しながら文字キーを打ったらその段階でシフト側の文字確定…出力と、NICOLA規格2000年バージョンの状態遷移表と同じ処理をおこなっていることがわかります。

E33は親指シフト処理の根幹(のひとつ)でもあるのですが、その一方親指キーの単独打鍵を検知しやすくするという観点から見たときにも、

やはり問題はないことがわかります。

なぜならば「変換キー共用型NICOLA」だから、です。

変換キーを押して、その変換キーが離されないうちにあらたに文字キーが押されることは絶対ないと、もちろん言えません。

言えませんが、ふつうはないと考えてもおおきな差し支えはないでしょう。「押した変換キーが離されないうちに文字キーは押されない」と強引に仮定してしまっても、実用上大きな支障が出ることも、あるいは使いにくさを感じることも(常識的には)ないかと思います。

なので親指キーがほんのちょっとでも早く押された場合にはリリース処理は行いません。従来のOASYSが有する同時打鍵の精度がそのまま温存されるわけです。

黄色ライン

NICOLAが同手シフト主体の入力方式であること、そして親指キーリリース処理は行わないこと、このふたつの要素により変換キー共用型NICOLAは実用性を獲得しているのだと思います。

こうして見ていくと、親指シフトの操作性と親指シフトキーボード以外で使える汎用性、ふたつを両立させたという意味で、変換キー共用型NICOLAはむしろよく工夫された方式だとさえ思います。

だとしたら、

つぎのような疑問を持たれる方もいらっしゃるかと思います。

なにが問題なのか

じゃあいったい何が問題なのか?

富士通が親指シフトから撤退して、世間からも親指シフトの存在そのものが忘れ去られた観があるのに、今さら重箱の隅をつついてほんのわずかな差を針小棒大にとらえて、ことさらにネガティブな側面を強調することに、どんな意味があるの?

そんなふうな意見もあるかと思います。

重箱の隅であると同時に根幹の話でもあるから、というのが私の意見です。

富士通は、変換キー共用型NICOLAを指して親指シフトを改良したものだと発信してきたのでした。

じっさいには変換キー共用型NICOLAとOASYS方式(変換キー独立型NICOLA)はそれぞれに長所短所があるので、本来ならば相互補完的な、つまり一方が他の一方の足らないところを補う、という関係にあるべきだったと思います。車の両輪です。

でも

変換キー共用型NICOLAを指して、親指シフトを改良したものだ(つまりOASYSはレガシーの方式だ)と言いきってしまうと、違う話になってしまいます。

違う話とは?

基準がなくなってしまいます。

一度でも基準が崩れると

なんでもありの収拾のつかない状況になるかもしれません。

ではなく

なんでもありの収拾のつかない状況に、すでになってしまっています(現在進行形)。

その一例を、日本語入力コンソーシアムの公式サイトでも見ることができます。

日本語入力コンソーシアムの公式サイトと私

何やら小学生の書いた作文のタイトルのようになってしまいましたが、正直にいうと日本語入力コンソーシアムのことも、その公式サイトのことも詳しいことは知りません。

関係者ではないので。

通り一遍の内容ではありますが、ざっとまとめたのが以下です。

日本語入力コンソーシアムとは、1989年に親指シフトキーボードの普及と標準化(すなわちJIS規格化)を目指して立ち上がった第三者機関です。

具体的にはNICOLAという親指シフト準拠の独自規格を定め、参加企業以外のメーカーにも積極的にNICOLAの採用を促す、そんな活動をしていたようでした。

で、その参加企業ですが、

日本語入力コンソーシアムの公式サイトによると、80年代のパソコン業界で欠かせない存在だった株式会社アスキーを筆頭に、アップルやIBMなどの外資系、ソニーや松下電器産業(現パナソニックホールディングス株式会社)そしてもちろん富士通と、誰もがその名を耳にしたことがあるそうそうたる企業が集結しています。

ただ、その活動は実質的には1990年代の後半あたりで終わっていたんじゃないかなあ、というのが私の印象です。

一方そういった状況のなかでも、現在の日本語入力コンソーシアム・公式サイトは1990年代後半あたりにに立ち上げられたようです(詳しいことは知りません)。

かつては私自身も日本語入力コンソーシアムの公式サイトを閲覧することが多かったのですが、富士通が最後の親指シフトキーボード・FMV-KB232を出したころ(2008年ころ?)あたりから疎遠になってしまいまいました。なので、その後の状況はよくわかりません。

2018年・「誤りの修正」とは?

さて、私はまったく知らなかったのですが、富士通・最後の親指シフトキーボードKB232が発売されてから10年後、富士通が親指シフトからの完全撤退を決定したというような話がネット上で交わされるようになった2018年、

日本語入力コンソーシアム公式サイト・日本工業規格(提案)に、親指シフトの処理をあらわす状態遷移表に修正があったようでした。

久しぶりに(ほんとに何年ぶりかに)サイトを閲覧した私は、以下のような記述に気がつきました。

[2018.4] 状態遷移表に誤りがありましたので、修正しました。

正直、この文言じたいが驚きでした。それなりに親指シフターの人口が多かった数十年前には誰も誤りには気づかず、野球の試合に例えるなら9回裏2アウト、つまり富士通の親指シフト撤退がリアリティーをもって語られ、親指シフトのことなど聞いたこともない人が大勢という時代になったある日突然、「誤り」に気づいて修正した、というのです。

どのような修正が行われたのでしょうか。

状態遷移表2018年のもの

親指キーリリース処理を、加えていますね。

上述した親指ひゅんQの「同時打鍵ステートマシン」でいうところのE33(親指キーを押しながら文字キー押下を検知したら同時打鍵確定)は親指シフト処理の根幹でもあるのですが、この部分を崩してしまっています。(なぜ親指シフト処理の根幹といえるのか、その理由はこちらに書いています)

そして従来の状態遷移表には存在しなかったOMオン状態(親指キー文字キー押下中状態)をつくりだし、処理B、および処理Dといったあらたな処理を入れています。

処理B、および処理Dをわかりやすくまとめると、こうなります。

親指キーが、シフトキーではないかのような処理を取り入れている。

黄色ライン

確実に言えるのは、目的が変わってしまっているよね、ということです。

いま打った文字キーがシフトありかなしかを判定するのが親指シフト、のはずなのですが、別のものを判定しようとしている、そういう感じです。

言い方を変えると、「文字入力の確実性」を削りとってでも親指キーの単独打鍵を検出しやすくする処理になっています。

いったい目的は何だろう?と考えてしまいます。

親指シフトとは違う何かを試みているのかな、という気もします。

2018年・新NICOLA規格書の状態遷移表を簡単に言えば

親指シフトのようでもあり、逐次打鍵のようでもある、という感じです。

それを一言でいえば

どちらでもない

です。

つまり

そのむかし名だたる国内メーカーにくわえてIBMやアップルまで参加し、

親指シフトキーボードの普及と標準化を目指して立ち上がった日本語入力コンソーシアム

でしたが、

数十年の時を経て、現在日本語入力コンソーシアムの公式サイトに記載された処理方法は、

親指シフトではない

と言うのが私の意見です。

黄色ライン

ローマ字入力のように打鍵順序が入力文字を決定する逐次打鍵方式と、打鍵順序で入力文字を決定してはいけない親指シフト方式。

水と油のようにけして交わることのない、ルールが異なるロジックを混載させて果たして実務に耐える入力方式が出来上がるのか。

私の答えはノーです。

すくなくとも親指シフトではないと思います。

なぜか。

変換キー共用型NICOLAでさえも理屈上は親指シフトのサブセット(機能限定バージョン)、ロジック的には親指シフトマイナスになってしまうからです。

その変換キー共用型NICOLAが実用性を担保していた部分を削り取って、さらに同時打鍵の判定精度を落としたものが一体なんだろうかと問われたとき、親指シフト以外のなにかですね、としか答えようがない気がするんです。

同時打鍵遷移表を再掲

日本語入力コンソーシアムの公式サイトに記載された同時打鍵処理は親指シフトじゃない、というのはキホン理屈の話なんですが、もちろんそれだけではありません。

FMV-KB211などを軸に数年にわたって富士通の親指シフトキーボードを使いつづけ、window7の時代には自作エミュレーターで親指シフトしていた自分の経験値も加味して、

親指シフトではない、と書いています。

2000年代の初めころになるのですが、上述の「親指キーリリース処理」を加えたらどんな操作感になるか実際に試してみたこともあります。

結論を言えば同時打鍵判定の精度が歴然と低下する(具体的にはシフトのタイミングでシフト側の文字が入力できない)のを体感することになりました。やはり公式サイトの記述(2000年バージョン)はよく考えられているのだなあと感心したことを覚えています。

あれから長い月日が流れて、気がつけばいつの間にか立場が逆転してしまいました。

当時は日本語入力コンソーシアムの公式サイトを運営している側にも、きちんと親指シフトを押さえている方がいるのだ、と感じることがありました。しかし担当者が代変わりして、そういう方も少なくなったのでしょう。

ということで唐突、ですが

1992年・VOL.18の富士通ジャーナルには

「(親指シフトの)技術を公開し、日本語入力コンソーシアムに実施許諾を譲渡しました」

という記述が見られます。

なんとなく親指シフトに対する決別宣言のようにも思える文ですが

それはともかく

かつて(2000年頃から2018年以前に)日本語入力コンソーシアムの公式サイトに揚がっていた状態遷移表こそは、上記の”富士通が公開した技術”の中核にあたるものだと、私は理会していました。

上述のようにその貴重な資料が消えてしまって、現在は参照することができません。

とても残念です。

ということで改めて当サイトで掲載することにしました。

こちらが親指シフトの基準、状態遷移表です。

よろしくどうぞ。

こちらこそがって、なんだか本家争いみたいだなあ。

黄色ライン

付記 2024年7月15日

上述したように、「誤りがありましたので、修正」したとして日本語入力コンソーシアムの公式サイトから消されてしまった状態遷移表、それこそが本来の親指シフトであるというのが私の意見でした。

それはとりもなおさず日本語入力コンソーシアム設立にさいして富士通が公開した技術の中核をなすものだと、以前から考えてきました。

この記事を初投稿したのは2023年6月3日でしたが、それから1年近く過ぎて私の考えを客観的に裏付ける資料を見つけることができました。

紅皿のサポートブログ」経由で知ったのですが、具体的には親指シフト関連の特許資料です。その内容はどなたでもネット経由で自由に閲覧することが可能になっています。

たとえば出願日、昭和53年(1978)の特公昭62-37405号「文字入力方式」、あるいは昭和60年(1985)特公平6-82314号「キーボード同時打鍵シフト処理方式」などに親指シフトを実現するためのロジックが記載されています。

当サイトでも「特許出願でわかったOASYSの親指シフト」というタイトルで記事を書きましたので興味のある方は参照してみてください。