RAG 03：文書の準備とチャンク分割 ― 資料を「探せる形」にする

形式ごとに、文字の取り出し方が違う

社内の資料は、いろいろな形式で置かれています。どれも人が読むぶんには同じ「資料」ですが、中身の作りはまったく違います。

特にスキャンした PDF は要注意です。画面では文字が見えるのに、取り出してみると空っぽ、ということがよくあります。OCR をかけて文字にしますが、読み間違いが混ざるので、その前提で扱います。

道具もたくさんあります。PDF から文字を抜き出す基本のライブラリのほかに、いろいろな形式をまとめて扱い、見出しや表を見分けようとする Unstructured や、IBM が公開した Docling のような道具があります。最近は、ページを画像として LLM に見せて、文字や表を読み取らせる方法も使われています。

どの道具も完璧ではありません。一番大事なのは、自分の資料で試して、取り出した文字を目で見ることです。

PDF の落とし穴：見た目の順番と、文字の順番は別物

PDF は、印刷したときの見た目を正確に再現するための形式です。中に入っているのは、基本的に「この座標に、この文字を描く」という命令の集まりです。「ここからここまでが1つの段落」「これは見出し」といった情報は、持っていないことがよくあります。

そのため、文字を取り出す道具は、座標を手がかりに「たぶんこの順番で読むのだろう」と推測して並べ直します。この推測が、いろいろな所で外れます。

図の例は2段組みです。人は左の段（第3条）を上から下まで読んでから、右の段（第4条）に移ります。でも、道具が「上から1行ずつ、左から右へ」と読むと、第3条の1行目と第4条の1行目が交互に混ざってしまいます。

こうして崩れた文字を切ってベクトル（文章の意味を表す数の並び。第4章）にすると、意味の混ざったチャンクができてしまいます。最近の道具は、ページの見た目（レイアウト）を分析して、段組みや見出しを見分けようとします。それでも、段組みの多い資料では、取り出した結果を必ず確かめてください。

表は、行と列がばらばらになる

PDF のもう1つの大きな落とし穴が、表です。

図の表は「勤続6か月なら10日、1年6か月なら11日、6年6か月以上なら20日」という対応を表しています。人は、行と列を目で追って読みます。でも、素朴な道具で文字を取り出すと、「勤続 付与日数 6か月 10日 1年6か月 11日 …」と、ただの1列の文字になってしまいます。

この程度の小さな表なら、LLM が推測で読み解けることもあります。でも、列が5つ6つある表や、セルが結合された表になると、どの数字がどの行・どの列のものか、まったく分からなくなります。そして、社内の資料で本当に聞かれることの多い「数字」は、たいてい表の中にあります。

対策は、表を表のまま取り出すことです。

最後の「見出し行を繰り返す」は大事です。表を途中で切ると、後半のチャンクには「勤続」「付与日数」という列の名前が無くなり、数字だけが残ります。表や画像の扱いは、第10章でも見ます。

掃除する：毎ページのヘッダー・フッター・ノイズを取る

文字を取り出したら、次は掃除です。

図のページの一番上には「社外秘 ― 就業規則 2026年版」、一番下には「- 3 -」というページ番号が入っています。これが100ページの資料なら、100回同じ文字が出てきます。

なぜ困るのでしょうか。ヘッダーの文がチャンクに混ざると、どのチャンクにも「就業規則」という同じ言葉が入ります。検索は、質問と言葉や意味の近いチャンクを探す仕組みです。ヘッダーが入っていると、「就業規則について」のような質問に、どのチャンクも同じように近く見えてしまい、本当に関係のあるチャンクが埋もれます。LLM に渡す量も、無駄に増えます。

ただし、消しすぎにも注意します。見出し、表の列名、「※注意」のような注記は、ノイズに見えても大事な情報です。見出しは、後で「どこの話か」を示す手がかりになります（この章の後半で使います）。

掃除のルールは、資料の種類ごとに少しずつ違います。まずは代表的な資料を数個選び、取り出した文字を見ながらルールを足していくのが現実的です。

メタデータ：チャンクに「札」を付ける

チャンクには、本文のほかに、そのチャンクについての情報を持たせておきます。これをメタデータと呼びます。図書館の本に貼ってある分類ラベルや、貸し出しカードのようなものです。

特に大事なのが最後の見てよい人（権限）です。人事部だけが見てよい資料が、全社員向けのチャットの答えに混ざったら大事故です。RAG は、資料庫にあるものは何でも探して LLM に読ませてしまいます。見せてはいけない資料は、LLM に渡す前に、検索の段階で除く必要があります。そのためには、元の資料が持っていた権限の情報を、読み込みの時点でチャンクに写しておかなければなりません。

メタデータは、読み込みの段で捨ててしまうと後から取り戻せません。最初は使わなくても、取れるものは取っておくのがおすすめです。メタデータで検索を絞り込む方法は第5章、権限の扱いは第13章で見ます。

