チャンク分割、リランキング、ハイブリッド検索：RAGを実用レベルにする

多くのRAG実装は、うまく機能していません。モデルに問題はありません。ClaudeやGPT-5は、検索された文書に基づいて問題なく回答できます。失敗するのは検索です。質問すると、システムが誤ったチャンクを返し、モデルは誤った情報に基づいて自信満々な回答を生成します。

この記事では、質の低い検索を改善する3つの要素、チャンク分割戦略、リランキング、ハイブリッド検索を実践的に解説します。これらを正しく設定すれば、「自分たちのユースケースではRAGが機能しない」という不満の大半は解消します。

技術的な数式の詳細は省き、実際に何をすべきかに焦点を当てます。

検索が失敗する理由

標準的なRAGパイプラインは次のとおりです。

1. 文書をチャンクに分割します。
2. 各チャンクを埋め込みベクトルに変換します。
3. 質問を受け取ったら、それも埋め込みベクトルに変換し、最も類似するチャンクを探します（コサイン類似度）。
4. そのチャンクをLLMへ渡します。

各ステップには失敗する可能性があります。

不適切なチャンク分割では、チャンクが短すぎて役に立たないか、長すぎて一貫性を失います。論理的な概念の途中で分割され、どちらの断片も適切に検索されないこともあります。

単純な類似度検索では、クエリと同じ語彙を含むものの、実際には関連性のないチャンクが見つかります。「サブスクリプションを解約する方法」というクエリで、「サブスクリプション」という語を含むだけの無関係なマーケティング文が検索される可能性があります。

リランキングなしでは、類似度検索が返した結果をそのままLLMが見ることになります。最も類似するチャンクが、常に最も関連性の高いチャンクとは限りません。

セマンティック検索のみでは、重要な完全一致のキーワードを見逃します。「エラーコード503」というクエリは、そのまま「エラーコード503」と記載されたチャンクを見逃す可能性があります。クエリのセマンティックベクトルと、そのチャンク全体のトピックが一致しないためです。

より適切なチャンク分割、リランキング、ハイブリッド検索という3つの改善策が、それぞれの問題に対処します。

改善策1：より適切なチャンク分割

チャンク分割はRAGパイプラインの中で最も大きな影響を与える判断ですが、多くの人は結果が悪くなるまで意識しません。

多くのノーコードツールでは、固定トークン数（たとえば、500トークン、50トークンのオーバーラップ）で分割する単純な方法が標準です。ある程度は機能しますが、頻繁に問題が起きます。

より優れた戦略を紹介します。

セマンティックチャンク分割

任意のトークン数ではなく、トピックが変わる位置という意味上の境界で文書を分割します。最新のフレームワーク（LangChain、LlamaIndex）の多くには、トピックの変化を検出して分割するセマンティックチャンカーがあります。

利点は、チャンクに完結した概念が含まれることです。モデルには、議論の半分だけではなく、一貫した文脈が渡されます。

構造を考慮したチャンク分割

文書に自然な構造（Markdownの見出し、HTMLのセクション、PDFの章、コードの関数境界）がある場合は、それを利用します。トークン数ではなく、セクション単位で分割してください。

Markdownの場合：

• 各H2セクションを1つのチャンクにします（H1の文脈を先頭に追加）。
• 長いH2セクションはさらに分割し、文脈としてH2見出しを繰り返します。

コードの場合：

• 各関数またはクラスを1つのチャンクにします。
• チャンクにはファイルパスとimport文を含めます。

構造化されたコンテンツでは、固定サイズで機械的に分割するより、はるかに優れた結果になります。

階層型チャンク分割

近年のRAG研究から生まれたパターンです。複数の階層でチャンクを作成します。

• 小さいチャンク（200～500トークン）：正確な検索に使います。
• 中サイズのチャンク（1000～2000トークン）：文脈の提供に使います。
• 文書の要約（50～100トークン）：大まかな一致に使います。

検索時には小さいチャンクと照合しますが、周囲の中サイズのチャンクを返します。LLMには、正確な関連箇所と、それを理解するのに十分な文脈の両方が渡されます。

チャンクサイズの選び方

