ルールベースシステムで実装するのに適した問題を、一口で言うことは難しいですが、一般的には、
・複雑な条件判断が組み合わさっている
・仕様が頻繁に変わる
ような問題に対しては、ルールベースシステムが適しているといえます。
ルールベースシステムにおいては、(これ以上分割できないという意味で)アトミックなif-thenルールをルールベースに個別に登録していくことで、プログラムを作って行きます。プログラムの実行については備え付けのルールエンジンが適切に判断してくれるため、競合解消の戦略を上手に使ったり、優先度の仕組みをうまく設計しておくと、後から個々にルールを追加していくだけで仕様の変更ができるルールベースが作れます。
たとえば、通常の場合は一般ルールを使うが、ある特殊な場合には、特殊なルールを使うなどといったときには、競合解消の戦略として、複雑な条件をもったルールを優先するという戦略をとることで、容易にルールセットを書くことができます。具体的には、最初に、
「全国で使用する(＝条件部で特に地域の指定がない)デフォルトの接着剤は△△を用いる」
「寒冷地では(=条件部で寒冷地地域の指定がある)、(寒さにも接着強度の落ちない)接着剤××を用いる」
などというルールのセットがあった場合、後から新たに
「雨量の多い地域では、(防水性が高く経年変化に強い)接着剤□□を用いる」
といった特殊なケースが追加されたとき、ルールの判断順序を気にすることなく、その特殊な場合のルールを追加するだけで、仕様の追加ができます。 (さらに、寒冷地でかつ雨量が多いというようなケースがあった場合は、最初からルールに優先度をつけてしまうか、and条件のルールを書いていくなど、ケースバイケースで適切な対応をとることができます)
以上のように見ていくと、ルールベースの応用システムとして、顧客の属性に応じて、顧客に適した商品を薦めるといったレコメンデーションシステムなどは、確かにルールベースのしくみに合っているといえるでしょう。
その反面、アルゴリズムが明確に決まっており、複雑な条件分岐もなく、仕様変更もあまり頻繁でないシステムでは、無理にルールベースで書く必要はないでしょう。計算をゴリゴリ行うプログラムなど、実はルールベースで書けなくもないのですが、かなり書きにくいでしょう。
パターンマッチを基にしたルールベースシステムというと、パフォーマンスを気にする方がいらっしゃいます。確かに概念的には、ルールベースのすべてのルールの条件部と、ワーキングメモリのすべてのfactとの間で常にマッチングの検査をして、マッチするものを選び出しています。しかし、内部的にはReteマッチアルゴリズム(とその進化形など)を使って、以前に比較したルールの条件部とfactとの組で、再度同じマッチングをする必要がない場合に重複しないように配慮がされるので、性能面を気にしすぎる必要はないように思います。ミッションクリティカルなスピード重視の場合ならともかく、だいたいの場合それほど問題にはならないと思います。
***
ルールベースの
・複雑な条件判断が組み合わさっている
・仕様が頻繁に変わる
といった問題解決に適しているという性質は、その昔、人工知能の応用技術であるエキスパートシステム*1の作成において大いに利用されました(ルールベースのルーツは、人工知能の研究にあります)。エキスパートシステムの構築は、「専門家の知識をヒアリングを通じて引き出しては、その知識をシステムに組み込んで評価する」ということの繰り返しです。構築そのものが要求仕様の変更を前提としているエキスパートシステムが、仕様変更に強いアーキテクチャを必要としたのは当然のことでした。
米国のミニコンメーカで、その昔DEC*2という会社がありました。この会社、実は人工知能の技術にも力を入れていて、VAXというコンピュータの構成を決める実用エキスパートシステムを80年代に稼動させていました。名前をR1/XCONというこのシステム、一度は、従来の手続き的な言語で作成されたのですが、メンテナンスがとてもできないということで、ルールベース言語のOPS5で書き直されました。書き直された後のシステムは、メンテナンスも容易になり、ビジネスの現場で使われるようになって実用的なエキスパートシステムとして最初の成功事例として語られています。
*1 エキスパートシステム： 病気の診断や、故障診断、生産計画などの専門家の知識をシステムに取り込むことによって、専門家の支援を行うことを目的とするシステム。
*2 DEC(Digital Equipment Corporation)： 昔はミニコンメーカとして一世を風靡したものですが、今はありません。90年代の後半にコンパックに買収され、さらにコンパックはHPに買収されています。
