RAG開発とは？自社の専門知識で答えるAI機能の考え方

RAG（ラグ）とは、AIが回答を作る前に、自社の資料から関連する情報を探し出し、それを根拠に答えさせる仕組みのことです。この記事では、RAG開発の基本的な仕組み、新規事業サービスに向く場面、組み込むときに先に決めておきたいことを順に整理します。専門知識を答えるAI機能を事業の中心に置きたい場合の、考え方の材料として読んでください。

RAGとは何か

RAGは「Retrieval-Augmented Generation」の略で、日本語では「検索拡張生成」と訳されることが多い言葉です。「Retrieval（検索）」で情報を探し、「Generation（生成）」で文章を作る、という2つの動きを組み合わせた仕組みを指します。

LLMだけでは「自社の知識」を答えられない

ChatGPTやClaude、GeminiといったLLM（大規模言語モデル。大量の文章から言葉の規則を学んだAI）は、学習した時点までの一般的な知識をもとに答えます。

そのため、次のような質問には弱い面があります。

• 自社だけが持っている手順書、マニュアル、過去の対応記録に関する質問
• 学習した後に更新された規程や、最近できたルールに関する質問
• 一般には公開されていない専門領域の判断基準についての質問

知らないことを聞かれたとき、LLMはもっともらしい文章で答えてしまうことがあります。これは「ハルシネーション」と呼ばれる現象で、事業でAIを使うときの大きな注意点です。見つけ方や防ぎ方は、生成AIのハルシネーションが開発に混ざるとき｜見つけ方と防ぎ方でも整理しています。

RAGは「資料を見ながら答える」仕組み

RAGは、この弱点を補うための考え方です。試験にたとえると、何も見ずに答える形式ではなく、「資料の持ち込みを許可して、該当するページを開いてから答える」形式に近いと言えます。

流れは次のとおりです。

1. 利用者が質問を入力する
2. システムが、自社の資料の中から質問に関係しそうな部分を探し出す
3. 探し出した部分を質問と一緒にLLMへ渡す
4. LLMが「渡された資料の内容」をもとに回答を作る
5. 必要に応じて、どの資料を根拠にしたかを一緒に表示する

LLM自体を作り直すのではなく、LLMに渡す材料を、質問のたびに入れ替える仕組みです。資料を更新すれば、次の質問から新しい内容で答えられる点が特徴です。

RAGの仕組みを開発の目線で分解する

RAG開発と聞くと難しく感じるかもしれませんが、部品に分けると考え方は単純です。大きくは「資料を準備する」「探す」「答える」の3段階に分かれます。

1. 資料を取り込む

PDF、Word、社内のドキュメント、データベースの内容などを読み込み、探しやすい大きさに区切ります。この区切った単位は「チャンク」と呼ばれます。

次に、区切った文章を「埋め込み（エンベディング）」という処理にかけます。これは、文章の意味を数値の並びに変換するもので、意味が近い文章ほど近い数値になります。変換した結果は、「ベクトルデータベース」など、意味の近さで検索できる保管場所に入れておきます。

2. 質問に合う部分を探す

利用者の質問も同じ方法で数値に変換し、保管してある資料の中から意味が近いものを探します。キーワードが一致していなくても、意味が近い文章を見つけられるのが利点です。

実際の開発では、意味での検索に加えて、キーワード検索を組み合わせることもあります。型番や専門用語のように、一字一句の一致が大事な情報では、キーワード検索のほうが向く場合があるためです。

3. 見つけた資料をもとに答える

探し出した資料を、質問と一緒にLLMへ渡します。このとき「渡した資料に書かれていないことは答えない」「分からないときは分からないと伝える」といった指示を添えます。ここでの指示の設計が、回答の信頼感を大きく左右します。

ファインチューニングや、資料の貼り付けとの違い

自社の知識をAIに答えさせる方法は、RAGだけではありません。代表的な方法を並べると、違いが見えやすくなります。

方法	内容	向く場面
資料をそのまま貼り付ける	質問のたびに全資料を入力に含める	資料が少なく、試しに動かしたいとき
RAG	質問に関係する部分だけ探して渡す	資料が多く、更新もあるとき
ファインチューニング	追加データでモデル自体を調整する	文体や回答の型を整えたいとき

ファインチューニングは、知識を覚えさせる方法というより、答え方の癖や形式を整える方法として使われることが多い手段です。更新が頻繁な知識や、根拠を示したい用途では、RAGのほうが扱いやすい場面があります。ただし、どれが適しているかは、扱う資料の量や更新の頻度、求める回答の形によって変わります。

新規事業サービスにRAGが向く場面

