Knowledge Flowはどう実装するのか 企業ドキュメントからオントロジーを自動生成するシステムアーキテクチャ

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

前回の記事では、Knowledge Flowを

「企業ドキュメントからAIが利用できる知識基盤を自動生成する仕組み」

として紹介しました。

今回は、その具体的なシステム構成について説明します。

全体アーキテクチャ

Knowledge Flowは、大きく5つのレイヤで構成されます。

Enterprise Documents
        │
        ▼
Document Ingestion
        │
        ▼
Knowledge Extraction (LLM)
        │
        ▼
Ontology Builder
        │
        ▼
Knowledge Graph
        │
        ▼
DSL Generator
        │
        ▼
Knowledge Repository
        │
        ▼
Decision Trace Model
        │
        ▼
Runtime OS

すべての処理はイベント駆動で実行されます。

新しいドキュメントが追加されるたびに、知識基盤も自動的に更新されます。

Step1 Document Ingestion

最初に企業内の情報を収集します。

対象になるのは、

• SharePoint
• Confluence
• Google Drive
• OneDrive
• GitHub
• Box
• Dropbox
• Slack
• Teams
• Outlook
• PDF
• Word
• Excel
• PowerPoint
• CAD設計書
• ソースコード
• Wiki

などです。

例えば

契約書.pdf

↓

PDF Parser

↓

Markdown

あるいは

Word

↓

Docx Parser

↓

Markdown

のように、

すべて一度共通フォーマットへ変換します。

MarkdownやJSONが最も扱いやすい形式になります。

Step2 Document Chunking

そのままLLMへ渡すことはできません。

まず意味単位へ分割します。

例えば

設備管理マニュアル

↓

Chapter

↓

Section

↓

Paragraph

さらに

Paragraph

↓

Semantic Chunk

へ変換します。

チャンクには

{
    id
    source
    author
    version
    timestamp
    title
    tags
    text
}

のようなメタデータも保持します。

これがKnowledge Flowの最小単位になります。

Step3 LLMによる知識抽出

ここでLLMが文章を解析します。

例えば

検査工程では
不良率が5%を超えた場合
品質保証部へ通知する

という文章から

概念

Inspection
Defect Rate
Quality Assurance

関係

Inspection

↓

Defect Rate

↓

Notify

↓

Quality Assurance

制約

DefectRate > 5%

イベント

Notify QA

を抽出します。

これをJSONで表現すると

{
  "entities": [
    "Inspection",
    "Defect Rate",
    "Quality Assurance"
  ],
  "relations": [
    {
      "from":"Inspection",
      "to":"Defect Rate",
      "type":"measure"
    }
  ],
  "constraints":[
    "DefectRate > 5%"
  ]
}

となります。

Step4 オントロジー生成

抽出した概念を統合します。

例えば

Customer

Client

Account Holder

これらが同じ意味なら

Customer

へ統合します。

さらに

Customer

├── Premium

├── Gold

└── Silver

のように階層を構築します。

また

Customer

↓

Order

↓

Invoice

という関連も追加します。

これによって企業独自のオントロジーが育っていきます。

Step5 Knowledge Graph生成

オントロジーだけでは判断できません。

概念同士をグラフとして保持します。

例えば

Customer

↓

Purchase

↓

Product

↓

Factory

↓

Inspection

↓

Quality

のようなネットワークになります。

Neo4jなどのグラフデータベースを利用すると、

MATCH

Customer

↓

Purchase

↓

Product

のような問い合わせが可能になります。

LLMもGraph RAGとして利用できます。

Step6 DSL生成

次に判断ルールを抽出します。

例えば

1000万円以上なら
部長承認

↓

DSL

IF Contract.Amount >= 10000000

THEN Approval = Director

あるいは

温度が80℃以上

↓

停止

↓

IF Temperature >= 80

STOP Machine

このDSLは

Decision Runtime Kernel

で実行されます。

Step7 人間レビュー

もちろんLLMは間違えます。

そのため

Ontology Candidate

↓

Human Review

↓

Approve

↓

Repository

という流れを入れます。

レビュー時には

• 差分表示
• 新規概念
• 関係追加
• DSL追加

だけを確認します。

すべて読み直す必要はありません。

Step8 継続学習

Knowledge Flowは

一回構築して終わり

ではありません。

例えば

新しい業務マニュアル

↓

新概念

↓

Ontology Update

↓

DSL Update

↓

Knowledge Graph Update

が自動で行われます。

つまり知識は常に最新になります。

実装例

Pythonで概念抽出を行う場合、

document
    ↓
LLM
    ↓
Entities
    ↓
Ontology Builder
    ↓
Neo4j

という構成になります。

LLMには

• GPT
• Claude
• Gemini
• Llama

などを利用できます。

Graph Databaseは

• Neo4j
• Memgraph
• Amazon Neptune

などが候補になります。

DSLは

JSON DSL

YAML DSL

あるいは

独自DSL

として保存できます。

Runtime OSとの接続

Knowledge Flow単体では、

知識を蓄積するだけです。

本当の価値は、

Decision Runtime Kernel

と接続したときに生まれます。

AIが判断を行う際には、

Decision Request

↓

Ontology

↓

Knowledge Graph

↓

DSL

↓

Policy

↓

Decision Trace

↓

Decision

という流れで推論を行います。

つまりKnowledge Flowは、

Runtime OSへ知識を供給する役割を担います。

Knowledge Flowは「知識を資産化する基盤」

Knowledge Flowの本質は、ドキュメントを検索可能にすることではありません。

企業内に散在する文書や会話、設計書、ソースコードなどから、AIが理解できる知識構造を継続的に生成・更新することにあります。

オントロジーは「組織が何を知っているか」を表し、Knowledge Graphは「それらがどう結び付いているか」を示します。そしてDSLは「どのように判断すべきか」を形式化します。

これらが組み合わさることで、企業の知識は単なる情報の蓄積から、AIが推論し、意思決定に活用できる知識資産へと変わります。

Knowledge Flowは、この知識資産を継続的に育て、Decision Trace ModelやRuntime OSへ供給する「知識インフラ」です。

AI時代に競争力を生み出すのは、より大きなモデルではありません。

組織固有の知識をどれだけ構造化し、継続的に進化させられるか。

Knowledge Flowは、そのための基盤となるアーキテクチャなのです。