「社内文書をAIに読ませたい。何社かに見積もりも取った。でも、各社で金額も提案もバラバラで、何を基準に選べばいいのか分からない」——RAG（Retrieval-Augmented Generation＝検索拡張生成。社内文書を検索してAIに答えさせる仕組み）の発注を前に、こんな戸惑いを抱えている技術決裁者や情シスの方は少なくありません。
正直にお伝えすると、RAGの結果を左右するのは、技術選定そのものよりも**「発注側が事前に何を決めて渡すか」**です。ここが曖昧なまま発注すると、見積もりが各社で割れ、完成後に「思っていたのと違う」が起きやすくなります。
本記事では仕組みそのものの技術解説には深入りせず、契約やキックオフの前に発注側で握っておきたい5つの論点に絞ってお話しします。読み終えるころには、相見積もりを正しく比較でき、初回打ち合わせに自分の言葉で要件を持っていける状態になっているはずです。
なぜ「発注前の5論点」で差がつくのか
RAGは要件が曖昧なまま発注すると、ほぼ確実に見積もりが割れます。理由はシンプルで、各社が「曖昧な部分」を別々に解釈して値付けするからです。
曖昧さが生むトラブルは、だいたい次の3つに集約されます。
- 対象文書が膨らむ：「とりあえず全社の文書を」と渡すと、量も形式もバラバラで工数が読めない
- 精度の合格ラインを誰も決めていない：完成後に「これで合格なのか不合格なのか」を判断できない
- 更新が止まって陳腐化：作って終わりにした結果、半年後には古い回答を返すようになる
これから挙げる5論点は、それぞれが見積もりのどこに効くかがはっきりしています。
- 対象データの範囲 … 工数の土台。膨らむほど高くなる
- 精度の合格ライン … 検収（受け入れ判定）の基準になる
- 更新運用 … ランニングコストと保守契約の有無を決める
- セキュリティ … 構成（クラウド/オンプレ）と権限設計の難度を決める
- 費用感 … 上の4つの掛け算で決まる
「丸投げで作ってもらう」より、「発注側が決めて渡す」ほうが、結果的にコストも品質も安定します。難しく考える必要はありません。順番に見ていきましょう。
論点1：対象データの範囲を決める（どこまで読ませるか）
最初の鉄則は、いきなり全社の文書を入れないことです。「一番よく聞かれる質問」に答えられる文書群へ範囲を絞ると、コストも精度も安定します。
これは精神論ではなく、費用の話でもあります。費用超過の主因は「対象文書範囲の拡大」と「精度への過剰追求」だと指摘されており、1部門・1業務に絞って始め、段階的に広げるのが最もコスト効率が良いとされています（2026年4月時点、gxo.co.jp の費用解説より）。
対象にしやすい文書と、入れにくい文書を整理しておきましょう。
- 入れやすい：マニュアル・手順書・社内規程・過去の議事録・報告書（テキストが素直に取れるもの）
- 入れにくい：手書きスキャン画像・図表中心の資料・最新版が不明なファイル
入れにくい文書は、OCR（画像から文字を抽出する処理）などの前処理工数が別途かかります。データ整備（ドキュメント前処理）は開発費とは別に50〜150万円程度を見込むことがある、という報告もあります（2026年6月時点、blog.ripla.co.jp より）。「画像PDFが多い」だけで見積もりが変わる、と覚えておくと話が早くなります。
もう一つ、用途で索引（インデックス）を分ける考え方も有効です。
- 業務文書の索引（規程やマニュアルの在りかを探す）
- ナレッジ資産の索引（過去事例や対応履歴を探す）
この2つは混ぜないほうが使いやすくなります。私たちが製造業のお客様で構築した際も、用途ごとに索引を分けて精度を安定させました。
発注時には、次の棚卸し情報を渡せると見積もりが締まります。
- 対象フォルダ／ファイル形式（PDF・Word・Excel・画像など）
- おおよその件数
- 最新版がどう管理されているか
ここが曖昧だと、各社が「最悪のケース」を想定して見積もりを膨らませます。
論点2：精度の「合格ライン」を先に決める（RAGは100点にならない前提）
ここが本記事の中核です。最初に正直に共有します。RAGは確率的に動くため、正答率100点は保証できません。
数字で見ると分かりやすいです。RAGはハルシネーション（もっともらしい誤答）を標準的なLLM比で70〜90%削減できるものの、本番環境では依然15〜38%の発生率が残存し、完全排除は困難だと報告されています（2026年4月時点、optimax.co.jp より）。だからこそ、先に合格ラインを決めておくことが何より大事になります。
合格ラインは、次の3つの指標で測ると分かりやすいです。
- 回答率：質問にちゃんと答えられた割合
- 正答率：その答えが正しい割合
- 出典提示：根拠となった文書を一緒に出せるか
受け入れ基準（検収の合格条件）の作り方は、こうです。
- 本番でよく出る質問を30〜50問用意する
- 開発会社と一緒に採点ルール（何をもって正解とするか）を決める
- その質問セットで合格ラインを満たすかをテストする
業界では、検索側と生成側を分けて評価する考え方が定着しつつあります。検索の精度、回答が取得文書に忠実か（Faithfulness＝ハルシネーション抑制）、質問に的確に答えているか、などを測る指標群です。これらを一括計算するRAGAS（ラガス。オープンソースの評価ツール）も、広く使われる代表的な評価ツールの一つです（2026年2月時点、techfun.co.jp より）。発注先に「精度はどう評価しますか？」と聞いて、こうした評価の仕組みを説明できるかは、良い見極めポイントになります。
設計の思想として、もう一点だけ。**「分からない時は、AIに分からないと言わせる」**ことが業務では安全です。間違った断定より、「該当文書が見つかりませんでした」と出典付きで正直に返すほうが、現場の信頼を失いません。
そして、これは強調しておきたいのですが——「完全自動で全問正解」はうたいません。最終確認は人が担う、AI＋人のハイブリッド運用を前提に置いてください。むしろ「100点を保証します」と断言する業者は、警戒対象と考えたほうが安全です。
なお、精度は「決め打ち」ではなく育てるものです。大手IT企業の社内ヘルプデスクでは、初期の正答率が約50%だったものを、チャンク（文書を区切る単位）の調整やハイブリッド検索・リランキング（再順位付け）の追加で80〜91%まで段階的に引き上げた事例が報告されています（2026年4月時点、optimax.co.jp より）。「最初は60%でも、運用で育てる」という前提で握っておくと、お互いに無理がありません。精度に伸び悩んだら、RAGの導入そのものを段階的に進める考え方に立ち返るのが近道です。
論点3：更新と運用を誰が回すかを決める（作って終わりにしない）
RAGは、文書が古くなれば回答も古くなります。RAGの利点は、モデルの再学習が不要で、知識ベース（ベクトルDB）の更新だけで最新情報を反映できる点にあります。裏を返せば、その更新を誰かが回さないと精度が劣化していく、ということです（2026年6月時点、zenn.dev の解説より）。
導入時よりも先に、運用設計を決めておきましょう。決めることはこの4つです。
- 文書の追加・差し替えを、誰が・どの頻度で行うか
- 古い文書をどう外すか（再インデックス＝索引の作り直しが必要な場合がある）
- 更新を既存の業務フローに組み込めるか
- 月次レビューを誰が見るか
月次レビューの考え方はシンプルです。実際に聞かれた質問のログを見て、「答えられなかった質問」を文書側で補強していく——この継続改善のループを回せると、RAGは使うほど賢くなっていきます。
発注時の確認ポイントは、ここです。
- 納品後の更新を、自分たちでできる形にするか
- それとも保守契約で受託側に任せるか
- 任せる場合の月額はいくらか
ちなみに月額運用費の目安は10〜50万円というレンジが示されています（2026年4月時点、gxo.co.jp より。要件で大きく変わる前提の数字です）。運用負荷とランニングコストの線引きは、契約前に握っておきましょう。
論点4：セキュリティとデータの置き場所を決める（社内文書を外に出さない設計）
社内文書には、機密情報や個人情報が混ざるのが普通です。だからこそ、データがどこを通り、どこに保存されるかを発注前に確認する必要があります。
実は、社内文書RAGで最も深刻なのは「データが学習に使われるか」よりも権限制御です。役員報酬リストや未発表のM&A情報のような「見えてはいけない文書」を、権限のないユーザーへ回答してしまうリスクがあるからです。これに対しては、セキュリティトリミング（ユーザーの所属グループ情報をクエリに付け、閲覧可能な文書だけを検索対象にする仕組み）で対抗します。セキュリティは「閉域網／データ権限／入力制御／データレジデンシー／監査ログ」の5層で設計する、という整理が示されています（2026年1月時点、media.tcdigital.jp より）。
権限制御は、要件として渡すべき項目です。
- 誰が、どの文書に基づく回答を見られるか（部署・役職での出し分け）
- RLS（Row Level Security＝行レベルのアクセス制御）のような、データ単位での権限制御が必要か
クラウドの選定軸も、技術買い手の目線で整理しておきましょう。
- 既存の社内システムとの親和性
- 契約上のデータ所在地（どの国・リージョンに保存されるか）
- 社内のセキュリティ規程との整合
私たちが製造業のお客様で構築した際は、社内利用を前提とした要件に合わせてAzureを採用しました。Azure OpenAI（クラウド型）では、入力データが基盤モデルの再学習に使われないことが規約上保証され、Japan Eastリージョン利用で国内完結が可能とされています（2026年1月時点、media.tcdigital.jp より）。
ただし、ここは断定を避けたいところです。「クラウドだから何でも安全」ではありません。再学習に使われない保証はあっても、機密文書はAPI経由でクラウドに送信されます。「データを一切外部に出さない」要件なら、Open-Weightモデル（重みが公開されたモデル）のセルフホストが選択肢になり、その分コストは上がります。要件次第で結論が変わる、と理解しておいてください。
外部AI APIに文書を送る場合の確認点も挙げておきます。
- 送ったデータが学習に使われない契約条件か
- ログの保持期間はどうか
- 監査ログを残せるか
なお、総務省・経済産業省は「AI事業者ガイドライン（第1.2版）」を2026年3月31日に公表しており、RAGの参照元データに含まれる個人情報・秘密情報が意図せず出力されるリスクが、想定論点として扱われています。発注前のチェックの後ろ盾として、頭の片隅に置いておくとよいでしょう。
論点5：費用感とスコープの関係を理解する（見積もりが割れる理由）
費用は「RAGいくら」では決まりません。論点1〜4の決め方で大きく変わります。まず、よくある誤解を一つ正させてください。
「LLMのAPI代が安いから安く作れる」は、誤りです。
費用の内訳を見ると、UI開発・システム連携が全体の30〜40%、データ整備が20〜30%、ベクトルDB構築・運用が15〜25%で、LLM API利用料は10〜20%にとどまるとされています（2026年4月時点、gxo.co.jp より）。費用の大半を占めるのはAPI代ではなく、データ準備とUI開発・連携の人的工数です。
参考までに、相場感のレンジを時点情報として挙げておきます（いずれも前提条件付きの目安です）。
- PoC（小さな実証実験）：100〜300万円／期間2〜6週間（2026年4月時点、gxo.co.jp）
- 本番構築：300〜1,000万円／2〜4か月（同上）
- 月額運用：10〜50万円（同上）
別の受託会社の相場感では、PoC 50〜200万円、部門向け 300〜1,000万円、全社展開 1,000〜3,000万円超、と示されており、見積もりが割れる主因は「文書の量と種類（PDF/画像の前処理）」「セキュリティ要件（オンプレは高額化）」「既存システム連携」「精度要件」の4点とされています（2026年4月時点、syusodo.co.jp より）。
見積もりが膨らむ要因を、自社に当てはめてチェックしてみてください。
- 対象文書の量と形式の多様さ
- 精度要件の高さ
- 権限制御の細かさ
- クラウドや既存システムとの連携範囲
投資設計の基本は「小さく始める」ことです。まず1業務・1文書群でPoCを回し、効果を見てから広げる——この進め方が、結局は最もムダがありません。具体的な進め方はAI導入は「PoC」から始めるで詳しく書いています。
相見積もりを読み解くコツも一つ。金額だけで比べないことです。「どこまでをスコープに含むか（運用・改善・権限設計の有無）」を揃えてから比較しないと、安く見える見積もりが実は運用費を含んでいなかった、ということが起こります。初期構築費だけでなく、AI API利用料・クラウド費・保守の月額も合算した総額（TCO＝総保有コスト）で考えましょう。
補足として、2026年度から中小企業向けにAI・デジタル導入を後押しする補助金の活用も検討材料になります。ただし補助率・名称・要件は公募回次で変わります。利用を見込む場合は、申請時点の公募要領で必ず最新の内容をご確認ください。
発注前チェックリスト（このまま打ち合わせに持っていける）
5論点を、1ページの確認リストに圧縮しました。初回打ち合わせにそのまま持っていけます。
- [ ] 対象文書を絞ったか（1部門・1業務から。フォルダ・形式・件数・最新版管理を棚卸し）
- [ ] 合格ラインの指標と評価質問を用意したか（回答率・正答率・出典提示／評価用30〜50問）
- [ ] 更新担当を決めたか（誰が・どの頻度で／保守契約の有無と月額）
- [ ] データ所在と権限要件を整理したか（保存先・データ所在地／部署・役職での出し分け）
- [ ] スコープ前提で相見積もりを比較したか（運用・改善・権限設計の有無を揃える／TCOで見る）
使い方のコツは、全部を完璧に埋めようとしないことです。空欄こそ、開発会社と一緒に詰めるべき論点です。むしろ「ここが決まっていません」と正直に持ち込むほうが、提案の精度は上がります。このリストを持参するだけで、各社の提案を同じ土俵で比べられるようになります。
よくある質問（FAQ）
Q1. 社内文書がきれいに整理されていなくても発注できますか？
はい、できます。整理は発注後に一緒に進められます。まず対象を絞り、棚卸し（件数・形式・最新版の管理状況）を共有するところから始めれば十分です。「整理してから相談しなきゃ」と止まってしまうより、現状のまま相談したほうが前に進みます。
Q2. RAGの精度は何割くらいまで上がりますか？
文書の質と質問の範囲によって変わるため、断定はできません。だからこそ、評価質問で合格ラインを事前に合意することが大切です。事例では初期50%前後から80〜91%まで段階的に改善した報告もありますが（2026年4月時点、optimax.co.jp より）、これは継続改善の結果です。100点を前提にせず、最終確認は人が担うAI＋人のハイブリッド運用で回すのが現実的です。
Q3. 既存のSaaSやAIチャットで足りるか、受託で作るべきか迷っています
範囲が狭く一般的な用途なら、既製のツールも十分に選択肢です。汎用的なFAQや、機密性の低い情報の検索であれば、そちらのほうが早く安く済むこともあります。一方、社内文書・細かい権限制御・セキュリティ要件が絡むなら、受託の出番です。判断軸は「権限の出し分けが必要か」「データを社外に出せるか」の2点。どちらが優れているという話ではなく、要件しだいです。
あわせて読みたい
まとめ：決めてから渡せば、RAGは怖くない
最後に、要点を短くまとめます。RAGの受託は、技術選定よりも**「発注側が5論点を決めること」**で結果の大半が決まります。
- 対象を絞り、合格ラインを握り、更新担当を決め、権限とデータ所在を整理し、スコープ前提で見積もりを比べる
- 最初から完璧を目指さず、PoCから始めて運用で育てる
- 「100点保証」「全文書を一度に」「API代だけで安い」——この3つの言葉が出たら一歩立ち止まる
周辺の論点は、既存システムを活かしたままAIを組み込む方法や、AI開発会社の選び方もあわせて読んでいただくと、発注の解像度がさらに上がるはずです。
私たちゼットリンカーでも、製造業のお客様で数百件の社内文書を対象にしたRAGを、Next.js＋OpenAI API（Embeddings＝文書をベクトル化する仕組み）＋Mastra（検索→整形→生成のワークフロー管理）＋Azureという構成で構築した実績があります。今日挙げた5つの論点を、御社の文書とセキュリティ要件に合わせて一緒に言語化するところからお手伝いできます。「まず何から決めればいいか」の壁打ちだけでも歓迎ですので、よければお気軽にご相談ください。
※本記事に記載した費用・精度・補助金の数値は、各出典の公開時点（2026年1月〜6月）の情報に基づく目安です。要件によって大きく変動し、補助金の要件・公募回次は変更されます。導入の判断にあたっては、必ず最新の公募要領・各サービスの公式情報をご確認ください。
この記事を書いた人
株式会社ゼットリンカー