RAGの作り方を7ステップで解説｜社内文書AIを最短で構築する設計手順

▼ この記事の内容

RAGは、社内文書をAIに読ませるだけでは安定しません。作り方は、文書整理、分割、検索、生成、評価、更新運用の順に進め、承認済みナレッジ・権限・回答不可条件まで決めることが重要です。

実務上の課題を考えると、RAGの初期検証では、30問前後の評価質問を用意し、正答、誤答、回答不可を分けて確認します。文書をAIにつなぐだけでは、業務で使えるかを判断できません。

判断の背景を示す例として、社内文書AIを作ろうとすると、どの資料を入れるべきか、権限外の情報をどう避けるかで手が止まりやすくなります。整理しないままPoCへ進むと、古い回答や根拠のない回答が出て、現場から信用されにくい状態になります。

この記事では、RAGを作る工程を文書整理、検索、生成、評価、更新運用の順に整理します。読み終えると、PoCで確認する項目と業務利用へ進めるための判断基準が分かります。

RAGとは何か。作り方の前に押さえる基本構造

RAGは、外部文書を検索し、その根拠を生成AIへ渡して回答を作る方法です。社内文書AIでは、モデルの性能だけでなく、検索対象の文書品質と回答に使う条件が成否を左右します。

弊社が営業改善支援で扱う確認済みナレッジでも、成果を分けるのはAIの回答文そのものではなく、どの資料を根拠として使ってよいかの管理です。RAGも同じく、文書の承認状態と回答責任を決めてから技術設計へ進む必要があります。

作り方を考える前に、RAGが何を変える仕組みなのかを押さえます。FAQ、チャットボット、ファインチューニングとの違いも、参照する根拠の扱い方で整理します。

RAGは検索と生成を組み合わせる仕組み

RAGは、検索で得た根拠文書を生成AIに渡し、回答を作る方法です。社内文書AIでは、まず回答させたい文書と質問範囲を決める必要があります。

RAGは retrieval と generation の2工程で理解すると整理しやすい方法です。検索対象から1件以上の関連文書を取り出し、その内容を回答生成の材料にします。

通常の生成AIに質問だけを渡すと、社内ルールや最新資料を知らないまま回答する可能性があります。RAGは、承認済みナレッジを根拠として渡し、回答のよりどころを限定します。

営業やCSの現場では、提案資料、FAQ、対応履歴、製品仕様書の更新頻度が高くなります。RAGを作る前に、AIへ渡してよい情報と渡してはいけない情報を分けることが出発点です。

参考：Build a Retrieval Augmented Generation (RAG) App｜LangChain Docs

FAQ、チャットボット、ファインチューニングとの違い

RAGは、質問のたびに文書を検索して回答を作る点が、固定回答や追加学習と異なります。更新される社内文書を扱う場合は、回答内容を文書側で管理しやすい方法です。

FAQは、想定質問と回答が固定される業務に向きます。チャットボットは会話窓口を担いますが、裏側で参照する情報が古ければ、回答品質は安定しません。

ファインチューニングは、モデルの振る舞いや文体を調整する用途に向きます。社内規程や商品資料のように内容が変わる情報は、学習し直すより検索対象を更新する方が運用しやすい場合があります。

違いは、何を変えたいかで判断します。回答の口調を変えたいなら調整学習、最新文書を根拠にしたいならRAG、定型質問だけならFAQを優先します。

表で分けると、RAGはAIの会話能力を高める方法ではなく、参照する根拠を制御する方法だと分かります。自社文書を扱う場合は、まず情報の更新頻度と回答責任を見ます。

社内文書AIでRAGが向くケース

RAGは、社内文書が更新され、回答根拠を示したい業務に向きます。営業資料、FAQ、製品仕様、社内手順書を横断して探す場面で検討しやすい仕組みです。

向いているのは、質問の型がある程度見えており、根拠文書も存在するケースです。CS責任者なら、顧客対応FAQと仕様変更履歴をつなぐ用途から始めると範囲を絞れます。

文書が散らばり、承認者や更新日が不明な場合は、RAG構築を急がない方がよいです。未整理の文書を検索対象にすると、AIは古い情報や権限外の情報を拾いやすくなります。

営業やCSでの活用場面を広げたい場合は、まず対象業務を分けて考えるのがおすすめです。RAGの営業・CS活用の判断軸は、営業現場でRAGを使う業務の見極め方でも整理しています。

営業AI・営業DX RAGを営業で活用する方法｜効く業務の見極めと失敗しない始め方

