企業の知識はAIが読める形になっているか？ ドキュメントからオントロジーとDSLを自動生成するKnowledge Flowという考え方

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

生成AIは企業のドキュメントを読み、要約し、質問に答えることができるようになりました。

しかし、多くの企業では、次のような問題が残っています。

• 回答は正しいが、自社のルールが反映されない
• 部門ごとに言葉の意味が異なる
• 判断の根拠が説明できない
• ベテランの暗黙知が共有されない
• AIが部署ごとに異なる答えを返してしまう

つまり、AIは文書を「読む」ことはできても、組織の知識を「理解」しているわけではありません。

私たちは、この課題をKnowledge Flowという考え方で解決しようとしています。

Knowledge Flowとは何か

Knowledge Flowは、企業に存在する知識を単に検索可能にする仕組みではありません。

企業の知識を、

AIが判断できる構造

へ変換し続ける仕組みです。

従来の企業では、

• Word
• PDF
• Excel
• PowerPoint
• Wiki
• メール
• チャット
• ソースコード
• 設計書
• 業務マニュアル

など、膨大な情報が存在しています。

しかし、それらは人間には理解できても、AIにとっては単なる文章の集合に過ぎません。

Knowledge Flowでは、これらを継続的に解析し、

• 概念（Ontology）
• 業務知識（Knowledge Graph）
• 判断ルール（DSL）
• 制約条件
• 意思決定パターン

へと変換していきます。

つまり、

ドキュメントからAIが利用できる知識基盤を自動生成する

ことが目的です。

オントロジーを自動生成する

企業には独自の言葉があります。

例えば製造業なら、

• 品番
• ロット
• 工程
• 不良
• 検査
• 歩留まり

金融なら、

• 与信
• 保証
• 契約
• 顧客属性
• リスク

医療なら、

• 患者
• 処方
• 診療
• 禁忌

これらの言葉は単なる単語ではありません。

それぞれが関係を持っています。

例えば、

製品
 ├─ 部品
 ├─ 工程
 ├─ 品質
 └─ 検査

この関係性を表現したものがオントロジーです。

LLMは企業文書を解析し、

• 概念
• 上位下位関係
• 属性
• 関連性

を抽出できます。

Knowledge Flowでは、この処理を継続的に行い、

企業専用のオントロジーを自動で育てていきます。

DSLも自動生成できる

企業には必ず判断ルールがあります。

例えば、

契約金額が1000万円を超える場合は部長承認が必要

あるいは、

温度が80℃を超えたら設備を停止する

さらに、

在庫が100個未満なら発注する

これらはすべて、

判断ロジック

です。

Knowledge Flowでは、

自然言語からDSL（Domain Specific Language）を自動生成します。

例えば、

IF Contract.Amount > 10000000

THEN Approval = Director

あるいは、

IF Temperature > 80

STOP Machine

さらに、

IF Stock < 100

Purchase()

のような形へ変換できます。

つまり、

文書が実行可能なルールへ変わるのです。

オントロジーとDSLは相互に進化する

オントロジーは、

「何が存在するのか」

を定義します。

DSLは、

「どう判断するのか」

を定義します。

この二つは独立ではありません。

例えば、

Customer

↓

Order

↓

Invoice

という概念構造があるから、

IF Customer.Status == Gold

Discount = 10%

というDSLを書けます。

逆に、

DSLが増えることで、

新しい概念も発見されます。

Knowledge Flowでは、

この循環を継続的に回します。

人間もAIも共同で知識を育てる

Knowledge Flowでは、

AIだけが知識を作るわけではありません。

人間がレビューし、

修正し、

改善し、

再びAIが学習します。

つまり、

Document

↓

LLM

↓

Ontology

↓

DSL

↓

Human Review

↓

Knowledge Base

↓

LLM

という知識循環になります。

これは単なるRAGではありません。

企業知識そのものが進化していく仕組みです。

Decision Trace Modelとの接続

Knowledge Flowが生成したDSLは、

Decision Trace Modelで利用されます。

例えば、

Need

↓

Goal

↓

Constraint

↓

Policy

↓

Decision

↓

Trace

ConstraintやPolicyは、

Knowledge Flowから供給されます。

つまり、

Knowledge Flowは、

Decision Trace Modelへ知識を提供する役割を担います。

Runtime OSとの統合

Knowledge Flowは静的な知識管理システムではありません。

Runtime OSと統合されることで、

AIは実際の判断時に、

• オントロジー
• DSL
• ポリシー
• 制約条件
• 過去のDecision Trace

を参照しながら推論できます。

これにより、

AIは単なる「回答生成」から、

「組織の知識に基づいた意思決定支援」へと進化します。

LLMが変えた知識管理

かつて、オントロジーやDSLの構築には、多大な時間と専門知識が必要でした。

知識エンジニアが業務担当者へヒアリングを行い、概念モデルを設計し、ルールを一つずつ記述していく作業は、膨大なコストを伴いました。そのため、多くの知識管理プロジェクトは途中で更新されなくなり、「作って終わり」のシステムになってしまいました。

LLMの登場は、この状況を大きく変えました。

企業内のドキュメントを継続的に解析し、新しい概念を抽出し、オントロジーを更新し、業務ルールをDSLとして生成することが現実的になったのです。

もちろん、人間によるレビューやガバナンスは不可欠です。しかし、知識の抽出・整理・構造化という膨大な作業をAIが担うことで、知識基盤は継続的に進化できるようになります。

Knowledge Flowが目指す未来

私たちは、AI時代の企業に必要なのは、単なる文書検索ではないと考えています。

必要なのは、

• 組織の知識を構造化し、
• 判断ルールを形式知化し、
• AIと人間が共同で改善し続ける

知識循環の仕組みです。

Knowledge Flowは、そのための基盤となります。

企業のドキュメントからオントロジーを生成し、DSLを生成し、Decision Trace Modelへ知識を供給し、Runtime OSの意思決定を支える。

私たちは、Knowledge Flowを、AI時代の「知識インフラ」として位置付けています。

AIの価値は、モデルの性能だけでは決まりません。

本当に重要なのは、組織の知識をどれだけ正しく理解し、判断へとつなげられるかです。

Knowledge Flowは、その知識を流れとして捉え、人間とAIが共に育て続ける新しい知識基盤なのです。