製造業の機密データを外へ出さずに進めるSemantic Chunk LLMを前提にしない、公開知識と社内証拠を分けた設計

🎥 YouTubeでも公開しています

機密データを外に出さないAI活用｜Semantic Chunk・Knowledge Graph・No-LLM Mode

Books: Semantic Chunk 根拠ある意味単位からつくる: 文書・表・業務データを、説明可能で実行可能な知識へ

製造業でSemantic ChunkやKnowledge Graphを導入しようとすると、すぐに一つの大きな懸念に突き当たる。保全記録、品質異常報告、MESやERPの実績、BOM、設計変更、図面、工程条件には、顧客固有の仕様や自社の製造ノウハウが含まれる。これらを外部のLLMへ送ってよいとは限らない。

ここで重要なのは、Semantic Chunkを「LLMに文書を読ませること」と同一視しないことである。Semantic Chunkとは、本来、原文を後から確認できる根拠とともに、設備、部品、工程、事象、対処、結果といった意味の単位へ整理することを指す。LLMはその候補を作るための有力な部品ではあるが、必須条件ではない。

現実的な設計は、公開情報と社内情報を分離することである。公開文書からは一般知識を整備し、社内の機密データは閉域で、ルール、辞書、BERT系モデル、統計的手法、Knowledge Graph、GNNなどを用いて扱う。両者は原文の受け渡しではなく、承認済みの共通概念を介して接続する。

二つのグラフを混ぜない

まず、データを二つの層に分ける。

公開側では、例えば「軸受」という一般概念について、故障モード、観測指標、対処候補を整理できる。

軸受
  ├─ 故障モード：摩耗、潤滑不足、過熱、振動
  ├─ 観測指標：温度、振動、騒音
  ├─ 対処候補：潤滑、交換、芯出し、負荷低減
  └─ 関連設備：モーター、主軸、回転機械

一方、社内側には実際の設備、ライン、部品、実測値、顧客仕様を保持する。

設備_EQ001
  ──使用部品──> 部品_P-782
  ──発生事象──> 異常_EVT-456
  ──対処──> 保全作業_M-91
  ──結果──> 停止時間、再発有無、品質影響

社内の部品や異常を公開概念へ結びつけるときも、実名や数値を公開側へ送る必要はない。社内で管理する対応表に、たとえば次のような関係を記録するだけでよい。

部品_P-782 ──broaderMatch──> 公開概念「軸受」
異常_EVT-456 ──observed-as──> 公開概念「過熱」

この構造により、一般的な「過熱時に確認すべき観測指標」や「関連しうる対処候補」は参照できる。一方で、どの工場の、どの設備で、どの値が出たかは社内から出ない。

先に作るのはLLM基盤ではなく、原文と根拠の基盤

導入の第一段階で固定すべきなのは、モデルではなく原文、権限、根拠である。Semantic Chunkは要約だけを保存するのではなく、原文のどこから得られたかを必ず保持する。

Chunk ID: SC-2026-00124
事象: 主軸の温度異常
対象: 設備_EQ001
暫定対処: 回転条件変更、部品交換
確信度: 0.82
根拠: 保全記録 MR-2026-054、3ページ、段落2・表4
閲覧権限: 生産技術部・保全部

原文、版数、文書ID、権限、根拠位置、抽出・修正・承認の履歴を社内に残しておけば、モデルを変更しても、抽出結果を訂正しても、判断の再現性を失わない。逆に、AIの要約だけが残る設計では、品質保証や監査、再発防止に使える知識基盤にはならない。

LLMなしで作るSemantic Chunkの骨格

製造業の帳票には、すでに多くの構造が存在する。設備番号、部品番号、異常コード、日付、工程、担当者、処置区分などである。これらはまず、既存マスタ、帳票定義、正規表現、辞書、OCR・レイアウト解析で抽出できる。

保全記録に「振動が大きいため軸受を交換」と書かれている場合、初期段階で原因を自動確定する必要はない。以下のように、確定した情報と未確定情報を分ければよい。