チャンクが小さすぎると、文脈が消える

ここから、切り方の話に入ります。図の左は、第3条・第4条・第5条からなる文書です。その上に重なっている色の付いた枠が、チャンクです。これから、この枠が、切り方に合わせて伸び縮みしていきます。

まずは、小さく切りすぎた場合です。1文ずつ、あるいは数十文字ずつに切ると、図のように細かい枠がたくさんできます。

小さいチャンクの良い点は、当たったときにぴったりの所だけを渡せることです。LLM に渡す量も少なく済みます。

でも、困ったことが起きます。たとえば「10日を付与する。」というチャンクができたとします。これだけを見ても、何の10日なのか分かりません。有給休暇なのか、慶弔休暇なのか。いつ付与されるのか。その情報は、前の文や見出しにあったのに、切り離されてしまいました。

人にたとえると、本のページをはさみで1行ずつ切り刻んで、そのうちの1枚だけを渡されるようなものです。

大きすぎると、話題が混ざってぼやける

逆に、大きく切りすぎた場合です。図では、第3条と第4条がまとめて1つのチャンクになりました。

大きいチャンクの良い点は、文脈がよく残ることです。「10日を付与する」の前後もちゃんと入っているので、読めば意味が分かります。

でも、別の問題が出ます。

1つ目は、焦点がぼやけることです。検索のために、チャンクは1つずつ埋め込み（文章を、意味の地図の上の1点の座標にすること。第4章）に変えます。チャンク全体の意味が、1つの点にまとめられるのです。有給休暇と慶弔休暇と申請の方法が混ざったチャンクは、そのどれにも「そこそこ近い」、でもどれにも「ぴったり近い」わけではない、平均的な座標になってしまいます。すると、「慶弔休暇は何日？」という質問に対して、慶弔休暇だけを書いた別の資料のほうが近く見えて、こちらが拾われないことがあります。

2つ目は、渡す量が増えることです。質問に関係あるのは1文だけなのに、関係ない部分まで丸ごと LLM に渡すことになります。第1章で見たとおり、高く・遅く・見落としやすくなります。

どちらにも良い点と悪い点がある、トレードオフです。万能の正解はなく、資料と質問の性質によって変わります。よく使われる出発点は数百〜千トークン（第1章で見た、LLM が文章を数える単位）くらいですが、必ず自分の資料と質問で試して決めます（第12章）。「探すのは小さく、渡すのは大きく」という両取りの工夫（親子チャンク）は第10章で見ます。数字を変えて比べる方法は第12章です。

切れ目をまたぐ文のために、少し重ねて切る

決まった長さで切ると、どうしても文の途中で切れることがあります。「入社6か月後に」で1つ目のチャンクが終わり、「10日を付与する」が2つ目のチャンクに入る、といった具合です。こうなると、どちらのチャンクにも完全な答えが入っていません。

そこでよく使われるのが、隣り合うチャンクを少し重ねて切る方法です。図では、枠が少しずつずれながら重なっています。重なった部分の文は、両方のチャンクに入ります。すると、切れ目にかかった文も、どちらか一方には丸ごと残りやすくなります。

ただし、重ねるのは応急手当です。重ねても、「第3条の途中から第4条の途中まで」のような、話題の切れ目とずれたチャンクができる問題は解決しません。それを解決するには、切る場所そのものを賢く選ぶ必要があります。次のページで、切り方の型を見ます。

切り方の4つの型：長さ・区切り文字・見出し・意味

チャンクの切り方には、大きく4つの型があります。

再帰的な切り方は、たとえば LangChain の分割部品（RecursiveCharacterTextSplitter）が採用していて、よく使われます。「まず空行（段落の切れ目）で切ってみて、それでも長すぎる塊だけを、改行や句点で切り直す」という考え方です。文の途中で切れることが、固定長よりずっと少なくなります。

図は見出しで切った場合です。第3条・第4条・第5条が、それぞれ1つのチャンクになりました。枠が文書の構造にぴったり重なっています。規程やマニュアルのように、書き手がすでに意味の切れ目を見出しで示してくれている資料では、それを使うのが一番素直です。

ただし、1つの見出しの下がとても長い場合は、その中をさらに再帰的に切ります。逆に短すぎる節は、隣とまとめます。実際には「見出しで大きく切り、長すぎれば再帰的に切る」という組み合わせがよく使われます。

意味で切る：話題が変わる所を探す

見出しが無い文章、たとえば議事録やメールのやりとり、長い説明文では、どこで話題が変わるのかが、形からは分かりません。そこで、意味の近さを使って切れ目を探す方法があります。

