ＡＣＥ構想

リギーコーポレーション  片桐  明

　いままでＭｉｎｄで得たノウハウをもとに、エンドユーザ向けの新しいソフトを企画
する。聞き飽きた言葉ではあるが、「まったく新しいタイプのソフト」というものを考
えてみたい。


１．マン・マシン・インターフェースについて

　現在のパソコンソフトでは、マン・マシン・インターフェース（以下ＭＭＩと言う）
が優れているかがソフトの重要な評価基準になっている。
　操作する側は人間であり、対するパソコンは機械だから、その間のインターフェース
は確かにＭＭＩと言うことはできる。しかし、人間がコンピュータを「機械」として扱
うかぎり、皮肉なことにＭＭＩはある程度以上向上しないのではないかと思われる。例
をあげてみる。

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
（例１）航空券の予約をとる場面を想像してみよう、機械を使う場合、端末に向かって
キーボードやマウスを操作して希望する目的地・時間の便を予約することになるが、た
とえ、いかなる最高のＭＭＩを持ったソフト（システム）をもってしても、たとえば秘
書に向かって、「○○日の札幌行きの便をとってください」と言って済ませる安直さに
はかなわない。

（例２）区役所に行って、そこにある膨大な資料の中から、その区内に住む一人の人間
の情報を知りたいとする。この場合も同様である。どんな優れた端末をここで与えられ
るよりも、そこにいる担当者に「誰それさんについて情報を教えてください」と言うほ
うが楽で早い。

（例３）テレビ番組を作成中に、ディレクタが某所の祭りの風景を番組の中に挿入した
くなたとする。自局のビデオライブラリーから望みのシーンが入っているテープを探し
出すのに、自分で端末をたたき、場所を見つけて出かけて行くより、アシスタントに探
させるほうを望む。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

　このように、人間にとって一番てっとり早くて容易な方法は、同じ人間相手に指示を
出すことである。
　コンピュータがこれから人間にとって使いやすい相手になっていくには「機械」とし
て安住していたのでは駄目であり、「人間」に近づいていかなくてはならない。この意
味で、ひたすらＭＭＩの優秀性を単純に追求していく今のソフトの考え方では、いずれ
は使い易さへの道は壁に突き当たるはずである。

　先に区役所の例を出したが、区役所の全情報がコンピュータでアクセス可能になって
いたとしよう。現在のパソコンの先端技術であるウィンドウに、きれいに整理された住
民情報がリストアップされようと、そのファイル群の中をマウス操作でいかに簡単にブ
ラウジングできたとしても、「この人についての情報を知りたい」という素朴な要求を
前にした時、そのようなことは手段の話であり、ウインドウシステムに最先端のものを
使っているかどうか・・、使い易いマウスであるかどうか・・などは些末なことでしか
ない。

　たとえばある男が、休みで誰もいない区役所にでかけて情報を入手するとしよう。自
分で探す・・という意味において、キャビネットの一つ一つを手で開けて書類を探し回
るのも、マウスを使ってディスプレイ上を探索するのも五十歩百歩である。
　別の人が彼にこう尋ねたとする、

　　　　何をしたいのですか？

この時、男が答えるセリフが、自分のやりたいことを表わすすべてであろう。この時の
答え以外のこと・・キャビネットを開けること、マウスをどう使うか・・は手段であり
、本来の目的とは無関係である。

　現在のパソコンソフトはさしずめ、ここで言う「休日の区役所」に相当するだろう。
我々の理想はもちろん、「平日の区役所」に相当するサービスをすることである。具体
的に言えば、普通の人が「こうして欲しい」「こういうものが欲しい」と普段言ってい
る言葉そのものを手がかりにし、それよりレベルの低い作業には関与させずに満足のい
く結果を与えることである。

　平日の区役所は休日の区役所とどこが違うか・・、必要な窓口に行って担当者に頼め
ば要求することをやってくれる点である。平日であればそこに人がいて、我々は最小の
手間（エネルギー）で要求するものを達成することができるし、休日で人が居なければ
、より多くの手間を必要とする。
　このように、これからのコンピュータは「人間のように振る舞う」ことを要求される
ようになるだろうし、そうならなくては大きな発展は望めないと思われる。

