RAGの現在地と
「文脈の断片化」という罠

「社内規程やマニュアルを読み込ませて、自社専用のAIチャットボットを作りたい」。この数年、多くの企業がこうしたプロジェクトに取り組んできました。そして試験導入を終えた現場から、二つの不満が繰り返し聞こえてきます。「回答が遅い」と「ときどき大事な条件を見落とす」です。

前者の不満から、2026年9月に登場した判断特化AI「Jev」に注目し、「RAGにJevを組み込めば速くなるのではないか」と考える方が増えています。方向性は正しいのですが、どこにJevを入れるかで成果は大きく変わります。本特集では、その答えを全5章で示します。第1章では、まずRAGの仕組みを整理し、何が遅く、何を取りこぼしているのかを診断します。

AI検索の標準「RAG」の仕組み

ChatGPTやClaudeのような大規模言語モデル（LLM）は、世の中の一般的な知識を幅広く持っています。しかし、あなたの会社の最新の就業規則や、まだ公開していない製品マニュアルの中身は知りません。学習データに含まれていないからです。

そこで、LLMに自社の知識を「その場で」渡すための技術がRAG（Retrieval-Augmented Generation：検索拡張生成）です。名前のとおり、検索・拡張・生成の3工程で動きます。

テストに持ち込む「カンペ」の比喩

RAGは、持ち込み可の試験を受ける学生にたとえると理解しやすくなります。学生（LLM）は教科書の中身をすべて覚えてはいません。そこで設問を読んだら、手元の資料から関係しそうなページを探し（Retrieval）、そのページを設問の横に広げ（Augmented）、資料を見ながら答案を書きます（Generation）。

1. Retrieval（検索）：「出張手当はいくら？」という質問に対し、社内文書の中から関連する資料を探し出します。
2. Augmented（拡張）：見つけた資料を、質問と一緒にプロンプトへ入れてLLMに渡します。
3. Generation（生成）：LLMは渡された資料を根拠に回答文を作ります。

資料という根拠があるため、LLMがもっともらしい嘘をつく「ハルシネーション」を減らせます。これがRAGが企業AIの標準構成になった理由です。ただし、この比喩には落とし穴が隠れています。学生に渡されるのは教科書そのものではなく、切り抜いた数枚のページだという点です。

典型的なRAGパイプライン

実際のシステムでは、事前準備（オフライン）と質問応答（オンライン）の二つの流れがあります。事前準備では、文書を数百文字ほどの断片（チャンク）に切り分け、それぞれを埋め込みモデルで数値ベクトルに変換して、ベクトルデータベースに保存します。質問が来ると、質問文も同じようにベクトル化し、意味の近いチャンクを上位k件（top-k）取り出してLLMに渡します。

RAGはどこで遅くなるのか

「RAGが遅い」と感じたとき、真っ先に疑われるのはベクトル検索です。しかし多くの場合、ボトルネックはそこではありません。質問文の埋め込みとベクトルDBの近傍検索は、適切に構成すればミリ秒単位で終わる処理です。時間とお金を使っているのは、ほぼ例外なくLLMの呼び出しです。

精度を補う工程がLLM呼び出しを増やす

素朴なRAGは、質問に対してLLMを1回呼ぶだけで済みます。ところが本番運用で精度が足りないと分かると、チームは改善策を積み重ねていきます。質問をLLMで言い換えて検索しやすくする「クエリ書き換え」、取り出した候補をLLMや専用モデルで並べ直す「リランク」、検索結果が不十分ならLLMが自分で検索をやり直す「エージェント型RAG」などです。どれも有効ですが、一つ足すたびに文章を生成するLLMの呼び出しが増えます。

文章生成型のLLMは、1トークンずつ順番に出力を作るため、短い判断であっても数秒かかることが珍しくありません。エージェント型RAGで検索と判断のループを3回回せば、利用者は回答の1文字目を見るまでに十秒以上待つことになります。精度を上げようとするほど遅く、高くなる。これが現在のRAGが陥りやすい構図です。

表1から分かるとおり、高速化の余地は「判断のために文章生成LLMを呼んでいる工程」に集中しています。言い換え、並べ替え、検索をやり直すかどうか。これらは本来、文章を書く必要のない選択や採点の問題です。ここに、文章を一切生成せず判断だけを返すJevが入り込む余地があります。Jevの仕組みは第3章で詳しく扱います。

「文脈の断片化」という罠

RAGのもう一つの不満、「大事な条件を見落とす」はどうでしょうか。こちらは速度よりも根が深い問題です。原因は、RAGの前提であるチャンク分割とベクトル検索そのものにあります。

出張規程の「ただし書き」が消える

次のような社内規程があるとします。第1項に「国内出張の宿泊費は一律1万円とする」とあり、数ページ離れた第5項に「ただし、役員の場合は第1項にかかわらず実費精算とする」と書かれています。人間なら規程全体に目を通して、例外を見落とすことはまずありません。

