レッスン2：文書パイプライン——社内文書の類型・前処理・メタデータ設計・更新戦略

このレッスンで学ぶこと

社内文書を 6 類型（Wiki／ファイルサーバー／メール／チャット／DB／画像）で捉え、扱い方の違いを整理できる
PDF・HTML・Office・OCR の抽出パイプラインで押さえるべき要点がわかる
日本語トークナイズ（Sudachi・MeCab）と辞書設計の勘所を把握する
レイアウト解析（見出し・表・図・目次）で失う情報と拾える情報を区別できる
メタデータ設計（部署・期間・種別・権限タグ・改訂履歴）の必要要素を組み立てられる
更新戦略（差分検出・削除文書の反映・再インデックスのタイミング）を設計できる
SharePoint・Confluence・Notion・Google Drive の連携パターンの選択肢を持てる

前レッスンでは RAG の 4 段階アーキテクチャ（データ→索引→検索→生成）と、本コースを貫く 6 個の中核メッセージを提示しました。本レッスンからは、その 4 段階の 1 段階目「データ」に踏み込みます。RAG の 8 割は LLM の外側で決まる——文書と検索が勝敗を分ける、が本コース最初の柱です。文書パイプラインは、その「勝敗を分ける外側」の最初の関門です。

社内文書の 6 類型

社内文書は、単一のリポジトリに整理されていることはほとんどありません。実務では次の 6 類型に散らばっているのが普通です。RAG の設計は、まず「どこに何があるか」を棚卸しするところから始まります。

flowchart TB
  Docs[社内文書]
  Docs --> W[Wiki 系<br/>Confluence<br/>Notion<br/>Backlog Wiki]
  Docs --> F[ファイルサーバー<br/>SharePoint<br/>Google Drive<br/>Box<br/>NAS]
  Docs --> M[メール・議事録<br/>Outlook<br/>Gmail<br/>電子メール保管]
  Docs --> C[チャット<br/>Slack<br/>Teams<br/>LINE WORKS]
  Docs --> D[データベース<br/>CRM<br/>ERP<br/>問い合わせ管理]
  Docs --> I[画像・スキャン<br/>紙帳票の PDF<br/>設計図・写真]

Wiki 系（Confluence・Notion・Backlog Wiki など）

構造が整っていて、部門ページや権限管理も比較的しっかりしています。API も提供されているため、RAG のデータソースとしては相対的に扱いやすい類型です。ただし、Wiki は「書かれた時点で正確でも、放置されて古くなる」という宿命があります。改訂日時・最終編集者・最終レビュー日をメタデータに含めることが必須です。

ファイルサーバー（SharePoint・Google Drive・Box・NAS など）

Word・Excel・PowerPoint・PDF が中心で、社内で最もボリュームが大きい類型です。フォルダ階層が権限と結びついていることが多く、「フォルダ名＝部門名」となっていれば、それ自体を部門メタデータとして使えます。命名規則がバラバラな組織では、フォルダ階層からメタデータを自動抽出する仕掛けが役に立ちます。

メール・議事録

RAG のソースに含めるかどうかで、悩ましい類型です。「議事録は情報が濃いが、雑談も混ざる」「メールは経緯を知る手がかりだが、公開範囲の判定が難しい」といった性質があります。多くの組織では、メール本体は RAG ソースに含めず、議事録として整理されたものだけを含めるのが現実的な落としどころです。

チャット（Slack・Teams・LINE WORKS）

流量が多く、公開範囲がチャンネル単位に細かく区切られます。全社チャンネルの一部だけを RAG ソースに含める、といった選定が実務的です。永続的な意思決定文書というより「補助情報」として位置づけます。

データベース（CRM・ERP・問い合わせ管理）

構造化データが中心で、そのままではベクトル検索の対象になりません。「レコードを自然文の記述に変換する」処理（テンプレート化）を挟むことで、RAG のソースにできます。とはいえ、構造化データに対する質問は SQL や BI ツールの方が向いていることも多く、RAG に無理に統合しない判断も選択肢です。

