RAGの文書分割（チャンク）の決め方：規程・マニュアル・議事録で変える切り方

まず押さえる公式情報

MicrosoftのAzure AI Searchのチャンク分割ガイドには、次の内容があります。

• 大きな文書を分割すると、モデルの入力上限に収めやすくなり、1つのベクトルで表しにくい話題の多いページも細かく扱えます。
• 固定サイズ分割の出発点として、512トークン（約2,000文字）と重なり25%（128トークン）が示されています。ただし、Azure AI Searchの同ページには、文字数を基準にする場合の別の初期値として2,000文字、重なり500文字も示されています。最適値は内容や用途で変わり、構造化されたデータは重なりを少なくできる場合があります。
• HTMLやMarkdownは見出しで区切る方法があり、長い文書では途中のチャンクに文書タイトルを付ける例も挙がっています。

Azure Architecture CenterのRAGチャンク分割フェーズ（同2026年5月27日）では、小さすぎるチャンクは質問に答える文脈を欠き、大きすぎるチャンクはモデルの入力上限やコスト、無関係な情報の混入に影響すると説明しています。また、文書の構造や種類を方式選びの手がかりとし、複数の方式を試して比べることを勧めています。

文書種別ごとの分割ルール表

以下は上の資料を踏まえた編集上の提案で、実測の結果ではありません。条文の書き方や議事録の様式は組織で違うため、自社の文書に合わせて直してください。

• 規程・規則、基本の単位：1条（見出し付き）、長い場合：項ごとに分け、条の見出しを各項に繰り返す、各チャンクに付ける情報：規程名＞章＞条、施行日・改定日、注意点：「前条の場合を除き」のような参照先を別チャンクに分離しない。定義条項は独立させる
• マニュアル、基本の単位：1つの作業（見出し下の手順全体）、長い場合：前提・手順・注意・トラブル対応の境目で分ける、各チャンクに付ける情報：製品名、版、見出しの階層、注意点：番号付き手順の途中で切らない。「警告」は対象の手順と同じチャンクに入れる
• 議事録、基本の単位：1議題、長い場合：決定事項とToDoを別チャンクにする、各チャンクに付ける情報：会議名、日付、議題名、参加部署、注意点：日付や議題名がないと「いつの決定か」が答えられない。雑談や挨拶は除外を検討する
• 表が主体の別表・料金表、基本の単位：1表（行数が多ければ見出し行を付けて行グループ）、長い場合：見出し行を各グループに繰り返す、各チャンクに付ける情報：表のタイトル、単位、適用条件、注意点：行だけ切り出すと列名が失われる

議事録のように長い発言録を要約してからチャンクにする方法は、Architecture Centerでも言語モデルによる補強の用例として挙がっています。ただし要約に誤りが入る可能性があるため、決定事項は原文を残して併記するほうが安全です。

分割単位を決める6つの手順

1. 質問を集める。 実際に想定される質問を20件ほど用意します。問い合わせ履歴や担当者へのヒアリングから、実際の言い回しで集めます。
2. 答えの場所を記録する。 各質問の答えが、文書のどこに、どの範囲で書かれているかを人が文書で確かめて記録します。「1項」「1条」「複数条にまたがる」「表の1行」などで分類します。
3. 最頻の粒度を単位にする。 多くの質問が1条で答えられるなら、条を基本単位にします。複数条にまたがる質問が多いなら、章単位の要約チャンクを追加するか、後述の見出しパス付与で補います。
4. 上限を確認する。 使う埋め込みモデルの入力上限と、1回の回答に入れる件数から、1チャンクの上限を決めます。AzureのText Splitスキルのように文字数で数えるツールもあれば、トークンで数えるものもあり、両者は一致しません。
5. 見出しパスを付ける。 本文の先頭か、メタデータに「規程名＞章＞条」のような階層を持たせます。
6. 試して直す。 手順2の質問を実際に検索し、正しいチャンクが上位に出るかを見ます。出ない質問の原因（大きすぎ、小さすぎ、見出し欠落）を分類し、ルールに戻って調整します。

