車上のワープロ技術史

辞書は文法と併せて言語処理の最大の要素である。文法については既に述べたように従来の文法は役に立たなかった。それは人間の理解能力を前提にして構築されているので、「後は察せよ」的な作りであり、たとえば、マンションのセールス用パンフレットの完成予想図的なものにすぎない。これではマンションは立てられないのである。計算機は生まれつきの言語能力など持っていないのだから、全て我々が教育しなければならない。それには完全な設計図（文法）を作る必要がある。

辞書も同様である。学校で使う通常の辞書は人間用のものである。著名な辞書に「日本」が載っていない事に我々はすぐに気がついた。確かにこのような語は説明しなくても分かる。とはいえ、機械用の辞書としては、これではだめである。このような問題はいくらでも出てくる。反対概念は必ず載っていなければならない。「上流」が登録されているのなら「下流」も当然の事として期待される。しかし、「中流」はうっかり忘れられるかもしれない。「とうきょう」なのか、「とおきょう」なのか、「取り扱い」はあるが、「取扱い」がないということはないか。。。更には、時事用語、専門用語などは通常の国語辞書には載っていない。複合語も同様である。新聞に載る政府の委員会名などは状況に応じて作られるわけであるからあらかじめ辞書に載せることはできない。

こんな例もあった。「異常」という言葉は、普通、形容動詞と説明される。従って、「異常な」と活用する。「異常な事態」のように用いる。しかし、「異常の」という用例もある。「異常の太陽」という小説が出ていた。そもそも形容動詞という品詞を認めない国文法学者もいるのである。我々にとっては、品詞名はなんであってもいい。用法を弁別できればＡ種、Ｂ種でもいいのである。名詞を修飾する同じ機能の言葉に、「美しい」のような形容詞とは確かに異なる活用をする「奇麗な」のような言葉が厳然としてあるのである。「奇麗な」と「異常な」は同じグループに属すると思われるが、しかし、「奇麗の」とはいわない。ということは、この二つは異なる品詞とすべきか。あるいは、「異常」には形容動詞と、名詞の２つの立場があるのか。「異常が発生した」、「異常を感じる」といえるからそうなのだろう。辞書を作るにあたっては、このように品詞を正確に検証していくことが大変なことであった。

語彙の面でも、辞書を少しでも完全に近づけるには、過去の新聞、雑誌、などから単語を拾わなければならない。このような分野の単語は以外に国語辞書には載っていないのである。さらに実験で確認するだけではだめである。実験ではすべての単語を総当たりしている保証がない。結局は、辞書を何度も全て見直さなければならない。森さんの提案で、、ＪＷ－１０完成直前に青梅工場の児玉課長を加えた森、河田、天野の４人は３万語程度の辞書を８０００語づつ分担し、誤字がないか、反対語はあるか、品詞に誤りはないかを一語づつ調べていった。これは大変退屈な仕事である。私は、退屈にも絶えられる時間を使った。電車の中である。ここなら、どうせ退屈である。それに誰にも邪魔されない。これもプログラムの虫取りと同じで虫取りなのである。こうして、自信をもてる辞書が出来上がっていった。

揚羽の蝶

エディタ

最近は、ワードプロセッサとエディタを使い別けている文書に良く出会う。エディタは、複雑な編集ができず、ただ単に文字を入力する程度の機能を持つものを指すらしい。この書き物ではそのような区別はしない。要するに、構成・編集を行う機能部分をエディタと呼ぶことにする。

既に述べたが、１９７０年代のエディタとはラインエディタのことであり、プログラムを書く道具のことであった。テレタイプからＦｏｒｔｒａｎ、Ｌｉｓｐなどのプログラムを１行づつ入力していくのである。テレタイプとは電動タイプライタに計算機用のインタフェースをつないだものと思えばよい。キーボードから入力した文字は紙に打ち出されていく。モニタなどはまだまだ一般には使われていなかった。テレタイプではそもそもページエディタでさえ無理である。１０行前の２６字目を指定するのは、たとえページエディタが出来ても面倒な操作になる。そんな中で文書エディタの出現は人々を驚かせた。文書全体の任意の場所にアクセスして、そこを校正できるのである。

このエディタを開発するにあたって、私は「統一された原理で操作できる事」、「思考を中断させない事」を設計の指導原理とした。前者は、

　１．位置／範囲指定
　２．校正操作
の順で指定することで実現した。すべての操作はこの手順で統一される。

