RAGチャンキング最適化｜構造認識と可変長設計【2026年版】

---

2026年のRAGチャンキングは、「何文字で切るか」から「文書構造をどう読み、どの知識単位に再編成するか」へ軸足が移った段階である。

多くの企業で、「検索結果は一見正しいのに、LLMの回答だけが微妙に外れる」原因は、固定長チャンキングが見出し・条文・表・FAQ・コードの意味境界を壊しているところにある。

本記事は、構造認識型・可変長チャンキングを中心に、固定長、Recursive、Semantic、Parent-Child、Late Chunking、RAPTOR、GraphRAG連携までを実務判断できる形で整理するガイドである。

何が変わったのか

チャンキングは固定長分割から、文書構造を読んだ可変長の知識設計へ変化している。

かつてのRAGでは、文書を500〜1,000トークン程度に固定長で切り、少しオーバーラップを入れてベクトル化する方法がよく使われていました。PoCではこの方法でも十分に見えることがあります。しかし、本番運用に近づくほど、固定長チャンキングの限界が見えてきます。

たとえば、見出しと本文が別々のチャンクに分かれる。表のタイトルと表本体が分離する。FAQの質問と回答が切り離される。手順書の前提条件と操作手順が別チャンクになる。規程文書の条文と例外条件が分断される。コードと説明文が別々に検索される。

このような状態では、EmbeddingモデルやVector DBを高性能化しても、検索対象となる知識単位そのものが壊れています。RAGの回答が不安定になる原因は、LLMだけではありません。何を1単位として検索・生成に渡すかが、回答品質の土台を決めます。

RAG全体の設計や導入ロードマップは、まず RAG完全ガイド を参照してください。本記事では、その中でも「チャンキング手法」に絞って、実務でどう選ぶべきかを整理します。

固定長チャンキングから構造認識型チャンキングへ

ここで重要なのは、固定長チャンキングを否定することではありません。固定長＋オーバーラップは、今でもベースラインとして有効です。ただし、それだけで本番品質まで持っていくのは難しくなっています。まず固定長で基準値を測り、文書構造に合わせて段階的に高度化する、という進め方が現実的です。

なぜ今重要なのか

RAGの精度は、Embeddingの前に「何を1単位として埋め込むか」で大きく変わる。

RAGの改善でよくある誤解は、検索精度をEmbeddingモデルやVector DBだけで語ってしまうことです。もちろんEmbeddingや検索基盤は重要です。しかし、その前に「どのテキストを1つの意味単位として埋め込むか」が決まっていなければ、検索の前提が崩れます。

たとえば、次のような文書を考えてみます。

この文章を途中で切ると、「標準プランで利用できます」だけが検索され、「ただし」以降の重要な例外条件が抜ける可能性があります。RAGでは、このような境界の誤りが回答の誤りに直結します。

つまり、チャンキングは単なる前処理ではありません。検索可能な知識単位を設計する工程です。RAGの精度改善を考えるなら、EmbeddingやRerankerの前に、チャンクの粒度と意味境界を見直す必要があります。

チャンキングの3つのジレンマ

チャンキングには、避けられない3つのジレンマがあります。

このため、万能なチャンクサイズはありません。文書タイプ、質問タイプ、Embeddingモデル、検索方式、Reranker、LLMのコンテキスト長によって最適解は変わります。

RAGの精度が出ない原因全体を確認したい場合は、RAG精度改善ガイド を参照してください。本記事は、その中の「チャンク設計」に特化した実装判断ガイドです。

どう捉えるべきか

チャンキングは文字数調整ではなく、文書を検索可能な知識単位へ再構成する工程である。

RAGチャンキングを正しく理解するには、まず「前工程」と「主題」を分ける必要があります。

チャンキング以前には、PDF、Word、HTML、Excel、画像、議事録などから文字列や表、見出し、ページ番号、日付、版数、権限情報を抽出する工程があります。ここが壊れていると、どれだけ高度なチャンキングをしても品質は上がりません。

ただし、本記事の主題はETLやOCRではありません。ここでは、正しく抽出・構造化された文書を前提に、どの粒度で、どの手法で、どんなメタデータを持たせてチャンク化するかを扱います。

チャンキング以前に確認すべき前提

以下の項目が崩れている場合、チャンキングの前にデータ抽出・構造化工程へ戻るべきです。

この前提を確認したうえで、チャンキングに進みます。チャンキングは「壊れたデータを直す魔法」ではなく、構造化された文書を検索可能な知識単位へ再編成する工程です。

チャンキングの基本モデル

実務では、次の順番で考えると迷いにくくなります。

1. 文書タイプを判定する：FAQ、マニュアル、規程、契約書、論文、コード、議事録など。
2. 意味の最小単位を決める：質問＋回答、手順＋注意点、条文＋例外、表＋注釈など。
3. 検索用の粒度を決める：小さく取りたいのか、文脈ごと取りたいのか。
4. 回答用の文脈を決める：検索で当たったチャンクの周辺、親チャンク、見出し階層を渡すか。
5. メタデータを付ける：文書名、章、ページ、日付、版数、権限、親IDなど。
6. 評価する：Context Precision / Recall、Faithfulness、Answer Relevancyで比較する。

