DSL Generation 企業文書に埋もれた判断ルールを実行可能な知識へ変換する

🎥 YouTubeでも公開しています

Knowledge Flow実践ガイド — 企業知識をAIが利用できる知識基盤へ変換する

Books: Knowledge Flow実践ガイド: 企業知識をAIが利用できる知識基盤へ変換する

Knowledge Acquisitionによって企業内の情報が収集され、Semantic Document Chunkingによって意味単位へ分割されました。

さらにKnowledge Extractionによって、文章からエンティティ、関係、制約、イベント、意図が抽出され、Ontology ConstructionとKnowledge Graph Generationによって企業知識の意味体系と関係性が整理されました。

しかし、この段階では、AIはまだ企業のルールを「知っている」だけです。

そのルールを実際の判断に利用するためには、

どの条件で、何を評価し、どの処理を実行するのか

を機械が解釈できる形へ変換する必要があります。

Knowledge Flowでは、その役割をDSL Generationが担います。

DSLとは、Domain-Specific Languageの略です。

企業文書に記述された自然言語のルールを、特定の業務領域で実行可能な形式へ変換するための言語です。

なぜDSLが必要なのか

企業には大量の判断ルールがあります。

例えば、契約管理では、

契約金額が1,000万円以上の場合は部長承認を必要とする。

設備管理では、

設備温度が80℃以上になった場合は運転を停止する。

在庫管理では、

在庫数が100個未満になった場合は追加発注を行う。

品質管理では、

不良率が5%を超えた場合は品質保証部へ通知する。

これらは人間にとって理解しやすい表現です。

しかし、自然言語には曖昧さがあります。

例えば、

• 「以上」は境界値を含むのか
• 「部長」はどの部門の部長なのか
• 「停止」は即時停止なのか、安全確認後の停止なのか
• 「通知」はメールなのか、承認ワークフローなのか
• 複数条件がある場合、すべて満たす必要があるのか

といった問題があります。

そのため、自然言語のままでは、安全で一貫した実行ができません。

Knowledge Flowでは、こうした判断ルールをDSLへ変換し、条件、対象、行動、責任主体を明確にします。

自然言語からDSLへの変換

例えば、

契約金額が1,000万円以上の場合は部長承認を必要とする。

という文章は、次のように分解されます。

対象:
Contract

属性:
Amount

条件:
Amount >= 10,000,000

実行:
Request Approval

承認者:
Director

これをDSLにすると、

RULE ContractDirectorApproval

WHEN
    Contract.Amount >= 10000000

THEN
    REQUIRE Approval BY Director

となります。

単純な例では、

IF Contract.Amount >= 10000000
THEN Approval = Director

でも表現できます。

しかし、実運用ではルール名、対象、バージョン、出典、責任主体なども保持した方が安全です。

設備停止ルールの例

次の文章を考えます。

設備温度が80℃以上になった場合は装置を停止し、保全担当者へ通知する。

Knowledge Extractionでは、以下の要素が抽出されます。

{
  "subject": "Machine",
  "variable": "Temperature",
  "operator": ">=",
  "value": 80,
  "unit": "Celsius",
  "actions": [
    "Stop Machine",
    "Notify Maintenance"
  ]
}

DSLでは次のように表現できます。

RULE MachineOverheatProtection

WHEN
    Machine.Temperature >= 80 CELSIUS

THEN
    STOP Machine
    NOTIFY MaintenanceTeam

さらに、安全性を考慮する場合は、

RULE MachineOverheatProtection

PRIORITY Critical

WHEN
    Machine.Temperature >= 80 CELSIUS

THEN
    REQUEST SafeShutdown
    NOTIFY MaintenanceTeam
    RECORD Incident

REQUIRE
    Sensor.Status == Valid

のように、センサーの有効性やログ記録まで含められます。

DSLの基本構造

Knowledge Flowで生成するDSLは、一般的に次の要素を持ちます。

Rule ID
Rule Name
Version
Source
Target
Condition
Constraint
Action
Actor
Priority
Exception
Approval
Trace