画像・スキャン（紙帳票の PDF・設計図・写真）

紙をスキャンした PDF や、写真・設計図・帳票の類は、OCR が必要です。日本語 OCR は、Adobe Acrobat・Google Document AI・Azure Document Intelligence・Amazon Textract・PaddleOCR・Tesseract など、選択肢があります。精度と料金体系は 2026 年 7 月時点でも差が大きいため、対象文書のサンプルで精度検証してから選定します。

💡 ポイント 全類型を最初から RAG に含めようとすると、パイプラインが破綻します。最初のパイロットでは Wiki 系＋ファイルサーバーの中で更新頻度の高いものに絞るのが定石です。メール・チャット・DB・画像は、パイロットで手応えを掴んだあとに段階的に追加します。

前処理パイプライン——PDF・HTML・Office・OCR

文書の抽出は、形式ごとにライブラリと勘所が違います。

flowchart LR
  S[ソース<br/>PDF/DOCX/PPTX/HTML/画像] --> Ex[抽出<br/>PyPDF・pdfplumber<br/>python-docx<br/>BeautifulSoup<br/>OCR]
  Ex --> Cl[クリーニング<br/>ノイズ除去<br/>正規化]
  Cl --> To[トークナイズ<br/>Sudachi・MeCab]
  To --> La[レイアウト解析<br/>見出し・表・図・目次]
  La --> Me[メタデータ付与]

PDF

PDF は、文字情報を持つ「テキスト PDF」と、画像を貼っただけの「イメージ PDF」があります。前者は PyPDF・pdfplumber・PDFMiner・pdf.js・PyMuPDF（fitz）などで文字を抽出できますが、段組・表・脚注が絡むと抽出品質が乱れがちです。特に日本語 PDF は、縦書き・振り仮名・段組の混在に注意が必要です。イメージ PDF は前段で OCR が必要になります。

HTML

社内ポータルや Wiki の HTML は、BeautifulSoup（Python）・Cheerio（Node.js）・jsoup（Java）などでパースします。ナビゲーション・フッター・広告のような「本文でない要素」を除去することが品質を大きく左右します。Readability 系のライブラリ（trafilatura、newspaper3k、Readability.js など）が、本文抽出に役立ちます。

Office（Word・Excel・PowerPoint）

Word（.docx）は python-docx や docx2txt、PowerPoint（.pptx）は python-pptx、Excel（.xlsx）は openpyxl や pandas で抽出できます。Excel の場合、セル単位の文字列だけでなく「表としての意味」を保つために、シート名や列見出しをメタデータに残す工夫が必要です。図・チャートは通常テキスト化されないため、必要なら OCR や画像記述モデルを組み合わせます。

OCR

紙をスキャンした PDF や画像文書は、OCR で文字を起こします。2026 年 7 月時点では、Google Document AI・Azure Document Intelligence・Amazon Textract のようなクラウド系の日本語対応が向上し、レイアウト保持と表構造の認識まで含めた「Document Understanding」機能が実用段階です。ローカルでは PaddleOCR・Tesseract が定番です。OCR は誤認識が避けられないため、抽出後に「怪しい文字列」を検出して人の目でチェックする仕組みが必要です。

⚠️ 注意 抽出パイプラインは「一度作れば終わり」ではありません。PDF のフォーマットが変わる、Word テンプレートが更新される、といった変化で抽出結果が壊れます。抽出品質の指標（抽出成功率・文字化け率・ノイズ混入率）を定期的にモニタリングし、劣化を検知できる仕組みを備えてください。

日本語トークナイズ——Sudachi・MeCab の選び方

英語と違い、日本語は語と語の間に空白がありません。「東京駅」を「東京」「駅」と分割するか「東京駅」の 1 語のままにするかで、検索の挙動が変わります。日本語 RAG では、トークナイザーの選定と辞書設計が検索精度に直結します。

