RAG システムにおける Chunking のベストプラクティス：固定分割から構造化、文脈付与、評価駆動へ

Chunking は、RAG のデータ取り込み段階における中心的な設計事項である。次の点を左右する。

• 検索システムが何を見つけられるか
• Embedding が1つの完全な概念を表すか、複数の話題が混在したものを表すか
• 引用を正確な位置へ向けられるか
• Reranker と LLM がどれほどのコンテキストを処理する必要があるか
• システムの最終的な正確性、遅延、コスト

現在、すべての RAG システムに適用できる唯一の最適 Chunk Size はなく、あらゆるデータセットで優位となる Chunking アルゴリズムも存在しない。より堅牢な工学的結論は次のとおりである。

文書構造と意味の完全性を主な分割基準とし、Token 長を制約として用いたうえで、実際の検索・質問応答データセットによって最終案を決める。

Google Cloud は、最適な Chunking 戦略に標準解はなく、データとアプリケーションによって異なると明記している。2026年の体系的研究でも、Chunking の効果は検索タスク、データセット、Embedding 手法に大きく依存し、複雑な LLM 駆動方式が単純な構造分割より優れるとは限らないことが示された。(Google Cloud Documentation)

1. Chunking が本当に解決する問題は何か

理想的な Chunk は、3つの目標を同時に満たす必要がある。

意味が完全である：
単独で理解できる事実、概念、規則を含む

検索対象として焦点が明確である：
クエリと無関係な話題を大量に混ぜない

コンテキストが十分である：
事実の理解に必要な見出し、限定条件、前後関係を保つ

しかし、これらの目標は互いに緊張関係にある。

Chunk が小さすぎる場合

次の問題が起こり得る。

• 主語と結論が分離される
• 規則と例外条件が分離される
• 表のデータが見出しを失う
• 代名詞が指示対象を失う
• 局所的な文は検索できても、質問へ答えるには不十分になる

Chunk が大きすぎる場合

次の問題が起こり得る。

• 1つのベクトルが複数の話題を同時に表す
• 関連情報が大量の無関係な内容に薄められる
• Rerank と生成のコストが上がる
• 引用範囲が広すぎる
• Embedding が局所的な詳細を失う

Google の現行文書は、このトレードオフを次のようにまとめている。小さい Chunk は通常、より正確なベクトル表現を得られ、大きい Chunk はより多くのコンテキストを保持できるが、局所的な詳細を見落としたり、過度に広い表現になったりしやすい。(Google Cloud Documentation)

したがって、Chunking の目的はすべてのブロックをまったく同じ長さにすることではない。

意味単位を、検索対象として扱うのに適した大きさへ分けることである。

2. 現在の堅牢なデフォルト戦略

大多数の企業文書では、次の基準パイプラインを推奨できる。

元ファイル
   ↓
レイアウトと構造を解析
   ↓
見出し、節、段落、リスト、表、コードブロックを認識
   ↓
自然な構造境界で一次分割
   ↓
長すぎるブロックを段落、文、Token で再帰分割
   ↓
見出しパス、ページ番号、版、ACL などの metadata を追加
   ↓
Embedding とインデックス作成

優先順位は次のようにまとめられる。

文書構造の境界
    >
段落と文の境界
    >
固定 Token の境界
    >
任意の文字境界

Google のレイアウト認識 Chunking は、1つの Chunk に含まれる内容が、見出し、下位見出し、リストなど同一のレイアウト要素に属するよう保証し、意味上の一貫性を高め、検索ノイズを減らす。Microsoft も、固定長だけで分けるのではなく、見出し、段落、表、ページレイアウトなどの構造から Chunk を作ることを推奨している。(Google Cloud Documentation)

3. 固定長 Chunking にも依然として価値がある

固定長 Chunking は時代遅れではない。

長所は次のとおりである。

• 単純
• 高速
• 結果を再現しやすい
• インデックス規模を制御しやすい
• 実験の基準線にしやすい

LangChain v1 は現在も文字、Token、再帰テキストの Splitter を提供している。汎用の再帰 Splitter は一連の区切り文字を順番に使い、長さ制限を満たしながら、可能な限り段落と文を先に保つ。(Docs by LangChain)

