Loading article…
ビジネスルールエンジンとは、実行時の本番環境で1つ以上のビジネスルールを実行するソフトウェアシステムです。ルールは、法律（「従業員は理由の有無を問わず解雇されるが、違法な理由では解雇されない」）、企業方針（「一度に100ドル以上を消費するすべての顧客に10%の割引を提供する」）、またはその他の情報源から得られる場合があります。ビジネスルールシステムにより、これらの企業方針やその他の運用上の決定を、アプリケーションコードとは別に定義、テスト、実行、および保守することが可能になります。
ルールエンジンは通常、ルール、事実、優先順位（スコア）、相互排他、前提条件、およびその他の機能をサポートしています。
ルールエンジンソフトウェアは、一般的にビジネスルール管理システムのコンポーネントとして提供され、他の機能の中でも特に、すべてのルールを登録、定義、分類、管理する機能、ルール定義の一貫性を検証する機能（「ゴールドレベルの顧客は注文数量が10を超える場合に送料無料の対象となります」と「シルバーレベルの顧客の最大注文数量は15です」など）、異なるルール間の関係を定義する機能、およびこれらのルールの一部を、影響を受ける、または1つ以上のルールを適用する必要があるITアプリケーションに関連付ける機能を提供します。
あらゆるITアプリケーションにおいて、ビジネスルールはアプリケーションコードの他の部分よりも頻繁に変更される可能性があります。ルールエンジンまたは推論エンジンは、ビジネスルールアプローチによってアプリケーションコードから外部化または分離されたビジネスルールを実行するプラグイン可能なソフトウェアコンポーネントとして機能します。この外部化または分離により、ビジネスユーザーはIT部門の介入なしにルールを変更できます。このような外部ビジネスルールによってシステム全体の適応性が向上しますが、これはQAやその他のテストの通常の要件を排除するものではありません。
Computerworldの記事では、ルールエンジンの起源を1990年代初頭に遡り、Pegasystems、Fair Isaac Corp、ILOG [ 1 ] 、 SapiensのeMerge [ 2 ]などの製品にたどっています。
多くの組織のルール作成の取り組みでは、一般的にワークフロー設計と考えられている側面と従来のルール設計の側面が組み合わされています。この2つのアプローチを分離しないことで、ビジネスルールとワークフローの両方を再利用および制御する能力に問題が生じる可能性があります。このジレンマを回避する設計アプローチでは、ビジネスルールとワークフローの役割を次のように分離します。[ 3 ]
具体的には、ビジネスルールは、ビジネス状況が発生したことを検知してビジネスイベントを発生させる（通常はメッセージングインフラストラクチャを介して伝達される）ことや、より高レベルのビジネス知識を生成する（例えば、融資が引受基準を満たしているかどうかに関する組織、製品、規制に基づく一連のルールを評価する）といったことを行う可能性がある。一方、ワークフローは、ルーティングポイントの過負荷などを示すイベントに応答して、一連のアクティビティを開始する。
この分離が重要なのは、同じ業務判断（住宅ローンが引受基準を満たしている）や業務イベント（ルーターが過負荷状態である）に対して、さまざまなワークフローが反応する可能性があるためです。ルール主導型の知識生成に対応する作業をルール自体に組み込むと、ワークフロー固有のものになってしまうため、組織全体でビジネスルールを再利用できる可能性が大幅に低下します。
ビジネスルールエンジンを採用したアーキテクチャを構築するには、ビジネスルールによって定義されたイベントへの応答やビジネス判断の検証に基づくプロセスによって、 BPM（ビジネスプロセス管理）プラットフォームとBRM（ビジネスルール管理）プラットフォームとの統合を確立することが不可欠です。市場には、この統合をネイティブに提供する製品がいくつかあります。それ以外の場合は、特定のプロジェクトや組織内で、このような抽象化と統合を開発する必要があります。
ほとんどのJavaベースのルールエンジンは、さまざまなアプリケーションとの統合を可能にするために、JSR-94アプリケーションプログラミングインターフェース（API）標準に基づいた技術的な呼び出しレベルのインターフェースを提供しており、多くのルールエンジンは、 WSDLやSOAPなどのWebベースの標準を介したサービス指向の統合を可能にしています。
ほとんどのルールエンジンは、ルールを記述する対象となるビジネスエンティティと関係性を表すデータ抽象化を開発する機能を提供します。このビジネスエンティティモデルは、通常、 XML、POJO、フラットファイルなど、さまざまなソースからデータを取り込むことができます。ルール自体を記述するための標準言語はありません。多くのエンジンはJavaライクな構文を使用しますが、一部のエンジンでは、独自のビジネスフレンドリーな言語を定義できます。
ほとんどのルールエンジンは呼び出し可能なライブラリとして機能します。しかし、 RDBMSのように汎用プロセスとして実行されるルールエンジンも増えてきています。ほとんどのエンジンはルールをプロセスインスタンスにロードする構成として扱いますが、中にはルール実行インスタンス全体のコードを生成するものや、ユーザーが選択できるものもあります。
ルールエンジンには様々な種類があります。これらの種類は（一般的に）ルールの実行スケジュールの立て方が異なります。
企業が使用するルールエンジンのほとんどは前方連鎖型であり、これはさらに2つのクラスに分類できます。
これらのタイプの最大の違いは、プロダクションルールエンジンはユーザーまたはアプリケーションが呼び出したときに実行される点であり、通常はステートレスな方法で実行されます。一方、リアクティブルールエンジンはイベントが発生したときに自動的に反応し、通常はステートフルな方法で実行されます。多くの（そして実際にはほとんどの）人気のある商用ルールエンジンは、プロダクションルールとリアクションルールの両方の機能を備えていますが、どちらか一方を優先する場合があります。たとえば、ほとんどのビジネスルールエンジンは主にプロダクションルールエンジンですが、複雑なイベント処理ルールエンジンはリアクションルールを重視しています。
さらに、一部のルールエンジンは後方連鎖をサポートしています。この場合、ルールエンジンは特定の目標に合致するように事実を解決しようとします。既存の情報に基づいて何かが存在するかどうかを判断しようとするため、目標駆動型と呼ばれることがよくあります。
別の種類のルールエンジンは、推論実行中にバックチェイニングとフォワードチェイニングを複数回自動的に切り替えます。例えば、インターネットビジネスロジックシステムは、ウェブ検索で見つけることができます。
ルールエンジンの4つ目の分類として、決定論的エンジンと呼ばれるものがある。これらのルールエンジンは、順方向連鎖と逆方向連鎖の両方を放棄し、代わりにドメイン固有言語を用いてポリシーをより適切に記述する。このアプローチは、実装と保守が容易な場合が多く、順方向連鎖または逆方向連鎖システムに比べてパフォーマンス上の利点がある。
ファジー論理に基づく推論の方が適切な場合もあり、その場合はブール規則ではなくヒューリスティックが規則処理に使用されます。例としては、顧客分類、欠損データの推論、顧客価値の計算などが挙げられます。DARL言語[ 4 ]および関連する推論エンジンとエディタは、このアプローチの一例です。
ルールエンジンの一般的なユースケースの1つは、アプリケーションへの標準化されたアクセス制御です。OASISは、アクセス制御専用のルールエンジンアーキテクチャと標準であるXACML（拡張アクセス制御マークアップ言語）を定義しています。XACMLルールエンジンとビジネスルールエンジンの重要な違いの1つは、XACMLルールエンジンはステートレスであり、データのステートを変更できないことです。ポリシー決定ポイント（PDP）と呼ばれるXACMLルールエンジンは、「アリスはドキュメントDを閲覧できますか？」などの二者択一のYes/Noの質問を想定し、許可/拒否などの決定を返します。
ルールエンジンは、マサチューセッツ州ケンブリッジのPegasystems Inc.、ミネソタ州ミネアポリスのFair Isaac Corp.、カリフォルニア州マウンテンビューのILOGなどの企業が販売していた1990年代初頭から存在しています。これらは通常、金融や保険などのルールが多用される業界で使用されていました。しかし、ここ数年で多くのベンダーが市場に参入し、より多くの企業がビジネスオペレーションの柔軟性を高める方法としてルールエンジンに注目しています。