RAG（社内文書を検索してAIに答えさせる仕組み）は、小さく試すPoCの段階では比較的すぐに「それらしく動く」状態になる。だが、PoCで動いたことと、本番として日々の業務で使えることの間には、大きな隔たりがある。対象文書の更新、権限の整合、間違いへの対処、費用と運用体制といった論点を詰めないまま本番に進めると、現場で使われない仕組みや、見せてはいけない情報を返す仕組みになりかねない。

本記事は「RAG導入・連携の実務チェック」連載の最終回として、PoCから本番運用へ進めるための判断基準と、開発会社に渡すRFP（提案依頼書）に書くべき項目を整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。これまでの第1回から第11回で扱ってきた論点を、発注の言葉にまとめ直す回だと考えてほしい。RFPと開発会社選びにつなげる観点を一覧化する。

結論：合格条件を先に決め、範囲を絞り、運用までRFPに書く

RAGをPoCから本番に進める判断は、感触ではなく、あらかじめ決めた合格条件で行う。GXOがこの判断とRFP作成で重視するのは、次の3点である。

  • 本番化の合格条件（どの精度・どの範囲なら本番に進めるか）を、PoCを始める前に決めておく
  • 対象文書・利用部署を絞って始め、確かめてから広げる
  • 対象文書・権限・検索方式・評価・更新運用・セキュリティ・費用・体制をRFPに明記し、開発会社が同じ前提で見積もれるようにする

PoCの目的は「動くか」ではなく「本番に進める判断材料を得ること」である。合格条件と範囲を先に決めておくほど、本番化の判断も、開発会社への依頼も、ぶれずに進められる。

PoCから本番へ進める判断基準

PoCの後に「なんとなく良さそうだから本番へ」と進めると、後から運用やセキュリティの問題が噴き出す。本番化は、先に決めた合格条件に照らして判断したい。

合格条件を先に決める

PoCを始める前に、「どうなったら本番に進めるか」を言葉にしておく。たとえば、想定する質問のうち、許容できる範囲で正しく答えられること、出典が確認できること、見せてはいけない情報を返さないこと、といった条件である。具体的な数値の基準は業務によって異なるため、自社で「これなら現場が使える」と言える線を、関係者で合意しておく。合格条件がないと、PoCの結果を前にして判断が主観に流れ、本番化の是非が決まらない。

範囲を絞って始める

最初から全社・全文書を対象にすると、評価も運用も難しくなる。対象文書を一部の業務に絞り、利用部署も限定して始めるほうが、結果を確かめやすい。範囲を絞った本番運用で手応えを得てから、対象を広げる進め方が現実的である。PoCがそのまま試作で終わってしまう失敗は、関連連載のAI開発の発注でPoCが頓挫する理由でも扱っている。

運用とセキュリティを判断に含める

精度だけで本番化を判断すると、後から運用が破綻する。文書が更新されたときに反映できるか、権限が既存システムと整合しているか、間違いに気づける仕組みがあるか。これらが本番運用の前提として用意できるかも、判断基準に含めたい。

RFPに書くべき項目

開発会社に依頼するとき、RFP（提案依頼書）に必要な項目が抜けていると、各社の提案が前提の異なるものになり、比較できなくなる。RAGのRFPでは、これまでの連載で扱ってきた論点を、次のように項目として書き出しておきたい。

項目書くべき内容関連する論点
対象文書どの文書を対象にするか、形式（PDF・社内システム等）、量、更新頻度データの準備・前処理
権限誰がどの文書を見てよいか、既存システムの権限との整合アクセス制御
検索方式キーワード検索・意味検索のどちらか、出典の提示が必要か検索精度・根拠の提示
評価方法想定質問での精度確認、合格条件、誰が評価するか精度評価
更新運用文書更新の反映方法、反映の頻度、運用担当鮮度の維持
セキュリティ機密・個人情報の扱い、社外サービス利用の可否、ログ情報漏えい対策
費用初期費用と運用費用の内訳、利用量に応じた変動費用構造
体制開発・運用の役割分担、社内の窓口、保守の範囲運用体制