RAGが向くかどうかは、AIに何を答えさせたいかではなく、どの文書を根拠にしてよいかで決まります。次のセクションでは、実際に作る手順へ進みます。

RAGの作り方7ステップ

RAGの作り方は、文書を集めてAIにつなぐ作業だけではありません。対象文書、分割、取得基盤、回答生成、根拠提示、評価、更新運用を一連の業務として設計します。

最初から大きく作るより、業務でよく聞かれる質問範囲を絞る方が安定します。社内問い合わせや営業ナレッジでは、使う文書と答えない質問を先に決めることが出発点です。

ここでは、実装前の範囲決めから評価と更新運用までを順に確認します。技術構成だけでなく、自社で再現できる運用条件も同じ粒度で見直します。

1. 対象文書と質問範囲を決める

RAGの最初の手順は、対象文書と質問範囲を先に決めることです。社内規程、FAQ、提案資料、議事録を一度に入れると、回答の根拠がぶれやすくなります。

CS部門なら、まず問い合わせ対応マニュアルと承認済みFAQに絞るのが現実的です。営業部門なら、商材別の提案資料と失注理由メモを分けて扱います。

対象範囲を決めるときは、誰が何を聞くAIなのかを1文で表します。新入社員向けの社内FAQなのか、営業担当向けの提案支援なのかで必要な文書が変わります。

質問範囲を曖昧にしたまま作ると、古い資料や権限外の文書まで回答候補に混ざります。最初は小さく作り、よく聞かれる質問で使えるかを確認します。

2. 文書を分割して検索しやすくする

文書分割では、AIが根拠として扱いやすい単位に文書を切ります。1ファイル全体をそのまま扱うと、必要な説明と関係ない文章まで回答に混ざります。

分割単位は、見出し、項目、FAQの質問単位を基準にします。営業資料なら、課題、提案内容、料金条件、導入手順を混ぜずに分ける方が扱いやすくなります。

細かく切りすぎると、前提条件が欠けた短い断片だけが取得されます。粗く切りすぎると、似たテーマの説明が同じ候補に入り、回答が散らばります。

実務では、分割後の文書にタイトル、対象部門、更新日、承認者を付けます。これにより、AIが使う根拠を後から人が確認しやすくなります。

3. 埋め込みと検索基盤を作る

埋め込みと検索基盤は、質問に近い文書断片を取り出すために作ります。RAGでは、文書をベクトル化し、質問との近さで候補を選びます。

ここで重要なのは、技術構成よりも取り出す候補の質です。似た言葉だけで選ぶと、規程と営業資料のように用途の違う文書が同時に出ます。

候補の質を上げるには、部署、商材、顧客フェーズ、公開範囲などの属性を持たせます。情シス向けの回答に営業限定資料を混補にしないためです。

一般的なRAG実装では、文書取得の仕組みを生成モデルの前段に置きます。LangChainのRAG関連ドキュメントでも、取得した文書を回答生成へ渡す構成が示されています。

参考：Build a Retrieval Augmented Generation (RAG) App｜LangChain

4. 回答生成、根拠提示、回答不可を設計する

回答生成では、AIに答えさせるだけでなく、根拠と回答不可条件を同時に設計します。根拠文書が足りない質問には、推測で答えない制御が必要です。

回答文には、参照した文書名、更新日、該当箇所を添える設計が有効です。社内利用では、答えの自然さよりも、確認できる根拠が信頼を左右します。

次に、評価質問を作って回答品質を確認します。よくある質問、答えてはいけない質問、古い資料に引っ張られやすい質問を分けて試します。

最後に、誤回答の修正方法と文書更新の責任者を決めます。RAGは一度作って終わる仕組みではなく、回答ログと根拠文書を見直しながら運用します。

5. 評価質問で正答・誤答・回答不可を確認する

評価では、実際に利用者が聞きそうな質問を30問前後用意します。正しく答えるべき質問、誤答しやすい質問、回答不可にすべき質問を分けて確認します。

正答の確認では、回答内容だけでなく、参照した根拠が適切かを見ます。根拠文書にない内容を補っている場合は、文章が自然でも合格にしません。

回答不可の確認では、情報不足や権限外の質問に対して推測しないかを見ます。ここで失敗する場合は、プロンプト、検索対象、根拠提示の条件を見直します。

6. 質問ログから改善対象を決める

公開後は、質問ログを見て利用者が何を知りたいのかを確認します。想定していなかった質問が多い場合は、検索対象の文書やFAQの不足が見えてきます。

