TOP>製品/サービス>カテゴリから探す>ディシジョンオートメーション>Progress Corticon>BRMSコンサルタントが語る ~超高速開発だけがメリットではない~ Vol.2

Progress Corticon

BRMSコンサルタントが語る ~超高速開発だけがメリットではない~ Vol.2

ルールエンジンのアルゴリズム

ここのところBRMS(ルールエンジン)を使ったシステム開発が以前に比べだいぶ増えてきましたが、まだまだ人口に膾炙するといったところではないようで、ルールエンジンの動き等に関連していろいろ質問されることが多々あります。

例えば、以下のようなものがあります。

  • ルールエンジンのプログラムって、if-Thenのルールが並んでいるけれども、上から順にやっていくの?
  • (上記に関連して)通常のプログラムの(単体)テストだと全部のパスを通るようにテストするけれども、ルールの場合のテストでは、全部のパスを通す…ってどのように考えればよい?
  • ルールエンジンのメモリ使用量は何に依存してきまるのでしょうか?ルール数?
  • 同じようにルールエンジンの処理速度は何できまる?

多くのルールエンジンは、一般的なプログラミング言語の実行方法(手続き的)と動きの原理が違い、またif-thenルールはコンパイル時にネットワークの形に最適化されると同時に、実行時にデータの重複評価をしないように判断結果をキャッシュしたりもします。

ここではまず、ルールエンジンの動きを見ていきましょう。このルールエンジン、もともとは人工知能や認知心理学の研究をルーツとするもので、人間が長期記憶にあたる「ルール」を使って、認識した外界の状況(短期記憶に保持される)に合わせて判断を行うという行動がモデルとなっています。

これをルールエンジンの動きとして翻訳してみると、以下のようになります。

この動きをみるとわかるように、ルールエンジンでは、すべてのデータに対して、すべてのルールの条件部のマッチングを試し、そののちにルールを実行します。したがってルールの実行順序は必ずしも上から順などといったことではありません。

ルールエンジンにも現実的には実行順の規則はあるのですが、そもそもルールによるプログラミングそのものが、実行の順番ではなくルールの条件に合ったものから実行するという考え方なので、実行順に過度に依存するようなルールの書き方はルールによるプログラミングのお作法に反するものと言えましょう。

特に最近ルールエンジンがよく使われている入力データのチェックなどは、(チェックそのものだけでいえば)別に順番などはどうでもよく、条件に合うか合わないかで正しくエラーが出ればそれでよいのであって、上記のようなルールエンジンの動きはこの「チェック」という作業に対して非常に親和性の高いもののように思います。

もっとも、入力データのチェックなどは、ルールのパターンマッチの側面こそ利用していますが、一方でルールの実行中に入力データが変わっていくわけではないので、先に挙げたルールの実行サイクルを何度も回して結果を出すという特徴的なところはあまり利用していないとも言えます。

では、よりルールエンジンの動きの特徴が表れている例というとどんな例があげられるでしょうか。思うに、たとえば質問に対して答えていき最後に結果を出すといったコンサルティングというか、レコメンドというか…といったシステムの例はそのひとつではないでしょうか。

この動きをルールエンジンの実行サイクルに合わせて見てみましょう。

これだけではあまりに抽象的なので、もう少しかみくだいた例として、たとえば、料理に合うワインをおすすめするといった場合を考えてみましょう(この具体的な実装は、Clipsというツールの例としてあげられています)。

まず質問の例としては、以下が挙げられます。

これら質問をルールとして保持し、ルールの実行部分で質問の回答を記憶領域に書くようにしておきます。
さて、まず最初に1の質問のルールが動き、質問に対して「肉」という回答をすると、(短期)記憶領域に

・「料理は肉」

と書かれます。次に2の質問に、「ソースがかかっていない」という回答をすると、記憶領域に

・「料理にはソースがかかっていない」

という事実が追加されます。
次に3の質問。これは本来、料理にソースがかかっていなければ意味のない質問です。したがって、3の質問を行うルールの条件部分には「料理にはソースがかかっている」という前提条件を加えておきます。そうすると、現在の記憶領域の状態

・「料理は肉」
・「料理にはソースがかかっていない」

に3の質問ルールはマッチしないので、ルールは実行されません。一方、2でソースがかかっていると回答すると自然に3のルールもマッチしてきます。

このように、質問を行う各ルールの前提条件をきちんと書いておけば、意味のない質問をすることもなく、効率的に結果を求めることができましょう。

さて、実は上の議論では少々ゴマカシがあるのですが、お気づきでしょうか。上の議論では、1から順に実行することが前提となっているような書き方になっていますが、ルールエンジンの一般的な動きでは上から順に動くという保証はありません。順番に関して何も指定していない(*1)と、上記のルールのうち1,2,4,5のどのルールが最初に動くかの保証は何もありません。まあ、論理的には最初に1,2,4,5のどの質問から聞いても結果は同じなのですが、ワインの好みに対して聞く4,5の順番はともかく、1,2は気持ちとしては、1の次に2を聞くのが普通かと。こんなときには、

A. 2の前提条件に料理の種類が決まっている条件。具体的には、「料理は○○」という事実があるという条件を加える。

B.ルールに優先度をつけて、1が2よりも先に動くようにする。

というような解決方法があります。まあ、ルールの一般的なお作法としては、A.のほうが推奨ですが、ケースバイケースで一概にどちらがいいというわけでもありません。さらに質問のかたまり間で順番をつけたいという場合に、たとえば料理に関する質問のルール、ワインの好みに関する質問のルールといったかたまりの間での順番をつけたいというときには、ルールのかたまりとその順番を定義するという仕組みがたいていのルールエンジンに標準的に装備されています(Droolsでは、アジェンダグループとか、ルールフローとか、またCorticonで言えばルールシートがこれにあたるでしょう)。

  • ※1実は、ルールが動く順番は全くのランダムというわけではなく、たいていの場合何らかの規則にしたがって、実行されるルールが選ばれます。この規則を競合解消戦略といって、考え方としては、「最新の情報を優先する」、「一般的な条件のルールと、より特殊な条件のルールと両方にマッチした場合は、特殊な条件のルールを優先する」などといった基準があります。

    ルールベースAI(BRMS)についてもっと知る

著者プロフィール

BRMSコンサルタント 津島 靖彦 氏

BRMSコンサルタント。
様々な経営方針に基づくシステム化の企画に携わり、過去には損害保険、生命保険会社で、BRMSを利用した申請書類や査定事務処理チェックシステムの構築、保険料試算、査定支援システムの構築など数々の実績を残す。

関連記事

お求めの情報は見つかりましたでしょうか。

資料請求/お問い合わせはこちら(専門の担当者が確認し、ご対応します。)

お客様の状況に合わせて詳しい情報をお届けできます。お気軽にご相談ください。

ページの先頭へ戻る