　使いやすいパソコン・・という話をする時によく引き合いに出されるものとして、
「コンピュータもＴＶやラジオのように簡単に扱えるようになるべきだ」という、一見
もっともに聞こえる意見がある。コンピュータが機械であり続ける限り、あるいは、コ
ンピュータに機械としての能力のみ要求し続ける場合に限り正しい意見のように思う。
　機械に徹した、たとえば「マイコン内蔵炊飯器」はＴＶやラジオのように使うことが
できるが、それは結局炊飯器でしかなく、コンピュータと言えるのかどうかは疑問であ
る。

　すでにパソコンの能力はテレビやラジオのレベルを遙かに越えて先に進んでおり、こ
の流れをＴＶ、ラジオのレベルに戻そうと考えてみても意味がない。パソコンは既に高
度な情報処理能力を持つようになっており、処理速度や記憶量については容易に進化が
進んで行くと思われる。今後の課題は「柔軟な判断能力」「優れたＭＭＩ」といったも
のであろう。

　高度な情報処理能力、柔軟な判断能力、優れたＭＭＩを持ったモデルというものは既
にこの世に存在しており、それは人間である。パソコンの進化がどこまが行くかまだ分
からないが、「人間」をとりあえずの目標としても良いのではないだろうか。
　マン・マシン・インターフェースを純粋に考え続けるのは、当面必要なことではある
のだが、本筋ではないような気がする。むしろ「マン・マン・インターフェース」のこ
とを研究してみる必要があるように思う。これの略称は同じくＭＭＩになってしまうの
で「ヒューマン・ヒューマン・インターフェイス」ＨＨＩとでも言うのかも知れない。
そのようなものについてこれから考察してみたい。


２．現実モデル

　パソコンソフト一般に論ずると話が分散してしまうので、当面興味ある分野であるデ
ータベース関連のソフトについて考えてみる。

　現在のパソコンソフトはおおむね、デスクトップ環境をシミュレーションしたもので
ある。「ファイル」「ディレクトリ」という用語、Ｍａｃにおける「フォルダ」、ある
いは、「オープン」「クローズ」といった動作に関する用語を見ると、そういったデス
クトップ環境、あるいはオフィスルームをパソコンの中に再現し、対応させて説明しよ
うという意図がうかがえる。

　この方式は、日常的なオフィス環境をシミュレートしているだけに、一見、合理的な
モデル設定のように思えるが、実は日常環境のシミュレーションであるがゆえの欠点も
持ち合わせていることを知る必要がありそうだ。
　良く経験することだが、書類をどこの棚に入れたか忘れてしまうこと、あるいは、そ
もそも、その書類を入れたかどうか忘れてしまうこともある。
　また古い書類の破棄などもなおざりにされがちであり、満杯になった書棚の整理など
は、忙しい毎日の中では意を決して時間をかけるぐらいの気力が必要となる。

　パソコンを使ったデータベースもまったく同じ問題を抱えている。パソコン上に存在
するデータベースファイルがたった一つの場合には問題ないが、個人住所録、取引先一
覧、趣味の会の会員名簿・・と増えるにしたがって、あるいは初年度、２年度・・・と
年度ごとのファイルに分散が始まるにしたがって、ファイルは無数に増えていく。この
様子はちょうど、机の上の書類入れ−−ファイル−−が机の上に溢れんばかりになった
状態とあまり違いがない。

　ファイルさえ特定できれば、そのあとのデータ検索では無類のパワーを発揮するデー
タベースソフトも、肝心のファイルがどれなのか分からなければ、まったく手が出ない
という欠陥は、「大量のデータを合理的に管理」するはずのデータベースソフトとして
は皮肉という言うほかはない。

