ただいま、ご紹介にあずかりました高木と申します。実は、大変に申し訳ないのですが、今日のお話の概括を記したレジュメなんですが、今朝までかかって作っていたのですけれど、遂に最後まで至りませんで尻り切れになって居ります。資料館の皆様には大変にご迷惑をおかけしてしまいました。というわけで、余りまとまったお話ができる自信がないので、先に今日のお話の主旨を申し上げて、あとは時間の許す限りレジュメの順にお話させて頂きたいと思います。

基本的には講演題目に示した通り、アプリケーションと呼ばれているいわばお仕着せのワープロソフトやデータベースソフトから離れて、フリーな MS-DOS 上のツールを用いてデータを扱うことにおけるメリットについてお話をしたいわけです。

実は、このことに就いて書かれた大変に良い本があります。東京女子大学の黒崎政男さんが、「月刊ASCII」という雑誌に連載されたものを単行化して出された「哲学者クロサキのMS-DOSは思考の道具だ」(アスキー出版局、￥1,900)という本です。黒崎さんは私とほぼ同世代の方なのですが、「一太郎」帝国から脱して MS-DOS 上のツールである grep だとか sed だとかに出会って、さらに CD-ROM や通信、そして LaTeX を使いだすまでの経験が書かれています。似た経験を経て、道具としてのパソコンを使っている人文科学研究者がいらっしゃるということに、大層意を強くしたわけです。この本は、最近売れているようで、大きな本屋さんへ行きますと平積みされています。この本をご覧になっていただければ、今日私のお話することは、おおむね盡きているわけなのです。

さて、まずは「アプリケーション」と「ツール」とは、一体何が本質的に違うのかということから始めましょう。私もパソコンでものを書いたり調べたりという使い方をするわけですけれども、たとえば「同じことを一太郎を使って出来るのに、なぜ一太郎でやらないのか。」とか「桐を使えば簡単に出来るのに、なぜ桐でやらないのか。」などという様なご質問が出てくるだろうなと予想するわけですが、極端に申せば「ほとんど趣味の問題です」といい切ってしまえるかもしれません(笑)。

私はパソコンのことを、ひそかに「悲しき玩具」と呼んでいるのですけれども、この機械は、使うことそれ自体が目的になってしまう危険性を大変強く孕んでいる道具でありまして、「環境おたく」という言葉があるように、深みに嵌まると、毎日 autoexc.bat ファイルと config.sys を書き換えるというような事態になって来るわけです。ですから「趣味の問題だ」というふうにいわれてしまえば、「ハイそうですね」といわざるを得ないわけです。

それでも、先ほどの湯浅さんのお話に出て来たデータや、また、これからお話になる西端さんの扱われるような大きなデータの場合、おそらく「桐」では処理し切れないと思われるわけです。また、将来的には MS-DOS 上のアプリケーションでは処理不能になって来るに違いないような規模のデータが多く作成されると思います。そういう事態に至っても、現在のワークステーションレベルで行われている処理の大概が、パソコン上でも既に可能になっているので、アプリケーションから離れてツール類を使うことによって処理出来るはずなのです。

かつて、この会ではないのですけれど、村上学さんが「エンドユーザーの視点から」というような題目で講演なさったのを覚えているのですが、システムとユーザーとの問題があります。先ほどの湯浅さんも、それから資料館のシステムの場合もそうなのですが、要するに、抱えている課題はユーザー誰でもが簡単に使えるようなシステムを作るというものです。その場合マンマシン・インターフェイスの問題が一番厄介なので、そこに一番頭を悩まされていると思うわけです。ところが、私の場合は、ほとんど閉じた環境の中で、自分がやりたいようにできればそれで良い、というふうに割り切れるわけです。たとえばメニューというのは大嫌いですし、実際には触ったことはありませんが、あの Windows の GUI(Graphic User Interface)という、華やかなメニューをマウスで選ばされる方式が大嫌いでありまして、とりあえずプロンプトが無いと(MACの場合もそうですが)何をどうすれば良いのか分からないという事態に陥ってしまいます(笑)。

ですから、まぁ趣味の問題といわれれば確かにその通りなのですけれど、アプリケーションを出た環境で何ができるのか、ということを問題にしたいのです。

パソコンを使うと何かとてつもないことが出来そうだ、という過剰な期待を持ったり、まったく逆に妙な拒否感を持ったりすることは無意味です。かつては勤務先の教室会議で「パソコンに文学がわかるか」などという発言が平然となされていたわけで、「それでは、あなたがお持ちになっていらっしゃる万年筆には文学がわかるのですか」などと、思わずちゃちゃを入れたく成ってしまうわけですが、本当にそういうレベルで、卒論をワープロで書いてはいけないという、まことに教育的な決定がなされて来たわけです。まぁ、現在も学生達はワープロで書き上げた後で、改めて手書きで清書をさせられているのですが……。