対象設備: 設備番号から確定
事象候補: 振動異常
対処候補: 軸受交換
原文: そのまま保持
根拠位置: 自由記述欄
未確定項目: 発生原因、効果確認

この「未確定を未確定のまま残す」ことが、根拠のない知識グラフ化を防ぐ。AIやルールは候補を出すが、証拠がない原因や因果を事実として登録しない。

人の役割は全件入力ではなく、基準と例外の判断

公開知識グラフや社内との対応表を全件手作業で作るのは現実的ではない。そこで最初に人が決めるのは、対象業務に必要な最小限の共通語彙である。保全業務なら、最初は次の規模で足りる。

設備種別：ポンプ、モーター、主軸、コンプレッサー
部品種別：軸受、ベルト、シール、ギア
事象：過熱、振動、異音、漏れ、停止
対処：点検、給脂、調整、交換、停止
結果：復旧、要観察、再発、品質影響

この共通語彙を基準に、機械が候補を作り、人は不確実または影響の大きいものだけを承認する。

例えば「深溝玉軸受 6205」は高確信度で「軸受」へ接続できる。しかし「回転支持モジュール Z7」や顧客専用部品は、意味を推測して確定してはならない。この差を表現するため、関係を単純な is-a に限定しない。

人がレビューすべきなのは、新しい部品種別・工程・不良区分、安全や品質保証、顧客報告に影響する接続、確信度の低い候補、従来知見と矛盾する候補である。これにより、専門家の時間を全件入力ではなく、意味と責任が重要な箇所に集中できる。

GNNは最後ではなく、根拠付きグラフの後に使う

GNNは、設備、部品、工程、不良、保全、品質結果の関係を利用して、類似性や未発見の関係を推定するのに役立つ。ただし、グラフさえ作れば自動的に正しい知識が生まれるわけではない。ノードとエッジの定義、時点、権限、原文根拠が先に必要である。

根拠付きグラフが整った後であれば、GNNや統計モデルは次の候補を提示できる。

• 類似設備で起きやすい異常
• 部品変更が停止時間や品質へ与えうる影響
• 未登録の「設備―部品」「事象―対処」関係
• 再発しやすい工程や条件の組合せ

ただし、出力は対策を自動実行する指示ではなく、確認すべき候補として扱う。利用者には予測値だけでなく、参照した履歴、グラフ経路、原文根拠を示す必要がある。

段階的な導入順序

最初から全社の図面、BOM、品質、保全を対象にしない。一工場の保全記録、または一製品群の品質異常報告など、一業務に絞る。対象期間も直近1〜3年、件数も数千〜数万件程度から始める。

評価するのはAI精度だけではない。

• 過去事例の探索や報告作成がどれだけ短縮されたか
• 設備、異常、対処の抽出をどの程度人が修正したか
• 原文根拠を正しく提示できたか
• 権限外の文書や顧客横断情報を表示しなかったか
• どの自由記述だけが、将来の閉域LLM導入を必要とするか

その結果を見て初めて、閉域LLMや専用クラウド環境に投資すべき範囲を判断できる。閉域LLMは最初から必須の前提ではなく、ルールやBERTでは扱いにくい自由記述を、外部へ出さずに処理する必要が確認されたときに追加すればよい。

おわりに

製造業のSemantic Chunkで最初に問うべきことは、「どのLLMを使うか」ではない。原文、権限、根拠、承認履歴を社内に保持したまま、どの意味を共通化し、どの判断を人に残すかである。

公開情報は一般概念と参照根拠を整えるために活用し、社内情報は閉域で、構造化データ、ルール、BERT、機械学習、Knowledge Graph、GNNを組み合わせて扱う。両者を共通概念IDで接続すれば、機密を外へ出さずに、一般知識と自社の実績を同じ分析・判断の枠組みで利用できる。

LLMは、その基盤を置き換えるものではない。必要な範囲で差し替えられる、候補生成の一部として位置づけることが、長期に安全で運用可能な知識基盤につながる。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance