RAGの前処理（分割・タグ・メタデータ）を最小工数で整える方法

RAGで「前処理」が重要な理由（失敗の8割はここ）

RAG（検索拡張生成）は「検索で見つけた根拠をもとに回答する」仕組みなので、元になる社内文書やFAQが「検索しやすい形」に整っていないと、生成AIの性能以前に回答が崩れます。よくある現象は、もっともらしいのに誤っている回答（ハルシネーション）、回答の根拠が薄い、部署ごとに言い方が違って混乱する、といったものです。

原因は、データの「前処理」が曖昧なまま、いきなりベクトル検索やLLM連携に進んでしまうこと。前処理とは大きく、(1)文書の分割（chunking）、(2)タグ付け、(3)メタデータ設計、(4)更新・運用のルール化です。ここが整うと、RAGの検索精度が上がるだけでなく、監査・説明責任（なぜその回答になったか）も担保しやすくなります。

特に情シスや経営層の方が導入でつまずきやすいのは、「どこまで整えれば十分か」が分からず、過剰に作り込みすぎてコストが膨らむ点です。本記事では、開発知識がなくても判断できるように、最小工数で成果が出やすい基準（どこまでやるか／やらないか）を、業務シーンの例とともに整理します。

なお、RAGの目的は「万能のAIを作る」ことではなく、社内の正しい情報に基づいて、問い合わせ対応・文書検索・ナレッジ共有を速くすることです。前処理はそのための土台であり、完璧を目指すより“事故が起きない最低ライン”を早く作るほうが費用対効果が高くなります。

最小工数で始めるための全体設計（やること・やらないこと）

最小工数の前処理は、次の方針で進めると破綻しません。ポイントは「最初に決めるべきことを、最小限だけ決める」ことです。

• 対象文書を絞る：全社文書を一気に取り込まない（まずは問い合わせが多い領域から）
• 正解の定義を置く：「一次情報（規程・手順書・製品仕様）」を優先し、雑談・古い議事録は後回し
• 分割・タグ・メタデータを“運用前提”で作る：一度作って終わりにしない
• 評価指標を先に置く：検索ヒット率、回答の根拠提示率、問い合わせ削減数など

やらないことも決めましょう。たとえば初期段階で、全文書の厳密な正規化、用語統一辞書の完備、部署横断の承認フローを完璧にするのは避けるのがおすすめです。“70点で回しながら改善”がRAGの現実解で、前処理も同じです。

この設計が効くのは、RAGの検索は「完璧な分類」より「検索に効く最小限の情報（メタデータ）と、読みやすい分割」が成果に直結するからです。例として、総務の社内規程をRAGで扱う場合、部署名・規程種別・施行日・改定履歴が分かれば十分なことが多く、全文書に対する複雑なタグ体系は不要です。

以降では、分割（chunking）・タグ・メタデータを、最小工数で品質を上げる具体策として説明します。

分割（chunking）設計：検索精度を決める「切り方」の最適解

RAGの前処理で一番効果が出やすいのが分割です。文書を適切な長さに切っておくと、検索で「欲しい段落」だけが当たりやすくなり、生成AIも根拠を引用しやすくなります。逆に、文書が長すぎるとノイズが増え、短すぎると文脈が欠けます。

最小工数でのおすすめは、「見出し単位＋上限文字数」のハイブリッドです。たとえば、手順書なら「目的」「手順」「例外」「問い合わせ先」などの見出しごとに区切り、長い見出しはさらに一定の文字数（例：800〜1,200文字程度）で分割します。これなら人手での調整が少なく、構造も保てます。

実務でよくある文書タイプ別の目安は次の通りです。

• 規程・ポリシー：条項（第◯条）単位で分割。定義や例外は同じチャンクに入れる
• 手順書・マニュアル：「1作業＝1チャンク」を意識。注意事項と前提条件は手順とセット
• FAQ：Q＋Aを1チャンクに。Aが長い場合は「結論→理由→手順」に分ける
• 議事録：原則後回し。入れるなら「決定事項」「ToDo」「背景」だけ抽出して分割

分割で失敗しやすいのが、表や箇条書きの扱いです。表が途中で切れると意味が壊れます。可能なら「表全体を1チャンク」にする、難しければ表をテキスト化して行単位ではなく「項目セット」でまとめます。“意味が壊れない単位”が最優先です。

また、チャンク同士のつながりを保つために、オーバーラップ（前後の文章を少し重ねる）を使う手もあります。ただし最小工数の段階では、まず見出し単位の分割で十分なことが多いです。オーバーラップは検索結果の重複を増やすため、導入後に「文脈が足りない」症状が出てから追加するのが安全です。

技術的には、PDF/Word/HTMLなど入力形式に応じて抽出品質が変わります。PDFは見出しや改行が崩れやすいため、最初は「Webの社内ポータル（HTML）」や「整形されたWord」など、構造が取りやすいソースから始めると前処理コストを下げられます。

タグ付け：分類ではなく「検索のヒント」を付ける発想

タグ付けというと、部署・業務・製品・顧客などを細かく分類したくなりますが、RAGの前処理でのタグは「人間の分類学」よりも、検索時の絞り込みに効く「ヒント」に寄せたほうが成果が出ます。タグは少なく、意味がぶれないものに限定するのが最小工数のコツです。

おすすめのタグは、次の3系統です。

• 領域タグ（どの業務か）：例）経費精算、入退社、セキュリティ、購買
• 文書タイプタグ（何の文書か）：例）規程、手順書、FAQ、テンプレ
• 対象者タグ（誰向けか）：例）全社員、管理職、情シス、営業

これだけでも、RAGで「経費精算の手順だけ」「管理職向けの規程だけ」といったフィルタができ、検索の精度が安定します。逆に、タグが増えすぎると運用で更新されず、古いタグが残って逆効果になります。とくに「製品名」「プロジェクト名」「部門内の通称」のように変わりやすいものは、最初からタグにしないほうが無難です。

タグの付け方は、全件手作業にすると破綻します。最小工数なら、(1)フォルダ構造やURLから自動付与、(2)ファイル名の規則から推定、(3)本文のキーワードから軽く自動付与、の順で十分です。例えば「/security/policy/」配下の文書は領域=セキュリティ、タイプ=規程、と機械的に決められます。

どうしても迷う場合は、「将来の質問」を想像してください。ユーザーは自然文で「在宅勤務の申請方法」「パスワードの有効期限」などと聞きます。タグは、その質問に対して検索結果を絞るのに役立つかで判断します。タグは“説明のため”ではなく“検索のため”です。

最後に、タグのガバナンスとして「タグ辞書（許可されたタグ一覧）」を作ると運用が安定します。Excelでも十分で、タグ名・説明・例・廃止タグの扱い（置き換え先）を1枚にまとめるだけで、属人化をかなり防げます。

メタデータ設計：最低限これだけあれば運用が回る

メタデータは、RAGの検索・ランキング・フィルタ・監査に効く「台帳」です。最小工数で整えるなら、まず「必須メタデータ」を決め、入力できない項目は無理に作らないのがコツです。メタデータは“増やす”より“欠けない”が重要です。

まず押さえたい必須メタデータの例を挙げます（多くの企業で汎用的に使えます）。

• source：出典（URL、ファイルパス、SharePointリンクなど）
• title：文書タイトル（ファイル名より人が読める形が望ましい）
• doc_type：文書タイプ（規程/手順書/FAQ…）
• owner：管理部署（総務、人事、情シスなど）
• effective_date：施行日・最終改定日（いつの情報か）
• access_level：公開範囲（全社員/一部/機密）
• chunk_id：分割後の識別子（再取り込みや差分更新に必須）

この中でも特に効くのが「effective_date」と「access_level」です。RAGは古い情報も平等に検索してしまうため、改定された規程があると事故になりやすいです。改定日が入っていれば「新しいほうを優先する」ランキングが組めます。またアクセスレベルは、権限のないユーザーに機密情報が混ざる事故を防ぎます。

