本記事では、RAG構築を進めるエンジニア・IT担当者に向けて、チャンキングの仕組みと検索精度を高める設計のポイントをお伝えします。
RAGの検索精度が思ったように上がらない原因の多くは、チャンキング設計の不備にあります。チャンクが大きすぎると検索ノイズが増え、小さすぎると文脈が失われます。埋め込みモデルやベクトルデータベースをいくら最適化しても、チャンキングが適切でなければ精度の改善には限界があります。
RAG構築とデータ設計に携わってきたエンジニアの知見をもとに執筆しています。チャンキング設計で迷っている方の判断材料として、お役に立てれば幸いです。
チャンキングとは何か|RAGにおける文書分割の役割
.jpg)
チャンキングの定義
チャンキングとは、情報を意味のあるまとまり(チャンク)に分割し整理するプロセスです。心理学者のジョージ・ミラーが提唱した「マジカルナンバー7±2」に由来する概念で、人間が短期記憶で保持できる情報量には限界があるため、情報をグループ化して認知負荷を下げるという考え方です。この考え方はAIにおけるデータ処理にも応用されています。
分野 | チャンキングの活用例 | 期待される効果 |
心理学・学習 | 英単語の語根分け・電話番号のハイフン区切り | 記憶の定着率向上・認知負荷の軽減 |
ビジネス | タスクの細分化(WBS)・課題の抽象化 | 問題解決の迅速化・プロジェクト管理の効率化 |
生成AI(RAG) | 長文ドキュメントを意味的・構造的な単位で分割 | 検索精度の向上・ハルシネーションの抑制 |
言語学 | 文章を文節やフレーズごとに区切って解釈 | テキストの自然な文脈理解・機械翻訳の精度向上 |
なぜチャンキングがRAGの精度を左右するのか
RAGではAIが外部データベースから関連情報を探し出して回答を生成しますが、元のドキュメントが長すぎるとAIはどの部分が重要か判断しにくくなります。情報を適切なサイズのチャンクに分割することで的確な検索が可能になり、ノイズを減らして回答の正確性を高めます。
RAGにおける課題 | チャンキングによる解決策 |
長すぎる入力によるAIの混乱 | 情報を意味のある小さな単位に分割し要点を明確にする |
無関係な情報(ノイズ)の混入 | 質問に関連するチャンクのみを抽出し回答の純度を高める |
コンテキストウィンドウの制限 | AIが一度に処理できる情報量に合わせてサイズを最適化する |
情報検索の計算コスト肥大化 | 事前に分割・ベクトル化しておくことで検索速度を向上させる |
チャンクサイズと検索精度の関係
チャンクサイズは検索結果の質に直接影響を与える重要な要素です。サイズが大きすぎると一つのチャンクに複数の話題が混在し検索精度が落ちます。逆に小さすぎると文脈が失われAIが意味を正しく理解できなくなります。
チャンクサイズ | メリット | デメリット |
大(例:1000トークン〜) | 全体的な文脈を維持しやすい | ノイズが増え特定の回答を見つけにくい |
中(例:500〜1000トークン) | 文脈と検索精度のバランスが良い | 複雑な情報では意味が途切れる場合がある |
小(例:100〜500トークン) | ピンポイントで正確な情報を見つけやすい | 前後の文脈が失われやすい |
目的やデータの性質に合わせて最適なサイズを見極めることが、チャンキング設計の核心です。
チャンキングの種類|分割手法を目的別に整理
.jpg)
固定長チャンキング(文字数・トークン数ベース)
指定した文字数やトークン数でテキストを機械的に分割する手法です。実装がシンプルで処理速度が速い反面、文の途中で区切られるリスクがあり意味が通じなくなることがあります。構造が単純なテキストやスピードを最優先する場合に適しています。
構造ベースチャンキング(段落・見出し・文単位)
HTMLのタグやMarkdownの見出しなど、文書の構造を利用して分割する手法です。段落や文単位で区切るため論理的なまとまりを維持しやすく、マニュアルや規程集など見出し構成が明確なドキュメントに非常に適しています。
構造の単位 | 分割の基準となる要素 | 適したドキュメントの例 |
HTMLタグ | <h1>・<p>・<table>などのタグ | Webページ・オンラインマニュアル |
Markdown | #・##などの見出し記号 | 技術ドキュメント・社内Wiki |
文・段落 | 句点(。)・改行コード | ニュース記事・一般的なビジネス文書 |
意味的チャンキング(セマンティックチャンキング)
テキストの意味的な類似性を計算し、話題が変わる箇所で分割する高度な手法です。各チャンクが一貫した内容になるため検索の精度が飛躍的に向上しますが、分割位置を判断するための計算コストが高くなる点には注意が必要です。Q&Aデータや専門的な技術文書など、高い回答精度が求められる場面で活躍します。
階層型チャンキング(親子チャンク)
情報を大まかなまとまり(親)と詳細なまとまり(子)の階層構造で管理する手法です。検索時は「子チャンク」でピンポイントに一致する情報を探し、AI回答生成時には文脈が豊富な「親チャンク」を渡します。これにより正確な検索と文脈を捉えた自然な回答の両立が可能になります。
階層レベル | 役割と特徴 | 具体例 |
親チャンク | 全体の文脈を保持しAIに背景情報を提供する | ドキュメントの「章」や「節」全体 |
子チャンク | 検索のヒット率を高めるための詳細な情報 | 各段落や特定の「文」 |
孫チャンク | さらに細かいキーワード検索に特化する(任意設定) | 専門用語や特定の数値データ |
チャンキング設計のポイント|精度を高める4つの基準
.jpg)
扱う文書の種類・長さに合わせて手法を選ぶ
すべての文書に通用する「完璧なチャンキング手法」は存在しません。FAQのように短いデータと長大なマニュアルでは最適なアプローチが異なります。元の文書が持つ構造や情報の密度を分析した上で手法を選択してください。
文書の種類 | 推奨されるチャンキング手法 | 選定の理由 |
FAQ・一問一答 | 文単位またはチャンキング不要 | 1つのデータがすでに意味の最小単位であるため |
Web記事・ブログ | 構造ベース(見出し単位)・再帰的分割 | 段落ごとのまとまりが強く文脈を維持しやすいため |
専門書・論文 | 意味的チャンキング・階層型 | 複雑な論理展開があり文脈の欠落が致命的になるため |
ログデータ | 固定長チャンキング | 構造が均一で意味的なまとまりを考慮する必要が薄いため |
チャンクサイズとオーバーラップの最適な設定
チャンクサイズを決める際は、隣接するチャンク同士を少し重複させる「オーバーラップ」の設定が重要です。オーバーラップを設定することで境界部分での情報の分断を防げます。一般的にはチャンクサイズの10〜20%程度をオーバーラップさせるのが目安です。
- まずは500トークン・オーバーラップ50トークン程度から始める
- 検索結果にノイズが多い場合はサイズを小さくする
- 回答に文脈が不足している場合はサイズとオーバーラップを増やす
- 複数の設定パターンで評価指標(ヒット率など)を比較する
メタデータと組み合わせて検索精度を高める
分割したテキスト情報だけでなく、作成日やカテゴリなどのメタデータを付与することで検索精度が大きく向上します。メタデータで検索範囲を絞り込むことで、無関係なチャンクがヒットするのを防げます。同じような用語が複数の文脈で使われる社内ドキュメントでは特に必須の設計です。
メタデータの種類 | 付与する情報の例 | 検索時の活用方法 |
属性情報 | 作成日時・更新日時・作成者 | 「最新の規程」など時間軸での絞り込みに使用 |
分類情報 | カテゴリ・部署名・プロジェクト名 | 特定の部署に限定した検索でノイズを排除 |
階層情報 | 親ドキュメントのURL・章のタイトル | 回答の出典元を明示し情報の信頼性を担保 |
埋め込みモデルのトークン制限を考慮する
テキストをベクトル化する埋め込みモデルには、一度に処理できるトークン数に上限があります。上限を超えるサイズのチャンクを入力すると後半の情報が無視される可能性があります。利用するモデルの仕様を事前に確認し、制限内に収まるチャンクサイズで設計することが大原則です。OpenAIのモデルなどでは8,000トークン以上に対応しているものもありますが、モデルごとに異なるため必ず仕様を確認してください。
チャンキングの失敗パターンと対策
.jpg)
チャンクが大きすぎる場合の問題
チャンクが大きすぎると一つの塊に複数のトピックが混ざってしまいます。検索時に「部分的には一致するが全体としては無関係」な情報がヒットしやすくなり、AIも複数のトピックから適切な情報を抽出できず的外れな回答を生成しがちです。
発生する問題 | 具体的な症状 | 解決に向けた対策 |
ノイズの増加 | 質問と関係ない情報が多く含まれてしまう | チャンクサイズを半分程度に縮小して再検証する |
検索順位の低下 | 本当に重要な情報を含むチャンクのスコアが下がる | 意味的チャンキングを導入し話題ごとに分割する |
生成コストの増加 | AIに渡す文字数が増えAPI料金が高騰する | 階層型チャンキングで検索用データを軽量化する |
チャンクが小さすぎる場合の問題
チャンクを細かくしすぎると単語レベルでの検索精度は上がりますが、主語や述語・指示代名詞(これ・それ)の指す内容が失われがちです。前後の文脈が分からないためAIが誤った解釈をしてしまうリスクが高まります。
- 主語が抜け落ちてしまい誰の行動なのか分からなくなる
- 「しかし」などの逆接の前後が分断され意味が逆転する
- 回答が断片的になりユーザーにとって分かりにくい文章になる
文脈が途切れる分割によるハルシネーションリスク
固定長で機械的に分割すると重要な説明の途中でチャンクが切れることがあります。情報が不完全な状態でAIに渡されると、AIは不足部分を推測して補おうとします。これが事実に基づかない情報を生成する「ハルシネーション」の原因のひとつです。オーバーラップを設けるか、構造ベースの分割手法を採用することで対策できます。
ハルシネーションの原因 | チャンキング側の問題点 | 改善アプローチ |
情報の分断 | 文の途中で強制的に区切られている | 句点や改行を優先して分割する設定に変更する |
前提条件の欠落 | 「※ただし〜」という例外規定が別チャンクになる | 階層型チャンキングで例外規定を親チャンクに含める |
専門用語の解釈ミス | 用語の定義が書かれた部分と分離される | メタデータに用語の定義を埋め込んで文脈を補完する |
チャンキングの評価と改善方法
.jpg)
検索結果のゼロヒット分析
ユーザーの質問に対して適切なチャンクが一つもヒットしなかったケースを分析します。専門用語の揺れやチャンクサイズが合っていないことが主な原因です。検索クエリとチャンクの内容を見比べ、分割の粒度やメタデータの不足を修正します。
回答品質からチャンク設計を見直す方法
AIが生成した回答の品質を人間が評価し、チャンク設計にフィードバックします。「回答が長すぎる」「的外れである」といった課題はチャンクに起因することが多いため、理想的な回答を出力するために必要な情報が過不足なくチャンクに含まれているか確認してください。
回答の不満点 | 推測されるチャンキングの課題 | 見直しのポイント |
情報が足りない | チャンクが小さすぎる・オーバーラップが不足している | サイズを拡大し文脈をより多く含める |
関係ない話が混ざる | チャンクが大きすぎる・トピックが混在している | 意味的チャンキングに変更し話題の境界を明確にする |
古い情報が混ざる | バージョン管理ができていない | メタデータに更新日を追加し検索時にフィルタリングする |
継続的なチューニングのサイクル
チャンキングの設計は一度設定すれば終わりではありません。ユーザーの質問の傾向は変化するため定期的な見直しと改善が不可欠です。評価指標を定めてデータを収集し、PDCAサイクルを回し続けることがRAGシステムの長期的な価値を高める鍵です。
計画(Plan):改善目標と検証する分割手法を決める
実行(Do):一部のデータセットで新しいチャンキング設定をテストする
評価(Check):検索精度と回答品質のスコアを従来の設定と比較する
改善(Action):結果が良好であれば本番環境に適用しルールを更新する
よくある質問|チャンキングの設計・運用について
.jpg)
Q. チャンクサイズの目安はどれくらいですか?
A. 一般的には500トークン・オーバーラップ50トークン程度からスタートするのが現実的です。ただし文書の種類によって最適値は大きく異なります。FAQや短い一問一答形式であればそもそもチャンキング不要なケースもあり、専門書や論文など複雑な文書では1,000トークン以上が適切な場合もあります。まずデフォルト値で検索テストを行い、結果を見ながら調整していくアプローチをおすすめします。
Q. オーバーラップはどのくらい設定すべきですか?
A. チャンクサイズの10〜20%程度が目安です。たとえばチャンクサイズが500トークンであれば50〜100トークンのオーバーラップが標準的な設定です。オーバーラップが少なすぎると境界部分で文脈が途切れハルシネーションのリスクが高まります。逆に多すぎると同じ情報が重複してヒットしノイズが増えるため、検索結果を確認しながら調整してください。
Q. 文書の種類によって手法を変えるべきですか?
A. はい、変えるべきです。FAQは文単位・Web記事は構造ベース・専門書は意味的チャンキングというように、文書の性質に合わせた手法を選ぶことが精度向上の基本です。同じRAGシステム内でも文書の種類ごとに異なるチャンキング手法を適用することで、全体的な回答品質を高められます。
Q. チャンキングを後から変更することはできますか?
A. 技術的には可能ですが、変更する際はベクトルデータベース内のデータをすべて再生成する必要があります。文書量が多い場合はこの作業コストが大きくなるため、初期設計の段階で複数のパターンをPoCで検証しておくことが重要です。本番運用後の変更は影響範囲が大きいため、スモールスタートで最適なチャンクサイズを見極めてから拡張する進め方をおすすめします。
まとめ|チャンキング設計のチェックリスト
.jpg)
チャンキングはRAGシステムの検索精度を根本から左右する設計です。埋め込みモデルやベクトルデータベースをいくら最適化しても、チャンキングが適切でなければ精度の改善には限界があります。本記事のポイントを整理します。
1. 文書の種類に合わせて手法を選ぶ FAQ・Web記事・専門書・ログデータなど文書の性質によって最適な手法は異なります。すべてに通用する「完璧な手法」は存在しないため、文書ごとに適切なアプローチを選定してください。
2. チャンクサイズは500トークン・オーバーラップ50トークンからスタートする まずデフォルト値で検索テストを行い、結果を見ながら調整していくアプローチが現実的です。ノイズが多ければサイズを小さく、文脈が不足していればサイズとオーバーラップを増やします。
3. メタデータと組み合わせて精度を高める チャンクにメタデータを付与することで検索範囲を絞り込め、無関係なチャンクがヒットするのを防げます。特に同じ用語が複数の文脈で使われる社内文書では必須の設計です。
4. 失敗パターンを事前に把握しておく チャンクが大きすぎるとノイズが増え、小さすぎると文脈が失われます。文脈が途切れる分割はハルシネーションの原因になるため、オーバーラップの設定と構造ベースの分割で対策してください。
5. ゼロヒット分析とPDCAで継続的に改善する チャンキングは一度設定して終わりではありません。検索ログのゼロヒット分析と回答品質の評価を定期的に行い、PDCAサイクルで継続的に改善していくことがRAGシステムの長期的な価値を高める鍵です。
RAG構築・チャンキング設計支援なら株式会社glorious futureへ

株式会社glorious futureは、「だれにでもデータ活用ができる社会へ」をミッションに掲げ、企業のDX推進を支援するシステム開発会社です。RAG導入においては、チャンキング設計・ナレッジベース構築から、システム開発・運用定着まで一貫してサポートします。
glorious futureが選ばれる理由
- 企画・コンサルティングから開発・運用まで一貫して伴走
- お客様のビジネスを深く理解した当事者意識のある支援
- チャンキング設計・メタデータ整備など精度向上の上流工程から対応
- AWSなどのクラウドインフラ構築や高度なセキュリティ要件にも対応
チャンキング設計に迷っている、RAG構築をどこから始めればいいかわからない、という方はまずお気軽にご相談ください。現状の課題ヒアリングからご提案まで、無料で対応いたします。

