RAGチャンク最適化とは?チャンクサイズ・オーバーラップ・分割手法の決め方

RAGチャンク最適化とは、検索拡張生成(RAG)でAIが参照する文書を、意味のまとまりを保ったまま適切な大きさに分割し、各チャンクが単体で読んでも意味が伝わる状態に整える作業です。

RAGは質問に対して文書全体ではなく、関連性の高い一部(チャンク)を検索して回答生成に利用する仕組みです。従来のRAGでは文書を500〜1,000トークン程度の固定長で区切り、オーバーラップを加えてベクトル化する方法が広く使われてきました(出典: arpable.com)。この方式は実装が容易な一方、文や話題の途中で区切られやすく、検索結果の精度低下につながりやすいという課題があります。

最適化の目的は、必要な情報が正しく取得される「検索精度」と、取得した情報から正確な回答が作られる「生成品質」の両方を高めることです。チャンクサイズ・分割方式・見出し設計の3要素を組み合わせて調整するのが基本方針になります。

チャンクサイズに絶対的な正解はなく、256〜1024トークンの範囲で文書やモデルに応じて調整するのが現実的です(出典: qiita.com)。LlamaIndexなどの実験例では1024トークンが品質と効率のバランスに優れるとされ、1トークンは概ね0.75単語または1.5漢字に相当するため、1024トークンは約680漢字が目安になります(出典: qiita.com)。

一方、文字数ベースの実測では異なる結果も出ています。あるAIアシスタントの検証では、チャンクサイズ3000文字(オーバーラップ900文字)としたとき評価データ45件に対する正解率が69%と最も高く、900文字・1500文字では60%、5000文字では67%でした(出典: exa-corp.co.jp)。トークン換算の目安より大きいチャンクが有利になる場合もあるため、必ず自社データで比較検証することが重要です。

また情報源によって元文書の長さは大きく異なり、Googleサイト1ページあたりの平均文字数は1525.1文字(最大23600、最小63)、Slack1スレッドあたり平均529.8文字(最大16490、最小5)というデータもあります(出典: exa-corp.co.jp)。情報源ごとの文字数分布を踏まえてチャンクサイズを設計する視点も欠かせません。なお、Gemini 1.5 ProやGPT-4.1 Miniのように100万トークンのコンテキストウィンドウを持つモデルも登場していますが(出典: qiita.com)、コンテキストウィンドウが大きくても検索精度やコストの観点からチャンク分割の重要性は変わりません。

オーバーラップはチャンクサイズの10〜20%程度を確保するのが一般的な目安で、1024トークンのチャンクであれば100〜200トークン程度が推奨されます(出典: qiita.com)。オーバーラップを入れる目的は、チャンクの境界で文脈が途切れて検索・引用の精度が落ちることを防ぐためです。

実際の運用例として、あるAIアシスタントでは900文字のチャンクサイズに対して100文字のオーバーラップ(比率約11%)を採用していました(出典: exa-corp.co.jp)。これは目安の下限に近い設定であり、文書の性質によって比率を調整する余地があることを示しています。

オーバーラップを増やすほど境界での情報欠落は減りますが、チャンク数とインデックスサイズが増え、埋め込み計算や検索処理のコストも増加します。まずは10〜20%を起点に、検証結果を見ながら微調整するのが実務的な進め方です。

固定長チャンキングとセマンティックチャンキングは一方が常に優れるわけではなく、文書の構造化度と処理コストの許容度に応じて選ぶのが基本方針です。

固定長チャンキングは文字数やトークン数で機械的に区切る方法で、実装が容易な反面、文や話題の途中で分割されやすいという課題があります。従来のRAGでは500〜1,000トークンの固定長分割にオーバーラップを加える方式が広く使われてきました(出典: arpable.com)。

