RAGは何に向いている？生成AIの得意・不得意を整理｜LLM入門 2.4

2.4 RAGが得意なケース、不得意なケース

RAG（Retrieval-Augmented Generation）は、検索と生成を組み合わせることで、高精度かつ柔軟なAI応答を実現する強力なアーキテクチャです。
しかし、どんな技術にも適材適所があるように、RAGもまた「向いている業務」と「限界のある業務」が存在します。

このセクションでは、RAGが特に効果を発揮する代表的なユースケースと、現在の技術水準ではまだ難しい・不向きとされるケースを明確にし、導入判断の参考となる視点を整理します。

RAGが得意とするケース

1. ナレッジ検索・FAQ応答の高度化

RAGの最も典型的な応用分野は、社内文書やFAQなどに基づいたナレッジベース型の質疑応答です。

例：

• 「出張申請の手順を教えて」→ 社内ガイドラインを検索し、自然な言葉で説明

• 「製品Aと製品Bの仕様の違いは？」→ 製品マニュアルから該当部分を抜粋・要約して回答

このように、明文化された情報がすでに存在するが、利用者がその探し方を知らない／時間がかかるような場面では、RAGが極めて有効です。

2. 法務・医療・教育など専門文書の活用

LLMだけでは正確な情報を生成できない分野においても、RAGを活用することで専門的文献や規定に基づいた回答を提供できます。

例：

• 医療機関内の診療ガイドラインに基づくFAQ対応

• 教育機関でのカリキュラム・要綱の問い合わせ対応

• 契約書に基づく条件確認や差分抽出

こうした場面では、回答の裏に「根拠のある文書」が存在することが前提となるため、RAGの仕組みと非常に相性が良いと言えます。

3. マルチモーダルナレッジの活用（テキスト中心）

テキストで構造化されていないが、一定の文脈で情報が埋もれているような文書群（例：議事録、チャットログ、議会答弁など）から関連情報を探し出して答えを生成するような用途でも、RAGは活用されています。

ここではRetrieverが「文脈ごとに切り出された単位（チャンク）」の中から関連情報を抽出し、LLMが全体の流れに合った回答を作ります。

RAGが不得意とするケース

1. 数値計算やロジックが必要なケース

RAGは、事実の検索と自然言語生成には強い一方で、論理的な推論や複雑な数値処理には弱みがあります。

例：

• 「前年の売上の前年比を計算して」

• 「このルールとあのルールの交差条件を満たすケースを列挙して」

こうした問いには、検索しても答えがどこにも“書いていない”ことが多く、LLMだけでは計算や論理の整合性が保証されません。

この場合は、RAGと組み合わせて外部スクリプトやツールによる処理を挟むなどの工夫が必要です。

2. 即時性・リアルタイム性が求められるケース

ニュース速報、株価、天気、交通情報など、刻々と変化する情報に対応する場合、ナレッジベースの更新タイミングが遅れると誤答のリスクが高まります。

たとえば、「今、新幹線に遅れは出ていますか？」という質問に対して、Retrieverが参照する情報が昨日のものであれば、正確な回答はできません。

このようなリアルタイム性の高いユースケースには、APIとの接続や最新情報のストリーミングが求められ、RAG単体では対応が難しくなります。

3. 会話の文脈を継続的に保持するような対話型エージェント

RAGは1問1答型のやりとりに強く、その都度検索し、応答することを前提としています。
一方で、会話の流れを複数ターンにわたって保持し、状態を引き継いでいくような設計には、MCP（Model Context Protocol）などの状態管理の仕組みとの連携が必要になります。

RAGに適した設計判断の視点

以下のような問いを立てることで、RAGの導入が適しているかどうかを判断することができます。

• 回答の根拠が、どこかに文章として存在するか？

• ナレッジは静的で、数日〜週単位の更新で十分か？

• 質問のバリエーションが多く、テンプレート対応では限界があるか？

• 専門性が高く、一般のLLMでは知識が足りないか？

これらに「はい」と答えられるなら、RAGは非常に有効なアーキテクチャとなる可能性があります。

RAGのための技術要素とは？

このセクションでは、RAGの特性を活かすためのユースケースと、注意すべき制約について整理しました。
次の章「第3章　RAGのユースケースと導入効果」からは、実際にRAGを構成するために必要となる技術要素──埋め込みモデル、ベクトル検索エンジン、プロンプト統合の工夫など──を具体的に見ていきます。

RAGを「構想」から「実装」へと移していくステップに入ります。