RAGのチャンク分割｜サイズ・オーバーラップの決め方と検証手順

RAGのチャンク分割とは｜検索精度を左右する理由

チャンク分割は、RAGの精度を決める最初の分岐点です。検索にヒットする最小単位がチャンクなので、ここで切り方を誤ると、後段でLLMやプロンプトを工夫しても改善しにくくなります。リランクや親子チャンクで挽回できる余地は残りますが、その分だけ手数が増えます。

チャンクは「検索の単位」であり「文脈の単位」でもある

チャンクには2つの役割が同居しています。ひとつは検索の単位。ベクトル検索は「チャンク1件＝ベクトル1件」で動くため、チャンクの粒度がそのまま検索のヒット粒度になります。もうひとつは文脈の単位です。ヒットしたチャンクがそのままLLMへ渡る以上、チャンク内に答えの根拠が収まっていないと、正しく引いても正しく答えられません。

この2つは引っ張り合う関係にあります。検索の精度だけを見ればチャンクは小さいほうが有利です。1つのベクトルが表す意味が絞られるからです。一方、生成の精度だけを見れば大きいほうが有利になります。両方を同時に最大化する値は存在しません。だからこそ「測って決める」工程が必要になります。

分割を誤ったときに出る2つの壊れ方

症状は、だいたい次の2パターンに分かれます。

前者は、見出しと本文が別チャンクに割れたときによく起きます。後者は、1チャンクに複数の小見出しをまとめ込んだときに出ます。どちらに寄っているかを先に見極めると、調整の方向を間違えません。

優先度の判断も、この見極めとセットになります。検索側の精度が出ていない段階なら、チャンク分割は先に手を付ける価値がある工程です。逆に、検索は当たっているのに回答が崩れている場合は、プロンプト設計や生成側の制御のほうが効きます。どちらのフェーズで落ちているかの切り分けは、RAGの評価方法｜Ragasの評価指標とボトルネック特定・精度改善で扱っています。

チャンク分割の4つの手法と使い分け

分割手法は大きく4つに整理できます。実務では「再帰的文字分割を基本にして、構造が明確な文書だけ構造ベースに切り替える」構成が扱いやすい組み合わせです。

固定長分割｜最も単純で、再現性が高い

決めた文字数またはトークン数で機械的に区切ります。Microsoftのチャンク ドキュメント（Azure AI Search）では、固定長分割の説明例として、意味的にまとまりのあるサイズ（200単語や600文字など）を定め、10〜15%程度の重なりを許容する方法が挙げられています。あくまで例示であり、推奨値として断定されているものではありません。処理が速く、結果がぶれないのが利点です。文の途中で切れることは許容します。

再帰的文字分割｜実務の初期設定になりやすい

区切り文字に優先順位をつけ、上位の区切りで収まらない場合だけ下位に降りる方式です。LangChainのRecursiveCharacterTextSplitterが代表格で、公式ドキュメントによれば既定の区切り順は「空行、改行、空白、文字単位」です。段落をできるだけ壊さずに目標サイズへ寄せられるため、最初に選ばれやすい手法です。

文書構造ベース分割｜見出し・表を手がかりにする

MarkdownやHTMLのように構造タグを持つ文書では、見出し階層で区切ったほうが意味のまとまりを保てます。前出のAzure AI Searchのドキュメントでも、埋め込みマークアップの見出し構文をチャンク境界に使う方法が可変サイズの手法として挙げられています。社内規程やAPI仕様書のように、章立てがそのまま検索単位になる文書と相性が良い方式です。

セマンティック分割｜意味の切れ目で分ける

隣接する文の埋め込み同士の距離を測り、話題が変わった位置で区切ります。LlamaIndexのSemanticSplitterNodeParserは、公式のNode Parserガイドで、breakpoint_percentile_thresholdを95に設定する例が示されています。切れ目の質は高くなりますが、分割時に埋め込み計算が走るぶん前処理コストが増えます。

