El mundo que soñé

まずは、前回の補足。
・エキスパートシステムの目指すところ目標が高すぎ、期待が大きすぎた。
→1980年代には、R1/XCONなどビジネス的にも成功したエキスパートシステムが作られることで、後に続くシステムは人間のエキスパートに匹敵するような高い性能を期待されることとなりました。しかし、多くの場合ある程度の結果までは出せるものの、期待ほどの性能まではなかなか到達できず、必要以上にチューニングすることで、前回述べたようにルールベースは複雑化(スパゲティ化？)していきました。

このようなときの最終的な落としどころとしては、たいがい人間のエキスパートが出す解に匹敵するような解を自動的に得るというところはあきらめ、システムでは目標解の7,8割程度の解を出し、あとは人間のエキスパートが修正して適切な解を求めるという「(人間の)エキスパート支援システム」というところに落ち着くのが普通でした。

ところで、前回の表題は「エキスパートシステムの思ひ出１(なぜ今またルールベースに光があたっているのか)」でしたが、どうも思い出話ばかりで、「なぜ今またルールベースに光があたっているのか」というところに関しては、あまり書いていないことに気がつきました。これはまさに後ろの方でちょっと書いている、ルールベースが、複雑な条件分岐を書きやすく変更しやすいプログラミングパラダイム(テクニック)であるという認識が広まってきたということに尽きるのではないかと思います。
では、なぜそれが今頃になってという疑問が湧くでしょう。ルールベースが上記の性質を持つということは、エキスパートシステム全盛の時代から考え方としては当然のことと認識はされていましたが・・・この辺が次にあげるエキスパートシステムブームが去っていった理由その２に関わってきます。ということで、その２

・ブーム時代のエキスパートシステムは、スタンドアローンで作られることが多い一方、判断に必要なデータは基幹のシステムの中にあり、それらの間の連携に手間がかかった。

→ブーム時代のエキスパートシステム構築ツールが稼動する環境は、多くの場合ワークステーション(DECとか、Sunとか、News!とか)や場合によっては Symbolics の Lisp マシンとか。一方で基幹のシステムはIBM、富士通、日立などの汎用機。それぞれ独自のネットワーク環境があってその間のデータの連携に手間がかかりました。一度フロッピー(→瀕死語)に落として渡したり、場合によっては再度手入力をしたり・・・現在のようにネットワークでデータを容易に受け渡しできるような環境と違い、データの受け渡しで工数がかかり、その割にはシステムそのもののパフォーマンスはあがらないし・・・ということでコスト・ベネフィットを考えるとあまり割に合わないという状態でした。

(ちなみにエキスパートシステムのことを書いているうちに思い出した話として・・・エキスパートシステムと言えば、ひとつの典型的なシステム類型に「故障診断システム」というのがあります。その昔ある会社で、パイロット的に機械の故障診断エキスパートシステムを作ったのですが・・・そもそもその機械は出来が良くほとんど故障しないのでシステムの出番がまったくなかったという話を聞いたことがあります。)

そしてそのころから十数年経っている今。現在のBRMSでは、たとえば基幹システムで普通に使われている「Java」と普通に連携できますし(Javaのオブジェクトがそのままファクトになる)、またルール部分をWebサービス化してサービスとして扱うこともできます。また、コンピュータのハード的に見てもメモリ容量が飛躍的に増え、その昔「メモリ食い虫」であったエキスパートシステムを十分な余裕をもって実行できるようになりました。(今は、ごく普通のアプリケーションが昔のエキスパートシステム並み、あるいはそれ以上のメモリを使うようになっていますし。)
こうなってくると、ルールベースの適用に対する敷居は十分に低くなってきます。エキスパートシステム全盛の時代には、ルールベースというと、それだけである程度のまとまったシステムを作ることを意味していましたが、今の時代のルールベースは、普通の基幹システムの中でルールで書きやすい部分をルールで書いて埋め込んだり、Webサービスとしてサービス化することが可能となっています。基幹システムの再構築プロジェクトで、レガシー化した基幹システムからルール部分を取り出して(ルールのマイニング)見える化し、同時に変更にも強いシステムとするということなど、一昔前には考えにくかったことが今はひとつの流行ともなっています。

実は、私が最初に仕事で扱ったのはDEC(今は最終的にHPに吸収されましたが)のワークステーションにのっていた「OPS5」でありまして、仕事として後から手続き的な言語を扱ったので、ときに複雑な条件分岐に出会うと「こんなものルールで書けばわかりやすいのに」と思ったこともありました。また、時間割の割付システムのプロトタイプを作成したときなど、VB3(!)でUIをつくり、ルールエンジンは「Clips」、でその間を連携するのにdllを作ったり(?だったと思う)やたらと面倒だったことを覚えています。

それに比べれば、今は天国、「私の夢見た世界」ですわ。(ちょっと大げさですが・・・)

ルールベースシステムと言うと、かつてはエキスパートシステム、今はBRMSということになるでしょう。知っている方は知っているかと思いますがエキスパートシステムと言えば、一時は産業界への人工知能応用の旗手としてもてはやされていた技術でした。

