RAG導入スケジュールの立て方：いつ何をやれば使える状態になるかの目安

RAGとは何か：まず「使える状態」を定義する

RAG（Retrieval-Augmented Generation）は、社内文書やナレッジ（規程、FAQ、手順書、議事録、契約雛形など）を検索し、その検索結果を根拠として生成AIが回答する仕組みです。ChatGPTのように“それっぽい文章”を作るだけでなく、社内の正しい情報に基づいて回答できるため、業務で使いやすくなります。

ただし、導入を急ぐほど「いつから使えるのか」が曖昧になりがちです。そこで最初に決めたいのが“使える状態”の合格ラインです。例えば次のように具体化すると、スケジュールが立てやすくなります。

• 対象業務：情シスの問い合わせ（アカウント、PC申請、SaaS利用、セキュリティ）に限定する
• 対象情報：社内規程・申請手順書・よくある質問・過去回答メール（公開できる範囲）
• 利用形態：まずは社内のWeb画面で質問できる（Slack/Teams連携は後で）
• 品質基準：回答の正答率、根拠提示率、回答に要する時間、危険な回答の抑止
• 運用基準：文書更新が月1回でも回る、権限（部署別・役職別）を守れる

RAG導入は「モデルを賢くする」より、実務的には情報を整え、運用に乗せ、事故を防ぐことが成功要因です。この記事では、専門知識がない方でも進められるように、いつ何をやれば何が出来上がるかを、期間の目安と成果物（やることのゴール）で説明します。

スケジュールの全体像：PoC→パイロット→本番の3段階で考える

RAGの導入は、いきなり「全社で本番」ではなく、3段階に分けるのが安全です。理由は、データ（文書）の癖や社内ルール、権限設計、回答品質の許容範囲が企業ごとに違い、試して初めて分かることが多いからです。

例えば「情シスのFAQ領域だけ」なら、最短で1〜2か月で社内提供に到達できます。一方、「全社の文書（規程・法務・営業・人事まで）」「部署別アクセス制御」「監査対応」を含めると、3〜6か月で段階的に広げるのが現実的です。

大事なのは、期間を短く見積もることではなく、段階ごとに“合格”を判定するチェックポイントを置くことです。そうすれば、途中で期待値がずれたり、追加要件が膨らんでもコントロールできます。

導入前の準備：最初の1〜2週間で決めること（失敗の芽を摘む）

RAGは「文書を入れたら勝手に賢くなる」わけではありません。導入前の準備で、スケジュールの精度が決まります。ここは開発よりも、業務側の意思決定が重要です。

決めるべきスコープ（範囲）

• 対象業務：問い合わせ対応、社内規程検索、製品マニュアル、コールセンター支援など
• 対象ユーザー：情シスだけ、特定部門、全社員、外部（顧客）向け
• 対象ドキュメント：PDF、Word、Confluence、SharePoint、Google Drive、メールなど

最初は「問い合わせの多いテーマ上位20%」に絞るのが現実的です。例えば情シスなら、アカウント・端末・申請・ネットワーク・セキュリティ注意事項の領域が狙い目です。

品質の合格ライン（KPI）を先に置く

RAGでは「正答率」だけでなく、根拠提示（参照した文書の箇所が出るか）や危険回答の抑止が重要です。例えば次のように決めます。

• 根拠付き回答率：回答のうち何割が根拠（出典）を示すか
• 不確実時の挙動：「分からない」と言えて人にエスカレーションできるか
• 禁止領域：個人情報、機密情報、法務判断などは回答しないルール

“答えられないときに無理に答えない”設計は、RAGを業務に入れる上で必須です。

体制（誰が決め、誰が直し、誰が運用するか）

• 業務オーナー：回答方針・対象業務の責任者（例：情シス部門長）
• ナレッジ管理者：文書の正本・更新の担当（例：規程担当、FAQ担当）
• IT/情シス：認証、権限、ログ、セキュリティ審査
• 開発/ベンダー：RAG実装、検索精度改善、運用設計

