ビジネスルール管理システムとエキスパートシステム(4)

(前項に続く)

さて、次の違いを見てみましょう。これはむしろ周辺環境の時代変化による違いだとも言えますが、

3.エキスパートシステムが流行っていた時代と比べて、コンピュータの性能が格段にアップし、メモリなどのリソースも潤沢となっている。

ルールエンジンというものは一般的に通常のアプリケーションよりメモリを食います。以前、ルールエンジンのコアアルゴリズムとして一般的なReteアルゴリズムについて書きましたが、このReteアルゴリズムではデータとルールの条件部分とのマッチング速度を稼ぐために、ルールとデータの部分的なマッチング状態もメモリ上に保持しているので、メモリを食わないわけがないというわけです。
この問題、昔は結構制約となる問題で、そのおかげでエキスパートシステムはリソースの豊富なワークステーションでしか動かせなかったりしたものでした。しかし現在はPCでも普通にギガレベルのメモリを積みCPUの速さも格段に速くなったので、それなりの大きさの問題をPC上で動かせるようになっています。PCが開発環境や運用環境に利用できるようになったことで、ルールエンジンは、以前に比べずいぶんと身近になったと言えましょう。
そんな身近になったルールエンジンですが、このルールエンジン、アルゴリズム上、比較的単純なことを行うにもメモリやCPUパワーなどのリソースを通常のアプリよりも贅沢に使います。これに関して、そんなにメモリを消費して如何なものか?という意見も聞こえてきそうですが、これはルールエンジンに限らず、WindowシステムなどのGUIやRDBMSなども昔の技術に比べればパワーを贅沢に使っているものではないかと・・・人間にとって扱いやすくすることと引き換えに、リソースを贅沢に使うようになるというのは時代の常なのかもしれませんね。

また周辺環境の時代変化による違いとしてもうひとつ

4.システム間でのデータの受け渡しが容易になってきている。

エキスパートシステムが流行っていた時代、企業の基幹システムが汎用機上で動いている一方、エキスパートシステムは、それらシステムとは切り離されたワークステーション上でスタンドアローンで動いているのが一般的でした。前にも書いたと思いますが、エキスパートシステムを動かすための基礎データを入力するために、汎用機とワークステーションの間で、フロッピーでデータをやりとりしていたこともあります。
ところが、現在のBRMSは、基幹システムなどの他のシステムとは、たとえばWebサービス、EJBなどを用いて以前に比べればずいぶんと容易にデータの受け渡しが可能となっています。
このシステム間でのデータのやりとりの障壁が劇的に低くなったことのおかげで、ルールエンジンの適用分野もぐっとひろがりました。そもそもルールエンジンがスタンドアローンでクローズなコンピュータの上に載っている時代に、ルールで一般的な業務システムの入力の相関チェックをやろうという発想が出てくるとも思えないでしょう。

以上、ビジネスルール管理システム(BRMS)とエキスパートシステムという題で書き続けてきました。エキスパートシステムはIT技術の表舞台から去って20年あまり経ちます。ところが、まあ20年も経つとコンピュータの周辺環境も大きく変わって、以前大きな制約となっていたリソースやデータの受け渡しなどの問題が飛躍的に改善されてきた…というか制約として認識されない程度にまで環境が改善してしまいました。それにともない以前は応用人工知能という枠の中に収まってしまっていたルールエンジンも、利用する上での敷居が大幅に低くなり、「BRMS」として新たな開発環境、運用環境、方法論をともなって適用分野を広げ再生してきています。

さらに最近では「ビジネスルール」の管理システムというところから、「デシジョン」管理システム(意思決定管理システム)、「ナレッジ オートメーション」という方向に進んできています。デシジョン管理という言葉は、もともとFICOが「Enterprise Decision Management」と言いだしたのがはじまりですが、最近ではIBMなども、ツールの名称を IBM WebSphere Operational Decision Management と改称したり、時代の流れとしてはそういった方向に行っています。
いずれそういったところもブログで書いていこうかと思っておりますが、ひとまずは参考文献として、

サイト
ビジネスルール管理からデシジョン管理の時代へ

デシジョンについて

文献
Decision Management System (2011)

Knowledge Automation (2012)

Smart Enough Systems (2008)

をあげておきます。