(・・・「でした」とか「思ひ出」とか書くと、過去の技術のように思われてしまいますが今も技術としては、いろいろなところで地味に使われています)

しかし、あれほど脚光を浴びたエキスパートシステムも次第に尻すぼみになってしまう一方、また、エキスパートシステムの技術とともに育ってきたルールベースの技術は、今再び光を当てられ、今までのエキスパートシステムとは微妙に違う(と私は思います)分野でBRMSとして使われるようになってきています。

ここでは、なぜかつてのエキスパートシステムが尻すぼみとなったか、逆になぜルールベースが今また流行りつつあるのか、かつて生産計画関連のシステムに携わっていた者として、その時代のエキスパートシステムと今のBRMSとの違いを見ながらちょっとまとめてみようかと思います。(昔エキスパートシステムでルールベースをごりごり書いていて、今更何でルールベース？と言っている方のために・・・)

　まずは、エキスパートシステムブームが去っていった理由として、この辺はさまざまな意見があるかと思いますが、個人的には以下のようなところかなと思っています。まず一つめ。

・エキスパートシステムは、人間のエキスパートのアドホックな知識をルール化していくことでプロトタイピングで作っていったが、ルールの連鎖が次第に把握できなくなりメンテしきれなくなった

　→ルールベースシステムは、ルールを組み合わせてシステムを構築していくので、比較的追加・変更がしやすく、その性質からプロトタイピング的にシステムが作られていくことが普通でした。エキスパートシステムの構築もその例にもれず、まずは小さなシステムを作成し、人間のエキスパートによる解と比較評価しながらエキスパートから足りないルールを引き出して徐々に成長させていくというのが開発方法論でした。

　そのころルールベースシステムは、複雑な条件判断を含んだり明確な決まったアルゴリズムが存在しないような問題に対し適していると言われていました。もちろん通常の手続き型の言語で書くよりは適していると言えるのですが、そもそも複雑な問題はどのような手段でも複雑であって、やはりあまりに大規模で複雑な問題に対してはルールベースで書いたところで複雑になります(たぶん手続き型言語で書くよりは格段に単純化できるとは思いますが)

　エキスパートシステムも最初は人がハンドリングできる程度の小さなシステムであっても、エキスパートのきちんと整理しにくいアドホックな知識を次々ルール化して問題解決力をチューンナップしていく過程で、規模が大きくなってきたときに次第にルールのメンテナンスができなくなるのはある意味当然のことかもしれません。

　同じような言い方ですが、その昔システムが解決しようとする問題には、良い構造の(well-structured)問題と、悪い構造の(ill-structured)問題のふたつがあり、エキスパートシステムが特にターゲットとしているのは、この悪い構造の問題であると説明されていました。

　ここで良い構造の問題というのは、明確で決まったアルゴリズムがあって、それに沿って実行していけば解答が得られる問題で、悪い構造の問題というのは明確なアルゴリズムを持たない、たとえば専門家が勘と経験に頼って判断したり解決している問題です(生産計画とか設計とか診断とか)。

　エキスパートシステムが主に対象とするのはこのような悪い構造の問題なのでルールをきちんと整理するのも難しく、こういった面でもメンテに影響が出てきたのは想像に難くないでしょう。

では一方、今のBRMSはそこのところどうなのかと考えてみると

・現在のBRMSの使い方の主流は、上で言う「良い構造を持った問題」であるが、条件分岐などが複雑で、また変更が多い場合に使われています。手続き型の if-then で書けば書けるだけの明確なアルゴリズムにはなるはずだが、条件分岐が複雑で変更があった場合を考えると、ちょっと手続き的に書くのはしんどいなあ・・・という場合がそうでしょう。携帯電話の料金計算とか、保険の審査とかルールは明確に決まっているが複雑というのがまさにそうでしょう(ただこの中に、ルールを四角四面に解釈せず多少てごころを加えるなどという「エキスパート的な」話が入ってくるととたんに上であげた「悪い構造の問題」になってきます)。
　そういう意味では現在のBRMSは、ルールベースプログラミングを、複雑な条件分岐を書きやすく変更しやすいプログラミングパラダイム(テクニック)として使っていると言えましょう。

　実は、現在のBRMS は、ルールベースの言語として見た場合、その昔の OPS5 や Clips と本質的に変わっているわけではありません。ツールとして行えることは、本質的にはエキスパートシステム華やかなりし時代と何ら変わっていないので、昔と同じことをやろうとすれば程度の差こそあれ同じように袋小路に入っていくというのは今も昔も変わりません。まあ、結局昔も今も複雑なものは複雑だということでしょうか。

ルールエンジン・・・ここ最近注目を集めていますが、技術そのものはそれほど新しいものではないことをご存知のかたも多いでしょう。世間にはさまざまなルールエンジンがありますが、そのルーツは・・・とたどってみたらこんなページがありました。

BRE家系図2008

頻繁に更新されているようなので、ときどき見てみると新たな発見があります。またARTとかKEEとか、懐かしい人には懐かしい名前も。私もBlaze Advisorのルーツが昔々ちょっと弄ったことのあるNexpert Objectであることをこの図ではじめて知りました。ちょっとおもしろいページでした。