rag【2026年版】社内検索RAGの設計・90日導入ロードマップ

はじめに

RAGの導入は、対象業務と検索させる社内文書を絞り、小さく検証してから広げる進め方が現実的です。回答の精度は、生成AIの選択よりも、文書の整理・分割・権限の設計に左右されやすくなります。評価用の質問と、期待する根拠文書を先に決めておくと、改善の効果を判断できます。既製のサービスで足りるか、自社の権限やシステムに合わせた開発が必要かも早めに比較しましょう。

社内に資料はあるのに、必要な情報が見つからない。これは営業、CS、バックオフィス、開発、製造、物流、コールセンターまで共通する課題です。FAQ、議事録、仕様書、PDF、マニュアル、問い合わせ履歴が散らばっていると、担当者は検索に時間を使い、同じ質問が何度も発生します。

RAGは、生成AIが社内文書を検索し、根拠となる情報を取り出してから回答する仕組みです。一般的なチャットAIのように学習済みの知識だけで答えるのではなく、マニュアルや議事録など自社の一次情報を参照して回答を作ります。そのため、精度、説明責任、再現性の3点で扱いやすく、社内検索、問い合わせ一次回答、規程確認と相性があります。

本記事でいう「AI開発」は、ゼロからモデルを作る話ではありません。ChatGPT、Gemini、Claudeなど既存の生成AIを活用し、検索と画面をつないで素早く形にすることを指します。RAGはこの進め方と相性がよく、90日で小規模本番まで進めやすい点が強みです。

ただし、RAGを入れれば自動的に正しい回答が出るわけではありません。文書の分割方法、評価設計、権限、更新運用を決めないまま進めると、「思ったほど当たらない」「運用が回らない」という失敗が起きます。

この記事では、ragを社内検索へ導入するための設計、ファインチューニングとの違い、90日ロードマップ、KPIと費用の目安、よくある失敗までを2026年版として整理します。予算の組み方や外注するかどうかを先に判断したい場合は、AI開発の費用相場でPoC・本開発・運用の内訳と見積もりの見方を確認できます。

RAGで解決できる社内検索の課題

ragで解決しやすいのは、社内資料が多く、検索キーワードだけでは答えにたどり着きにくい業務です。たとえば「この機能の制約はどこに書いてあるか」「顧客対応の標準回答は何か」といった質問に対し、関連文書と該当箇所を示しながら回答できます。

課題	RAGでの改善
資料が散らばる	複数ストレージを横断検索
検索語が分からない	自然文の質問で探せる
回答の根拠が弱い	文書名や該当箇所を表示
属人化する	よくある質問への回答を標準化

RAGの価値は、回答よりも根拠にあります。根拠リンクや抜粋が見えると、利用者は回答を確かめやすく、管理者も誤回答の原因を追跡できます。

最初のユースケースは、問い合わせ件数が多く、正解文書が存在し、回答の型がある業務から選びます。就業規則、製品仕様、社内手続き、CS回答集のように、担当者が毎週探している資料が候補です。判断責任が重い業務は、初回検証から外す方が安全です。

RAGとファインチューニングの違い

RAGは「取り出してから生成する」方式です。質問に近い社内文書をベクトル検索で取得し、その断片（チャンク）をプロンプトに同梱して回答を作ります。よく比較されるファインチューニングは、モデル自体の重みを追加学習で更新する方式で、最新情報の反映や根拠提示には向きません。

比較軸	RAG	ファインチューニング
情報の更新	文書を差し替えれば翌日から反映	更新のたびに再学習が必要
根拠の提示	参照した文書名・箇所を示せる	回答の根拠を示せない
初期準備	既存文書の整理と分割	学習用データの作成
向く用途	社内検索、FAQ、規程確認	文体・形式の統一、特定タスクの型

導入判断では、更新頻度が高いか、根拠提示が必須かを軸にRAGを選ぶのが実務的です。社内検索はこの2つを両方満たすことが多く、RAGが第一候補になります。

導入前に整える社内データ

RAG導入前には、検索対象の文書を棚卸しします。対象はマニュアル、FAQ、議事録、仕様書、社内規程、営業資料、問い合わせ履歴などです。ファイル名、所有者、更新日、閲覧権限、機密度、利用頻度を整理すると、最初に取り込むべき資料が見えます。

PDFや画像化された資料は、OCRやレイアウト保持が必要になる場合があります。表や見出しが崩れると検索精度が落ちるため、古い資料や重複資料が多い場合はRAGの前にナレッジ整理を行ってください。社内検索RAGは、AIより先にデータ品質が成果を左右します。

90日導入ロードマップ

