RAGの回答精度が低いのはなぜ？APIコストを抑え「的外れ」を防ぐチャンクサイズ最適化の数理

「マニュアルは全部読み込ませました。ベクトルDBも最新のものを使っています。それなのに、なぜAIはこんなに的外れな回答をするんでしょうか？」

実務の現場では、企業のDX推進担当者から同様の相談を受けることが少なくありません。最新のLLM（大規模言語モデル）を採用し、高価なインフラを整えてPoC（概念実証）を行っていても、期待通りの結果が得られないケースが見られます。「検索ヒットはするが、欲しい答えが含まれていない」「関連性の低い情報をつぎはぎして、もっともらしい嘘（ハルシネーション）をつくる」といった事象に悩まされることがあるようです。

もし、同様の課題に直面しているなら、それはLLMの性能不足でも、データの質だけの問題でもないかもしれません。多くの場合、原因はもっと「物理的」な部分にある可能性があります。

それは、「チャンクサイズ（Chunk Size）」と「トークン上限（Token Limit）」の設定ミスです。

RAG（検索拡張生成）システムにおいて、ドキュメントをどのように分割（チャンク化）してAIに渡すかは、料理人が食材をどうカットして鍋に入れるかと同じくらい重要です。大きすぎれば火が通らず（コンテキストあふれ）、小さすぎれば何の食材か分からなくなります（文脈の欠落）。

本記事では、多くのエンジニアが見落としがちな「数値のカラクリ」に焦点を当てます。なぜチャンクサイズが検索精度を支配するのか、そしてAPIコストを最小限に抑えつつ、回答品質を最大化するための「論理的な最適解」をどう導き出すのか。AI導入コンサルタントとして、顧客体験の向上と業務効率化の両立を支援してきた知見をもとに、そのメカニズムを解き明かしていきます。

なぜRAGの精度は「チャンクサイズ」に依存するのか

RAGシステムの構築において、多くのエンジニアが「どの埋め込みモデル（Embedding Model）を使うか」や「どのベクトルDBが速いか」にはこだわります。しかし、「データをどのサイズで切るか」については、デフォルト設定のまま放置しがちです。

昨今のトレンドとして、知識グラフを活用して情報の関係性を保持するGraphRAGや、画像や図表も統合して扱うマルチモーダルRAGといった技術進化が注目されています。しかし、これら高度な手法を検討する以前に、基礎となる「データの切り出し方（チャンク戦略）」が適切でないために精度が出ないケースは珍しくありません。これこそが、精度低下の最大の要因であると言えます。

「検索しても見つからない」の正体

まず、検索システムにおける「情報の粒度」について考えてみましょう。

例えば、数百ページある製品仕様書をRAGに読み込ませるとします。もし、チャンクサイズを「1ページ単位」で区切った場合、どうなるでしょうか？ ユーザーが「エラーコードE-01の原因は？」と質問したとき、そのエラーコードが含まれるページ全体がヒットします。しかし、そのページには他のエラーコードや無関係な注意書きも大量に含まれているかもしれません。

ベクトル検索は、チャンク全体の「意味の平均値」のようなものを計算するため、ノイズが多いと、本当に重要な「E-01」の特徴が薄まってしまい、検索ランキングの下位に沈んでしまうのです。

逆に、チャンクサイズを「1文単位」で細かく区切りすぎたらどうなるでしょう？ 「電源を入れ直してください」という文だけがヒットしても、それが「どのエラーに対する対処法なのか」という前後の文脈（コンテキスト）が失われてしまいます。これでは、AIに渡される情報は「意味不明な断片」でしかありません。

これが、検索精度（Recall/Precision）が低下するメカニズムです。情報の粒度が適切でないと、LLMは文脈を理解できず、正解を導き出せません。 この「文脈の分断」こそが、従来の単純なテキスト分割型RAGの限界として指摘されている点であり、文脈や関係性を保持するGraphRAGなどが台頭してきた背景でもあります。

トークン上限と「情報の消失」リスク

さらに厄介なのが、LLM側の処理能力との兼ね合いです。現在では、GPT-4o等のレガシーモデルが廃止され、長文理解や汎用知能に優れたGPT-5.2が新たな標準モデルへと移行しています。また、Claude Sonnet 4.6のように、100万トークンという非常に大きなコンテキストウィンドウを持つモデルも登場しています。