コンテンツの種類別のおおまかな目安は次のとおりです。

チャンク分割が見えないノーコードツールを使っている場合は、答えがコーパス内にあると分かっている質問を10件試してください。適切なチャンクがたびたび検索されないなら、チャンク分割が問題です。

効果的なパターン：「ページまたはセクション単位、その後に質問ベース」

ほとんどのパーソナルRAGで有効なパターンは次のとおりです。

1. 文書のセクション（MarkdownのH2、PDFの章など）でチャンク分割します。
2. 約2000トークンを超えるチャンクは、段落単位でさらに分割します。
3. 各チャンクの先頭に、文脈として文書タイトルとセクション見出しを追加します。
4. このチャンクがどのような質問に答えるかを短く説明する文を追加します（インデックス作成時に高速なLLMで自動生成）。

「このチャンクが答える質問」を自動生成する手法は、驚くほど利用されていませんが、非常に強力です。ユーザーのクエリは質問形式で表現されることが多いため、生の文書テキストより、質問形式のメタデータと照合する方が正確になるからです。

改善策2：リランキング

最初の検索（通常、ベクトル類似度に基づいて20～50件のチャンクを返す）の後に、リランカーを使い、クエリとの実際の関連性に基づいて並べ替えます。

リランカーは別のモデルで、通常はより小さく、特定用途に特化しています。（クエリ、チャンク）の組を受け取り、関連性スコアを出力します。上位20～50件の結果に適用し、新しいスコアで並べ替え、上位3～5件をLLMへ渡します。

利点は、適合率が大幅に向上することです。ベクトル類似度は高速ですが、それほど正確ではありません。リランカーは低速ですが、はるかに正確です。組み合わせることで、高速な検索と正確な順位付けの両方を実現できます。

2026年時点のリランカーの選択肢は次のとおりです。

• Cohere Rerank — 実績のあるAPIベースのリランカーです。検索1,000件あたり$2.00（標準価格、2026-07-10確認）。
• Voyage AI rerank-2 — 強力な商用の選択肢で、専門領域ではCohereを上回る場合もあります。
• bge-reranker-v2-m3 — オープンソースで、ローカル環境または低価格のホスティングで実行できます。
• Jina Reranker — もう1つの強力なオープンソースの選択肢です。

一般的なパイプラインは次のようになります。

1. ベクトル検索が上位50件のチャンクを返します（低コスト、高速）。
2. リランカーが50件すべてをクエリに対して採点します（比較的高コスト、低速）。
3. リランキングスコア上位5件をLLMへ渡します。

追加される合計レイテンシは約200～500msです。品質は、検索精度のベンチマークで20～40%向上することがよくあります。

標準でリランキングを含まないノーコードツール（NotebookLM、基本的なn8n構成の多く）では、これが最も効果の高いアップグレードです。n8nにはCohere Rerankノードがあり、LangChainとLlamaIndexにはリランカー連携が標準で用意されています。

改善策3：ハイブリッド検索

ベクトル類似度は意味の一致を捉えます。キーワード検索（BM25など）は完全一致を捉えます。それぞれ、もう一方が捉える情報を見逃すことがあります。

「ゲートウェイのHTTP 503エラーを修正する方法」というクエリの場合：

• ベクトル検索は、HTTPエラー、ゲートウェイの問題、トラブルシューティングに関するチャンクを見つけます。
• キーワード検索は、特に「503」と記載されたチャンクを見つけます。それが実際の答えである可能性があります。

ハイブリッド検索は両方を実行し、結果を統合します。統合にはReciprocal Rank Fusion（RRF）という方法を使います。各方式の順位を受け取り、両方のシグナルを考慮した統合順位を生成します。

ほとんどのツールでは、実装は単純です。

• ベクトル検索を実行 → 順位付きリストAを取得。
• BM25／キーワード検索を実行 → 順位付きリストBを取得。
• 各チャンクについて、RRFスコア＝1/(k + rank_in_A) + 1/(k + rank_in_B)を計算（kは通常60）。
• 統合スコアで並べ替え、上位の結果を返します。

2026年には、以下がハイブリッド検索を標準でサポートしています。