ラインエディタではこんな面倒なことは考えなくて良い。できることはバックスペースでカーソルを戻し、そこから再度入力するだけである。しかし、文書エディタでは、校正／編集操作は多様になる。それらの操作が同一思想で設計されていなければ使う気力がなくなる。ＰＣで、スイート(suite)と呼ばれる一組のソフトの中でさえ、微妙に操作方法が異なりイライラした人は多いと思う。ＰＣなら今では、周りに使う人が多く居るので聞けば良いが、我々が作っているものは前代未聞の機械であるから聞く人も周りにはいないであろう。理解し易く、推論し易いことは絶対要件であると私は思った。

後者に関しては、なかなか難しかった。時々、作家の方々が言われるのは、ワープロは思考を中断させる、というものである。一々、同音語を決めなくては先に進めないので、流れが途絶えるというものである。実は、ＪＷ－１０では、同音語は決めなくても良いように作ってあった。決める操作は何時してもよいのである。それまでは、内部的には全候補を抱えたまま、最初の候補だけが点滅しながら表示されているのである。従って、タイプを止めることなく先に進むことができる。とはいえ、これには相応の犠牲が必要であった。１６ｂｉｔ計算機では最大メモリーは６４ＫＢである。文書用のバッファーはそんなに大きくとれないので、あまり同音語をためすぎると、時々、文書をＨＤＤに吐き出さなければならない。仮想メモリーにおけるスワップと同じ現象がおきるのである。現実の制限により、完全に思考を中断する要素を排除する事はできなかったが、かなりのレベルまでは実現できたと思う。その後、陸続と出現した一連のいわゆるワープロにはＪＷ－１０の設計思想から後退しているものが多いのである。

前者に関しては、後のことになるが、実際、こういう事があった。７８年１０月のデータショーでは私は３日間朝から晩まで、時々、吉井ジュニアと交代しながら説明した。最初の日のまだ開場前の準備中に他社のブースの技術者が３人ほどで社名を背中に書いたジャンパーを来たまま見学にきた。任意の２点間の削除、任意の位置からの任意字数の挿入など自在の校正／編集機能を見て、「負けた」といって去っていった。事実ではあろうが、私の居る前で潔くそのように認めて出ていったのにはそれなりに同じ技術者として感ずるものがあった。多分、彼らは新聞社などで使っていたページエディタを開発していた技術者ではなかったか。当時はページエディタといっても消した文字のあとは、空白が残るのである。

またこういう事もあった。研究所の図書館には当時和文タイプ部門があった。研究報告書は、まだ手書きの時代であったが、重要なものはこれで活字にしていた。それをワードプロセッサに変えることとなった。私がその操作をタイピストに教えることになった。入力した仮名がどんどん漢字になってモニタ画面に表示される。彼女は既に予備知識があったのでそれには驚かなかった。では、ここからここまでを削除してみましょう、といってその操作をさせた。削除ボタンで、消す最初の文字と、最後の文字を指定するだけである。

彼女が「ワッ、凄い」と驚いた。彼女のその反応に今度は私が驚く番であった。和文タイプでは、いや、タイプライタだけでなく大型計算機上の高価なエディタでさえ、消した部分は白く残るだけである。しかし我々のＪＷ－１０では自動的に文字詰めが行なわれるのである。現在では当然のことである。ワードプロセッサを作ろうと思い立った我々にも当然のことであった。しかし、技術には相場というものがある。当時は、そんなことは誰も考えていなかった。

ご飯を炊くのに、かまどに藁をくべて火をおこし、それから薪をくべ、はじめチョロチョロなかパッパ、赤子泣いても蓋とるなといいながら炊いていた時代の人には、現在の、火もつかわず、従って、炎もたたずスイッチ一つで炊き上がる炊飯器は思いもよらないだろう。逆に、今では「はじめチョロチョロ。。。」などは何の事か分からない人が増えてきているだろう。消した文字の部分が自動的に詰まっていくということはそのくらい衝撃的な出来事であった。

しかし、現在の人間が、こんな程度の事が本当に難しかったのかという感想をもったとしたら、それはやはり部分的に正しい感想である。技術には時代精神があり、相場があるが、技術者というものは保守的なものである。悪く言えば精神的に怠け者である。相場が許せば苦労してまでそこから出ようとはしない。研究という本質的に苦労をする事が仕事である場合でも、必ずしも苦労に敢えて立ち向かうとは限らない。森さんが大型機からミニコンに仮名漢字変換を移植せよ、と言われたとき、私は反発した。私がやるわけでなく、河田さんの仕事であったが。。。それでもこれは無理ではないかと思った。当時はまだ存在していなかったが、ｉ８０８６程度のＣＰＵのミニコンでＡＩをしようというのである。しかし、結果はできてしまった。よく言われる事だが、担当技術者が、それはできません、という。管理者が、そうか、できないか、でもやってみよう、と言うとできてしまう。担当者の出来ませんは鵜呑みにしてはいけない。