90日で進める場合は、全社展開ではなく、問い合わせが多い部門や資料が整理されている領域から始めます。最初の目的は、万能なAIを作ることではなく、実務で使えるユースケースを一つ証明することです。社内のDriveやSharePoint、FAQ、PDFなど既存資産の再活用を中心に組み立てます。

フェーズ	期間目安	主要タスク	成果物/KPI
企画・設計	1〜2週	対象業務の特定、ユースケース選定、KPI定義（Top1/3ヒット率・根拠提示率・回答時間）	要件書、評価指標シート
データ整備	2〜3週	文書収集・正規化（PDF/OCR/図面）、分割方針、埋め込み作成、権限メタ情報の付与	ベクトルDB初期化、権限タグ設計
構築（PoC）	2〜3週	検索→再ランキング→回答テンプレート、根拠リンク・抜粋表示、会話ログ・監査ログ	PoC版画面、評価レポートv1
検証・改善	1〜2週	評価セットでの比較、誤回答分析（どの文書が不足か）、調整	評価レポートv2
小規模本番	1〜2週	権限連携（RBAC）、夜間の差分更新ジョブ、運用手順、問い合わせ導線	本番公開、週次モニタリング

導入時は、回答画面だけを急いで作らないことが大切です。検索対象の更新、権限同期、会話ログの保管、回答評価まで含めて設計すると、PoCで終わらず本番運用へ進めます。

技術の肝：文書の分割と再ランキング

精度を左右するのは、モデルの選択よりも文書の扱い方です。PoCの段階から次の5点を設計に入れておくと、本番へそのまま広げられます。

分割（チャンク）：見出しや表を壊さない意味単位で区切ります。長すぎるとノイズが増え、短すぎると文脈が失われます
再ランキング：初段の検索結果を、別の基準で並べ直して上位の精度を上げます
根拠提示：文書名、ページ、該当抜粋を画面に明示し、引用をそのまま使えるようにします
権限：SSOとRBACで、ユーザーが閲覧できる文書だけを検索対象にします
更新：夜間に差分だけ埋め込みを作り直し、今日の資料が明日には検索に出る状態を保ちます

精度を底上げする3つの工夫

当たり率を上げる工夫を3つ入れておくと、現場の体感が大きく変わります。

1つ目はハイブリッド検索です。意味の近さで探すベクトル検索に加えて、製品コードや固有名詞に強いキーワード検索（BM25）を併用し、両方で上位に出た文書を優先します。

2つ目は根拠の見やすさです。見出し、文書名、該当箇所の前後を抜き出して短く見せ、同じ文書の近い箇所は1つにまとめます。

3つ目は自信がないときの振る舞いです。検索スコアが低いときは無理に答えず、候補の根拠だけを並べて「関連ドキュメントを表示しました」と案内します。画面に自信度（高・中・低）とワンクリック評価を置けば、毎週の改善材料が自然に集まります。

評価指標と改善サイクル

RAGの評価では、回答が自然かどうかだけでなく、根拠が正しいかを見ます。頻出の質問を50問ほど集めた評価セットを作り、期待する根拠文書、回答に含めるべき内容、答えてはいけない条件を決めておきます。評価セットを持たないRAGは、改善したのか悪化したのか判断できません。

現場で合意を取りやすいのは次の4指標です。数値は業界標準ではなく、当社が小規模本番の初期合意に使う目標例です。初月は控えめに置き、3か月で実用域を目指します。

指標	見るもの	目標例（初月→3か月）
Top1ヒット率	最上位の根拠が妥当か	55%→70%
根拠提示率	回答に引用が付く割合	80%→95%
平均回答時間	質問から画面表示まで	2.5秒以内
誤回答率	レビュー担当が誤りと判定した割合	10%→5%以下

既存システムやDBとの連携も必要になる場合は、生成AI 既存システム連携とは？API・RAG・DB参照の方式比較と導入手順も参考になります。

改善サイクルは週次で十分です。低評価の質問を確認し、文書不足、検索漏れ、権限設定、回答テンプレートのどれが原因かを分類します。原因別に直すと、場当たり的なプロンプト修正に頼らず、検索品質を安定させやすくなります。

PoC後に本番へ進むかを判断する基準

PoCが終わったら、本番化する、改善を続ける、対象業務を見直す、のいずれかを決めます。判断の材料にするのは、PoCの前に合意した評価指標の結果と、実際に使った利用部門の評価です。担当者の印象だけで決めると、本番化してから「現場では使われない」という事態になりかねません。

次に、人が最終確認する運用で業務に組み込めるかを確かめます。RAGの回答をそのまま使うのではなく、担当者が根拠文書を見て確かめてから使う流れを想定し、その手間を含めても業務が回るかを利用部門と一緒に確認します。