この様な喜劇的な状況がある一方で、とりあえずパソコンを使ってみようという方も多いと思うのですけれども、おそらくB6カードとパソコンと比べてみて、出来ることは本質的には何も変わらないのだろうと思います。これは、はっきり断言できるのですけれど、パソコンを使い始めると余計に大変に成ります。一つのことが出来ればそれで済むというような、場当り的なことで済まして行ければ良いのですけれども、汎用性を持たせようとか、こちらのデータを使い回ししようとかと考え出しますと、そこは既にほとんど本末転倒の世界でして、先ほど申した通りインターフェイスが未成熟な道具でありますから、かなりの労力と時間を費やして自分自身で試行錯誤を繰り返さないと、決して満足に使えるようにならないように思います。

適切な比喩ではないかもしれませんが、自転車に乗るのと同じかもしれません。自分で何度も転んでコツを覚えていかないと満足に乗れるようにならない。いくら人から自転車の乗り方について講義を受けようと、あるいは自転車の乗り方について書かれた本を読もうと、おそらく余り役には立たないでしょう。ですから、本来は学問に注がなければならないエネルギーを無理やりそちらに向け、かなりの精力と相当な時間を費やして、パソコンと格闘しないと、なかなか思い通りに使えるようにならない、というのが正直なところだろうと思います。

その点、アプリケーションソフトは周囲で使っている人も大勢いますし、マニュアルもまあ整備されていますし、取り敢えず何か出来るという意味では良いだろうと思います。ですから、そういう意味でアプリケーションを使っていらして、それで満足なさっていらっしゃる方に対して、私は別に「やめろ」というふうにいうつもりは毛頭ございません。ただし、それには、おのずから限界と問題があるのだ、と思っているわけです。

詰まるところ、今日お話し申し上げたいことの第一は、パソコンを使うということに対して過度な幻想を持ってもしょうがないし、逆に恐れをなして遠ざけることも同様に、ほとんど意味がないことだ、ということなのです。

あとは、私が実際にパソコンを使ってやった仕事の話よりも、もう少し抽象的な機械としての性格というか、使うに当たっての理念の問題というか、そういうレベルでお話が出来たらと思います。

とりあえずレジュメを読んでいただければわかるように、最初の方はこの様に書いてみました。けれども、大学というのは不正コピーの巣窟でありまして、「一太郎」を30個買って90個コピーしているということが平気で行われている場なんであります。この様な情況の中で、たとえば日本マイクロソフト社から警告書が送られている、というようなことがありまして、市販アプリケーションの不正コピーの問題も、一大学人として心の痛む問題だと思っております。ただし、問題が単に倫理観という側面だけではなく、ハードはともかくソフトに金を掛けられないという、教育現場の貧困な経済的環境に存することも存じて居ります。そこで、高価なアプリケーションに勝るとも劣らない機能を持ち、自由にコピーして使って構わないフリーソフトウエアが沢山あるのだ、ということもお話したかったことの一つです。

さて、本論に入ります。まずワープロとは何ぞや、ということなのですが、1.1 のところに書きましたが、とりあえずこれは文書を見栄えよくする道具だ、というふうに考えていただけたら如何でしょうか。つまり文章を作成する、文章を書く道具ではなくて、書かれたものをいかに見やすく(ゴタゴタと装飾して本当に見やすいかどうか知りませんけれども)、きれいに印刷できるかというための機能がメインなんだろうと。それゆえに、とてつもなく資源を喰いますし、「一太郎」があるから NEC のハードが売れるという話もあるくらいで、EMS を要求したり、あるいは高速の CPU を要求したりという形で、むしろソフトがハードの方を要求してくるというような、どんどん使わない機能ばかり増えてくるという形で肥大化して行くわけです。私は現在の「一太郎」で文章を書く気にはとても成れません。カーソル移動の遅さ一つ考えても苛々してしまう。その上、値段も高いですし。

私が正規ユーザーになっているワープロソフトは VJE-pen という、一昔前に買ったものですけれども、これは割に処理は速いのですが、その分凝った印字は出来ません。今やほとんど使う機会はなくなってしまいました。

それでは何を使うのかというと、エディタと呼ばれる本来はプログラム記述用のソフトであります。たとえば Mifes とか、Vz というものがあって、Vz でいえば実勢価格で ￥6,000〜￥7,000 程で買えるソフトウエアでして、大変に優れたエディタです。エディタは基本的には印刷機能を持っておりませんので、文章を書いたり、編集したり、コピーしたりということだけに徹しているわけです。ですから 1Mbyte のテキストを読み込んで、一番最初から最後までジャンプするとしても、ラムディスク上だと瞬く間にジャンプできるという軽快さが売りものなのです。でもそれだけでは困りますので、凝った印刷を要求される場合には、テキストフォーマッタと呼ばれているツールを用います。これは、インデントとか強調とかいう印(タグ)をテキスト中につけてやって、そのツールを通すとその指示通りの印字ができるというツールなのですが、こいつを使って印字するわけです。

