RAGの回答精度を上げるチャンキング手法｜文書分割で結果はこれだけ変わる
RAGの精度が伸びない原因、実は「分割の仕方」かもしれません
「RAGを社内に入れたが、思ったほど賢く感じない」「同じドキュメントを根拠に、ある質問には鋭く答えるのに、別の質問には文脈が抜け落ちた的外れな答えを返す」「LLMを最新モデルに差し替えても、回答品質が頭打ちのまま伸びない」——RAGを運用に乗せ始めた現場で、よく聞く悩みです。
精度が頭打ちになると、現場の関心はまずLLMの性能、次にベクトルデータベースの精度、最後にプロンプトの書き方へと向きがちです。けれども、回答品質を真に左右しているのは、その手前にある地味な工程——**チャンキング（文書をどう分割するか）**であるケースが、実務では非常に多いのです。同じ文書、同じLLM、同じプロンプトでも、分割の仕方を変えるだけで回答品質ががらりと変わる——これがRAGの面白さでもあり、難しさでもあります。
分割が雑になるのは、実装者の力不足ではありません
最初に申し上げておきたいのは、RAGのチャンキングが雑になっているのは、実装したエンジニアの技量不足ではなく、多くの導入プロジェクトで「最初の動くものを作る」段階でチャンキングの議論が後回しにされるという、構造的な事情があるからです。
PoC段階では、ライブラリのデフォルト設定（たとえばLangChainのRecursiveCharacterTextSplitterで1000文字／オーバーラップ200）で十分動いてしまいます。動いた瞬間にステークホルダーに見せたい誘惑も強く、「チャンキングはそのうち詰めよう」と先送りされたまま本番に乗ります。ところが本番では、想定外の文書形式、想定外の質問、想定外の利用頻度が押し寄せ、デフォルト設定の限界がじわじわ顕在化します。これは初期実装の責任ではなく、チャンキング設計はそもそも、自社文書と自社の質問パターンを観察してから本格チューニングする領域だからです。逆に言えば、観察→改善のループに乗せれば、回答精度はまだ大きく伸ばせます。
この記事は「チャンキング手法の地図と選び方」をまとめます
そこでこの記事では、RAGの回答精度を一段引き上げるために、まず手をつけるべきチャンキング手法を地図として整理します。固定長分割・センテンス／パラグラフ分割・セマンティック分割・階層的分割・親子チャンクといった代表的な手法を、特性・向き不向き・実装難度の3軸で並べ、自社の文書構造と質問パターンに合わせた選び方の判断軸を提示します。
あわせて、チャンクサイズ・オーバーラップ・メタデータ付与といった実装上のチューニングポイント、改善ループの回し方も整理します。読み終える頃には、「次の改善で、自社のチャンキングをどう触るか」が、具体的なアクションとして見えている状態を目指します。
代表的なチャンキング手法を地図として整理する
代表的なチャンキング手法5つと、それぞれの特性
ここからが本題です。RAGの実務でよく使われるチャンキング手法を、特性とともに整理します。
手法1：固定長分割（Fixed-size Chunking）
最も基本的で、PoCではほぼ全てがここから始まる手法です。文字数あるいはトークン数で機械的に区切ります。たとえば「1000文字ごとに区切り、前後200文字をオーバーラップさせる」のが定番の設定です。
メリットは、(a) 実装が極めて簡単、(b) 文書形式を問わない、(c) チャンク長が揃うのでベクトル検索との相性が良い、ことです。落とし穴は、(d) 文の途中、段落の途中、表の途中で機械的に切れてしまい、文脈が壊れる、(e) 長い手順書や法令文書のように「前後の繋がりが重要」な文書で精度が伸びにくい、点です。
向くのは、文書がそもそも短い・均質なケース、あるいはPoCの初手としてベースラインを取りたい場面です。本番で精度が頭打ちになった場合は、他手法への置き換えが第一の検討対象になります。
手法2：センテンス／パラグラフ分割（Structure-aware Chunking）
文書の自然な区切り、つまり文・段落・見出しを尊重して分割する手法です。Markdownの#や##、HTMLのタグ、改行2つ以上などの構造手がかりを利用します。
メリットは、(a) 意味的なまとまりを壊しにくい、(b) 既存ドキュメントが構造化されていれば実装も容易、(c) 表・コードブロックを単独チャンクとして扱える、ことです。落とし穴は、(d) チャンク長が不揃いになり、短すぎる断片や長すぎる塊が混在する、(e) 構造化されていない平文では効きが弱い、点です。
向くのは、社内Wiki、Markdown化されたマニュアル、HTML資料など、もともと構造的に書かれている文書を扱うケースです。固定長分割からの最初のアップグレード候補として、効果が見えやすい選択肢です。
手法3：セマンティック分割（Semantic Chunking）
文の埋め込みベクトル（embeddings）を計算し、意味的な類似度の変化点を境目として区切る手法です。隣り合う文同士のベクトルが大きく離れた地点を「話題の切り替わり」と判定して分割します。
メリットは、(a) 構造化されていない平文でも意味のまとまりを捉えられる、(b) 不要なオーバーラップを減らせる、(c) 話題ごとに整ったチャンクができる、ことです。落とし穴は、(d) 埋め込み計算と類似度判定のコスト・実装難度が上がる、(e) ハイパーパラメータ（類似度の閾値など）のチューニングが必要、(f) 短い文書ではメリットが見えづらい、点です。
向くのは、議事録、インタビューログ、長文の調査資料など、意味的な切れ目はあるが構造的な見出しが乏しい文書です。RAGの精度を「もう一段上げたい」段階で、検討に値する強力な選択肢になります。
手法4：階層的分割（Hierarchical Chunking）
長文ドキュメントを、章→節→段落→文のような階層構造として捉え、複数の粒度のチャンクを同時に持っておく手法です。検索時に、まず粗い粒度で関連箇所を絞り、必要に応じて細かい粒度に降りていきます。
メリットは、(a) 全体の見通しと詳細の両方を、状況に応じて提示できる、(b) 長文ドキュメント（規程集、技術仕様書など）に強い、(c) 「総論を聞きたい」「具体的な数値を聞きたい」の両方の質問に対応しやすい、ことです。落とし穴は、(d) インデックスのデータ量が増える、(e) 検索フローの設計が複雑になる、点です。
向くのは、長くて階層的な構造を持つ重要文書（社内規程、製品仕様書、契約書テンプレ集）が中心の用途です。
手法5：親子チャンク（Parent-Child Chunking）
検索のためには小さなチャンクを使い（精度の高い類似度判定）、LLMに渡すためには対応する**親（より大きな塊）**を渡す、という二段構えの手法です。「小さくして当てる、大きくして渡す」の発想で、ベクトル検索と文脈保持を両立させます。
メリットは、(a) 検索のヒット精度を保ちつつ、生成時の文脈不足を緩和できる、(b) 階層的分割ほど複雑ではない、(c) 多くの主要フレームワーク（LangChain、LlamaIndex等）が対応している、ことです。落とし穴は、(d) インデックス管理がやや複雑、(e) 親チャンクが大きすぎるとLLMのコンテキスト圧迫やコスト増を招く、点です。
向くのは、固定長分割で精度の頭打ちを感じ、かつ階層的分割まではコストをかけたくない場面の中間解として、極めて実務的な選択肢になります。
自社RAGに合うチャンキングを選ぶための3つの判断軸
5つの手法を眺めただけでは選びきれないので、選定のための3つの判断軸を提示します。
判断軸1：文書構造（構造化されているか／平文か）
第一の軸は、自社のメイン文書がどれだけ構造化されているかです。Markdown化された社内Wiki、見出し付きの仕様書、表が整理されたPDFなどであれば、まずセンテンス／パラグラフ分割が第一候補。一方、議事録、インタビュー、長文レポートなど構造手がかりが乏しい文書が中心であれば、セマンティック分割の検討価値が上がります。
判断軸2：質問の粒度（要約系か／詳細系か）
第二の軸は、社員から飛んでくる質問の粒度です。「○○制度の全体像を教えて」のような要約系が多いなら、階層的分割の上位粒度や、親子チャンクの親側の活用が効きます。「○○の手数料はいくら？」のような具体値の問い合わせが多いなら、細かい粒度のチャンクと精度の高い類似度検索が重要で、セマンティック分割や親子チャンクの子側の調整が効きます。両方が混在するなら、親子チャンクや階層的分割の検討価値が一段上がります。
判断軸3：実装・運用コストの許容度
第三の軸は、現実的な実装・運用コストの許容度です。社内に専任エンジニアがいないなら、固定長＋構造意識のシンプル構成から始め、改善ループでチューニングを進める形が無理がありません。専任が確保できるなら、セマンティック分割や親子チャンクへの段階的な進化が、回答精度を一段引き上げる確かな投資になります。
この判断軸を一人で抱え込まずに進めるなら、業務文書の特性とLLM側の挙動の両方を見渡せるパートナーと一緒に整理するのも有効です。生成AIの活用設計から実装・運用までを伴走する アトリエ・バイナリ（atelier binary） のような取り組みでは、まさにこのチャンキング選定と改善ループの初期設計に重きを置いています。
3つの判断軸でチャンキング手法を選び込む
チャンクサイズ・オーバーラップ・メタデータ——必ず触る3つのつまみ
手法を選んだら、次は具体的なチューニングです。回答精度に直結する3つの「つまみ」を押さえます。
第一に、チャンクサイズ。一般的な目安はLLMのコンテキスト長に対して十分余裕を持たせつつ、検索の粒度として意味のあるサイズに収めることで、日本語のドキュメントでは300〜800文字程度が出発点としてよく使われます。短すぎると文脈が不足、長すぎると検索ヒットの解像度が下がります。
第二に、オーバーラップ。チャンク同士の前後を一定量重ねることで、文の途中で切れた場合のリカバリーや、文脈の連続性を担保します。チャンクサイズの10〜20%程度から試すのが目安です。多すぎるとインデックスが冗長になり、コストとノイズが増えます。
第三に、メタデータ付与。チャンクに「文書タイトル」「章節」「更新日」「カテゴリ」「対象部門」などのメタ情報を付け、検索時のフィルタや、生成時のプロンプトへの注入に使います。これが入っているかどうかで、同じチャンキング手法でも回答精度に体感できる差が出ます。
3つのつまみを動かしながら、典型質問20〜30問を用意した評価セットで正解／不正解を採点していくのが、改善ループの基本動作です。LLMを最新版にする前に、まずチャンキングのチューニングで何点取れるかを観察してから、モデル差し替えの是非を判断する——この順番が、最もコスト効率の良い精度改善の進め方です。
こんな立場の方に、このチャンキング設計をおすすめします
- 自社RAGを運用に乗せ始めたが、回答精度が頭打ちで、次にどこを触れば伸びるのか判断がつかないAIエンジニア・データエンジニアの方
- ベンダーから「LLMをアップグレードしませんか」と提案されているが、その前にもっとコストの低い改善余地があるのではと感じているDX推進担当・情シスの方
- これからRAG導入を本格化するにあたり、PoCのデフォルト設定で本番に乗せてしまわないよう、選定軸を最初から押さえておきたい意思決定者の方
チャンキングの見直しは、RAGの全工程の中で最もコスト対効果が高い改善領域のひとつです。モデル差し替えや大規模な再学習に比べ、実装変更とインデックス再構築だけで効果が見える上、改善ループの中で自社固有のノウハウとして残ります。回答品質に違和感を覚えた今このタイミングが、最も着手しやすい時期です。
まとめ
チャンキング改善ループが回るRAG運用
RAGの回答精度を一段引き上げる最大のレバーは、LLMの差し替えでもベクトルDBの選定でもなく、チャンキング設計にあります。固定長分割・センテンス／パラグラフ分割・セマンティック分割・階層的分割・親子チャンクという5つの代表手法を、文書構造・質問粒度・実装コストの3軸で選び分け、チャンクサイズ・オーバーラップ・メタデータの3つのつまみを評価セットで観察しながら動かしていく——この地道なループこそが、自社RAGを実務インフラに育てる中核作業です。
完璧な初期設定を狙う必要はありません。PoCのデフォルト設定で動かしてベースラインを取り、典型質問20〜30問の評価セットで現状スコアを把握し、5つの手法のうち最も自社文書に合うものへ段階的に移行する——この順番で進めれば、RAGはモデル差し替えに頼らず、半年で見違える精度に育っていきます。
まずは、自社RAGに対して飛んでくる典型的な質問を10個、ノートに書き出してみてください。次に、そのうち回答が弱い質問を3つ選び、根拠として引かれたチャンクを実際に確認してみてください。多くの場合、「文の途中で切れている」「前後の文脈が抜けている」「関連文書が引かれていない」といった、チャンキング起因の問題が見つかります。そこから1点ずつ手を入れていく——それが、RAGの精度を着実に底上げする、最も実用的な最初の一歩です。