RAGは、業務の効率化にも使えますが、ここでは新規事業の観点に絞って考えます。注目したいのは、専門知識そのものがサービスの価値になる事業です。

専門知識を、使える形で届けるサービス

たとえば、特定の業界の規程や手続きに詳しい人の知識を、利用者がいつでも質問できる形にするサービスが考えられます。これまで人が時間をかけて答えていた相談を、システムが一次回答するという構成です。

こうした事業では、「何を知っているか」が競争力になります。誰でも使える一般的なAIに質問するのと、その事業だけが整理した知識を根拠に答えるのとでは、回答の質に差が出ます。ノウハウをサービスにする考え方は、ノウハウのサービス化とシステム化｜事業にできる部分の見つけ方で詳しく扱っています。

RAGが向く条件

次の条件がそろうほど、RAGを組み込む意味が大きくなります。

• 答えの根拠になる文書や記録が、すでにある、または用意できる
• 知識が更新されるため、都度の再学習は現実的でない
• 回答の根拠を、利用者に示したい
• 質問の種類が多く、あらかじめ全問の答えを用意しにくい

向かない場面もある

一方で、RAGが得意でない領域もあります。

• 売上の集計や、複雑な計算を正確に行いたい場合は、データベースの検索やプログラムでの計算のほうが適しています。
• 手順が完全に決まっている処理は、AIの回答ではなく、決まった画面と処理で作るほうが安定します。
• 根拠となる資料がそもそも整理されていない場合は、AIの前に、資料の整理が必要になります。

RAGは便利な部品ですが、事業の課題すべてを解決するものではありません。どこにAIを使い、どこは通常のシステムで作るかを分けることが、設計の出発点になります。

RAGを事業に組み込む前に決めておきたいこと

RAGの技術的な組み立て自体は、年々扱いやすくなっています。むしろ、事業として使うときに迷いやすいのは、技術以外の判断です。開発に入る前に、次の6点を整理しておくと後の手戻りを減らせます。

1. どの知識を、誰のものとして扱うか

AIに読ませる資料の中に、第三者の著作物や、取引先との契約で外に出せない情報が混ざっていないかを確認します。また、利用者に回答として見せてよい範囲と、内部でのみ使う範囲も分けておく必要があります。

外部のAIサービスに資料を送る場合の考え方は、生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアにまとめています。個人情報を含む場合は、新規事業の個人情報とシステム設計｜設計前に確認する点も合わせて確認してください。

2. 資料をどう整えるか

RAGの回答の質は、資料の質に強く左右されます。同じ内容が複数の文書で食い違っていたり、古い版が残っていたりすると、AIはそのまま混ぜて答えてしまいます。

• 最新版はどれかを決める
• 表や図で表された情報を、文章として読み取れる形にする
• 誰が、いつ、資料を更新するかを決める

資料の整理は地味な作業ですが、ここに手をかけたかどうかが、後の回答の差になります。

3. 分からないときの振る舞い

専門知識を扱うサービスでは、「間違って答える」ことのほうが、「答えない」ことよりも信頼を損ないやすい場合があります。そこで、次のような方針を先に決めておきます。

• 根拠となる資料が見つからないときは、推測で答えず、その旨を伝える
• 回答に根拠の資料名や該当箇所を添える
• 判断が難しい質問は、人の担当者に引き継ぐ

どこまでAIに任せ、どこから人が対応するかは、サービスの信頼に直結します。AIと人の役割分担の考え方は、AI開発でも品質には人の確認が必要な理由でも触れています。

4. 良い回答の基準と、確かめ方

「正しく答えられているか」は、感覚だけでは判断できません。実際に利用者が聞きそうな質問を集め、それぞれに期待する答えを決めておくと、変更の前後で比べられます。

RAGでは、次の2つを分けて見ると原因を特定しやすくなります。

• 探す段階：質問に必要な資料を、正しく見つけられているか
• 答える段階：見つけた資料に沿って、正しく文章にできているか

回答が間違っていたとき、資料を見つけられなかったのか、見つけたのに読み違えたのかで、直す場所が変わります。評価項目の決め方は、LLMアプリ開発の精度評価｜開発前に決める5つの項目を参考にしてください。

5. 権限と公開範囲

利用者ごとに見てよい資料が異なる場合は、探す段階で閲覧権限を反映させる必要があります。この設計を後回しにすると、見せるべきでない資料の内容が回答に出てしまう恐れがあります。最初の設計で、利用者の種類と見せる範囲の対応を整理しておきます。

6. 使うAIモデルが変わる前提を置く