ここが曖昧だと、後半で「誰が文書を直すのか」「誤回答の責任はどこか」が揉め、スケジュールが止まります。最初の1〜2週間で合意できれば、後工程が一気に進みます。

PoC（2〜4週間）：最短で「動くもの」を作り、論点を洗い出す

PoCの目的は、完璧なRAGを作ることではありません。自社の文書で“ちゃんと答えられそうか”と“どこが難所か”を早期に見える化することです。ここでの成果物は「デモ」ではなく、「本番に向けた判断材料」です。

PoCでやること（成果物ベース）

• 代表的な文書50〜300件程度を収集（まずは限定範囲）
• 文書の前処理：重複、古い版、スキャンPDFの文字起こし可否を確認
• インデックス作成（検索用データベース化）と基本的な検索設定
• 質問セット作成：よくある質問30〜100問（正解となる根拠文書も紐づけ）
• 最小UI：Webフォームで質問→回答＋根拠表示、ログ保存

この段階で多くの企業が驚くのが、「AIより文書側がボトルネック」だという点です。例えば、手順書が部署ごとに表現が違う、更新日がない、例外条件が口頭運用になっている、といった問題が検索精度に直結します。

PoCの評価観点（ここで測ると後がラク）

• 検索ヒットの妥当性：質問に対して適切な文書が上位に出るか
• 根拠の明確さ：該当箇所が示され、ユーザーが判断できるか
• 誤回答パターン：似た手順や例外条件で混同しないか
• セキュリティ：アクセス権のない文書が参照されない設計にできるか

PoCの終わりには、次の判断をします。「この業務領域ならパイロットに進む」「文書整備が必要で先にそこをやる」「権限設計が難しいので対象を絞る」。PoCは短期間でも、“やめる判断”も含めて価値があります。

パイロット（4〜8週間）：現場で使ってもらい、品質と運用を完成させる

パイロットの目的は、「動く」から「使える」へ引き上げることです。実ユーザーが使うと、PoCでは見えなかった課題が一気に出ます。ここでの主役は、開発チームだけでなく業務側（利用部門）です。

パイロットで整えるべきポイント

• 回答ポリシー：断定してよい条件、注意書きのテンプレ、参照先リンクの出し方
• ガードレール：禁止質問の扱い、個人情報が含まれた場合の遮断、エスカレーション導線
• ナレッジの版管理：正本はどれか、更新頻度、改定時の反映手順
• ログと改善：検索クエリ、未解決率、ユーザー評価（役に立った/立たない）

特に重要なのは、回答精度を“モデルの気合い”で上げないことです。RAGの改善は、たとえば次のような地道な調整が効きます。

• 文書の分割（チャンク）方法を、見出し単位・手順単位に合わせる
• 同義語（例：「アカウント」＝「ID」）を吸収する辞書やクエリ補正
• 検索の設定（キーワード検索＋意味検索の併用、上位何件を根拠にするか）
• “この手順は例外がある”など注意事項を文書側に明記する

さらに、情シスや管理部門でありがちな課題が「ルールはあるが、例外が多い」ことです。RAGは例外の扱いが苦手になりやすいので、パイロットでは例外パターンをFAQとして明文化し、根拠に入れると一気に安定します。

パイロットのゴール（“本番OK”の状態）

• 対象ユーザー（例：情シス窓口担当＋一部社員）が日常的に使っている
• 危険回答が出ない（出ても検知・修正できる）
• 文書更新〜反映までの手順が回る（担当・頻度・承認が明確）
• 費用見積もりが固まる（運用工数、クラウド利用料、保守範囲）

ここまで来ると、全社展開や対象領域の拡大（人事、総務、法務、営業）へ進める判断がしやすくなります。

本番展開（4〜12週間）：情シスが安心できるセキュリティと運用設計

本番展開では、「使える」だけでなく「安心して使い続けられる」を満たします。特に大企業の情シスや監査では、認証・権限・ログ・データ持ち出し・委託先管理が重要になります。

本番で必須になりやすい要件