　ＯＳ管理下で走行するようなデータベースでは、データファイルも当然、ＯＳ管理下
のファイルとして生成されることが普通であり、ファイル数が増えて手に追えなくなっ
た場合には、サブディレクトリを切るなどで管理を容易にするようユーザ側で対処する
道が提供されてはいる。しかし、ユーザが切ったディレクトリ状況自体をデータベース
ソフトが把握してくれることは少なく、そのディレクトリの数が多くなったり、サブデ
ィレクトリが深くなって何層にもなった場合に、やはりこれもデータベースソフトは救
済してはくれない。（データベースソフトが、ディスク内のディレクトリ編成について
仮定を持ち込むことは許されないだろうから、このあたりをデータベースソフトのせい
にするのは酷ではある）

　前回で、区役所での区民情報の検索を例に出したが、あのケースに当てはめると次の
ようになるだろう。
　住民の一人に関するデータが欲しいとする。コンピュータ化されていない区役所では
無数の数のキャビネットのうちの一つを特定し、それを開けて該当者の資料を探す・・
といった手順になると思う。

　この「キャビネット」は、物理的な収容能力の問題で複数に分かれているだけであり
、本来であれば「住民台帳」とでも言う巨大なキャビネット一つの中に収容したい所で
あろう。
　コンピュータ化された区役所では、おそらく「住民台帳」を一つのファイルに集中さ
せるぐらいはやっているはずである。この点は検索速度と並び、コンピュータ処理のほ
うが圧倒的に有利になる優位性の一つだ。

　しかしここでも恐らく、データファイルの複数化の問題は有るのではないかと思う。
住民台帳以外にも、たとえば外人登録、課税、福祉、（有るかどうか知らないが）犬猫
の登録など、思い付くだけでもかなりの数に上りそうである。先にも言ったように、こ
れらを縦横に結んだような超高機能なシステムは、たぶん（プログラミングによる）設
計は可能だろうが、データベースソフトが基本的に持つ能力に限定した話をした場合、
先の話と同様に「一体どのファイルに入っているのか」と迷う場面は有りそうである。
　少し譲って、この高機能システムが使える状態も話に含めるにしても、そのシステム
を操作できる人間は、やはりそれ専門の人間が操作するのであって、訪れた市民が端末
を借りてちょいと動かすレベルではないだろう。


３．人間モデル

　データベースを、人間をモデルにして設計した場合にどうなるかを考えてみる。現在
の技術レベルでどの程度が可能かは当面考えないことにする。
　人間がやっている記憶やその引き出しについては二つのケースがある。自分自身の頭
への記憶が一つで、メモや日記など外部記憶装置とでも言うべきものに記憶するのがも
う一つの手段である。

　人は自分自身を含めて、自分と深い関係のある事項をかなり大量に記憶しているが、
他人のことになると、詳細かつ正確な記憶は難しくなってくる。しかも今はパソコンソ
フトのことを考えているのだから、ここで「自分の記憶能力を高める」といった話をし
てみても始まらない。
　すると残りは「外部記憶装置」ということになる。
　住所録などは一番馴染みのあるものだが、この住所録をそのままコンピュータ上で実
現したのでは前回の「現実モデル」と同じになってしまう。せっかくコンピュータが目
の前にあるのだからもっと気の効いた人間的なやり方を考えたい。

　「生き字引き」という呼び方がある。その人に聞けば、どんなことでも知っていて教
えてくれる。自分自身の頭に記憶するわけではないのだから、これも一種の外部記憶装
置と考えて良いだろう。しかし、利用する側から見れば「外部」だが、生き字引き氏に
とっては「内部記憶」ということになる。

　これは理想的なシステムのように思える。
　まず、現実モデルのように、ファイルをどこに置いたか・・といったことを覚えてお
く必要はない。もちろん「サブディレクトリ」といったややこしいものもない。
　こちらから見れば、生き字引き氏は「ブラックボックス」であり、少なくとも利用す
るサイドから見たら、データがどのように蓄えられているか、データ（ファイル）のフ
ォーマットはどのようになっているか、そのデータを引き出すにはどのような検索をし
たら良いか・・など、細かな手段については一切関知する必要が無い。自分が知りたい
ことを一言彼に伝えれば良いのである。ただそれだけで答えをもらうことができる。

