RAG構築の5工程｜社内文書AIの作り方と精度改善の手順

「RAGの意味は分かった。では、自社の文書でどう作るのか」。ここでつまずく中小企業の担当者は非常に多いです。解説記事は仕組みの図までは丁寧なのに、実際の作業になると急に専門用語だけになるからです。

そのまま手探りで進めると、たいてい同じ場所で止まります。社内文書を集めて入れたのに、聞いても正しく答えてくれないという状態です。原因の大半は生成AIの能力ではなく、その手前の「検索」の設計にあります。ここを直さないまま高性能なモデルに変えても、結果はほとんど変わりません。

本記事では、中小企業のAI導入を支援するAi-Rakuの視点で、RAG構築を5つの工程に分け、各工程で何を決め、どこでつまずき、どう直すかを具体的に整理します。用語そのものがまだあいまいな方は、先にRAGとは｜社内文書をAIに使わせる仕組みをお読みください。本記事はその続きとして、「作る側」の手順に絞って書いています。

結論｜RAGは検索が9割

先に結論を書きます。RAG構築の成否は、生成AIの性能ではなく「検索の設計」でほぼ決まります。 RAG（Retrieval-Augmented Generation／検索拡張生成）は、質問が来るたびに社内文書を検索し、見つかった文書をAIに読ませてから答えさせる仕組みです。つまりAIは、渡された文書の範囲でしか答えられません。検索が間違った文書を持ってくれば、AIはその間違った文書をもとに、もっともらしく答えます。

精度が出ない原因は検索側

「RAGを作ったが精度が低い」という相談を受けたとき、Ai-Rakuが最初に見るのは回答文ではありません。その質問に対して、どの文書のどの部分が検索で拾われたかです。ここを見ると、原因は次の3つのどれかに収まることがほとんどです。

1. 正解が書かれた文書が、そもそも検索対象に入っていない
2. 文書は入っているが、検索の上位に出てこない
3. 上位には出ているが、分割の切れ目が悪く、肝心の一文が欠けている

3つとも、生成AI側では直せません。モデルをGPTからClaudeに変えても、上位に出てこない文書は上位に出てきません。直すべき場所は検索の側であり、だからこそ「RAGは検索が9割」なのです。

この構造は公式ドキュメントでも明示されています。Microsoft LearnのAzure AI SearchにおけるRAGの解説では、RAG実装が直面する課題として「クエリの理解」「複数ソースへのアクセス」「トークン制約」「応答時間」「セキュリティとガバナンス」の5つが挙げられており、いずれも検索システム側の課題です（出典：Microsoft Learn「Azure AI Search でのレトリーバル拡張生成 (RAG)」）。

先に作るのは検索の土台

したがって、構築の順番も検索から入ります。チャットの画面や社内への告知は最後で構いません。先に「社内文書を検索したら、正しい文書が上位に出る」状態を作り、そのうえで生成AIをつなぐ。この順番を守るだけで、手戻りは大きく減ります。

逆に、よくある失敗が「まずデモを作って見せる」です。デモは動くので社内の期待が上がり、その状態で文書整備の話をすると「まだ準備が必要なのか」と失望されます。検索の土台ができてから見せるほうが、結果的に社内の合意も早く取れます。

前提知識はこの記事で補う

本記事は「作り方」に集中するため、用語の定義は最小限にとどめます。RAGそのものの意味・仕組み・向く業務はRAGとは｜社内文書をAIに使わせる仕組みで解説しています。AIが社外のツールやデータに接続するための規格についてはMCPとはとMCPサーバーとはを、検索した情報をもとにAIが自律的に動く仕組みはAIエージェントの作り方をあわせてご覧ください。

RAG構築の全体像と5工程

全体像を2つの視点で押さえます。「動いているときの流れ」と「作るときの作業」は別物です。ここを混同すると、作業の見積もりを大きく外します。

動くときの流れは4段階

RAGが質問に答えるまでの流れは、AWSの技術ガイダンスでは大きく4段階として説明されています。1段階目だけが一度きりの準備で、残りの3段階が質問のたびに繰り返されます（出典：AWS Prescriptive Guidance「Understanding Retrieval Augmented Generation」）。

同じガイダンスでは、実運用のRAGに必要な部品として、データ源との接続（コネクタ）、データ処理、埋め込み、ベクトルデータベース、検索器（リトリーバー）、基盤モデル、ガードレール、全体を回すオーケストレーター、利用画面、そしてID・権限管理が挙げられています。権限管理が部品として明記されている点は、中小企業の構築でも軽視できません。

作る側の作業は5工程

一方、作る側の作業を並べると次の5工程になります。本記事はこの順番で解説します。

工数の配分は前半に寄る

