RAGの障害の多くは、検索前に始まっています。文書が古かった。OCRが表を読み取れなかった。情報源に担当者がいなかった。権限メタデータが失われていた。削除済みの契約書がベクトルストアに残っていた。スキャンされたPDFに、誰もレビューしていない非表示テキストが含まれていた。取り込みパイプラインが「テキストが存在する」ことを「ナレッジとして安全に使用できる」ことと同一視したため、システムは自信を持って回答してしまいました。
安全な文書取り込みは、企業ナレッジのソース管理です。何を検索システムに取り込むか、誰が閲覧できるか、鮮度をどう追跡するか、削除をどう処理するか、不適切な入力をどう検出するかを決定します。
本記事では、PDF、OCR、メタデータ、権限、保持、運用上のチェックという取り込み層を扱います。
ユーザーが情報源となるシステム上の文書にアクセスすべきでないのであれば、RAGシステム内のチャンク、埋め込み、要約、キャッシュされた回答にもアクセスすべきではありません。権限メタデータは必須です。
取り込みパイプライン
本番環境のパイプラインには、明確な段階が必要です。
- 情報源の登録。
- データの分類。
- ファイルの安全性チェック。
- テキスト抽出とOCR。
- 構造の維持。
- メタデータの付与。
- 権限のマッピング。
- チャンク化と埋め込み。
- 品質チェック。
- インデックスの公開。
- 保持と削除の処理。
具体的なツールは異なっても構いません。管理ポイントは変えるべきではありません。
ステージ1：情報源の登録
接続しやすいという理由で、無作為にフォルダを取り込んではいけません。
情報源ごとに次の項目を記録します。
- 情報源の名前、
- 正式な記録元となる基幹システム、
- 情報源の担当者、
- データの責任者、
- 許可されたユーザーまたはロール、
- 文書の種類、
- 機密性レベル、
- 保持規則、
- 更新頻度、
- 削除時の動作、
- レビュー周期。
情報源の例：
- 公開ヘルプセンター、
- 社内サポート手順書、
- 営業資料、
- 顧客との契約書、
- 人事規程、
- エンジニアリング運用手順書、
- 製品ドキュメント、
- 会議の文字起こし。
これらすべての情報源を、同一の権限を持つ同一のインデックスに格納すべきではありません。
ステージ2：抽出前にデータを分類する
モデルまたは埋め込みプロバイダーがコンテンツを受け取る前に、情報源を分類します。
有用な分類：
| 分類 | 例 | 基本方針 |
|---|---|---|
| 公開 | 公開済み文書、マーケティングページ | 広範な検索を許可 |
| 社内 | 手順書、業務プロセス文書 | 社内限定、ロールで絞り込み |
| 機密 | 契約書、顧客情報、財務情報 | ロールを制限し、ログ記録を強化 |
| 規制対象／センシティブ | 医療、法務、人事、給与、セキュリティインシデント | 明示的に承認されない限り使用を避ける |
分類は単なるコンプライアンス上の書類作業ではありません。コンテンツをホスト型の埋め込みAPIへ送信できるか、共有ベクトルデータベースに保存できるか、ログに含められるか、評価用の例に使用できるかを決定します。
ステージ3：ファイルの安全性チェック
文書には悪意が含まれている場合もあれば、単に壊れている場合もあります。
抽出前に次の処理を行います。
- 許可リストと照合してファイル形式を確認する、
- ファイルサイズの上限を強制する、
- 環境で必要な場合はマルウェアをスキャンする、
- 承認済みの復号経路がない限り、暗号化されたファイルを拒否する、
- サポートされていない埋め込みオブジェクトを含むファイルを拒否する、
- ファイル名を正規化する、
- 元ファイルのハッシュを保存する、
- ファイルをアップロードまたは接続した人物を記録する。
管理者以外のユーザーが文書をアップロードできる場合、これは特に重要です。管理者のみに取り込みを限定すればリスクは低下しますが、なくなるわけではありません。
ほとんどのRAGスタックでは、ウイルス対策やコンテンツ無害化の統制は自動的に備わっていません。信頼できないユーザーがファイルをアップロードできる場合は、解析前に実効性のあるファイル安全層を追加します。
この層の実務的な構成を警戒度の低い順に挙げると、最低限としてシグネチャスキャナー（ClamAVクラス）、次に外部通信を遮断した分離コンテナ内での解析です。PDFおよびオフィス形式のパーサーには長年にわたるCVEの履歴があるため、パーサー自体を攻撃対象領域として扱います。さらに、真に信頼できない経路から受け付ける場合は、元ファイルを信頼せず、無害なファイルとして再構築するコンテンツ無害化・再構築（CDR）を使用します。中小企業のパイプラインの大半では最初の2つが必要です。外部の人が文書を送信できる場合はCDRを追加します。
ステージ4：テキスト抽出とOCR
実際のところ、PDFは単一の形式ではありません。選択可能なテキストを含むものもあれば、スキャン画像であるものもあります。段組み、表、脚注、フォーム、コメント、スタンプ、非表示のテキストレイヤーを含む場合もあります。
文書の種類に応じて抽出方法を選択します。デジタルで作成されたPDFにはテキスト優先の抽出ツール（PyMuPDFまたはpdfplumberクラス）、構造化文書にはレイアウトを認識する変換ツール（DoclingまたはUnstructuredクラス。表と読む順序がはるかによく維持されます）、実際のスキャン画像に限ってOCRを使用します（自社運用の基準としてTesseract、スキャン品質が低く、データ分類上許可される場合はクラウドOCRサービス）。
しきい値については、ブログ記事に書かれた汎用的なOCR信頼度のしきい値をそのまま採用してはいけません。自社文書のサンプルを使って調整します。実用的なのは2つの境界値を設ける方法です。下限を下回るページは即座に拒否し、2つの境界値の間にあるページは人による確認待ちのキューに入れ、上限を超えるページはそのまま処理します。境界値をどこに設定するかは、スキャナー、文書の古さ、言語によって異なります。
私たちの市場に固有の注意点があります。エストニア語のOCRは英語のOCRより困難です。Tesseractにはエストニア語モデルが付属していますが、õ/ä/ö/ü、古いタイプライター文書、エストニア語とロシア語が混在する文書に対する精度には大きなばらつきがあります。そのため、エンジンを決定する前に、自社アーカイブを代表するサンプルで比較試験を行うべきです。エストニア企業にとって、この半日の試験によって、後から発生する表面化しにくい検索障害の4分の1を回避できます。
抽出品質について次の項目を追跡します。
- 抽出方法、
- 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：権限のマッピング
検索結果がモデルに到達する前に、権限のマッピングを行う必要があります。
適切なパターン：
- ユーザーが質問する。
- アプリケーションが認証情報からテナント、ユーザー、ロール、グループ、データ権限を取得する。
- 検索処理が権限に基づいて候補チャンクを絞り込む。
- 許可されたチャンクの中でランキングを行う。
- モデルは許可されたチャンクだけを受け取る。
不適切なパターン：
- 広範囲に検索する。
- 関連性が高いと思われるすべてのチャンクをモデルに送信する。
- プロンプトで「ユーザーがアクセスできるチャンクだけを使って回答する」よう指示する。
不適切なパターンでは、その時点ですでにモデルのコンテキストへデータが開示されています。
情報源の権限が複雑な場合は、より狭い範囲から始めます。機密文書を漏えいするより、回答を提示できない方が適切です。
ステージ8：チャンク化と埋め込み
チャンク化は、検索を調整するためだけの判断ではなく、セキュリティと品質に関する判断でもあります。
ガイドライン：
- チャンクを権限の境界内に収める。
- 公開テキストと機密テキストを1つのチャンクに統合しない。
- 見出しと情報源への参照を含める。
- 無関係なセクションを含む巨大なチャンクを避ける。
- コンテキストを失うほど小さなチャンクを避ける。
- 情報源のテキストまたはメタデータが変更されたら、埋め込みを再生成する。
- 埋め込みモデルとバージョンを保存する。
機密性の高い情報源については、埋め込みプロバイダー、ベクトルストア、ログがそのデータ分類で承認されているかを確認します。
ステージ9：品質ゲート
情報源を本番環境の検索対象として公開する前に、次のチェックを実行します。
- すべての文書に担当者がいる、
- すべてのチャンクに権限メタデータがある、
- 古い文書にフラグが付いている、
- 抽出に失敗したページが除外またはレビューされている、
- サンプルの質問で期待する情報源を検索できる、
- 権限のないユーザーが取得する制限付きチャンクがゼロである、
- 削除済み文書が検索結果から消える、
- 引用が有効な情報源の場所を指している、
- 文書内の疑わしい指示がコンテンツとして分離され、実行されない。
最後の点は重要です。文書にはプロンプトインジェクションが含まれる可能性があります。ユーザーが文書の内容を知る必要がある場合もあるため、取り込みパイプラインですべてを削除すべきではありません。ただし、実行時には、信頼できない文書コンテンツとして扱う必要があります。
ステージ10：保持と削除（GDPR第17条が適用される場所）
RAGシステムは、情報源となるシステムよりも長期間、誤ってデータを保持することがよくあります。
このステージでは、GDPRの消去権（第17条）が、ポリシー上の記述ではなく、エンジニアリング要件になります。削除要求を受けた際、パイプライン内の別の場所に複製が残っているなら、「元ファイルを削除しました」という回答は正当化できません。削除の対象には次のものを含める必要があります。
- 元ファイルのキャッシュ、
- 抽出したテキスト、
- チャンク、
- 埋め込み、
- 要約、
- サムネイルまたはレンダリング済みページ、
- 評価用サンプル、
- 法的に必要な場合はログ、
- ポリシーに従ったバックアップ。
文書が削除された場合、またはアクセス権が取り消された場合、検索でそのチャンクが返されないようにする必要があります。機密性の高い情報源については完全削除をサポートし、バックアップについては保持方針を文書化することが理想です。
次の項目を追跡します。
- deletedAt、
- deletedByまたは情報源のイベント、
- 削除理由、
- 下流のクリーンアップ状況、
- 検証結果。
「UIから削除した」だけで済ませてはいけません。ベクトルストアやキャッシュは簡単に見落とされます。
ステージ11：運用上の責任
すべての情報源に担当者が必要です。すべての担当者について、レビュー周期を定める必要があります。
情報源ごとに次の役割を定義します。
- 取り込みを承認する人、
- 権限の変更を承認する人、
- 古い文書をレビューする人、
- 抽出の失敗に対応する人、
- データ削除要求に対応する人、
- 検索の誤りを調査する人。
担当者がいない情報源は、本番環境のRAGシステムに取り込むべきではありません。
まとめ
安全なRAGへの取り込みは、良い意味で地味なものです。検索を予測可能にします。
中核となる統制：
- 情報源を登録する、
- データを分類する、
- 解析前にファイルをチェックする、
- 抽出品質を測定する、
- 構造を維持する、
- メタデータを付与する、
- 検索前に権限を適用する、
- 権限のないアクセスをテストする、
- 削除に対応する、
- 担当者を割り当てる。
良い回答は、良い情報源から生まれます。安全な回答は、優れた情報源の統制から生まれます。