　「ファイル」や「ディレクトリ」といったものが存在しない点では、もちろん自分の
頭での記憶も同様である。人間の頭の記憶方法は、たとえば「家族に関する情報はこの
ファイルに」「自分の生い立ちに関する情報はこのファイルに」「スポーツはここに」
などと言いながら、区分けした場所に記憶しているわけではない。

　これは考えてみればあまりにも当然なことなのだが、データフォーマットだとか格納
場所（ファイル）といったものは、物理的な要請から出て来ているにすぎない。
　例えば現実社会での「住所録」「メモ帳」は物理的に重さや体積を必要とすることか
ら、データフォーマット（「Ａ４縦４００頁」といったもの）が規定されてしまい、そ
の置き場所にも注意しなくてはならない。１０年分の日記は１０冊の分冊になってしま
うことにもなる。これは現実社会をそのままモデルにしたパソコンソフトもまったく同
様であり、同じ問題を抱えていることは前回考察した通りである。

　とにかく人間の場合はもっと柔軟な記憶方式をとっているらしく、そういった物理的
制約は極めて少ない。
　再度まとめてみると次のような特徴がある。

　　　　・データ形式という概念が無い
　　　　・記憶場所とかファイルという概念が無い（単一の場所にすべて記憶される）
　　　　・連想で複数の記憶を引き出すことができる

　自分自身がこのようにして日常生活を営んでいるわけだから、まさにこのような概念
で「外部記憶装置」もアクセスできればそれが一番理想的であることは言うまでもない
だろう。外部記憶なので自分の頭は使わない、しかし自分の頭のように気軽にアクセス
ができる・・それが生き字引き氏を利用することで可能になる。

　区役所の例を以前に出したが、その区内に住むある人物についての情報を知りたい時
、平日に区役所の窓口に行って担当者に頼むのが一番てっとり早いことを述べた。しか
し現実の社会はそんなにてっとり早くはない。区役所の中は幾つもの課に分かれており
、フロアも何階にも分かれている。その中から自分の目的に合致した課を見つけて正し
い窓口までたどり付かなくなはならない。

　このあたりを全部コンピュータの世界に当てはめた場合、先の生き字引き的考え方を
するならば、もっと理想なシステムができる。
　コンピュータでモデル化するのであれば、どのみち仮想の世界なのだから、より改善
可能である。複数の課は廃止、担当者も一人にしてしまうのである。それがアクセスす
る側から見たら一番楽な方法であろう。
　たとえて言うならば、区役所に入ってすぐの所に一人の「生き字引き氏」が座ってお
り、いつでも相手をしてくれる・・といった世界である。（区役所と言うよりは宝くじ
売場に近い）
　
　現代のコンピュータのＧＵＩは、こういった発想とは違う方面に応用されている。
　区役所の中に高速なエスカレータやエレベータを設置したり、絵文字を使った分かり
やすい案内板を入口に設けて、全窓口の場所がすぐわかるようにしたり・・そういった
方面での改善ばかりが目立つように思う。ＡＣＥではこのあたり、大きな発想の転換を
考えてみたい。


４．システムの構想

４−１　データ構造について

　ＡＣＥの性格を「新しいタイプのデーターベースソフト」という位置付けにし、その
具体的な面について考える。
　次の例は既存のデーターベースを想定したデータ構造である。知人に関する情報管理
だと思って頂きたい。

　　属性　　→　氏名　　職業　　　　住所　　　　電話番号　　　年令
　　　　　　　　−−−−−−−−−−−−−−−−−−−−−−−−−
　　レコード→　木村明　プログラマ　東京都・・　03-123-4567 　３５
　　　　　　　　・・・　・・・・・　・・・・・　・・・・・　　・・
　　　　　　　　・・・　・・・・・　・・・・・　・・・・・　　・・

　データベースソフトを使うには、まず最初に上のようななデータ構造の定義から始ま
る。リレーショナル型かカード型かによって操作方法は変わるが、おおむね似たような
ものである。
　ここで、このデータ構造もまた、例の現実モデルを映したものと見ることができる。
　ＲＤＢでは「表」という言葉がよく使われているが、まさに紙に書いたものと似たよ
うな「表」をモデルにしている。

