組織に散在する業務一次データから、根拠のあるオントロジーへ 固有名詞の収集を超える Evidence-Grounded Ontology Construction

🎥 YouTubeでも公開しています

組織の一次データから、根拠のあるオントロジーへ｜Evidence-Grounded Ontology Construction

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

企業内には、メール、議事録、規程、手順書、契約書、PDF、表計算ファイル、業務チケット、システムログ、会話記録などの**業務一次データ（Raw Data）**が散在している。そこには、組織が日々使っている言葉、例外処理、判断基準、役割分担が記録されている。

こうしたデータから固有名詞を広く抽出し、LLMで上位概念・下位概念・類似語を補いながら蓄積すれば、短時間で知識グラフの種を作ることができる。これは探索の出発点として有効である。

しかし、そのままオントロジーとして育てると、別の問題が現れる。名称を中心に関係を増やすため、実データや発話文脈に裏付けられない階層や類似関係が、もっともらしい形で蓄積してしまうのである。

「顧客」と「利用者」は似ているが、契約・請求・サポートという業務では別の役割を持つことがある。「売上」も、受注額、請求額、入金額、取消後の純売上のいずれを意味するかによって、判断結果は変わる。

必要なのは、名詞の周囲に知識を増殖させることではない。原文に現れた事実、関係、出来事、ルール、制約、意図を抽出し、それらを根拠とともに概念へ統合することである。

本稿では、この考え方を Evidence-Grounded Ontology Construction と呼ぶ。ChinobaのKnowledge Flowにおいて、Raw DataをOntology、Knowledge Graph、DSL、Decision Trace、Runtime OSへ接続するための、より検証可能なオントロジー生成方式である。

固有名詞中心の方式が抱える課題

従来の方式は、Raw Dataに含まれる固有名詞や名詞を抽出し、LLMが上位・下位・関連・類似の概念を補完する。発見的な知識探索には向く一方、業務で利用できる知識基盤にするには、次の問題を解かなければならない。

重要なのは、LLMの生成能力を抑えることではない。LLMが提案した関係を、どの根拠で、どの適用範囲で、どの状態まで利用できるのかを明確にすることである。

Raw Dataから承認済みOntologyまでの流れ

Evidence-Grounded Ontology Constructionでは、抽出・統合・承認・実行利用を一つの処理に混ぜない。

flowchart TD
  A["Organizational Raw Data\nEmail / Documents / Tables / Tickets / Logs / Conversations"] --> B["Semantic Chunking\n文脈・発信者・時刻・権限を保持"]
  B --> C["Structured Extraction\nEntity / Event / Rule / Constraint"]
  C --> D["Concept Resolution\n候補の照合・分離・統合"]
  D --> E["Evidence Graph\n根拠付きの関係グラフ"]
  E --> F["Ontology Draft\n仮説として版管理"]
  F --> G["Validation & Human Review"]
  G --> H["Approved Ontology\nRuntime / DSLへ供給"]
  H --> I["Trace & Feedback"]
  I --> F

この流れでは、Raw Dataから抽出された内容は、直ちに正しいオントロジーにはならない。まずは根拠を伴う候補であり、検証・承認を経て初めて、判断や実行のための知識になる。

Raw Dataは一種類ではない

組織知は複数の媒体に分散しており、媒体ごとに根拠の強さ、更新性、利用可能な範囲が異なる。したがって、すべての業務一次データを同じ「テキスト」として扱ってはいけない。

ここで重要なのは、会話記録や個別メールに現れた内容を、規程や契約書と同じ強さの知識として扱わないことである。たとえば、現場で共有された例外対応は、優れた改善候補になりうる。しかし正式なルールへ昇格するには、規程との整合、責任者の確認、適用範囲の判断が必要である。

Source Adapterで、媒体固有の文脈を保持する

各Raw Dataは、共通のSemantic Chunkへ変換する前に、媒体固有の情報を取り出すSource Adapterを通す。

Email Adapter       : sender / recipients / thread / attachment / approval wording
Document Adapter    : title / section / version / effective dates / cited policy
Table Adapter       : schema / unit / grain / refresh cadence / data owner
Ticket Adapter      : status transition / assignee / priority / acceptance criteria
Log Adapter         : event time / actor / system / operation / result / error code
Conversation Adapter: speaker / channel / thread / reply relationship / reaction