ここで多くの会社が見誤るのが工数の配分です。技術的な実装よりも、工程1の文書整備と工程4の評価に時間がかかります。 実装だけなら数日で動くものが、文書整備で数週間止まる、というのが典型的な進み方です。

理由は単純で、社内文書は「AIに読ませる前提」で書かれていないからです。旧版と新版が混在している、口頭でしか伝わっていないルールがある、部署ごとに用語が違う。これらは技術で解決できず、人が判断して整える以外にありません。スケジュールを引くときは、前半に厚く時間を取ってください。

工程1｜社内文書を棚卸しする

最初の工程は、社内文書の棚卸しです。地味ですが、ここの精度が最終的な回答精度を決めます。やることは「何を入れるか」ではなく「何を入れないかを決めること」だと考えてください。

棚卸しは3列の表で足りる

凝った管理台帳は不要です。次の3列（＋補足2列）の表を作れば十分に機能します。Excelでもスプレッドシートでも構いません。そのまま社内で使えるように、記入例つきで示します。

この表で重要なのは「正しさの責任者」の列です。責任者が決まらない文書は、更新も止まりますし、間違った回答が出たときに誰も直せません。責任者を書けない文書は、いったん対象から外すのが安全です。

最初に入れない文書を決める

棚卸しの実務では、次の4種類を最初に除外します。除外は「永久に入れない」という意味ではなく、1周目には入れないという意味です。

• 旧版・改訂前の文書：新旧が混在すると、AIは区別できずに古いほうを引用します。事故が最も起きやすい類型です
• 個人情報を含む文書：人事評価、健康診断結果、顧客の個人データなど。取り扱いは個人情報保護委員会の個人情報の保護に関する法律についてのガイドライン（通則編）に沿って判断します
• 機密性の高い文書：役員会資料、未公表のM&A情報、価格戦略など。社内の情報資産の分類は、IPAの中小企業の情報セキュリティ対策ガイドラインの考え方が参考になります
• 結論が書かれていない文書：検討中の議事録、メモ書き。読ませても答えが出ず、ノイズとして検索精度を下げます

権限は文書ごとに持たせる

「営業部だけが見られる文書」がある場合、権限は文書側に持たせます。よくある誤りは、回答文をAIに調整させる方法です。「この人には見せないでください」とプロンプトで指示しても、検索が拾ってしまった時点で情報はAIに渡っています。指示を工夫して出力を抑えるのではなく、そもそも検索対象から外すのが正しい設計です。

実装上は、文書に「閲覧できる部署」のタグを付け、検索時に利用者の所属で絞り込みます。前掲のAWSガイダンスでも、ID・ユーザー管理は本番運用のRAGに必須の構成要素として挙げられています。1周目は「全社員が見てよい文書だけ」に限定してしまうのが、最も安全で速い進め方です。

文書が少ないなら作らない

棚卸しの結果、入れられる文書がほとんどなかった場合、RAG構築はいったん中止すべきです。 探す対象がないのに検索の仕組みを作っても、返ってくるものがありません。この場合は先にマニュアル整備を行うほうが、結果的に近道になります。

もうひとつ、規模が小さすぎる場合も作らない判断があります。Anthropicの技術記事では、知識ベースが20万トークン（おおよそ500ページ分）より小さければ、RAGを使わずに全文をそのままプロンプトに入れてしまえばよいと明記されています（出典：Anthropic「Introducing Contextual Retrieval」）。マニュアルが数十ページの会社なら、RAGを構築せず、文書をまるごと読ませる運用で足りる可能性があります。この判断は工程1で行ってください。

工程2｜文書を分割する

入れる文書が決まったら、次は分割です。文書を丸ごと検索対象にするのではなく、数百文字から数千文字の「かたまり」に切り分けます。このかたまりをチャンクと呼びます。ここでの選択が、精度に直結します。

チャンクの大きさの決め方

分割が必要な理由は2つあります。ひとつはモデルの入力上限です。Microsoft Learnの解説によれば、埋め込みモデルのtext-embedding-3-smallは入力テキストの最大長が8,191トークンで、これはおおよそ6,000語程度に相当します（出典：Microsoft Learn「Azure AI 検索で RAG とベクター検索用の大きなドキュメントをチャンクする」）。埋め込みモデルの仕様そのものはOpenAI「Embeddings」の公式ドキュメントで確認できます。

もうひとつの理由が本質的です。長い文書を1つのかたまりにすると、複数の話題が混ざり、検索の狙いがぼやけます。 逆に細かく切りすぎると、前後の文脈が失われて意味が通らなくなります。