　次に人間の場合を考えてみよう。私がある日、木村さんという人と知り合いになった
とする。人間の場合、「まずデータ構造を設計して・・」などとは考えない。

　　　　・○月△日に木村さんに会った
　　　　・面白い人だ
　　　　・眼鏡をかけていた

というような、幾つかの事実だけがポンポンと頭の中に放り込まれていく。上の三つの
事実はいずれも同一人物「木村さん」に関する情報であるが、それがどのような場所に
「格納」されているかは知るよしもないし、知る必要もない。あとでこれらを思い出す
ことが出来れば良いのである。
　後日、新しい情報が追加されたり修正されることもあるが、その場合も、「情報の格
納場所を見つけてその項目を直す」という意識は極めて薄い。

　前者と後者の例の違いは情報格納場所の考え方だけではない。「属性」に関する概念
が相当違うように思う。
　ＲＤＢにおけるデータの構造の定義というと、正規化されたリレーション（表）の構
築といった厳密な定義の話が出てきそうだが、簡単に言ってしまえば属性を定義するこ
とにほかならない。

　どの程度の属性を予測するのか、それらはどのような値の範囲を取り得るのか・・と
いったことを、「データがやって来る前に」充分な吟味の上で決定しておかなくてはな
らない。先の例では「氏名」「職業」「住所」といったものを決めておくわけだが、そ
のあとで突然、「眼鏡をかけている」という情報が飛び込んで来ても、それを受け付け
ることができない。その情報は予測されなかった属性であり、格納すべき場所が無いか
らである。

　実際には「備考」とかいう名称で何でも書き込める属性を入れておくという運用面で
の逃げ道はあるが、当然ながらそのような属性は他の属性と同じようには検索すること
はできず、種々雑多な情報がとんどん入り込んで来た場合には備考欄のほうが大きいと
いった事態にもなりかねない。

　ＡＣＥはもちろん後者の「人間モデル」を考える。予めデータ構造を定義しておく必
要はなく、まったくゼロの状態からデータベースがスタートする。
　属性はデータが来た時に決まることになる。それは住所や氏名のような、よくある属
性でも良いし、「眼鏡をかけていた」「黄色い服を着ていた」といった突飛な属性でも
まったく構わない。


４−２　情報の管理方法

　前回、ＡＣＥは「生き字引き」モデルであると定義した。一般的にこの言葉は「情報
の引き出し」にだけ注目するニュアンスが強いが、当然ながら情報のインプットもやっ
てもらう必要がある。
　さて、情報のインプット（記憶）時のフォーマットであるが、前回、「データ形式と
いう概念は無い」などと述べたが、それは外部仕様としてデータ形式を利用者が意識し
ない・・というだけであり、当然ながら内部的には必要である。
　なんら脈絡のないデータをどんどん生き字引き氏に放り込むのでは、彼は単なる情報
のゴミ捨て場になってしまい、それはデータベースとは言えない。
　ＬＩＳＰ言語にみれらるような、非常にフレキシブルなデータ管理が必要になるかと
思うが、具体的にはまだアイデアは無い。


４−３　操作形態

　少し話が飛ぶが、ＡＣＥはどうやって動かすのかを少し見ておく。

■メニューレス
　原則としてＡＣＥはメニューを持たないか、非常に少ないものになるだろう。
　くどいようだが今まで述べたように、メニューを持ったシステムは「現実モデル」で
あり、メニューを取り入れた瞬間に「人間モデル」から離れてしまう。
　人間同士が会話をする時にメニューなど出てこない・・それと同じである。コンピュ
ータと利用者との言語によるインターフェースがうまく実現すればメニューは少なくで
きるのではないかと思う。

　メニューレスということは、命令・指示・操作体系が１層しかない・・ということに
なる。あらゆるシステムとの対話は、単一のモードでおこなうことになる。また、メニ
ューレスで自然言語対話をするとなると、ユーザからの言葉（指示）から（暗黙に指図
されたことも含め）すべてのことを理解しなくてはならない。
　ある指示はメモであったり、ある指示は質問文であったりする。その質問文も、どう
いったデータに関する質問かをメニューで選ばせることはできないから、質問文自身か
ら推測する必要があろう。