LLMは、新しいモデルが出たり、古いモデルの提供が終了したりします。モデルを入れ替えても動くように、AIを呼び出す部分を切り分けておくと、変更に対応しやすくなります。考え方は、LLMモデル変更に備える開発の進め方｜提供終了の前にで扱っています。AIの選び方そのものは、AIシステム開発でのAIの選び方｜2026年10月比較も参考になります。

RAG開発で起きやすい失敗

ここからは、RAGを組み込むサービスでつまずきやすい点を挙げます。あらかじめ知っておくと、確認の観点が増えます。

資料が読み込まれているのに、答えがずれる

資料の区切り方が適切でないと、答えに必要な前提が別のチャンクに分かれてしまい、断片的な情報だけでLLMが答えてしまうことがあります。区切る大きさや、見出しを残すかどうかで、結果が変わります。

似た内容が多く、違う資料を拾う

専門領域では、似た表現で条件だけ違う規程が複数あることがあります。意味の近さだけで探すと、違う条件の資料を拾う場合があります。対象の種類や適用日などの情報を資料に付け、絞り込めるようにする方法が使われます。

回答が自信ありげで、誤りに気づきにくい

資料にない内容を、LLMが自然な文章で補ってしまうことがあります。文章が整っているほど、誤りは見つけにくくなります。根拠の表示や、人が定期的に回答を抜き取って確認する運用が、品質を保つ助けになります。

作ったあとの更新が回らない

最初に資料を取り込んで終わりにすると、時間とともに内容が古くなります。資料の更新が、誰の仕事になるのかを決めていないと、サービスの信頼が少しずつ下がります。システムは作って終わりではなく、育てていくものだという考え方は、システムは納品後の改善で育てる｜新規事業の考え方で書いています。

動くプロトタイプで確かめる進め方

RAGは、資料をいくつか取り込んで質問すれば、短い期間でも動くものが作れます。一方で、「実際の利用者の質問にどこまで答えられるか」は、動かしてみないと分かりません。そこで、本格的に作り込む前に、小さく作って確かめる進め方が向いています。

確かめたいことを絞る

最初のプロトタイプでは、次の問いに答えが出れば十分です。

• 手元の資料だけで、現場で出る質問の多くに答えられそうか
• 回答の根拠を示したとき、利用者は安心して使えそうか
• 答えられない質問は、どんな種類に偏っているか
• 資料の更新を、どのくらいの手間で回せそうか

生成AIを使うサービスで、プロトタイプの段階で確かめておきたい項目は、生成AIを使う新規事業サービスで、プロトタイプで確かめたいことに整理しています。

実際の質問と、実際の資料で試す

作り物のデータで動かすと、うまく答えているように見えがちです。可能な範囲で、現場で実際に出ている質問と、実際に使っている資料で試すことで、事業として成り立つかどうかの判断材料になります。

また、質問と回答を画面で触りながら確認すると、言葉の説明だけでは気づけない点が見つかります。たとえば「この言い方だと現場では通じない」「この資料は根拠として足りない」といった指摘です。実物を見ながらすり合わせる利点は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで説明しています。

結果を見て、次の判断をする

プロトタイプで分かったことをもとに、続ける、範囲を変える、見送る、のいずれかを判断します。見送ることも、早い段階で分かれば大きな成果です。アイデアを動くものでどう確かめるかは、新規事業のアイデア検証方法｜動くシステムで確かめる手順も参考になります。AIを活用した開発で、プロトタイプが短い期間で作れる仕組みは、AIでプロトタイプを短期間で作れる理由｜工程ごとの仕組みで説明しています。

まとめ

RAGは、AIが回答を作る前に自社の資料から関連する情報を探し、それを根拠に答えさせる仕組みです。LLMだけでは答えられない専門知識や、更新される情報を扱えるため、専門知識そのものが価値になる新規事業サービスと相性があります。

一方で、RAG開発で結果を左右するのは、技術の選び方だけではありません。次のような点を、開発に入る前に整理しておくことが大切です。

• どの知識を、どの範囲で、誰に見せるか
• 資料をどう整え、誰が更新するか
• 分からないときに、AIと人がどう分担するか
• 良い回答の基準を、何で確かめるか
• モデルが変わっても使い続けられる作りにするか

そして、実際の質問と資料で動かしてみることで、事業になるかどうかの判断材料が得られます。

JustFitは、株式会社LEGAREAが運営する受託開発サービスで、「先に作って、後から決める」という考え方のもと、構想をもとに約1ヶ月で動くプロトタイプを開発します。実物を見てから契約を判断できるため、専門知識を答えるAI機能を軸にした構想のように、仕様が固まっていない段階の相談にも向いています。進め方の全体像はJustFitのサービス紹介で紹介しています。