RAG導入の判断基準｜社内データをAIに使わせる4つの方法の比較と、失敗しやすい条件

RAG(検索拡張生成)とは、質問のたびに社内文書から関連する箇所を検索してAIに渡し、その根拠にもとづいて回答を生成させる方式です。 導入判断の軸は「文書が多いか」「更新頻度が高いか」「回答に根拠の提示が要るか」の3点で、この3つがそろわない用途では、文書をまるごと渡す長文コンテキストや通常のチャット利用で足りることが少なくありません。この記事では、RAGの仕組み、社内データをAIに使わせる4つの方法の比較、コスト試算、失敗しやすい条件と導入手順を解説します。

RAGとは何か — 仕組みを3工程で

RAGは、2020年にFacebook AI Research(現Meta)のLewisらが提案した手法で、LLM(大規模言語モデル)が学習していない情報を、検索で補って回答に使わせます。仕組みは事前処理と質問時の2段階、合わせて3工程です。

1. 分割とインデックス化(事前処理): 文書を数百〜千文字程度の単位(チャンク)に区切り、意味で探せる形(ベクトルなど)に変換して保存する
2. 検索(質問時): 質問と意味が近いチャンクを上位数件取り出す
3. 生成(質問時): 質問と取り出したチャンクをまとめてLLMに渡し、その範囲で回答させる。出典(どの文書のどの箇所か)を添えられる

社内の生成AI活用で「規程について答えるチャットボット」「製品マニュアルのQ&A」がRAGで作られるのは、この仕組みが「学習していない情報を使える」「出典を示せる」「文書の差し替えで最新化できる」という3つの要件を同時に満たすからです。

社内データをAIに使わせる4つの方法の比較

RAGは唯一の方法ではありません。2026年時点では主要なモデルの多くが100万トークン級のコンテキスト(1回に渡せる文章量)を提供しており、数百ページの文書をまるごと渡す「長文コンテキスト」も現実的な選択肢になっています。4つの方法を並べます。

判断のポイントは3つです。

第一に、事実の参照にファインチューニングは使わない。 ファインチューニングが向くのは文体・形式・専門用語の定着で、更新される事実を覚えさせる用途ではありません。規程が変わるたびに再学習が必要になり、回答の根拠も示せません。

第二に、長文コンテキストとRAGは文書量と質問頻度で分ける。 Googleの研究者らによるEMNLP 2024の比較研究では、十分なリソースがあれば長文コンテキストの方がRAGより平均性能で上回る一方、RAGのコストは大幅に低く、質問ごとに両者を使い分ける方式(Self-Route)で性能を保ったままコストを下げられると報告されています。文書が少なく質問が散発的なら長文コンテキスト、文書が多く質問が多いならRAGが基本形です。

もう1つ、長文コンテキストには「中間の情報を見落とす」性質があります。スタンフォード大学のLiuらの研究(TACL 2024)は、関連情報が入力の先頭か末尾にあるときに精度が最も高く、中間にあると大きく下がることを示しました。数百ページをまるごと渡す方式では、この影響を受けやすくなります。

第三に、常に変わるデータはRAGではなくエージェント型で参照する。 在庫・案件の状況・問い合わせチケットのような刻々と変わる情報は、インデックス化した時点で古くなります。MCPのような規格でAIから社内システムを直接呼び出す方が適しています。仕組みと導入判断はMCPとはで扱っています。

コストの試算例 — 長文コンテキストとRAGの差

コスト差を具体的に見ます。前提は、社内規程集500ページ(1ページ約1,000トークンとして計50万トークン)、1日200問、月20営業日(月4,000問)、入力100万トークンあたり3ドルのモデルを使う場合です。

入力コストで100倍の差が出ます。同じ文書を繰り返し渡す場合はプロンプトキャッシュ(同一部分の再利用割引)で長文コンテキスト側の費用を下げられますが、中間の情報を見落とす問題は残ります。逆に、文書が50ページ(5万トークン)で1日10問なら、長文コンテキストでも月あたり数十ドルにしかならず、検索基盤を作る初期コストの方が高くつきます。文書量と質問数を掛け算して、どちらが安いかを先に計算するのが導入判断の第一歩です。トークン数の見積もりはトークン数カウンター、月額の試算は生成AI API料金計算ツールで行えます。