メタデータを入れる場所は、(1)文書管理システムの属性、(2)ファイルのプロパティ、(3)取り込み時に付与する外部DB（ベクトルDBのメタデータ）、のいずれかになります。現場で最小工数にするなら、すでに運用されている文書管理の属性（SharePointの列など）を優先し、足りない分だけ取り込み時に補完するのが現実的です。

「どう入力するか」も重要です。全部手入力は続きません。例えばownerはフォルダで推定、doc_typeはテンプレやファイル名規則で推定、effective_dateは本文の「改定：YYYY/MM/DD」表記を抽出、など半自動化が可能です。人が入力するのは“判断が必要な項目だけ”に寄せましょう。

最後に、メタデータの品質チェックとして、最低限のバリデーション（空欄禁止、日付形式、許可値）を入れると、後工程のトラブルが激減します。これは高度な開発がなくても、取り込みスクリプトやETLの段階で実装できます。

最小工数の実装手順：小さく作って、評価して、増やす

ここまでの分割・タグ・メタデータを、実際に導入する際の流れを「最小工数」に寄せてまとめます。重要なのは、最初から全社対応にしないことと、評価できる形で始めることです。

1. 対象ユースケースを1つに絞る：例）総務への問い合わせ（経費精算・勤怠・入退社）
2. 一次情報だけ集める：規程、手順書、公式FAQ、テンプレの最新版
3. 取り込み前に“NG文書”を外す：古い版、下書き、個人メモ、機密の塊
4. 分割ルールを決めて自動分割：見出し単位＋上限文字数（意味が壊れない）
5. タグは3系統に限定：領域・文書タイプ・対象者
6. 必須メタデータを付与：source/title/doc_type/owner/effective_date/access_level
7. テスト質問を20〜50個作る：実際の問い合わせログから作ると強い
8. 評価→改善を2週間で1サイクル：外れた質問を分析して分割やメタデータを直す

評価の観点は、LLMの賢さより「検索が当たっているか」です。具体的には、(1)関連するチャンクが上位に出るか、(2)根拠が提示できるか、(3)改定前の情報を引いていないか、(4)権限外の情報を混ぜていないか、を見ます。RAGは“検索の品質が8割”なので、前処理の改善がそのまま成果に直結します。

ありがちなつまずきとして、「PDFしかない」「文書が散らばっている」「最新版が分からない」があります。この場合は、全てを直すのではなく、まずは対象ユースケースに必要な文書だけ「最新版フォルダ」を作り、そこから取り込むのが最小工数です。情報整理プロジェクトを全社で始めると長期化しやすいので、RAGの導入範囲に合わせて局所的に整えるのが現実的です。

運用面では、更新フローを簡単に決めておくと後で困りません。例えば「規程や手順書が改定されたら、そのフォルダに入れる（古い版はアーカイブに移す）」「週1で自動再取り込み」「改定日が取れない文書は取り込まない」など、最低限のルールで十分回ります。

まとめ

RAGをうまく動かすための前処理（分割・タグ・メタデータ）は、開発知識がなくても「最小工数で効くポイント」を押さえれば成果が出ます。結論としては、完璧な分類や全社の文書整理より、検索に効く土台を小さく作って回すことが重要です。

• 分割は「見出し単位＋上限文字数」で、意味が壊れない切り方を優先する
• タグは増やしすぎず、「領域・文書タイプ・対象者」の3系統から始める
• メタデータは「出典・管理部署・改定日・公開範囲」を中心に、欠けない設計にする
• ユースケースを1つに絞り、テスト質問で評価→改善を短いサイクルで回す

「どの文書から始めるべきか」「自社の文書がPDF中心でうまく抽出できない」「権限管理込みでRAGを作りたい」といった状況でも、前処理設計を先に固めることで、導入後の手戻りを大幅に減らせます。自社の状況に合わせた最適な分割・タグ・メタデータ設計を一緒に作るところから進めたい場合は、ぜひご相談ください。