このページは、生成規則モデル（Production Rule Model）の基本を、初学者向けに短く整理するためのノートです。
ざっくりいうと
生成規則モデルは、**「もし条件が成り立つなら、この行動をする」**という if-then 形式の規則を多数持ち、規則を順に適用して結論を導く考え方です。
例:
- IF 「発熱がある」かつ「咳がある」 THEN 「呼吸器系の検査を提案」
この「IF 側」を条件部（LHS）、「THEN 側」を**動作部（RHS）**と呼びます。
何でできているか
典型的には、次の3つで構成されます。
- ルールベース:
if-then規則の集合 - 作業記憶（ワーキングメモリ）: 現在わかっている事実
- 推論エンジン: 使えるルールを探し、どれを実行するか決める部分
推論エンジンは一般に、次のサイクルを回します。
- 作業記憶と一致するルールを探す（マッチ）
- 同時に複数候補があるとき優先順位を決める（競合解決）
- ルールを実行して作業記憶を更新する（実行）
ツリー構造なのか
説明上は木構造のように見せることがありますが、実際は分岐と合流があるため、挙動はグラフ構造に近くなることが多いです。
生成規則モデルの本質は「固定ツリー」ではなく、「ルール集合を事実に照合して反復実行する仕組み」にあります。
推論の方向
主に2つの使い方があります。
- 前向き推論（Forward Chaining）: 手元の事実から出発して結論を増やす
- 後ろ向き推論（Backward Chaining）: 目標の結論が成り立つかを逆向きに確認する
業務ルール適用では前向き推論、診断や問い合わせでは後ろ向き推論が使われることが多いです。
詳細は 前向き推論と後ろ向き推論（詳細） を参照してください。
入力の考え方
古典的なエキスパートシステムやルールベースの対話では、自由文をそのまま解釈するより、選択式で答えてもらう設計が主流でした。
はい/いいえ、単一選択、複数選択、メニューから項目を選ぶ、といった形で、ユーザーが選んだ内容がそのまま既知事実として作業記憶に積まれます。
そのため、体験としてはアンケートやウィザードに近く、システムが次に聞く質問も、ルールが参照しやすい形に揃えられていました。
（数値・コード・定型フォームなど、選択以外の構造化入力もよく使われます。）
詳細は 入力形式と対話設計 を参照してください。
また「実際にルールはどのファイルにどう保存するか」は ルールファイル形式（.clp など） に分離して整理しています。
歴史的背景（短く）
1960-1980年代の記号AIの中心技術の1つです。エキスパートシステムで広く使われ、OPS 系（OPS5 など）の実装が「大量ルールを現実的に動かす」ための重要な基盤になりました。
強み
- 説明しやすい: どのルールが発火したか追跡しやすい
- 統制しやすい: 規制や社内ルールを明示的に実装できる
- 部分修正しやすい: ルール単位で追加・変更しやすい
限界
- ルールが増えると整合性管理が難しくなる
- 例外処理が増えるほど保守コストが上がる
- 曖昧な自然言語や未定義ケースへの対応は苦手
現代での使いどころ
現在は「ルールだけ」で完結させるより、検索、機械学習、生成AIと組み合わせるハイブリッド構成が主流です。特に、最終判定に説明責任が必要な領域で生成規則モデルは今も有効です。