ビジネスルール管理システムとエキスパートシステム(3)

(前項の続き)
1番目は対象分野の違いと書きましたが、その違いによって開発ツールの力点の違いがでてきます。

2.開発ツールの力点の違い

・BRMSは、比較的単純で明確なルールを容易に書け、ビジネスユーザ自身でもルールを記述できることを目指している。
・一方で、エキスパートシステムは、専門家の知識をきちんと表現できるように、複雑なルールも書きやすくしているかわりに、ルールの記述はツールの使い方を習得した専門の担当者でないと難しいようになっている。

(もっとも今のBRMSでも昔のエキスパートシステムシェルでも使っているルールエンジンのコアアルゴリズムはそれほど変わっていないのでルールの記述力としては同じです)

実際、昔のエキスパートシステム開発ツール(シェル)のいくつかは、生のLispやPrologが垣間見えるところがあったりして、さすがにこれを使ってユーザが直接ルールを直すというのはちょっと…という感がありました。しかし、最近のBRMSでは簡単なルールを簡単にわかりやすく記述するというところが徹底されて(もしくは徹底しようとして)いて、さらに、それを前提としたルールのリポジトリや容易なデプロイのしくみなど、まあ言ってみれば至れり尽くせりの方向に進んでいます。

この方向性というのは、結局のところBRMSの概念のもうひとつのルーツである、ビジネスルールアプローチの影響かと思います。

実は、ビジネスルールアプローチについても前に書きかけていたり(^^;)したのですが

ビジネスルールアプローチ(1)

これは、そもそもIBMのGUIDEの1993年に始まる Business Rules Project の中から生まれてきたものです。それまで企業をモデリングするというと、データの側面からや機能の側面からのモデリングは試みられてきたものの、企業が日常のオペレーションを行っていく上での制約といった側面は看過されておりモデリングされてきていませんでした。以上の反省から、このプロジェクトでは、企業のオペレーションのコントロール、構造といった部分をビジネスルールを用いてモデリングすることを目指しました。ちなみにこの辺は、Business Rules Groupのサイトにある

Defining Business Rules ~ What Are They Really?

を見ていただくとわかるかと。ちなみにこのプロジェクトのメンバーを見てみると、E.F. Codd とか John Zachman などといった錚々たる顔ぶれが並んでいてちょっとびっくりします。また、のちにビジネスルールアプローチを推進していく中心的な人物 Barbara von Halle や Ronald Ross の名前も見えます。

(ちょっと脱線しますが、このようにビジネスルールの考え方は、関係データベースやEAの祖を含めた人々が集まって作られてきました。データベースの教科書で有名な C.J.Dateもルールに関する本を書いています。)

さて、メンバーであった Barbara von Halle は、その後2001年にビジネスルールアプローチの具体的な開発方法論を次の本にまとめています。

Business Rules Applied: Building Better Systems Using the Business Rules Approach

この中で、Barbara Von Halle は、BRAの原則としてSTEPということを言っています。詳しくはすでに上記にあげた記事の中で書いているのでそちらを参照するとして、原則だけ列挙しておきましょう。

Separate rules(ルールを分離せよ)
Trace rules(ルールがトレースできるようにせよ)
Externalize rules(ルールを外部化せよ)
Position rules for change(変更を前提にルールを配置せよ)

最近のBRMSはまさに上の原則を満たすような形につくられています。
最初にエキスパートシステムの中で実装レベルであらわれた「ルール」の考え方は、ここにいたってビジネスルールアプローチであらわれてきた概念レベルの「ビジネスルール」とドッキングして、BRMSというツールが生まれたわけです。
(この項続く)

(補足)
私が日経コンピュータの例の記事の「ビジネスルール特化型」のBRMSと「オールインワン型」のツールとをしつこく区別しようとしているのは、記事ではBRMSの背景にあるこういった考えをまったく無視しており、自動生成のツールを十把一絡げに「BRMS」という言葉でくくってしまっているからです。たとえば、RDBMSとNoSQLのDBMSを同じDBだからと言って「RDBMS」という言葉でくくってしまっているようなもので、さすがに乱暴すぎるだろうということ…芸人ではないのだから、あまりに ワイルド にすぎるかと。

ビジネスルール管理システムとエキスパートシステム(2)