■文の種類
　生き字引き氏に対しての利用者の操作は、極めて単純で、日本語の文をキーボードか
ら入力する・・ただそれだけである。システムはそれに適切な対応をするはずである。
文字通り「対話型」で処理が進んでいく。
　入力する文は、

　　　　１．「事実」を伝えることで情報のインプットをすること
　　　　２．「質問文」を出すことで情報のアウトプットをすること

のように大きく分けることが出来るだろう。他にもあると思うが、とりあえず上記のい
ずれを利用者が指示しているかぐらいは判別できないといけない。
　１と２の判別はそれほど難しくないように思える。例えば、

　　　　・・・・・ですか
　　　　・・・・・か
　　　　・・・・・か？

のような文末を検出することで「質問文」かどうかをまず判断し、それ以外の場合は
「事実」の入力だと区別すれば良いかも知れない。


４−４　属性の自動検出

　前回（その４）の話の続きに戻ることにする。
　事実の入力、あるいは質問文の入力において、属性は省かれても良いようにしておく
必要がある。前回を例にとれば、

　　　　木村さんの職業はプログラマです

という文が入力されることで、木村さんというレコードに対して、その「職業」という
属性に関する記述であると判断でき、システムはその属性値として「プログラマ」を記
憶することができる。しかし、日常的には、

　　　　木村さんはプログラマです

のような表現をされることのほうが多い。属性が省略されているがこれは重要なことで
ある。もっと極端な例を挙げれば、

　　　　鈴木さんは太っています　　　　　　　　　（イ）

という例がある。これはあえて言い換えれば、

　　　　鈴木さんの体格は太っています

ということになるだろうが、「体格は」を明示してくれる場合は少ない。
　一般的なＲＤＢでは、（イ）のような表現は確実に文法エラーである。かならず、

　　　　属性＝値

の形態で情報を入力しなくてはならない。「太っている」を単に指示することは許され
ない。（もっと言えば、データベースファイルもまた特定する必要がある）

　しかしＡＣＥは外部仕様上はフォーマットレスであることから、ＡＣＥ自身が「鈴木
さんは太っている」という文から、ある場合は新しく「鈴木さん」のレコードを追加登
録する必要があるだろうし、既に鈴木さんに関する情報が存在する場合には、その中に
新たに「体格」という属性およびその属性値「太っている」を追加しなくてはならない
。これらの仕事を最初の事実指示文が入った段階で一気に片づけるわけである。

　うっかりしていたが、実は「鈴木さんの」という語もまた省略された表現である。厳
密には、

　　　　氏名が鈴木さんの体格は太っています　　　（ロ）

とするべきところなのだろうが、とてもこれでは自然な表現とは言えないだろう。

　整理してみる。問題は属性をどの程度自動的に把握できるかにかかっている。
　まず（イ）の文から得られる単語は二つしかない。「鈴木さん」「太っている」の二
つである。「鈴木さん」という文節には「さん」という送り仮名が付いていることから
、この属性は人名であるぐらいは予測できるだろう。これは簡単そうである。（このほ
かにも「ちゃん」「氏」「様」「殿」などが人名を示すキーワードとして考えられる）

　問題は「太っている」の文節である。「太っている」という形容詞から「体格」とい
う常識的な属性を判断するには、ある種の辞書が必要になるだろう。
　また、属性の自動判定とこれと関係することだが、シソーラス（同義語辞書）もまた
た必須となる。一般的なデータベースでは、シソーラスはデータ本体のキーワード検索
に用いられるものだが、ＡＣＥにおいてはむしろ、データ本体よりも属性判断のために
積極的に使われることになるだろう。

　ところで、事実のインプットは、実は質問文にもなる。

　　　　鈴木さんは痩せている　　　　　　（ハ）

（イ）の文が入力されたあとに（ハ）の文が入力されたとすると、

　　　　いいえ、太っています　　　　　　（ニ）