最近（２０００年）、ＣＤ－ＲにＢＵＲＮ－ＰＲＯＯＦという技術が導入されて、やっと誰でも失敗せずに焼けるようになった。これは我々計算機技術者からみたら当然の出来事である。そのような技術－－ビジーあるいはフロー制御の概念－－は、計算機では常識的というもおろかで、それなくしては計算機システムが成り立たない、基本中の基本の技術である。ちなみにＣＤ－Ｒは計算機に付けて使うが計算機技術ではない。電子工学の技術である。非専門分野から見たら同じ分野に見えるかもしれないが、それが同じだというのは、４０万トンタンカーの船長は、同じ乗り物の分野であるジャンボジェットも操縦できるだろうというに等しい。三洋電機で、計算機部門からCD-R部門に移った技術者が実現したらしい。ＣＤ－Ｒの一ユーザとしてやっとやってくれたかという思い出あった。

しかし、本当にできないこともある。上記のような自動詰めができるためには、それなりのモニタが必要であった。研究所で最初に使っていたのは蓄積管であり、部分を消した場合でも、その後ろだけ再表示すれば良いというわけには行かなかった。メモリー上はそのようにするが、表示上は一度全部消して再表示する必要があり、実用的ではない。もっとも研究室では原理的な試験をしているわけなので、遅くともテストはできた。技術管理者はこの間の事情を良く弁え、適切な判断を行う必要がある事を、そして、管理者と言えどもそれだけの技術知識は不断に保持し続けていなくてはならない事をこの時、学んだ。

エディタではもう一つ勉強した事がある。上記のタイピストに教えていた時、はたと彼女の手がとまったのである。既にタイプした文書を編集していた時のことである。途中に段落を入れたくなったのである。

xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxyyyyyyyyy
yyyyyyyyyyyyyyyyyyyyy
yyyyyyyyyyyyyyyyyyyyy

　　　　↓

xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx

yyyyyyyyyyyyyyyyyyyyy
yyyyyyyyyyyyyyyyyyyyy
yyyyyyyyy

このようにしたいのである。

最初から順にタイプしている場合は、改行キーを叩いて、何の迷いもなく段落を作ってタイプしていた彼女が、編集過程では改行する方法を推測できないでいるのである。ヒューマン・インターフェイスというものの難しさを考えさせられた事件であった。笑い話に、フロッピを渡して、コピーしておくように頼んだところ、フロッピをゼロックスコピーをして持ってきたというものがあるが、これも別段、不思議ではない。「ウィスキーの水割り」は英語では「whisky and water」であるが、レストランで「spaghetti and wine」と注文したらウェイトレスは「スパゲッティにワインをかけたもの」を持ってくるであろうか。言語の解釈はその発話がなされた文脈、環境で解釈されるものだからである。環境を共有していない場合には、このような事が起こっても不思議ではない。

改行は、英語ではキャリッジ・リターンである。キャリッジとは、carriageで、運搬、乗り物という意味である。手動のタイプライタでは紙をサランラップの軸のようなキャリッジ＝紙を運搬するものに巻く。その軸が横に一字づつ移動してタイプしていく。プリンタではヘッドが動くのであるが、タイプライタでは紙の方が動く。紙を運搬するその軸をキャリッジと呼ぶのであるが、紙の端にくると、その軸の端についているレバーで初期位置に戻す。すると、同時に一行分進んで次々と改行されていくのである。

改行（キャリッジリターン）はこのように「動作」である。しかし、計算機内でこれを表現するとどうしてもコードにならざるを得ない。「動作」を静的な「コード」としてあらわすのである。順にタイプしている時なら改行キーを押す「動作」であるので、改行になんの困難もない。この操作は手動タイプと同じである。しかし、一度打ってしまった文書の途中で改行という「動作」を行うとはどういうことなのであろうか？コードなどというのは計算機屋の勝手な作り事にすぎないのである。彼女は、考え込んでしまった。元々「動作」が「文字」と同じであるという考え方には無理があったのである。ヒューマン・インタフェース（ＨＩ）というのは難しいものである。「自分が何を知っているのか」さえ確実に認識しているかどうか覚束ないが、「自分が何をしらないか」は、原理的に分からないのである。彼女のそのような認識について、そのような考え方がある事を、私は知らなかったのである。知っていれば、もっとやさしいＨＩを考える事ができたかもしれない。とはいえ、この場合は無理である気もする。

