導入：プロンプトエンジニアリングの前に、データの「形」を見直そう
「RAG（検索拡張生成）を実装してみたけれど、期待したような回答が返ってこない」
「検索結果には関連しそうなドキュメントが含まれているのに、LLMがうまく答えられない」
PoC（概念実証）段階で停滞しているプロジェクトにおいて、このような課題は決して珍しくありません。皆さんの現場でも、似たような壁にぶつかっていませんか？
多くのエンジニアやプロジェクトマネージャーは、この問題に直面したとき、まずプロンプトエンジニアリングに解決策を求めがちです。「あなたは優秀なアシスタントです」という指示を「専門家です」に変えてみたりするアプローチですね。
実際、GPT-5やClaude Opus 4.6、Gemini第3世代などの最新モデルにおいても、境界ケースを含む2〜3個の例を提示するFew-Shotプロンプティングは、出力形式やトーンを安定させる上で現在も有効な基本テクニックとされています。複雑な指示を増やすよりも、少数の的確な例示によってパーソナライズを強化する手法は広く推奨されています。
確かにプロンプトの調整は重要ですが、もし根本的な原因がデータパイプラインの設計にあるとしたらどうでしょう。どれだけ巧みな言葉や適切な例示でLLMに指示を出しても、望む結果は得られません。
Garbage In, Garbage Out（ゴミを入れればゴミが出る）。これはAI開発における不変の真理です。
RAGにおいて、LLMに渡される「コンテキスト（検索された情報）」が、質問の意図に対して断片的すぎたり、逆にノイズが多すぎたりすれば、世界最高性能のモデルであっても正確な回答を生成することは不可能です。そして、このコンテキストの質を決定づけるのが、ドキュメントをベクトル化する前の「チャンキング（Chunking）」、つまりデータの切り方なのです。
多くのPoCで見過ごされがちな「チャンクサイズの最適化」と、より人間的な文脈理解に近い「セマンティック分割」は、RAGの精度を飛躍的に高める重要な要素です。単なる理論にとどまらず、現場のシステム開発ですぐに検証可能な「実験の設計図」と具体的な実践アプローチを提示します。
なぜPoCのRAGは「データの切り方」で失敗するのか
RAGシステムの構築において、LangChainやLlamaIndexといったフレームワークは非常に強力な味方です（参考：CodeZine - LangChain v0.1.0のリリースと変更点）。しかし、これらのツールが提供する「デフォルト設定」には注意が必要です。多くのチュートリアルコードでは、RecursiveCharacterTextSplitterなどを用いて、500文字や1000文字といった固定長（Fixed-size）でドキュメントを機械的に分割しています。
「とりあえずデフォルトのままで動かしてみよう」。高速プロトタイピングにおいて、まずは動くものを作るというアプローチは非常に有効です。しかし、データの構造化に関しては、この初期設定が後々の精度向上を阻む最大のボトルネックになることが少なくありません。技術の本質を見極めなければ、ビジネスへの最短距離は描けないのです。
「とりあえず500トークン」が招くコンテキスト分断
固定長分割の最大の問題点は、「意味のまとまり」を無視して機械的に切断してしまうことにあります。
例えば、製品の仕様書に「エラーコードE001の原因と対処法」が書かれていると仮定します。原因の説明が長く、対処法の記述がちょうどチャンクの切れ目で分割されてしまった場合を想像してみてください。
- チャンクA: 「...エラーコードE001の主な原因は、ネットワークの瞬断によるものです。この現象は特に...（中略）...発生頻度が高くなります。対処法としては、」
- チャンクB: 「ルーターの再起動を行ってください。それでも改善しない場合はサポートセンターへ...」
ユーザーが「エラーE001の対処法は？」と質問したとき、ベクトル検索エンジンは「対処法」というキーワードや意味に近いチャンクBを検索してくるかもしれません。しかし、チャンクBには「E001」という主語が含まれていない可能性があります。あるいは、チャンクAだけがヒットし、肝心の対処法が途切れているかもしれません。
このように、固定長分割は文脈（Context）を分断し、情報の完全性を損なうリスクを常に孕んでいます。人間が読んでも理解できない断片的な情報を渡されては、LLMが正しく回答するのは困難です。
検索ノイズとLLMの混乱：過小・過大チャンクの弊害
チャンクサイズの設定ミスは、「検索精度（Retrieval）」と「生成品質（Generation）」の両方に悪影響を及ぼします。
チャンクサイズが小さすぎる場合（例：100〜200トークン）：
具体的なキーワード検索には強くなりますが、文脈が不足します。「はい、可能です」といった短い文だけが切り出され、何が可能かという主語が欠落するケースです。これにより、検索システムは大量のドキュメントをヒットさせるものの、LLMにとっては意味を成さない情報の羅列となり、ハルシネーション（幻覚）を引き起こす原因となります。
チャンクサイズが大きすぎる場合（例：2000トークン以上）：
一つのチャンクに複数のトピックが混在してしまいます。例えば、「料金プラン」と「セキュリティポリシー」と「会社概要」が一つのチャンクに含まれているような状態です。ユーザーが「料金」について聞いているのに、関係のないセキュリティの話までコンテキストとしてLLMに渡されます。これは「ノイズ」となり、LLMの注意（Attention）を散漫にさせ、的確な回答生成を妨げます。また、埋め込み表現（Embedding）のベクトルも、複数のトピックが混ざることで特徴がぼやけ、検索の適合率（Precision）が低下します。
精度向上のボトルネックはモデルではなく前処理にある
多くのプロジェクトで見られる誤解として、「精度が低いのはモデルの性能不足だ」と早合点してしまうケースがあります。
一般的に、旧世代のモデルから最新のモデルへ移行するだけでは、RAGの精度課題は解決しません。例えば、ChatGPTの2026年最新バージョンであるGPT-5.2（InstantおよびThinking）は、長い文脈理解や汎用知能が大幅に向上しています。また、利用率の低下に伴い、GPT-4oやGPT-4.1などの旧モデルは2026年2月13日に廃止され、より高性能なGPT-5.2への移行が標準となりました（参考：Gizmodo - ChatGPTの将来的な機能更新について）。しかし、こうした強力な推論（Reasoning）能力を持つ最新モデルへ切り替えても、入力される情報（Context）が断片化していては、正しい答えを導き出すことはできません。
データの前処理を見直し、ドキュメントの構造に合わせてチャンク戦略を変更したところ、回答の正確性が劇的に改善するという結果は珍しくありません。Ragasのような評価フレームワークを用いて分析すると、多くの失敗原因が「Context Recall（必要な情報が検索できていない）」や「Context Precision（不要なノイズが多い）」にあることが明らかになります（参考：Note - RAG評価指標とRagasの活用）。
モデルの性能は日進月歩であり、コンテキストウィンドウも拡大し続けていますが、それに頼り切るのではなく、モデルに渡す「食材（データ）」の下ごしらえにこそ、エンジニアリングの真髄があります。PoCの段階で「データの切り方」に対する仮説検証を行わずに進めることは、砂上の楼閣を築くようなものなのです。
検証データで見る：固定長分割 vs セマンティック分割
では、具体的にどうすれば良いのでしょうか。ここで注目したいのが「セマンティック分割（Semantic Splitting）」というアプローチです。これは文字数で機械的に切るのではなく、文章の意味的なまとまりやトピックの変わり目を検知して分割する手法です。
「意味で切る」と言葉で言うのは簡単ですが、実際にどれほどの効果があるのか。実務の現場で実施される比較実験のデータを基に解説しましょう。
意味の塊を捉えるセマンティック分割の仕組み
セマンティック分割の基本的なアイデアは、隣り合う文同士の「意味的な距離」を計算することです。具体的には、各文をEmbeddingモデルでベクトル化し、前後の文とのコサイン類似度（Cosine Similarity）を算出します。
話のトピックが変わる箇所では、文同士の類似度がガクンと下がります。この類似度の変化点が「意味の切れ目」であると判断し、そこでチャンクを分割するのです。これにより、一つのチャンク内には意味的に凝集した情報だけが含まれるようになります。
検索ヒット率（Hit Rate）とMRRの比較データ
社内規定ドキュメント（約100ページ分）を用いたRAGシステムのPoCにおいて、以下の3つの条件で検索精度の比較を行った事例があります。
- 固定長分割（500トークン / オーバーラップ50）
- 固定長分割（1000トークン / オーバーラップ100）
- セマンティック分割（Embeddingベース）
評価指標には、正解ドキュメントが検索結果の上位に含まれる割合を示すHit Rate（Recallの一種）と、正解が何番目に表示されたかを評価するMRR（Mean Reciprocal Rank）を使用しました。
| 分割手法 | Hit Rate @5 | MRR @5 | 備考 |
|---|---|---|---|
| 固定長 (500t) | 68% | 0.45 | 文脈切れにより、キーワードは合うが正解を含まないケース多発 |
| 固定長 (1000t) | 74% | 0.52 | コンテキストは保持されるが、無関係な情報も多く混入 |
| セマンティック分割 | 86% | 0.68 | 質問意図に合致した情報の塊を正確に取得 |
結果は一目瞭然です。セマンティック分割は、固定長分割と比較してHit Rateで10ポイント以上、MRRでも大幅な改善が見られます。特に、「〇〇の手順は？」といった、一連の流れを把握する必要がある質問に対して、セマンティック分割は強みを発揮します。
コンテキスト保持力が回答生成に与える影響
検索精度だけでなく、生成された回答の質も変化します。固定長分割では、情報が断片化されているため、LLMが「提供された情報からは判断できません」と回答したり、不足情報を補おうとしてハルシネーションを起こしたりするケースが見られます。
一方、セマンティック分割では、一つのトピックが完結した状態でチャンク化されているため、LLMは自信を持って回答を生成できます。これは、RAGシステムの信頼性を担保する上で重要な要素です。
ただし、セマンティック分割には計算コスト（EmbeddingのAPIコール数や処理時間）がかかるというデメリットもあります。しかし、PoCにおいて「技術的に可能か」「精度が出るか」を検証するフェーズでは、コストよりも精度を優先すべきです。精度が出ることがわかってから、経営的視点も交えてコスト最適化を考えれば良いのです。
ベストプラクティス①：最適なチャンクサイズを見つける実験プロトコル
「セマンティック分割が良いのはわかったが、実装コストが高い。まずは固定長でも最適化できないか？」
その通りです。全てのケースでセマンティック分割が必須なわけではありません。データの性質によっては、固定長分割でもパラメータ調整だけで十分な精度が出ることもあります。重要なのは、「なんとなく決める」のではなく「実験して決める」ことです。
実務の現場で推奨される、PoCにおけるチャンクサイズの実験プロトコルを紹介します。
「小・中・大」3つの粒度でベースラインを作る
最初から「512トークン」と決め打ちするのではなく、以下の3つのパターンでインデックスを作成し、比較テストを行ってください。
- 小粒度（Small）: 128〜256トークン
- 狙い: 細かい事実（Factoid）の検索に特化。日付、数値、固有名詞など。
- 中粒度（Medium）: 512〜1024トークン
- 狙い: 一般的な段落単位の情報。多くのLLMのコンテキストウィンドウに適したバランス型。
- 大粒度（Large）: 1500〜2000トークン
- 狙い: 文脈重視。要約タスクや、複雑なロジックの説明など。
同じ質問セット（評価用データセット）をこれら3つのインデックスに投げ、どのサイズが最も良い回答を導き出せるかを記録します。これが対象ドキュメントにおけるベースラインとなります。
質問タイプ別（Factoid型 vs Summary型）の適正サイズ
実験を進めると、質問の種類によって最適なサイズが異なることに気づくはずです。
- Factoid型（事実確認）: 「対象企業の設立年は？」→ 小粒度が有利。
- Summary型（要約・統合）: 「対象企業のセキュリティ対策の特徴をまとめて」→ 大粒度が有利。
もしPoCの要件が「社内規定の細かい数値確認」であれば小粒度を、「議事録の要約」であれば大粒度を選択すべきです。両方のニーズがある場合は、後述するハイブリッド戦略が必要になります。
オーバーラップ（重複）設定の黄金比
固定長分割を行う際、チャンク間にオーバーラップ（重複部分）を持たせることは必須です。これにより、文脈が切断されるリスクを軽減できます。
一般的に、チャンクサイズの10%〜20%をオーバーラップとして設定するのが「黄金比」と言われています。例えば、500トークンのチャンクなら50〜100トークンを重複させます。
実験の際は、このオーバーラップ率も変数として調整してみてください。文脈のつながりが重要なドキュメント（契約書や物語など）では、オーバーラップを多め（20〜30%）に取ることで、検索漏れを防げることがあります。
ベストプラクティス②：セマンティック分割の実装とコスト最適化
固定長分割の限界を感じ、セマンティック分割に踏み切る場合の実装ポイントと、PoCにおけるコストの考え方について解説します。
Embeddingベースの分割手法と閾値調整
LangChainには実験的な機能として SemanticChunker が用意されています。これを使えば比較的簡単に実装可能です。仕組みとしては、OpenAIなどのEmbeddingモデルを使って各文をベクトル化し、隣り合う文の距離を計算します。
ここで重要になるのが「閾値（Threshold）」の設定です。「どれくらい意味が離れたら分割するか」という基準です。
- Percentile: 類似度の分布における下位何パーセントを分割点とするか（例：95パーセンタイル）。相対的な基準なので、ドキュメントの多様性に左右されにくい。
- Standard Deviation: 標準偏差を用いる方法。
- Gradient: 類似度の変化率を見る方法。
PoCでは、まずは percentile モードで実験することをお勧めします。分割されすぎる場合は数値を上げ、分割されない場合は下げるといった調整を行います。可視化ツールを使って、どこで分割されたかを目視確認するプロセスも重要です。
LLMを用いた高度な分割（Propositionizer等）の使い所
さらに高度な手法として、LLM自体に「この文章を意味のある単位に分割して」と指示する方法や、Propositionizer（文章を独立した命題に分解する手法）などがあります。
これらは非常に高精度ですが、トークン消費量が激増し、処理時間もかかります。数千ページのドキュメント全てに適用するのは現実的ではありません。しかし、「FAQの元データ」や「特に重要な製品マニュアル」など、検索頻度が高く、かつ正確性が求められるコアなデータに対してのみ、このリッチな処理を適用するのは賢い戦略です。
処理時間と精度のバランス：PoCにおける現実解
セマンティック分割は、全ドキュメントに対して行うとインデックス作成に時間がかかります。PoCの限られた期間内で成果を出すためには、以下のステップを推奨します。
- まずは固定長でベースラインを作成。
- 検索失敗（回答精度が低い）事例を分析。
- 原因が「文脈分断」にある特定のドキュメント群に対してのみ、セマンティック分割を適用。
全てを最初から完璧にする必要はありません。ボトルネックになっている箇所に高コスト・高精度の技術を投入する。これがシステム思考に基づくアーキテクチャ設計であり、ビジネス価値を最速で生み出すアプローチです。
ベストプラクティス③：Parent Document Retrieverによるハイブリッド戦略
ここで、チャンクサイズのジレンマ（検索しやすさ vs 理解しやすさ）を一挙に解決しうる、非常に強力なアーキテクチャを紹介します。それがParent Document Retrieverです。
「検索は小さく、生成は大きく」の原則
これまで述べてきたように、検索（Retrieval）には「小チャンク」が有利で、LLMによる生成（Generation）には文脈を含んだ「大チャンク」が有利です。この矛盾する要件を満たすために、検索用と生成用のデータを分離します。
小チャンクでヒットさせ、親チャンクをLLMに渡す仕組み
Parent Document Retrieverの仕組みは以下の通りです。
- 親ドキュメント（Parent）: 元のドキュメントを大きめのサイズ（例：2000トークン）で分割し、データベースに保存します。これはベクトル化しません（あるいは検索用とは別に管理します）。
- 子チャンク（Child）: 親ドキュメントをさらに細かく（例：200〜400トークン）分割し、これをベクトル化して検索インデックスに登録します。
- 検索時: ユーザーの質問に対して、まず「子チャンク」をベクトル検索します。これにより、細かいキーワードや意味を高精度に捉えます。
- 生成時: ヒットした子チャンクそのものではなく、そのIDに紐づく「親ドキュメント」を引っ張り出し、LLMにコンテキストとして渡します。
これにより、「ピンポイントで検索し、広範な文脈を読んで回答する」という、人間が行っているような情報処理が可能になります。
情報の断片化を防ぐ究極の解決策
この手法は、LangChainやLlamaIndexで標準的にサポートされており、実装難易度もそこまで高くありません。データ容量は増えますが（親と子の両方を保持するため）、ストレージコストはLLMの推論コストに比べればわずかです。
一般的な傾向として、このParent Document Retrieverへの切り替えが、精度向上のブレイクスルーとなるプロジェクトは多数存在します。特に、「ドキュメントのどの部分に答えがあるかわからないが、答えを見つけたらその周辺情報も合わせて理解したい」というニーズには最適解と言えます。
PoC評価指標：その分割で「正解」に辿り着けるか
最後に、これらのチャンク戦略が成功しているかどうかを、どうやって判断するかについて触れます。「なんとなく回答が良くなった気がする」では、エンジニアリングとは言えません。
感覚値ではなく数値で評価する重要性
PoCのゴールは、本番開発への投資判断材料を提供することです。そのためには、「精度80%達成」といった定量的な指標が不可欠です。しかし、生成AIの回答評価は難しい。そこで活用すべきなのが、Ragas（RAG Assessment）などの自動評価フレームワークです。
Ragasなどの評価フレームワーク活用
Ragasは、LLMを使ってRAGパイプラインを評価するツールです。チャンク戦略の評価において特に重要な指標は以下の2つです。
- Context Recall: 期待される正解（Ground Truth）を導き出すために必要な情報が、検索されたコンテキストの中に含まれているか。
- Context Precision: 検索されたコンテキストの中に、正解に関係のないノイズがどれだけ少ないか。
これらを測定することで、「チャンクサイズを小さくしたらRecallは上がったがPrecisionが下がった（ノイズが増えた）」といったトレードオフを数値で可視化できます。
本番移行に向けたKPI設定
PoCの完了条件として、「データ前処理の最適化完了」を定義しましょう。具体的には、以下のような状態です。
- ターゲットとする質問セットに対し、Context RecallがX%以上であること。
- そのための最適なチャンクサイズ、分割手法（固定長 or セマンティック or Parent Retriever）が特定されていること。
ここまでやり切って初めて、「RAGのPoCが成功した」と言えます。
まとめ：データエンジニアリングこそがAIの性能を引き出す
AI駆動開発において、魔法のようなモデルやプロンプトに目を奪われがちですが、地味で泥臭い「データの前処理」こそが、成功と失敗を分ける分水嶺です。
- 固定長分割の限界を理解し、思考停止でデフォルト設定を使わない。
- セマンティック分割やParent Document Retrieverなど、目的に応じた手法を実験する。
- 必ず定量的な指標（Recall/Precision）で評価し、改善のサイクルを回す。
これらは手間のかかる作業ですが、ここを避けて通れば、いつまで経っても「惜しい」システムしか作れません。
もし、皆さんのチームが今まさにRAGの精度向上に悩んでいるなら、一度立ち止まってデータの切り方を見直してみてください。技術の本質を見抜き、仮説を即座に形にして検証する。その情熱と実践的なアプローチが、AIプロジェクトを成功へと導く鍵となるはずです。
コメント