それでは単にワープロの編集機能と印刷機能とを二つに分けて使っているに過ぎないのではないか、とお思いになるかもしれませんが、実は決定的な違いがあるのです。エディタの吐き出す文章というのは基本的にはプレーンなテキストファイルなのです。つまり、「一太郎」ですと、拡張子 jsw、「松」ですと bun という具合の、普通のタイプコマンドでは中が読めないバイナリーファイル(純粋な文字コードだけが書かれたファイルではないもの)を吐き出すわけです。こう申し上げると、どのワープロソフトでもテキストファイルとして保存する機能が付いているじゃないかとか、jsw や bun という拡張子を持ったバイナリファイルをテキストに変換するためのコンバートソフトがあるじゃないか、とおっしゃると思いますが、ワープロソフト上でインデントを使ったテキストをコンバータに通すと、不要なスペースが大量に入ってしまいレイアウトがガタガタになりますよね。また場合に拠っては、プリンタ制御のエスケープシーケンスも残ります。ですから、とにかくテキストを純粋なテキストファイルとして扱うことができない、という決定的な問題があると思うのです。基本的には、ワープロ専用機でも、フロッピーそのものに特殊なフォーマットをかけてありますから、そのままでは他の機械やパソコンで読めないわけですけれども、そういうものをコンバータで変換しても、結局、装飾コードやスペース・タグなどが紛れ込んで、とても使いにくいのです。

私は、基本的にパソコンを使う最大のメリットとは、自分が一度打ち込んだデータが汎用性を持っていることに盡きると思うのです。ですから、そういう汎用性や可搬性を欠くようなものは、極力排除すべきだろうと考えます。これは悪口になりますので、レジュメには書きませんでしたが、たとえば「一太郎」では ATOK 以外は使えない仕様になっています。で、あれだけ莫迦でかい辞書を持っていれば変換効率は上がるに決まっている。しかし、私は変換効率が良いよりも軽快なものが便利だと思います。ですから、特定のハードの環境や、特定の仮名漢字変換フロントエンド・プロセッサ(FEP)などを押し付けてくるアプリケーションというのは、基本的には使いたくないと思うわけです。

実はちょっと余談になりますが、お配りしたレジュメですが、これは TeX (テックもしくはテフと発音する)という組版ソフトを使ったものです。自分で惚れぼれするくらい美しく仕上がっていると思います(笑)。これ、実はつい最近使い出したものでして、と申しますのは、まず 386 以上の CPU を要求するということで、ハード環境が整っていなかったのです(286で走るものも在るにはあります)。その上、レーザープリンタがないと出力に時間が掛かります。今までは BJ-10v というインクジェットでA4を一枚印字するのに一分かかるものを使っていたのですけれども、これではとてもストレスが溜まって使う気にはなれません。

このソフトのメリットは、とにもかくにも美しく印字出来ることです。ただし、結構なハード環境と大量のフォントを納めておくメモリ資源が要求されます。基本的には組版ソフトですから、自動的に割り付けたり、見出しを付けたり、索引を作ったりするソフトウエアなのですが、なんとコピーフリーでして、基本的には無料で手に入ります。

いま少しメリットを申し上げておきましょう。まずルビがまともに扱えることです。たとえば、レジュメの「資源」という漢字に「メモリ」と振り仮名が振ってありますけれども、これはマクロで実現しています。重要な点はワープロソフトやワープロと違って、ルビがリニアに記述できることです。つまり、「\ RUBY{資源}{メモリ}」という具合に、ルビを付けるべき漢字の文字列の最初にコマンドを付け、ルビのつく漢字を括弧で括り、その後にもうひとつ括弧でそのルビを入れてやる、というだけでルビが実現できるのです。普通のワープロソフトやワープロ専用機ですと、行を固定しますので、ルビを付けた行をいじると、ルビがずれてしまいます。まして、テキストとして見た場合は本文がルビ行で途切れますから、検索する場合に困ることになります。リニアにルビが付くメリットがお分かりいただけると思います。また、両側にルビが振れるマクロも備わり、左注まで含めてリニアに付けられます。これを少し工夫すると、漢文の返り点も表現できます。