• 認証・権限：SSO（SAML/OIDC）連携、部署・役職・プロジェクト単位のアクセス制御
• データ境界：社外秘文書の取り扱い、学習に使わない設定、保存期間
• 監査ログ：誰が何を質問し、何の文書を参照し、どう回答したか
• 可用性：障害時の代替手段、SLA、バックアップ、メンテ時間
• 運用：問い合わせ窓口、障害連絡フロー、改善要望の受付と反映サイクル

RAGは「検索＋生成」なので、どの文書を参照したかが重要です。本番では根拠（出典）の表示と、参照元へのリンクを標準にすると、現場の信頼が上がり、監査的にも説明しやすくなります。

よくある失敗と回避策

• 失敗：全社文書を一気に入れて混乱 → 回避：部門ごとに段階的に、アクセス権込みで拡大
• 失敗：古い版の規程を参照して誤案内 → 回避：正本の置き場を統一し、版管理を必須化
• 失敗：現場が使わない → 回避：最初は“問い合わせ削減”など明確な業務効果が出る領域から
• 失敗：改善が進まない → 回避：ログから未解決質問を週次で棚卸しし、FAQ化して反映

本番後も、RAGは「育てるシステム」です。運用開始後1〜2か月は改善速度が最重要になります。最初から完璧を目指すより、改善サイクルを回せる設計にするのが、結果的に最短ルートです。

導入スケジュール例：最短・標準・しっかりの3パターン

「うちはどれくらいで使える？」に答えるため、現実的な導入パターンを3つ提示します。前提は“対象領域を絞って開始し、段階的に拡張する”です。

最短パターン（4〜6週間）：限定領域でまず社内提供

• 1週目：対象業務と文書置き場を決定、質問セット作成
• 2〜3週目：文書取り込み、RAGの基礎実装、UI最小構成
• 4週目：評価・改善、利用部門に限定公開
• 5〜6週目：ログ改善、ガードレール強化、運用手順を簡易に整備

向いているケース：情シスFAQ、社内手順書、問い合わせ削減など、リスクが比較的小さい領域。

標準パターン（2〜3か月）：パイロットで品質・運用を固める

• 1〜2週目：スコープ・KPI・体制合意、文書棚卸し
• 3〜6週目：PoC→改善、質問セット拡充、根拠表示の整備
• 7〜10週目：パイロット運用、権限・ログ・更新フローを実装
• 11〜12週目：本番相当の運用設計、教育・周知、段階展開

向いているケース：部門内で日常利用する、監査やセキュリティ審査が必要、継続運用を重視。

しっかりパターン（3〜6か月）：全社展開や高い統制が必要

• 要件定義：権限、監査、データ分類、委託先管理を含めて設計
• データ整備：正本統一、版管理、メタデータ付与、文書品質改善
• 段階展開：部門ごとに拡大し、ログ改善を継続

向いているケース：全社横断の規程・人事・法務、外部向け回答、厳格な権限管理が必須。

どのパターンでも共通して、スケジュールを狂わせるのは「要件追加」ではなく「文書の現実」です。だからこそ、最初に文書の棚卸しと、正本・更新者の決定を置くと、導入が一気に前に進みます。

まとめ

RAGは、社内文書を根拠に生成AIが回答できるようにする仕組みで、問い合わせ削減や検索効率化に直結します。一方で、成功の鍵はモデル選びよりも、対象業務の絞り込み、文書整備、運用設計、セキュリティ統制にあります。

• 最初に「使える状態（合格ライン）」を定義すると、スケジュールが立つ
• PoC→パイロット→本番の3段階で進めると、リスクと手戻りを抑えられる
• 最短4〜6週間で限定提供、標準2〜3か月で運用まで整備、全社は3〜6か月が目安
• “答えられないときに無理に答えない”ガードレールが業務利用では必須

もし「自社の場合、どのパターンが現実的か」「文書の棚卸しから手伝ってほしい」「情シス審査を通る形で進めたい」といった状況であれば、要件整理の段階から伴走するとスムーズです。