では、いくつにするか。同じMicrosoft Learnの解説では、具体的な出発点として512トークン（約2,000文字）のチャンクサイズと、128トークン（25%）の重なりから始めることが推奨されています。また固定サイズ分割の例として、200単語や600文字といった単位に10〜15%の重なりを付ける方法も挙げられています。Anthropicの記事では、チャンクは通常「数百トークン以下」とされています。

重なりを付ける理由

重なり（オーバーラップ）とは、隣り合うチャンクの末尾と先頭を少し重ねることです。前掲のMicrosoft Learnでは、固定サイズで切る場合に少量のテキストを重複させることで、連続性と文脈を保つ助けになると説明されています。

具体例で考えます。「有給休暇の申請は、取得日の5営業日前までに直属の上長へ申請してください。ただし、慶弔休暇についてはこの限りではありません」という文が、ちょうど「ただし」の直前で切れたとします。すると検索で前半だけが拾われ、AIは例外があることを知らないまま「5営業日前までです」と断言します。これがRAGで最も多い事故の形です。重なりは、この事故の確率を下げるための保険です。

ただし重なりを大きくしすぎると、同じ内容のチャンクが増え、検索結果が似たものだらけになります。前掲のとおり10〜25%程度が出発点で、そこから調整するのが現実的です。

見出しの単位で切る

中小企業の社内文書に限っていえば、文字数で機械的に切るより、見出しの単位で切るほうが精度が出ます。 Microsoft Learnでも、HTMLやMarkdownのように見出し構文を持つ文書は、セクションごとに分割できると説明されています。

実務的には、次の順に検討します。

1. 文書に見出し・条番号があるか確認する。あればその単位で切る
2. 見出しがない場合、段落の切れ目（空行）で切る
3. それも無理なら、約2,000文字＋25%重複の固定サイズで切る
4. 1つのチャンクが長くなりすぎた場合のみ、さらに分割する

WordやPDFの文書に見出しスタイルが設定されていないケースは非常に多いです。この場合、見出しを設定し直す作業そのものが工程1の文書整備に含まれます。 面倒に見えますが、ここに時間を使った会社ほど、後の精度改善が短く済みます。

文脈を足して精度を上げる

分割には、原理的に避けられない弱点があります。切り出したチャンク単体を読んでも、それが何についての記述か分からなくなることです。Anthropicの記事では、「当社の売上は前四半期比で3%増加した」というチャンクを例に、どの会社のいつの話か分からないため、正しく検索することも活用することも難しくなると説明されています。

対策として同社が示しているのが、各チャンクの先頭に「このチャンクが文書全体のどこに位置するか」の短い説明を足してから検索用のデータを作る方法です（Contextual Retrieval）。この説明文は通常50〜100トークン程度で、生成AIに作らせます。

同記事の実験では、この工夫だけで上位20件の検索失敗率が5.7%から3.7%へ、35%減少しました。キーワード検索（BM25）と組み合わせると5.7%から2.9%へ49%減少、さらに後述する並べ替え（リランキング）を加えると1.9%へ67%減少したと報告されています（出典：Anthropic「Introducing Contextual Retrieval」）。

この手法は日本語の社内文書でもそのまま使えます。Ai-Rakuで使っている日本語版のプロンプト例を載せます。

【文書全体】
{ここに文書全体を入れる}

【対象のかたまり】
{ここに切り出したチャンクを入れる}

上の「対象のかたまり」が、文書全体の中でどの位置づけの記述かを、
検索で見つけやすくすることを目的に、80文字以内で簡潔に説明してください。
文書名・章の名前・対象範囲・適用時期が分かるように書いてください。
説明文だけを出力し、それ以外は書かないでください。

出力例：「就業規則2026年4月版・第5章 休暇の項。全正社員に適用される有給休暇の申請手続きに関する記述」。この一文をチャンクの先頭に付けるだけで、「有給の申請はいつまで」といった質問に対する的中率が目に見えて変わります。

工程3｜検索の仕組みを選ぶ

分割ができたら、検索方式を決めます。選択肢は3つあり、中小企業の社内文書では「2つを併用する」が基本形です。

ベクトル検索の得意と苦手

ベクトル検索（意味検索）は、文章を数値の並びに変換し、意味が近いものを探す方式です。「有休」と「年次有給休暇」のように言い回しが違っても意味が同じなら拾えるのが最大の利点です。社内では部署ごとに用語が違うことが多いため、この特性は効きます。

一方で苦手があります。Anthropicの記事では、埋め込みモデルは意味的な関係を捉えるのが得意な反面、厳密な完全一致を取りこぼすことがあると指摘されています。例として「エラーコード TS-999」という質問が挙げられており、意味検索ではエラーコード全般の説明は見つかっても、TS-999そのものを外す可能性があるとされています。