例えば、

rule_id: RULE-00031
name: ContractDirectorApproval
version: 1.2
source_document: DOC-001245
target: Contract
priority: High

when:
  field: Contract.Amount
  operator: ">="
  value: 10000000
  currency: JPY

then:
  action: RequireApproval
  approver_role: Director

trace:
  enabled: true

のようにYAMLで保持することもできます。

この形式であれば、人間にも読みやすく、システムからも処理できます。

JSON DSL

システム間連携を重視する場合は、JSON DSLが適しています。

{
  "rule_id": "RULE-00031",
  "name": "ContractDirectorApproval",
  "version": "1.2",
  "target": "Contract",
  "condition": {
    "field": "Contract.Amount",
    "operator": ">=",
    "value": 10000000,
    "currency": "JPY"
  },
  "action": {
    "type": "RequireApproval",
    "actor": "Director"
  },
  "source": {
    "document_id": "DOC-001245",
    "chunk_id": "CHK-000154"
  }
}

JSON DSLは、

• API連携
• ルール検証
• バージョン管理
• Runtime Kernelへの受け渡し

に向いています。

独自DSLを使う場合

企業独自の業務ロジックが複雑な場合は、独自DSLを設計できます。

例えば契約承認領域では、

CONTRACT APPROVAL RULE ContractHighValue

IF
    Amount >= 10000000 JPY

AND
    ContractType != Standard

THEN
    APPROVAL REQUIRED BY LegalDirector

BEFORE
    Execution

製造業では、

SAFETY RULE MachineTemperatureLimit

IF
    Temperature >= 80 C

FOR
    10 SECONDS

THEN
    SAFE_STOP Machine

AND
    ALERT Maintenance

のように、業務領域に合った表現が可能です。

DSLは汎用プログラミング言語ではありません。

特定の業務判断を、人間とAIの双方が理解できる形で表すことが目的です。

単一条件から複合条件へ

企業の判断ルールは、一つの条件だけとは限りません。

例えば、

契約金額が1,000万円以上で、海外企業との契約であり、標準契約書を使用しない場合は、法務部長の承認を必要とする。

このルールは次のようになります。

RULE InternationalNonStandardContractApproval

WHEN
    Contract.Amount >= 10000000
    AND Contract.Counterparty.Country != "Japan"
    AND Contract.Template != "Standard"

THEN
    REQUIRE Approval BY LegalDirector

条件を構造化すると、

{
  "all": [
    {
      "field": "Contract.Amount",
      "operator": ">=",
      "value": 10000000
    },
    {
      "field": "Contract.Counterparty.Country",
      "operator": "!=",
      "value": "Japan"
    },
    {
      "field": "Contract.Template",
      "operator": "!=",
      "value": "Standard"
    }
  ]
}

になります。

複合条件を明示することで、自然言語に含まれる曖昧なAND・OR関係を整理できます。

例外ルールの表現

企業ルールには例外があります。

例えば、

契約金額が1,000万円以上の場合は部長承認が必要。ただし、既に取締役会で承認済みの案件は除く。

DSLでは、

RULE ContractDirectorApproval

WHEN
    Contract.Amount >= 10000000

THEN
    REQUIRE Approval BY Director

EXCEPT WHEN
    Contract.BoardApproved == true

と表現できます。

例外を暗黙のまま残すと、AIは誤った判断を行う可能性があります。

DSL化することで、通常条件と例外条件を明確に分離できます。

時間条件の表現

業務ルールでは、時間も重要です。

例えば、

温度が80℃を超えた状態が10秒以上続いた場合は設備を停止する。

単純な比較だけでは不十分です。

RULE SustainedOverheatShutdown

WHEN
    Machine.Temperature > 80 CELSIUS

DURATION
    >= 10 SECONDS

THEN
    SAFE_STOP Machine

あるいは、

申請から3営業日以内に承認されなければ上位管理者へエスカレーションする。

RULE ApprovalEscalation

WHEN
    Approval.Status == Pending

DURATION
    > 3 BUSINESS_DAYS