それからもうひとつは、注が簡単に付けられる点です。注は我々が論文を書く時には必需品なのですが、今回は脚注という形で出しました。ワープロソフトでも最近の「一太郎」なんかではサポートしているようですけれども、TeX では単純にベタベタに書いていけば良いわけです。ここに注をつけたいと思ったらそこに \footnote というふうに書いて、{　}で括って注を書いて、そのままどんどん先へ書いていけば、コンパイルした時に自動的に番号を振って出力してくれる。これは、スタイルファイルを書き換えれば、後注という国文学で一般的な、論文の一番最後に注をつける形も可能です。これを使いだすと、やたらに注が多い論文になりがちですので注意が必要です(笑)。今まではワープロを使うと注を付けるのが億劫になり、書名でも何でもパーレンの中に押し込んでしまって胡麻化して来たわけですが、これで割と気軽に注が付けられるように成ります。注の処理が自動的に出来る点も の良いところだと思います。

これは機能というべきではないかも知れませんが、文章を構造化して認識しやすいのです。アウトラインプロセッサという階層化するソフトウエアもありますけれども、どうもワープロでものを書き出してからは、たれ流し式の書き方をしてしまいます。つまり、メモをちょこちょこっと書いて、その間を埋めて行くという、場当たり的な文章になってしまいがちなのですが、この TeX ですと、章節段と階層化して \section, \subsection, \subsubsection というようにコマンドさえつけておけば、その1は「アプリケーション」、1.1「ワープロ」、1.2「データベース」、ずっとつながって 2 があってというように、章段の番号を意識して書かなくても、また後から章段を入れ替えたり増減させたりしても、自動的に番号を振ってくれるわけです。今日はお出ししませんでしたけれども、見出しを抜き出して目次にするコマンドを使えば、非常にはっきりと階層化したことが確認出来るのです。

ここまで申し上げたように、索引や目次などが簡単にできるということ、さらに、およそあらゆることがマクロで実現可能で、割注や角書などもマクロで実現できます。それから、今回は横書でしたけれども、縦書でも pLaTeX が使えます。ただしこのように横文字が多い文章というのは、縦書にするとどうも見難いのです。

以上述べて来たように TeX のメリットというのは、はかり知れないと思います。汎用の組版用ソフトですから、実はきちんと LaTeX で書いてやって、それを印刷会社に持って行きますと、そのまま版下に成ってしまうのです。今回私が使ったのはエプソンの安価なレーザープリンタでして、300dpi(1インチの間に300ドット)の品位なのですが、印刷会社の電算出力機などにかけますと、2000dpi 近い細密さで出力可能ですから、そのまま版下になってしまうわけです。これは、デスクトップパブリッシングの比ではなくて、 LaTeX を使えば本そのものも、書き手がレイアウトを考えながら書けます。そういった意味でのメリットもあるわけです。

それでは逆にデメリットは何かというと、一見先ほどの話と矛盾しますが、莫大な資源が要求されるわけです。フォントファイルと実行ファイルだけで、おそらくハードディスクを 25Mbyte から 30Mbyte 占領しますし、それから私が今使っているのは 486SX の 20MHz という現在ではごく普通のレベルのハードだと思いますが、それでもコンパルには一寸と苛々させられます。

それから一般的に dviファイルと呼ばれているコンパイル済の出力ファイルの中身を確認するためのプレビューアという大変便利なソフトがあるのですけれど、いかんせんこれはグラフィック処理をしていますので、大変遅いし、ズリズリと気持ち悪いスクロールをするので、その辺はもう少し使い勝手がよくなると良いと思います。まぁ、ハイレゾの広い画面へ行けばもう少し楽になるだろうという気がしています。

それからこれは決定的な障害かも知れませんが、はっきりいってインストールが大変です。これはワープロを使う時のようなインストールではちょっと済まない。そういう意味では初心者が自分でセットアップするのは非常に困難です。また、ソースを書いてコンパイルし実行するという、所謂コンパイル型の言語を使ったことが無い方も、最初とまどうかも知れません。

一方、普通に段落を区切って書かれた文章を LaTeX のソースにコンバートする plain2 というフリーソフトウエアがあります。もちろん、若干手直しが必要ですけれど。これを使えばユーザーは詳しくのコマンドのことを知らなくても一応のソースが書けるわけです。

今回、このレジュメはコマンドを入れながら書いていったわけですが、そういうのソースを普通のプレーンなファイルにするためには detex というツールがありまして、まぁ sed や AWK でチョコチョコと書ける程度のことですけれども、LaTeX のコマンドを全部剥ぎ取ってしまうようなツールもあります。ですから普段ものを書いている時はともかくも、このような発表資料をつくる時など LaTeX は大変便利だと思います。