MeCab：京都大学発の形態素解析器。IPA 辞書・Neologd 辞書・UniDic 辞書などを切り替えて使う。長い歴史があり、資料も豊富
Sudachi：Works Applications が開発、Apache 2.0 で公開。「A モード（短単位）・B モード（中単位）・C モード（長単位）」の 3 段階分割ができるのが特徴で、社内 RAG では B モードや C モードを軸に、キーワード検索側で C モードを併用するといった使い分けが可能
Janome：Python で MeCab 相当の解析が可能な純 Python 実装。導入が軽い
fugashi：Python の MeCab バインディング。UniDic 辞書と組み合わせて使うのが定番

固有名詞・製品名・社内略語は、辞書に登録しないと分割されすぎる、あるいは繋がりすぎる、といった問題が起きます。社内 RAG では、社内用語辞書を段階的に育てることが、検索精度の底上げに直接効きます。

レイアウト解析——見出し・表・図・目次

文書の「意味」は、文字だけでなくレイアウトにも埋め込まれています。「これは章タイトル」「これは表の行」「これはコード」といった構造情報を落とすと、後段のチャンキング・検索・引用が難しくなります。

見出し階層：h1・h2・h3 のようにマークダウン風に保存すると、後段のチャンキングで見出し単位に分けられる
表：行・列を保持したまま Markdown 表や JSON にする。単純にテキスト化すると、行と列の関係が失われる
図・キャプション：図の周辺のキャプションは重要。図そのものは画像記述モデルで説明文を作るか、周辺テキストで代替する
目次：短い応答時に「該当章を示す」ことに使える。ただし目次そのものをチャンクに含めると、目次だけがヒットする現象が起きるため、通常はチャンク対象から除外する

メタデータ設計——RAG の権限・品質・改訂管理の土台

チャンクに紐づけるメタデータは、後段の権限伝播・鮮度判定・出典表示・失敗分析すべての土台になります。最初のスキーマ設計を怠ると、後から足しても十分に機能しません。これが中核メッセージ「権限伝播とガバナンスは後から足せない」の実務的な意味です。

主要なメタデータの例です。

メタデータ	用途	例
部署	部門別絞り込み・権限	情シス／人事／営業
権限タグ	閲覧範囲の伝播	一般公開／社員のみ／管理職以上／特定チームのみ
文書種別	質問の種類との対応	規程／マニュアル／議事録／FAQ／製品仕様
有効期間	鮮度判定	有効／執行中／失効
作成日・改訂日	鮮度判定・優先順位	ISO 8601 形式
作成者・改訂者	追跡・問い合わせ先	部署名まで含む
ソース種別	抽出パイプラインの特定	Confluence／SharePoint／Notion
元 URL・元パス	出典表示の根拠	完全 URL
言語	多言語対応	ja／en／zh
改訂履歴の有無	版管理	版数・前版 ID
チャンク ID・親文書 ID	検索から親文書へのリンク	UUID

📖 もっと詳しく メタデータのスキーマは「増やす」よりも「絞る」のが難しい設計です。初期にすべての候補を洗い出し、絶対に外せないものだけをスキーマに残す判断が有効です。使われないメタデータは、更新パイプラインの負担だけを増やし、検索精度には効きません。運用開始後に、実際に使われるメタデータをログから逆算して、スキーマを段階的に整理していきます。

更新戦略——差分検出・削除文書・再インデックスのタイミング

社内文書は日々更新されます。「毎晩全件を再インデックス」は最も単純ですが、規模が大きい組織では現実的ではありません。

差分検出：文書ソースの updated_at やハッシュ値を比較し、変わったものだけを再処理する。SharePoint や Confluence の API は差分取得に対応しているものが多い
削除文書の反映：削除された文書のチャンクを、ベクトル DB から確実に取り除く。忘れると「もう社内にない情報が回答される」事故につながる。ソース側の「削除リスト」を積極的に取りに行く運用が必要
改訂履歴の扱い：旧版は残すか、消すか。規程系文書では「発効中の版のみをインデックスし、旧版はメタデータに版数だけ残す」のが典型的な設計
再インデックスのタイミング：更新頻度の低い文書（規程・マニュアル）は日次バッチで十分、更新頻度の高い文書（Wiki・議事録）は数時間おき、といった具合に文書種別ごとに周期を分ける
モデル更新に伴う再埋め込み：埋め込みモデルを別のものに切り替える場合、全チャンクの再埋め込みが必要になる。この費用は事前に見積もっておく（詳細はレッスン 8）