RAGが失敗しやすい5つの条件

Gartnerは2024年7月に、生成AIプロジェクトの少なくとも30%が2025年末までにPoC(概念実証)後に中止されると予測し、その理由としてデータ品質の低さ・リスク管理の不備・コストの膨張・ビジネス価値の不明確さを挙げました。RAGはその典型で、失敗は構築技術よりも次の5つの条件で決まります。

③と⑤はAIガバナンスの論点でもあります。RAGを社内に出す前に、利用ルールと権限の考え方を社内ガイドラインとして決めておくと、公開後の混乱が減ります。

導入の手順(6ステップ)

1. 対象業務を1つに絞る(1週間): 「社内規程の問い合わせ」「製品仕様の照会」のように、質問の種類と参照文書が限定される業務から始める。質問数(1日何問か)と文書量(何ページか)をこの段階で数える
2. 評価セットを作る(1週間): 実際に来た質問から50問を選び、正解と出典をつける。この50問の正答率が以降のすべての判断基準になる
3. 文書を整備する(2〜3週間): 版管理、重複の削除、表の形式変換、権限の付与。RAG導入の工数の半分以上がここにかかる
4. 小さく構築して正答率を測る(2週間): 分割の単位・検索の件数を変えて評価セットで測る。目安として正答率80%未満なら公開せず、②の検索側(分割・検索件数・文書の質)を先に直す
5. 人の確認を残す運用で公開する(1ヶ月): 回答には必ず出典を添え、利用者が原文を確認できるようにする。誤答の報告経路を作り、人が最終確認する体制で始める
6. 文書更新の運用を決める: 誰が・いつ文書を差し替え、再インデックスするかを決める。ここが決まっていないRAGは、公開3ヶ月後には旧情報を答え始める

ステップ4で正答率が上がらない場合、原因の多くは生成側(モデル)ではなく検索側(文書の質と分割)にあります。モデルを高価なものに替える前に、評価セットで「検索が正しい箇所を取れているか」を確認します。PoCの計画と成功基準の置き方はPoCの進め方、AI導入全体の準備はAI導入のフローを参照してください。

よくある失敗

• 全社の文書を最初から入れる: 権限と品質の管理が追いつかず、矛盾した回答と情報漏えいの懸念で止まる。1業務・1文書群から始める
• 評価セットなしで「なんとなく良さそう」で公開する: 精度の議論が感想の応酬になり、改善できない。50問の正答率を判断基準にする
• 精度が出ないとモデルを替える: 原因の多くは検索側。分割の単位と文書の質を先に直す
• ファインチューニングで規程を覚えさせる: 更新のたびに再学習が必要になり、出典も示せない。事実の参照はRAGか長文コンテキストで行う
• 文書量が少ないのにRAGを構築する: 数十ページなら長文コンテキストで足りる。検索基盤の初期コストと運用が無駄になる
• 文書更新の担当を決めない: 公開後に文書が古くなり、誤答が増えて使われなくなる。更新と再インデックスの担当・頻度を最初に決める

まとめ

• RAGは「検索してから答えさせる」方式。学習していない情報を使え、出典を示せ、文書の差し替えで最新化できる
• 社内データをAIに使わせる方法は長文コンテキスト・RAG・ファインチューニング・エージェント型検索の4つ。事実の参照にファインチューニングは使わず、常に変わるデータはエージェント型で参照する
• 長文コンテキストとRAGは文書量×質問数で分ける。500ページ・月4,000問なら入力コストで100倍の差、50ページ・月200問なら長文コンテキストで足りる
• 失敗の条件は文書の未整理・表と図・権限・評価セットの不在・「分からない」を返せない設計の5つ。技術より文書整備と評価で決まる
• 導入は対象業務1つ・評価セット50問・文書整備・小さく構築・人の確認を残して公開・更新運用の6ステップ

RAG・LLM・エンベディング・ファインチューニングなど、この記事で使った用語の定義はAIの用語集にまとめています。API利用料の全体設計は生成AI APIのコスト管理入門、社内データを外に出せない場合の選択肢はローカルLLMとAPIの比較を参照してください。