ちょっと最初の話と矛盾するような気もするでしょうが、大きな違いをいえば、LaTeX というのは基本的にはフリーソフトウエアだという点と、98 だろうと DOS/V だろうと UNIX だろうと環境さえ整えば機種依存しない(可搬性がある)という点です。

現在流布しているものには、 NTT版と ASCII版との 2種類あるのですが、これが日本語化されていて、何人かの方がボランティアで精力的にヴァージョンアップなさっています。InterNet や商業BBS(Bulletin Board System) で入手可能ですし、ディスクの回覧という形でも配布されている様です。また、パソコン雑誌の付録に付けられたり、「縦組対応版パーソナル日本語 」(アスキー出版局、￥10,000)の様に解説書と共にフロッピー付き書籍としても売られています。

すみません、話が大分脱線して横にずれました。さて、1.2 の「データベース」の方へ行きますが、これも基本的には同じことです。先程の 60Mbyte もあるデータを「桐」に読み込んで処理するのは無謀です。たとえ可能だとしても、とても実用には堪えないのではないかと思います。そういう莫迦でかいデータを使う時に、市販のデータベースソフトというのは、ほとんど用をなさないと思います。実はデータベースソフトで行われる処理といっても、我々国文の場合はソートと検索と、場合によってはフィールドの入れ換えとか、必要なフィールドだけの印刷フォーマットに従っての出力などというレベルだと思うのですが、これはこれから申し上げる所謂ツール類で完璧に可能です。それも手軽にかつ迅速に処理可能です。

データベースソフトでサポートされている本格的なリレイショナル処理というのは、ちょっと AWK なんかだと荷が重いかもしれませんけれども、いずれにしても、大きなデータを扱うにはとにかくアプリケーションでは致命的だというふうに思います。何よりも値段が高いということもありますね。

さて、データベースのデータの方なのですが、たとえば金沢大学の木越治さんが上田秋成の研究文献目録を、ほとんど個人の労力で入力されて保守されています。これがコンマ区切りの csvファイルというプレーンなテキストで 260Kbyte 位の大きさです。それから今日会場に見えていますけれど、中央大学の鈴木俊幸さんは出版関係の文献目録をお作りになって配られています。これらのデータは、さほど大きくありませんし、普通の csvファイルですからデータベースソフトに読み込んでも使えるわけですけれども、いちいち重いソフトを起動しなくても、コマンドラインやエディタの子プロセスで grep という正規表現の使える文字列検索ツールを使えば、充分それで役に立ちます。

もうひとつは、以前配られた資料館のマイクロ資料データベースの CD-ROM ですね。これにはテーブルとかシソーラスなどのデータが随分一杯入っていますので、それらを全部剥ぎ取って純粋なデータだけにして、2byte の英数記号を 1byte にするなどの加工をしますと、だいたい 13Mbyte 位になります。ですからこれは今日持って来ていますけれど、ノートパソコンのハードディスクに十分入るわけでして、さらに場合によっては lha などというツールで圧縮しておけば、5Mbyte 程に成ってしまいます。これがあると何処へ調査へ行っても大変に便利です。

それから売り物ではありますが、『広辞苑』の CD-ROM 版と電子ブック(EB)版とが出ています。これも、基本的にはどうもハードディスクを落としてしまった方が使いやすいようです。要するに自分の必要なデータを持ち歩けるということが、たぶん一番便利なのだろうと思います。

ここからまた少し脱線しますが、たとえば資料館のマイクロ資料データなども、CD-ROM(平成元年迄)版の後をぜひ公開してほしいと思います。それから資料館の調査員を引き受けさせていただいている立場からいえば、文献調査の現場でパソコンを使って入力したり検索したり出来ると、ものすごく楽だと思うわけです。

実は、今年の夏休みに科研費を用いた共同研究の調査で、中央大学の鈴木俊幸さん達と、妻籠の脇本陣の書誌調査に参りました。その時6人のメンバー全員がノートパソコンを持って行きまして、現場で片端から打ち込んで行ってしまいました。それは異様な雰囲気の書誌調査の風景でしたが(笑)。もちろん、現場で打ち込むといっても時間的な余裕がありませんから、前もって昨年の予備調査で作成した書目に基づいて、書誌を取るべき項目を設計してフィールドを共通にした上で、データを出来るだけ入れてから行ったわけです。具体的には、レジュメの一番最後を見ていただきたいのですが、「書名」から「よみ」「書型」と、かなり細かいですけれども、あらかじめ入力出来る書誌事項を入れて現場に持って行って、実物を確認しながらデータの修正をしたり入力したりして行く、という形で実施したわけです。この事前のデータ作成に『国書総目録』も用いましたが、資料館のデータというのは、切り貼りすれば済んでしまうわけですから、大変役に立ったわけです。