やり方の考え方は、次のとおりです。まず文章を1文ずつに分けて、それぞれを埋め込み（意味を表す数の並び）にします。次に、隣り合う文どうしの近さを順番に測っていきます。同じ話題が続いている間は、近さは高いままです。話題が変わると、近さがガクッと下がります。図の右のグラフの、谷になっている所です。そこを切れ目にします。

図の左では、第3条が2つに分かれました。第3条の中に「付与日数」と「繰り越し」という2つの話題があり、その間で近さが下がった、というイメージです。

意味で切る方法は魅力的に聞こえますが、いつも一番良いとは限りません。「まず再帰的か見出しで切り、測ってみて足りなければ試す」くらいの順番がおすすめです。どの切り方が良いかは、自分の資料と質問で測って決めます（第12章）。

チャンクに「どこの話か」を書き足す

どんなにうまく切っても、切り出したチャンクは、元の文書の中にあったときの文脈を失います。「10日を付与する。」が第3条の有給休暇の話だということは、見出しや前の文を読まないと分かりません。

そこで、チャンクの先頭に「これはどこの、何についての部分か」を短く書き足してから、埋め込みや検索の索引を作る、という工夫があります。

いちばん簡単な形は、資料名と見出しの道のりを付けることです。「就業規則 ＞ 第3章 休暇 ＞ 第3条 有給休暇」を先頭に付けるだけで、「有給休暇」という言葉がチャンクに入ります。LLM を使わないので、費用もほとんどかかりません。メタデータ（見出しの道のり）を取っておいたことが、ここで生きます。

手間をかけた形として、Anthropic が 2024年9月に公開した Contextual Retrieval という方法があります。文書全体とチャンクを LLM に読ませて、「このチャンクは文書全体の中でどういう部分か」を説明する短い文（50〜100トークンほど）を書かせ、それをチャンクの先頭に付けてから、埋め込みと、キーワード検索（言葉の一致で点数を付ける昔ながらの検索。代表的な方式が BM25。第6章）の索引の両方を作ります。

同社の実験では、上位20件の中に正しいチャンクが入らない「検索の失敗」が、この方法（埋め込み＋BM25）で 49% 減り、さらにリランキング（拾った候補を別のモデルで読み直して並べ替えること。第7章）を組み合わせると 67% 減ったと報告されています。ただし、これは同社のデータでの結果です。また、全チャンクについて LLM を1回ずつ呼ぶので、準備の費用がかかります（同じ文書を何度も読ませる部分は、読んだ結果を使い回す「プロンプトのキャッシュ」（第1章）で安くできるとされています）。

ID を振る：出典を示し、改訂で差し替えるために

最後の仕事は、チャンクに ID（名札）を振ることです。第2章でも少し触れましたが、ID の付け方は、RAG を運用し始めてから効いてきます。

資料は変わります。就業規則は毎年のように改訂され、マニュアルは製品の更新に合わせて書き換えられます。改訂のたびに、資料庫の中身も入れ替えなければなりません。このとき、ID がでたらめ（毎回ランダム）だと、どのチャンクが古い版のものか分からず、古いチャンクが索引に残り続けます。すると、「有給は最大20日」という古い規程と「最大25日」という新しい規程が両方拾われ、LLM がどちらかを選んで答える、という事故が起きます。

おすすめは、資料と位置から決まる ID と、中身の指紋（ハッシュ） を持たせることです。ハッシュは、文章から計算して作る短い文字列です。同じ文章からは必ず同じ値が出て、1文字でも変わるとまったく違う値になります。

import { createHash } from "node:crypto";

function makeChunk(doc: string, section: string, n: number, text: string, source: string) {
  return {
    id: `${doc}#${section}-${n}`,                          // 例: shugyo-kisoku#3-1
    hash: createHash("sha256").update(text).digest("hex"), // 本文が変われば変わる
    doc, text, source,
  };
}

このコードは、ID を「資料名#条-連番」の形で組み立て、本文から SHA-256（よく使われるハッシュの計算方法）で指紋を計算して、本文・出典と一緒に1つのチャンクにまとめています。

改訂版を読み込んだら、図の右の手順で差し替えます。同じ ID のハッシュを比べ、変わったチャンクだけを埋め込み直します。変わっていないチャンクは、埋め込みの費用をかけずにそのまま使えます。新しい版で消えた ID は、索引からも消します。これを忘れると、廃止された規程がいつまでも答えに出てきます。

ID は出典の表示にも使います。答えに付いた番号から ID をたどり、元の資料名とページを見せる、という第2章の仕組みです。

よくある落とし穴と、ほかの章とのつながり

この章の内容で、実務でよく見かける落とし穴をまとめます。

最初の「目で見る」は、何度でも強調したい点です。RAG がうまく答えられないとき、原因を検索や LLM に求めがちですが、実際にはそもそもチャンクの文字が崩れていたということが少なくありません。

この章とつながる章は、次のとおりです。