社内の文書を読み込ませたAIに質問しても、的外れな答えが返ってくる——この現象の原因の大半は、AIモデルの性能ではなく文書前処理とチャンク設計にあります。
RAG（検索拡張型AI）のシステムを構築する際、最初に設計する「文書の切り方」と「不要データの除去方法」が、最終的な回答精度を8割方決定します。この記事では、社内RAGシステムの文書前処理とチャンク設計について、情シス兼任担当者が最初に固めるべき3つの設定を、具体的な数値・Before/After・チェックリストで解説します。ベクトルDBの選定基準と精度管理の考え方まで、一記事で整理できます。
社内RAGとは？文書前処理が「精度の9割」を決める理由
RAG（Retrieval-Augmented Generation）とは、社内の文書から関連情報を検索し、その内容を元にAIが回答を生成する仕組みです。情報を外に出さない社内専用AI（ローカルLLM）と組み合わせることで、顧客情報や技術資料を社外に送ることなく、AIを業務活用できる環境が整います。
社内RAGの精度が低い原因として、多くの企業がモデル選定の問題だと誤解します。しかし実際には、文書の前処理とチャンク設計の問題がほとんどです。
RAGの処理フローは3段階で構成されています。
・①文書の取り込みと前処理（インジェスト）: PDFやWord、テキストから文章を抽出し、ノイズを除去するフェーズ
・②チャンク分割とベクトル化（エンコード）: 文書を適切なサイズに分割し、数値ベクトルに変換してベクトルDBに格納するフェーズ
・③クエリとの照合・回答生成（検索・生成）: ユーザーの質問に近いチャンクを取得し、AIが回答を組み立てるフェーズ
このうち①と②の設計精度が、最終的な回答品質の約8割を左右します。どれほど高性能なモデルを使っても、「読み込ませる文書の質」が低ければ精度は向上しません。
具体的な失敗事例を見てみましょう。
PDFマニュアルを前処理なしで取り込んだ場合（Before）、各ページのヘッダーに記載された「株式会社〇〇 社外秘 第3版」という文字列が全ページ分ベクトル化されます。「第3版の内容を確認したい」という質問に対して、本文ではなくヘッダー文字列のチャンクが上位にヒットし、意味のある回答が生成されません。
同じ文書に正規表現でヘッダー除去を適用した場合（After）、ヘッダーが削除された状態の本文テキストがベクトル化されます。同じ質問に対して本文の該当箇所が正確にヒットし、回答の正答率が検証環境で約40%から85%以上に改善しました。
この差を生んだのはモデルの違いではなく、前処理の有無だけです。「前処理の優先度はモデル選定より高い」という認識が、社内RAG設計の出発点です。
社内RAGを使う目的としてよく挙がるユースケースには、社内規程の検索、過去議事録からの情報抽出、製品仕様データの照会、顧問先への対応履歴確認などがあります。いずれも「文書の質」が回答品質を決定するという点は共通しています。前処理とチャンク設計を後回しにして社内専用AIだけを導入しても、期待する精度が出ない構造的な理由がここにあります。
最初に決める設定① 文書タイプ別チャンク戦略
チャンク設計で最初に問うべき質問は「どんな文書をRAGに読み込ませるか」です。文書の種類によって適切なチャンク戦略が異なります。一律のルールを適用すると、特定の文書タイプで精度が著しく落ちます。
中小企業でよく取り込まれる4つの文書タイプと、それぞれに適したチャンク戦略を整理します。
マニュアル・規程類（階層型）
社内規程、業務マニュアル、就業規則などは見出し階層（大項目→中項目→小項目）が明確に定義されています。見出しレベル（H2・H3相当）を境界として文書を分割する「セクション単位分割」が最も精度を出しやすい方法です。
PDFの場合はフォントサイズや太字の有無でヒューリスティックに見出しを検出する前処理が必要です。あらかじめMarkdownやwiki形式に変換してから処理すると、見出し検出が格段に容易になります。「第○条」「第○項」などの条文形式の場合は、条単位を1チャンクの境界とする設計が自然です。
セクション単位分割の利点は、1チャンクが意味的に完結している点にあります。チャンクサイズが多少大きくなっても、文脈の分断が起きにくいため、回答品質が安定しやすい方式です。
議事録・メール・チャット履歴（時系列型）
時系列で記録された文書には明確なセクション区切りがないため、「固定サイズ×オーバーラップ」方式でチャンクを切ります。この方式の詳細は次のセクションで解説します。
議事録では日付と参加者情報をメタデータとして付与することが特に重要です。ベクトルDB側のメタデータフィルタを使えば「2025年以降の議事録のみ検索」といった絞り込みが可能になり、古い情報が回答に混入するリスクを抑えられます。
技術仕様書・表形式データ（構造型）
品番と仕様値が表形式で並ぶ文書は、通常の文章チャンクに埋め込むとベクトル化した際に数値の意味が失われやすいです。表の行単位でチャンク化し、ヘッダー行を各チャンクの先頭に繰り返し付与する処理が有効です。
「品番：A-1234、材質：SUS304、耐熱温度：450℃」という行を独立したチャンクとして扱い、「A-1234の耐熱温度を教えて」というクエリに対して直接ヒットさせます。この処理により、仕様値の検索精度が大きく改善します。
FAQ・Q&Aデータ（ペア型）
既存のFAQ文書をRAGに取り込む場合は、Q（質問）とA（回答）のセットを1つのチャンクとして扱います。Qだけのチャンクを作ると、検索時にQが先行ヒットして回答文が得られないケースが発生します。Qを含むチャンクとAを含むチャンクを分離せず、必ずQ＋Aをひとまとまりのチャンクとして格納します。
この4分類を事前に整理しておくことで、新しい文書が追加されるたびに処理方針を迷わず判断できる体制が整います。分類ルールをドキュメント化して引き継ぎ可能にすることで、担当者交代時のリスクも低減できます。
最初に決める設定② チャンクサイズとオーバーラップ幅の具体値
チャンク戦略が決まったら、次に設定するのがチャンクサイズ（1チャンクに含める文字数）とオーバーラップ幅（隣のチャンクと重複させる文字数）です。この2つの数値を適切に設定することが、RAGの検索精度に直結します。
チャンクサイズの考え方は「1チャンクで完結できる情報の粒度」です。大きすぎると1チャンクに複数の話題が混在し、クエリとの関連度が薄まります。小さすぎると文脈が途切れ、AIが回答を生成するための十分な情報を持てません。
日本語文書での推奨値は以下の通りです（日本語は英語の約2倍の情報密度があるため、英語圏の推奨値の半分程度が目安です）。
・標準チャンクサイズ: 200字～500字
・マニュアル・規程（詳細型）: 150字～300字（小さめに切ることで精度が上がりやすい）
・議事録・レポート（概要型）: 400字～800字（文脈を長めに保つ）
・表データ型: 1行＝1チャンクを基本とし、50字以下になる場合はヘッダー含め100字程度に拡張する
オーバーラップ幅はチャンクサイズの10%～20%が基本です。チャンクサイズ300字なら、オーバーラップ幅は30字～60字に設定します。オーバーラップを設定しない場合、文章の境界部分で重要な文脈情報が分断されます。
具体的なBefore/Afterで確認します。
オーバーラップなし（Before）の問題：製造手順マニュアルで、チャンク①の末尾が「冷却後に検査工程へ移す」で終わり、チャンク②の先頭が「合格基準は以下の通り」から始まる場合を考えます。「検査の合格基準を教えて」というクエリに対してチャンク②がヒットしますが、AIは「何を検査しているのか（A製品の○○工程）」という文脈情報を持たないため、不完全な回答しか生成できません。
オーバーラップあり（After）の改善：60字のオーバーラップを設定することで、チャンク②の冒頭にチャンク①の末尾60字（「冷却後に検査工程へ移す。対象はA製品の○○工程」）が含まれます。AIが文脈を把握した状態で回答を組み立てられ、回答の完全性が向上します。
実装はLangchainの`RecursiveCharacterTextSplitter`やLlamaIndexの`SentenceSplitter`を使うのが一般的です。日本語対応の分割ロジック（MeCab系の分かち書き）を組み合わせるか、文字数ベースの分割器を使うかを事前に決めておきます。
設定後の確認方法は5～10件の代表クエリを用意し、期待するチャンクがトップ3位以内にヒットするかを確認することです。ヒット率が70%を下回る場合はチャンクサイズの見直しが必要です。LangchainではRetrieverの`search_kwargs={“k”: 3}`で上位3件を取得し、目視確認するのが手軽な検証方法です。
最初に決める設定③ ベクトルDB格納前の品質フィルタと選定基準
チャンク設計が整ったら、ベクトルDBへの格納前に行う「品質フィルタ」の設計が第3の設定です。不要なデータを事前に除外することで、ベクトルDB全体の検索精度と応答速度が改善します。
品質フィルタで除去すべき主要なパターンは4つです。
・ヘッダー・フッターの繰り返し文字列: 「会社名・部署名・機密区分・ページ番号」など各ページに同じ文字列が繰り返されるもの。正規表現でパターンマッチングして除去します。除去パターンは文書テンプレートを確認して一覧化してから実装します。
・極端に短いチャンク（30字以下）: 目次の1行や空白行の断片である可能性が高く、情報価値がほぼありません。格納時に文字数フィルタでスキップします。
・OCRノイズ: スキャンPDFをOCRで文字化した際の誤認識文字（「ー」が「一」に化ける等）。固有名詞や数値の誤認識は致命的なため、重要文書はOCR精度の事前確認が必要です。
・重複チャンク: 同じ文書が複数バージョン取り込まれると古いバージョンが回答に使われるリスクがあります。ドキュメントIDと更新日時の管理で重複格納を防ぐ仕組みが必要です。
メタデータはチャンクとセットで格納します。以下の4項目は最低限付与することを推奨します。
・source（出典ファイル名）: 回答の根拠文書をユーザーに提示するために必須です
・updated_at（更新日）: 古い情報を優先度下げるフィルタに使用します
・department（部門）: 「営業部の文書のみ検索」といった部門絞り込みに使用します
・doc_type（文書タイプ）: 「規程」「議事録」「仕様書」などの分類を格納します
ベクトルDBの選定は文書規模と既存インフラに応じて行います。
| 製品名 | 自社サーバー展開 | 適した文書規模 | 初期コスト | メタデータフィルタ |
|---|---|---|---|---|
| ChromaDB | ○（ローカルファイル） | 数千件まで | 低（OSSで無料） | △ 基本的なフィルタのみ |
| Qdrant | ○（Docker） | 数万件以上 | 中（Docker環境が必要） | ◎ 柔軟なフィルタ対応 |
| pgvector | ○（PostgreSQL拡張） | 中規模まで | 低（既存DB活用可） | ○ SQL条件と組合可 |
| Weaviate | ○（Docker） | 大規模向け | 高（設定が複雑） | ◎ GraphQL対応 |
中小企業が初めてRAGを構築する場合の推奨は「ChromaDB＋セクション単位または固定サイズ分割」からのスタートです。実運用で文書数が増え、検索速度や精度に課題が出てきた段階でQdrantへの移行を検討します。
品質フィルタは最初から完璧を目指す必要はありません。「短チャンクスキップ」と「ヘッダーフッター除去」の2つだけでも効果は大きいです。実際の検索結果を見ながら段階的に精度を高める姿勢が、限られたリソースで運用する情シス兼任担当者の現実的なアプローチです。フィルタの改善履歴は必ずドキュメントに残し、なぜそのパターンを追加したかの理由も記録しておきます。
よくある質問
Q1. RAG構築に必要な最低限の技術スキルはどのくらいですか？
PythonでCSVファイルを読み込んだ経験がある程度であれば、LangchainやLlamaIndexのサンプルコードをベースに最初のRAGを動かすことができます。LangchainのDocument Loadersを使えばPDFやWord文書の読み込みは10行程度のコードで完了します。本番運用に耐える前処理・品質フィルタの実装には正規表現の基礎知識と文書種類別の設計判断力が必要ですが、まず小さく動かすことを優先してください。完璧な前処理を作ってから本番投入するより、動くものを作って精度の問題を実データで確認するほうが、改善サイクルが速く回ります。
Q2. 社内文書を外部のAIサービスに送らずにRAGを構築できますか？
はい、可能です。社内専用AIのモデル（OllamaやvLLMで動かすオープンソースモデル）と自社サーバー上のベクトルDB（ChromaDB・Qdrant等）を組み合わせることで、文書データが社外に出ない完全ローカルのRAGを構築できます。守秘義務を負う士業事務所や個人情報を多く扱う企業では、この構成が推奨です。クラウドサービスのAPIを使う場合はエンベディング生成時にもデータが外部に送られるため、どの処理を社内で行いどこをクラウドに依頼するかを設計段階で明確にする必要があります。
Q3. チャンクサイズを後から変更すると全データを作り直しになりますか？
はい、チャンクサイズを変更した場合はベクトルDB上のデータを全件削除して再インデックス（再ベクトル化・再格納）が必要です。このため最初の設定が重要です。数千件程度の文書であれば再インデックスは数時間以内に完了することが多いです。本番環境に影響を出さないよう、開発・検証用の別コレクションで実験してから本番に反映する運用を推奨します。設定変更の際は変更前後の精度比較テスト（前述の代表クエリ20件以上のヒット率）を必ず実施します。
Q4. 検索精度を定量的に計測する方法はありますか？
代表的な指標としてRecall@K（上位K件のチャンク中に正解チャンクが含まれる割合）があります。具体的には20～30件の「質問＋期待する出典チャンク」のテストセットを作成し、RAGの検索結果と照合する評価スクリプトを用意します。月次でテストセットを実行することで、文書追加や設定変更の影響を定量的に追跡できます。最初はExcelで質問と期待する段落を管理し、Python側で照合するシンプルな構成から始めるのが現実的です。
Q5. PDF以外の文書形式でも同じ前処理が使えますか？
基本的な考え方（ノイズ除去・チャンク分割・メタデータ付与）はどの形式でも同じです。形式ごとの対応ライブラリはWord文書がpython-docx、ExcelがopenpyxlまたはLangchainのUnstructuredExcelLoader、テキストファイルがPython標準のファイル読み込みです。HTMLはBeautifulSoupでタグを除去してから処理します。スキャンPDFはpdf2imageとpytesseractでOCR処理を実施した後、通常のテキスト処理フローに乗せます。社内文書の多様な形式を一元的に処理するためには、形式別のローダーを統一インターフェースで管理するラッパーを作成しておくと運用が楽になります。
社内RAG構築前チェックリスト
以下の項目を確認してから構築を開始することで、後戻りを最小化できます。
・取り込む文書の棚卸し完了: どの文書をRAGに取り込むか、文書タイプ別にリスト化している
・文書タイプの分類決定: 各文書をマニュアル型・時系列型・構造型・Q&Aペア型のいずれかに分類した
・チャンクサイズの初期値設定: 文書タイプ別の初期チャンクサイズ（文字数）とオーバーラップ幅を数値で決定した
・ノイズパターンの洗い出し: 取り込む文書のヘッダー・フッターの定型文字列を一覧化した
・メタデータ項目の設計: 格納時に付与するメタデータ（出典・更新日・部門・文書タイプ）を決定した
・ベクトルDB選定完了: ChromaDB・Qdrant・pgvectorのいずれかを文書規模に応じて選定した
・評価テストセットの準備: 精度確認用の「質問＋期待する正解チャンク」を20件以上用意した
・再インデックス手順の確認: チャンクサイズ変更時に全件再格納できる手順を確認した
・文書の更新フロー設計: 文書が更新された際にベクトルDBも更新する仕組み（ファイル監視・定期バッチ等）を決定した
・情報の社外流出防止確認: ベクトルDB・AIモデルともに自社サーバー内で完結しており、外部への通信がないことを確認した
まとめ
社内RAGシステムの精度は、AIモデルの性能よりも「文書前処理とチャンク設計」の質で決まります。最初に固めるべき3つの設定を整理します。
・設定① 文書タイプ別チャンク戦略: マニュアル型・時系列型・構造型・Q&Aペア型の4分類で処理方針を決める
・設定② チャンクサイズとオーバーラップ幅: 日本語文書では200字～500字、オーバーラップは10%～20%を基本値とし文書タイプで微調整する
・設定③ ベクトルDB格納前の品質フィルタ: ヘッダー・フッター除去、短チャンクスキップ、メタデータ付与を最低限実施する
初めてRAGを構築する場合は「ChromaDB＋固定サイズ分割」から始め、20件のテストセットで精度を確認した後、段階的に設定を改善していく進め方が失敗の少ない方法です。
自社サーバー内AIを活用したRAG構築について、設計相談や実装支援をご希望の方はお気軽にお問い合わせください。