固定ウィンドウに適するもの：

ログ
チャット履歴
連続した文字起こし
構造の弱いプレーンテキスト
迅速なプロトタイプ
比較可能な基準線の作成

あまり適さないもの：

複雑な PDF
契約書と法規
表
コード
多階層見出しを持つ技術文書
複数列のレイアウト

Microsoft の Document Intelligence 文書も、固定サイズ分割は明確な意味構造を欠くデータには有効だが、正確なコンテキストと意味理解を必要とする文書のデフォルトにすべきではないと述べている。(Microsoft Learn)

4. 文書の種類ごとに異なる戦略を使う

1. Markdown、HTML、Wiki、技術文書

次の構造に沿って分割する。

H1
└── H2
    └── H3
        ├── 段落
        ├── リスト
        └── コードブロック

推奨事項：

• 上位見出しの境界を安易にまたがない
• 同じ節の短い段落は結合できる
• 長すぎる節はさらに再帰分割する
• 完全な見出しパスを各 Chunk へ付与する
• コードブロック、リスト、引用ブロックを途中で切らない

LangChain v1 は HTML、JSON、コード専用の Splitter を提供している。これは重要な原則を示している。異なるデータ形式には、その構造を理解する Splitter を使い、すべてをプレーンテキストへ変換して一律に分割すべきではない。(Docs by LangChain)

Chunk のインデックス用テキストは、たとえば次のようになる。

文書：返金管理マニュアル
節：注文処理 > 返金条件 > 30日を超えた注文

30日を超えた注文は、次の場合に限り……

見出しパスは、本文の局所的な断片に欠けている文脈を補える。

2. PDF、オフィス文書、スキャン画像

複雑な文書の第一歩は通常、Chunking ではなく、レイアウトを正しく解析すること である。

復元すべき要素：

• 読む順序
• 見出し階層
• 段落
• ページ番号
• リスト
• 表
• 画像と説明
• 複数列レイアウト
• 脚注、ヘッダー、フッター

PDF を長い文字列へ抽出して500文字ごとに切ると、次の問題が起こり得る。

左右の列の内容が交差する
表の見出しとデータが分離する
節見出しが失われる
ヘッダーとフッターが何度もインデックスへ入る

Google の現行レイアウト解析とレイアウト認識 Chunking、および Microsoft の文書レイアウト方式は、どちらも文書構造の復元を高品質な RAG 取り込みの重要工程としている。(Google Cloud Documentation)

ページ番号の主な用途は次のとおりである。

引用位置
出典表示
監査 metadata

文、表、節はページをまたぐ可能性があるため、ページをデフォルトの意味境界にすべきではない。

3. 契約書、法規、制度文書

正式な論理構造に沿って分割する。

章
条
項
号
定義
付録

重要な原則：

• 本則と例外条件を分離しない
• 下位項目には所属する条文の見出しを残す
• 条文番号を metadata へ入れる
• 定義条項と、その定義を参照する条項を関連づけられるようにする
• 長すぎる条項は下位項目で分けるが、必要な上位文脈を繰り返す

たとえば、次の2文を無関係な Chunk へ分けてはいけない。

従業員はリモートワークを申請できる。
ただし、機密データを扱う職種は除く。

最初の文だけが検索されると、システムが誤った回答を生成する可能性がある。

4. 表

表の単独の値は通常、それだけでは理解できない。

700

これだけでは検索価値がない。

より適したインデックス形式は次のとおりである。

表：高度人材の年収ポイント
年齢区分：35～39歳
年収：700万円
ポイント：25点

実務では次のように扱える。

• 小さい表は全体を保存する
• 大きい表は論理的な行グループで分ける
• 各子ブロックで表名、列名、単位を繰り返す
• 元の Markdown、HTML、構造化 JSON を保つ
• 文章による説明を追加してもよいが、元データを完全に置き換えない

5. コード

コードは任意の Token ではなく、構文構造に沿って分割する。

モジュール
クラス
関数
メソッド
インターフェース
設定ブロック

コード Chunk には通常、次の情報を付ける。

repository
file_path
language
class_name
function_name
signature
docstring
imports

