RAGと長いコンテキストの使い分け：選ぶ基準は入力長だけではない

この記事で分かること

RAGと長いコンテキストを入力可能な文字量以外で比較する方法
情報更新、検索漏れ、引用、権限、遅延、評価コストの違い
Lost in the Middleが設計判断へ与える示唆
20〜30件から始められる小規模評価の作り方

注意： モデルが長い入力を受け付けることと、入力内の必要情報を安定して使えることは別です。また、RAGを導入しただけで根拠の正しさやアクセス制御が保証されるわけでもありません。

先に結論

少数の固定文書を毎回まとめて読み、文書全体の要約や章をまたぐ比較をするなら、長いコンテキストが単純です。文書が頻繁に更新される、利用者ごとに閲覧権限が違う、回答ごとに根拠を示したい、対象が増え続けるなら、RAGが有力です。

ただし、実務では二者択一にしない方がうまくいきます。RAGで候補文書を絞り、その候補と必要な周辺部分を長いコンテキストへ渡す構成なら、検索範囲と読解範囲を分けて調整できます。

RAGと長いコンテキストを要件から選ぶ判断フロー 更新頻度、権限と引用、検索品質を順に確認し、単独方式または併用方式を選ぶ。

選定基準は最大入力長ではなく、業務上の失敗を発見し、原因を切り分けられるかです。公開順位やカタログ上の入力上限だけで決めず、自社文書を使った小規模評価で検索、読解、引用を別々に測ります。

まず用語をそろえる

RAGはRetrieval-Augmented Generationの略で、質問に関連する情報を検索し、取得した部分をモデルへ渡して回答を生成する構成です。典型的には、文書の取り込み、分割、索引作成、検索、必要に応じた再順位付け、回答生成という段階があります。

長いコンテキスト方式は、検索基盤で細かく絞らず、複数文書や長文をモデルの入力へ直接含めて処理する構成を指します。実際にはファイル選択、前処理、上限に合わせた切り詰めが行われることもあるため、「全文を必ず一字残らず読ませている」とは限りません。

Stanford CRFMのHELM Long Contextは、長い入力をサポートすることが強い長文処理能力を意味しないとして、単一段階QA、複数段階QA、長編の理解・要約、長い会話での参照解決など複数タスクで評価しています。これは、入力上限という単一の仕様値だけでは実務能力を判断できないことを示す一次情報です。

7つの比較軸

比較軸	RAG	長いコンテキスト
情報更新	索引更新の設計が必要。差分反映しやすい	入力する文書を差し替えればよいが、毎回の選択が必要
検索漏れ	関連文書を取得できず回答段階へ届かないことがある	検索漏れは減らせるが、入力内で見落とす可能性がある
引用	取得チャンクと文書IDを対応付けやすい	原文位置の保持と引用生成を別途検証する必要がある
権限	検索前後で利用者権限を適用できる	入力作成前に閲覧可能文書を厳密に絞る必要がある
遅延・費用	検索や再順位付けが増える一方、モデル入力を抑えやすい	構成は単純だが、入力増加で処理時間や利用量が増え得る
原因分析	検索失敗と生成失敗を分けられる	一連の入力処理として見えやすいが、見落とし原因の特定が難しい
運用負荷	分割、索引、検索評価、更新監視が必要	入力組み立て、上限管理、文書順序、重複除去が必要

料金、入力上限、キャッシュ、対応ファイルは製品とプランで変わるため、方式の一般論と分けて確認してください。

Lost in the Middleをどう読むか

2023年の論文「Lost in the Middle」は、長い入力に含まれる関連情報の位置を変えて、モデルが情報をどう利用するかを調べました。複数文書の質問応答と、長い入力から特定情報を取得する課題で、関連情報が入力の先頭または末尾にある場合より、中間にある場合に性能が低下する傾向を報告しています。

この研究から「すべてのモデルは中央を読めない」と断定するのは不適切です。対象モデル、課題、入力長、発表時期が限定されており、現在のモデルは別途評価が必要だからです。一方、入力可能範囲に入っているだけでは利用成功を保証できないという検証観点は現在も有効です。

自社評価では、同じ根拠を入力の先頭・中央・末尾へ置いたケースを作ります。正解率だけでなく、引用位置、不要文書に引かれた誤答、回答不能時に「不明」と言えるかも確認します。

RAGの検索漏れを分解する

RAGで正答できなかったとき、すぐモデルを変更してはいけません。少なくとも次の4段階に分けます。

収録漏れ：正解文書が索引へ入っていない、または更新が反映されていない。
分割の失敗：見出しと本文、表の行と列、例外条件と本文が別チャンクになっている。
取得の失敗：表記揺れ、略称、数値、固有名詞などのため上位候補へ入らない。
生成の失敗：正解を含む候補を渡しているのに、モデルが無視、混同、過剰推論する。

検索評価では、最終回答だけでなく「正解文書が上位k件へ入ったか」を記録します。生成評価では、正解文書を強制的に渡した条件も試します。強制条件で正答するなら検索側、強制条件でも誤るなら読解・指示・生成側が主な改善対象です。

方式を選ぶ判断フロー

1. 文書集合の変化を確認する

規程や商品情報が日々変わる、大量の文書が追加されるならRAG寄りです。月に数回、決まった数本の契約書を比較するだけなら、長いコンテキストから始める方が構成を小さくできます。