この前処理によって、すべての入力は共通形式で検索・比較できる一方、元の媒体が持つ意味と統制情報を失わない。結果として、「あるメールで部長が承認した」「最新版の規程では異なる」「ログ上は実際に処理が失敗している」といった違いを、同じ知識グラフの中で扱える。

1. Raw Dataを「意味のある単位」に切る

業務一次データを、単なる文字列やレコードとして扱うのではなく、意味のまとまりとして保持する。概念の意味は、その言葉だけでなく、誰が、どの媒体で、いつ、どの話題や業務の中で使ったかによって変わるからである。

{
  "chunk_id": "raw-20260918-042",
  "text": "不良率が5%を超えた場合は、品質保証部に通知してください。",
  "source_type": "operational_document",
  "speaker_role": "quality_manager",
  "timestamp": "2026-09-18T10:15:00+09:00",
  "source_reference": "quality-operations-procedure-v2",
  "authority_hint": "operational_instruction",
  "thread_context": ["前日の検査結果についての会話"]
}

この段階では、日時表現、URL、助数詞、一般的すぎる名詞などを除外する。一方で、話者、送信者、役割、スレッド文脈、宛先、添付資料、文書版、参照先、データ所有者、アクセス権といった情報は残す。

後段で「これは正式な規程か、現場の会話か」「誰の権限で述べられた内容か」を判断するためである。

2. Entityではなく、業務意味フレームを抽出する

オントロジー生成で必要なのは、Entityのリストだけではない。各チャンクから、少なくとも次の六種類を取り出す。

たとえば「不良率が5%を超えた場合は、品質保証部に通知してください」という発話からは、次のような構造を抽出できる。

{
  "entities": [
    {"mention": "不良率", "type": "Metric"},
    {"mention": "品質保証部", "type": "OrganizationUnit"}
  ],
  "event": {
    "type": "ThresholdExceeded",
    "subject": "不良率",
    "condition": "> 5%",
    "time": "when_observed"
  },
  "rule": {
    "type": "NotificationRule",
    "if": "DefectRate > 0.05",
    "then": "Notify(QualityAssurance)",
    "modality": "required"
  },
  "evidence": {
    "source_chunk_id": "raw-20260918-042",
    "quote": "不良率が5%を超えた場合は、品質保証部に通知してください。"
  }
}

ここで得られるのは、「不良率」という名詞の上位語ではない。どの条件のもとで、誰に、何をすべきかという、実行可能な業務ルールの候補である。

3. 抽出とConcept Resolutionを分離する

抽出された表現を既存の概念へ統合する処理は、独立した工程にする必要がある。

たとえば「顧客」という表現が出ても、直ちに既存のCustomerへ統合しない。契約を締結する主体なのか、サービスの利用者なのか、請求先なのかを比較する。

判定結果は、必ず次の三つに分ける。

• Resolved：既存の正規概念へ安全に統合できる
• Candidate：似ているが、統合するための根拠が不足している
• Ambiguous：複数解釈があり、統合してはいけない

「不明」を失敗として消すのではなく、知識の状態として保持することが重要である。これにより、LLMが「顧客」と「利用者」を善意で一つにしてしまう誤統合を防げる。

4. 関係そのものを、根拠付きで管理する

オントロジーでは概念だけでなく、関係そのものも管理対象にする。特に業務ルールは、誰が何と関係するかだけでなく、条件、適用期間、根拠、状態を持つ必要がある。

relation:
  id: rule.notify_quality_when_defect_rate_exceeds_threshold
  subject: metric.defect_rate
  predicate: triggers_notification_to
  object: org.quality_assurance
  condition: "value > 0.05"
  source:
    chunk_id: raw-20260918-042
    quote: "不良率が5%を超えた場合は、品質保証部に通知してください。"
  confidence:
    extraction: 0.94
    resolution: 0.91
  status: candidate
  valid_from: null
  valid_to: null

confidenceは、候補の優先順位を決めるためには役立つ。しかし、それだけでRuntime利用を許可してはならない。利用可否は、出典、権限、適用期間、矛盾、承認状態を合わせて決める。

