RAGに最適なチャンクサイズは？

普遍的な答えはありませんが、オーバーラップ10〜20%で400〜512トークンが良い出発点です。次にクエリタイプに合わせて調整しましょう。正確な事実検索には128〜256トークン、分析や要約クエリには512〜1024トークンです。単一のデフォルトを当てにするのではなく、自分の質問に対していくつかのサイズをベンチマークしてください。

チャンクのオーバーラップはどのくらいにすべき？

チャンクサイズの10〜20%、500トークンのチャンクで約50〜100トークンです。オーバーラップは境界で意味が断ち切られるのを防ぎます。少なすぎると分割点でコンテキストが分断され、多すぎるとインデックスが肥大化してほぼ重複する検索結果が出ます。NVIDIAは財務資料で約15%が最適だと示しました。

semantic chunkingはfixed-sizeより優れていますか？

確実とは言えません。semantic chunkingはトピック単位で文をグループ化するため良さそうに思えますが、ベンチマークではrecursiveやfixed-sizeに対する優位性が安定せず、追加のエンベディング計算コストに見合わないことが多いです。fixed-sizeとrecursiveは強力で安価なベースラインであり、まずはそこから始め、評価で実際の改善が確認できたときだけsemanticへ移行しましょう。

late chunkingとは何で、いつ使うべきですか？

late chunkingは、まず長コンテキストのエンベディングモデルで文書全体をエンベディングし、続いてトークンエンベディングをチャンクへプーリングします。そのため各チャンクのベクトルは、自身のテキストだけでなく文書全体のコンテキストを担います。前の文脈がなければパッセージの意味が通らないような、長距離の依存関係を持つ長い文書に使いましょう。

contextual retrievalは本当に精度を上げますか？

はい、測定可能な形で上がります。Anthropicの報告によれば、各チャンクにLLM生成のコンテキストノートを付加することで、contextualエンベディングでトップ20の検索失敗を35%、contextual BM25との併用で49%、リランキングの追加で67%削減しました。プロンプトキャッシングを用いて、100万ドキュメントトークンあたり約$1.02です。パッセージの取りこぼしが高くつく重要コーパスで最も価値があります。

parent-document（small-to-big）retrievalとは何ですか？

マッチングの仕方と返却する内容を切り離す手法です。正確なマッチングのために小さい子チャンクをインデックスしますが、マッチしたときはモデルに大きな親セクションを渡して周囲のコンテキストを与えます。これにより、どちらも犠牲にせず、小さいチャンクのリコールと大きいチャンクのコヒーレンスを両立できます。

どのチャンキング戦略から始めるべきですか？

約500トークン、オーバーラップ15%のrecursive chunkingです。自然な境界を尊重し、安価で、ほとんどのコンテンツに対する強力なベースラインになります。PDFやマニュアルにはstructure-aware分割を加え、回答にもっとコンテキストが必要ならparent-document retrievalを、追加コストに見合う場合に限ってcontextual retrievalを使いましょう。

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

RAGのチャンキング戦略：サイズ・オーバーラップと実際に効く手法

チャンキングは、検索が動き出す前の段階でRAG品質の上限を決めてしまいます。本ガイドでは実務で主流の6つの戦略を比較し、サイズとオーバーラップの具体的な数値を示し、どのクエリタイプにどの戦略が向くかを解説します。

チャンキングがRAGの品質を左右する理由

チャンクはリトリーバーが実際に取得する単位なので、チャンクの境界が下流処理すべての上限を決めてしまいます。チャンクが小さすぎると各エンベディングのシグナルが足りず、確実に見つけられなくなります。逆に大きすぎると、関連するパッセージのシグナルが平均化されてベクトルが薄まり、クエリとマッチしなくなります。チャンキングを誤ると、どんなリランカーや大きなモデルを使ってもリコールは救えません。正しいパッセージがそもそも検索されていないからです。だからこそ、モデル選びよりも先にチャンキングを調整するのが定石なのです。

