エキスパートシステムから生成AIエコシステムへ
Posted:
エキスパートシステムから生成AIエコシステムへ
古典的なエキスパートシステムは、主に知識ベースと推論エンジンによって、専門家の判断をルール化して扱う仕組みだった。
現在の生成AIでは「エキスパートシステム」という名前はあまり使われない(技術的な連続性も乏しいと思います)。 しかし、その構成要素は RAG、tool calling、agent runtime、guardrails、policy engine、workflow engine、observability などに分解されて生き残っている。
現代的には、次のように捉えると分かりやすかった。
LLM が曖昧な自然言語理解、分類、計画、候補生成を担い、 RAG が外部知識を与え、 tool calling が外部手続きを実行し、 guardrails / policy engine / schema validation / approval gate が決定性と安全性を補う構成。
古典的構成との対応
| 古典的エキスパートシステムの要素 | 現代の生成AI周辺で近いもの | 役割 |
|---|---|---|
| Knowledge Base | RAG、Vector DB、全文検索、Knowledge Graph、ドキュメント index | LLM 本体にない外部知識を検索し、質問に応じて関連 context として渡す |
| Rule Base | Guardrails、Policy-as-Code、OPA/Rego、JSON Schema、Business Rule Engine | 「この条件なら許可/拒否」「この形式以外は不可」「このトピックは禁止」などの明示ルールを担う |
| Inference Engine | Agent runtime、agent harness、planner-executor | LLM が tool 選択や次の行動を判断し、外側の実行基盤がループを管理する |
| Forward Chaining | Event-driven automation、監視 alert pipeline、SOAR、workflow engine | 事実やイベントを起点に次の処理を発火する。例: ログ異常、分類、runbook 検索、ticket 作成 |
| Backward Chaining | Query planning、RAG query decomposition、multi-step retrieval | 目標から逆算して、必要な情報、検索、tool call を決める |
| Working Memory | Conversation state、agent state、scratchpad、checkpointer | 現在の事実、途中結果、tool 結果、会話履歴を保持する |
| Explanation Facility | Trace、citation、observability、eval、provenance | 判断過程、参照元、tool 実行履歴を後から検証できるようにする |
| Knowledge Acquisition | Document ingestion、connector、crawler、MCP resource、schema extraction | 専門家の知識、ドキュメント、API、GitHub、Slack、チケットなどを取り込む |
| External Procedure Call | Tool calling、function calling、MCP tools | LLM の判断を外部 API、CLI、DB、Kubernetes、GitHub などの操作へ接続する |
| Input / Output Validator | Structured Outputs、JSON Schema、Pydantic/Zod validation | LLM 出力を自由文ではなく、機械処理しやすい schema 準拠データにする |
| Safety / Compliance Layer | Guardrails、moderation、PII filter、topic control、approval gate | 危険操作、情報漏洩、不適切出力、権限逸脱を防ぐ |
| User Questioning / Interview | Elicitation、フォーム補完、human-in-the-loop approval | 不足情報を人間に確認し、重要操作では承認を挟む |
古典的な仕組みとの違い
古典的エキスパートシステムでは、推論の中心は if X then Y のような明示ルールだった。
一方、現在の生成AIアプリでは、LLM が曖昧な入力を解釈し、方針や候補を生成する。 ただし、LLM 単体にすべてを任せると、非決定性、幻覚、権限逸脱の問題が残る。そのため、外側に明示的な制御層を置く。
現代的な分担は次のように見ると整理しやすい。
LLM
- 自然言語理解
- 要約
- 分類
- 候補生成
- tool 選択
- 曖昧な状況での仮説生成
RAG / Search / Knowledge Graph
- 外部知識の検索
- 最新ドキュメント、runbook、仕様の参照
- 根拠付き回答
Policy / Guardrails / Schema
- 禁止条件
- 許可条件
- 出力形式
- 危険操作の抑止
- 人間承認の強制
Workflow / Agent Runtime
- tool call のループ管理
- 状態管理
- リトライ
- 観測可能性
- 実行履歴の保存
LLM の役割は、古典的な rule engine を丸ごと置き換えることではない。
むしろ、曖昧な入力を扱う層を LLM に寄せ、正確な知識参照、決定的な制約、実行権限、監査可能性は外側のシステムに残す設計の方が安定する。
SREとHome Labでの応用
自宅サーバ、k3s、OpenWrt、監視ログ、GitHub、Ansible、Terraform などと組み合わせる場合、ローカル LLM は「最終判断者」にするより、分類器、要約器、候補生成器、自然言語インターフェースとして使う方が安全。
ログ / alert / metrics / event
↓
正規化・重要度分類: local LLM
↓
関連 runbook 検索: RAG
↓
危険操作判定: policy engine / 静的ルール / allowlist
↓
次アクション提案: LLM
↓
実行可否: human approval
↓
ticket / issue / PR / Ansible / kubectl / Terraform plan
具体的には、次のような使い方が考えられる。
- OpenWrt / banIP / nftables のログを要約し、異常傾向だけ通知する
- k3s の
kubectl describe/kubectl logsを要約し、関連 runbook を提示する - Prometheus / Grafana / Loki の alert を人間向けの短い説明に変換する
- Ansible / Terraform の plan 差分を自然言語でリスク分類する
- GitHub Issue / PR の内容から、関連ファイル、過去の修正、runbook を検索する
kubectl delete、security group 変更、公開設定変更のような危険操作では、policy engine と human approval を必須にする
この設計では、LLM が自律的に復旧を完了することより、状況を小さく要約し、人間が判断できる候補へ圧縮することの方が重要になる。
設計方針
LLMに最終権限を与えない
LLM は提案、分類、要約を担当する。実行判断はルール、承認、権限分離で制御する。
知識はRAGやドキュメントに寄せる
モデルに暗記させるのではなく、外部知識を検索して渡す。runbook、設計メモ、API document、ticket、GitHub issue などを検索可能な知識として扱う。
危険操作はpolicy engineで明示的に止める
OPA/Rego、allowlist、denylist、RBAC、GitHub branch protection などを使う。自然言語で「気をつけて」と指示するだけでは制御層として弱い。
出力はschemaで縛る
自由文だけでなく、JSON Schema / Pydantic / Zod などで後段処理可能な形式にする。特に自動化へ渡す場合、schema validation は出力品質ではなく安全境界の一部として扱う。
traceと根拠を残す
どのログを見たか、どの runbook を参照したか、どの tool を呼んだかを残す。説明可能性は「きれいな説明文」ではなく、後から検証できる実行履歴に寄せる。
ローカルLLMは軽量な専門作業に寄せる
小型ローカルモデルは、ログ要約、分類、初期診断、通知文生成、候補生成に向く。広い tool selection、長大な context、危険操作の最終判断は外側の policy / approval に寄せた方がよい。
まとめ
現在の生成AIアプリケーションは、名前こそ違うものの、古典的なエキスパートシステムの思想をかなり引き継いでいる。
ただし、現在の構成はルールベース単体ではない。LLM の柔軟性と、外部システムの決定性を組み合わせる形に進化している。
重要なのは、LLM を「万能な判断者」として扱うことではなく、次のように役割分担することである。
曖昧な判断・文章理解・候補生成 -> LLM
正確な知識参照 -> RAG / Search / Knowledge Graph
決定的な制約・安全性 -> Policy / Guardrails / Schema
実行と状態管理 -> Workflow / Agent Runtime
最終責任 -> Human approval / 明示ルール
この構成は、SRE、自宅サーバ、監視、自動復旧、runbook automation、GitHub issue / PR automation と相性が良さそう。