社内のマニュアルや議事録をAIに読み込ませて、質問すれば答えが返ってくる仕組みを作りたいと調べていて、『RAG』という言葉に行き当たり、結局何なのかつかめないまま止まっていないでしょうか。
検索すると『検索拡張生成』という訳語や、ファインチューニングとの比較表を載せた記事は多数出てきますが、自社の場合はどちらを選ぶべきかまでは答えてくれないことがほとんどです。
生成AIの業務活用が広がったこの2～3年で、AIに社内情報を答えさせる方法にはRAG、ファインチューニング、社内FAQ専用のツールなど複数の選択肢が登場しました。
違いを理解しないまま選ぶと、費用や運用の負担が想定と大きくずれることがあります。
この記事では、業務自動化の構築設計で使っている判断基準をもとに、RAGの仕組み、ファインチューニングとの違い、自社がどちらを検討すべきかの見分け方、社内データで使う際に必要な要素を整理しています。
RAGとは？検索と生成を組み合わせて回答する仕組み
RAG（Retrieval-Augmented Generation：検索拡張生成）は、AIが質問に答える前に、あらかじめ登録された文書から関連する情報を探し出し、その情報をもとに回答文を作る仕組みです。
ChatGPTやClaudeのようなAIは、学習した時点までの一般的な知識をもとに回答しますが、自社の社内規定や今月のキャンペーン内容までは学習していません。
RAGは、この『知らないこと』を都度検索で補いながら回答させる方法で、モデル自体を作り直さずに、参照する資料を用意する形でAIの回答範囲を広げます。
We introduce RAG models where the parametric memory is a pre-trained seq2seq model and the non-parametric memory is a dense vector index of Wikipedia, accessed with a pre-trained neural retriever.
（訳）パラメトリックメモリに事前学習済みのseq2seqモデルを、ノンパラメトリックメモリにWikipediaの密ベクトルインデックスを用い、事前学習済みのニューラル検索器でアクセスするRAGモデルを提案する。
出典： Lewis et al.「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」
処理の流れは大きく3つの役割に分かれており、それぞれが担う仕事を理解しておくと、後述のファインチューニングとの違いも把握しやすくなります。
検索（Retrieval）：質問に関連する情報を探す
利用者が質問を入力すると、まずシステムが登録済みの文書群から、その質問に関連性の高い部分を検索します。
検索対象になるのはPDFやWordの業務文書、社内Wiki、議事録など、あらかじめ整理してAIに読み込ませておいた資料です。
検索は文書全体を一度に渡さず、意味のあるまとまり（段落や章など）ごとに区切って、質問と関連度の高い部分だけを取り出す形で行われます。
社内文書が整理されずに散在している場合、この検索の精度が落ち、関係のない部分を拾ってしまう原因になります。
拡張（Augmentation）：見つかった情報をAIへの指示に追加する
検索で見つかった関連情報は、そのまま利用者の質問に付け加えられて、AIへの指示文の一部になります。
つまりAIは「この質問に、この参考資料を踏まえて答えてください」という形で情報を受け取ることになり、資料に書かれていない内容を勝手に補って答える余地が小さくなります。
利用者から見える画面は通常のチャットと変わりませんが、裏側では質問文がこの形へ組み替えられてからAIに渡る仕掛けです。
この段階があることで、AIが持つ一般知識と、その企業だけが持つ固有の情報を1回のやり取りの中で組み合わせられます。
生成（Generation）：情報をもとに回答文を作る
最後にAIが、渡された参考資料と質問内容を突き合わせて、自然な文章として回答を生成します。
多くのRAGの仕組みでは、回答と一緒に『どの資料のどの部分を根拠にしたか』という出典も表示されるため、利用者は回答をそのまま鵜呑みにせず、原文に当たって確認できます。
たとえば出張旅費の上限を質問すると、回答と合わせて規程のどの項目を参照したかまで示される、という具合です。
根拠不明の生成AIの回答と違い、出典をたどれる点は、社内での運用を任せる相手として現場の信頼を得やすい特性です。
RAGとファインチューニングの違いは？
RAGとファインチューニングの違いは、AIモデル自体を作り変えるかどうかという点にあります。
RAGはモデルには手を加えず、参照する資料を差し替えるだけで回答内容を更新できるのに対し、ファインチューニングはモデルの内部パラメーターを追加データで再学習させ、モデル自身の応答の傾向を変えます。
この違いから、情報の更新しやすさと、向いている用途がそれぞれ異なります。
どちらも『AIを自社向けにする』技術ですが、混同すると導入方針を誤りやすいため、次の観点で整理しておくと判断しやすくなります。
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 仕組み | 質問のたびに外部の文書を検索して回答に反映する | 追加データでモデル自体を再学習させる |
| 情報の更新 | 参照する文書を差し替えるだけで反映される | 更新のたびに再学習が必要になる |
| 向いている用途 | 頻繁に変わる情報、出典を示したい問い合わせ対応 | 応答の口調や形式の統一、専門分野特有の言い回しの習得 |
| 出典の提示 | 参照元を明示しやすい | モデルの内部知識として溶け込むため出典は示しにくい |
| 導入の手間 | 文書の整備が中心で、比較的着手しやすい | 追加学習用データの作成と再学習の工程が必要になる |
表からも分かるとおり、RAGは『何を根拠に答えたか』を示しやすく、ファインチューニングは『どう答えるか』を作り込みやすいという役割分担になります。
実務では、社内規定やマニュアルのように事実を正確に伝えたい場面はRAGが目安になります。
一方、カスタマーサポートの口調統一や専門用語の使い分けのように応答スタイルを揃えたい場面は、ファインチューニングの出番です。
ファインチューニングの仕組みそのものは、次の記事で詳しく整理しています。
自社はRAGとファインチューニングのどちらを検討すべきか？
自社がどちらを検討すべきかは、情報が更新される頻度、AIに求めるのが知識か応答スタイルか、誤答したときの影響範囲の3つで判断できます。
どれか1つだけで決めようとすると判断を誤りやすいため、まず自社の状況を3つの軸に当てはめて、どちらの傾向が強いかを確認するところから始めます。
いずれの軸も自社の業務の性質を問うものであり、AIの仕組みに詳しくない担当者でも答えられる観点です。
以下では、それぞれの軸で何を見ればよいかと、判断がつきにくいときの考え方を整理します。
情報が更新される頻度で見る
キャンペーン内容や在庫状況、就業規則の改定のように、月単位や週単位で内容が変わる情報を扱うなら、RAGが向いています。
ファインチューニングで学習させた内容は、モデルの中に固定化されるため、情報が変わるたびに再学習が必要になり、更新のたびにコストと時間がかかります。
たとえば毎月改定される料金表をファインチューニングで覚えさせると、翌月には古い金額のまま答えるモデルが残り、作り直しの費用と時間だけが積み上がっていきます。
更新頻度が読めない場合は、その情報が直近1年で何回変わったかを数えてみると判断しやすくなります。
逆に、業界特有の言い回しや社内でしか使わない略語のように、一度覚えれば長期間変わらない知識であれば、ファインチューニングで一括して習得させる方が効率的です。
求めるのが『知識』か『応答スタイル』かで見る
「この規定について正確に答えてほしい」という要望はRAG向きで、「いつもこの口調、この構成で答えてほしい」という要望はファインチューニング向きです。
たとえば「経費精算の締め日はいつか」に正しく答えさせたいのは知識の問題で、「回答は必ず敬語で3行以内に」と揃えたいのは応答スタイルの問題です。
RAGは根拠となる文書を差し替えるだけなので、事実関係を正確に伝えることに強みがありますが、AIの話し方そのものを変える力は弱いという特性があります。
反対にファインチューニングは、モデルの応答の癖そのものを変えられる一方で、学習させた具体的な事実は更新しにくいという弱点があります。
どちらか迷う場合は、いまAIの回答を人が手直しするとしたら直すのは事実の誤りなのか言い回しなのか、を想像してみてください。
誤答したときの影響範囲（事故コスト）で見る
顧客への返金対応や法務判断のように、誤った回答がそのまま実害につながる業務では、RAGを選び、必ず出典を確認する運用を組み合わせることをおすすめします。
たとえば返金可否の問い合わせにAIが誤った基準で答えれば、そのまま顧客対応の事故につながるため、担当者が原文を確認してから返答する前提の運用が欠かせません。
ファインチューニングだけで対応すると、モデルが誤った情報を『もっともらしく』生成した場合に、根拠となる原文が存在しないため、どこで間違えたのかを追跡しにくくなります。
社内向けのちょっとした質問対応のように、多少の誤答があっても現場で判断できる業務であれば、応答の自然さを優先してファインチューニングを検討する余地もあります。
社内データでRAGを使うにはどんな仕組みが必要か？
社内データでRAGを使うには、文書をそのままAIに渡すのではなく、検索対象として整備したうえで、出典付きで回答するツールに接続する必要があります。
社内文書は部署ごとに保管形式や更新のタイミングがばらばらなことが多く、整備を飛ばして登録すると、古い情報や重複した内容を根拠にした誤答につながります。
以下の3点を順に整えることで、社内データを使ったRAGの土台ができます。
文書を検索できる形に整備する
まず、対象にする文書の中から『正しい最新版』だけを選び、古い版や重複したファイルをアーカイブへ移して除外します。
どれが最新版か判断できない文書が出てきたときは、その場で作成部署に確認し、日付を入れて保存し直すルールも決めておくと、後の見直しが楽になります。
店舗業務や経理業務のように部署をまたぐ業務であれば、業務のプロセス別（受付、処理、確認など）に整理し直すと、利用者の質問と対応づけやすくなります。
文書量が多い場合、この棚卸し作業自体が導入プロジェクトの本体になることが多く、AIツールの設定作業よりも時間がかかる傾向があります。
文書をどの単位で区切って検索対象にするかも、この整備作業の精度を左右します。
出典付きで回答するツールを選ぶ
社内データ向けのRAGを試す入り口として、登録した資料だけを根拠に、出典付きで回答するNotebookLM（Googleが提供するAIサービス）のようなツールがよく使われます。
回答だけを返す仕組みだと、現場の担当者が正しさを検証できず、1回でも誤った回答で対応してしまうと使われなくなりますが、出典付きであれば原文を確認したうえで判断できます。
利用人数や分析機能まで求める段階になれば社内FAQ専用のサービスも選択肢になりますが、小さく試す段階では無料範囲で使えるツールで十分なことが多いです。
こうしたツールが検索の裏側で使っている仕組みは、次の記事で整理しています。
アクセス権限を保ったまま運用する
社内文書には人事情報や取引先の機密情報など、閲覧範囲が限定されている資料が含まれることがあるため、RAGに登録する文書からはあらかじめ対象外にしておく必要があります。
登録した文書は月次で見直す担当者を決めておかないと、キャンペーンや規定が変わったあとも古い情報のままAIが回答を続け、現場からの信頼を失う原因になります。
運用開始後は、業務マニュアルの改定タイミングと登録文書の更新をそろえておくと、抜け漏れを防ぎやすくなります。
小売業で店舗からの問い合わせ対応にRAGを活用したケースを、判断材料として紹介します。
【よくある誤解】RAGを導入すればどんな社内文書でも正確に答えられるわけではない
RAGは登録した文書に書かれている範囲でしか正確な回答を作れず、文書自体が古い、あるいは店舗ごとに手順が異なるといった状態のままでは、AIも同じように誤った内容を答えてしまいます。
以前は「AIに任せれば文書の整理も自動でやってくれる」と誤解されがちでしたが、現在では、AIに読み込ませる前の文書の棚卸しが精度を左右する最重要工程だという理解が広がっています。
自社で試す場合も、まずはツールの選定より先に、対象文書の状態を確認するところから始めることをおすすめします。
導入の進め方そのものは、次の記事で順を追って整理しています。
RAGが向かない条件・注意点は？
RAGは文書の検索と要約に強い一方で、数値の集計、全社横断的な複雑な分析、リアルタイム性が求められる動的なデータの扱いは苦手とされています。
在庫数や当日の売上のように秒単位で変化する数値を扱いたい場合は、RAGではなく基幹システムとの直接連携など、別の仕組みを組み合わせる必要があります。
また、そもそも業務手順が文書化されていない会社では、RAGは登録できる資料自体が存在しないため、先にマニュアル作成から着手することになります。
問い合わせ件数が月に数件程度であれば、担当者への電話対応のままで十分なことも多く、無理に仕組みを導入する必要はありません。
自社の業務で整理してみて判断に迷う場合は、 個別相談 で一緒に棚卸しすることもできます。
社内データをAIに答えさせる仕組みづくりで迷っていませんか
「RAGとファインチューニングのどちらが自社に合うか判断がつかない」「社内文書の整理から始めるべきか、先にツールを選ぶべきか分からない」「小さく試したいが何から手をつければよいか分からない」
少しでもお心当たりがあれば、お気軽にご相談ください。
現在、AI業務自動化に関するお悩みをお伺いする 無料の個別相談 を実施しています。
よくある質問
Q. RAGを導入するのに専門的なエンジニアは必要ですか？
NotebookLMのようなツールで小さく試す段階であれば、専門的なエンジニアがいなくても着手できます。
ただし、対象文書の量が多い、アクセス権限を細かく制御したい、複数システムとの連携が必要といった段階になると、構築や運用の設計に専門知識が必要になります。
まずは1つの業務領域に絞って試し、手応えを確認してから範囲を広げる進め方をおすすめします。
Q. RAGとファインチューニングは同時に使えますか？
はい、併用は可能です。
応答の口調や専門用語の使い方をファインチューニングで整えたうえで、最新情報や社内固有のデータの参照をRAGで補う組み合わせ方がよく使われます。
まずはRAGだけで必要な回答精度に届くかを確認し、それでも応答スタイルに課題が残る場合にファインチューニングの追加を検討する、という順番なら無理がありません。
Q. 社内文書が整理されていない状態でも始められますか？
いきなり全ての文書を対象にする必要はありません。
まずは問い合わせが集中している一部の業務領域に絞って、その範囲の文書だけを整理してから試すと、効果を検証しやすくなります。
全社的な文書整備を先に終わらせようとすると着手が遅れるため、範囲を絞った小さな検証から始めることをおすすめします。
Q. RAGの回答が間違っていた場合、原因はどこにありますか？
原因として多いのは、登録した文書自体が古い、または複数の版が混在していることです。
RAGはAIの推論そのものよりも、参照する文書の質に回答精度が左右される仕組みのため、誤答が続く場合はまず文書の棚卸し状況を見直すことをおすすめします。
出典付きで回答するツールであれば、どの文書を根拠にしたかを確認できるため、原因の切り分けがしやすくなります。