実務で主流の6つの戦略

現在の実務は、おおむね6つのアプローチに集約されます。

Fixed-size：オーバーラップ付きの等しいトークン/文字スパン。最も古く、最も安価で、再現性があり、しかも驚くほど強力なベースラインです。
Recursive：境界を尊重しつつサイズ上限に収めるため、セパレータの優先順位（段落 → 行 → 文）で分割します。推奨されるデフォルト。
Semantic：各チャンクが1トピックになるよう、エンベディングの類似度で文をグループ化します。recursiveに対する優位性は安定せず、追加のエンベディング計算コストがかかります。
Structure-aware：文書構造（見出し、セクション、ページ、Markdown）で分割します。PDF、マニュアル、財務資料に最適です。
Late chunking：まず長コンテキストモデルで文書全体をエンベディングし、トークンエンベディングをチャンクへプーリングします。これにより各チャンクがグローバルなコンテキストを保持します。
Contextual retrieval：インデックス作成前に、LLMが生成した短いコンテキスト説明を各チャンクの先頭に付加します。

まずrecursiveから始め、文書やクエリタイプが求める場合に他の戦略へ進みましょう。

チャンクサイズとオーバーラップ：具体的な数値

普遍的に最適なサイズはありませんが、良い出発点はあります。まずは400〜512トークン前後、オーバーラップ10〜20%（500トークンのチャンクで約50〜100トークン）から始めましょう。次にサイズをクエリタイプに合わせます。小さいチャンク（128〜256トークン）は正確な事実やキーワードの検索に向き、大きいチャンク（512〜1024トークン）はナラティブの流れが重要な分析・要約クエリに向きます。

オーバーラップは境界で意味が断ち切られるのを防ぎます。少なすぎるとコンテキストが分断され、多すぎるとインデックスが肥大化して検索結果が重複します。NVIDIAのベンチマークでは、財務資料でオーバーラップ約15%が最適とされ、ページ単位のチャンキングが混合コーパス全体で最も高く一貫した精度を示しました。ファクトイドクエリは256〜512トークン、分析クエリは1024トークン以上でピークに達しています。

応用：contextual retrievalとlate chunking

2つの新しい手法が同じ問題に取り組んでいます。「revenue increased 15%」とだけ書かれたチャンクは、どの会社のどの四半期か判別できなければ役に立ちません。

AnthropicのContextual Retrievalは、エンベディングとBM25インデックスの両方の前に、LLMが生成した50〜100トークンのコンテキストノートを各チャンクに付加します。トップ20の失敗率5.7%というベースラインに対し、contextualエンベディングで失敗を35%、contextual BM25の併用で49%、さらにリランキングの追加で67%削減しました。プロンプトキャッシングを用いて、100万ドキュメントトークンあたり約$1.02のコストです。

Jinaのlate chunkingはパイプラインを逆転させます。長コンテキストモデル（最大約8,192トークン）で文書全体をエンベディングし、コンテキスト化されたトークンエンベディングをチャンクへプーリングするため、各チャンクのエンベディングがあらかじめチャンク間のコンテキストを保持します。長距離の依存関係を持つ長い文書に使いましょう。

親ドキュメント検索とメタデータ

ほぼあらゆる場面で効く2つの工夫があります。Parent-document（"small-to-big"）retrievalは、検索の粒度と生成を切り離します。正確なマッチングのために小さい子チャンク（≈100〜500トークン）をインデックスし、モデルには周囲のコンテキストが得られるよう大きな親セクション（≈500〜2,000トークン）を返します。また、各チャンクにソース、セクション見出し、ページ番号、タイムスタンプを付与するメタデータエンリッチメントは、フィルタリングを改善し、引用を可能にし、チャンクサイズとは独立に検索精度を高めます。

osFoundryでの選択とチューニング

