RAGで該当する文は検索できたのに、回答が条件を取り違える。そこでチャンクを大きくすると、今度は別の話題まで一緒に検索される。この問題では、分割サイズだけでなく「検索する単位」と「回答に渡す単位」を分けて考えたい。

本稿は2026年9月21日時点の公開資料に基づく設計案です。本番導入や精度改善の実績報告ではありません。コード実装・検索精度・負荷は未検証です。AI業務システムのナレッジ検索を設計するエンジニアに向け、採用条件と捨てる条件を整理します。

問いは「何文字で切るか」より「何が一緒に必要か」

架空の操作マニュアルに、次の記述があるとします。

設定変更後はサービスを再起動する。
ただし、共有環境では作業承認を得てから実施する。

前半だけを取得すると、回答から前提条件が落ちます。後半だけなら、何の承認かが不明です。この例で保持したいのは文の長さではなく、操作とその適用条件の関係です。

前提は、見出しを持つ日本語文書を対象に、根拠箇所を引用するRAGです。表・コード・例外条件は本文と同じ切り方で扱わず、文書内で閲覧権限が変わる場合は、その境界を優先します。

Microsoftの資料では固定長分割、構造に基づく分割、意味に基づく分割を区別しています。また、文字数とモデルが扱うトークン数は一致しません。日本語の文字数をそのままトークン上限と見なさないことが出発点です。Chunk documents

比較するのは分割器だけではない

以下は、この前提に対する設計上の比較です。優劣の実測結果ではありません。

選択肢	採用しやすい条件	引き受ける制約
固定長＋重複	文書構造が乏しく、まず比較用の基準が必要	操作と例外を分断する可能性。重複が検索枠を占有する
見出し・段落単位＋上限	見出しが安定し、節ごとに意味がまとまる	長い節の再分割、見出し抽出の品質管理が必要
小さい子チャンクで検索し、親の節を補う	検索対象の文と説明に必要な範囲が異なる	親の取得、再認可、文脈予算の管理が増える
意味変化を推定して分割	構造が弱く、話題の切り替わりを検出したい	推定処理のコストと再現性を評価する必要がある

文書の種類に応じて分割方針を変える考え方は、Azure Architecture Centerにも整理されています。ただし、以下の採否と処理順序は本稿の提案です。Chunking phase

本案では見出し・段落単位を基準にします。最初から意味推定の処理を追加すると、抽出失敗・分割失敗・検索失敗の切り分けが増えるためです。子から親への展開は、評価で「根拠文は見つかったが条件が欠ける」と確認できた質問群にだけ追加します。

検索用の本文と、回答用の文脈を分ける

取り込み時に、各チャンクへ次のメタデータを付ける設計にします。

フィールド	用途
`document_id` / `revision`	元文書と版を特定する
`section_id` / `chunk_id`	親の節と検索単位を区別する
`source_span`	版を固定した抽出テキスト上の位置を記録する
`heading_path`	単独の本文では欠ける見出し情報を補う
`acl_ref`	認可ポリシーを参照する。プロンプトには入れない
`chunker_version`	分割規則を再現する

source_spanの座標は、正規化前後で混ぜません。抽出テキストの版と位置を保存し、PDFなどではページや表示箇所へ戻す対応表も別に持ちます。チャンク内の文字列だけでは、引用元を安定して再現できないためです。

回答までの処理は次の順序を想定します。

利用者の認証・検索対象の認可
  → 許可された範囲で子チャンクを検索
  → 同じ版・同じ範囲の重複を整理
  → 必要な場合のみ親の節を取得して再認可
  → 回答用のトークン予算内に文脈を組む
  → 根拠を添えて生成 / 根拠不足なら回答を保留

親へ展開するときは、同じ文書の同じ版に限定します。検索時に認可した子の隣に、異なる権限の節があるかもしれません。親の再認可ができなければ、広げない設計にします。

また、親をすべて連結する方式は採りません。必要な条件を含む節を優先し、同一節の重複取得をまとめます。予算超過時に末尾を機械的に切ると、結局「ただし」以降を落としかねないので、節全体を外すか、不足として扱います。

分割サイズの評価は、回答生成の前後で分ける

比較用の候補として、上限を256・512・1,024トークン、重複を0%・12.5%にする実験を考えます。この値は実験計画上の仮置きで、推奨値でも測定済みの最適値でもありません。 使用する埋め込みモデルと生成モデル、それぞれのトークナイザー・入力上限で別々に検査します。

分割方式ごとに同じ質問集合を使います。モデル、検索方式、取得件数を固定した比較に加えて、最終的に渡す文脈トークン予算も固定した比較を行います。同じ取得件数でも、チャンクが大きければLLMに渡る情報量が変わるからです。

観測するもの	判断できること
必要な根拠箇所が候補に含まれる割合	検索までの段階で根拠を取り逃がしていないか
適用条件まで最終文脈に含まれる割合	親展開や予算調整で条件が失われていないか
根拠と回答の整合性	文脈が揃っても生成で取り違えていないか
回答不能の質問を保留できた割合	検索結果があるだけで回答していないか
文脈量・取得時間・索引サイズ	品質の差に対して運用負担が見合うか

正解をchunk_idで固定すると、分割変更で評価基準まで変わります。本案では、元文書の版と根拠範囲を正解として持ち、各設定のチャンクへ対応付けます。質問も「単独の定義」「例外付き手順」「表の参照」「答えが存在しない」に分け、平均値だけで判断しません。

想定する失敗と、追加しない仕組み

ここは経験談ではなく、設計レビューで想定する失敗パターンです。

重複を増やして同じ節ばかり返る：document_id・版・範囲で重複を整理する。ただし、同じ文書の別の根拠まで一括除外しない。
表の列名と値が離れる：表として抽出し、行を分割する場合は列見出しを付ける。上限を超える表は専用の処理対象として保留する。
旧版の子から新版の親へ展開する：親子を版で結び、公開する索引の世代を揃える。
検索本文に書かれた指示に従う：取得した文書は参照データとして扱い、ツール実行権限は別の認可層に置く。分割だけで命令注入を防げるとは考えない。

初期段階では、LLMによる分割境界の自動最適化は追加しません。固定した評価集合で構造分割の弱点を特定してから、追加コストに見合うかを比較します。

本番化で先に決めるのは更新と失敗時の扱い

取り込みの再試行で同じチャンクが増えないよう、文書ID・版・分割器の版・チャンク位置を再実行時の識別に使います。新しい索引を構築して検査後に切り替える設計なら、作成途中の親子が回答へ混ざることを避けやすくなります。ただし、切り替えの原子性は使う検索基盤で検証が必要です。

削除・権限変更は、索引だけでなく親文書の保存先とキャッシュにも反映させます。古い世代へ戻す場合も、最新の権限確認を通し、削除済みの本文を復活させない条件を設けます。

ログには分割器の版、索引世代、根拠ID、文脈量、保留理由、処理時間を残します。質問や文書本文を無条件には記録しません。空の抽出結果や入力上限超過は隔離し、一時的な通信障害だけを回数と期限を制限して再試行します。

次に検証すること

まず、同じ公開文書と質問集合で固定長と構造分割を比較します。次に、条件が欠けた質問に絞って親展開の効果を確認します。

採用基準は「平均精度が上がった」だけでは不十分です。例外条件の保持、権限境界、版の整合性、文脈予算を同時に満たせるかを見る。チャンクを小さくする判断は、この比較結果が揃ってから行うつもりです。

参考リンク

同様の仕組みの設計・構築・運用については相談可能。

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。