揚羽の蝶

漢字用ハードウェア

１９７０年代というのは、計算機で漢字を扱いたいという運動が絶頂期にあった時代である。１９６０年代中頃メインフレームの事務処理用言語であるＣＯＢＯＬ;Common Business Oriented Languageで半角のカタカナを用いることができるようにしたカナＣＯＢＯＬというような言語をＮＥＣなどが提供していた。その頃は仮名しか英字に対抗する手段がなかった。仮名ならざっと５０音で済み、大文字、小文字あわせて５２文字の英字に対抗できたのである。しかし、日本人である限り、仮の名ではない、真の名、すなわち、真名＝漢字に対する希求は果てしがない。

梅棹忠夫氏はタイプライタを使うことによって知的生産力を上げようと「知的生産の技術」で提唱していた。しかし、当時はタイプライタといえば、英字かカタカナしかなかった。「できることならいまの漢字かなまじり文を、そのままタイプすることができれば、それにこしたことはないのである」とある。しかし、当時はこれは無理であったので心理的抵抗のもっとも少ないひらかなタイプを提唱された。

一方では、カナ文字運動やローマ字運動がある。タイプライタを使うという意味ではこれはなかなか魅力的である。しかし、我々はかな文字だけの文章を読む事になれていない。そもそも、かな文字だけで日本語を表すには無理があるのである。日本語が純粋な大和言葉であったなら、それもできたかもしれないが、遣唐使以来、既に大量に中国の発音のまま、漢字言葉を輸入してしまっている。「おん」と言われる漢字の読みがそれである。中国語では四声や母音体系の関係で異なる発音であった言葉が日本語の音の体系－－四声は無く、母音も５つしかない。高低のアクセントはあるが、それで意味が異なるとしても関西と関東では逆になったりする。「雨」と「飴」。また、母音にしても、名古屋弁にはcatの「あ」がつぶれたような母音がある。「おまえさん」は「おみゃーさん」である。しかし、これらの事は、書き言葉の同音語の弁別には役にたたない。－－に取り込まれると同じ音になってしまうのである。従って、音読み熟語は同音語が異常に多い。これを仮名で表すには無理がある。同音語が文脈から特定しにくい場合、表現を変えれば良いと主張されるが、表現には美学が籠る。それに、氏名を表すには文脈も、言い変えも有効ではない。

そんなわけで一方には仮名文字を使うことを主張する人達の歴史があるのであるが、大勢は、なんとか計算機で漢字を扱えるようにできないかという思いであった。このような情勢のなかで行われていたのは日本語の研究以前に漢字の研究であった。漢字を入出力することさえ安価にはできない時代であった。この安価とは、「数百万円」程度でという意味である。2000年現在のＰＣのモニタやプリンタのような、数万円のことではない。新聞社が使っていた漢字処理機器は数千万はしたのではなかろうか。７４年頃の事務機器の雑誌に漢字処理機器--まずは、顧客名簿、住所録などが大きなニーズであり日本語というより、漢字を入出力することが当面の目標であった--の未来像が載った事がある。現在のＰＣ用と同じ程度の大きさのプリンタに１４インチ程のＣＲＴ（ブラウン管）がついて、これが今できたとしたら２０００万円はするだろうという記事であった。

総合研究所でもそのようなハードを研究しているグループがあった。漢字を記憶させる磁気素子、漢字を印刷するプリンタ用のヘッドなど、今から見たら何故？というような方式の研究がされていた。漢字パターンなどＨＤＤに格納すればいいではないか、と思ってはいけないのである。それでは、パリ市民は毎日のパンにも事欠いているのだと聞いて、パンが無ければ、お菓子を食べればいいじゃないと応えたと言うマリー・アントワネットと同じレベルの時代認識になってしまう。坂井研にＨＤＤが入ることになったのが７１年か、７２年のことであった。そのドライバを作る為の流れ図の説明を研究室の助手や博士課程の先輩に混じって聞きながら、たかがデータを読み書きするだけにしては、なんと複雑なものだろうと感心していた記憶がある。先輩の誰かが、そのドライバを書くことになった。