手早い判断の目安：recursiveが安全なデフォルト、構造化された文書にはstructure-awareまたはページ単位、トピックが密な文章にはsemantic、長コンテキストのエンベッダーを使う長い文書にはlate chunking、コンテキストの欠落が大きな損失になる重要コーパスにはcontextual retrieval、精度とコンテキストの両方が必要なときはparent-documentです。

osFoundryはこれらすべてをコードではなく設定として扱います。Auto-chunkingは妥当なrecursiveのデフォルトを備え、カスタムRAGパイプラインではナレッジベースごとにサイズ・オーバーラップ・戦略をチューニングでき、リランキングとparent-document retrievalはパイプラインステージのトグルとして使えます。ステージが設定可能なので、スタックの他の部分を固定したまま、自分のクエリ分布（ファクトイドか分析か）に対してチャンキング設定をA/Bテストできます。これはまさに、研究が推奨するチューナブルパラメータのワークフローそのものです。

Frequently asked questions

RAGに最適なチャンクサイズは？: 普遍的な答えはありませんが、オーバーラップ10〜20%で400〜512トークンが良い出発点です。次にクエリタイプに合わせて調整しましょう。正確な事実検索には128〜256トークン、分析や要約クエリには512〜1024トークンです。単一のデフォルトを当てにするのではなく、自分の質問に対していくつかのサイズをベンチマークしてください。
チャンクのオーバーラップはどのくらいにすべき？: チャンクサイズの10〜20%、500トークンのチャンクで約50〜100トークンです。オーバーラップは境界で意味が断ち切られるのを防ぎます。少なすぎると分割点でコンテキストが分断され、多すぎるとインデックスが肥大化してほぼ重複する検索結果が出ます。NVIDIAは財務資料で約15%が最適だと示しました。
semantic chunkingはfixed-sizeより優れていますか？: 確実とは言えません。semantic chunkingはトピック単位で文をグループ化するため良さそうに思えますが、ベンチマークではrecursiveやfixed-sizeに対する優位性が安定せず、追加のエンベディング計算コストに見合わないことが多いです。fixed-sizeとrecursiveは強力で安価なベースラインであり、まずはそこから始め、評価で実際の改善が確認できたときだけsemanticへ移行しましょう。
late chunkingとは何で、いつ使うべきですか？: late chunkingは、まず長コンテキストのエンベディングモデルで文書全体をエンベディングし、続いてトークンエンベディングをチャンクへプーリングします。そのため各チャンクのベクトルは、自身のテキストだけでなく文書全体のコンテキストを担います。前の文脈がなければパッセージの意味が通らないような、長距離の依存関係を持つ長い文書に使いましょう。
contextual retrievalは本当に精度を上げますか？: はい、測定可能な形で上がります。Anthropicの報告によれば、各チャンクにLLM生成のコンテキストノートを付加することで、contextualエンベディングでトップ20の検索失敗を35%、contextual BM25との併用で49%、リランキングの追加で67%削減しました。プロンプトキャッシングを用いて、100万ドキュメントトークンあたり約$1.02です。パッセージの取りこぼしが高くつく重要コーパスで最も価値があります。
parent-document（small-to-big）retrievalとは何ですか？: マッチングの仕方と返却する内容を切り離す手法です。正確なマッチングのために小さい子チャンクをインデックスしますが、マッチしたときはモデルに大きな親セクションを渡して周囲のコンテキストを与えます。これにより、どちらも犠牲にせず、小さいチャンクのリコールと大きいチャンクのコヒーレンスを両立できます。
どのチャンキング戦略から始めるべきですか？: 約500トークン、オーバーラップ15%のrecursive chunkingです。自然な境界を尊重し、安価で、ほとんどのコンテンツに対する強力なベースラインになります。PDFやマニュアルにはstructure-aware分割を加え、回答にもっとコンテキストが必要ならparent-document retrievalを、追加コストに見合う場合に限ってcontextual retrievalを使いましょう。