ログは、正答、誤答、回答不可、根拠不足に分類すると改善対象を決めやすくなります。特に同じ種類の誤答が繰り返される場合は、個別回答ではなく文書側を直します。

質問ログを見る頻度も決めておくと、改善が担当者の感覚に偏りにくくなります。週次や月次で確認し、影響が大きい質問から優先して直します。

7. 更新責任者と再評価日を運用に組み込む

RAGの品質は、根拠文書の更新責任が曖昧だと下がっていきます。部署ごとに文書の責任者を決め、古い情報を誰が直すのかを明確にします。

文書を更新した後は、同じ評価質問で再評価します。30問前後の評価質問を残しておくと、修正前後で回答品質を比べやすくなります。

再評価日は、文書更新のタイミングや定例運用に組み込みます。質問ログ、更新責任、再評価日を一体で管理すると、RAGを継続的に改善できます。

作る前に整理すべき社内文書とナレッジ

社内RAGでは、承認済み情報、権限、更新責任、回答不可条件を先に決めます。文書を入れる前に参照ルールをそろえるほど、誤回答や古い回答を減らしやすい状態になります。

作る前の整理は、技術準備ではなく業務設計です。誰が使い、どの文書を根拠にし、どこから先は人に戻すかを明確にします。

承認済み情報だけを参照対象にする

社内RAGの参照対象は、承認済み情報に限定します。承認前の資料や属人的なメモまで参照対象に含めると、確認前の内容を根拠として回答に使うおそれがあります。

営業部門なら、最新の提案資料、価格条件、導入事例、FAQを承認済みフォルダに分けます。CS部門なら、対応マニュアルと仕様変更履歴を同じ基準で点検します。

承認者を決めずに文書を追加すると、正しい資料と古い資料の区別がつきません。作成者、承認者、適用開始日を持たせると、参照可否を後から判断できます。

承認済み情報だけに絞ると、最初に使える文書量は減ります。それでも、社内説明では対象文書と回答不可条件を先に言語化する方が合意を取りやすい進め方です。

権限外の文書を検索させない

RAGは、ユーザー権限に応じて検索対象を分ける必要があります。閲覧権限のない文書を検索候補に含めると、回答文を通じて情報が漏れるおそれがあります。

情報漏洩が不安な場合は、生成AIの設定だけで防ごうとしない方がよいです。文書保存先、検索インデックス、ユーザー認証を同じ権限体系でそろえます。

営業担当には提案資料と公開済みFAQを見せ、経営会議資料や個別契約条件は除外します。人事や経理の文書も、部署単位ではなく閲覧者の役割で分けます。

権限設計は、後から追加するより最初に決める方が手戻りを抑えます。検索前に除外する文書と、回答時に伏せる情報を分けて管理します。

更新責任者と更新日を文書ごとに持つ

社内RAGの文書には、更新責任者と更新日を必ず持たせます。更新者が不明な文書は、回答の根拠として使い続けるほど現場の信頼を失いやすくなります。

価格表、仕様書、営業トーク、FAQは変更頻度が異なります。月次で見直す文書と、変更発生時だけ更新する文書を分けると運用負荷を抑えられます。

管理項目は、文書名、担当部門、承認者、更新日、次回確認日で十分です。最初から複雑な台帳を作るより、回答に使ってよいかを判断できる粒度を優先します。

上申時は、対象文書、責任者、成果指標を一枚で説明できる状態が必要です。社内ナレッジを業務で使う準備として、文書だけでなく評価軸も整理します。

更新責任を持たせると、古い回答を見つけた後の対応が速くなります。誰に戻せば直るのかが明確になり、RAGを継続的に改善しやすくなります。

答えられない質問を先に定義する

RAGでは、答えられない質問を先に定義します。根拠文書がない質問まで答えさせると、自然な文章でも業務上は誤回答になります。

回答不可は失敗ではなく、安全に業務利用するための条件です。契約条件、個別見積もり、法務判断、未公開情報のように、人の確認へ戻すべき質問を明示します。

実務では、回答不可の条件を質問例で持つと運用しやすくなります。営業担当なら、値引き可否や競合比較の断定をAIだけで回答しないようにします。

答えない範囲を決めるほど、AIの回答品質は評価しやすくなります。文書整理の次は、古い文書や重複文書がどのような失敗を生むかを確認します。

RAGで失敗しやすいパターン表