という答えをシステムが返すことができるかも知れない。これは、外見上は事実の入力
でありながら質問を兼ねることができる可能性を示している。（Ｐｒｏｌｏｇで似たよ
うな機能があったように思う）
　このような機能を装備するにも、「太っている」が「体格」という属性の一つの値で
あり、しかも「太っている」という状態は「痩せている」とうい状態とは排他的な関係
にあることをシステムが把握している必要がある。属性辞書にはそのような情報も必要
となるが、シソーラスとの連携で動くべきかも知れない。

　次の文はどうだろう。

　　　　鈴木さんは男性です　　　　　　　（ホ）

上記（ホ）の文が入力される以前に、「鈴木さんは太っています」または「鈴木さんは
痩せています」のどちらの文が入っていようとも、（ホ）はそれらの事実とは独立して
受け入れることができる。体格の属性と性別の属性は独立しているからである。
　しつこいようだが、上記（ホ）のあとで、

　　　　鈴木さんは女性です　　　　　　　（ヘ）

を入力したら、これは「ちがいます」というエラーを返す必要がある。

　ところで、属性が必ず明示される場合もあるようだ。例えば、

　　　　鈴木さんの電話番号は03-123-4567です 　　（ト）

というようなケースで、「電話番号は」を省いて発音する日本人は居ないだろう。


４−５　属性の上下関係

　たとえば、

　　　　鈴木さんの趣味はテニスです　　　　　　　（チ）

という事実が入力されている時、

　　　　鈴木さんの趣味はスポーツです　　　　　　（リ）

をどのように扱うかは難しい問題だ。これは属性値に包含関係がある場合である。
　このほかにも、　花が好き＜植物が好き、　日本酒が好き＜酒が好き　のような例が
挙げられる。


４−６　数詞の扱いと単位系

　あらかじめデータ構造が定義されるわけではないので、事実のインプットにおける数
量の単位もまた自動的に決定する必要がある。このようなものは一般のデータベースで
はまったく問題にならなかった部分である（裏を返すと、ユーザに管理させていたわけ
である）。たとえば、
　
　　　　木村さんの体重は６０キロです

のような文を受け付ける必要があるだろう。「キロ」は「Ｋｇ」かも知れない。
　「体重はキロ単位である」を仮想するようなことも注意しないといけない。乳児はグ
ラム単位で言うことが多い。
　自動車の排気量は「ｃｃ」が多かったが、最近になって「リッター」で言うことも多
くなってきている。時間の経過を時／分／秒で言ってみたり、分換算で言う場合もある
だろう。
　もう少し複雑な例では、

　　　　人口千人当たりの医師の数

というような複雑な属性もあるかも知れない。（こんなものは無理だとは思うが、一応
難しい例として挙げておく）。この値は人数のように見えるが、正確な単位は人数では
なく、値は小数表現になることがある。

　この話と関係するが、単位系も考慮する必要があるかも知れない。インチ／センチや
フィート／メートル、ポンドとグラムの関係なとである。ただこれについては、一つ一
つのデータで「単位系が何であるか」まで記憶する必要はないように思う。日本で標準
的な単位系で統一しておき，必要に応じて換算して答えれば良いだろう。


４−７　言い回しの違いと否定文

　次の文をご覧頂きたい。

　　　　薔薇の花の色は赤です
　　　　薔薇の花は赤色です

　このあたりの扱いをどうするかも慎重に決める必要があるように思う。
　これとは違うが、否定文に対する応答能力も持っている必要がある。（Ｍｉｎｄの場
合はプログラムだったから否定文についてはまったく考える必要がなかったが・・）
　例えば、

　　　　鈴木さんは太っていません

という文をうまく処理してやる必要がある。「太っていない→痩せている」は少し乱暴
な推測だろうから、この場合には「普通か痩せている」のような判定をさせたいところ
だ。


４−８　既存のデータベース言語との比較

　話が重複するが、データ検索の例を示すことで現在のデータベースソフトとＡＣＥの
違いを比較してみる。