長い関数を分割する場合も、関数名、所属クラス、ファイルパスを保つ。

5. Chunk Size はどれくらいにするか

普遍的な最適値はないが、実験の開始値を置くことはできる。

短い事実、FAQ、定義：
約 200～400 tokens

一般的な企業文書：
約 400～800 tokens

長い規則、分析的な内容：
約 800～1,200 tokens

これらは業界標準ではなく、候補実験を始めるための数値にすぎない。

代表的な製品デフォルトの一つが、OpenAI Vector Store の現在の自動 Chunking である。

最大 Chunk：800 tokens
Overlap：400 tokens

OpenAI は、Chunk Size と Overlap を独自設定する静的戦略も認めている。このデフォルト値は、同社のマネージド File Search の製品既定値としてのみ理解すべきで、800/400 がすべての RAG システムで最適だと証明するものではない。(OpenAI Developers)

Chunk Size を決める際は、次を考慮する。

• ユーザーの質問が通常どれほどの証拠範囲を必要とするか
• 文書内の完全な意味単位がどれほど長いか
• Embedding モデルの入力制限と長文性能
• Reranker を使うか
• 最終的なコンテキスト予算
• インデックス数、遅延、コスト
• 段落をまたぐ質問が多いか

6. Overlap は慎重に使う

Overlap は、重要情報がちょうど分割境界をまたぐことを防ぐ。

しかし、大量の重複を機械的に加えると、次の問題が起こる。

• ベクトルの重複
• インデックスの肥大化
• 互いに非常によく似た複数の結果
• LLM コンテキストの重複
• Reranker コストの増加
• 引用の重複

現実的な開始値は次のとおりである。

固定ウィンドウ：
約 10%～20% の overlap

構造化 Chunk：
通常は一律の overlap を使わない

特殊な境界：
直前の文、見出し、条文番号、必要な定義を複製する

OpenAI のマネージド File Search は現在、自動戦略で50%の重複を使う。ただし、これは特定のマネージド製品のデフォルト動作であり、自作システムで一般的な業界標準として扱うべきではない。(OpenAI Developers)

通常、よりきれいな方法は次のとおりである。

隣接する本文を大量に複製するのではなく、構造化されたコンテキストを補う。

7. Parent–Child と複数粒度の検索

検索単位と、最終的に LLM へ渡すコンテキスト単位は、同じである必要はない。

2階層の構造を作れる。

Parent：
完全な節、条項、または大きな意味単位

Child：
Embedding と精密検索に使う小さなブロック

クエリの流れ：

Child を検索
   ↓
一致した細粒度の内容を特定
   ↓
必要に応じて Parent または隣接 Chunk へ拡張
   ↓
Rerank
   ↓
LLM へ送信

この方式は次を両立する。

• 小ブロックの検索精度
• 大ブロックの文脈完全性
• 正確な引用
• 複数段落の証拠の組み合わせ

毎回、親文書全体を無条件に返してはいけない。次に応じてコンテキストを動的に拡張する。

• Parent の長さ
• 質問の種類
• ヒット位置
• 複数段落の証拠が必要か

8. Contextual Retrieval：Chunk に文書全体の文脈を補う

Anthropic が提案した Contextual Retrieval は、インデックス前に各 Chunk 向けの短いコンテキスト説明を生成し、次を組み合わせる。

コンテキスト説明 + 元の Chunk

これを Embedding と BM25 インデックスに使う。

たとえば元の Chunk が次の内容だとする。

この製品の売上高は前年同期比3%増加した。

コンテキストを補うと、次のようになる。

この段落は、ある企業の2023年第2四半期決算報告からのもので、
当該四半期における製品売上高の変化を説明している。

この製品の売上高は前年同期比3%増加した。

これにより、短い Chunk が全文から離れたときの曖昧さを減らせる。Anthropic は社内実験で、Contextual Embeddings と Contextual BM25 の組み合わせが検索失敗率を下げ、Reranking を加えるとさらに改善したと報告している。ただし、数値は同社独自のデータセットと設定によるもので、すべてのプロジェクトへ直接一般化できない。(Anthropic)

代償は次のとおりである。