本番化を決めた場合も、公開の前に担当を決めておきます。社内の権限とどう連携させるか、文書の追加や差し替えを誰が行うか、回答に疑問があったときの問い合わせ窓口を誰が受けるかの3つです。ここが決まらないまま広げると、検索対象が古くなり、利用者の信頼を失いやすくなります。

判断	選ぶ場面	次に行うこと
本番化	合意した指標を満たし、利用部門も業務で使えると評価した	権限連携・更新運用・問い合わせ窓口の担当を決めて小規模本番へ
改善継続	指標や評価に届かないが、原因が文書不足や分割など直せる範囲にある	原因を分類し、評価セットで再検証する
対象業務の見直し	正解文書が無い、または人の確認を入れると業務が回らない	ユースケースを選び直す

費用の目安と料金の確認先

費用は、データ整備と権限連携の濃さで大きく変わります。下表は当社が100名規模の社内検索を小規模本番まで進める場合の見積もり目安で、個別ベンダーの料金ではありません。

項目	目安（税抜）	主な内訳・変動要因
初期費用（設計〜PoC〜小規模本番）	200万〜500万円	データ整備、権限連携、評価設計の濃さ
月額ランニング（月払い換算）	10万〜60万円	埋め込み更新、ベクトルDB、生成AI API、監視・保守

月額のうちAPIやベクトルDBは従量課金が多く、利用量で上下します。2026年10月20日に公式サイトで確認した主な単価は次のとおりです。

サービス	単価（公式）	前提
OpenAI text-embedding-3-small	$0.02 / 100万トークン	税抜・従量
OpenAI text-embedding-3-large	$0.13 / 100万トークン	税抜・従量
OpenAI File Search	$2.50 / 1,000回、保存 $0.10 / GB・日	税抜・従量、保存は1GBまで無料
Pinecone Standard	最低利用額 $50 / 月	税抜・月払い、超過分は従量
Pinecone Starter	$0	無料枠（保存2GBまで）

埋め込みの単価は小さく、月額の多くは生成AIの回答生成と監視・保守が占めます。Azure AI Searchのように地域と通貨で単価が変わるサービスは、公式の料金ページで条件を選んで確認してください。

既製のRAGサービスと個別開発の選び方

RAGを導入する方法は、既製のRAGサービスを使うか、自社の要件に合わせて個別に開発するかに大きく分かれます。どちらが向くかは、会社の規模よりも、検索させる文書と権限の条件で決まります。

既製のRAGサービスは、文書を登録すれば検索と回答の画面がそろうため、早く始めやすいのが利点です。一方で、社内の権限との連携や画面の作り込みはサービスが用意する範囲に限られ、制約が出やすくなります。

個別開発は、既存の権限や基幹システムとの連携、監査の要件に合わせて作り込みやすい方法です。そのぶん、検索の仕組みや権限同期の設計、公開後の運用まで自社側で担う負担が増えます。

判断の材料は、検索対象の文書量、権限の複雑さ、連携したいシステム、社内で運用を担当できる人がいるかの4つです。文書が少なく権限が単純なら既製サービスから試し、部署や案件ごとに閲覧範囲が細かく分かれる場合や、基幹システムとつなぐ場合は個別開発を含めて比較します。

方式	向く状況	権限連携の柔軟さ	運用の負担	事前に確認すること
既製のRAGサービス	対象文書が限られ、早く試したい	サービスが用意する範囲に限られる	比較的軽い	権限の設定単位、データの保存先、画面を変えられる範囲
ノーコードの画面と既製の検索基盤の組み合わせ	画面や業務の流れは自社に合わせ、検索は既製の仕組みを使いたい	画面側で調整しやすい	中程度	検索基盤と画面のつなぎ方、権限情報の受け渡し
検索基盤まで個別開発	権限が複雑、基幹システム連携や監査要件がある	要件に合わせて設計できる	重い	運用担当の体制、更新と監視の手順、改修の進め方

画面と管理機能をノーコードで作り、検索基盤や権限同期を開発で補う進め方は、後半の「ノーコード/ローコードで始める判断」で詳しく扱います。

権限・セキュリティ・監査ログ

社内検索で最も危険なのは、見えてはいけない資料が検索結果や回答に混ざることです。役職、部署、案件、顧客、契約範囲ごとに閲覧権限を分け、検索前の段階で対象文書を絞る必要があります。回答後に隠すだけでは不十分です。

監査ログも必要です。誰が、いつ、何を質問し、どの文書が参照され、どの回答が返ったかを記録できると、トラブル時の確認や改善に使えます。個人情報を扱う場合は、マスキング、保存期間、削除ルールも決めてください。

よくある5つの失敗と回避策

失敗の多くは、データ前処理と運用設計の後回しから起きます。着手前に次の5つを確認してください。