大変残念なのは、資料館のマイクロ資料データベースの刊記の項目で、板元の所在が省略されてしまい、たとえば(江戸)だけなわけです。刊年に関しても同様です。これは、調査員の汗と涙と血の結晶である〈調査カード〉に基づいて入力されていないからだと仄聞して居りますが、館外の者から見ればまったく不可解なことです。また、字体も不統一なようですし、データにも大分間違いがありまして、気がつくとその都度メモを書いてお渡しするのですが、一向に直る気配がない。折角これだけ大規模なデータベースを使わせていただいていながら、やはり不安や不満はかなりあるということなのです。

にもかかわらず、いま申し上げたような使い方ができるという意味では、充分に役立たせていただいているわけですが、是非とも完全な「刊記」を〈調査カード〉から入れることと、ついでに『国書総目録』のデータベースも作成して頂いて、なおかつ調査員に配って頂きたいと思います。もちろん調査員に限らずとも良いわけですが、そうすれば、かなり調査の能率が上がるだろう思います。特に、長編合巻などの調査をやらされますと、本当に嫌気がさすわけです。数十枚の細目カードの大半の項目には同じことを書かなくてはならない、こんな莫迦げたことを何故やらなくてはいけないのか(どうせ書誌カードは死蔵されているだけだし……)などと思いながらも、日頃御世話になっている館へのお礼奉公のつもりで我慢してやるわけです。そういう意味で、パソコン上のデータで頂戴出来れば随分楽になるだろう、と思っている調査員は、決して私一人だけではないことを断言しておきます。

レジュメの下の方にゲタ(〓)があって括弧してありますが、利用者定義文字(所謂外字)の問題もあります。外字などでもひとつルールをつくっておけば、資料館の大型機では外字をどんどん作られて、それはそれで結構なことだと思うのですけれど、まあパソコンのレベルでは JIS外の外字を使わない方が良いのだろうと思います。

余談になりましたが、ぜひデータの精度を上げて行くということ、それから遡及入力的な意味合いがありますから『国書総目録』のデータを入れていただきたいということと、「刊記」を完全に入力すること、さらに、大まかで良いから「ジャンル」という項目があるとなお一層便利だろうと思います。

10万レコードを越した資料館のマイクロ資料データベースが中心にあって、それが流布して利用されることに拠ってさらに精度を高め、またそれを持って調査に出て行くというような形が理想だと思います。いま使っている細目カードの所定の位置に該当内容をプリントアウトするのもごく簡単なことだと思うので、パソコンが使えない方にはそういうカードを渡して不明な所を埋めてきてもらうという形にすれば、良いと思うわけです。

さて本題に戻って、表計算ですが、私には使い道がないので省かせて頂きます。レジュメには一寸と余計なことも書きましたが、基本的には家計簿と考えていただければ良いかと思います。家計簿も計算だけだったら、AWK とか Perl という言語で処理できます。

その他として仮名漢字変換のソフトウエアをあげておきましたが、これは、たとえば WPX と呼ばれる、今の WXII+ の前身でありますが、これはまったくコピーフリーで公開されています。ですから、たとえば学生に授業でパソコンを教えなくてはいけない羽目に陥った時には、この WXP をインストールしてやれば問題ないわけです。ちなみにフリーのエディタもあります。

長い間懸案であったハ行の四段活用ですとか、ちょっとフェイクなのですけれども文語文法での助動詞の活用なども、WXII+ で書けます。ただ近世の場合は文法通りに行きませんから、無茶苦茶になってしまうわけですけれども、とりあえずハ行四段を認識してくれるのは便利です。ソフトハウスによっては、かなり精力的に対応してくれていますし、基本的に安い。それこそ WXII+ は、￥6,000 程で買えるソフトウエアですから、これも骨までしゃぶってやれば良いのではないかと思います。

それからエディタですが、先ほどいいました Vz にはマクロという機能がありまして、ある一定の操作手順を、一見意味不明の超難解なマクロ言語で書いておくと、その通り実行するという、これも結構オタクな世界です。ただおそらく、いま必要な機能というのは、ほとんど誰かが作ったマクロが既に備わっていますので、それも公開されているのはほとんどコピーフリーですから、エディタの上で、たとえば一行60字で禁則処理に拠って整形するとか、全部旧漢字に書き換えてしまうとか、和歴の後に西暦を付け加えるなどという色々な機能が、マクロでどんどん付け足せるということなのです。新版「一太郎」にもマクロがついたらしいのですけれど、たぶん重いだろうな。

その次に、通信と書きました。これも結構大きな問題であります。所謂パソコン通信のことなんですが、このパソコン通信とかネットとかいうのは一寸変ないい方なんです。まぁ現在はそういうふうにいっているのですが、正確には BBS というべきでしょうか。パソコンを電話回線を通じて端末とし、ホストコンピュータを介して情報をやり取りする電子掲示板システムのことです。

