RAG Chunking ベストプラクティスガイド
NVIDIA、Microsoft Azure、Vectara（NAACL 2025）、Chroma Research、FloTorch（2026.02）などが公開したベンチマークデータと業界の実践を基に整理しています。
最終更新：2026年3月
1. ChunkingがRAGで最も重要な工程である理由
RAGの失敗の80%は、LLMそのものではなく、ingestionとchunkingの層に原因をたどれます。
VectaraがNAACL 2025で発表した研究（arXiv:2410.13070）は、25種類のchunking設定と48種類のembeddingモデルを組み合わせて検証しました。その結論は、chunking設定が検索品質へ与える影響は、embeddingモデルの選択と 同等か、それ以上 だというものです。Chromaの評価では、同じコーパス上で最良と最悪のchunking戦略に9%のrecall差が生じました。
中心的な矛盾は、chunkが大きすぎるとembeddingが希釈されて検索精度が下がり、小さすぎるとcontextを失って、検索できても役に立たなくなることです。すべての戦略は、このtrade-offの中で均衡点を探しています。
2. 推奨デフォルト設定：ここから始める
| パラメーター | 推奨初期値 | 出典 |
|---|---|---|
| 戦略 | Recursive Character Splitting | FloTorch 2026ベンチマークで第1位 |
| Chunk Size | 512 tokens | Microsoft Azure / NVIDIA / FloTorchの共通見解 |
| Overlap | 50〜100 tokens（10〜20%） | NVIDIAでは15%が最良、Azureは25%（128 tokens）を推奨 |
| chunkの最大値 | 1024 tokens | この長さを超えた場合は強制的に再分割 |
| 長すぎる段落 | 再帰的なfallback分割 | Recursive splittingに組み込まれた仕組み |
これらはベンチマークで検証されたデフォルト値です。 FloTorchが2026年2月に行ったテストでは、Recursive 512-token splittingが69%のエンドツーエンド精度を達成し、7種類の戦略で第1位になりました。追加のモデル呼び出しも必要ありません。
このbaselineの評価指標が頭打ちになった場合に限り、より複雑な戦略を検討します。
3. 主要な六つのChunking戦略を比較する
3.1 Fixed-Size Chunking（固定長分割）
意味を考慮せず、固定のtoken数または文字数で分割します。
- 長所： 実装が最も単純で、振る舞いを予測しやすく、indexingが最も速い
- 短所： 文や段落の途中で切れ、意味のまとまりを壊すことがある
- 適した用途： ログファイル、構造が均一なデータ、短期間のprototype
3.2 Recursive Character Splitting（再帰的な文字分割）⭐ 推奨デフォルト
優先順位を下げながら、区切り文字の配列["\n\n", "\n", " ", ""]で再帰的に分割します。
最初に段落で分割 → それでも大きすぎる場合は行で分割 → それでも大きすぎる場合は空白で分割 → 最後の手段として文字単位で分割します。各段階では、一つ前の段階に残った「長すぎる塊」だけを処理します。
- 長所： 文書構造を尊重しながらchunk sizeを制御でき、追加のモデル呼び出しが不要で、benchmarkでは最も安定している
- 短所： 意味を理解せず、書式上の境界だけを見る
- 適した用途： ほとんどの一般的なRAG用途における第一選択肢
コードファイル向けの変形：class定義 → function定義 → 段落 → 行の順に優先して分割します。
3.3 Sentence-Based Chunking（文単位の分割）
spaCyやNLTKなどのNLP文分割器で先に文へ分け、目標の長さまで文をまとめます。
- 長所： 一つの文を途中で分断しない
- 短所： 複数の文にまたがる意味を分断する可能性は残る
- 適した用途： FAQ文書、短い段落で構成された文書
2026年1月の体系的な分析では、5,000 tokens以内の文書でsentence chunkingがsemantic chunkingと同等の性能を示し、コストは後者のごく一部でした。
3.4 Semantic Chunking（意味に基づく分割）
embeddingで隣り合う文の意味的な類似度を計算し、類似度が急落する場所で分割します。
- 長所： chunkの境界が実際の話題の境界と一致する
- 短所：
- 隣接する文の組み合わせごとにembedding計算が必要で、計算コストが高い
- chunk sizeを予測できない
- FloTorch 2026のテストでは、平均わずか43 tokensの断片を生成したため、精度は54%にとどまった
- 適した用途： 精度要件が極めて高く、十分な予算があり、文書内で話題が頻繁に変わる場面
- 注意： Chromaの研究では、semantic chunkingのrecallはrecursiveより2〜3%高いだけ（91〜92%対85〜90%）ですが、コストは大幅に高くなります
3.5 Document Structure-Based Chunking（文書構造に基づく分割）
Markdownの見出し、HTMLタグ、PDFの章、コードのASTなど、文書が持つ構造上の信号を利用します。
- 長所： 構造化文書で最良の効果を発揮する。著者自身が意味をグループ化しているため
- 短所： 文書が適切に構造化されていることに依存し、非構造化テキストには適さない
- 適した用途： 技術文書、API文書、法律契約書、学術論文
NVIDIAのテストでは、金融文書のように複雑な分析推論を要するqueryで、page-level chunkingが最も安定していました。
3.6 Contextual Chunking（contextを補強する分割）
Anthropicが提案した方法です。LLMを使って各chunkへcontextの接頭辞を自動生成し、そのchunkが文書全体のどこにあり、どのような背景を持つかを説明します。
- 長所： 検索精度を大きく改善する。Anthropicは検索失敗が49%減少したと報告
- 短所： chunkごとにLLMを1回呼び出す必要があり、一括処理のコストが高い
- 適した用途： 精度要件が極めて高く、十分な予算がある本番システム
どの分割戦略とも組み合わせられます。たとえばrecursive splittingで先に分割し、その後LLMでcontextの接頭辞を追加します。
4. 三つの中核パラメーターを詳しく調整する方法
4.1 Chunk Size
経験則：一つのchunkだけで一つの問いに答えられるか、回答に必要な情報を完全なまとまりとして提供できるようにします。
| Queryの種類 | 推奨Chunk Size | 出典 |
|---|---|---|
| 事実を尋ねるquery（「XXのAPI keyはどこで取得できますか」） | 256〜512 tokens | NVIDIA: DigitalCorpora / Earningsデータセット |
| 分析query（「Q3とQ4の売上推移を比較してください」） | 512〜1024 tokens | NVIDIA: FinanceBenchデータセット |
| 一般的な混合用途 | 512 tokens | 複数のベンチマークで共通する初期値 |
「context cliff」現象に注意してください。2026年1月の体系的な分析では、単一のchunkが約2,500 tokensを超えると、LLMの応答品質が明確に低下しました。モデルが128Kのcontext windowをサポートしていても、巨大なchunkを使うべきではありません。
embeddingモデルとも整合させます。BGE-M3の最大入力は8,192 tokensですが、実務では512〜1,024 tokensのほうが良い結果を得られます。embeddingモデルの最大入力長は上限であって、目標値ではありません。
4.2 Overlap
経験則：chunk sizeの10〜20%。
| Chunk Size | 推奨Overlap | 備考 |
|---|---|---|
| 256 tokens | 25〜50 tokens | |
| 512 tokens | 50〜100 tokens | |
| 1024 tokens | 100〜150 tokens |
NVIDIAはFinanceBenchで10%、15%、20%をテストし、15%が最も良い結果になりました。
意見の分かれる結果にも注意が必要です。SPLADE検索 + Mistral-8Bを使った2026年1月の体系的な分析では、overlapは測定可能な効果をもたらさず、indexingのコストだけを増やしました。これは、overlapの効果が具体的な検索方法とデータの特徴に依存することを示します。overlapは常に有用だと決めつけず、evaluationで検証してください。
Overlapが大きすぎると、ストレージ使用量が増え、重複コンテンツがcontext windowの空間を浪費し、embedding indexの肥大化によってqueryが遅くなります。
4.3 長すぎる段落を処理する
一つの自然段落またはコードブロックが目標のchunk sizeを超える場合は、次のように処理します。
- 主戦略の再帰的なfallback機構を使って、塊の内部をさらに分割します。
- 分割時も、主戦略と同じoverlap設定を保ちます。
- 子chunkへ親のmetadata、たとえば元の段落の見出しや位置を残し、後から再構成できるようにします。
5. 文書の種類に応じて戦略を選ぶ
| 文書の種類 | 推奨戦略 | 説明 |
|---|---|---|
| Markdown/HTML技術文書 | Structure-Based + Recursive fallback | 見出し階層で分割し、長すぎるsectionを再帰的に再分割 |
| プレーンテキスト | Recursive Character Splitting | 一般的なデフォルト |
| 構造のあるPDF | Structure-Based（章/見出し） | 先にDocument Intelligenceで構造を抽出 |
| スキャンPDF/構造のないPDF | OCR → Sentence-BasedまたはRecursive | 先にOCRを実行してから分割 |
| コードファイル | AST-Based / Code-Aware Recursive | class → function → methodの境界で分割 |
| 表データ | 行単位/セル単位の分割 | 各行または意味上まとまった行の組を一つのchunkにする |
| FAQ / Q&A文書 | Q&A pairごとに一つのchunk | 自然な境界が明確 |
| 法律/金融文書 | Page-LevelまたはSection-Based | NVIDIAのテストではこの種の文書にpage-levelが最も安定 |
本番システムにはchunking routerが必要です。 一つの戦略をすべての文書へ適用するのではなく、ファイル形式と文書構造に応じて戦略を自動選択します。
6. 必ず保存すべきMetadata
各chunkには、テキスト本体に加えて次の情報を保存します。
| Metadataフィールド | 用途 |
|---|---|
source_file | 元ファイルのパス/名前 |
page_number / line_range | 元文書内の正確な位置 |
heading_hierarchy | 「第3章 > 3.2 認証 > JWT」のような見出し階層 |
chunk_index | 文書内におけるchunkの順序 |
total_chunks | 文書のchunk総数 |
doc_type | 文書の種類。検索時のfilterに使用 |
created_at / updated_at | 時刻情報。新しさによる順位付けに使用 |
language | 言語識別子。多言語用途では必須 |
Metadataには、検索時にsourceやdoc_typeでfilterする、結果表示で出典を示す、隣接chunkを再構成してcontextを復元する、といった価値があります。
7. Evaluation-Drivenな調整フロー
直感でパラメーターを選ばず、次の流れを使います。
Step 1：評価セットを作る
典型的なqueryパターンを網羅する50〜100組の(question, expected_answer, source_document)を用意します。
Step 2：Baselineを作る
推奨デフォルト設定（Recursive、512 tokens、overlap 50〜100）を実行し、基準となる指標を記録します。
Step 3：中核的な評価指標
| 指標 | 意味 | ツール |
|---|---|---|
| Context Recall | 取得したchunkに、本来含むべき情報がどの程度含まれるか | Ragas / DeepEval |
| Context Precision | 取得したchunkのうち、ノイズではなく実際に関連するものがどの程度あるか | Ragas / DeepEval |
| Answer Correctness | 最終的に生成した回答の正しさ | Ragas / DeepEval |
| Faithfulness | 回答が幻覚ではなく、取得したcontextへ忠実か | Ragas / DeepEval |
Step 4：パラメーターを走査する
一度に一つのパラメーターだけを変更します。
- Chunk size: [256, 512, 768, 1024]
- Overlap: [0, 50, 100, 150]
- 戦略: [recursive, sentence, structure-based]
Step 5：反復する
context recallが低い → chunkが小さすぎるか、戦略が重要な情報を分断していないか確認します。
context precisionが低い → chunkが大きすぎて無関係な情報を含んでいないか確認します。
faithfulnessが低い → 誤ったchunkを取得した可能性があるため、embeddingとrerankingを確認します。
8. 品質確認Checklist
Chunkingの完了後、次の項目を確認します。
- 20 tokens未満の断片的なchunkが大量にないか。通常は分割ロジックのbugを示します。
- embeddingモデルの最大入力長を超えるchunkがないか。
- 20個のchunkを抽出し、意味が明らかに分断された箇所がないか人が確認する。
- chunkのtoken長の分布は妥当か。ヒストグラムはおおむね正規分布で、極端なlong tailがないこと。
- metadataは完全か。source、position、headingに値があること。
- overlap領域のテキストが隣接chunkと正しく一致するか。
9. 高度な改善の方向
baselineの評価指標が頭打ちになったら、次の順序で検討します。
- Contextual Chunking（Anthropicの方法）：LLMで各chunkへcontextの接頭辞を追加します。コストは高いものの、効果は大きくなります。
- Hybrid Retrieval： Dense（embedding）+ Sparse（BM25）を組み合わせた検索です。どちらか一方だけを使うより良い結果を得られます。
- Reranking： top-20を検索し、Cohere Rerankなどのrerankerで並べ替え、top-5をLLMへ渡します。小さく正確なchunkは、rerankerに明確な信号を与えます。
- Query Transformation： 検索前にユーザーのqueryを書き換え、拡張、分解し、検索のhit率を改善します。
- Late Chunking： 文書全体を先にembeddingしてから分割し、全体の意味情報を残します。比較的新しい方法であり、まだ実験段階です。
10. よくある落とし穴
落とし穴1：最初からsemantic chunkingを使う FloTorch 2026のテストでは、semantic chunkingは短すぎる断片を生成したため精度が54%にとどまり、recursive splittingの69%を大きく下回りました。単純な戦略から始め、データによって必要性を証明できた場合だけ高度化します。
落とし穴2：embeddingモデルの最大入力長をchunk sizeにする BGE-M3が8,192 tokensをサポートしていても、8,192-tokenのchunkを作るべきではありません。実務では、windowを使い切るより512〜1,024 tokensのほうが、検索性能が大幅に高くなります。
落とし穴3：すべての文書に同じ戦略を使う コード、Markdown、PDF、表では、最適な分割方法がまったく異なります。本番システムにはchunking routerが必要です。
落とし穴4：evaluationなしでパラメーターを調整する 直感で選んだパラメーターが最適であることはほとんどありません。評価セットを用意し、Ragas/DeepEvalで定量的に比較します。
落とし穴5：chunk作成後にmetadataを残さない metadataがなければ、出典によるfilter、位置の特定、隣接chunkの再構成ができません。後から追加するコストは極めて高くなります。
落とし穴6：overlapによるストレージへの影響を無視する 20%のoverlapは、ベクトルデータベースへ約20%多くのデータを保存することを意味します。大規模なコーパスでは小さな量ではありません。
参考資料
- NVIDIA Technical Blog: Finding the Best Chunking Strategy for Accurate AI Responses (2025)
- Vectara / FloTorch Benchmark: 50 academic papers, 7 strategies, February 2026
- Chroma Research: Token-level retrieval recall across chunking strategies (2025)
- Microsoft Azure Architecture Center: RAG Chunking Phase
- Anthropic: Contextual Retrieval Paper (2024)
- Databricks Technical Blog: The Ultimate Guide to Chunking Strategies for RAG (2025)
- Stack Overflow Blog: Breaking up is hard to do — Chunking in RAG applications (2024)
- Firecrawl: Best Chunking Strategies for RAG in 2026
- PremAI: RAG Chunking Strategies — The 2026 Benchmark Guide