チャンキングの本質は、切ることではなく、検索・生成で再利用できる知識単位を設計することです。

実務ではどう判断するか

最初は固定長を基準にし、文書構造と失敗症状に応じて段階的に高度化するべきである。

チャンキング手法は多くありますが、すべてを最初から導入する必要はありません。実務では、まずシンプルなベースラインを作り、評価結果を見ながら必要な手法だけを追加します。

代表的なチャンキング手法

Semantic Chunkingを過信しない

Semantic Chunkingは「意味で切る」ため直感的には優れて見えます。しかし、実務では常に最良とは限りません。公開ベンチマークの一例では、Semantic Chunkingが平均43トークン程度の細かすぎる断片を生成し、Recursive分割より低い精度にとどまったケースも報告されています。

この結果を一般化しすぎるべきではありませんが、少なくとも 「Semanticだから常に高精度」ではない ことは押さえるべきです。Semantic Chunkingは、トピックが極端に混在する文書や、明確な意味境界が重要な文書で試す価値があります。一方で、標準的な業務文書では、RecursiveやHeader-based、Parent-Childの方が安定する場合もあります。

文書タイプ別の実務判断

チャンキング手法は、文書タイプでかなり変わります。以下は、実務での初期判断表です。

ミニストーリー：社内ポリシーQ&Aボットの場合

たとえば、社内規程とFAQを混在させた「社内ポリシーQ&Aボット」を考えてみます。

規程PDFは条文＋ただし書きをParent-Childでまとめ、FAQは質問＋回答で1チャンクにするだけで、「標準プランで利用できます」だけがヒットして例外条件を落とす、といった典型的な事故の多くは防げます。

同じRAG基盤でも、チャンキング設計を変えるだけで「検索は当たっているのに回答がズレる」状態から、監査で説明可能な回答へ近づけます。CxOやPMが見るべきなのは、モデル名ではなく、どの文書構造をどの知識単位として検索対象にしているかです。

最小コード：構造認識型・可変長チャンキング

以下は、構造認識型チャンキングの最小例です。ポイントは、単純に文字数で切るのではなく、段落、改行、句点、読点、空白の順に分割候補を試すことです。この例では文字数ベースで512前後を目安にし、約15%のオーバーラップで前後文脈を保つ設定にしています。トークン数ベースで制御したい場合は、利用するトークナイザーに合わせて length_function を指定してください。

from langchain_text_splitters import RecursiveCharacterTextSplitter

# 日本語の文章構造を考慮し、改行・句読点で段階的に切り分ける
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=80,
    separators=["\n\n", "\n", "。", "、", " "],
)

chunks = text_splitter.split_documents(documents)

for i, chunk in enumerate(chunks):
    chunk.metadata["chunk_index"] = i
    chunk.metadata["section"] = chunk.metadata.get("section", "unknown")
    chunk.metadata["source"] = chunk.metadata.get("source", "unknown")

このコードは完成形ではありません。実務では、PDF、HTML、Markdown、Excelなどの抽出段階で付与したメタデータを引き継ぐ必要があります。chunk_index、section、source、page_number、updated_at、version、access_role などは、検索結果のフィルタリング、引用表示、監査対応に効きます。

メタデータ設計：チャンクに必ず持たせたい情報

チャンキングでは、テキスト本文だけでなくメタデータ設計が重要です。メタデータがないと、最新版だけを検索する、特定部署の文書だけを検索する、引用元を表示する、権限に応じて検索対象を制御する、といった運用が難しくなります。

評価設計：チャンキング手法は比較して決める

チャンキング手法は、理屈だけでは決まりません。同じデータ、同じ質問セット、同じEmbeddingモデル、同じLLMで比較し、どの手法が最も安定するかを確認します。

比較対象：
A. 固定長 512 chars / overlap 80
B. Recursive splitter
C. Parent-child chunking

評価指標：
- Context Precision：検索結果にノイズが少ないか
- Context Recall：必要な根拠を取りこぼしていないか
- Faithfulness：回答が取得根拠に忠実か
- Answer Relevancy：質問意図に合った回答か

判断：
検索漏れが多い → Context Recallを確認
ノイズが多い → Context Precisionを確認
回答が根拠から逸脱する → Faithfulnessを確認
回答が質問に噛み合わない → Answer Relevancyを確認

Ragasなどの評価フレームワークを使う場合も、チャンキングだけを単独で見るのではなく、検索結果と生成回答の両方を確認します。評価の詳細は、RAG精度改善ガイドで扱ったように、検索品質と回答品質を分けて測ることが重要です。

一次情報からどこまで言えるか

一次情報から言えるのは、万能手法ではなく、文書構造と評価に基づく選択が重要ということです。

LangChainのText Splittersでは、多くの用途でRecursiveCharacterTextSplitterから始めることが推奨されています。これは、文脈をなるべく保ちながらチャンクサイズを管理する現実的なベースラインです。