実は私、まったく文科系の生い立ちで、情報処理の教育を受けた経験はなかったわけです。尤も、学部の頃、電子計算機概論とかいう一般教養の授業で Fortran を習い、フローチャートを書いてパンチカードの穴を空けた記憶があります。その後 BASIC や Pascal や C もかじりましたが、決して自分で自在にコードが書ける様には成りませんでした。そんな私がした体験とは次のようなものでした。

今はもうなくなってしまったのですが、アスキー株式会社のやっていた pcs という実験 BBS がありました。ここは所謂ハッカー達が集まる所でして、そこに junk.test という一週間で消えてしまっう実験用のボードがあり、とにかく「何でもあり」という活気に満ちた世界だったのです。ここで、たとえば「何々をするソフトウエアはあるか」とか、あるいは「こういうプログラムを使ってみたいのだけれど」というようなことをいうと、腕に覚えの在るハッカー達はかなり熱心にこちらの要求を聞いて、希望した仕様のソフトを作ってくれるわけです。私は本当に最初は頭が下がって、夢のような世界だと思ったのですけれども、彼等にいわせると仕様や使いみちが思い浮かばないというのです。つまり自分たちはコーティングする技術はあるけれども、何にどう使ってどうなるかということは思い浮かばないというわけですね。ですから、むしろ具体的な仕様を要求されて、そういうのを使ってみんなが便利に使ってくれれば、それは望むところだという、そういう発想の若い人たちが大勢いたわけです。残念ながら pcs は既に閉鎖されてしまったのですけれど、一時代のフリーソフトウエア文化を築いたといっても過言ではない場であったことは確かです。

実は、その pcs の junk.test で貴重な経験をしました。 grep という文字列を検索してくる便利なツールが在るのですが、これは一行単位でしか検索できない仕様なのです。ですから、途中に改行コードをはさんだ語彙というのは検索できなかったわけです。色々と不便なもので、何とかならないものかとボードに書いたら、いやそんなものは簡単だと機能を拡張するオプションを付けて貰ったツールが、次にお話する cgrep というものなのです。

2.6 の「検索」というところの下にちょっと書いておきましたが、これは、今度のシンポにもいらっしゃる様ですが、長瀬真理さんのお作りになって公開されている『源氏物語』(小学館古典文学全集版)の機械可読テキストから cocoa という、Micro-OCP 用のタグを剥ぎ取ってプレーンテキストにして、そこから「あはれ」を検索したものです。cgrep には改行コードをまたいで検索する -F オプションがありまして、このオプションをつけて「あはれ」を検索しますと、下のディスプレイの真ん中に《あは》と《れ》と泣き分かれになっている部分が出てきていると思いますが、こういうものをも検索して来てくれるのです。

ついでに、他に何か仕様の希望はないかというので、行頭のホワイトスペース、つまりタブとか 1byte や 2byte のスペースのことですが、これを無視するというオプションも付けて頂きました。

当然ですが、正規表現もサポートしていますから、もうほとんどプレーンのテキストファイル、普通の機械可読テキストであれば、どこに改行コードが入っていようと、この cgrep だけであらゆる検索が可能になってしまったのです。

この BBS では、未知の人と知り合っていく中で、新しいものが生み出されていくという大変貴重な経験をさせてもらったわけです。cgrep の作者はある国立機関に所属する研究者ですが、ペンネームとして AssistantIO と名乗られて居り、本名は明かしていらっしゃいません。

このような BBS という場で、cgrep に限らず色々なツールが日々産み出され改訂されているのです。色々とツールのメリットを申し上げたので、後は実際に使ってご覧になれば良いかと存じます。

たとえば、村上学さんは、ご自身が BASIC でお書きになったプログラムで、大変きれいな KWIC をお作りになっていらっしゃいました。C Magazin という雑誌がありまして、それに KWIC もどきの検索プログラムのソースコードが掲載されていたので、それをいじりまわして、擬似的に KWIC 風の出力をする grep のようなものを作ってみたのですが、これも場合によっては便利です。

GNU式のフリーなソフトウエアは、基本的にはソースを付けて配付されますので、自分の環境にあわせてコンパイルしなおしたり、手直ししたり、色使いが気に入らないから色を取るなど、ユーザーが自在にカスタマイズできるのです。こういう点もツールの魅力の一つだと思います。