チャンクサイズの決め方｜起点にする数値と調整の方向

結論として、サイズは「公式が示す初期値から始めて、症状を見て片方向に動かす」のが最短です。最初から最適値を当てにいくと、比較対象がないまま迷走します。

公式ドキュメントが示す出発点

MicrosoftのAzure AI Searchのチャンク ドキュメントは、2つの初期値を提示しています。トークンベースでは512トークン（約2,000文字）とその25%にあたる128トークンの重複。文字数ベースで組み込みのテキスト分割スキルを使う場合は、最大ページ長2,000文字・ページ重複500文字です。

Pineconeのチャンク戦略ガイドでは、128・256・512・1024トークンの各水準でクエリを流して比較する検証方法が紹介されています。この4水準は比較設計の出発点として使えますが、埋め込みモデルの上限や文書の長さによっては1024が入らない、128では短すぎるといったケースもあります。自分の条件に合う3水準を選んでください。

なお、同じAzureのドキュメント内でも、固定サイズ手法の一般的な説明では「10から15%」の重なりに言及があり、重複の考慮事項の節では25%が初期値として書かれています。公式ドキュメントの中でも幅があるという前提で読み、自分のデータで詰めるのが正しい扱い方です。

フレームワーク側の既定値も参考になります。LlamaIndexの公式ガイドでは、SentenceSplitterの設定例としてchunk_size=1024・chunk_overlap=20、階層的な分割を行うHierarchicalNodeParserの例として2048・512・128の3階層が示されています。重複20文字という数値からわかるとおり、フレームワークの例示値は「とりあえず動く値」であって、推奨値ではありません。

日本語で踏みやすい「トークン上限」の罠

ここは日本語でRAGを組むときに事故が集中する箇所です。原則として、英語圏のドキュメントが前提にする「1トークン＝約4文字」という換算は日本語では成り立ちません。Azureのドキュメントが示す4文字換算も英語前提の数値です。日本語は1トークンあたりの文字数が英語より少なくなるため、同じ文字数でもトークン数は膨らみます。

影響が大きいのは、埋め込みモデル側の最大入力長です。text-embedding-3-smallの最大入力は8,191トークンあるため、2,000文字程度のチャンクなら余裕があります。一方、multilingual-e5-largeのモデルカードには「長いテキストは最大512トークンに切り詰められる」と明記されています。切り詰めはエラーにならず、黙って起きます。

つまり、LlamaIndexの例示値である1024をそのまま使い、埋め込みにmultilingual-e5系を選ぶと、チャンクの後半が埋め込みに反映されないまま動く状態になります。検索結果の表示には後半も出るため、気づきにくい不具合です。使う埋め込みモデルの最大入力長を先に確認し、そのうえでトークナイザで実測してからサイズを決めてください。

管理の単位も整理しておきます。埋め込みモデルの上限がトークンで定義されている以上、最終的にはトークンで管理するほうが安全です。ただし日本語文書は文字数のほうが設計時の見通しが立ちます。文字数で設計し、トークン数で上限を検算する。この二段構えが実務では扱いやすい進め方です。

オーバーラップ（重複）の決め方

オーバーラップは、隣り合うチャンクの境界で文脈が切れるのを防ぐための保険です。入れすぎるとインデックスが膨らみ、同じ内容が重複ヒットします。

推奨される割合と上限

目安はチャンクサイズの10〜25%です。Azure AI Searchのドキュメントでは512トークンに対して128トークン（25%）が初期値として示される一方、固定サイズ手法の説明では10〜15%にも言及があります。上限については、組み込みのテキスト分割スキルの仕様として「ページ重複は最大ページ長の半分以下にする必要がある」と明記されています。

