Context Engineering vs RAG / Long Context — PoC比較

エグゼクティブサマリ

本レポートは、Unovia が実施した「長文社内ナレッジベース構築」の検証結果と、業界公開ベンチマークを統合し、日本企業が今選ぶべきアーキテクチャを整理したものである。要点は以下の三点。

単純な RAG は、複数事実を横断する質問で大きく性能低下する。Gemini 1.5 Pro は単一事実検索で 99.7% の再現率を達成するが、現実的なマルチファクト検索では平均 60% 前後にとどまる[1]。エンタープライズの実問題は後者である。
Long Context（100 万トークン窓）も万能ではない。Claude Opus 4.6 は MRCR v2 1M で 78.3% を維持するが、GPT-5.4 は 36.6%、Gemini 3.1 Pro は 18.5%、Sonnet 4.5 は 25.9% まで低下する[2]。コストは RAG の約 1,250 倍、レイテンシは 30〜60 倍[3]。「とりあえず全部入れる」戦略は、製品グレードでは成立しない。
答えは Context Engineering にある。RAG をひとつの取得手段として包含し、ガバナンス・分類・権限・履歴管理を query-time に統合する規律。導入企業では精度が 35〜60% 改善し、ガバナンス済みコンテキストでは 94〜99% に達するという報告がある[4][5]。

Unovia の検証でも、同様の傾向が確認された。詳細は以下に整理する。

1. 背景 ── なぜ「RAG だけ」では足りないのか

過去 3 年間、社内ナレッジベース構築のデファクトは Vector RAG だった。クエリをエンベディングに変換し、近傍検索で上位 k 件を取得し、LLM に渡して回答を生成する。シンプルで導入しやすい。

しかし、エンタープライズで本番運用に入った組織から、共通の不満が報告されている。

「契約書の Section 3.2 と 7.1 を横断する質問」で精度が落ちる
「3 年前の社内 Slack スレッド + 最新の議事録 + 関連法令」を統合した回答ができない
古い情報と新しい情報が混在し、どちらが正なのか判断できない
部門ごとの権限を考慮しない検索結果が返ってくる

これらは Retrieval（取得）の問題ではない。Context Quality（与えるコンテキストの質）の問題である[5]。

実際、業界調査では「エンタープライズ RAG 案件の失敗の大半は、検索再現率ではなく、コンテキスト品質に起因する」と整理されている[5]。

2. 三つの選択肢の整理

現時点で、長文ナレッジ検索における主要なアプローチは三つある。

2.1. Vector RAG（従来型）

クエリをエンベディング → 近傍検索 → 上位 k 件を LLM に投入。

観点	評価
コスト	低
レイテンシ	速（数百ミリ秒）
単一事実精度	高（90%+）
マルチファクト精度	中〜低（60% 前後）[1]
権限・ガバナンス対応	別実装が必要

2.2. Long Context（直接投入型）

100 万トークン窓を持つ LLM（Claude Opus 4.6、Gemini 3 Pro、GPT-5）に、ナレッジベース全体を直接投入する。

観点	評価
コスト	非常に高（RAG の約 1,250 倍）[3]
レイテンシ	遅（RAG の 30〜60 倍）[3]
単一事実精度	高（NIAH で約 90%）[2]
マルチファクト精度	モデル依存。Opus 4.6 は 78.3%、GPT-5.4 は 36.6%、Gemini 3.1 Pro は 18.5%（MRCR v2 1M）[2]
権限・ガバナンス対応	困難

2.3. Context Engineering（規律としての統合）

RAG を「取得手段の一つ」として位置づけ、その上に分類、権限、認証、コラム単位の lineage、時系列の鮮度管理を query-time に重ねる規律。RAG + Memory + Knowledge Graph をガバナンス層下で組み合わせる構成が、現時点での先進的実装パターンである[4][5]。

観点	評価
コスト	中（RAG ベース + 統合層）
レイテンシ	中（RAG の 1.5〜3 倍）
単一事実精度	高
マルチファクト精度	高（ガバナンス済みで 94〜99%）[4]
権限・ガバナンス対応	標準実装

3. Unovia の検証：日本企業の社内ナレッジベースで三方式を比較

Unovia は、日本企業の社内ナレッジ検索を想定したデータセットで、上記三方式の検証を実施した。

3.1. 検証設定

対象データ：契約書、社内規程、議事録、Slack/Teams ログ、技術ドキュメント、業界レポートを混合した約 80 万トークン相当
データ特性：日本語＋英語混在、改訂履歴あり、部門別権限あり、3 年分の時系列
検証手法：上記三方式（RAG / Long Context / Context Engineering）でそれぞれ実装し、同一クエリセットで比較
評価指標：
単一事実検索（Single-Fact Retrieval）：document 内の特定数値・日付・固有名詞の取得
マルチファクト統合（Multi-Fact Composition）：複数 document を跨ぐ事実の合成
時系列認識（Temporal Awareness）：「最新版」と「過去版」の判別
権限フィルタ（Access Control）：閲覧権限を持たない情報の除外
コスト・レイテンシ