RAGの失敗は、生成AIの性能だけで起きるものではありません。文書品質、検索設計、評価不在、運用責任の曖昧さが重なると、正しい根拠を探せないまま回答が作られます。

失敗パターン	起きる問題	先に決めること
古い文書や重複文書を参照する	回答内容が部署や時期でぶれます	参照対象と除外条件
チャンク分割が粗い	根拠に不要な情報が混ざります	文書タイプ別の分割単位
評価質問がない	PoCの成否を説明できません	代表質問と不合格条件
運用責任がない	古い回答が放置されます	更新責任者とレビュー頻度

失敗パターンを表に分けると、RAG構築で直すべき対象が明確になります。モデル変更より先に、参照文書と評価方法を点検するのが現実的です。

古い文書や重複文書を参照する

古い文書や重複文書が混ざると、RAGは同じ質問に別々の根拠を拾います。営業資料、FAQ、社内規程の版がそろっていない場合、回答の一貫性が崩れます。

廃止済みの料金表や旧運用マニュアルが共有フォルダに残ると、AIが古い条件を根拠にする場合があります。RAGは人間のように最新版を察知しないため、参照対象に残った文書を根拠として扱います。

文書品質を点検する際は、タイトル、作成日、更新日、承認者、利用対象部署をそろえます。履歴として残す文書は保存してもよいですが、回答用の参照対象からは外す必要があります。

チャンク分割が粗く根拠が外れる

チャンク分割が粗いRAGでは、必要な根拠と不要な説明が同じ取得候補に混ざります。チャンクとは、文書を検索しやすい単位に分けた本文のかたまりを指します。

営業FAQなら質問と回答を1組で分けると、回答根拠が保ちやすくなります。長いマニュアルを章単位のまま入れると、近そうに見えても回答に余計な条件が混ざります。

分割単位は、文書の見出し、FAQの設問、業務手順の区切りに合わせて決めます。表や箇条書きが多い資料では、項目名と説明文を切り離しすぎない設計が必要です。評価質問で根拠の外れ方を見ながら、粒度、重なり、メタ情報を調整します。

評価質問がなく精度を判断できない

評価質問がないRAGは、精度が高いか低いかを説明できません。現場で多い質問、誤回答が許されない質問、回答不可にすべき質問を分けて検証します。

PoCでは早く触れる画面を作りたいと感じる方は多いです。しかし代表質問がないまま試すと、担当者の印象だけで合否が決まり、改善すべき箇所が見えません。

評価質問は、正答できる質問だけでなく、答えてはいけない質問も含めます。方式やツールの比較に進む前に、RAG比較で見るべき判断軸を確認すると、評価項目を整理しやすくなります。

営業AI・営業DX RAGをどう比較する？同じ資料と質問で根拠・更新・権限・運用費用を確認する

運用責任がなく更新されない

運用責任がないRAGは、導入直後だけ使われて徐々に信用を失います。問い合わせ対応や営業資料は変わるため、更新されない参照文書は誤回答の原因になります。誰が質問ログを見て、誰が回答根拠を直すかまで決めます。

小規模な営業組織なら、営業企画、情シス、現場責任者で役割を分けると運用が止まりにくくなります。情シスだけに任せると、業務文脈の誤りを見落とす可能性があります。

RAGは作った時点で完成する仕組みではなく、質問ログと文書更新を回して業務に近づけます。次のセクションでは、精度を安定させる確認済みナレッジ運用を整理します。

精度を安定させる確認済みナレッジ運用

RAGの精度は、初回実装だけで固定されません。質問ログ、誤回答レビュー、承認済みナレッジの更新を回すことで、業務で使う回答に近づきます。

ここで重要なのは、回答結果だけでなく、根拠文書と更新責任まで見直すことです。関係者、データ、運用会議、成果指標を同じ粒度で確認します。

質問ログから失敗しやすい質問を集める

RAGの改善対象は、質問ログから優先順位を決めます。現場が実際に入力した質問を見れば、文書不足、検索ずれ、回答不可の不足を分けやすくなります。

最初に見るべきなのは、回答が外れた質問だけではありません。回答は合っていても根拠が弱い質問や、毎回同じ確認が発生する質問も改善候補になります。

CS部門なら、契約条件、解約手順、障害時の案内などを分けて確認します。情シス部門なら、アカウント申請、権限変更、端末トラブルの質問を別々に扱います。

ログがまだ少ない場合は、現場FAQや問い合わせ履歴から代表質問を選びます。質問を集める目的は件数を増やすことではなく、改善すべきナレッジを絞ることです。