もう時間が余りなくなってきましたので、最後にひとつだけ申し上げておきます。データそのものはプレーンで持つべきだ、ということと関係するのですが、単なる本文を機械可読化したテキストを本文データベースと呼ぶのは変なのではないか、ということです。つまり何らかの構造化がなされなければいけない、たとえば単語で区切るとか、傍注を入れるとか、何らかの形でテキストが構造化された時にはじめてデータベースといえるわけです。構造化されていないテキストは「フルテキスト」などとも呼ばれることがありますが、 MRT(Machine Readable Text) の直訳である「機械可読テキスト」といういい方は、少々こなれませんが、一番いい得て妙だと思います。やはりデータベースではなく、そういうふうに呼ぶべきだと思います。

それではどうやって構造化するかというと、基本的に一つのレコードを一行で表現して、一項目を一フィールドとして区切るわけです。区切り(デリミタ)には 1byte のコンマが良く使われるのですけれど、この各レコード間の各フィールドに整合性をもたせたデータ、これなら構造化されたデータベースと呼んで良いのではないかと思います。

そこで 2.4 の「データの構造化」のところにサンプルを出しておきました。同朋大学の服部仁さんが、学部の頃『八犬伝』を読みながら作られたノートを基に『八犬伝』の登場人物の初出一覧というのを作られました。これは「読本研究」第7輯に出された大変な労作なのですが、いかんせんワープロ専用機「Rupo」の機械依存コードや、一覧印字をするためにスペースが一杯入った、まさに構造化されていないデータでありまして、これを MS-DOS にコンバートさせてもらい、それを sed とか AWK を使いながらごちゃごちゃいたずらして、そこそこデータベースの形に直したものです。最初の番号と読みと書名と注釈と、最後に旧版岩波文庫の何巻目の何ページの何行目に出ているという形式に成っています。

これをこういうふうにコンマ区切りに直してやると、たとえば2つ目のフィールド「あまさき」とか「かぶと」「いつさく」という「読み」に注目してアイウエオ順(辞書順)に並べることが出来ます。これは「桐」なんかですと以前から出来たわけですけれども、今までフィールドソートやアイウエオ順ソートなどの機能をサポートしたソートはありませんでした。ここで使ったソートは sortf と呼ばれる北海道大学の豊島正之さんがお作りになったもので、これもヴァージョンアップが重ねられていまして、もうほとんどこれなしでは生活できない人が多いのではないかと思います。ですから構造化されたデータというのは、ツール類を用いて検索やソートをするために不可欠の形式なのです。

レジュメの最後から2番目の 2.7 の「変形」というところを見ていただきたいのですが、「新番」とか「番号」「書名」「読み」などという各フィールドに付けた見出しを剥ぎ取ってコンマ区切りに直すと斯様な形に成るわけです。つまり、データベース化したものをそのままエディタに読み込んで直したりすると、いくつめのフィールドかが分かり難く、ちょっと扱いにくいわけです。そこで、 AWK を使ってちょこちょこっと書いたプログラムで、見出しをつけた形にコンバートしてやります。その上で普通のエディタで編集して、また csvファイルに戻してやるということをすれば、データの保守管理は大変便利になります。

最近、都立大学の高橋明彦さんに教えて貰ったのですが、sortf のパラグラフソートという機能が補強されまして、この一番最後の一覧表ですが、見出しのついた一覧表のままでフィールドソートができてしまう機能が付いています。たとえば版元のところでこの大きなデータ全体をソートすれば、このカード形式のままで版元のところが揃って並んでしまう。さらに、 ygrep という拡張されたツールを用いると、ブロック全体を一行と看做した検索が可能になりますから、上の一覧表形式のままで検索も大丈夫です。これでは、もうほとんど csvファイルにする必要がなくなってしまいますね。

斯様なことはアプリケーションを用いては出来ないわざだろうと思いますが、それがツールを使えばかなり大きいデータでも迅速に可能になるし、将来 UNIX に移行しても、これらのノウハウが多分そのまま生かせるのだろうと思います。

というわけで、「アプリケーションからツールへ」という発想の下での機械可読テキストの処理についてお話させて頂きました。どうも長々と失礼致しました。

【附言】
本稿は、1993年10月に「機械可読テキストの処理 −アプリケーションからツールへ−」と題して、「第3回 国文学とデータベース研究集会」（国文学研究資料館）において口頭発表したもので、当日の講演を録音したテープから起こした原稿に全面的に手を入れ直したものである。

【追記】
本稿の内容は1993年10月の時点におけるソフト・ハードウエアの環境に拠った記述で、環境的にも多くの変化を経てしまった現時点から見ればかなり古い情報である。基本 OS の主流が MS-DOS から Windows9x へと変わってきたが、小生のアプリケーションよりツールで仕事をすると云う基本的な思想（嗜好）は変化していない。Windows を極力マウスを使わずにキーボードからだけ操作することに腐心し、エディタと LaTeX で仕事をしているのは相変らずであり html すら手でタグを附している体たらくなのである^^;