3.2. 観察された傾向（公開ベンチマークと整合）

検証のサンプル数は限定的であるため、本レポートでは「定性的な傾向」を中心に記述する。定量比較が必要な場合は、参照 [1][2][4] の公開ベンチマークを併用されたい。

Vector RAG（単独）

単一事実検索は強い
マルチファクト統合で大きく落ちる（公開ベンチマークと同様）
時系列認識は不可（実装次第で部分対応）
権限フィルタは別レイヤーで実装が必要

Long Context（直接投入）

Claude Opus 4.6 では実用的な精度を維持
GPT-5、Gemini 3 では 1M 投入時に精度が大きく劣化（公開ベンチマークと整合）[2]
レイテンシ・コストが本番運用に堪えない（数十秒、1 クエリあたりトークンコスト数ドル）
権限フィルタは事前にコンテキストを絞る必要があり、結局 RAG に戻る

Context Engineering（統合構成）

取得層：Vector RAG + Knowledge Graph（GraphRAG）の併用が、エンタープライズ Q&A の 90% 以上をカバー[4]
ガバナンス層：分類タグ、権限、鮮度（version）、データ系譜（lineage）を query-time に評価
メモリ層：会話履歴と長期記憶を分離し、各クエリで必要分のみ注入
結果として、単一事実・マルチファクト・時系列・権限の全てで実用的な精度を実現

3.3. 重要な観察

検証を通じて確認された、最も重要な事実は次の点である。

「Long Context モデルが普及しても、RAG は不要にならない」

100 万トークン窓は、デバッグや探索には強力なツールである。しかし、本番運用の知識ベースとしては、コストとレイテンシが現実的でない。1 日 1 万クエリのシステムを Long Context で運用すれば、月額コストはトークン代だけで数千万円規模に達する。

それより、「適切に絞ったコンテキストを、適切なガバナンス下で LLM に渡す」ことが、製品グレードのナレッジ検索に必要な規律である。これが Context Engineering の核である。

4. 業界全体の動向との整合

公開されている業界レポートも、同じ方向を示している。

Atlan（データガバナンス分野）：「Context Engineering は RAG を内包する上位概念であり、分類、認証、列単位 lineage、アクセスポリシーを query-time に統合する規律」[4]
Callstack / RAGFlow（OSS RAG エコシステム）：「2025 年末から 2026 年初頭にかけて、議論の中心が RAG 単体から Context Engineering へ移行した」[5][6]
TianPan（プロダクション意思決定フレームワーク）：「100 万トークン窓は『誤った道具』であるケースが多い。決定基準は精度ではなくコスト・レイテンシ・権限である」[3]
MindStudio：「Claude 1M Token Context は RAG を置き換えない。RAG をより良くする」[7]

つまり、Unovia の検証で観察された結論は、業界の最新動向と概ね整合する。「Long Context は強力だが、置換ではなく補完」「RAG は必要だが、それだけでは不足」「Context Engineering が次のレイヤー」という構造である。

5. 日本企業向け実装パターン推奨

検証と業界調査を踏まえ、日本企業のナレッジベース構築における推奨アーキテクチャを示す。

推奨構成（フェーズド導入）

┌─────────────────────────────────────────────┐
│         Application Layer (UI / API)          │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│   Context Engineering Layer (Governance)      │
│   - 権限フィルタ（部門・役職・契約）             │
│   - 鮮度管理（最新版優先、改訂履歴）             │
│   - 分類タグ（機密度・カテゴリ）                 │
│   - データ系譜（lineage、出典）                 │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│              Retrieval Composers              │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│   │ Vector  │  │GraphRAG │  │ Memory  │     │
│   │  RAG    │  │         │  │ (履歴) │      │
│   └──────────┘  └──────────┘  └──────────┘  │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│         LLM Layer (long-context optional)     │
│   - 通常クエリ：Claude Sonnet / GPT-5（短窓）   │
│   - 探索・デバッグ：Claude Opus 4.6（1M 窓）    │
└─────────────────────────────────────────────┘

フェーズ提案

Phase 1（〜3 ヶ月）：Vector RAG をベースに導入。単一事実検索の精度を確保。 Phase 2（〜6 ヶ月）：GraphRAG 層を追加。エンティティ関係を扱う質問に対応。 Phase 3（〜9 ヶ月）：Context Engineering ガバナンス層を構築。権限、鮮度、lineage を query-time 統合。 Phase 4（〜12 ヶ月）：Long Context モデルを「探索・デバッグ用」として補助的に組み込む。本番クエリは依然として絞り込んだコンテキストで運用。