社内文書に置き換えると、品番、型番、契約番号、条文番号、社内の略称がこれに当たります。製造業や卸売業のように型番で会話する会社では、ベクトル検索だけでは必ず取りこぼします。

キーワード検索を併用する

そこで併用するのがキーワード検索です。BM25という、文字列の一致で順位を付ける方式が広く使われています。前掲のAnthropicの記事では、埋め込みとBM25を組み合わせ、両方の結果を統合して重複を除く手順が示されており、「埋め込み＋BM25は、埋め込み単独より優れている」と結論づけられています。

この組み合わせはハイブリッド検索と呼ばれ、主要な検索基盤で標準的に提供されています。Elasticの公式ドキュメントでは、全文検索とセマンティック検索の結果をRRF（Reciprocal Rank Fusion）という方法で統合する手順が解説されています（出典：Elastic「Hybrid search with semantic_text」）。Microsoft Learnでも、従来型のRAGパターンとして「ハイブリッド検索とセマンティックランク付け」が実証済みのアプローチとして紹介されています。

判断の目安はシンプルです。社内の会話に型番・番号・略称が出てくるなら、最初からハイブリッドにしてください。 ベクトル検索だけで始めて後から足すより、手戻りが少なくて済みます。

並べ替えで上位20件に絞る

検索で候補を集めたあと、もう一段の絞り込みを入れると精度が上がります。これがリランキング（並べ替え）です。まず広めに候補を集め、専用のモデルで関連度を採点し直し、上位だけをAIに渡すという二段構えです。

Anthropicの記事では、最初の検索で上位150件を取得し、リランキングモデルで採点し直したうえで上位20件をAIに渡す構成が示されています。渡すチャンク数についても、5件・10件・20件を比較して20件が最も成績が良かったと報告されています。ただし同記事は「情報を増やすとモデルの注意が散る」ため限度があるとも述べており、多く渡せば良いわけではない点に注意が必要です。

中小企業の実務では、まず並べ替えなしで作り、精度が足りないときに追加するのが現実的です。並べ替えは実行のたびに処理が増えるため、応答時間と費用が上がります。

全文をそのまま渡す選択肢

最後に、あえて検索を作らない選択肢も挙げておきます。前述のとおり、Anthropicは知識ベースが20万トークン（約500ページ）より小さければ、全文をプロンプトに入れる方法で足りるとしています。Microsoft Learnでも、GPT-4が受け入れるトークンは約128,000で、1万ページの文書をすべて送ることはできないという前提でRAGの必要性が説明されています。裏を返せば、文書が数十ページ規模なら検索の仕組みは不要ということです。

実際、Ai-Rakuでも「まず全文を読ませる方式で試し、文書が増えて限界が来てからRAGに移行する」という進め方を勧める場面があります。最初から作り込むより、確実で速いためです。

工程4｜回答の精度を測る

ここが、多くの会社が飛ばしてしまう工程です。「なんとなく良さそう」で本番公開すると、必ず後で揉めます。 精度は測れます。そして測れば、どこを直すかも分かります。

評価用の質問50問を作る

最初にやるのは、評価用の質問リストを作ることです。手順は次のとおりです。この作業は業務側の担当者が主導してください。

1. 実際に来た質問を集める：総務・経理・技術への問い合わせメール、チャットの履歴から直近3か月分を抜き出す
2. 頻度順に並べる：同じ趣旨の質問をまとめ、多い順に並べる
3. 上位30問を採用する：ここが本番で最も聞かれる質問になる
4. 難しい質問を10問足す：例外規定、複数の文書にまたがる質問、似た商品の比較など
5. 答えられない質問を10問足す：社内文書に書かれていない内容。「分かりません」と正しく答えられるかを見る
6. 各問に正解を書く：正解の文章と、その根拠がどの文書のどこにあるかを記録する

合計50問。5番の「答えられない質問」を必ず入れてください。 RAGの事故で最も怖いのは、社内文書に書かれていないことを推測で答えてしまうケースです。この10問で、その性質を事前に把握できます。

見るべき指標は4つ

RAGの評価指標は数多くありますが、中小企業の現場で見るべきものは4つに絞れます。RAG評価の代表的なライブラリであるRagasでも、RAG向けの指標としてContext Precision、Context Recall、Faithfulness、Response Relevancyなどが定義されています（出典：Ragas「List of available metrics」）。これを日本語の実務向けに言い換えると次のようになります。

「文書に忠実か」と「知らないと言えるか」は、目標を甘くしないでください。 ここが崩れると、社内の信頼が一度で失われます。回答の信頼性を担保する考え方はRAGとはの記事でも触れています。

検索と生成を分けて測る