これら最新のAPIモデルは、コンテキスト上限近辺で自動的にサマリーを生成するCompaction機能や、タスクの複雑さに応じて思考の深さを自動調整するAdaptive Thinkingなどを備え、大量の情報を処理する能力が飛躍的に向上しています。しかし、だからといって無制限に情報を詰め込めば良いわけではありません。

大きなチャンクサイズ（例：数千トークン）を設定すれば、文脈は保持されやすいですが、検索結果として複数のチャンクをLLMに渡そうとすると、入力トークンの上限を圧迫します。また、大量のコンテキストの中に正解が埋もれてしまい、AIがそれを見つけ出せない「Lost in the Middle（情報の消失）」という現象も依然として注意すべき課題です。いくらモデルが高性能化しても、不要なノイズを含めずに精度の高いコンテキストを渡すことが求められます。

コストと精度のトレードオフ構造

そして、ビジネスで運用する上で無視できないのがコストです。多くのLLM APIは、入力トークン数に応じて課金されます。最新モデルの中には、Claude Sonnet 4.6のように旧世代の最上位モデル（Opus）級の性能を5分の1以下のコストで実現するものも登場していますが、それでも無駄なトークン消費は運用コストの増大に直結します。

• チャンクサイズが大きい場合: 検索ヒット時の入力トークン数が増え、APIコストが跳ね上がります。また、無関係なノイズ情報も多く含まれるため、LLMが混乱しやすくなります。
• チャンクサイズが小さい場合: コストは抑えられますが、必要な情報が複数のチャンクに分断され、AIが回答を生成するための十分な材料を得られなくなります。

つまり、RAGの最適化とは、この「文脈保持（精度）」と「トークン節約（コスト）」の間の、最適なバランスポイントを見つける作業に他なりません。最新のトレンド技術を取り入れたり、より高性能なAPIモデルへ移行したりする前に、まずはこの基礎的なパラメータ設定を理解し、最適化することが成功への近道と言えるでしょう。

【基礎用語】RAGを構成する数値の定義

議論を深める前に、RAGのチューニングにおいて避けて通れない3つの数値指標について、改めて定義しておきましょう。これらは単なる技術用語ではなく、互いに密接に絡み合う「依存変数」です。

トークン（Token）：LLMが理解する最小単位

私たちは文字数（Character）で長さを測りますが、LLMは「トークン」で世界を認識しています。ここでの最大の落とし穴は、言語によってトークン効率が劇的に異なることです。

英語の場合、1単語はおおよそ1トークンに近いですが、日本語の場合は複雑です。ひらがな、カタカナ、漢字が混じるため、一般的に英語よりもトークン数が多くなる傾向があります。例えば、「AI」は1トークンですが、「人工知能」はモデル（例えばOpenAIの標準的なトークナイザーなど）によっては3トークン以上消費することがあります。

多くの開発者が犯すミスは、「文字数制限」でチャンクを切ってしまうことです。「500文字で切ろう」と設定しても、実際のトークン数は800トークンを超えているかもしれません。これがAPIエラーや課金超過、そしてコンテキストあふれの主原因となります。必ずtiktokenなどのライブラリを使用し、使用するモデルのトークナイザーに合わせて正確に計算する必要があります。

チャンク（Chunk）：検索精度の最小単位

チャンクとは、元のドキュメントをベクトル化（Embedding）する際の分割単位です。これが、ベクトル検索における「1つのレコード」になります。

重要なのは、「チャンクサイズ ＝ 検索の解像度」であるという点です。解像度が高すぎれば（サイズ小）全体像が見えず、解像度が低すぎれば（サイズ大）ぼやけてしまいます。一般的には、トークン数（例：512, 1024）で指定しますが、後述するように「意味のまとまり」で切ることが理想です。

コンテキストウィンドウ（Context Window）：記憶の許容量

LLMが一度のやり取りで「記憶」しておけるトークン量の上限です。ChatGPTやClaudeでは、10万トークン（数十万文字相当）を超える膨大な情報を扱えるようになり、以前のモデルとは比較にならないほどの長文を読み込めるようになりました。しかし、「容量が大きい」ことと「すべてを正確に扱える」ことは別問題であり、これに甘えてはいけません。