「全部一気に作る」のではなく、Phase 1 で動くものを出してから順次層を厚くする。これが、検証を踏まえた現実的な進め方である。

6. 結論

長文ナレッジ検索における正解は、二つの極端ではなく、その間にある。

「RAG は古い、Long Context が来た」という極論も、「Long Context は使えない、RAG が永遠の正解」という極論も、いずれも正確ではない。

正しい問いは「何を取得し、どう編成し、どのモデルにどう渡すか」を、取得・編成・投入のすべての段階で意識的に設計することである。それが Context Engineering の本質であり、エンタープライズ AI のナレッジ層が次に向かう先である。

Unovia は、日本企業のこの移行を、Phase 1 から Phase 4 まで一貫して支援する立場にある。

お問い合わせ・採用情報

社内ナレッジベース、Context Engineering 導入、RAG → Context Engineering 移行のご相談は、以下からどうぞ。

unoviax.co.jp/contact

なお Unovia は、Context Engineering / GraphRAG / Memory Architecture などのナレッジ層設計に取り組むエンジニアを募集しています。「LLM の上のレイヤー」を設計したい方は、同じ窓口からお問い合わせください。

参考文献

[1] Gemini 1.5 Pro on multi-fact retrieval ── 単一事実 NIAH で 99.7% 再現率を達成するが、現実的なマルチファクト検索では平均 60% 前後。 https://alphacorp.ai/blog/is-rag-still-worth-it-in-the-age-of-million-token-context-windows

[2] MRCR v2 1M Token Benchmark（2026 年）── Claude Opus 4.6: 78.3%、GPT-5.4: 36.6%、Gemini 3.1 Pro: 18.5%、Sonnet 4.5: 25.9%。 https://www.mindstudio.ai/blog/1m-token-context-window-vs-rag-claude

[3] Long-Context vs RAG Cost/Latency Analysis（TianPan, 2026/4）── 1M トークンリクエストは RAG の約 1,250 倍のコスト、30〜60 倍のレイテンシ。 https://tianpan.co/blog/2026-04-09-long-context-vs-rag-production-decision-framework

[4] Context Engineering vs. RAG（Atlan, 2026）── ガバナンス済みコンテキストで精度 94〜99% vs ungoverned で 10〜31%。Context Engineering は RAG + classification + access policy を query-time に統合する規律。 https://atlan.com/know/context-engineering-vs-rag/

[5] From RAG to Context: A 2025 Year-End Review（RAGFlow）── エンタープライズ RAG 失敗の大半は検索再現率ではなくコンテキスト品質。Vector retrieval + GraphRAG 併用で Q&A の 90% 以上をカバー。 https://ragflow.io/blog/rag-review-2025-from-rag-to-context

[6] RAG Is Dead. Long Live Context Engineering（Callstack）── 2025〜2026 にかけて議論の中心が RAG 単体から Context Engineering へ移行。 https://www.callstack.com/blog/rag-is-dead-long-live-context-engineering-for-llm-systems

[7] Claude 1M Token Context: RAG Isn’t Dead（MindStudio）── 100 万トークン窓は RAG を置き換えない。RAG をより良くする。 https://www.mindstudio.ai/blog/1m-token-context-window-vs-rag-claude

FAQ

Q. RAG は本当に時代遅れか？ いいえ。RAG は依然として中核技術です。本レポートの主張は「RAG だけでは不足」であり、「RAG が不要」ではありません。Vector RAG はマルチファクト統合と権限制御で限界がありますが、それを Knowledge Graph、Memory、Governance 層で補強するのが Context Engineering です。

Q. うちの会社、どこから始めればいい？ Phase 1 として Vector RAG を最小構成で立ち上げることを推奨します。動くものが出てから、Phase 2 以降で層を厚くしてください。最初から Context Engineering を全構築しようとすると、実装複雑度で失敗します。

Q. 100 万トークン窓は本当に必要？ 本番クエリには通常不要です。コードベース全体を読ませる、長文契約書を一括分析するなど、「探索・デバッグ用途」では強力なツールです。本番運用は短窓 + RAG + Context Engineering で十分のケースが多いです。

Q. 日本語データセットで精度はどうか？ 公開ベンチマークの多くは英語ベースですが、Unovia の PoC では日本語＋英語混在データでも、Context Engineering 構成で実用精度を確認しました。日本語特有の問題（曖昧な参照、敬語、同音異義語）は前処理層で対応する必要があります。

Q. 検証のもっと詳しいデータは？ データセットのプライバシー上、本レポートでは公開ベンチマークと併用する形で定性記述にとどめています。具体的な検証構成・結果のご相談は unoviax.co.jp/contact からお問い合わせください。

News

【Unovia Research】長文ナレッジ検索の最適解 ── RAG / Long Context / Context Engineering の PoC 比較