評価で最も大事なのは、検索と生成を分けて測ることです。まとめて「正答率60%」と出しても、どこを直せばいいか分かりません。

手順は簡単です。50問それぞれについて、まず検索結果だけを見て、正解の根拠が含まれているかを○×で記録します。次に、正解の根拠が含まれていた問だけを対象に、回答文が正しいかを○×で記録します。この2つの数字を分けて出すだけで、原因が切り分けられます。

数字が悪いときの直し方

切り分けができたら、次の順で手を入れます。上から順に試すのが、費用と手間の面で最も効率的です。

1. そもそも文書があるか確認する：正解が社内文書に書かれていなければ、何をしても直りません。文書を書き足す作業に戻ります
2. キーワード検索を併用する：型番・条文番号を外している場合は、これで一気に改善します
3. チャンクの切り方を変える：切れ目で答えが分断されていないか、実際のチャンクを目で見て確認します
4. チャンクに文脈を足す：前述のContextual Retrievalの手法を適用します
5. 並べ替えを追加する：候補は拾えているが順位が低い場合に効きます
6. 渡すチャンク数を調整する：少なすぎて根拠が入らない、多すぎて注意が散る、の両方があり得ます
7. プロンプトを直す：「渡された文書に書かれていないことは答えない」「根拠の文書名を必ず示す」を明記します
8. モデルを変える：最後です。1〜7を試さずにモデルを変えても、たいてい変わりません

RAGの構成要素と代表的な実装パターンはLangChain「Retrieval augmented generation (RAG)」の公式解説にもまとまっています。技術担当者がいる場合は、この順序を共有しておくと議論が早く進みます。

工程5｜運用に載せる

評価が合格ラインに届いたら、運用に載せます。RAGは「作って終わり」にならない仕組みです。社内文書が変われば、答えも変えなければならないからです。

AIに任せる線と人が決める線

運用に入る前に、必ず社内で合意しておくことがあります。どこまでをAIの回答で済ませ、どこからを人が判断するかの線引きです。ここをあいまいにしたまま公開すると、事故が起きたときに責任の所在が決まりません。

Ai-Rakuでは、次の3段階で整理することを勧めています。

線引きの基準はひとつです。「間違っていたときに、誰にどれだけの損害が出るか」で分けます。 社内で完結し、間違いにすぐ気づける業務はAIに任せてよい。社外に出る文書、金銭が動く判断、法令の解釈が絡む場面は人が決める。この基準なら、現場の誰でも同じ判断ができます。

また、Google Cloudの解説では、RAGは事実に関する情報を「検索」し、それをモデルに渡して答えさせる技術であり、これがグラウンディング（根拠づけ）の意味であると説明されています（出典：Google Cloud「RAG and grounding on Vertex AI」）。根拠づけができるのは、根拠が社内文書に書かれている範囲だけです。書かれていない判断はAIの領域外だと考えてください。

文書の更新を誰が担うか

運用で最初に壊れるのは、たいてい文書の更新です。規程が改訂されたのに、RAGの中身は古いまま。この状態でAIが答えると、「システムが古い規則を案内した」という形で問題が表面化します。

防ぎ方は、工程1で作った棚卸し表の「正しさの責任者」を運用に持ち込むことです。具体的には次の3つを決めます。

• 誰が更新するか：文書ごとの責任者。総務なら総務部長、というように部署単位で決める
• いつ更新するか：改訂したその日に差し替える。月次のまとめ更新はズレが生じる期間が長くなる
• 旧版をどうするか：必ず削除する。残すと新旧が混在し、最も多い事故の形に戻ります

社内マニュアルそのものの整備から進めたい場合は、社内マニュアルのAI活用のページに、文書化の進め方をまとめています。

答えられない質問を貯める

運用中に最も価値が高いデータは、AIが答えられなかった質問です。これは「社内文書に書かれていないこと」の一覧そのものだからです。

仕組みは簡単で構いません。回答画面に「解決しなかった」ボタンを1つ置き、押された質問を記録するだけです。月末にこの一覧を見れば、次に文書化すべき内容が優先順位つきで手に入ります。

Ai-Rakuの現場感覚では、公開して1か月で、想定していなかった質問が必ず出てきます。 事前に完璧な文書を用意しようとするより、運用しながら埋めていくほうが速く、無駄がありません。

月次で見る3つの数字

運用の定例で見る数字は、3つで足ります。多くすると誰も見なくなります。

3番目が最も重要です。RAGの目的は「AIを使うこと」ではなく「人に聞く回数を減らすこと」です。利用件数が増えても担当者の負担が減っていなければ、業務が二重になっているだけの可能性があります。

失敗パターン5つと直し方