セマンティックチャンキングは文同士の類似度を計算し、話題が変化する箇所で区切る手法です。話題のまとまりを保ちやすく検索精度が高まりやすい一方、埋め込み計算のコストが増えるため、文書量が多い場合は処理時間や費用との兼ね合いが必要になります。

さらに、検索には小さいチャンクを使い、回答生成時には周辺文脈を含む大きな親チャンクを渡す「階層型(親子)チャンキング」という手法もあります。検索精度と文脈の完全性を両立させたい場合に有効な選択肢です。

見出し・表・FAQのような構造を持つ文書は、構造の単位(H2・H3の見出し、表の行、Q&Aのペア)を1チャンクの境界として扱う「構造認識型チャンキング」が基本になります。

見出し単位分割では、H2・H3などの見出しごとに1チャンクを構成し、見出しのテキスト自体を検索キーとして利用します。文書がしっかり構造化されている場合に高い効果を発揮する手法です。

表を分割する際は、行単位で機械的に切ると見出し行(ヘッダー)やキャプションとの対応が失われ、単体では意味が通らなくなる点に注意が必要です。各チャンクに表のタイトルやヘッダー行の情報を含める工夫が有効です。

FAQコンテンツの場合は、1つの質問と回答のペアを1チャンクとして扱うのが基本です。質問文が見出しの役割を果たすため、そのままユーザーの検索質問と類似度が高くなりやすい形式になります。

日本語文書のチャンキングでは、文の境界が英語のピリオドのように明確でない点が最大の注意点です。句読点や改行だけを基準にすると、文の途中や意味的に不自然な位置で区切られることがあり、形態素解析や文単位の判定を組み合わせた分割が有効です。

また、日本語は1トークンあたりの情報量が英語と異なり、1トークンは概ね1.5漢字に相当します(出典: qiita.com)。英語圏の記事で紹介されているトークン数の目安をそのまま流用すると、実際の文字数として意図した分量と食い違うことがあるため、文字数換算で確認する習慣が重要です。

さらに、日本語は指示語や助詞によって前後の文がつながりやすく、文単位で機械的に分割すると「これは」「前述の」といった指示語だけが残り、チャンク単体では意味が通らなくなるリスクがあります。分割後は各チャンクを単独で読んで意味が成立するかを必ず確認する必要があります。

チャンキング手法の良し悪しは、想定される質問文に対してどのチャンクが検索・引用され、その内容が質問に十分に答えられているかという正解率で評価するのが基本です。

具体的には、評価用の質問セットを用意し、各チャンクサイズ・分割方式で検索結果を比較します。ある検証では評価データ45件に対して、チャンクサイズ3000文字(オーバーラップ900文字)で正解率69%、900文字・1500文字で60%、5000文字で67%という結果が出ており、サイズによって精度差が生じることが確認されています(出典: exa-corp.co.jp)。

この手法は人手による確認が基本ですが、AI検索での引用状況を測定できる診断ツールを併用し、実際にどのチャンク単位で引用・参照されているかを定期的に確認する方法もあります。あわせて、チャンク数増加に伴う埋め込み・検索コストの増加も評価軸に含め、精度とコストのトレードオフを踏まえて手法を選定することが重要です。

この記事は次の情報源を参考に、2026年8月時点の情報で作成しています。

・RAGチャンキング最適化｜構造認識と可変長設計【2026年版】 RAGチャンキング最適化｜固定長・可変長・評価まで(arpable.com) ・RAGのチャンキング設計：chunk size/overlapと戦略6選＋LangChainデモ – TechHarmony(blog.usize-tech.com) ・日本語RAGシステムにおけるチャンクサイズとオーバーラップのベストプラクティス #LLM - Qiita(qiita.com) ・Azure 上で RAG ソリューションを開発する - チャンク化のフェーズ - Azure Architecture Center | Microsoft Learn(learn.microsoft.com) ・第7回：RAGの精度、どう改善する？AIアシスタント「たまちゃん」の改善事例 vol.3｜株式会社エクサ(exa-corp.co.jp)