• 取り込み段階で LLM 呼び出しが増える
• インデックス用テキストが長くなる
• 再構築コストが上がる
• 自動生成コンテキストが誤る可能性がある
• 評価と debug が複雑になる

したがって、次の状況により適する。

Chunk を全文から切り離すと曖昧になりやすい
文書で代名詞や局所参照を多用している
検索データセットによって通常の構造分割では不足すると分かった
より高い取り込みコストを許容できる

すべての文書へデフォルトで適用すべきではない。

9. Late Chunking：Chunk ベクトルを作る前に全文の文脈を保持する

従来方式は次のとおりである。

先に分割する
→ 各 Chunk を個別に Embedding する

Late Chunking は次の順序を取る。

長いコンテキスト対応の Embedding モデルで、先に長文を処理する
→ そのモデル出力から各 Chunk の表現を集約する

目的は、小さい Chunk のベクトルにも全文のコンテキストを残すことである。元の論文は、一部の検索タスクで改善し、各 Chunk 向けに追加の説明文を生成する必要もないと報告している。(arXiv)

ただし、実務上の制限もある。

• 対応する長コンテキスト Embedding モデルが必要
• 実装と推論の流れが複雑
• 非常に長い文書は依然として分割が必要
• 検索タスクによって効果が一貫しない

2026年の体系的比較では、Contextualized Chunking は標準的なコーパス横断検索に役立つ可能性がある一方、文書内検索では性能が低下する場合があり、一部タスクでは単純な段落または固定長の構造的方式の方が優れていた。(arXiv)

したがって、Late Chunking は新しいデフォルト標準ではなく、高度な候補方式として扱うべきである。

10. Semantic Chunking と LLM-guided Chunking

Semantic Chunking は文ベクトルの変化や話題転換から境界を見つける。LLM-guided Chunking は、どの内容を一緒に保つべきかモデルに判断させる。

考えられる長所：

• 明示的な見出しのない話題境界を見つけられる
• 長い自由形式テキストでは、より自然に分けられる可能性がある
• 意味単位が機械的に切られる問題を減らせる可能性がある

考えられる短所：

• 取り込みコストが高い
• 結果が不安定になり得る
• モデルと閾値へ敏感
• 再現しにくい
• 段落分割や構造分割より優れるとは限らない

体系的研究から得られた重要な結論の一つは、複雑な方法が普遍的に優れるわけではないことだ。標準的な文書横断検索では、単純な構造方式が複数のテストで非常に高い競争力を示し、タスクが異なれば、まったく異なる方式が好まれる場合がある。(arXiv)

したがって、推奨順序は次のとおりである。

構造認識による分割
   ↓
文 / Token の再帰分割
   ↓
Parent–Child またはコンテキスト拡張
   ↓
Contextual Retrieval / Late Chunking
   ↓
Semantic または LLM-guided Chunking

各段階の必要性は、評価結果によって証明すべきである。

11. 各 Chunk に保存すべきデータ

企業向け Chunk は、次の内容だけでは不十分である。

{
  "text": "...",
  "vector": [...]
}

少なくとも次の保存を検討する。

{
  "chunk_id": "doc-123-v4-c08",
  "document_id": "doc-123",
  "document_version": 4,
  "parent_id": "section-12",
  "content": "...",
  "title": "育儿休业制度",
  "section_path": [
    "人事制度",
    "休假制度",
    "育儿休业"
  ],
  "page_start": 8,
  "page_end": 9,
  "chunk_index": 8,
  "token_count": 542,
  "source_uri": "...",
  "tenant_id": "...",
  "allowed_roles": ["employee"],
  "content_hash": "...",
  "effective_from": "2026-04-01"
}

Microsoft の Chunk Enrichment ガイドも、フィルタリング、検索、結果説明を支えるため、タイトル、要約、キーワード、エンティティ、その他の metadata で検索レコードを拡充するよう勧めている。(Microsoft Learn)

重要なフィールドには通常、次が含まれる。

文書と版
親子関係
節のパス
ページ番号
順序
ACL
テナント
発効日
内容ハッシュ
パーサーのバージョン
Chunking 戦略のバージョン
Embedding モデルのバージョン