Ai-RakuがRAG構築の相談を受ける中で、繰り返し出てくる失敗が5つあります。いずれも技術的に高度な問題ではなく、進め方の問題です。

棚卸しをせずに全部入れた

症状：社内の共有フォルダをまるごと取り込んだ結果、古い資料や検討中のメモが大量に混ざり、質問しても関係ない文書ばかり返ってくる。

原因：「多く入れれば賢くなる」という思い込みです。RAGでは逆で、対象文書が増えるほど、無関係な文書が上位に食い込む確率が上がります。

直し方：工程1に戻り、文書を絞ります。実務ではいったん20〜50文書まで削ってから作り直すのが最短です。精度が出ることを確認してから、少しずつ足していきます。

全社に一斉公開した

症状：完成と同時に全社員へ告知。最初の数日で誤答が数件出て、「使えない」という評価が固まり、その後誰も使わなくなる。

原因：期待値の管理をしないまま、精度が安定する前に公開したためです。社内システムの評価は最初の1週間でほぼ決まります。

直し方：部署を1つ、あるいは5〜10名に限定して2〜4週間試します。そこで出た誤答を潰し、評価用の質問リストに追加してから広げます。「1部署で成功してから広げる」は、AI導入全般に通じる原則です。詳しくは中小企業のAI導入のガイドにまとめています。

体感だけで精度を判断した

症状：「けっこう良い感じ」で公開したが、実際には特定の種類の質問だけ全滅していた。指摘されて初めて気づく。

原因：工程4を飛ばしたためです。人が思いつく質問は偏るので、数問試しただけでは弱点が見つかりません。

直し方：50問の評価リストを作り、検索と生成を分けて測ります。この作業は半日から1日で終わります。 公開後に信頼を失ってから作り直す時間と比べれば、圧倒的に安い投入です。

古い文書が残ったまま

症状：規程を改訂したのに、AIが旧版の内容を答える。しかも出典として旧版の文書名を堂々と示すため、利用者は正しいと信じてしまう。

原因：更新の担当と手順が決まっていないためです。「気づいた人が直す」は、誰も直さないのと同じです。

直し方：文書ごとに責任者を決め、改訂したその日に旧版を削除する運用にします。文書名にバージョンと日付を必ず入れておくと、混在にも気づきやすくなります。

出典を表示していない

症状：回答文だけが表示され、どの文書のどこに書かれているか分からない。利用者は正しいか確認できず、結局、担当者に聞き直す。

原因：チャット画面を作る段階で、出典表示を「後回し」にしたためです。

直し方：出典表示は必須機能として最初から入れます。文書名、章や条の番号、可能なら該当箇所へのリンクまで出します。Microsoft Learnでも、エージェント検索の利点として引用文献の追跡が組み込まれている点が挙げられています。出典があれば、利用者は自分で確認でき、誤答にもすぐ気づけます。出典表示のないRAGは、運用に載せてはいけません。

自社で作るか、買うか

ここまで読んで「自社でやるのは難しそうだ」と感じた方もいると思います。判断のための材料を整理します。

選択肢は大きく3つ

クラウドの部品を組む場合、代表的な選択肢としてAWSのAmazon Kendraや、Azure AI Searchなどがあります。いずれも公式ドキュメントに機能と制約が明記されているので、選定前に必ず一次情報で確認してください。

自社で作れる会社の条件

自社構築を勧められるのは、次の3つが揃っている場合です。

1. 社内文書がすでに整理されている：最新版が明確で、責任者が決まっている
2. 技術を担当できる人がいる：外部サービスのAPIを扱える人。専任である必要はない
3. 評価を続ける体制がある：作った後に50問を回し、改善し続けられる

3つのうち1つでも欠けるなら、まず外部の支援を受けて1周作り、やり方を社内に移すほうが速いです。 特に3番目が欠けた状態での自社構築は、「動いてはいるが誰も使っていない」に着地しがちです。

外注するときの契約形態

外部に依頼する場合、契約形態の選択が結果を左右します。RAG構築は作りながら精度を調整していく性質の仕事なので、仕様を先に固定しにくい特徴があります。

成果物を完成させる責任を負う請負契約は、仕様が固まっている場合には有効ですが、「精度が出るまで調整する」ような業務とは相性が良くありません。一方、業務の遂行そのものを対象とする準委任契約は、試しながら進める工程に向きます。両者の違いと使い分けは準委任と請負の違いで詳しく整理しています。

もうひとつ、契約時に必ず確認したいのが「社内文書がどこに保存され、学習に使われないか」です。総務省の令和7年版情報通信白書によれば、生成AI活用の課題・障壁として「社内情報の漏えい等のセキュリティリスク」が上位に挙げられています（1位は「効果的な活用方法がわからない」）（出典：総務省「令和7年版 情報通信白書」）。契約書に、保存先・保持期間・学習利用の有無・削除の手順を明記してもらってください。

費用とスケジュールの目安

費用の話をします。RAG構築の相場は、条件によって幅が大きく、単一の金額では表せません。 相場らしい数字を鵜呑みにするより、「何で決まるか」を理解して自社の条件に当てはめるほうが確実です。

費用は4つの要素で決まる

加えて、AIサービスの利用料は使った分だけかかる従量制が一般的です。質問1回あたりに渡す文書量が増えるほど費用も増えるため、「たくさん渡せば精度が上がる」わけではないという前掲の事実は、費用面でも意味を持ちます。

Ai-Rakuの費用の考え方

Ai-Rakuでは、初期費用0円・月額5万円〜で、RAG構築を含むAI導入の支援を行っています。最初にまとまった金額を投じてから成果を確認する形ではなく、毎月伴走しながら、動くところまで一緒に作る形にしているためです。

この形にしている理由は、本記事で繰り返し書いてきたとおり、RAGが「作って終わり」にならない仕組みだからです。文書は変わり、質問も変わります。構築費だけを支払って納品を受ける形だと、更新が止まった時点で価値がゼロになります。 別途、AIサービス側の利用料（従量課金）は実費でかかります。

12週間の進め方

従業員30名前後の会社で、社内問い合わせ対応にRAGを入れる場合の標準的な進め方です。実装より前後の工程に時間を割いている点に注目してください。

文書が整っている会社なら3〜5週目が短縮され、8週間程度に収まります。逆に紙の資料が多い会社では、ここが倍以上に伸びます。スケジュールを左右するのは技術ではなく文書の状態だと考えてください。

モデルケース｜30名の商社

ここからは、具体的な数字で見ていきます。以下は実在企業の実績ではなく、Ai-Rakuが試算したモデルケースです。 自社に当てはめて考えるための、たたき台としてご覧ください。

前提と対象にした業務

試算の前提は次のとおりです。

• 従業員30名の建材商社。営業12名、内勤・総務・経理8名、倉庫10名
• 取扱商品は約800品目。仕様・在庫ルールが商品ごとに異なる
• 社内文書は、就業規則、経費精算マニュアル、商品仕様書、過去の見積条件
• 金額換算は時給2,500円・月20営業日で計算（人件費・社会保険料込みの概算）
• 削減時間は、質問1件あたりの所要時間と月間件数から算出した試算値

この会社の課題は明確でした。総務と技術部の特定の担当者に、社内からの質問が集中していたのです。「有給の申請はいつまでか」「この商品の耐荷重は」「A社の前回の見積条件は」。どれも文書に書いてあるのに、探すより聞くほうが速いため、質問が来ます。

削減時間の試算表

※上記はAi-Rakuによる試算であり、実在企業の実績ではありません。時給2,500円・月20営業日で計算。効果は文書の整備状況、質問の内容、運用の定着度により変動します。

削減時間の合計は月42時間です。注目していただきたいのは、導入後も26時間が残っている点です。質問対応がゼロになることはありません。 文書に書かれていない判断、例外的な対応、顧客固有の事情。これらは人が答え続けます。ゼロを目指すと必ず失敗します。

つまずいた3つの点

このモデルケースでも、順調に進んだわけではないという想定で試算しています。実際の構築で起きやすい3つを書いておきます。

1つ目は、商品仕様書の型番が検索で拾えなかったことです。 ベクトル検索のみで作った初期版では、「HK-2100の耐荷重は」と聞いても類似の別商品が返ってきました。本記事の工程3で書いたとおり、キーワード検索を併用して解決します。この修正だけで、商品関連の質問の的中率が大きく改善します。

2つ目は、過去案件の見積条件を全社に公開してしまうところでした。 取引先ごとの価格条件は、営業以外に見せるべき情報ではありません。工程1の棚卸しの段階で気づき、営業部限定に設定し直します。公開してから気づいたのでは間に合いません。

3つ目は、倉庫スタッフの利用が伸びなかったことです。 現場はパソコンの前にいないため、そもそも使う機会がありません。スマートフォンから使える形にして初めて利用が始まりました。「誰が、どこで、どの端末で使うか」は、精度と同じくらい重要です。

よくある質問

Q. 文書は何本くらい必要ですか？

A. 本数より「よく聞かれる質問の答えが書いてあるか」で判断します。1周目は20〜50文書に絞るほうが精度が出ます。逆に、文書の総量が20万トークン（約500ページ）に満たない場合は、RAGを作らず全文をAIに読ませる方法で足りる可能性があります（Anthropicの技術記事による）。