スタンフォード大学などの研究で指摘されている「Lost in the Middle」現象をご存じでしょうか。コンテキストウィンドウがどれだけ広くても、重要な情報が入力データの「真ん中」あたりにあると、LLMが見落とす確率が高まるという現象です。つまり、「ウィンドウが広いから、巨大なチャンクをたくさん放り込めばいい」という考えは、精度低下を招く危険な落とし穴なのです。最新の大規模モデルであっても、RAGにおいては「必要な情報だけを厳選して渡す」という原則は変わりません。

【検証データ】チャンクサイズと検索精度の相関関係

では、具体的にどのサイズに設定すれば良いのでしょうか？ LlamaIndexをはじめとする主要なRAGフレームワークのコミュニティや、AI研究機関が公開しているベンチマークデータから、チャンクサイズと精度の間には明確なトレードオフの関係があることが分かっています。

ここでは、一般的なトークン数ごとの特性を分析します。

小サイズ（128-256トークン）のメリット・デメリット

特徴: 非常に細かい粒度で情報を切り出します。文単位や短いパラグラフに相当します。

• メリット: 「製品の型番」や「用語の定義」といった、具体的かつ局所的な情報を問う質問に対して非常に高い検索精度（Retrieval Accuracy）を発揮します。余計な情報を含まないため、ベクトル類似度の計算においてノイズが少なく、特定のキーワードに対する感度が高まるためです。
• デメリット: 複雑な推論や文脈理解を要する質問には弱くなります。「AとBの関係性は？」といった質問に対し、Aの記述とBの記述が別々のチャンクに分断されてしまい、AIがその繋がりを認識できないケースが発生します。情報の断片化により、LLMが回答生成時に「コンテキスト不足」に陥るリスクが高まります。

中サイズ（512-1024トークン）のバランス特性

特徴: 段落から1ページ弱程度の分量です。多くのRAGシステムで標準的に採用されるサイズ感です。

• メリット: 多くのビジネス文書において、ひとつのトピックや主張が完結するサイズです。文脈（コンテキスト）をある程度保持しつつ、検索時のノイズ混入も防げるため、精度のバランスが良い「スイートスポット」と言えます。特に日本語のドキュメントにおいては、500〜1000文字程度が一つの意味のまとまりになりやすいため、まずはこのレンジから検証を始めることが推奨されます。
• デメリット: それでもなお、長文の契約書や、複数のセクションにまたがる因果関係を扱う場合には、情報が途切れる可能性があります。また、複数の異なるトピックが混在する密度の高い文書では、検索対象がぼやけ、ピンポイントな回答が得にくくなる場合があります。

大サイズ（2048トークン以上）のリスクと適用シーン

特徴: 複数ページにわたる情報をひとまとめにします。

• メリット: 文脈の欠落はほぼ起きません。文書全体の要約タスクや、広範な傾向を分析させる場合には有効です。LLMに一度に多くの情報を渡せるため、包括的な回答生成が期待できます。
• デメリット: 検索精度における「関連性スコア」が著しく低下するリスクがあります。ユーザーの質問に関連する重要なキーワードが含まれていても、その他の大量の無関係なテキストによってベクトルの特徴が薄まり（埋没し）、検索順位が下がってしまう現象が起きます。さらに、RAGの回答生成時にLLMが処理すべきトークン量が増えるため、レスポンスの遅延（レイテンシ）とAPIコストの増大を招きます。

結論として、日本語の一般的なビジネスドキュメントを扱う場合、512〜1000トークン程度が最もリスクの少ない開始点と言えます。しかし、これはあくまで目安に過ぎません。文書の構造（見出しの頻度や段落の長さ）によって最適な値は変動するため、実際のデータを用いた評価が不可欠です。

【応用用語】精度を底上げする分割テクニック

単にサイズを調整するだけでは、RAGの精度向上には限界があります。ここで、プロフェッショナルが用いる「分割のテクニック」をいくつか紹介しましょう。これらを知っているかどうかで、システムの実用性は大きく変わります。

チャンクオーバーラップ（Chunk Overlap）：文脈の滑らかな接続

ドキュメントを機械的に分割すると、重要な文脈がちょうど分割点で切れてしまうことがあります。

例：「この機能を使用する際の注意点は、以下の通りです。（ここで分割）１．必ず電源を切ること...」

