RAGの障害は、検索の前から始まることがあります。古い文書、取りこぼした表、責任者のいない情報源、失われた権限メタデータ、削除されていないベクトル、矛盾する隠しテキスト、安全でないファイルです。
安全な文書取り込みは、社内ナレッジの情報源管理です。検索システムに何が入るか、誰が見られるか、鮮度をどう追跡するか、削除がどう動くか、悪い入力をどう見つけるかを決めます。
この記事では取り込み層を扱います。PDF、OCR、メタデータ、権限、保持、運用上の確認です。
利用者が情報源のシステムで文書にアクセスできないなら、RAGシステム内のチャンク、埋め込み、要約、キャッシュ済み回答にもアクセスできないようにします。権限メタデータは任意ではありません。
取り込みパイプライン
本番パイプラインには、明示した段階を置くべきです。
- 情報源の登録。
- データの分類。
- ファイルの安全確認。
- テキスト抽出とOCR。
- 構造の保持。
- メタデータの付与。
- 権限の対応付け。
- チャンク化と埋め込み。
- 品質確認。
- インデックスの公開。
- 保持と削除の処理。
- 運用上の所有。
具体的なツールは変わり得ます。統制点は変えるべきではありません。
ステージ1：情報源の登録
つなぎやすいという理由で、無作為なフォルダを取り込んではいけません。
情報源ごとに、次を記録します。
- 情報源名
- 正式な記録元となる基幹システム
- 情報源の責任者
- データの責任者
- 許可する利用者または役割
- 文書の種類
- 機密度
- 保持ルール
- 更新頻度
- 削除時の挙動
- 確認の予定
情報源の例：
- 公開ヘルプセンター
- 社内サポート手順書
- 営業資料
- 顧客契約
- 人事方針
- エンジニアリングのランブック
- 製品ドキュメント
- 会議の文字起こし
これらの情報源を、同じ権限で同じインデックスに入れるべきではありません。
ステージ2：抽出前にデータを分類する
モデルや埋め込みプロバイダーが内容を見る前に、情報源を分類します。
使える区分：
| 区分 | 例 | 既定の姿勢 |
|---|---|---|
| 公開 | 公開済み文書、マーケティングページ | 広い検索を許可 |
| 社内 | 手順書、プロセス文書 | 社内のみ、役割で絞り込む |
| 機密 | 契約、顧客情報、財務 | 役割を制限し、ログを強める |
| 規制対象／機微 | 健康、法務、人事、給与、セキュリティインシデント | 明示的に承認されない限り避ける |
分類は、コンプライアンスの書類作業だけではありません。内容をホスト型の埋め込みAPIへ送れるか、共有ベクトルデータベースへ保存できるか、ログへ含められるか、評価の例に使えるかを決めます。
ステージ3：ファイルの安全確認
文書は、敵意を持つことも、単に壊れていることもあります。
抽出の前に：
- ファイル種別を許可リストと照合する
- ファイルサイズの上限を適用する
- 環境が求める場合はマルウェアを検査する
- 承認済みの復号経路がない暗号化ファイルを拒否する
- 未対応の埋め込みオブジェクトを含むファイルを拒否する
- ファイル名を正規化する
- 元ファイルのハッシュを保存する
- アップロードまたは接続した主体を記録する
管理者以外が文書をアップロードできる場合、これは特に重要です。取り込みを管理者だけにすれば脅威経路の1つは下がりますが、侵害された、悪意のある、過大な、または壊れた文書が安全になるわけではありません。コネクタとURLからの取り込みにも、許可リストに登録したオリジン、リダイレクトとDNSの統制、認証スコープの限定、レート制限、SSRFのテストが必要です。
信頼できない利用者がファイルをアップロードできるなら、解析の前にファイル安全層を実装してください。保守されているOWASP File Upload Cheat Sheetを基準とし、選んだパーサーと保存経路の脅威モデルを作ってください。汚染、権限漏えい、プロンプトインジェクション、安全でない出力を含む、より広い検索の脅威モデルには、OWASP RAG Security Cheat Sheetも使ってください。
統制の候補には、ファイル内容から検証した許可リスト上の種別、サイズとアーカイブ展開の上限、無作為化した保存名、シグネチャ検査、外部通信なしでリソース上限を付けた隔離解析、脅威モデルが正当化するならコンテンツの無害化と再構築があります。スキャナー単体では、ファイルが安全だと示すことはできません。
ステージ4：テキスト抽出とOCR
実務上、PDFは一つの形式ではありません。選択できるテキストを含むものもあれば、スキャンもあります。段組み、表、脚注、フォーム、コメント、押印、隠しテキスト層があるものもあります。
文書の種類に応じて抽出経路を選びます。電子的に作られたPDF向けのテキスト優先抽出、構造化文書向けのレイアウト対応変換、スキャン向けのOCRを比較してください。ツールの選択は、測定したレイアウト／表の精度、言語対応、ライセンス、パッチ手順、データの境界に従う必要があります。
しきい値について：ブログ記事にある一律のOCR信頼度を採用してはいけません。自社文書のサンプルで較正してください。実用的な形は2つの帯です。下の帯を下回るページは拒否し、帯のあいだは人による確認へ回し、上の帯を上回るページは通過させます。帯の位置は、スキャナー、文書の古さ、言語に依存します。
エストニア語や多言語のアーカイブでは、発音区別符号、古いタイプ打ちページ、表、押印、エストニア語とロシア語の例をベンチマークに含めてください。選んだOCRエンジンに必要な言語データがあることを確認し、代表的なページで文字、単語、項目、表の精度を測ります。一律の試行期間を約束してはいけません。
抽出品質を追跡します。
- 抽出方法
- OCR信頼度
- ページ数
- 抽出した文字数
- 表抽出の状態
- 検出した言語
- テキストのないページ
- パーサーの警告
品質の低い抽出を、静かにインデックスへ入れてはいけません。確認へ回すか、信頼度が低いと印を付けます。
よくある問題：
- 列を誤った順で読む
- 表の行を誤って結合する
- 見出しがすべてのチャンクで繰り返される
- スキャンページが丸ごと欠ける
- 手書きメモが無視される
- 隠しテキスト層が、見えるスキャンと矛盾する
- OCRが口座番号を誤変換する
価値の高い文書では、表示したページと抽出テキストを抜き取りで照合してください。
ステージ5：構造を保持する
RAGシステムに必要なのはテキストだけではありません。有用で、情報源に根ざした回答を出すための十分な構造が必要です。
保持します。
- タイトル
- 見出しの経路
- セクション番号
- ページ番号
- 表のキャプション
- リストの境界
- 文書のバージョン
- 発効日
- 情報源のURLまたは保存パス
見出しとページ参照を付けてテキストをチャンク化します。「次を適用する」とだけ書き、直前の見出しがないチャンクは、弱い根拠です。
表については、次のいずれにするかを決めてください。
- 表をMarkdownとして残す
- 構造化JSONへ変換する
- テキストと構造化行の両方を保存する
- より良いパーサーが使えるまで除外する
正確な価格、日付、上限、しきい値に依存するユースケースで、表抽出が解決済みであるかのように装ってはいけません。
ステージ6：メタデータを付与する
すべてのチャンクに、検索を越えて残るメタデータを持たせます。
{
"sourceId": "policy-2026-expenses",
"documentId": "doc_123",
"tenantId": "tenant_a",
"visibility": "internal",
"allowedRoles": ["finance", "leadership"],
"sensitivity": "confidential",
"sourceOwner": "Finance",
"version": "2026-02",
"lastReviewedAt": "2026-02-10",
"effectiveFrom": "2026-03-01",
"page": 7,
"headingPath": ["Travel", "Hotel limits"],
"contentHash": "sha256:..."
}
メタデータは、方針適用への入力を運びます。それ自体が方針を強制するわけではありません。アプリケーションは、信頼できるメタデータの由来を検証し、公開、検索、キャッシュ、引用、生成、エクスポートの各境界で認可を強制する必要があります。
ステージ7：権限の対応付け
権限の強制は、検索結果がモデルに届く前に行い、IDや方針が変わっている可能性のある回答、引用、キャッシュ、エクスポートの各境界でも改めて行います。
良いパターン：
- 利用者が質問する。
- アプリケーションが認証からテナント、利用者、役割、グループ、データ権限を導く。
- リトリーバーが権限で候補チャンクを絞り込む。
- 許可されたチャンクの中で順位付けする。
- モデルは許可されたチャンクだけを受け取る。
悪いパターン：
- 広く検索する。
- ありそうなチャンクをすべてモデルへ送る。
- プロンプトが「利用者がアクセスしてよいチャンクだけを使って答えてください」と言う。
悪いパターンでは、その時点ですでにデータをモデルのコンテキストへ露出しています。
情報源の権限が複雑なら、より狭く始めてください。回答を取りこぼす方が、機密文書を漏えいさせるよりましです。
ステージ8：チャンク化と埋め込み
チャンク化は、検索のチューニングだけでなく、セキュリティと品質の判断です。
指針：
- チャンクを権限の境界内に収める。
- 公開テキストと機密テキストを1つのチャンクにまとめない。
- 見出しと情報源への参照を含める。
- 無関係な節を含む巨大なチャンクを避ける。
- 文脈を失う小さなチャンクを避ける。
- 情報源のテキストまたはメタデータが変わったら、埋め込みを作り直す。
- 埋め込みモデルとバージョンを保存する。
機微な情報源では、埋め込みプロバイダー、ベクトルストア、ログが、そのデータ区分で承認されているかを確認してください。
ステージ9：品質ゲート
情報源を本番検索へ公開する前に、確認します。
- すべての文書に責任者がいる
- すべてのチャンクに権限メタデータがある
- 古い文書に印が付いている
- 抽出に失敗したページが除外または確認されている
- サンプル質問が期待する情報源を返す
- 権限のない利用者が、制限されたチャンクを一件も取得しない
- 削除した文書が検索から消える
- 引用が有効な情報源の位置を指す
- 文書内の不審な指示が、従う対象ではなく内容として隔離されている
最後の点は重要です。文書にはプロンプトインジェクションが含まれ得ます。取り込みパイプラインは、そのようなテキストをすべて黙って削除すべきではありません。利用者が文書の記載を知る必要がある場合があり、削除は根拠を損なうことがあるためです。実行時は、取得した内容をデータ用の経路に置き、ツールの付与や方針の変更ができないようにし、ツール引数を独立して検証し、影響の大きい効果には人による承認を求めてください。
ステージ10：インデックス版をアトミックに公開する
一部しか取り込まれていない文書や、古い権限と新しい権限の混在を、稼働中のインデックスへ漏らしてはいけません。候補インデックスまたは版付きの名前空間を作り、次を行います。
- 情報源／版のマニフェストと内容ハッシュを固定する。
- 文書数、抽出失敗、権限の網羅、重複方針、埋め込みモデル／リビジョン、代表的な権限あり／権限なしのクエリを検証する。
- 候補版、情報源の版、テスト結果、承認者、ロールバック先を記録する。
- ストアが対応していれば、エイリアスまたはアプリケーションの参照を承認済み版へアトミックに切り替える。
- 検索と回答のキャッシュを無効化するか、版を分ける。
- 昇格後のエラー、アクセス拒否、空の検索、旧版へのトラフィックを監視する。
ベクトルストアが版をアトミックに切り替えられない場合は、不完全なレコードを除外する公開状態をアプリケーション側に実装し、昇格中の同時読み取りをテストしてください。権限の取り消しと緊急の情報源削除を、完全な再構築まで待たせてはいけません。現行の認可をインデックスの外でも強制し、対象情報源を直ちに拒否し、関連キャッシュを消去し、ライフサイクルワークフローで派生データの後始末を完了します。
ロールバックは、取り消したアクセスや削除済みデータを戻さず、直前の承認済みインデックス参照だけを復元する必要があります。ロールバックが、置き換えられたACL、削除済み文書、汚染された情報源、古いキャッシュ回答を復活させないことをテストしてください。
ステージ11：保持と削除
RAGシステムは、情報源のシステムより長くデータを残してしまうことがよくあります。
GDPR第17条は、条件と例外付きの消去権を定めています。適用される義務と適法な保持は、適切な資格を持つ法律専門家が判断しなければなりません。システムには、すべての複製と派生物について、棚卸しとライフサイクル操作がなお必要です。
- 元ファイルのキャッシュ
- 抽出テキスト
- チャンク
- 埋め込み
- 要約
- サムネイルまたは描画したページ
- 評価サンプル
- ログ（承認済みの最小化と保持根拠付き）
- バックアップ（文書化した期限切れと復元の挙動付き）
文書が削除されるか、アクセスが取り消されたら、文書化した目標時間内に、検索と応答キャッシュがそれを返すのを止める必要があります。削除ワークフローは派生ストアも対象とし、古いバックアップや遅れた取り込みジョブがレコードを復活させないようにします。
追跡します。
- deletedAt
- deletedByまたは情報源のイベント
- 削除理由
- 下流の後始末状態
- 検証結果
「画面から消した」だけに頼ってはいけません。ベクトルストアとキャッシュは忘れやすいためです。
ステージ12：運用上の所有
本番の情報源には、説明責任を負う責任者と、変更の速さと影響から導いた確認の契機または周期が必要です。
情報源ごとに定めます。
- 取り込みを承認する人
- 権限変更を承認する人
- 古い文書を確認する人
- 抽出失敗に対応する人
- データ削除の依頼に対応する人
- 検索の誤りを調べる人
誰も所有していない情報源は、本番RAGシステムに入れてはいけません。
情報源のガバナンスであり、保証ではない
安全なRAG取り込みは、意図した情報源のガバナンスです。検索の挙動と障害を、より観測しテストしやすくします。生成された回答が本質的に正しく安全になるわけではありません。
中核の統制：
- 情報源を登録する
- データを分類する
- 解析の前にファイルを確認する
- 抽出品質を測る
- 構造を保持する
- メタデータを付与する
- 検索の前に権限を強制する
- 権限のないアクセスをテストする
- 削除に対応する
- 責任者を割り当てる
情報源の品質と情報源の統制は、回答の品質と安全性に必要な入力であり、保証ではありません。検索、認可、根拠付け、回答拒否、ツール利用、ライフサイクルの挙動を、端から端まで検証してください。