Q. PDFやスキャン画像でも使えますか？

A. テキストが埋め込まれたPDFはそのまま使えます。スキャン画像は、まず文字認識（OCR）でテキスト化する工程が必要です。前掲のAWSガイダンスでも、PDF・スキャン画像・プレゼン資料などを扱うためのデータ処理が構成要素として挙げられています。手書きの多い文書は精度が落ちるため、1周目は対象から外すのが無難です。

Q. 構築期間はどのくらいですか？

A. 文書が整っていれば8週間程度、紙や旧版が多い場合は12週間以上を見てください。期間を決めるのは技術的な作業ではなく、文書整備にかかる時間です。本記事の「12週間の進め方」に標準的な工程表を載せています。

Q. 社内文書が学習に使われませんか？

A. 使用するサービスの利用規約と契約次第です。法人向けのプランでは入力内容を学習に使わないと明記されているものが一般的ですが、必ず契約書と規約で確認してください。総務省の令和7年版情報通信白書でも、生成AI活用の障壁として社内情報の漏えいリスクが上位に挙げられています。保存先・保持期間・削除手順まで書面で確認するのが確実です。

Q. 部署ごとに見せる範囲を分けられますか？

A. できます。文書側に「閲覧できる部署」の情報を持たせ、検索の段階で絞り込みます。回答の出し方をプロンプトで制御する方法は不十分です。検索で拾えた時点でAIには情報が渡っているためです。AWSのガイダンスでも、ID・ユーザー管理は本番運用のRAGに必須の構成要素とされています。

Q. ExcelやCSVも検索できますか？

A. 扱えますが、注意が必要です。表形式のデータは文章として切り出すと意味が失われやすく、「合計はいくらか」といった集計を伴う質問にも向きません。数値の集計はデータベースへの問い合わせで行い、RAGは文章の検索に使う、という切り分けが現実的です。

Q. 精度は何%まで上がりますか？

A. 文書の質と質問の性質で変わるため、事前に約束できる数字ではありません。参考値として、Anthropicの実験では上位20件の検索失敗率が5.7%で、文脈付与とキーワード検索の併用で2.9%、並べ替えを加えて1.9%まで下がったと報告されています。自社の数字は、50問の評価リストで測ってください。

Q. ChatGPTの機能で足りませんか？

A. 文書が少なく、権限を分ける必要がなければ、既製の機能で足りる場合があります。判断の分かれ目は、文書量、権限分け、更新の頻度、既存システムとの連携の4つです。この4つがどれも軽ければ、まず既製機能で試すほうが速く、費用もかかりません。

Q. 社内にエンジニアがいなくても作れますか？

A. 既製のサービスを使えば、技術者なしでも動かせます。ただし、精度が出ないときの切り分け（工程4）と権限設計は、技術的な理解がないと難しい部分です。1周目を外部と一緒に作り、やり方を社内に移す進め方が現実的です。

Q. 文書の更新はどのくらいの頻度ですか？

A. 定期更新ではなく「改訂したその日に差し替える」運用にしてください。月次でまとめて更新すると、最大1か月間、AIが古い内容を答え続けることになります。旧版は必ず削除します。

Q. RAGとファインチューニングの違いは？

A. RAGは、質問のたびに外部の文書を検索してAIに読ませる方法です。ファインチューニングは、モデル自体を追加学習させて振る舞いを変える方法です。RAGの由来となった2020年の論文では、事前学習済みのパラメトリック記憶と非パラメトリック記憶を組み合わせる言語生成モデルとして定義されています（出典：Lewis et al.「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」）。社内文書のように頻繁に変わる情報を扱うならRAGが適しています。

Q. 使われないまま終わるのが不安です

A. その不安は正しく、実際に最も多い結末です。防ぐ方法は3つあります。1つ目は、1部署に限定して試行し、精度が安定してから広げること。2つ目は、答えられなかった質問を貯めて文書を足し続けること。3つ目は、担当者への直接の問い合わせ件数を月次で見て、実際に減っているかを確認することです。

RAGは、社内に散らばった文書を「探せる資産」に変える仕組みです。ただし、それは文書が整い、検索が正しく働き、更新が続く場合に限ります。技術より先に、自社の文書がどんな状態かを見ることから始めてください。

「自社の文書でRAGを作れるか判断したい」「作ったが精度が出ないので原因を切り分けたい」という方は、無料相談をご利用ください。棚卸し表の作り方から、評価用の質問リストの作り方まで、その場でお渡しします。費用は初期費用0円・月額5万円〜で、動くところまで一緒に作ります。あわせてRAGとは、中小企業のAI導入、社内マニュアルのAI活用もご覧ください。