誤回答レビューを人が承認する

誤回答レビューは、人が承認してからナレッジへ反映します。RAGの回答をそのまま正解扱いにすると、誤った修正や古い判断が次の回答にも残ります。

営業改善プログラム「FAZOM」では、人の確認を挟む運用をHITLとして扱います。HITLはAIの出力を止める仕組みではなく、承認済みナレッジへ戻す前の品質確認です。

【営業改善プログラム「FAZOM」の設計思想】

営業改善プログラム「FAZOM」では、現場の問いを集める工程を「Discovery」、人が確認する工程を「HITL」、運用後に回答を見直す工程を「Validate」と呼びます。改善した内容は「Retain」として承認済みナレッジへ戻し、次の回答品質を整えます。

人が入ると遅くなると感じる方は多いです。すべての回答を確認するのではなく、権限、契約、顧客対応など失敗時の影響が大きい領域だけを優先します。

承認者は、AI担当者だけに寄せない方が実務に合います。CS責任者、情シス、業務部門の担当者を分けると、判断の遅れと責任の曖昧さを抑えやすくなります。

根拠文書と回答をセットで見直す

RAGの改善では、回答文だけでなく根拠文書も同時に見直します。回答だけを直しても、検索される文書が古いままなら同じ誤回答が再発しやすくなります。

見直し順は、根拠文書、取得内容、回答生成の順に分けると整理しやすいです。文書が正しいのに回答がずれる場合は、チャンクやプロンプトを確認します。

規約の最新版はあるのに旧版のPDFも検索対象に残る場合は、モデル調整より参照対象から旧版を外す判断が先です。確認済みナレッジ運用は、RAGを作った後の保守作業ではありません。導入前から評価質問、承認者、更新責任を決めることで、内製、SaaS、外注の判断も具体化します。

内製、SaaS、外注の判断軸

RAGの構築方法は、技術力、機密性、更新頻度、評価設計、運用責任で選びます。短期PoCを急ぐ場合と、社内基盤として育てる場合では、適した進め方が変わります。

比較では、表面的な費用差だけでなく、自社で再現できる条件を確認します。関係者、データ、運用会議、成果指標を同じ粒度で見直します。

内製が向くケース：技術者と運用責任者を置ける

内製は、技術者と運用責任者を継続的に置ける組織に向いています。文書連携、検索調整、権限設計、評価質問の更新を社内で回せることが条件です。

機密性の高い文書や独自システム連携が多い場合、内製は設計自由度を持てます。一方で、保守担当が離れると改善が止まりやすくなります。

内製を選ぶなら、PoCの前に運用責任者を決めます。技術検証だけで終えると、本番化後の文書更新と評価が宙に浮きます。

SaaSが向くケース：短期でPoCし、運用画面や権限管理を使いたい

SaaSは、短期でPoCを始め、管理画面や権限管理を早く使いたい場合に向いています。開発負荷を抑えながら、文書登録と評価を進められます。

営業やCS部門が主導する場合、SaaSは運用担当者が触りやすい点で有利です。技術者だけに依存せず、文書更新や利用状況の確認を進められます。

一方で、独自連携や細かい検索制御には制約が出る場合があります。SaaSを選ぶときは、権限、ログ、評価質問、更新フローを確認します。営業AIツール全体の選定条件まで比較したい場合は、営業AIツール比較の判断軸も確認材料になります。

外注が向くケース：要件定義、セキュリティ、連携設計が重い

外注は、要件定義、セキュリティ確認、既存システム連携に社内工数が多くかかる場合に向いています。社内だけで設計判断を持てないとき、初期設計の支援を受けられます。

複数部署の文書を扱う場合、権限や承認フローの整理に時間がかかります。外注先には、AI開発だけでなく業務設計まで求める必要があります。

外注を選んでも、更新責任を外部へ丸投げする運用は不安定です。社内側に文書承認者と評価担当を置き、改善判断を持ちます。

判断表：技術力、機密性、更新頻度、評価設計、運用責任で比較する

内製、SaaS、外注は、費用だけで比較しないほうがよいです。RAGでは、導入後に誰が文書と評価質問を更新するかが成果を左右します。

判断軸は、技術力、機密性、更新頻度、評価設計、運用責任に分けます。以下の表で、自社がどこを担えるかを確認します。

選択肢	向く条件	注意点
内製	技術者と運用責任者を置ける	保守と評価が社内負荷になる
SaaS	短期PoCと管理画面を重視する	細かな連携に制約が出る場合がある
外注	要件定義やセキュリティ設計が重い	社内の更新責任は残る