(前回の続き)
ビジネスルール管理システム(BRMS)とエキスパートシステムとの違いとして、前回あげたのは適用する分野が違うということでした。まずは、その説明から

1.適用する例が違う

現在BRMSが使われている事例としては、入力データの相関チェックとか、保険などの査定などが多く見られます。これらは、処理そのものはそれほど複雑ではありません。また実装されるルールも規程などですでに明文化されていたり、仮に明文化されていないものであっても明確に表現することが可能なものであり、根拠がはっきりしていることが特徴です。

一方エキスパートシステムの事例は、医療診断や生産計画など、いわゆる専門家と呼ばれる人々の知識をルールの形で実装していくものであり、処理が一般的に複雑です。また、実装されるルールの多くはエキスパートの頭の中だけに存在する暗黙知であり、知識を引き出すのが難しいうえ、その根拠も不明瞭なケースが多々あります。

たとえばこんな感じ・・・
PETボトルの原料であるPET樹脂はさまざまなところで使われており、溶かしてフィルム上に加工し、ポイントカードのベースや、コンデンサーの絶縁体等々に使われていたりします。こういったフィルムに加工するラインの生産計画を立案するエキスパートシステムでは、たとえば以下のようなルールがありました。

「濃色の品種のあとに、ライン洗浄せずにより淡色の品種を生産してはいけない」

(フィルムには、透明なもの、淡色のもの、濃色のものなどがあり、またラインも定期的に洗浄したりします)

このルール、常識的に考えれば素人でも理解はできる当たり前のルールですが、必ずしもMUSTの条件ではありません。納期や生産量の都合と品質上の歩留まり等をてんびんにかけてあえて破ったりすることもあります。この、さまざまな状況を勘案してあえて破ることができる能力を持つというのが専門家の専門家たる所以なのでしょうが、この「さまざまな状況を勘案する」というところの知識を専門家から引き出してルールに落としていく・・・
そうしてできたシステムがエキスパートシステムになります。

こういった知識を引き出してくるのが簡単なことでないことは容易に想像のつくところ。実際エキスパートシステムが流行っていたころは、知識獲得という技術を持ったナレッジエンジニア(KE)という言葉があったものでした。

それに比べ、BRMSが対象とするルールは、

入力された銀行コードが銀行マスタになければエラーを出す
最高血圧140以上、最低血圧100以上なら血圧の評点が50
業種が建設業の企業の保険料率は○○

など、いわゆる普通の業務システムの仕様に書かれていてもおかしくないようなルールです。

以上のことをまとめると、

  • BRMSが対象としているのは、普通の業務システムが普通に実装しているようなビジネスロジックをもつ分野
  • エキスパートシステムが対象としているのは、通常の業務システムの手法ではおよそ対応ができないような複雑なビジネスロジックを持つ分野

ということになります。
ところで、BRMSが普通の業務システムが普通に実装しているようなビジネスロジックを対象としているというのだったら、これからわざわざBRMSを導入する必然性がないではないかという疑問がでてくるでしょう。これに対する回答は今回の記事の趣旨からはずれるので別途あらためて記事にしようかと思っていますが、簡単に言うと

  • ビジネスロジックの変更のしやすさ
  • ビジネスロジックの見える化

ということになるかと思います。ビジネスロジックをルールの形でシステムの他の部分から切り離して外部化することにより、上に書いたように、変更のしやすさ、ロジックの見える化が実現できます。

上記の対象の違いによって、次にあげる

2.開発ツールの力点の違い

もあらわれてくることになります。(この項続く)

ビジネスルール管理システムとエキスパートシステム(1)

最近、日経BP社 ITproのメールマガジンで「最新ITの“古さ”を知らない危険」という記事を読みました。

まとめてしまえば

最新のIT関連キーワードXXは、つきつめてみると昔流行ったキーワードYYの話である

という発言を情報システム部長などのベテランからよく聞くということ。
そしてそれは、

ある意味正しいが、ある意味正しくない

ということ。これは、

確かに最近のIT関連技術のキーワードは、昔の技術キーワードの蒸し返しであることが多く、ベテランの言うことはそういった面で正しいと言えるが、一方で昔のブーム以降のさまざまな(周辺を含めた)技術の進歩を取り込んで、単純な蒸し返しに終わらない再挑戦、再々挑戦となっているという面で正しくない

