Knowledge Acquisition in Knowledge Flow 企業ドキュメントをAIが理解できる形へ変換する

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

Knowledge Flowの最初のステップは、企業内に散在する情報を収集し、AIが扱いやすい形式へ統一することです。

生成AIが利用できる知識基盤を構築するためには、まず企業内の情報を「読む」だけではなく、「構造化できる状態」に変換する必要があります。

なぜDocument Ingestionが重要なのか

企業には、何十年にもわたって蓄積された膨大な情報があります。

しかし、それらは様々な場所に分散しています。

例えば、

• SharePoint
• Confluence
• Google Drive
• Microsoft OneDrive
• GitHub
• Box
• Dropbox
• Slack
• Microsoft Teams
• Outlookメール
• ファイルサーバ
• NAS
• S3
• 社内Wiki
• データベース
• ERP
• CRM

などです。

さらに保存形式も、

• PDF
• Word
• Excel
• PowerPoint
• HTML
• Markdown
• CSV
• JSON
• XML
• CAD図面
• ソースコード
• ログファイル

など様々です。

つまり企業には、

フォーマットの異なる知識

が大量に存在しています。

Knowledge Flowでは、最初にこの多様な情報を一つのパイプラインへ集約します。

コネクタ（Connector）

Document Ingestionでは、

各システム専用のConnectorを用意します。

例えば、

SharePoint Connector
Confluence Connector
Slack Connector
Teams Connector
GitHub Connector
Google Drive Connector
Outlook Connector
S3 Connector
File System Connector

それぞれがAPIを利用して

• 新規作成
• 更新
• 削除

を監視します。

例えばSharePointなら

SharePoint

↓

Microsoft Graph API

↓

Knowledge Flow

Slackなら

Slack

↓

Slack Events API

↓

Knowledge Flow

GitHubなら

Git Push

↓

Webhook

↓

Knowledge Flow

になります。

このため、

企業の利用システムが増えても、

Connectorを追加するだけで対応できます。

イベント駆動アーキテクチャ

Knowledge Flowでは、

夜間バッチで全ファイルを読み直すことはしません。

新しいイベントだけを処理します。

例えば、

Word更新

↓

Document Updated Event

↓

Queue

↓

Parser

あるいは、

Slack投稿

↓

Message Event

↓

Queue

↓

Parser

になります。

一般的には

• Kafka
• RabbitMQ
• AWS SQS
• Azure Service Bus

などのメッセージキューを利用します。

これにより、

数百万件のドキュメントでもリアルタイム更新が可能になります。

フォーマット変換

次に、

各ファイルを共通フォーマットへ変換します。

例えば、

Contract.pdf

↓

PDF Parser

↓

Markdown

Wordなら

Specification.docx

↓

Docx Parser

↓

Markdown

PowerPointなら

Architecture.pptx

↓

Slide Parser

↓

Markdown

Excelなら

Inventory.xlsx

↓

Table Extractor

↓

Markdown + JSON

メールなら

Outlook

↓

Mail Parser

↓

Markdown

HTMLなら

HTML

↓

HTML Cleaner

↓

Markdown

ソースコードなら

Python

↓

AST Parser

↓

Markdown

という流れになります。

なぜMarkdownなのか

Knowledge Flowでは、

中間フォーマットとしてMarkdownを採用します。

例えばWordでも

# 品質管理手順

## 検査

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

という形になります。

Markdownには、

• 見出し
• 箇条書き
• 表
• コード
• リンク

などの構造情報を保持できるという利点があります。

LLMもMarkdownを非常に扱いやすく、

後続のチャンク分割や知識抽出の精度が向上します。

一方で、

表形式や数値データはJSONとして保持します。

例えば、

{
  "part_number": "A-100",
  "inspection_rate": 0.03,
  "factory": "Tokyo"
}

のように、

構造化データはJSONのまま利用します。

ドキュメントメタデータの付与

本文だけではなく、

すべてのドキュメントにメタデータを付与します。

例えば、

{
  "document_id": "DOC-001245",
  "title": "品質管理マニュアル",
  "author": "品質保証部",
  "department": "QA",
  "version": "3.2",
  "created_at": "2026-01-15",
  "updated_at": "2026-06-01",
  "language": "ja",
  "security": "Internal",
  "source": "SharePoint"
}

これらは後続処理で非常に重要になります。

例えば、

• 最新版のみ利用する
• 部署限定で検索する
• 機密文書を除外する
• 作成者ごとに知識を分析する

といった制御が可能になります。

OCRとマルチモーダル解析

企業には、

スキャンされたPDFや画像も大量に存在します。

例えば、

• 手書きメモ
• 設備写真
• CAD図面
• ホワイトボード
• 工場の帳票
• 点検記録

などです。

これらは、

OCRやマルチモーダルLLMを利用して解析します。

例えば、

Scanned PDF

↓

OCR

↓

Markdown

あるいは、

Factory Drawing

↓

Vision LLM

↓

Component List

↓

Markdown

という流れになります。

これにより、

従来検索できなかった情報もKnowledge Flowへ取り込めます。

重複排除とバージョン管理

企業では、

同じ資料が複数存在することが珍しくありません。

例えば、

仕様書_v1.docx

仕様書_v2.docx

仕様書_最新版.docx

Knowledge Flowでは、

• ハッシュ値
• タイトル
• 内容類似度
• 更新日時

を利用して重複を判定します。

さらに、

最新版を管理しながら、

変更履歴も保持します。

これにより、

知識の進化を追跡できるようになります。

Step 1の成果物

Document Ingestionが完了すると、

すべての情報は共通形式へ統一されます。

Enterprise Systems

        │

        ▼

Connectors

        │

        ▼

Parser

        │

        ▼

Markdown + JSON

        │

        ▼

Metadata

        │

        ▼

Knowledge Flow

この時点では、まだAIは「知識」を理解しているわけではありません。

しかし、企業内のあらゆる情報が共通フォーマットに正規化され、メタデータとともに管理されることで、次のステップであるDocument ChunkingやKnowledge Extractionを高精度に実行できる土台が整います。

Knowledge FlowにおいてDocument Ingestionは単なるデータ収集ではなく、企業に散在する情報をAIが理解可能な知識へ変換するための最初の基盤となる重要なプロセスなのです。