重複を厚くしたほうがよいのは、話が前後に連続する文書です。議事録、インタビュー、物語性のある記述などが該当します。逆に、1項目が独立しているFAQや製品スペック表では、重複はほぼ不要です。同ドキュメントでも、構造化の度合いが高いデータは重複が少なくて済み、会話や物語的なテキストはより多くの恩恵を受けうる、という整理がされています。

重複を増やすとインデックスはどれだけ膨らむか

ここは感覚ではなく実測値で把握しておくと見積もりが早くなります。Azure AI Searchのドキュメントには、200ページのPDF（NASAの電子書籍）を同じ条件で分割したときのチャンク総数が掲載されています。

20%の重複でチャンク数が約1.26倍、25%で約1.33倍。この比率は、埋め込みAPIの呼び出し回数とベクトルDBの保存件数にほぼそのまま乗ります。小規模な検証では無視できますが、数万件規模の文書を扱う案件では初期見積もりに含めておくべき係数です。保存先ごとのコスト構造はベクトルDBの選び方｜Pinecone・Weaviate・Qdrant・pgvectorの使い分けで比較しています。

文書タイプ別のチャンク設計早見表

文書の性質が決まれば、初期値の当たりはかなり絞れます。以下は、前述の公式ドキュメントの推奨値を出発点に、文書タイプごとの方針を整理したものです。数値はあくまで初期設定であり、評価セットで動かす前提で使ってください。

表の中で共通している点がひとつあります。チャンク単体で読んでも何の話か分かる状態にすること。条番号、見出し、質問文のように「そのチャンクを特定する情報」が落ちていると、検索でも生成でも不利になります。

サイズ調整で解決しないときの打ち手

サイズと重複を2〜3水準動かしても精度が横ばいなら、分割の粒度ではなく設計そのものを変える段階です。主な選択肢は3つあります。

親子チャンク｜小さく引いて大きく渡す

検索は小さいチャンクで行い、ヒットしたら親の大きいチャンクをLLMへ渡す方式です。冒頭で触れた「検索は小さいほうが有利、生成は大きいほうが有利」という矛盾を、分けることで回避します。LlamaIndexのHierarchicalNodeParserが2048・512・128の階層例を示しているのは、この考え方に沿った構成です。実装の手間は増えますが、サイズ調整が行き詰まったときの効果は比較的読みやすい手法です。

チャンクに文脈を付与する

チャンクの先頭に、その断片が文書全体のどこに位置するかを説明する短い文を足してから埋め込む方法です。Anthropicが公開したContextual Retrievalの記事では、この手法を適用した場合の検索失敗率（1 minus recall@20）が5.7%から3.7%へ、全文検索（BM25）を併用すると2.9%へ、さらにリランクを加えると1.9%へ下がったという測定結果が示されています。同記事では、チャンクは通常数百トークン以下にとどめること、実験では800トークンのチャンクを用いたことにも触れられています。

複数の知識領域と複数の埋め込みモデルで測った結果であり、自分のデータで同じ改善幅が出るとは限りません。ただし「チャンクを切った時点で失われた文脈を、埋め込み前に足し戻す」という考え方自体は、文書タイプを問わず再現しやすいものです。

メタデータを付けて絞り込む

部署、年度、文書種別、バージョンといった属性をチャンクに持たせ、検索時にフィルタをかけます。チャンクの中身をいじらずに母集団を減らせるため、文書量が多い案件では費用対効果が高い打ち手です。文脈の渡し方全般の設計はコンテキストエンジニアリングとは｜プロンプトとの違いと実務で整理しています。また、根拠が引けていても誤答が残る場合はハルシネーション対策｜LLMの誤回答を減らす実装と運用設計側の論点になります。

チャンク設計の検証手順とよくある失敗

チャンク設計は、測らずに決めると必ず主観の勝負になります。検証の型を先に決めておくと、2〜3日で結論まで持っていけます。

評価セットは何問から始めるか