インクジェットで精細な制御ができるようになったのは、何時頃からだろうか。私が始めてインクジェットプリンタに出会ったのは、１９７３年である。それまでは、テレタイプで秒１０文字程度の速さでしか文字（英字）を打ち出せなかったのが、これで、はっきりとは覚えていないが秒８０字くらいにはなった。字はよれて汚かった。書類を印刷して人にみせるという用途には向かなかったが、自分のプログラムを打ち出して読むという用途には速くてありがたかった。この速さを経験したら、もうテレタイプには戻れなかった。無論、今のインクジェットと違って、文字しかそれも英字とカナくらいしか打てない。このインクジェットは確か日本初の物でカシオ製ではなかったかと記憶している。これをミニコンに付けることが、同期で入った井沢の研究室の実習テーマであった。PCのようにパラレルポートに付ければ済むというわけにはいかない。何事も、バスに挿すコントローラボードとドライバを作らなければ済まないのである。ある日、彼がボヤイテいた。このプリンタ、ビジー（ｂｕｓｙ；忙しい。電話の「話中」も英語ではビジーである）の概念が無い。

ＣＰＵは電子的に動くので速い。しかし、プリンタのような機械式で動くものは何桁も遅い。ＣＰＵはマイクロ秒のオーダでデータをプリンタに送る。それを受けたプリンタはインクをピューと吹きだし、ヘッドを１文字分進める。１秒で８０文字として、１文字１２．５ミリ秒である。ざっと３桁、１０００倍の差がある。ＣＰＵがどんどん自分のペースでデータを送っても、プリンタは対応できないから誤動作するだけである。これはプリンタだけの問題ではなく、同じ速さで動いていない物の間では必ず起きる事態である。これを解決するのがビジーの概念である。プリンタは１字受け取ると、バスにビジービットをたてる。ＣＰＵはデータを送った後、このビットを監視していて、このビットが消えるまで次のデータを送るのを待つのである。

　　OC dev,wrt ;OutputCommand.devレジスタで指定されるデバイスに書き込みモードを指示
cont *
　　LB reg1 data(reg2)　;LoadByte.data+reg2番地から１byeをreg1レジスタに持ってくる
　　WB dev,reg1　;WriteByte.devデバイスにreg1の内容を書き込む
　　SS dev,busy　;SenseStatus.devの状態をbusyレジスタに取り込む
　　BTC busy,*-4 ;BranchOnTrueCondition. busy bitが立っていたら自分より４番地前にジャンプ
　　AHI reg2,1　;AddHalfwordImmedeateデータバッファカウンタを１進める
　　CLHI reg2,stop　;CompareLogicalHalfwordImmediate.最終データチェック
　　BTC ok,cont　;最終でなければ、続行

３０年近く前のことなので、オペランドの細部は間違っているかも知れないが、まあ、ドライバーは、こんな書き方である。SSとＢＴＣがビジーチェックをしている所で、ビジービットが立っている間、＊－４へ、つまり自分より４番地前の命令＝SSへジャンプしなさいということである。これで分かるように周辺機器は必ずbusy　bitが無ければならない。それが無いらしい。しかたないのでコントローラ側で適当な時間ループしてその間をｂｕｓｙとする回路を作った。Ａ４程度のボードにＩＣを並べていくのだが、そんなこんなで回路が複雑になり、彼はＩＣを２階建てにしてボンドでくっつけていた。そんな悠長な時代であった。

１９７７年、青梅工場で開発メンバーの顔合せがあった。そのハード部隊に知った顔が居た。京大長尾研究室出身の吉井さんである。ハードのリーダも年長の吉井さんだったので、彼のことは以後、吉井ジュニアと呼ぶのであるが、これには驚いた。彼は長尾研で大容量、当時の「大」は１０ＭＢ超程度であるが、ＨＤＤをミニコンに付けていた。ＩＤＥや、SCSIなど無い時代であったから当時はハードを何百万円かで買ってくると自分でコントローラボードを設計して配線して作るのが普通であった。数百万円程度の「安価！」な機器にはそのようなものは付属していなかった。

このメンバーが２０００万円はすると言われたハードの開発にとりかかった。２０００万円ではオフィス機器であるワードプロセッサは売れない。漢字ディスプレイ、漢字プリンタ、カナキーボード、８インチフロッピディスク、１０ＭＢＨＤＤ。前にも書いたようにカセットテープドライブが３００万円の時代である。販売価格はまだ決まっていないが、後にこれらが片袖の事務机に仕込まれて、６３０万円で売り出された。