このページは、生成規則モデルでよく誤解される「ルールはどんなファイルにどう保存されていたか」を短く整理するノートです。
結論から言うと、当時の中心は JSON ではなく、推論エンジン向けの専用テキスト形式でした。
先に要点
- ルール本体は自然文の長文ではなく、条件判定しやすい記号構文で書く
- 形式は実装依存（CLIPS, Prolog, Lisp 系など）だが、核は
if-then - ファイルは「データ倉庫」だけでなく、推論の規則も同居することが多い
.clp（CLIPS）に入るもの
代表的には次の3種類です。
deftemplate: 事実データの型定義deffacts: 初期事実（ワーキングメモリに積む初期データ）defrule: 条件部（LHS）と動作部（RHS）を持つ規則
例（簡略）:
(deftemplate patient
(slot name)
(slot temp)
(slot cough))
(deffacts initial-data
(patient (name "A") (temp 38.5) (cough yes)))
(defrule suspect-flu
(patient (name ?n) (temp ?t&:(> ?t 38.0)) (cough yes))
=>
(assert (diagnosis (name ?n) (result flu))))
「yes/no の目的変数だけ」ではない
THEN 側は二値ラベルだけでなく、次のように多様です。
- 新しい結論ファクトを追加（例:
suspect_flu） - スコアや属性を付けて更新（例:
risk=high） - 次ルールの条件を満たす中間事実を追加
つまり、機械学習の単一目的変数のように1回で終わるより、結論を連鎖生成する設計が多く見られます。
「知識をコードに直書きしていたのか」
直書きされる場合もありましたが、設計思想としては次の分離が重視されました。
- 推論エンジン（マッチング・競合解決・実行）
- 知識ベース（ルール群と事実定義）
現実には完全分離できないケースもありましたが、知識を差し替え可能にする方向は当時から重要でした。
JSON との違い（短く）
- JSON: 汎用のデータ交換形式（データの入れ物）
- ルールファイル（
.clp等）: データ定義 + 規則 + 推論連鎖のトリガ
比喩としては、JSON が「倉庫」に近いのに対し、ルールファイルは「倉庫 + 判断ロジック」です。