これでは、後半のチャンクだけ検索された場合、「何の機能の注意点か」が分かりません。これを防ぐために、前のチャンクの末尾10〜20%程度を、次のチャンクの冒頭に重複（オーバーラップ）させて含める手法が一般的です。LlamaIndexやLangChainなどのフレームワークでも、デフォルトで設定できるようになっています。

なぜ10〜20%なのか？ これは経験則的な「黄金比」に近いものですが、あまり大きくしすぎると情報の重複が増えてトークンを無駄遣いし、小さすぎると文脈接続の効果が薄れるため、このあたりが妥当解とされています。

セマンティック分割（Semantic Splitting）：意味の切れ目で切る技術

固定の文字数やトークン数で切るのではなく、「意味のまとまり」で切る手法です。テキストの内容を解析し、話題が変わるポイントや段落の変わり目を検知して分割します。

例えば、Markdownのヘッダー（# や ##）を基準に分割したり、Embeddingモデルを使って文ごとの類似度を計算し、類似度が大きく変化した箇所を分割点とする高度な手法（Semantic Chunking）もあります。人間が本を読むときのように「章」や「節」で情報を区切るため、AIにとっても理解しやすいデータ構造になります。特にマニュアルや仕様書など、構造化された文書には絶大な効果を発揮します。

親文書検索（Parent Document Retrieval）：検索と生成の分離

これが現在、最も効果的とされる手法の一つです。「検索のためのデータ」と「回答生成のためのデータ」を分けるという発想です。

1. 検索用には「小さなチャンク」を用意します。これにより、細かいキーワードでも高精度にヒットさせます。
2. 回答生成用には、そのチャンクが属する「親文書（大きなチャンク）」をLLMに渡します。

つまり、「検索のしやすさ」と「文脈の理解しやすさ」を切り離して管理するのです。小さな手がかり（小チャンク）で見つけ出し、全体像（親文書）を読んで回答する。この仕組みを導入することで、情報の断片化問題とノイズ問題の多くを同時に解決できます。実装難易度はやや上がりますが、精度の壁にぶつかっているなら検討すべき筆頭の策です。

【結論】自社データに最適なパラメータを見つける手順

RAGのチューニングに「万人に共通する正解」は存在しません。扱うドキュメントがQ&A集なのか、技術仕様書なのか、あるいは社内日報なのかによって、最適な戦略は異なります。

しかし、最適解にたどり着くための「手順」は確立されています。以下のステップで進めることを強く推奨します。

1. ドキュメントの特性による仮説設定

まず、対象データの構造を確認してください。

• 構造化データ（Q&A、CSV等）: 質問と回答がペアになっているため、チャンクサイズは小さくても問題ありません。むしろ、1レコード1チャンクが理想です。
• 非構造化データ（マニュアル、規定集）: 文脈が重要です。まずは512トークン、オーバーラップ50〜100トークン程度から開始するのが定石です。

2. 「Ragas」等の評価フレームワークの導入

「なんとなく良くなった気がする」という感覚的な評価は危険です。Ragas (RAG Assessment) などの評価フレームワークを使用し、数値を計測しましょう。特に以下の指標が重要です。

• Faithfulness（忠実性）: 生成された回答が、検索されたコンテキストに基づいているか。
• Answer Relevance（回答関連性）: 生成された回答が、ユーザーの質問に対して適切か。

パラメータを変更するたびにこれらのスコアを計測し、変化を記録します。これにより、「サイズを上げたら関連性が落ちた」といった因果関係が可視化されます。

3. スモールスタートでのパラメータチューニング

最初から全データを投入してはいけません。代表的なドキュメントを数点選び、チャンクサイズを[256, 512, 1024]と振って、特定の質問セットに対する回答精度を比較します。

「回答が短い、断片的だ」と感じたらサイズを上げ、「関係ない情報が混ざる」と感じたらサイズを下げるか、オーバーラップを増やしてください。

まとめ

RAGの精度向上は、魔法のようなプロンプトエンジニアリングだけで成し遂げられるものではありません。地味に見える「データの切り方」こそが、AIのパフォーマンスを決定づける土台となります。

トークンというコスト（通貨）を賢く使い、チャンクという情報の器を最適化することで、あなたのRAGシステムは初めて「頼れるパートナー」へと進化します。まずは現在の設定値を確認し、それが「なんとなく」決められたものでないか、見直すところから始めてみてください。それが、成功への第一歩です。