これらがあって初めて、次を実現できる。

• 正確な引用
• 権限フィルタリング
• 再インデックス
• 文書更新
• A/B テスト
• 問題追跡

12. Chunking は評価によって決める

ベストプラクティスは、高度に聞こえるアルゴリズムを選ぶことではなく、再現可能な実験を構築することだ。

少なくとも次を比較する。

A：固定 400 tokens
B：固定 800 tokens + overlap
C：構造認識分割
D：構造分割 + Parent–Child
E：Contextual Retrieval
F：Late または Semantic Chunking

検索指標

Recall@K
Precision@K
MRR
nDCG@K
Hit Rate

最終的な質問応答指標

Answer Correctness
Groundedness
Citation Correctness
Completeness
回答拒否の正確率

工学指標

Chunk 数
インデックス規模
取り込みコスト
検索遅延
Rerank 遅延
LLM Context Token
成功回答1件当たりのコスト

クエリの種類ごとに分けた分析も必要である。

短い事実クエリ
段落横断クエリ
表クエリ
正確な番号クエリ
複数文書クエリ
答えのないクエリ
多言語クエリ

Google の RAG 評価ガイドも、最終回答だけを見るのではなく、検索と生成を分けて診断することを強調している。同じ最終的な誤りでも、その原因は Chunking、Retriever、Reranker、生成モデルのいずれにもあり得るためである。(Google Cloud)

13. 現実的な本番基準

大多数の企業知識ベースでは、次の方式から始められる。

1. レイアウト認識パーサーで文書構造を復元する
2. 見出し、節、段落、リスト、表、コードブロックに沿って分割する
3. 上位階層の節境界をまたがない
4. 長すぎるブロックを文と Token で再帰分割する
5. 最終的な長さ制約には文字ではなく Token を使う
6. 最初は 400、600、800 tokens など複数の段階をテストする
7. 必要な位置だけに少量の overlap を使う
8. 各ブロックへ見出しパス、ページ番号、版、出典、ACL を追加する
9. parent_id、chunk_index、隣接関係を保つ
10. 実クエリセットで Dense、Hybrid、Rerank 後の性能を比較する
11. 基準方式で不足する場合のみ Contextual または Late Chunking を導入する
12. Chunking 戦略と版をインデックス metadata へ記録する

OpenAI の800-token マネージド既定値、LangChain の再帰 Splitter、Google と Microsoft のレイアウト認識方式、Anthropic の Contextual Retrieval、Late Chunking の研究は、実際には異なる階層の解決策を表している。

OpenAI：
マネージド検索製品で使用可能なデフォルト設定

LangChain：
汎用実装ツールと組み合わせ可能な Splitter

Google / Microsoft：
文書構造と企業向け取り込みエンジニアリング

Anthropic：
局所 Chunk へ全文のコンテキストを補う

研究論文：
文脈を取り込む新しい Embedding と分割手法の探索

これらは互いに排他的ではなく、どの組織もすべてのシステムへ適用できる唯一の答えを示してはいない。

結論

前述の資料を総合すると、堅牢な RAG Chunking の実践は次のようにまとめられる。

まず文書構造を復元して尊重し、次に意味単位で分割する。Token 上限でブロックサイズを制約し、見出し、metadata、Parent–Child 関係でコンテキストを保持したうえで、実際の Evaluation Dataset によって Chunk Size、Overlap、高度な戦略を決める。

固定長 Chunking は依然として重要な基準線である。構造化 Chunking は通常、企業文書でより信頼できるデフォルトとなる。Contextual Retrieval、Late Chunking、LLM-guided Chunking は価値ある新しい方向を示すが、いずれも無条件のアップグレードではない。

避けるべきなのは、次の流れである。

あるプラットフォームのデフォルトが 800 tokens だと知る
→ すべての文書にそのままコピーする
→ PDF、契約書、表、コードを区別しない
→ 検索評価を行わない
→ それをベストプラクティスと呼ぶ

本当のベストプラクティスは、1つの固定パラメータではない。

説明可能な分割戦略、再構築可能なインデックス、文書種別ごとの処理、そしてデータ駆動の継続評価である。