ところがRAGでは、規程は数百文字ごとのチャンクに切られています。社長が「私の出張宿泊費はいくら？」と尋ねると、ベクトル検索は「出張」「宿泊費」という語に強く反応し、第1項のチャンクを最上位に返します。第5項は「役員」「実費精算」が中心の短い文で、質問文との類似度はそれほど高くなりません。上位k件の枠から漏れれば、LLMは第1項だけを読んで「1万円です」と答えます。根拠の資料を正しく引用しているため、回答は一見もっともらしく、誤りに気づきにくいのが厄介な点です。

なぜ「木を見て森を見ず」になるのか

この問題の本質は、ベクトル検索が一つひとつの断片と質問の近さだけで判断する点にあります。「この規程には例外条項がある」「第5項は第1項を上書きする」といった、断片同士の関係は、どのベクトルにも記録されていません。条文の参照関係、表の注記、章をまたぐ定義、改訂履歴の「旧規定は廃止」といった情報は、切り分けた瞬間に失われます。

LLMは渡された断片の中では非常に賢く振る舞いますが、渡されなかった情報について考えることはできません。細切れにされた木だけを見せられたAIに、森全体のルールを把握させることは原理的に難しいのです。

チャンクサイズ調整の限界

では、チャンクを大きくすれば解決するでしょうか。残念ながら、チャンクサイズは典型的なトレードオフで、どこに設定しても何かを犠牲にします。

表2の最下行が示すとおり、断片化を根本から解消できるのは「文書を切らない」選択だけです。しかし文書を丸ごとベクトル化すると、長い文書の特徴が平均化されて検索が当たらなくなります。文書を切らずに、正しい文書へたどり着く別の方法が必要になるわけです。

参考までに、多くのRAG実装で最初に書かれる素朴なチャンク分割は次のようなものです。固定長で機械的に切るため、条文の途中でも容赦なく分断されることが分かります。

def chunk_text(text: str, size: int = 400, overlap: int = 50) -> list[str]:
    """固定長でテキストを切り分ける素朴な実装。"""
    chunks = []
    start = 0
    while start < len(text):
        end = start + size
        chunks.append(text[start:end])   # 条文や表の途中でも切れる
        start = end - overlap            # 重なりで境界の欠落を少し緩和
    return chunks


rules = open("travel_rules.txt", encoding="utf-8").read()
for i, c in enumerate(chunk_text(rules)):
    print(i, c[:30])  # 第1項と第5項は別々のチャンクに入る

Jevを足すだけでは解けない

ここで、本特集のキーワードである「RAG Jev」に話を戻します。Jevは、文章を生成せず、選択（choice）・採点（score）・真偽確率（noul）という型付きの判断だけを返すモデルです。ベンダー公表値では1回の判断が70〜500ミリ秒で終わり、入力100万トークンあたり0.042ドル、出力は無料とされています。秒単位のLLM呼び出しを置き換えられれば、速度とコストの改善幅は大きくなります。

リランカーへの置き換えは「速くなる」が「正しくはならない」

最も手軽な統合案は、ベクトル検索の上位候補をJevで採点し直す、つまりリランカーとして使う方法でしょう。表1のリランク工程をJevに任せれば、LLMによるリランクより速く、安くなる可能性は十分にあります。

しかし、この構成では断片化の問題は手つかずのまま残ります。Jevが並べ替えられるのは、ベクトル検索がすでに拾ってきた候補だけです。最初の検索で第5項が上位k件から漏れていれば、どれほど賢いリランカーでも救い出すことはできません。候補を作る段階が断片の類似度に依存している限り、速く間違えるシステムになるおそれがあります。

「検索」から「探索」への転換

「細切れにするからいけないのだ。文書を丸ごと読ませればよい」。LLMが長い文脈を扱えるようになったことで、この考え方が現実的になってきました。ただし、数千件の文書をすべてプロンプトに入れることはできません。そこで登場したのが、検索エンジンの出した断片を受け身で読むのではなく、AI自身が人間のように目次を開き、関係する章を探し、必要な文書を丸ごと読むというアプローチです。

「Don't Retrieve, Navigate」という発想

この「検索するな、探索せよ」というパラダイムを、エンタープライズ向けに具体化したのがCorpus2Skillです。文書コーパスを事前に階層型のスキルツリーへコンパイルし、LLMエージェントが目次をたどって文書へ到達します。文書はチャンクに切られず、回答は原文全文を根拠に作られるため、ただし書きの見落としが起きにくい構造です。論文では、11データセットを使った比較で5勝3分3敗という結果が報告されています。特定の業務領域にまとまり、話題の構造を持つ社内文書に強い一方、オープンドメインの雑多な事実の集合や、均質な表形式データではフラットな検索が優位とされています。万能ではないものの、社内規程やマニュアルのような文書には有力な選択肢です。

そして、この探索の各ステップ、つまり「どの章を開くか」「どの文書を読むか」は、文章を書く必要のない選択の問題です。ここにこそ、Jevが本来の力を発揮する場所があります。ベクトル検索にJevを足すのではなく、Corpus2Skillの探索役にJevを据える。これが本特集の提案する「RAG×Jev」の答えです。