• Weaviate（ベクトルストア）— 標準機能としてハイブリッド検索を提供します。
• Qdrant — フィルタリングによるハイブリッド検索に対応します。
• Pinecone — スパースベクトルによるハイブリッド検索に対応します。
• Elastic／OpenSearch — キーワード検索とベクトル検索を組み合わせます。
• n8nのRAGテンプレートの多く — 最新のテンプレートではハイブリッド検索が標準です。

利点は、特定の識別子、コード、名前、専門用語を含むクエリの再現率が大幅に上がることです。技術コンテンツ（コード、エラーコード、製品名、規制上の参照）では、ハイブリッド検索が実質的に必須です。

クエリに完全一致すべき特定の用語（数字、名前、コード、正確な語句）がよく含まれるユースケースでは、ハイブリッド検索を有効にしてください。コストは低く、効果は大きいです。

3つを組み合わせる

2026年の最先端のRAGパイプラインは次のとおりです。

クエリ
  ↓
クエリ書き換え（任意 — クエリを整え、略語を展開）
  ↓
ハイブリッド検索：ベクトル検索＋キーワード検索
  ↓
上位30〜50件
  ↓
リランカー
  ↓
リランカースコア上位5件
  ↓
取得したチャンク＋クエリをLLMへ入力
  ↓
引用付きの回答

個々のステップは低コストです。組み合わせると、「ベクトル類似度 → 上位5件 → LLM」とは質的に異なる検索品質を実現します。

使用頻度は低いものの、強力な追加機能もあります。

クエリ拡張。 ユーザーのクエリを複数の表現に書き換え、それぞれを検索します。異なる言い回しを捉えられます。

複数ステップ検索。 複雑な質問では、複数回検索します。最初の検索でサブ質問を特定し、2回目の検索で各サブ質問への答えを取得します。

会話型検索。 複数ターンの会話では、会話履歴を検索に反映します（「先ほどXについて質問していたため、今回の質問ではXに関連するコンテンツを優先する」）。

情報源のフィルタリング。 メタデータフィルターを使って検索範囲を限定します。「『EU regulations』タグが付き、2023年以降の日付がある文書のみ検索する」などです。

これらもノーコードRAGツールで利用できるようになってきていますが、高度な機能に手を伸ばす前に、基本の3つ（適切なチャンク分割、リランカー、ハイブリッド検索）が揃っているか必ず確認してください。

RAGの品質を測定する方法

測定できないものは改善できません。実践的な評価戦略をいくつか紹介します。

「ゴールデンクエスチョン」テスト。 正解を知っている質問を20件選び、RAGに入力します。適切なチャンクが検索されたか、モデルが正しい回答を生成したかを採点します。これを毎月実施してください。

K件中の検索再現率。 各ゴールデンクエスチョンについて、答えを含むチャンクを特定します。次に、検索システムが上位K件（5、10、20）の中にそのチャンクのいずれかを返したか確認し、その割合を測定します。

LLM-as-judge評価。 より高度な方法では、強力なモデル（Claude Opus、GPT-5）に、回答が正しいか、引用が正確か、完全か、十分な根拠があるかを採点させます。代表的な質問群に対して一括実行します。評価については別の記事で詳しく解説しています。

ユーザーが感じる品質。 チーム向けまたは本番環境のRAGでは、すべての回答に高評価／低評価ボタンを追加します。低評価の傾向を確認すると、特定の質問タイプに集中しているため、そこを改善します。

最大の間違いは、測定を完全に省くことです。「悪くなさそう」は測定ではありません。測定しなければ、改善策が機能しているか分かりません。

実例：不調なRAGを改善する

自社の社内文書向けにパーソナルRAGを構築したとします。品質は今ひとつで、有用な回答が得られる質問は約60%です。次の順序で改善します。

まず検索を監査します。 品質の悪い回答を10件選び、どのチャンクが検索されたか確認します。適切なチャンクが検索されていたなら、モデルまたはプロンプトに問題があります。検索されていなければ、検索の問題です。

検索に問題がある場合：

1. チャンク分割を確認します。 チャンクに一貫性がありますか？重要な概念の途中で分割されていませんか？セマンティックチャンク分割または構造を考慮したチャンク分割へ変更します。