2. 権限境界を確認する

部署、案件、個人ごとに閲覧範囲が違う場合、検索候補を作る時点で権限を適用します。検索後に禁止文書を除外するだけでは、件名や断片が漏れる可能性があります。

長いコンテキストでも同じです。入力へ含めた時点でモデル処理へ渡るため、入力作成前に許可文書だけへ絞ります。「回答へ表示しなければよい」という設計では不十分です。

3. 必要な説明可能性を決める

規程QAや監査支援では、文書名、版、該当箇所を回答と結び付ける必要があります。RAGは取得記録を残しやすい一方、チャンクが文脈を欠くことがあります。長いコンテキストは広い文脈を渡しやすい一方、モデルが作った引用の正確性を原文照合する必要があります。

4. 失敗コストを決める

誤答が人の確認で止まるのか、そのまま顧客対応や処理実行へ進むのかで要求水準が変わります。高リスク用途では、根拠不足時の回答拒否、複数根拠の矛盾表示、更新日時、操作前の人による確認を必須にします。

コピペできる方式選定チェックリスト

# RAG / 長いコンテキスト選定票
- 対象文書数と総量：
- 1か月の追加・更新件数：
- 利用者ごとの閲覧権限：共通 / 異なる
- 回答に文書名・版・該当箇所が必要：はい / いいえ
- 全文要約や文書横断比較が中心：はい / いいえ
- 許容する初回応答時間：
- 1件あたりの処理上限：
- 根拠がない場合の期待動作：回答拒否 / 確認依頼 / その他
- 検索上位k件へ正解文書が入る目標：
- 重大誤答の許容件数：
- 候補方式：RAG / 長いコンテキスト / 併用

「上限が大きいから長いコンテキスト」の一文しか書けない場合は、選定根拠が不足しています。更新、権限、引用、重大失敗の4点が具体化できれば次の評価へ進めます。

小規模評価の作り方

最初は20〜30件でも構いません。ただし簡単な代表例だけに偏らせません。

代表例：頻出する規程名や通常の質問
表記揺れ：略称、旧名称、誤字を含む質問
境界例：例外条件、付表、脚注、複数章を使う質問
不在例：文書に答えがなく、回答を拒否すべき質問
権限例：存在するが、その利用者には見せてはいけない文書
位置例：同じ根拠を入力の先頭・中央・末尾に置いた質問
更新例：旧版と新版があり、最新版を選ぶ質問

各ケースについて、①検索上位に正解が入ったか、②回答が正しいか、③引用が原文と一致するか、④禁止情報を使っていないか、⑤確認に何分かかったかを記録します。

併用方式では、検索件数を3、5、10件などに変え、周辺チャンクを付ける条件も比較します。平均点だけでなく、権限違反、旧版参照、根拠の捏造を重大失敗として別集計します。

期待結果と確認方法

評価後には、単一の総合点ではなく次のような判断ができる状態を目指します。

RAGは検索上位への到達率は高いが、表の分割で例外条件を落とす
長いコンテキストは全文要約に向くが、中央にある根拠の引用が不安定
併用方式は回答品質が同等で、入力量と確認時間を抑えられる

これは実測例ではなく、評価結果の書き方です。自社データで得た件数、条件、モデル版、実行日を添えて初めて導入根拠になります。回答だけでなく、取得文書、入力へ渡した範囲、引用先を保存し、再現できるか確認してください。

失敗しやすい点と対処

最大入力長だけで決める：実際の文書長と位置を変えたケースで利用性能を測ります。
RAGの最終回答だけを見る：収録、分割、取得、生成を別々に採点します。
検索結果へ権限を後付けする：検索前に利用者の許可範囲を適用します。
引用があるから正しいと思う：引用先を開き、記述、版、適用条件の一致を機械または人で確認します。
評価文書を固定しすぎる：更新後の索引反映時間と旧版除外も試します。
併用を複雑化しすぎる：まず単純な全文入力と単純な検索を基準線にし、改善が確認できる部品だけ追加します。

採用しない条件

RAGは、文書が少数で固定され、検索基盤の更新・監視コストが利益を上回る場合には採用しません。長いコンテキストは、利用者ごとの権限付き文書を安全に選別できない、入力量による処理時間や費用が許容範囲を超える、位置を変えた評価で重大な見落としが続く場合には採用しません。

どちらの方式でも、根拠のない回答を自動実行へ直結させる用途は避けます。

AI活用ナビの判断

AI活用ナビの判断： 公開仕様の入力長は候補を絞る情報にすぎません。採用判断は、更新された正しい文書を、許可された利用者へ、検証できる根拠付きで返せるかで行うべきです。

初期構成は小さくします。固定した少数文書なら長いコンテキストを基準線にし、文書量、更新、権限が増えた段階でRAGを追加します。すでに大量文書を扱う場合も、検索だけで完結させず、正解文書を強制投入した読解評価を用意すると改善箇所を見誤りません。

確認日と公式情報

確認日：2026年7月29日。

HELM Long Contextの掲載モデルや順位は更新されるため、本記事では特定モデルの順位を採用根拠にしていません。Lost in the Middleは2023年の研究であり、現在利用するモデルと自社課題での再評価が必要です。

PRIMARY SOURCES