　　　　SELECT　筆者,標題,出版社
　　　　　　FROM　文献表　　　　　　　　　（「パソコンＲＤＭＳ比較言語論」
　　　　　　　　WHERE 価格 >=1500 　　　　　ＣＱ出版社より）
　　　　　　　　  AND 出版社='Ｃ社'

　上記はＯＲＡＣＬＥによる検索例である。この本によると次のことをやりたいのだと
言っている。（実際にこの文献中にある記述である）

　　　　価格が１５００円以上で、出版社がＣ社の文献を検索する

　自然言語によるデータ検索を目指すならば、まず上記のような文でそのまま通用する
ように設計することはもちろんであるが、これではまだＡＣＥの思想には合致しない。
　次のような文が使えることが最終目標である。

　　　　１５００円以上のＣ社の文献

　この違いが「フォーマットレス」であることの違いである。後者では「価格が」と「
出版社が」という単語が省略されている。


４−９　属性の理解

　現在のデーターベースは、非常に高度なデータベースであっても、その蓄積されてい
る属性や属性値をシステムが勝手に「理解」することは無い。たとえば、住所の項目に
電話番号が書き込まれてもシステムは文句を言わない。年令として２００才を記入した
場合も同様である。

　「氏名が鈴木さんのレコードの電話番号を表示」ぐらいの検索機能は、このような自
然言語的表現が出来るかどうかは別として現在のデータベースは備えているが、これは
システムがデータベースの内容を「理解」しているからではなくて、ちょうど表計算ソ
フトが全カラムの合計を計算できるのと同じように、特定のフィールドを検索して、一
致箇所の一覧を出しているに過ぎない。

　しかし、生き字引き方式を目指すかぎりは、ある程度、このあたりの領域−−属性や
属性値に介入すること−−に踏み込む必要があるだろう。
　データの理解については、これを完璧にやろうとしたら日本人の「一般常識」をすべ
て最初から用意する必要があり、膨大なシステムになってしまい、現実的ではないだろ
う。どこかで妥協点を探す必要がある。


４−１０　柔軟性の持たせ方

　フォーマトレスということは、あとになってからいくらでも新しい属性や属性値を追
加できる・・というメリットがある。
　「体格」という属性について、「太っている」「普通」「痩せている」という設定を
して、しばらく使っているうちに、「少し太っている」というような評価を追加するこ
とはたやすいだろう。
　また、既存のＲＤＢに比べて明らかに優位になるのは、突飛なデータの追加である。
　たとえば、知人に関する情報を蓄積している中で、いきりなり、

　　　　鈴木さんのお父さんの趣味は盆栽です

を入力することができる。「・・の・・の・・は」という構文から、コブのように分岐
したな新しいレコードが追加されることになるだろう。
　既存のＲＤＢではこのような情報入力は不可能である。入力できるようにするにはレ
コードフォーマットを再設計し、知人のレコードに「母の趣味」「父の趣味」といった
属性を（多くの場合、空欄ばかりになる属性欄を）追加しなくてはならない。

　もう一つ、すべてのデータが単一で記憶されることから、そのシステムが記憶してい
るすべてのことがらを、いきなり尋ねることができる。
　つい直前まで知人に関するデータを検索していたのに、突然、ビジネス情報−−たと
えば来週の出張予定−−といったものを尋ねても良い。普通のＲＤＢでは、個人ファイ
ルを一旦クローズして、出張予定ファイルをオープンする・・といった操作が必要にな
るところである。



（さいごに）

　ざっと眺めただけで、以上のようないろいろな問題があるが現在の技術レベルで不可
能ではないように思う。むしろいままでこのような発想が無かったために、この方面で
ノウハウが少ないということかも知れない。先に例に挙げたが「鈴木さん」という文節
を検出した時、「さん」という送り仮名から「鈴木」が人名であることを認識する・・
といった、ごく簡単ですむような技術さえも、まだ他のソフトではやっていないように
思う。

　巨大なデータ量を完全な定型業務で処理する・・といった分野では、既存のデータベ
ースソフトやＣＯＢＯＬのようなものに任せ、これはもっと違う場面で使われるほうが
向いているように思う。とりあえず浮かぶのは個人用途である。


※　構想終わり　※