2. リランカーを追加します。 基本的なベクトル検索と上位5件の結果を使っているなら、検索とLLMの間にCohere Rerankまたはbge-reranker-v2-m3を追加します。通常、効果はすぐに現れます。誰かが示す一般的な割合を信じるのではなく、自分の評価セットで測定してください。

3. ハイブリッド検索を追加します。 クエリに特定の用語（製品名、エラーコード、専門用語）が含まれる場合は特に有効です。

4. インデックス作成を調べます。 チャンクにメタデータ（文書タイプ、セクション、日付）が付いていますか？検索時にメタデータフィルターを使います。

モデルに問題がある場合（適切なチャンクが検索されても、回答が誤っている）：

1. プロンプトを厳密にします。 「提供された文脈のみに基づいて回答してください。文脈で扱われていない質問の場合は、その旨を伝えてください」とモデルに明示します。

2. 引用を追加します。 使用した具体的なチャンクを引用するようモデルに求めます。デバッグに役立つだけでなく、ハルシネーションも減らせます。

3. より強力なモデルを使います。 小型で高速なモデルを使用しているなら、Claude Sonnet 4.5またはGPT-5を試します。

このような調査と修正を2～3回繰り返すと、大半のRAG実装は有用な回答率85～90%に達します。これは、ユーザーが実際にシステムを採用し、信頼するようになる水準です。

よくある間違い

多くの人が繰り返し陥る具体的な問題をいくつか紹介します。

誤ったコンテンツをインデックスに登録する。 マーケティングページ、古い文書、低品質なブログ記事などです。モデルには区別できず、インデックス内のすべてが正式な情報として扱われます。厳しく選別してください。

文書が変わってもインデックスを更新しない。 古いコンテンツを持つRAGは、自信を持って誤った回答を返します。定期的に再インデックスするか、自動同期するシステムを使ってください。

評価を無視する。 多くのRAGは測定なしで導入され、その後も改善されません。「悪くなさそう」という段階が永遠に続きます。初日から評価を組み込んでください。

検索をブラックボックスとして扱う。 「とにかく動かない」は診断ではありません。検索結果を開き、何が返っているか確認してください。ほとんどの場合、確認すれば問題は明らかになります。

早すぎる過剰設計。 最先端のパイプラインから始める必要はありません。NotebookLMまたは基本的なベクトル検索から始め、具体的なボトルネックを特定してから複雑さを追加してください。

これらが重要になる場面

より適切なチャンク分割、リランキング、ハイブリッド検索という3つの改善策は、次の状況で特に重要です。

• コーパスが技術的で、固有の専門用語がある。
• クエリに完全一致の要件（コード、名前、ID）が含まれる。
• ユーザーが正確さを重視する（法務、コンプライアンス、カスタマーサポート）。
• システムが大規模に利用される（1日に10,000回使われる場合、小さな品質向上でも大きな意味を持つ）。

次の状況では、それほど重要ではありません。

• コーパスが小さく（100文書未満）、よく整理されている。
• クエリが自由回答形式である（「Xについて当社はどう考えていますか」）。
• ユーザーが寛容で、回答を見つけるために繰り返し質問できる。
• ユースケースが正確さより探索を目的としている。

ほとんどの個人および小規模チーム向けRAGでは、基本的なベクトル類似度検索から、ベクトル検索＋リランカーへ移行することが最も効果の高いアップグレードです。次に追加すべきものがハイブリッド検索です。チャンク分割は、規模にかかわらず重要です。

まとめ

質の低いRAGは、ほぼ常に検索の質が低いことが原因です。そして検索の問題は、ほぼ常にチャンク分割、リランキング、検索方式の3つに集約されます。この3つを改善すれば、RAGの品質に関する不満の大半は解消します。

これらを適用するために、検索エンジニアになる必要はありません。Weaviate、Pinecone、Qdrant、n8nのテンプレート、LangChainの連携機能によって、こうした技術は手の届くものになりました。現在の主な障壁は、その存在を知り、意識的に適用することです。

RAGが機能しないときは、モデルのせいにしないでください。返されたチャンクを確認し、検索を修正してから、もう一度評価しましょう。