2026.08.27
RAGチャンク設計で検索精度を高める実践法
IT関連
RAGチャンク設計は、生成AIが必要な根拠を正しく取り出せるかを左右する工程です。モデルやベクトルDBを変更しても精度が伸びない場合、原因は検索対象となる文章の切り方にあることが少なくありません。
チャンクとは、原文を検索・埋め込み・回答引用に使える単位へ分割した断片です。大きすぎれば論点が混ざり、小さすぎれば前提や条件が失われます。検索精度、ハルシネーション、コスト、更新容易性をまとめて考える必要があります。
本記事では、基本的な分割手法から文書構造を生かす設計、親子チャンク、メタデータ、評価と本番運用までを順に説明します。設定値を出発点にしつつ、実データと質問で検証するための判断基準も整理します。
RAGチャンク設計が回答品質を決める理由
チャンクは検索対象の意味を保つ最小単位
結論として、良いチャンクは質問に答えるための根拠を、前後関係を崩さずに閉じ込めた単位です。埋め込みモデルは文書全体ではなくチャンクごとの意味を数値化するため、分割境界が不自然だと類似検索そのものがぶれます。
例えば規程の「対象者」「例外条件」「申請方法」が別々の断片になると、検索では申請方法だけが返り、回答が誤った対象者へ適用されるおそれがあります。内容の正しさだけでなく、条件と結論を一緒に取得できる構造が重要です。
ALION株式会社が業種横断のシステム開発を支援する際も、業務マニュアル、FAQ、仕様書を同じ規則で機械的に切るのではなく、利用者が尋ねる単位を先に定義することが実装の出発点になります。
- 検索で見つかる意味のまとまりを優先する
- 条件・例外・手順を切り離さない
- 回答時に原文位置へ戻れる単位にする
分割不良はハルシネーションを招く
結論として、ハルシネーションを抑えるには、生成モデルへの指示だけでなく根拠チャンクの完全性を上げる必要があります。必要な情報が検索に含まれなければ、モデルは不足部分を一般知識や文脈推測で補おうとします。
大きすぎる断片では、質問と無関係な記述が埋め込みに混ざり、類似度が薄まります。反対に細かすぎる断片では、主語、否定、期間、注記が抜け落ちます。これは「検索は成功したように見えるが回答が誤る」典型的な状態です。
まず検索ログで、正解に必要な原文がTopK内にあるかを確認してください。なければ生成プロンプトを調整しても根本解決になりません。検索失敗、再順位付け失敗、回答生成失敗を分けて記録すると改善箇所が明確になります。
- 検索根拠の欠落と生成の誤りを分離する
- 否定・例外・適用範囲の欠損を検査する
- 回答だけでなく検索結果を監査する
サイズは目的と質問の粒度から決める
結論として、万能のチャンクサイズはなく、質問の細かさと文書構造に合わせて決めます。初期検証ではchunk_size目安 256〜512字を置くと、短い社内FAQや手順書の検索挙動を把握しやすくなります。
一方、仕様書の節や契約条件のように前後関係が長い文書では、chunk_size目安 256〜1024字で比較します。さらに章単位の概要検索が主目的なら、chunk_sizeを大きめ（1,000〜2,000字）にする選択もあります。
重要なのは、文字数だけで採否を決めないことです。同一の評価質問に対し、必要な根拠が何位で返るか、回答が引用範囲を逸脱していないかを測ります。サイズを変えたら、検索条件も固定して差分を比較します。
- FAQは短め、章の要約は長めから試す
- 質問セットを固定してサイズを比べる
- 文字数とトークン数の両方を管理する
文書に合わせて分割方式を選ぶ
固定長とオーバーラップは最初の比較軸
結論として、構造が乏しいテキストの初期実装では、固定長分割にオーバーラップを加える方法が有効です。たとえばchunk_size=500とchunk_overlap=50なら、境界付近の条件や接続表現を隣接チャンクにも残せます。
オーバーラップの一般的な出発点は、chunk_sizeの10〜15%程度です。ただし重複を増やすほどベクトル数、埋め込み処理、検索候補が増えます。境界欠損を防ぐ効果と、重複コストはトレードオフです。
固定長は実装が簡単ですが、見出しの途中や表の行の途中で切れやすい欠点があります。そのため、単純なログやOCR後のプレーンテキストには使いやすい一方、整ったMarkdownや規程類では構造を優先する方式と比較すべきです。
| 文書タイプ | 推奨方式 | 確認すべき点 |
|---|---|---|
| OCRテキスト | 固定長＋重複 | 改行・誤認識 |
| 業務手順書 | 再帰的・見出し単位 | 条件と手順 |
| FAQ | QA単位 | 質問と回答の対応 |
| Markdown仕様書 | 構造ベース | 見出し階層 |
| ソースコード | AST・関数単位 | 依存関係 |
- 最初は500字・50字重複などで基準を作る
- 重複率を増やす前に境界エラーを確認する
- 固定長を構造文書の最終解にしない
再帰的分割は自然な境界を優先する
結論として、再帰的分割は、段落・改行・文・文字というセパレーター階層を使い、上位の自然な境界を可能な限り守る方式です。固定長よりも文章のまとまりを維持しやすく、一般的な社内文書の初期設定として扱いやすい方法です。
LangChainでは`RecursiveCharacterTextSplitter`を利用でき、chunk_size=512、chunk_overlap=64のような設定から評価を始められます。日本語では句点「。」、改行、箇条書き記号を区切り候補へ含めると、途中で文が切れる割合を抑えやすくなります。
ただし、再帰的分割は意味を理解しているわけではありません。「ただし」「除く」「以下の場合」の直前後が分かれれば、検索上の危険は残ります。分割後のサンプルを目視し、例外規定が単独化していないかを確認してください。
- 段落から文字へ段階的に分割する
- 日本語の句点・改行・箇条書きを区切り候補にする
- 例外規定の分断をサンプル監査する
意味と構造を読む分割を使い分ける
結論として、見出しや表を持つ文書には構造ベース、話題転換が重要な長文にはセマンティックチャンキングが向きます。セマンティック方式は、隣接文の埋め込み距離が大きく変わる箇所を境界候補として扱います。
実装例では、意味的な区切りの感度としてbreakpoint_threshold_amount=95を設定し、過剰分割を避ける検証を行えます。ただし閾値は文書の語彙や長さで変わるため、数値を正解として固定せず、評価セットで調整してください。
Markdown・HTML・PDFでは、見出し、リスト、表題、ページ番号、脚注を抽出時点から保持します。表は行だけに分解すると列見出しが失われやすいため、表題・列名・該当行を一つの検索可能な断片に再構成する設計が安全です。
- 話題境界にはセマンティック方式を検討する
- 見出しと表題を本文から分離しない
- PDFの脚注・ページまたぎを検査対象にする
親子チャンクで精度と文脈を両立する
小さく検索して大きく読ませる
結論として、親子チャンクは小さな子チャンクで検索精度を確保し、大きな親チャンクで回答に必要な文脈を渡す設計です。短い断片だけを生成モデルへ渡すことで起きる、条件や定義の欠落を減らせます。
具体例として、`child_splitter = RecursiveCharacterTextSplitter(chunk_size=200, chunk_overlap=20)`で検索用断片を作り、親は`parent_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100)`で保持します。子のヒットから親を復元する関係が鍵です。
Parent Document Retrieverやsmall-to-big検索では、子チャンクのベクトルへ親IDを保存します。回答画面では子の一致箇所だけでなく、親の見出し、ページ、前後の説明を引用できるため、利用者が根拠を検証しやすくなります。
- 子チャンクは検索一致、親チャンクは回答文脈を担う
- child_idとparent_idの対応を永続化する
- 表示時は親の見出し・位置情報も返す
QAチャンクは定型質問に強い
結論として、質問と回答の対応が安定したナレッジではQAチャンクが有効です。問い合わせ履歴や整備済みFAQは、QA1組 = 1チャンクにすると、質問文に含まれる表現が検索キーとして働き、回答単体より見つけやすくなります。
ただしQA化できるのは、質問の範囲と回答の根拠が明確な情報です。長い規程を無理にFAQへ変換すると、例外条件や更新履歴が落ちる可能性があります。原文チャンクを併存させ、回答の出典を原文へ戻せるようにします。
実務では、定型問い合わせはQAチャンク、探索的な質問は見出し付き汎用チャンクへルーティングする方法が現実的です。質問文が「どうする」「期限は」など手順型か、比較・背景型かを分類して検索範囲を変えます。
- 定型問い合わせは質問文も埋め込む
- QAだけで原文の代替にしない
- 質問タイプごとに検索対象を切り替える
コードは関数と依存関係を壊さない
結論として、コードは文字数で切らず、関数・クラス・モジュールなどの構文構造で分割します。関数シグネチャ、docstring、実装、関連する型定義が別の断片になると、生成AIは呼び出し条件を誤解しやすくなります。
Notebookではセル単位を基本にし、説明Markdownと対応するコードセルの関係をメタデータへ持たせます。ASTを使える言語では、構文木から関数やクラスを抽出し、ファイルパス、シンボル名、import先、コミット版を属性として保存します。
公式に対応する言語にはMarkdown・Python・JavaScript・HTMLなどが含まれます（2026年6月時点）。ただしコード検索では意味類似だけに頼らず、キーワード検索、パスフィルター、リランクを併用して、固有のAPI名や例外型を取りこぼさないようにします。
- 関数・クラス・セルを分割の基本単位にする
- シンボル名とファイルパスをメタデータ化する
- 意味検索とキーワード検索を併用する
メタデータと検索後処理を設計する
メタデータは検索の安全性を担保する
結論として、チャンク本文だけでは本番検索に必要な制御ができません。チャンクID、親文書ID、版、見出し、ページ、作成日、権限、テナントを持たせることで、検索フィルター、差分更新、引用表示を一貫して実装できます。
特に複数部署や顧客の情報を扱う場合、権限は回答生成の後ではなく検索前に適用します。検索結果へ混入してから隠す方式では、モデルのコンテキストに機密情報が渡ります。tenant_idやaccess_scopeを必須フィルターにしてください。
安定したIDは、改訂時の差分再インデックスにも必要です。文書ID、見出しパス、原文位置、内容ハッシュを組み合わせ、変更された断片だけを更新します。削除済み文書の古いベクトルを確実に無効化する運用も欠かせません。
- 権限は検索前フィルターで強制する
- 親子関係と原文位置を保存する
- 改訂・削除を前提に安定IDを設計する
TopKとリランクで候補の質を上げる
結論として、検索はベクトル類似度の上位結果をそのまま渡さず、候補数と再順位付けを目的別に調整します。初期検証ではTopK=10の候補を取得し、質問との関連性をリランカーで並べ替える構成が扱いやすい選択です。
スコア運用の例として、High (Score > 0.3)、Medium (0.15 ≤ Score ≤ 0.3)、Low (Score < 0.15)を定義できます。ただしスコアの絶対値は埋め込みモデルやDBで異なるため、閾値は必ず自社データで校正します。
Cohereの`rerank-v3.5`のような再順位付けモデルを使う場合も、候補に正解根拠が含まれていなければ救えません。まず再現率を、次に適合率を測る順序を守り、検索クエリ生成やハイブリッド検索の必要性を判断します。
- TopKは再現率を確保するために設定する
- 閾値はモデルごと・データごとに校正する
- リランク前に候補集合の正解包含率を見る
コストは分割数だけでなく更新頻度で見る
結論として、細かいチャンクは検索粒度を上げる一方、埋め込み数と更新負荷を増やします。埋め込みコストの目安として、100,000文字 ≒ 50,000トークン → 約 $0.001 のコスト、料金例として$0.02/1M tokensが示されています。
OpenAIの埋め込みでは、各入力の最大トークン数制限（すべての埋め込みモデルで8192トークン）と、各リクエストごとの入力の合計トークン数の最大制限（300,000トークン）があります。前処理では文字数ではなく実トークン数で上限を検証します。
大量の初回登録では、バッチAPIは非同期で24時間の処理時間をかけてコストを約50％削減できる選択肢です。一方、即時性が必要な改訂は差分更新に分け、チャンクIDとハッシュにより再埋め込み範囲を最小化します。
- 分割数・ベクトル数・更新回数を同時に見積もる
- APIの入力上限を前処理で検査する
- 初回投入と差分更新を別フローにする
評価と運用でチャンク品質を継続改善する
正解質問を持たなければ最適化できない
結論として、チャンク設定の良し悪しは印象ではなく、実際の質問と正解根拠を対応付けたGolden Setで判定します。数百個のデータだけでも、利用頻度が高い質問、誤答が許されない質問、曖昧な質問を含めれば比較の出発点になります。
評価ではContext Recallで必要根拠を取得できた割合を、Context Precisionで取得根拠の無駄の少なさを確認します。さらに回答忠実性では、モデルの回答が取得コンテキストに裏付けられるかを判定し、検索と生成の問題を混同しません。
文書と質問を訓練・検証・テストに分けることも重要です。同じ質問を見ながら設定を詰め続けると過適合します。最終テストには、表記揺れ、敬語、略称、複数条件を含む日本語質問を残しておきます。
- 質問・正解根拠・期待回答をセットで管理する
- 再現率、適合率、忠実性を分けて測る
- 最終テスト質問を調整に使わない
失敗パターンをエラー分類する
結論として、改善速度を上げるには「精度が低い」と一括りにせず、失敗を分類します。代表例は、大きすぎるチャンク、小さすぎるチャンク、overlapゼロ、トークン上限の見落とし、検索評価をせずに生成設定だけを変える運用です。
日本語では、句読点、箇条書き、全角半角、製品名の表記揺れ、OCR誤りが境界や検索語に影響します。質問に正解語があるのに取得できない場合は、分割以前に抽出テキストと正規化の品質を確認する必要があります。
各失敗には、質問ID、期待する親文書、取得チャンク、順位、スコア、最終回答、分類ラベルを残します。この記録があれば、チャンク境界の変更、メタデータ追加、クエリ書き換えのどれを試すべきかを根拠を持って決められます。
- 検索漏れ、順位不良、文脈欠損、生成逸脱を分ける
- 日本語の表記揺れとOCR品質を確認する
- 失敗ログを次回評価セットへ反映する
本番更新は検証環境を経由させる
結論として、文書更新と分割ロジック変更は本番へ直接反映せず、stgとprodの2つの環境で検証します。同じ文書でも分割器の変更によりチャンクID、ヒット順位、引用位置が変わるため、品質と権限を段階的に確認する必要があります。
CI/CDには、抽出成功率、空チャンク数、重複率、トークン上限違反、Golden Setの最低基準を組み込みます。新しい文書を追加した際は、追加分だけでなく既存の重要質問に対する順位変動も確認し、検索ドリフトを監視します。
運用担当者には、回答の出典、文書版、検索スコア、フィードバック導線を提示します。利用者からの「見つからない」「古い」という報告を評価データへ戻すことで、RAGを一度作って終わりにせず、業務知識の変化に追従させられます。
- 変更はSTGで検索・権限・引用を検証する
- 品質ゲートをデプロイ工程に入れる
- 利用者フィードバックを評価セットへ還元する
まとめ
RAGチャンク設計の本質は、文書を一定サイズに切ることではなく、質問に必要な根拠を安全かつ再現可能に検索できる単位へ変換することです。文書構造、親子関係、メタデータ、検索後処理、評価と更新を一つの設計として扱いましょう。
要点
- 初期値は出発点であり、実際の質問セットで比較する
- 構造化文書は見出し・表・注記を保持して分割する
- 親子チャンクで検索粒度と回答文脈を両立する
- 権限・版・原文位置をメタデータに持たせる
- Golden SetとSTG検証で継続的に品質を改善する
まずは重要な業務質問を20件程度選び、固定長、再帰的、構造ベースの3案で検索結果を比較してください。結果を基に、利用文書に合う分割ルール、メタデータ、評価フローを段階的に整備することが、信頼できるRAGへの最短ルートです。
よくある質問
Q1. RAGのチャンクサイズは何文字から試すべきですか？
短いFAQや手順書では256〜512字を初期値にし、見出しや段落を保てるか確認します。長い規程や仕様書は256〜1024字も比較し、正解根拠の取得率と回答忠実性で決めてください。
Q2. オーバーラップは必ず必要ですか？
必須ではありませんが、条件文や接続表現が境界で分かれる文書では有効です。まずチャンクサイズの10〜15%程度で試し、重複によるコストと検索改善の差を評価します。
Q3. 親子チャンクはどのような場合に向いていますか？
細かい質問に正確に反応しながら、回答では広い前後文脈や引用を示したい場合に向きます。規程、仕様書、長い手順書など、短い根拠だけでは例外や条件が欠けやすい文書で特に有効です。
Q4. チャンク設計の改善効果はどう測定しますか？
質問、正解根拠、期待回答を対応付けた評価セットを作り、Context Recall、Context Precision、回答忠実性を比較します。検索漏れと生成の誤りを分けて記録することが重要です。
Q5. 機密情報を含むナレッジでは何を保存すべきですか？
本文に加え、テナントID、アクセス権、親文書ID、版、見出し、ページ、原文位置をメタデータに保存します。権限は回答後ではなく、検索クエリ時のフィルターとして必ず適用してください。
参考文献・出典
 # RAGのチャンキング戦略を比較する：固定長・再帰分割・セマンティックの使い分け…
zenn.dev
# [UPSIDER Techblog](https://tech.up-sider.com/) * [記事を書く](https://blog.hatena.ne.jp/upsider_dev/upsider-dev.hatenablog.com/edit) *…
tech.up-sider.com
 # 【2026】RAGチャンキング戦略 完全ガイド｜検索精度を決める分割設計 ![【2026】RAGチャンキング戦略…
aigentlab.tech