SharePoint・Confluence・Notion・Google Drive の連携パターン

主要な社内ドキュメント SaaS には、それぞれ API とコネクタの選択肢があります。2026 年 7 月時点の代表的なパターンです。

SharePoint（Microsoft 365）：Microsoft Graph API 経由でファイル一覧・本文・権限情報を取得。差分同期には Delta クエリ、権限伝播には「サイト権限＋ファイル固有権限」の 2 階層を辿る
Confluence（Atlassian）：REST API または CQL（Confluence Query Language）でページ・添付ファイル・スペース権限を取得。スペース単位・ページ単位で権限が階層化される
Notion：Notion API v1 でページ・データベースを取得。ブロックベースの構造で、階層を辿ってテキスト化する必要がある
Google Drive：Google Drive API v3。ファイルの permissions を取得することで、共有相手ごとの権限を把握できる

これらの API はすべて、認証（OAuth 2.0 が主流）、権限反映（ソース側の権限を検索時のフィルタに使う）、スロットリング対応が必要です。既製のコネクタ（LangChain の DocumentLoader、LlamaIndex の Reader、あるいは Elastic の Enterprise Search コネクタ、Azure AI Search のインデクサ、Amazon Bedrock Knowledge Bases のデータソースなど）を活用すると、実装の入り口を短くできます。

🔰 初学者の方へ どのソースから最初に着手するかは、「更新頻度」「重要度」「権限管理の複雑さ」の 3 軸で決めます。更新頻度が高く、重要で、権限管理が明快なもの（社内 Wiki の全社公開スペースなど）から着手するのが定石です。権限管理が複雑なもの（部門・案件ごとに細かく区切られた SharePoint フォルダ）は、後段のレッスン 7 でガバナンスを設計してから着手します。

中核メッセージの再確認

本レッスンで押さえた要点を、中核メッセージに戻して整理します。

RAG の 8 割は LLM の外側で決まる——文書の類型と抽出品質、メタデータ設計は、RAG の勝敗を分ける「外側」の代表格
モデルは 3 か月・フレームワークは 1 年・社内文書は 10 年で動く——文書側の資産は、モデルより長く残る。文書側の設計に投資することは、10 年単位で価値を出す
権限伝播とガバナンスは後から足せない——メタデータの権限タグを最初のスキーマに含めていないと、あとから権限モデルを載せることは事実上不可能

まとめ

社内文書は 6 類型（Wiki／ファイルサーバー／メール／チャット／DB／画像）に散らばる。最初は Wiki＋ファイルサーバーから始めるのが定石
PDF・HTML・Office・OCR の抽出には、形式ごとの定番ライブラリと勘所がある。抽出品質はモニタリングし続ける
日本語トークナイズ（Sudachi・MeCab など）は検索精度に直結する。社内用語辞書を育てる文化が効く
レイアウト解析で見出し・表・図・目次を保持することで、後段のチャンキングと引用が正確になる
メタデータ設計は権限・鮮度・出典・失敗分析の土台。「初期に絞って設計する」のが有効
更新戦略は差分検出・削除文書の反映・再インデックス周期の 3 点で設計する
SharePoint・Confluence・Notion・Google Drive はそれぞれ API が公開されており、既製コネクタ活用が現実的

次のレッスンでは、文書を意味のある単位に「切り分ける」チャンキング戦略と、切り分けたチャンクを数値ベクトルに変換する埋め込みモデルの選定を扱います。

確認クイズ

このレッスンの内容の理解度をチェックしましょう。