5. 「意味」と「実行可能なルール」を分離する

Chinobaでは、知識の各層を混同しない。

• Ontology：顧客、不良率、契約、品質保証部とは何か
• Knowledge Graph：誰が何と関係し、何がいつ起きたか
• DSL / Policy：条件を満たすとき、何を許可・依頼・停止するか
• Runtime OS：その操作を、現在の状況と権限のもとで実行してよいか

業務一次データに「顧客へメールを送る」という記述があったとしても、それを自動実行ルールにはしない。

candidate_rule:
  if: "churn_risk > 0.8"
  then: "send_email(customer)"
  status: draft
  concerns:
    - consent_unknown
    - message_template_unknown
    - owner_authority_unknown
  runtime_decision: ask

同意、担当者、テンプレート、送信権限を満たして初めて、その候補は承認済みルールとしてRuntime OSへ渡せる。意味を理解したことと、実行を許可されたことは別である。

6. Ontology Repositoryを、版管理された知識資産にする

オントロジーは完成図ではない。変化し、修正され、古くなる知識資産である。そこで、概念・関係・ルールを次の状態で管理する。

各変更には、少なくとも以下を残す。

• 何を追加、統合、分離、廃止したか
• どのRaw Dataが根拠か
• どの評価によって妥当と判断したか
• 誰またはどのPolicyが承認したか
• いつからいつまで有効か
• どのDecision Traceや業務結果が変更を促したか

つまり、Ontologyの更新自体もDecision Traceの対象にする。

7. 自動改善を「評価付き提案」に変える

Agentの誤解、人の訂正、例外処理は、オントロジー改善の重要な材料になる。ただし、改善とは自己書換えではない。

1. Agentの誤解、人の訂正、例外処理を収集する
2. 原因を分類する
   • Entity抽出誤り
   • 同義語・多義語の誤統合
   • 関係の誤り
   • ルールの欠落
   • 有効期限切れ
   • Policy・Boundary不足
3. Ontologyの差分案を生成する
4. 旧版と新版を、同じ質問、同じデータ、同じモデル、同じ予算で比較する
5. 高リスクの変更はHuman Reviewへ送る
6. 合格した差分だけをapprovedへ昇格する

評価も、抽出F1だけで完結させない。

この仕組みは、EvoOntologyが示した「同じ条件で改善した場合のみ採用する」という発想とも接続できる。ただしChinobaでは、精度だけでなく、根拠性、制約順守、再現性、Human Gateを含めて評価する。

最小実装は、四層から始められる

最初から全社オントロジーを作る必要はない。まずは、対象業務に関わる業務一次データを入力に、次の四層を実装すればよい。

Organizational Raw Data
  └ Email / Document / Table / Ticket / Log / Conversation
  → Semantic Chunk Store
  → Extraction Store
     └ Entity / Relation / Event / Rule / Constraint / Evidence
  → Ontology Draft Repository
  → Approved Ontology + Knowledge Graph

MCPとしては、次の六つから始められる。

• browse_semantics：概念、関係、ルール候補を探索する
• resolve_semantics：質問中の言葉を正規概念と根拠へ対応付ける
• explain_semantics：定義、原典、確信度、適用期間を返す
• propose_semantic_change：候補差分を作る
• evaluate_semantic_change：旧版と新版を比較する
• trace_semantic_decision：意味解決、判断、結果を保存する

業務一次データを、検証可能な組織知へ変える

この方式では、組織に散在する業務一次データが、ばらばらの業務記録ではなくなる。そこに含まれる暗黙知、正式な定義、例外、判断基準、実績、役割分担が、出典と文脈を失わずに、検証可能な知識基盤へ変換される。

Raw Data → Semantic Chunk → Evidence Extraction → Concept Resolution → Ontology / Knowledge Graph → DSL / Policy → Runtime OS → Decision Trace → Evaluated Evolution

以前の「固有名詞の周囲へLLMが知識を増殖させる」モデルから、Raw Dataに現れた事実を出発点に、意味・関係・ルールを根拠付きで構築し、承認された知識だけを判断に用いるモデルへ。

この転換によって、Knowledge Flowは検索のための前処理ではなく、組織が判断し、説明し、学び直すための知識インフラになる。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance