このページは、エキスパートシステム（専門家の判断をソフトウェア化する枠組み）の基本を、初学者向けに短く整理するためのノートです。個別の実装名（CLIPS、Drools など）の史は エキスパートシステム史 や各ノートに託し、ここでは全体像と、生成規則モデルとの関係に焦点を当てます。
ざっくりいうと
エキスパートシステムは、人の専門家に代わっていま何をすべきか判断するのではなく、専門家の知識を外に出し、同じ基準で推論・助言を出すための仕組みです。
典型形は 知識ベース と 推論エンジン の二本立てです。
- 知識ベース：領域のルールや静的事実などを書き留めた集合（実装ではファイル・BRMS・DB などに置くことが多い）
- 推論エンジン：いまわかっていること（事実・観察）が与えられたときに、どのルールをどう適用して結論やアクションへ進むかを担う部分
一言で言い換えるなら、その領域のエキスパートがやるような判断・助言を、知識としてソフトウェアに載せたシステムです。人間を機械が完全に置き換えるというより、判断基準を形式知として外に出し、だれが使っても同じ論点で結論を揃えやすくするイメージに近いです。
なぜ「エキスパートシステム」と呼ぶか（名前の由来）
英語の expert は「その分野に詳しい人」、system はそれを実装したソフトや仕組み全体です。1970〜1980 年代に用語が広まった頃は、一般プログラムが仕様どおりに固定的に動くのに対し、ドメインのプロの頭のなかにあるルールや経験則を知識ベースに載せ、入力に応じて専門家に近い結論や助言を返すことが売りでした。そのため歴史的には medical expert system のように領域名が頭に付くことも多かったです。
いまは同じ構造でも 業務ルールエンジン・ポリシーエンジン と呼ぶ文脈もありますが、「専門判断を載せたルールベース」のレッテルとして エキスパートシステム が残っています。
生成規則モデルとの違い（何が同じで何が違うか）
| 観点 | 生成規則モデル | エキスパートシステム |
|---|---|---|
| 位置づけ | やり方の型（if-then・作業記憶・推論の回し方） |
目的のくくり（専門判断をソフトに載せる） |
| 例えるなら | エンジンの設計パターン | 業務・診断などの応用ジャンル |
歴史的には、エキスパートシステムの多くが 生成規則（生産系）で実装されてきました。一方、ルールエンジンだけを「専門家の助言」ではなく 業務一括適用・ポリシー判定 に使う場合は、同じ仕組みでも「エキスパートシステム」とは呼ばないことがあります。詳しい用語は 生成規則モデルの概要 を参照してください。
ルール・事実・記号構造・エンジン（中身のイメージ）
専門知識は 「記号構造という抽象語にペタッと貼る」 のではなく、ルール・事実など具体的な記号的表現に書き写すことで載せます。
- ルール（
if-then）… 条件と結論・動作が 明示的な記号表現として保持される（実装ではテキストやオブジェクトなど）。 - 事実… 初期データ・マスタ・いまの観察結果など。ルール本文とは別の束として置くことが多く、ルールがマッチする 材料になる。
- 作業記憶… 推論の途中で増えた事実や目標も、同様に 記号的な状態として保持される。
知識ベースは、ざっくり ルール集合＋（語彙によっては）静的事実 をまとめた 保管庫（コンポーネント名） です。記号構造は、それらが どのような形（項・ファクト列・木など）で表されているか という 表現の言い方です。容器と中身の形を混同しないと読みやすいです（整理は 記号構造とは）。
推論エンジンは、この ルール集合 と 現在の記号的状態（事実・ゴールなど） を照合し、適用して状態を更新します。ルールも状態も、広い意味では記号構造の一族であり、エンジンは この二つ（に分解して言うなら「条文」と「いまそうなっていること」）を参照して動く、と捉えると一貫します。
運用での調整（ニューラルの重みとは別）
知識は 学習で自動更新される重みというより、人が書き換える明示的知識が中心です。調整のイメージは次のようなものです。
- ルールを足す・条件を細かくする・例外を分ける（いわゆる知識工学の反復に近い）
- 複数ルールが競合するときの優先… 実装では 顕現度（salience） や具体性など、エンジン固有のルールがある
- 不確実性… 系によっては 確信度 のような数値を結論に付ける（ニューラルネットの重みとは別物だが、「ノブ」としての数字はあり得る）
「ソースに直書き」に限らず、ルールリポジトリや BRMS 上で更新するのも、内容が明示的な記号表現であるという意味では同じです。モデルとは の「広いモデル」と混ぜないとよいです。
いつ使われたか・いまどうか
1960〜1970 年代の試作から、1980 年代の 知識工学 とともに産業応用が広がり、その後は ルール増加による保守コスト や期待の収束などで「すべてをこれで」の空気ではなくなりました。とはいえ 診断支援・業務判定・規程チェック・トラブルシュートなど、説明可能性や監査が効く場面では、いまも 知識＋推論 の構造が使われ続けています。
強みと限界（短く）
強み
- 根拠を言葉やルールとして残せる（レビューや運用での説明に向く）
- 規程や方針を明示的資産として管理できる（特に BRMS と組み合わせた業務運用）
限界
- 知識を取り出して形式化するコスト（知識獲得ボトルネック）
- 例外とルールの増加による保守負荷
- 自然な言語の入力をそのまま高精度に理解することとは切り離して設計されることが多く、入力は選択式・アンケート・フォームなど構造化されやすい
本フォルダで触れる実装の例
- CLIPS：生産系ルールと作業記憶を備えたシェル。教育・組み込み・研究で長く使われた系譜です。
- Drools：JVM 向けの BRMS。業務ルールを資産として管理し、アプリから呼び出す設計が一般的です。
どちらも「エキスパートシステム」というより広い語のうち、ルールとマッチングで動く実装の代表例として読めます。
認知アーキテクチャとの違い（目安）
認知アーキテクチャ（SOAR、ACT-R など）は、人間の認知プロセス全体を研究する枠組みです。一方、エキスパートシステムは多くの場合、ある業務ドメインの判断を製品・運用に載せることが主目的であり、目的と設計の中心がずれます。