THEN
    ESCALATE TO SeniorManager

このように、DSLでは時間的な制約も表現できます。

Ontologyとの接続

DSL内で使用する概念は、OntologyのCanonical Nameを参照します。

例えば、

Contract.Amount
Director
Machine.Temperature
QualityAssuranceDepartment

はすべてOntologyで定義された概念です。

これにより、

営業部門が「Client」と呼び、

経理部門が「Customer」と呼んでいても、

DSLではCanonical Nameである

Customer

へ統一できます。

DSLとOntologyが接続されることで、ルールの意味が一貫します。

Knowledge Graphとの接続

DSLは単独で存在するのではなく、Knowledge Graphへ接続されます。

例えば、

Contract
   │
   ├── HAS_RULE ──▶ ContractDirectorApproval
   │
   ├── REQUIRES ──▶ DirectorApproval
   │
   └── DESCRIBED_BY ──▶ ContractPolicyDocument

という構造になります。

これにより、

「このルールはどの文書から生成されたのか」

「どの概念に適用されるのか」

「どの承認者が関係するのか」

を追跡できます。

LLMによるDSL生成

Knowledge Flowでは、LLMがSemantic ChunkとOntologyを参照してDSL候補を生成します。

入力は例えば次のようになります。

{
  "chunk_id": "CHK-000154",
  "text": "契約金額が1000万円以上の場合は部長承認が必要",
  "ontology": {
    "Contract": {
      "attributes": [
        "Amount"
      ]
    },
    "Director": {
      "type": "OrganizationalRole"
    }
  }
}

LLMには、自由形式ではなくDSL Schemaを指定します。

出力例は、

{
  "rule_name": "ContractDirectorApproval",
  "target": "Contract",
  "conditions": [
    {
      "field": "Contract.Amount",
      "operator": ">=",
      "value": 10000000,
      "currency": "JPY"
    }
  ],
  "actions": [
    {
      "type": "RequireApproval",
      "actor": "Director"
    }
  ]
}

となります。

DSL生成時の検証

LLMが生成したDSLを、そのまま実行してはいけません。

Knowledge Flowでは、複数段階の検証を行います。

構文検証

DSLが定義された文法に従っているかを確認します。

Syntax Validation

例えば、演算子やフィールド名に誤りがないかを確認します。

意味検証

Ontology上に存在する概念や属性を使用しているかを確認します。

例えば、

Contract.Price

という属性がOntologyに存在せず、

正しくは

Contract.Amount

である場合はエラーにします。

型検証

金額、文字列、日時、Booleanなどの型を検証します。

Contract.Amount >= "Large"

のようなルールは型不整合として拒否します。

矛盾検証

既存ルールとの矛盾も確認します。

例えば、

IF Contract.Amount >= 10000000
THEN Approval = Director

と

IF Contract.Amount >= 5000000
THEN Approval = Manager

が同時に存在する場合、

1,000万円以上でどちらが優先されるのかを明確にする必要があります。

ルールの優先順位

複数のルールが一致する場合は、優先順位が必要です。

例えば、

RULE StandardApproval
PRIORITY 10

RULE HighRiskApproval
PRIORITY 50

RULE RegulatoryRestriction
PRIORITY 100

のように設定します。

一般には、

法令・安全ルール
        ↓
企業ポリシー
        ↓
部門ルール
        ↓
個別業務ルール

の順で優先されます。

これにより、部門ルールが法令ルールを上書きすることを防げます。

Human Review

自動生成されたDSLは、実行前に人間がレビューします。

DSL Candidate

↓

Syntax Validation

↓

Semantic Validation

↓

Conflict Detection

↓

Human Review

↓

Approved DSL

レビュー画面では、

• 元の文章
• 生成された条件
• 生成されたアクション
• 参照したOntology
• 既存ルールとの差分
• 想定される実行結果

を表示します。

人間は全文を読み直すのではなく、ルール候補と差分だけを確認できます。

Rule Repository

承認されたDSLはRule Repositoryへ保存されます。

