社内にAIを導入したいと考えたとき、「ChatGPTに社内資料を読ませたい」という発想が出てくることがあります。その仕組みの中核にあるのがRAG（Retrieval-Augmented Generation）です。RAGとは、AIが回答を生成する前に関連する文書を検索・参照させる技術で、「知識を持ったAI」を作るための基本的な設計手法です。ただ、RAGには複数の種類があり、場面に応じて選択肢が変わります。この記事では、代表的な8種類のRAGアーキテクチャを、業務シナリオと一緒に整理します。
そもそもRAGが必要な理由
ChatGPTなどの大規模言語モデルは、学習データのカットオフ以降の情報を知りません。また、自社固有の規程・マニュアル・過去の議事録といった情報は、そもそも学習に含まれていません。RAGはこの弱点を補う仕組みで、「外部の文書をリアルタイムで検索し、その内容を踏まえて回答させる」という流れで動きます。検索エンジンとAIを組み合わせたようなイメージが近いです。RAGを使わずにAIに社内情報を扱わせようとすると、ファインチューニング（追加学習）が必要になり、コストも時間もかかります。RAGはその代替として、比較的低コストで社内知識をAIに持たせる方法として広まっています。
8種類のRAGアーキテクチャ一覧
RAGには現在、用途や精度の要件に応じた複数の設計パターンが存在します。以下の表は、8種類のアーキテクチャを「向いている用途」と「導入の難易度」で整理したものです。
| アーキテクチャ | 向いている用途 | 難易度 |
|---|---|---|
| Naive RAG | 単純なFAQ・事実確認 | 低 |
| Multimodal RAG | 画像・音声を含む検索 | 中〜高 |
| HyDE | 専門的な質問への回答精度向上 | 中 |
| Self-RAG | 信頼性が重要な用途 | 高 |
| Corrective RAG | 検索結果の品質が不安定な場合 | 高 |
| Agentic RAG | 複数ステップの調査・分析 | 高 |
| Graph RAG | 関係性の複雑な知識ベース | 高 |
| Adaptive RAG | 質問の種類が多様な汎用システム | 高 |
これらは「新しいほど優れている」わけではなく、用途と開発リソースによって使い分けるものです。
基本の2種類：まず押さえるNaive RAGとHyDE
RAGを初めて導入する場合、出発点になるのがNaive RAGです。ユーザーの質問をベクトル（数値の配列）に変換し、あらかじめ変換しておいた文書群の中から近いものを探して、その内容をAIに渡す仕組みです。構造がシンプルなため、社内FAQや製品マニュアルの検索用途であれば十分に機能します。たとえば、人事部が就業規則に関する問い合わせ対応にAIを使いたい場合、Naive RAGで規程集を登録するだけで「有給休暇は何日取れますか？」「育休の申請手順は？」といった質問に答えられるようになります。構築コストが低く、小規模な社内ツールとして試しやすいのが特徴です。
ただし、質問が専門的になると精度が落ちることがあります。「ベクトルの近さ」で検索するため、質問の言い回しが変わると関連文書を見つけられないケースが出てきます。この課題に対処するのがHyDE（Hypothetical Document Embeddings）です。HyDEは、ユーザーの質問に対してAIがまず「仮の回答文」を生成し、その仮回答を使って文書を検索します。「質問で検索する」のではなく「答えっぽいテキストで検索する」ことで、専門用語を含む質問でも関連文書に近づきやすくなります。法務部が判例や契約書の解釈を調べる用途や、技術資料の中から仕様を引き出す場面で効果が出やすいです。
画像・音声も扱えるMultimodal RAG
Multimodal RAGは、テキストだけでなく画像や音声も検索対象に含められる設計です。製品の写真、設計図、動画の字幕データなどを一緒に管理し、テキストの質問から画像を含む回答を生成できます。製造業の現場で「この部品の取り付け手順を教えて」と聞いたとき、テキストの説明だけでなく図解も一緒に表示できるのがイメージに近いです。現時点では構築の難易度が高く、専門的なエンジニアリングが必要ですが、マニュアルや製品カタログを大量に抱える業種では中期的に注目される設計パターンです。
精度と信頼性を上げる：Self-RAGとCorrective RAG
AIの回答に誤りが含まれるリスク（いわゆる「ハルシネーション」）を減らしたい場合、Self-RAGかCorrective RAGが候補になります。Self-RAGは、AIが自分の回答を生成しながら「この内容は検索結果に基づいているか」「この部分は確信が持てるか」を自己評価する仕組みです。信頼性の低い部分を自動的にフラグ立てできるため、医療・法律・金融といった誤情報のリスクが高い用途で検討されています。
Corrective RAGは、最初の検索結果の品質を評価し、不十分であれば検索クエリを修正して再検索するアプローチです。一度の検索で終わらず、必要に応じて検索をやり直すため、文書の網羅性が不均一な知識ベースでも安定した回答が得やすくなります。社内文書の整備状況がばらついている場合（古い資料と新しい資料が混在しているなど）には、Corrective RAGのほうが実用的な選択肢になることがあります。
複雑な調査を自動化するAgentic RAGとGraph RAG
Agentic RAGは、AIが「検索→判断→追加検索」を自律的に繰り返すアーキテクチャです。単発の質問への回答ではなく、複数の情報源を組み合わせた調査・分析タスクに向いています。たとえば、40代の事業企画担当者が「競合他社の動向と自社の強みを比較した上で、新規事業の方向性を整理したい」という依頼をAIに出した場合、単純なRAGでは一度の検索で終わってしまいますが、Agentic RAGなら「まず競合情報を検索→次に自社データを参照→両者を比較して整理」という流れを自動で組み立てられます。ただし、設計の複雑さとコストは高く、現時点では社内に専任エンジニアがいる環境向けです。
Graph RAGは、文書をバラバラに検索するのではなく、情報同士の「関係性」をグラフ構造で管理するアプローチです。「A社がB社を買収し、B社はC技術を持っている」のような連鎖的な情報を扱う場合、通常のRAGでは関係性が失われますが、Graph RAGなら繋がりを保ったまま検索できます。組織の人間関係、製品の部品構成、法令の参照関係など、「繋がり」が重要な知識ベースで効果が出やすいです。
汎用性を求めるならAdaptive RAG
Adaptive RAGは、質問の種類に応じて最適な検索戦略を自動で切り替えるアーキテクチャです。シンプルな質問にはNaive RAGで素早く回答し、複雑な質問にはより精度の高い検索手法を使う、という判断をシステム側が行います。「社員が何でも聞ける社内AIアシスタント」のように、質問の幅が広い汎用ツールを作る場合に向いています。ただし、複数の検索戦略を組み合わせる分、設計・維持のコストは上がります。
ChatGPTの基本的な使い方を押さえた上でRAGの概念に進むと、社内ツールの設計イメージが具体的になります。
業務シナリオ別の選び方
どのRAGを選ぶかは、「何を検索対象にするか」「どれくらいの精度が必要か」「開発リソースがあるか」の3点で大きく変わります。社内FAQや規程集の検索であればNaive RAGで十分なことが多く、まず試してみる価値があります。専門的な質問が多い場合はHyDEを組み合わせると精度が上がります。誤情報のリスクが許容できない業務（法務・医療・金融）ではSelf-RAGが候補になりますが、エンジニアリングコストも上がるため、ROI（費用対効果）の見積もりが先です。
プロンプトの書き方ガイドで触れているように、AIへの指示の精度はシステムの設計と同じくらい回答品質に影響します。RAGを導入しても、AIに渡すプロンプトが粗ければ回答の質は上がりません。システムとプロンプトの両面を整えることが、実用的な社内AIを作る上での現実的な進め方です。
まとめ
RAGの8種類は、それぞれ異なる問題を解くために設計されています。Naive RAGのシンプルさから始め、精度・信頼性・複雑さの要件に応じてアーキテクチャを選ぶのが現実的な流れです。社内AI導入を検討している場合、最初から高度な設計を目指すよりも、Naive RAGで小さく始めて課題が見えてから次の手を考えるほうが、多くの場合うまくいきます。あなたの職場で「AIに検索させたい情報」はどこにありますか。その情報の性質が、選ぶべきRAGの種類を教えてくれます。
