Semantic Chunkは、生成AIに渡してよい知識の境界をつくる

🎥 YouTubeでも公開しています

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

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

生成AIを製造業の業務で使おうとすると、必ず問いが生じる。

設計資料、保全記録、VOC、顧客仕様を、どこまでAIに渡してよいのか。

ここで重要なのは、AIに「全社の文書を読ませる」設計から出発しないことである。原文は組織の管理下に残し、利用者の権限と利用目的に応じて、必要最小限の根拠だけを一時的にLLMへ渡す。

この境界を実装する単位が、Semantic Chunkである。

Semantic Chunkは、単にRAGの検索精度を上げるための分割手法ではない。AIが参照してよい情報を制御し、あとから根拠を検証できるようにするための、知識とセキュリティの境界でもある。

「細かく分ける」だけでは安全にならない

長いPDFを章や段落に分割し、小さなチャンクだけをLLMへ渡せば、文書全体を送るより露出範囲は小さくなる。これは重要である。

しかし、細分化だけではセキュリティにならない。

断片の中に顧客名、図面番号、設備構成、輸出管理情報、個人情報が含まれていれば、その断片も機微情報である。また、権限のない資料を検索結果に混ぜてしまえば、どれほど検索精度が高くても漏えいになる。

必要なのは、次の順序を守ることである。

1. 検索の前に、利用者が読める資料だけに絞る
2. 生成の前に、LLMへ渡す情報を最小化する
3. 回答の後に、根拠と処理履歴を確認できるようにする

Semantic Chunkは、この三つをつなぐ最小単位になる。

文書ではなく、許可済みの根拠だけを渡す

例えば、ある利用者が「設備Xで、過去に同様の振動異常はあったか」と尋ねたとする。

望ましくない設計は、保全報告書のPDF全文やフォルダ全体をLLMに投入する方法である。質問とは無関係な顧客情報、作業者情報、他設備の記録まで含まれる可能性がある。

代わりに、システムは次のように動く。

1. 利用者の所属、役割、案件、拠点、閲覧権限を確認する
2. その利用者に許可された資料だけを検索対象にする
3. 「設備X」「振動異常」「原因」「対策」に関係する数段落を取得する
4. 必要に応じて個人名や連絡先をマスキングする
5. 質問と、許可済みの根拠断片だけをLLMへ渡す
6. 回答には文書ID、版、ページ、該当箇所を添える

LLMは文書庫への自由な閲覧権限を持たない。その時点で渡された範囲だけを読み、根拠内で回答する。

Semantic Chunkに持たせるべき情報

チャンクは単なるテキスト片ではない。少なくとも、本文と一緒に次のメタデータを持つ必要がある。

ここで大切なのは、意味的に近いから返すのではなく、返してよいから検索対象にするという順序である。

ベクトル検索やキーワード検索は、ACL（アクセス制御リスト）による絞り込みの後で実行する。検索エンジンが高い関連度を見つけても、利用者に閲覧権限がなければ、そのチャンクは結果に含めない。

高機密情報は「注意」ではなく、システムで止める

高機密資料については、利用者に注意を促すだけでは不十分である。文書登録時のラベル、保管場所、IAM権限、取り込み処理、検索、LLM呼出のそれぞれで拒否する。

まず、文書登録時に以下を必須属性とする。

導入初期の規程は、次のように単純でよい。

• 高機密、輸出管理、防衛関連、原子力安全保障関連、AI利用禁止は、RAG登録もLLM送信も禁止する
• 機密または個別承認が必要は、原則禁止とし、承認済みの案件・目的・期間にだけ例外を認める
• 社内限定以下は、ACL確認、マスキング、最小送信を条件に利用可能とする

禁止資料は、検索画面で非表示にするだけでは足りない。チャンク化も、ベクトル化も、索引化もしない。検索用データベースに入れなければ、後から誤ってLLMへ送られる経路を大きく減らせる。

「隔離棚」と最小権限で守る

既存の文書すべてを、最初からAI検索対象にしてはならない。保管領域を次の三つに分ける。

• ai-eligible：AI検索・LLM利用を許可した資料
• ai-review：分類、契約、権限の確認待ち資料
• ai-excluded：高機密、規制対象、AI利用禁止資料

RAGの取り込みロールには、ai-eligibleだけを読み取る権限を与える。ai-excludedにはアプリケーション上の条件分岐だけでなく、IAM上もアクセスさせない。

この設計なら、アプリケーションに不具合があっても、取り込み処理は対象外の資料を読めない。セキュリティは、一つの判定ロジックに依存させず、複数の層で守るべきである。

例外利用は「例外トークン」として期限付きで管理する

機密資料を使う必要が出ることもある。その場合に、口頭やメールだけで例外を認めると、いつ、誰が、何のために利用できるのかが曖昧になる。

そこで、個別審査の結果をシステム上の承認記録として保持する。

質問時には、対象、利用者、利用目的、期間が承認記録と一致する場合だけ、例外的に検索対象へ加える。期限が切れれば自動的に停止する。

これは「一度許可したから常に使える」のではなく、利用目的に結び付いた、最小限で失効可能な権限にする考え方である。

LLM送信直前にも、もう一度止める

最後の境界は、LLMを呼び出す直前に置く。

検索結果に誤って不適切なチャンクが混入しても、送信前のポリシーチェックで拒否する。

if chunk.ai_use != "allowed":
    block
if chunk.regulatory in prohibited_categories:
    block
if approval is missing or expired:
    block
if user role / project scope is invalid:
    block

拒否時には資料の内容を出さず、次のように案内する。

この資料はAI支援の対象外です。利用が必要な場合は、情報管理責任者へ個別審査を申請してください。

LLMには、根拠に含まれないことを推測しないこと、判断・承認・設計変更を行わないこと、不明点を明示すること、根拠の文書IDと該当箇所を必ず返すことを固定指示として与える。

Semantic Chunkは、知識の最小単位であり、責任の最小単位でもある

Semantic Chunkの価値は、回答を短くすることではない。

どの原文の、どの版の、どの箇所を、誰の権限で、どの目的のために検索し、どのモデルへ渡し、どのような回答が返ったかを追跡できるようにすることである。

その履歴は、単なるアクセスログではない。回答の根拠を検証し、後から改善し、説明責任を果たすためのDecision Traceになる。

生成AIを安全に活用する鍵は、AIにすべてを見せないことにある。原文、権限、判断の主導権は組織の側に残し、AIには許可された根拠の範囲で、検索・要約・説明を支援させる。

Semantic Chunkは、そのためのRAG技術であると同時に、AI時代の知識ガバナンスを実装する基盤なのである。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance