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

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

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

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

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

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

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

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

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

それにしても……、

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

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

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

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

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

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

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

そんな感じ。

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

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

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

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

私の意見は、

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

です。

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

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

変換キー共有型NICOLAとは

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

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

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

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

親指シフトのJIS化を目的に制定された、日本語入力コンソーシアム･レイアウトすなわちNICOLA規格の骨子ともなった手法でもあります。

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

それは

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

という現象です。

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

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

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

みたいな。

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

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

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

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

になるのです。

危険です。

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

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

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

きわめて危険です。

そこで

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

親指キーの単独打鍵とする、というのは正確な表現ではないのですが、要は、そういうことです。

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

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

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

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

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

ここに矛盾があります。

では今度は視点を変えてみます。

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

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

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

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

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

ということになります。

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

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

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

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

ようするに

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

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

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

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

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

なぜか？

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

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

ただ、上述したようにそもそも日本語入力コンソーシアム設立の背景が「変換キー共用型NICOLAの推進」にありました。そして富士通としても日本語入力コンソーシアムにバトンを渡した以上はその路線を指示しよう、という方針だったのでしょう。

もちろん変換キー共用型にもメリットはありました。

もともと親指シフトキーボードは富士通の一社独占、他社が親指シフトキーボードを採用するのであれば富士通からライセンスを取得しなければならなかったのが1980年代でした。その富士通も「新JISキーボードの時代」に書いたように、親指シフトから手を引くのじゃないか、親指シフトキーボードをやめてしまうんじゃないか、そんな雰囲気、ちまたの意見が聞こえてきたのがその時代でした。

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

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

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

変換キー共用型NICOLAならばライセンスフリーだという話も耳にし、これこそは親指シフト復活の転換点になるのではないかと、当時は私も考えていました。

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

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

そうは思いません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下の表を見てください。

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

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

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

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

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

それを証明している資料を下記に掲載します。

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

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

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

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

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

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

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

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

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

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

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

だとしたら、

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

なにが問題なのか

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

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

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

重箱の隅であるかもしれないけれど、それと同時に

根幹の話でもあるから

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

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

じっさいには変換キー共用型NICOLAとOASYS方式(変換キー独立型NICOLA）はそれぞれに長所短所があるので、相互補完的な、車の両輪の両輪のような関係であったのであれば問題はなかったのです。

しかし1990年代に入って富士通は、親指シフトキーボード(OASYSキーボード)はデファクトスタンダードにはなりえず、したがって主力商品の座から外すほかない、そういう判断を下しました(と私は考えています)。

ちなみにこの判断そのものは(企業としては)正しかったと思います。

キーボードそのものの低価格化が進むなか親指シフトキーボードをデファクトスタンダードとするにはコスト的に合わないはずだからです。

そして親指シフトにかんする権利は日本語入力コンソーシアムに委ねたのだから、今後は日本語入力コンソーシアムの方針に合わせますよ、という方向を定めたのでしょう。

でも

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

違う話とは？

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

一度でも基準が崩れると

なんでもありの収拾のつかない、カオスともいえる状況になるかもしれません。

ではなく

なんでもありの収拾のつかない、カオスともいえる状況にすでになってしまっています(現在進行形）。

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

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

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

関係者ではないので。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

処理B、および処理Dを一言でいうと、こうなります。

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

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

目的が変わってしまった、とはどういうことでしょうか？

目的はなに？

ここで視点を変えてローマ字入力する立場になってみましょう。

通常、ローマ字入力すること自体を目的としてローマ字入力する人って、ほぼいらっしゃらないはずですよね。目的はローマ字入力することではなくて文章、報告書、企画書などのコンテンツ、書く中身にありますから、ローマ字入力はあくまで書くための手段、道具でしかないですよね。

その限りでは親指シフトもおんなじです。「誰もが考えながら日本語を打てるように」という設計理念のもと誕生したキーボードではありましたが、つまることろ「書くための道具」、手段であって、それ以上のなにかではありません、……でした。

これはもちろんローマ字入力だけの話ではなく、(仕事で)英文入力するときもおなじのはずです。私自身が仕事で英文入力することはほぼないのですが、タイピングそのものが目的ではない、ですよね。

ということであらためて基本中の基本、英文入力するときのシフトの動作を確認してみましょう。

オーソドックスなシフトキーの作用……、それは[A]キーを単打したら小文字の”a”、シフトキーを押しながら[A]キーを押したら大文字の”A”になる、というものですね。

その限りでは親指シフトキーの動作もまったくおなじなんです。同時打鍵といってもじっさいにはどちらかのキーが先に押されることになるので、仮に親指シフトキーが先に押されたのなら、文字キーが押された段階でシフト成立です。

でも、上述したように親指シフトの開発スタッフはさらにこう考えました。

同時打鍵したときに常にシフトを先に押す必要があるのでは、制約になってしまう。

そこでシフトをあとから押しても「あり」にしてしまおう、と。

そのほうが楽じゃないか、と。

その発想を一言でいえば

「シフトをもっとやさしく」

です。

それが親指シフトの根っこにある考え方です。

ところが、2018年に修正された状態遷移表

処理B、および処理Dだと、シフトキー、Aキーと続けて押してシフト状態になっても、シフトキーを早く離したらシフトを取り消して小文字のaとし、シフトキーをゆっくり離したらまた別の結果になる（大文字になるかも未定）ということをしているんですね。

「シフトがとてもむずかしくなってしまっている」

のがおわかりですよね？

目的が変わった、だけでなく「シフトをやさしく」という本来の親指シフトとは真逆の方向にいってしまいました。

むずかしい、というのはまだ柔らかな言い方であって、上の処理ではむしろアクロバットに近い技工、指の動きが求められるのではないでしょうか。

たとえば、下のように大文字が頻繁に現れる英文があったとします。

ThE gNu gENErAl Public LicENsE is A frEE, cOPylEfT licENsE fOr sOfTwArE ANd OThEr kiNds Of wOrks.

大文字になる文字と小文字とで文字種を分けてあるので、慣れてくればある程度は上達はすると思います。

でも、きっと打ちづらいですね。

それに加えて

シフトキーをすぐに離したら小文字にするよ、ゆっくり離しても大文字になるかどうかはタイミング次第だよ、みたいなことを言われたら

ストレスなく自在にコントロールし思い通りに文字入力できる人がはたして何人いるのか、という話です。

これは頭の中に浮かんだ言葉を文章にするための道具（手段）ではなく、それ自体を目的とするスポーツというか、タイピングゲームのような世界観でしか成り立たない入力形態ですね。

ようするに、目的が変わってしまいました。

親指シフトではなく、親指シフト以外のべつのなにかを求めているのかなあ、という気がしないでもないですが、仮にそうであったとしても、仕事で使う文字入力環境ではないですね。

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

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

それを一言でいえば

どちらでもない

です。

以上

同時打鍵遷移表を再掲

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

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

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

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

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

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

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

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

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

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

という記述が見られました。

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

それはともかく

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

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

とても残念です。

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

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

よろしくどうぞ。

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

付記　2024年7月15日

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

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

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

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

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

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