失敗	起きること	回避策
PDFが画像のまま	本文が検索に出ない	OCRとレイアウト保持抽出。表や脚注もメタ情報として保存
分割が雑	文脈が切れて誤回答が増える	章・見出し・表の単位で区切り、見出しをチャンクに継承
KPIが曖昧	改善したか判断できない	頻出50問の評価セットを用意し、毎週自動採点
権限が後回し	閲覧できない資料が回答に混ざる	最初からSSO・RBAC前提で設計し、検索ヒット自体を抑止
更新が手作業	古い資料で回答し続ける	夜間の差分更新と失敗検知、前バージョンの保持

ノーコード/ローコードで始める判断

RAGの導入は、最初から大規模開発にする必要はありません。ノーコード/ローコードを使えば、社内検索画面、質問履歴、評価ボタン、管理画面、文書登録フローを小さく作り、現場検証を進めやすくなります。FAQ中心ならDifyでFAQ対応を効率化する設計と構築手順やノーコードで作る社内FAQチャットボットの進め方も参考になります。

一方で、ノーコードだけでは複雑な権限連携、大量文書の処理、厳格な監査、基幹システム連携に限界があります。こうした要件がある場合は、画面と管理機能をノーコードで作り、検索基盤や権限同期は開発で補う構成が現実的です。AI開発ラボでは、この切り分けを設計段階から行い、RAG PoC、社内検索画面、権限連携、評価運用の仕組みまで伴走します。

よくある質問

Q. RAGを導入すれば、生成AIの誤回答はなくなりますか？

A. なくなりません。誤回答は起こりうる前提で、回答に根拠の文書を表示する、人が最終確認してから使う、検索スコアが低いときは回答を控えて関連文書だけを示す、といった振る舞いを組み合わせて抑えます。

Q. 社内文書を外部の生成AIサービスに渡しても問題ありませんか？

A. 利用するサービスの規約と、入力したデータの扱いや保存の設定を事前に確認してください。そのうえで、文書の機密度に応じて検索対象に含めるものと含めないものを分けます。機密度の高い文書を扱う場合は、外部と切り離した閉域の環境で運用する構成も選択肢になります。どの構成が適切かは、扱う情報と社内の規程によって変わります。

Q. 普段使っている社内のチャットツールから使えるようにできますか？

A. 連携の方法は利用中のツールによって異なります。RAG専用の画面を作るか、既存のチャットツールにつなぐかは、利用者の使い方や権限の扱いなどの要件を整理したうえで決めます。

まとめ

RAGは、社内資料を検索し、根拠を示しながら回答するための実務的な仕組みです。資料はあるのに探す時間が長い業務で効果を出しやすく、更新頻度が高く根拠提示が必須な社内検索では、ファインチューニングよりRAGが向いています。

導入の勘所は次の3つです。

最小のユースケースを一つ選ぶ（社内検索、CS一次回答など）
KPIを数値で合意する（Top1ヒット率、根拠提示率、回答時間、誤回答率）
90日で小規模本番まで回す（分割、埋め込み、権限、差分更新までをひと回し）

精度は、意味単位の分割、再ランキング、ハイブリッド検索、自信がないときの振る舞いで底上げできます。権限と監査ログは後回しにせず、閲覧できない資料は検索対象から外し、質問、参照文書、回答、評価を記録してください。

費用は当社の目安で初期200万〜500万円、月額10万〜60万円です。APIやベクトルDBの単価は変わるため、公式の料金ページで最新の条件を確かめてから見積もってください。月額の大半は回答生成と保守が占めるため、利用人数と質問数の見込みを先に置くと、見積もりのぶれを小さくできます。

RAGは、生成AIを賢い回答装置に変える取り組みではなく、既存ドキュメントを即答できる知識に変える運用づくりです。導入後は、使われた質問、評価、参照文書、未回答の内容を見ながら改善し、検索時間が減ったか、ナレッジ更新の担当が決まったかまで確認してください。

AI開発ラボでは、既存ドキュメントを活かしたクイックPoCから、社内検索画面、評価運用、権限設計、管理画面の構築までを相談できます。同じ課題なら、検索したい資料と最初のユースケースの要件整理から相談できます。精度や効果は資料の状態と権限の複雑さで変わるため、まずは検索したい資料、よくある質問、閲覧権限、更新頻度を整理するところから始めてください。

社内検索を改善するには、過去の事例や知見を条件で絞り込み、すぐに参照できる状態をつくることが出発点になります。当社では、自動車整備士同士が故障事例を投稿し、車種・年式・走行距離・症状などの条件で絞り込んで検索・共有できるクローズドSNSを開発しました。蓄積したナレッジを探しやすくする仕組みづくりの段階からご相談いただけます。

関連する事例：自動車整備士向け故障事例共有SNS「メカトーク」の事例を見る

会社概要を見る・開発実績を見る

受託開発の相談・具体的な相談を送る