見出し・表・箇条書きの扱い

見出し

見出しは分割の境界であり、同時に文脈情報です。LangChainのMarkdownHeaderTextSplitterは、指定した見出しで分割し、各チャンクにどの見出しの配下かをメタデータとして持たせます。初期設定では見出し行が本文から取り除かれます（strip_headersが有効）。見出しを本文にも残したい場合はFalseにします。同ドキュメントによれば、見出しで分割した後に再帰的な文字分割を重ねられ、重なりはセクションの境界をまたぎません。つまり見出し単位で分けると、隣の節の内容が混ざる心配は減りますが、「前の節を受けた説明」は自分で補う必要があります。

表

表は行単位で切ると列名が失われます。見出し行を各チャンクに付けるか、表を「項目：値」の文章に書き換えます。画像化された表や複雑なレイアウトは、レイアウト解析サービスの利用が選択肢になりますが、Architecture Centerは、これらがクラウドへの文書アップロードを伴うため、自社のセキュリティ要件で許されるかの確認が必要だと注意しています。

箇条書き・番号付き手順

親の文（「次の場合は申請が必要です」など）と箇条書きを分離しないでください。条文の「1、2、3」や「a、b、c」のような入れ子は、全体を1チャンクにするか、各項目の先頭に親の文を補います。入れ子の深い構造は、見出しパターンを正規表現などで処理する独自コードを使う方法もあります。

AIに手伝わせる部分と人が確かめる部分

AIに任せやすいのは、質問ログの粒度分類と、分割ルールの叩き台づくりです。AIは文書そのものを見ていないと推測になるため、答えの場所は人が文書で確認します。以下は依頼文の例です（機密情報は含めず、目次と説明用の質問だけを渡します）。

RAGのチャンク設計のため、質問の粒度を分類してください。
【文書】出張旅費規程（目次のみ貼ります。本文は貼りません）
【目次】第1章 総則／第2章 国内出張（第5条 日当、第6条 宿泊費…）／第3章 海外出張／別表1 宿泊費上限
【質問一覧】
1. 国内出張の宿泊費の上限はいくらですか
2. 日帰り出張でも日当は出ますか
（以下、約20件）
【依頼】各質問について、答えに必要な範囲を「1項／1条／複数条／別表／不明」から選び、理由を1行で書いてください。最後に最も多い粒度と、例外の質問を挙げてください。目次にない情報は推測だと明記してください。

この例の規程名や条番号は説明用で、実在の規程ではありません。返ってきた分類は仮説です。「別表」「複数条」と判定された質問は、担当者が本文を開いて、答えが本当にその範囲にあるかを確かめてください。

失敗の見分け方

• 条件の一部しか答えない（例外規定が抜ける）、考えられる原因：チャンクが小さい、参照先が別チャンク、試すこと：条単位に広げる。ただし書きを同じチャンクに含める
• 無関係な条の内容が混ざる、考えられる原因：チャンクが大きい、試すこと：項単位に分け、見出しパスを付ける
• 「いつの会議か」が答えられない、考えられる原因：日付・会議名の欠落、試すこと：各チャンクに会議名と日付を付与する
• 表の数値の意味を取り違える、考えられる原因：列名・単位が切り離された、試すこと：見出し行を各チャンクに繰り返す
• 同じ内容が重複して上位に並ぶ、考えられる原因：重なりが大きい、試すこと：重なりを減らす。見出し単位の分割では原則不要かを試す

分割方法の変更は、インデックスの作り直しなど下流の工程にも影響します。Architecture Centerも、チャンク方式は半ば固定的な設計判断だとして、本番前に比較するよう勧めています。20件の質問と正解位置の記録を残しておけば、ルールを変えたときに同じ質問で比べ直せます。