この一覧は、連載で扱った論点を発注の言葉に変えたものである。すべてを自社だけで詳細に書く必要はないが、各項目について「自社はどう考えているか」を一言でも添えておくと、開発会社の提案の質が変わる。

連載の論点を発注の言葉にまとめる

これまでの各回で扱ってきた論点は、単独で見ると技術的に思えるかもしれない。だが発注の場面では、すべて「何を依頼し、どう確かめるか」という言葉に置き換えられる。

  • 対象文書とデータ準備：散らばった文書をそのまま渡すのではなく、対象と形式を整理して伝える。
  • 権限とアクセス制御：見せてよい範囲を、既存システムの権限を起点に決めて伝える。
  • 検索方式と根拠の提示：答えだけでなく、どの文書を根拠にしたかを示せる作りを求める。
  • 精度の評価：想定質問のリストと合格条件を用意し、誰が評価するかを決める。
  • 更新運用と鮮度：文書が変わったときの反映方法と担当を、運用として依頼内容に含める。
  • セキュリティとログ：機密情報の扱いと、誰が何を参照したかの記録を要件にする。

これらを一つずつ言葉にすると、それがそのままRFPの中身になる。発注者が技術の細部まで理解している必要はない。「自社では何を、誰に見せて、どう確かめたいか」を整理できていれば、開発会社が技術的な実現方法を提案できる。

RFP作成と開発会社選びでよくある失敗

RFPを作り、開発会社を選ぶ段階では、次のような失敗が起きやすい。いずれも、事前に項目と判断基準を決めておけば避けられる。

  • PoCの感触だけで本番化を決める：合格条件がないまま「動いたから」と進め、運用で問題が表面化する。
  • 対象範囲を絞らずに依頼する：全社・全文書を一度に求め、評価も費用も見通せなくなる。
  • 運用とセキュリティをRFPに書かない：精度と費用だけで比較し、更新運用や情報の扱いが提案から抜ける。
  • 項目がそろわないまま相見積もりを取る：各社の前提が異なり、金額だけ見て選んでしまう。

RFPは、各社を同じ土俵で比較するための共通の前提である。項目をそろえておくことが、開発会社選びの質を左右する。開発会社の見極め方は、関連連載のAI開発会社の選び方チェックでも整理している。

よくある質問

Q1. PoCを飛ばして、いきなり本番開発を依頼してもよいですか

避けたほうがよい。RAGは対象文書の質や量で結果が大きく変わるため、自社のデータで一度試さないと、本番で使える精度に届くかが読めない。PoCは「動くか」を見るためだけでなく、本番に進めてよいかを判断するための材料を得る段階である。範囲を絞ったPoCを経てから本番に進むほうが、結果的に手戻りが少ない。

Q2. RFPはどこまで詳しく書けばよいですか

技術的な実現方法まで書く必要はない。対象文書、見せてよい範囲、確かめたいこと、運用と費用の前提を、自社の言葉で整理しておけば十分である。むしろ、自社で決めるべきこと（合格条件や対象範囲）を曖昧にしたまま開発会社に丸投げすると、提案がぶれる。判断は自社で、実現方法は開発会社で、と役割を分けて考えるとよい。RAGそのものの仕組みは社内ナレッジを活かすRAGの基本で整理している。

Q3. 複数の開発会社から相見積もりを取るときの注意点は何ですか

各社に同じRFPを渡し、同じ前提で提案してもらうことである。前提がそろっていないと、安く見える提案が運用やセキュリティを含んでいないだけ、ということが起こる。対象範囲・評価方法・更新運用・セキュリティ・体制まで項目をそろえ、金額だけでなく「何が含まれているか」で比較したい。

RAGのPoCから本番化、RFP作成までを一緒に進めませんか

GXOでは、本番化の合格条件づくり、RFP項目の整理、開発会社への依頼までを、これまでの設計論点を踏まえて一貫してご支援します。

RAGの本番化を相談する

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。