{
  "rule_id": "RULE-00031",
  "name": "ContractDirectorApproval",
  "status": "Approved",
  "version": "1.2",
  "effective_from": "2026-07-01",
  "effective_to": null,
  "owner": "Legal Department",
  "source_document": "DOC-001245",
  "source_chunk": "CHK-000154",
  "approved_by": "USR-0098"
}

Repositoryでは、

• バージョン管理
• 有効期間管理
• 承認履歴
• 所有部門
• 適用範囲
• 廃止状態

を管理します。

Decision Runtime Kernelでの実行

承認されたDSLは、Decision Runtime Kernelで評価されます。

例えば、契約申請が入力されると、

Decision Request

↓

Context Loading

↓

Ontology Resolution

↓

Knowledge Graph Retrieval

↓

DSL Evaluation

↓

Policy Check

↓

Human Approval

↓

Execution Permission

↓

Decision Trace

という流れになります。

具体的な入力が、

{
  "contract_id": "CNT-10021",
  "amount": 15000000,
  "currency": "JPY"
}

であれば、DSLは条件に一致します。

15000000 >= 10000000

その結果、

{
  "decision": "ApprovalRequired",
  "approver": "Director",
  "matched_rule": "RULE-00031"
}

が生成されます。

DSLは直接実行命令ではない

重要なのは、LLMが生成したDSLをそのまま外部システムへ実行しないことです。

DSLはまず、

判断候補

としてDecision Runtime Kernelへ渡されます。

Runtime Kernelは、

• Policy
• Boundary
• Authority
• Context
• Risk
• Human Approval

を評価したうえで、実行を許可するか判断します。

例えば、

STOP Machine

というDSLがあっても、センサー異常の可能性や安全停止手順を確認せず、即座に設備を停止するべきではありません。

DSLは実行ロジックを表しますが、最終的な実行権限はRuntime Kernelが管理します。

Decision Traceへの記録

DSLの評価結果はDecision Traceへ記録されます。

例えば、

{
  "decision_id": "DEC-000892",
  "input": {
    "contract_amount": 15000000
  },
  "matched_rule": "RULE-00031",
  "rule_version": "1.2",
  "evaluation": true,
  "required_action": "DirectorApproval",
  "timestamp": "2026-07-14T10:30:00Z"
}

これにより、

• どのルールが使われたのか
• どのバージョンだったのか
• どの入力条件に一致したのか
• なぜ承認が必要になったのか
• 誰が最終判断を行ったのか

を後から説明できます。

継続的なルール改善

企業ルールは変化します。

新しい法令が施行されたり、組織変更が行われたり、承認金額が変更されたりします。

新しい文書が登録されると、

New Policy Document

↓

Semantic Chunk

↓

Knowledge Extraction

↓

DSL Candidate

↓

Diff Detection

↓

Human Review

↓

Rule Update

という流れで既存DSLが更新されます。

例えば、

1000万円以上

が

500万円以上

へ変更された場合、Rule Repositoryでは差分として管理されます。

過去の判断は旧バージョンに紐付き、新しい判断には新バージョンが適用されます。

DSLは組織の判断を形式知化する

Knowledge FlowにおけるDSL Generationは、文章をプログラムへ変換するだけの処理ではありません。

企業文書に埋もれていた条件、制約、承認、例外、時間条件、優先順位、責任主体を明示し、組織の判断方法を機械が評価できる形へ変換するプロセスです。

Ontologyによって意味が統一され、Knowledge Graphによって関連知識が接続され、DSLによって「どのように判断するのか」が形式化されます。

そして、そのDSLはDecision Runtime Kernelによって評価され、Policy、Boundary、Human Authority、Context、Riskを通過した場合にのみ実行へ進みます。

つまりDSLは、AIに自由に行動させるための仕組みではありません。

AIの判断を組織のルールに接続し、検証可能で説明可能な意思決定へ変換するための仕組みです。

Knowledge FlowにおけるDSL Generationは、組織の暗黙的な判断ルールを、AI時代の実行可能な知識資産へ変える中核プロセスなのです。