30〜50問を目安に用意します。これは公的な基準値ではなく、サイズ水準間の差を読み取るための実務上の下限として置いている数字です。統計的な有意差を論じる規模ではなく、「どちらの方向に動かすか」を判断するための最小構成だと考えてください。この規模なら、実データの想定質問を集めて半日から1日で作れます。チャンクサイズの優劣を見るだけなら、網羅性より「設問のばらつき」を優先します。単一チャンクで答えられる問い、複数チャンクの横断が必要な問い、記載がないことを確認させる問いを混ぜると、サイズ変更の影響が出やすくなります。評価セットの作り方と指標の詳細は、評価側の記事に譲ります。

比較する水準と打ち切りの決め方

比較は2〜3水準に絞ります。Pineconeのガイドが示す128・256・512・1024の4水準から、自分の文書タイプに近い3つを選ぶのが手早い進め方です。1水準ごとにインデックスの再構築が必要になるため、水準を増やすほど待ち時間とAPI費用が線形に増えます。

打ち切りの基準も先に決めておきます。3水準試して差が誤差範囲なら、サイズはそれ以上触らず、前章の打ち手に移ります。サイズ調整だけで粘り続けるのが、この工程で最も時間を溶かすパターンです。

フリーランス案件でチャンク設計はどう見られるか

結論として、チャンク設計そのものを単独スキルとして募集する案件は多くありません。実際には、RAG構築案件の中の一工程として扱われます。ただし面談では「精度が出なかったときに何を試したか」を具体的に聞かれる場面があり、サイズと重複を何水準・どの評価セットで比較したかを数字で説明できると、検証の進め方を持っている人という伝わり方をします。

スキルシートに書く場合は、手法名の列挙より「対象文書の種類・件数規模・どの指標がどう動いたか」を1〜2行で添えるほうが伝わります。RAG案件そのものの単価水準や参画ルートについてはRAG構築案件の実情｜単価相場・必要スキル・獲得方法で扱っているため、ここでは重ねません。

自分のスキルセットでどの程度の単価を狙えるか確認したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。実際の募集条件を見たいときはフリコンの案件一覧から確認してください。

まとめ

チャンク分割は「初期値を公式ドキュメントから借りて、評価セットで2〜3水準だけ動かし、頭打ちになったら設計を変える」という進め方が、実務では着地させやすい型です。サイズの最適値を探し続ける工程ではありません。

• 文字数ベースは2,000文字・重複500文字、トークンベースは512トークン・重複25%が公式の出発点

• オーバーラップはサイズの10〜25%。上限はサイズの半分以下

• 日本語では英語前提のトークン換算が崩れる。multilingual-e5系の512トークン上限のような切り捨てに注意する

• 文書タイプが構造を持つなら、サイズ調整より構造ベース分割のほうが効く

• 重複20〜25%でチャンク数は約1.26〜1.33倍。大規模案件では見積もりに含める

• 2〜3水準試して差が出なければ、親子チャンク・文脈付与・メタデータ絞り込みへ切り替える

次に進むなら、評価の型を固めるところからです。何を指標に測るかが決まっていないと、どの水準が良かったのかを判断できません。RAGの評価方法｜Ragasの評価指標とボトルネック特定・精度改善で指標とボトルネック特定の手順を確認してから、本記事の検証手順に戻ると効率的です。

本記事で挙げた数値は、いずれも執筆時点で各公式ドキュメントから確認できるものです。LangChain・LlamaIndexの既定値や引数名、埋め込みモデルの最大入力長は更新されるため、実装前に公式ドキュメントで現行の仕様を確認してください。

参照した一次情報は以下のとおりです。

• チャンク ドキュメント - Azure AI Search（Microsoft Learn）

• Introducing Contextual Retrieval（Anthropic）

• Splitting recursively（LangChain 公式ドキュメント）

• Node Parser Modules（LlamaIndex 公式ドキュメント）

• Chunking Strategies for LLM Applications（Pinecone）

• multilingual-e5-large モデルカード（Hugging Face）