表で最も確認すべき点は、導入後の運用責任です。次の導入前チェックでは、PoC前に決める質問、文書、権限、KPIを整理します。

導入前チェックリスト

RAGの導入前には、文書、権限、評価、運用、成果指標を確認します。作り始める前に停止条件まで決めると、PoC後の継続判断がぶれにくくなります。

チェックリストは、技術要件を並べるためではなく、業務利用に耐える条件をそろえるために使います。CS、営業、情シス、管理部門で見ているリスクを同じ表に置きます。

文書、権限、更新責任を確認する

導入前チェックは、文書、権限、更新責任の3点から始めます。小規模なPoCでも、参照してよい文書と責任者が曖昧なままでは回答品質を判断できません。

文書は、承認済み、確認中、参照禁止の3区分に分けます。営業資料なら、最新版の提案書、価格条件、FAQ、導入手順を混ぜずに管理します。

権限は、部署名だけでなく利用者の役割で分ける必要があります。全社公開のFAQと、個別契約条件や経営会議資料を同じ検索対象に入れない設計が必要です。

更新責任は、文書ごとに担当部門、承認者、次回確認日を置くと運用しやすくなります。最初の確認で迷う文書は、RAGへ入れる前に人が判断します。

30問前後の評価質問を用意する

評価質問は、RAGのPoCを印象評価で終わらせないために用意します。初期検証では30問前後を目安に、正答、誤答、回答不可を分けて確認します。

質問は、現場で実際に聞かれる内容から選びます。CSなら解約手順、仕様変更、障害時対応を分け、営業なら提案条件、商材別FAQ、競合言及を分けます。

評価質問には、答えてはいけない質問も入れます。根拠がない質問に推測で答えないかを確認すると、生成AIの誤回答リスクを切り分けやすくなります。

誤回答の原因をさらに深掘りしたい場合は、生成AIの誤回答リスクを分けて見る考え方も確認材料になります。RAG本体の評価では、根拠文書、取得された根拠候補、回答文を分けて見ます。

営業AI・営業DX 生成AIのハルシネーションとは｜原因・事例と業務利用で防ぐ5つの対策

成果指標と停止条件を決める

成果指標と停止条件がないRAGは、PoC後に社内説明が止まりやすくなります。費用より先に、どの問い合わせ品質を改善対象にするかを決めます。

成果指標は、正答率だけに寄せない方が実務に合います。根拠提示率、回答不可の適切さ、再質問の減少、現場レビュー工数などを組み合わせます。

【営業改善プログラム「FAZOM」の導入前レビュー】

評価質問は、正解できる質問だけでなく、答えないべき質問も含めて設計します。成果指標は、回答精度だけでなく、現場が継続利用できる条件まで確認します。

作っても効果を説明できないと感じる場合は、導入判断を急がない方がよいです。まずは回答品質、更新責任、現場レビューの負荷を見える形にします。

RAG専用の診断資料が未整備でも、営業改善の実行と定着を相談前に整理する入口は作れます。自社で進める範囲と支援を受ける範囲を切り分けたい場合は、営業改善プログラム「FAZOM」の全体像を確認できます。

よくある質問

RAGはプログラミングなしで作れますか？

プログラミングなしでも、SaaSを使えば小さく始められます。ただし、文書整理、権限、更新責任、回答不可条件は自社で決める必要があります。本格運用では、評価質問で使える範囲を確認します。

RAGとファインチューニングは何が違いますか？

RAGは質問のたびに外部文書を検索し、その根拠を使って回答します。ファインチューニングはモデルの振る舞いや文体を調整する方法です。最新文書を根拠にしたい場合はRAGを優先しやすくなります。

社内文書をRAGに使うときの注意点は何ですか？

承認済み文書だけを参照対象にし、権限外の文書を検索させない設計が必要です。更新責任者、更新日、回答不可条件も持たせます。未整理の文書を入れると、古い回答や情報漏洩リスクが残ります。

まとめ

RAGの作り方は、文書を集めてAIにつなぐ手順だけではありません。対象文書、権限、分割、検索、根拠提示、評価質問、更新責任を一連の業務として設計する必要があります。

内製、SaaS、外注のどれを選ぶ場合でも、導入後に誰が文書と評価質問を更新するかが重要です。方式やツールの比較に進む前に、RAG比較で見るべき判断軸を確認すると、選定条件を整理しやすくなります。