というわけ。要するに

最近流行の技術は過去に存在した技術の蒸し返しであることも多いが、単純な蒸し返しであるというわけではない。したがって徒に否定してしまうのは正しくないが、一方で最近の技術を過去の経験と照らし合わせもせず無批判に取り入れるのは、過去と同じ失敗をしてしまう可能性があるのでそれもよくない。

ということのようです。

さて、上に挙げた記事では、実例として、

XXが「スマート…」なら YYが「ユビキタス」「ブロードバンド」「ニューメディア」
XXが「クラウド」なら YYは「ASP」「VAN」あるいは「仮想化」

が挙げられていましたが、今回の本題の話に入ると、さしずめ

XXが「ビジネスルール管理システム(BRMS)」なら YYは「エキスパートシステム」

といったところになるでしょう(ちなみにここで言っているBRMSとは例の記事のビジネスルール特化型のBRMSのことなので念のため、XXがオールインワン型のBRMSというのであれば、YYは自動生成???)。

したがって上の記事の主張に沿うならば、BRMSとエキスパートシステムとの対比と、過去の総括をやっておく必要がでてきます。実際、BRMSのことを上司に話したら、「昔のエキスパートシステムやルールベースの言語とどう違うの?」という質問をされた…という話も最近ちらほら耳にしていますし、

また、私が購読している海の向こう(というか言葉の壁の向こう)のブログでまさにこの対比がホットな話題となっていたりもします。

Follow-Up on ‘Harvesting Business Rules’: Business Rules vs. Expert Systems
Response to: Business Rules vs. Expert Systems: Same or Different?
Additional Response to: Business Rules vs. Expert Systems – Same or Different?

実は、かなり前に当ブログでも関連するようなことを話題にしており、

エキスパートシステムの思ひ出1(なぜ今またルールベースに光があたっているのか)
エキスパートシステムの思ひ出2(なぜ今またルールベースに光があたっているのか)

という記事があるのですが、読んでいてわかりにくい部分などもあるので、ここでは再度、ビジネスルール管理システムとエキスパートシステムとを対比しながらまとめておきましょう。

まず、今回のブームでのBRMSと過去のエキスパートシステムとの一番の大きな違いは

1.適用する対象の違い

と言えましょう。 (この項続く)

エキスパートシステムの思ひ出2(なぜ今またルールベースに光があたっているのか)

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

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

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

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

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

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

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

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

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

エキスパートシステムの思ひ出1(なぜ今またルールベースに光があたっているのか)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ルールエンジン家系図

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

BRE家系図2008

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

第5世代コンピュータ

先週DroolsのブログOctober Rules Fest (day 1) and the upcoming RuleML conferenceという記事を読みました。海の向こうでOctober Rules Festというのがあったようなのですが、そのいくつかのセッションの題名を見て懐かしくなってしまいました。Re-architecting 「CLIPS」などと言うのもなかなかに懐かしかったのですが、それ以上にReviving the Japanese Fifth Generation Project’s Dream: Building the Ultimate Rule-processing Engineという題名を見て、少しばかりの懐かしさと感慨に浸ってしまいました。よみがえる日本の第5世代コンピュータの夢・・・第5世代コンピュータ・・・まあ、Wikipediaを見る(一般的な評価でも)と結構ひどい言われようですが、プロジェクトが始まってちょっとしたころに大学に入った私としては、ある種の憧憬ににた感情も持っていたのですね。

日本の第5世代コンピュータプロジェクト自体は失敗したという評価ですが、このプロジェクトに刺激されて欧米で類似プロジェクトが立ち上げられたところを見ると、世界の人工知能の研究・応用に大きな刺激を与えたという意味では成果があったのではないでしょうか。もともとフランスの会社であるILOGは、この時期にヨーロッパで立ち上がったESPRIT(European Strategic Program of Research in Information Technology)プロジェクトからけっこう恩恵を受けていましたよね。

さて、今のコンピュータのパフォーマンスはあのころとは比べものにならないほど速いものになりました。「夢」は「夢」であったあのころから比べ、その「夢」は、今ではもう少し実現に近づいてきたのではないでしょうか。