RAGのチャンク分割で最も大切なのは、「何文字で区切るか」よりも「文書のどこで区切るか」です。文書を一定の文字数で機械的に区切る方法は手軽ですが、文の途中、表の途中、条件と結論の間で切れてしまい、検索で正しい箇所が見つからない、見つかっても必要な情報が欠けている、といった失敗の原因になります。規程なら条、マニュアルなら手順のまとまり、FAQなら一問一答、議事録なら議題、というように、文書の性質に沿った単位で区切り、各チャンクに文書名や見出し、更新日などの情報を持たせると、検索と回答の精度が大きく変わります。
さらに、どの分け方が最適かは、文書の種類だけでなく、どんな質問が来るかによっても変わります。そのため、分け方は机上で決め切るのではなく、評価用の質問を使って比べながら決めるのが確実です。
この記事は、RAGを構築している、あるいは精度の改善に取り組んでいる開発担当者に向けて書いています。チャンク分割の基本的な考え方、メタデータの持たせ方、規程・マニュアル・FAQ・議事録・表を含む資料・メールやチャットのログといった文書の種類別の分け方、分け方を決める手順、よくある失敗までを順に説明します。
チャンク分割が精度を左右する理由
RAGでは、文書をあらかじめ小さな断片(チャンク)に分けて保存し、質問に近いチャンクを検索で探して生成AIに渡します。用語の解説はチャンク(チャンク分割)の用語ページにまとめています。チャンクの作り方は、次の二つの場面で精度に影響します。
一つ目は検索の場面です。チャンクは検索の単位なので、一つのチャンクに複数の話題が混ざっていると、どの話題の質問とも中途半端にしか似ていない状態になり、検索で上位に来にくくなります。逆に、細かく分けすぎると、一つのチャンクに含まれる情報が少なすぎて、質問との関係が判断しにくくなります。
二つ目は回答の場面です。検索で取れたチャンクの中に、答えに必要な情報がそろっていなければ、生成AIは正しく答えられません。例えば、「ただし、試用期間中の者を除く」という条件が別のチャンクに分かれていると、AIは条件を知らないまま答えてしまいます。
つまり、チャンクは「検索で見つかりやすく」「それ単体で意味が通じる」大きさと区切りであることが理想です。この二つはときに相反するため、文書の性質に応じて調整する必要があります。
分割の基本的な考え方
文書の種類にかかわらず共通する、分割の基本を整理しておきます。
構造に沿って区切る
見出し、条、項目、段落など、文書が元から持っている構造を区切りの基準にします。書き手が意味のまとまりとして区切った場所で分ければ、チャンクの中身も意味のまとまりになります。そのため、分割の前にテキストを取り出す段階で、見出しや箇条書きの構造を失わないことが前提になります。
大きさの上限と下限を決める
構造に沿って区切っても、一つの見出しの下が非常に長い場合や、極端に短い場合があります。長すぎるものは段落の切れ目でさらに分け、短すぎるものは前後のまとまりとつなげます。上限は、検索で使う埋め込みモデルが扱える長さや、生成AIに渡せる量(コンテキストウィンドウ)も踏まえて決めます。
重なりを持たせる
長い文書を分けるとき、隣り合うチャンクの境目の文を両方に含める「重なり」を持たせると、境目で情報が途切れる問題を和らげられます。ただし、重なりを大きくするとチャンクの数と保存量が増え、似た内容のチャンクが検索結果に並ぶこともあります。構造に沿って区切れる文書では、重なりは小さくてかまいません。
文脈を付け足す
チャンクの先頭に、文書名と見出しの階層を付け足します。例えば「就業規則 > 第5章 休暇 > 第32条 慶弔休暇」のように付けておけば、本文に「慶弔休暇」という語が出てこない段落でも、何についての記述かが分かります。これは検索にも回答にも効く、手間の割に効果の大きい工夫です。
メタデータの持たせ方
チャンクには、本文とは別に、検索の絞り込みや回答の出典表示に使う情報(メタデータ)を持たせます。どの文書にも共通して持たせたい項目は次のとおりです。
- 文書名、文書の種類(規程、マニュアル、FAQ、議事録など)
- 見出しの階層、条番号やページ番号などの位置情報
- 原文への参照先
- 作成日、更新日、施行日、版
- 担当部署、作成者
- 公開範囲(全社員、特定部署、役職者のみなど)
- 対象の範囲(製品名、拠点、雇用形態など)
更新日や版は、古い内容の混入を防ぐために使います。公開範囲は、質問者が見られない文書を検索対象から外すために使います。対象の範囲は、質問者の所属や質問の対象に合わせて検索を絞り込むために使います。メタデータは後から付け足すと手間がかかるため、分割の設計と同時に決めておきます。
文書の種類別の分け方
ここからは、社内でよく扱われる文書の種類ごとに、分け方の考え方を説明します。まず全体を表にまとめます。
| 文書の種類 | 分割の単位 | 付け足す文脈 | 特に持たせたいメタデータ |
|---|---|---|---|
| 規程・規則 | 条(長い条は項) | 規程名、章、条の見出し | 施行日、版、対象者の範囲 |
| マニュアル・手順書 | 一つの作業の手順のまとまり | マニュアル名、章、作業名 | 対象の製品・システム、版 |
| FAQ | 一問一答 | カテゴリ | 対象の範囲、最終確認日 |
| 議事録 | 議題 | 会議名、開催日、議題名 | 開催日、参加部署、決定か検討中か |
| 表を含む資料・仕様書 | 表の行または意味のある行のまとまり | 表のタイトル、列名 | 型番、版 |
| メール・チャットのログ | スレッドややり取りのまとまり | 件名、日付 | 日付、関係する案件 |
規程・規則
規程は条が意味の単位になっているため、条ごとに分けるのが基本です。一つの条が長く、複数の項で構成されている場合は項ごとに分けますが、その際には条の見出しと本文の冒頭(原則を述べた部分)を各項のチャンクに付け足すと、項だけを読んでも文脈が分かります。
規程で特に注意すべきは、ただし書きと別表です。「ただし」以降の例外が別のチャンクに分かれると、例外を無視した回答が出ます。ただし書きは同じチャンクに含めるようにします。また、金額や日数が別表にまとめられている規程では、本文の条と別表の該当行を結び付けておく必要があります。別表を独立したチャンクにする場合は、どの条から参照されているかを付け足しておきます。
改定が多い規程では、施行日と版をメタデータに持たせ、検索時に現行の版だけを対象にします。改定の移行期間には、新旧の両方を区別して答えられるようにしておくと親切です。規程を使った社内問い合わせの仕組みづくりは、社内ヘルプデスクをAIチャットボット化する:規程Q&Aの作り方で詳しく扱っています。
マニュアル・手順書
マニュアルや手順書は、「一つの作業を完了するまでの手順」をまとまりとして分けます。手順を一つずつ別のチャンクにすると、途中の手順だけが検索で取れ、前後が欠けた回答になります。逆に、一つの章全体を一つのチャンクにすると、複数の作業が混ざります。
手順の前に書かれている「準備」「注意事項」「前提条件」は、手順と同じチャンクに含めるか、手順のチャンクに要約を付け足します。注意事項が別のチャンクになっていると、安全に関わる注意が回答から抜けることがあります。また、マニュアルは画面の画像や図を多く含みますが、画像の中の文字や図の内容はそのままでは検索できません。重要な図は、内容を文章で補っておきます。
製品やシステムの版によって手順が違う場合は、対象の版をメタデータに持たせ、質問者が使っている版で絞り込めるようにします。
FAQ
FAQは一問一答が自然な単位です。質問と回答を必ず同じチャンクに入れます。回答だけのチャンクにすると、何についての回答かが分からなくなり、検索でも見つかりにくくなります。
FAQで工夫したいのは、質問の言い換えを付け足すことです。FAQの質問文は作り手の言葉で書かれていることが多く、利用者の言い方とずれていることがあります。「退会したい」「解約方法」「やめるには」のような言い換えをチャンクに含めておくと、検索で見つかりやすくなります。また、回答が長く、条件によって内容が分かれるFAQは、条件ごとに別の項目に分けた方が、検索でも回答でも扱いやすくなります。
議事録
議事録は、一回の会議の中に複数の議題が含まれることが多いため、議題ごとに分けるのが基本です。各チャンクには、会議名、開催日、議題名を付け足します。開催日がないと、同じ議題が何度も議論されている場合に、どれが最新の結論か分からなくなります。
議事録で特に注意したいのは、「決定したこと」と「検討中の意見」が混ざっていることです。議事録を根拠に回答するとき、ある参加者の意見を決定事項のように答えてしまうと、誤った案内になります。議題ごとに「決定事項」「検討事項」「宿題」を区別して記録する書式に変える、あるいはチャンクにその区別をメタデータとして持たせる、といった工夫が有効です。
表を含む資料・仕様書
料金表、製品の仕様一覧、対応表など、表が中心の資料は、表の構造を保ったまま分けることが最も重要です。行ごとにチャンクにする場合は、各行に列名を付け足して「型番:A-100、最大出力:…、対応電圧:…」のような形にすると、行単体でも意味が通じます。表のタイトルや、表の前に書かれた前提条件(「価格は税別」「○年○月時点」など)も付け足します。
小さな表であれば、表全体を一つのチャンクにした方が扱いやすいこともあります。行同士の比較が必要な質問(「最も軽いモデルはどれか」など)が想定される場合は、表全体を一つのチャンクとして持つ方が答えやすくなります。PDFから表を取り出すときの崩れを防ぐ方法は、PDFや表を含む社内資料をRAGで扱うときの前処理の工夫で解説しています。
メール・チャットのログ
過去の対応記録としてメールや社内チャットのログを使う場合は、一通や一発言ごとではなく、スレッドや一連のやり取りのまとまりで分けます。一発言だけでは、何についての話か分からないことが多いためです。ログには、挨拶や雑談、引用の繰り返しが多く含まれるため、分ける前に取り除くか、やり取りの要約を作って要約をチャンクにする方法も検討します。また、個人名や連絡先などの個人情報が含まれやすいため、取り込む範囲と公開範囲には特に注意が必要です。
契約書・利用規約のひな形
契約書や利用規約は、規程と同じく条を単位に分けるのが基本ですが、定義条項の扱いに注意が必要です。冒頭の定義条項で「本サービス」「利用者」などの語が定義されていると、各条のチャンクだけを読んでも語の意味が分かりません。よく参照される定義は各条のチャンクに付け足すか、定義条項を常に回答生成に渡す仕組みにします。また、契約書は取引先ごとに内容が異なることが多いため、ひな形と個別の契約を混ぜずに、契約の相手先や締結日をメタデータに持たせて区別します。
社内Wiki・ナレッジ記事
社内Wikiの記事は、書き手によって構造がばらばらなことが多く、見出しがない長文や、箇条書きだけの短いメモが混在します。見出しのある記事は見出しで区切り、見出しのない長文は段落の切れ目で区切って、記事のタイトルを各チャンクに付け足します。更新されずに古くなった記事が多い場合は、最終更新日をメタデータに持たせ、一定期間更新されていない記事を検索の対象から外すか、回答の中で「古い情報の可能性がある」と示すようにします。
分け方を決める手順
分け方は、次の手順で、評価の結果を見ながら決めます。
- 対象文書を種類ごとに分ける:規程、マニュアル、FAQ、議事録、表を含む資料などに分類する
- 種類ごとに代表的な文書を数件選び、構造を確認する:見出しの付け方、表の有無、長さのばらつき
- 種類ごとに分割の単位と付け足す文脈、メタデータを決める:この記事の表を出発点にする
- 評価用の質問を用意する:文書の種類ごとに、実際に想定される質問を集める
- 分割して検索を試し、根拠の箇所が検索結果に入っているかを確認する
- 失敗した質問について、チャンクの中身を見て原因を探る:区切りの位置、欠けている文脈、混ざった話題
- 分け方を一つずつ変えて評価を繰り返す
- 決めた分け方を文書の種類ごとに記録し、新しい文書の取り込みにも同じ規則を使う
5で確認するのは、回答の正しさではなく、検索結果に根拠のチャンクが入っているかどうかです。こうすることで、チャンクの効果を、回答生成の良し悪しと切り離して確かめられます。精度改善の全体の進め方はRAGの回答精度を改善する方法で解説しています。
架空の例として、ある会社で、就業規則と業務マニュアルを同じ規則で「一定の文字数ごと」に分けていたとします。評価してみると、規程についての質問ではただし書きの抜けが、マニュアルについての質問では注意事項の抜けが目立ちました。規程は条ごと、マニュアルは作業ごとに分け方を変え、それぞれに見出しの階層を付け足したところ、どちらの失敗も減りました。このように、文書の種類ごとに分け方を変えることは、手間に見合う効果が出やすい改善です。
チャンク設計チェックリスト
- 文書の種類ごとに分割の単位が決まっている
- 見出しや条、表の構造を失わずにテキストを取り出せている
- 各チャンクの先頭に文書名と見出しの階層が付いている
- ただし書きや注意事項が本文と同じチャンクに入っている
- FAQの質問と回答が同じチャンクに入っている
- 表の各行に列名と表の前提条件が付いている
- 更新日・版・公開範囲・対象の範囲がメタデータにある
- 極端に長いチャンク、極端に短いチャンクがない
- 評価用の質問で、根拠のチャンクが検索結果に入ることを確認した
よくある失敗と避け方
すべての文書を同じ規則で分ける
一つの規則ですべての文書を分けると、ある種類の文書には合っても、別の種類では失敗が増えます。少なくとも主要な文書の種類ごとに分け方を変えます。
チャンクの大きさだけを調整する
精度が低いときにチャンクの文字数だけを増減させても、区切りの位置が悪ければ改善しません。失敗した質問のチャンクを実際に読み、何が欠けているかを確かめてから手を入れます。区切りの位置が原因なら分割の単位を、文脈の不足が原因なら付け足す情報を、話題の混在が原因ならまとまりの切り方を見直す、というように、原因ごとに打ち手を選びます。
文脈を付け足さない
見出しや文書名がないチャンクは、本文に主語やテーマが書かれていない限り、何についての記述か分かりません。文脈の付け足しは最初から入れておきます。
取り出したテキストを確認しない
分割の前段階で表や段組みが崩れていると、どんな分け方をしても正しいチャンクにはなりません。分ける前のテキストを人の目で確認する工程を入れます。
よくある質問
Q. チャンクの最適な文字数はどのくらいですか?
文書の性質と質問の傾向、使う埋め込みモデルによって変わるため、一律の正解はありません。構造に沿って区切ることを優先し、そのうえで長すぎるものと短すぎるものを調整し、評価用の質問で比べて決めるのが確実です。
Q. 一つの文書を複数の分け方で保存してもよいですか?
よい方法の一つです。例えば、細かいチャンクで検索して、見つかったチャンクを含むより大きなまとまり(節や条全体)を生成AIに渡す方法があります。検索の当たりやすさと、回答に必要な文脈の両方を確保できます。ただし、保存量と仕組みの複雑さは増えます。
Q. 文書を追加するたびに分け方を見直す必要がありますか?
同じ種類の文書であれば、決めた規則をそのまま使えます。新しい種類の文書を追加するときや、精度の評価で特定の文書に失敗が集中したときに見直します。分け方の規則を記録しておくと、追加のたびに判断し直す手間が省けます。
Otsumuに相談できること
対象の文書が一、二種類に限られ、見出しや構造が整っているのであれば、この記事の表を出発点に分け方を決め、評価用の質問で確かめながら調整することで、自社で十分に進められます。まずは失敗した質問のチャンクを実際に読んでみることから始めてみてください。
扱う文書の種類が多い、PDFや表、スキャンした資料が多く取り出しの段階から工夫が必要、権限や版の管理を含めたメタデータの設計が必要、といった場合は、分割の設計とあわせて前処理や検索の仕組みまで見直すことになり、経験の差が結果に表れやすくなります。RAG全体の作り方はRAGシステムの構築手順で解説しています。
Otsumuでは、文書の棚卸しと種類別の分割設計、前処理、メタデータと権限の設計、評価による精度改善までを一貫して支援しています。目的から逆算して必要な範囲に絞り、AIを活用した少人数の開発で、評価の結果を確かめながら進めます。詳しくはRAG開発のページをご覧ください。
手元の文書でどう分けるとよいか、実際の資料を見ながら一緒に整理することもできます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆:Otsumu株式会社 / 編集日 2026.10.01