Jina AIのLate Chunkingは、8K以上の長文コンテキストに対応した埋め込みモデルを使い、まず全文を1度だけエンコードして全トークンのベクトル列を得てから、その上で小さいセグメントごとに平均プーリングなどでチャンク埋め込みを生成する手法です。これにより、各チャンクが局所テキストだけでなく文書全体のコンテキストを反映しやすくなります。

RAPTORは、チャンクを再帰的にEmbedding、クラスタリング、要約し、文書の階層的な木構造を作る手法です。長大な文書や、抽象度の異なる質問に対応したい場合に検討できます。

Microsoft GraphRAGでは、まずIndexフェーズで入力テキストをTextUnitに分割し、その単位からEntities、Relationships、Claimsを抽出して知識グラフとコミュニティ階層を構築します。そのうえでQueryフェーズでは、グローバルサマリーやローカルな近傍ノードからコンテキストを組み立てます。

GraphRAGはチャンキングの先にある構造化手段

GraphRAGは、通常のチャンキングの代替ではありません。むしろ、チャンキングやTextUnitを前提として、その中から人物、組織、製品、案件、概念などの関係性を抽出し、文書横断の知識構造へ発展させる手段です。

単一文書内の文脈分断はチャンキングで直し、複数文書をまたぐ関係性はGraphRAGで扱う、という切り分けが実務では分かりやすいです。

GraphRAGの詳細は、別途 GraphRAG / Knowledge Graph記事 で深掘りするのが適切です。本記事では、GraphRAGを「チャンキングの先にある文書横断の構造化手段」として位置づけます。

よくある失敗

チャンキングの失敗は、検索結果のノイズ、根拠不足、引用ミス、回答の不安定さとして現れる。

RAGのチャンキングでよくある失敗は、手法選定そのものよりも、文書構造を壊してしまうことです。

特に注意したいのは、「短く切れば検索精度が上がる」と単純に考えることです。検索ヒットの粒度は細かくなりますが、回答に必要な文脈が不足することがあります。逆に、長く切りすぎるとノイズが増えます。チャンキングは、常に検索精度と回答文脈のバランスで考える必要があります。

まとめ

チャンキング最適化の本質は、構造を読み、意味単位で切り、評価で改善することである。

RAGチャンキング最適化とは、文書を一定文字数で切る作業ではありません。正しく抽出・構造化された文書を、検索と生成に適した知識単位へ再編成する設計です。

実務では、まず固定長＋オーバーラップでベースラインを作り、次にRecursiveやHeader-basedで構造を反映します。そのうえで、文脈不足が目立つ場合はParent-Child、代名詞や前後文脈が重要な場合はLate Chunking、長大文書や抽象度の異なる質問にはRAPTOR、文書横断の関係性にはGraphRAGを検討します。

最も重要なのは、万能なチャンクサイズを探すことではなく、自社の文書タイプと質問タイプに合わせて、チャンキング手法を評価しながら選ぶことです。

専門用語まとめ

チャンキング

文書を検索・生成に使いやすい単位へ分割・再構成する工程。RAGでは、回答品質の土台となる。

Recursive Chunking

段落、改行、句点、読点などの分割候補を順番に試し、なるべく文脈を保ちながらチャンク化する手法。

Semantic Chunking

意味やトピックの変化点を見て分割する手法。多様なテーマが混在する文書で有効な場合がある。

Parent-Child Chunking

検索用の小さな子チャンクと、回答用の大きな親チャンクを分けて管理する手法。

Late Chunking

長文を先にEmbeddingモデルへ通し、その後にチャンク埋め込みを作ることで、文書全体の文脈を保ちやすくする手法。

RAPTOR

チャンクをEmbedding、クラスタリング、要約し、再帰的な木構造を作る階層型検索手法。

GraphRAG

TextUnitからエンティティや関係性を抽出し、知識グラフとして構造化するRAG高度化手法。

参考文献 / 出典

次に読むならこの3本

補足Q&A

Q1.
最適なチャンクサイズはいくつですか？

A1.
万能なサイズはありません。

文書タイプ、質問タイプ、Embeddingモデル、検索方式によって変わります。まず固定長＋オーバーラップでベースラインを作り、Recursive、Parent-Child、Semanticなどを比較評価するのが現実的です。

Q2.
固定長チャンキングはもう使わない方がよいですか？

A2.
固定長チャンキングは、今でもベースラインとして有効です。

ただし、本番RAGでは固定長だけに依存せず、見出し、段落、表、FAQ、手順、コードなどの構造を反映した可変長チャンキングへ進むべきです。

Q3.
チャンキングの良し悪しはどう評価すればよいですか？

A3.
複数のチャンキング手法を同じ質問セットで比較し、検索品質と回答品質を分けて評価します。

固定長、Recursive、Parent-Childなど複数パターンを用意し、Context Precision、Context Recall、Faithfulness、Answer Relevancyを比較するのが現実的です。Ragasなどを使う場合も、検索品質と回答品質を混同しないことが重要です。

更新履歴