RAG構築会社を探す前に2026年のマネージド型で足りるか確かめる
社内規程、FAQ、提案書、問い合わせ履歴を生成AIで引けるようにしたい。そう考えて「RAG 構築 会社」「RAG 導入支援」と検索し、見積もりを取ろうとしている担当者は多いと思います。
ただ、見積もりを取る前に確かめておきたいことがあります。2026年のRAGは、数年前のように検索基盤から作り込む前提ではなくなりました。 主要クラウドがRAGの中核部分をマネージドサービスとして提供しており、フルスクラッチの構築費を払わなくても動く範囲が広がっています。
ここを確かめずに「RAG構築一式」で発注すると、本来なら不要だった開発費を払い、しかも肝心の文書整備と精度評価は自社に残る、という形になりがちです。この記事では、どこまでを買い、どこからを自社で持ち、外部支援には何を頼むのかを切り分けます。
この記事でわかること
- マネージド型で足りる範囲と足りない条件
- 費用が動く4つの要因と試算の立て方
- 精度と権限を発注仕様にどう書くか
- RFPで聞くべきRAG固有の質問
RAG導入支援は4つの発注範囲に分けて考える
RAG導入の見積もりが会社によって10倍以上ぶれるのは、各社が違う範囲を見積もっているからです。まず、発注範囲を4つに分けてください。この切り分けをしてから相見積もりを取ると、金額の差が「何をやるかの差」なのか「単価の差」なのかを判別できます。
| 発注範囲 | 中身 | 外注しやすさ | 自社に残る仕事 |
|---|---|---|---|
| 業務設計 | どの質問に答えさせるか、成功条件 | 一緒に決める | 対象業務の優先順位 |
| 文書整備 | 重複・旧版の廃棄、更新責任の割当 | 一部のみ | 文書オーナーの任命 |
| 構築 | 検索基盤、権限連携、UI、社内連携 | 外注しやすい | 要件の確定 |
| 運用改善 | 失敗質問の分析、文書と検索の修正 | 伴走可 | 改善会議の主催 |
このうち構築だけが「買える」領域です。 業務設計と文書整備は外部が代行しても、判断の主体は自社に残ります。運用改善は伴走を頼めますが、直す対象が自社文書である以上、手を動かすのは自社です。
見積書を読むときは、金額の前に「この4つのどこが含まれているか」を確認してください。構築だけの見積もりに文書整備を期待していると、納品後に「使えない」と感じる原因になります。==RAG導入で失敗する発注の多くは、構築費を払ったのに文書整備と運用改善の担当が決まっていない状態から始まります。==
2026年のRAGは「作る」から「つなぐ」へ変わった
RAG構築の記事や見積もりの多くは、検索基盤をゼロから組み上げる前提で書かれています。ですが2026年時点では、RAGの中核である取り込み、分割、埋め込み、索引、検索の各工程が、主要クラウドのマネージドサービスとして提供されています。
AWSのAmazon Bedrock Managed Knowledge Baseは、2026年6月17日に一般提供が開始されたフルマネージドのRAGサービスです（2026年7月19日確認）。データソースコネクタは Amazon S3、SharePoint、Confluence、Google ドライブ、OneDrive、Web クローラーの6つです。さらに hybrid search とドキュメントのランク付け、クエリ計画を自動で組み立てる agentic retrieval、マネージドのベクトルストレージまで備えます。
Google CloudのRAG Engineも、取り込みから変換、埋め込み、索引、検索、生成までを扱うマネージドのランタイムを提供します。ベクトルストアは RagManagedDb に任せることも、既存のベクトルDBを指定することもできます。
Microsoftのドキュメントによれば、Azure AI Search は、ワークロードが安定している用途向けの Dedicated が正式提供され、変動が大きい用途向けの Serverless はプレビュー段階です（2026年7月13日更新・同年7月19日確認）。Serverless は事前のキャパシティ確保が不要な従量課金という設計ですが、プレビュー中は本番利用が推奨されずSLAもなく、提供リージョンも West Central US・Switzerland North・Japan East の3つに限られ、他ティアとの相互移行もできません。本番前提の選定では現時点で Dedicated を基準に見積もってください。 なお、ベクトル検索自体は全ティアで追加料金なしに使えます。
つまり、以前は開発費として計上されていた工程のかなりの部分が、いまは月額のサービス利用料に置き換わっています。 発注前に「その構築費は、マネージドサービスで代替できない部分か」を必ず聞いてください。
ワンポイントアドバイス: 見積もりに「ベクトルDB構築」「検索基盤開発」の項目があったら、なぜマネージドで足りないのかを1問だけ聞いてください。答えられる会社は要件を理解しています。
それでもフルスクラッチが必要になる条件
マネージドで足りないケースも当然あります。私の実務見解では、次のいずれかに当てはまるときは作り込みを検討する価値があります。
- 検索対象が基幹システムや業務DBの中にあり、ファイルとして取り出せない
- クラウドの提供リージョンやデータ所在地の制約が社内規程と合わない
- 部署別・案件別の権限が既存のIDと連動せず、独自の権限モデルが必要
- 回答を業務システムへ書き戻すなど、検索の先に処理が続く
逆に、対象が SharePoint や Google ドライブに置かれた文書で、権限も既存のIDに沿っていて、まずは社内問い合わせに答えられればよい、という状態なら、構築費より先に文書整備へ予算を振ったほうが成果は出やすいです。
どの構成方式に落ちるかで、初期費用と期間の桁が変わります。金額は案件で大きく動くため実数では示せませんが、私の実務見解による目安として、相見積もりの前に自社がどの行に当たるかを確かめてください。
| 構成方式 | 初期構築の規模感 | 導入期間の目安 | 自社工数の中心 | 向くケース |
|---|---|---|---|---|
| マネージド型 | 小。サービスの設定が中心 | 数週間から1か月程度 | 文書整備と評価 | 文書がクラウド上にあり権限も既存IDに沿う |
| ハイブリッド型 | 中。接続や権限の一部を開発 | 1から3か月程度 | 評価に加え接続仕様の確認 | 一部のデータが業務システムの中にある |
| フルスクラッチ | 大。検索基盤から設計 | 3か月以上 | 専任に近い体制が必要 | 独自の権限モデルや業務連携が必須 |
自社がマネージド型の行に当てはまるなら、相見積もりで比べるべきは構築費ではなく、文書整備と評価設計の支援内容です。逆にフルスクラッチの行に当てはまる場合は、期間と体制の見積もりが甘い提案を先に落とせます。
RAGを作らなくてよいケースを先に外す
発注検討の前に、そもそもRAGが手段として合っているかを確かめてください。相談を受ける中で、RAG以外の手段のほうが早いケースは珍しくありません。
| 状況 | RAGより先に見る手段 | 理由 |
|---|---|---|
| 対象文書が数十件以内 | 文書の統合と目次整備 | 検索を作るより探しやすくなる |
| 答えが数値の集計 | BI・レポート | 検索ではなく集計の問題 |
| 情報が毎日書き換わる | 元システムへの直接参照 | 索引の更新が追いつかない |
| 質問が定型10種類程度 | FAQページ・分岐型ボット | 生成AIを挟む必要が薄い |
| 文書が個人フォルダに散在 | 保管場所の一本化 | 何を索引するか決められない |
RAGが効くのは、答えが文章の中にあり、質問の言い回しが人によって揺れ、対象文書が人手で探すには多すぎる場合です。 この3つがそろわないなら、別の手段のほうが安くて速いことがあります。
==「RAGをやること」を目的にした相談は、PoCで一度動いた後に止まりやすいです。== 止まる理由は精度ではなく、そもそもその業務で毎日使う理由がなかったから、という場合が多いと感じています。
RAG構築会社に依頼できることと、自社に残る仕事
依頼できる範囲を具体化しておくと、提案書の比較が一気に楽になります。RAG導入支援で外部が担えるのは、要件定義、データソース接続、分割方針の設計、検索の調整、権限連携、評価環境の用意、運用手順の整備までです。
| 依頼できること | 自社が持ち続けること |
|---|---|
| データソース接続と索引の設計 | どの文書を対象にしてよいかの判断 |
| 分割単位と検索方式の調整 | 現場が実際に聞く質問の提供 |
| 権限連携の実装 | 部署別・役職別の閲覧可否の決定 |
| 評価用の質問セットと採点環境 | 正解・不正解の最終判定 |
| 運用手順と改善会議の設計 | 文書の更新と旧版の廃棄 |
右列は外注できません。特に**「現場が実際に聞く質問を集める」ことと「回答の正誤を判定する」ことは、業務を知っている人にしかできない**作業です。ここを外部任せにした案件は、評価が「なんとなく良さそう」で終わり、改善の起点を失います。
初回相談では、文書量や予算の前に、現場が本当に聞きたい質問を10個出せるかを見てください。質問例が具体的なほど、対象範囲を絞れて見積もりも小さくなります。文書量や権限が未整理でも、対象業務とPoC範囲から相談は始められます。
支援範囲や進め方をあらためて確認したい場合は、AI活用サービスのページもあわせてご覧ください。
RAG導入の費用は4つの要因で決まる
金額そのものより、何が金額を動かすのかを理解しておくほうが交渉に使えます。RAG導入の費用は、次の4つでほぼ説明がつきます。
| 費用を動かす要因 | 小さく収まる条件 | 大きくなる条件 |
|---|---|---|
| 対象範囲 | 1部署・1用途・1データソース | 全社・複数用途・多数の接続先 |
| 文書の状態 | 保管場所が一本化されている | 個人フォルダに散在、旧版が混在 |
| 権限の複雑さ | 全員が同じ範囲を見てよい | 部署別・案件別・役職別に分岐 |
| 評価の厳しさ | 参考回答として使う | 誤答が業務事故につながる |
ランニングの内訳も、構造で理解しておくと見積もりを読み解けます。マネージド型の場合、費用は検索基盤の利用料、検索リクエストへの課金、埋め込みと回答生成のトークン課金に分かれます。AWSは agentic retrieval についてBedrockの料金ページで、独自のLLMを使う構成では Retrieve API の呼び出し1,000回あたり1.00 USDに加えてクエリ計画で使うモデルの料金がかかると案内しています（2026年7月19日確認・料金は改定されるため契約前に公式で最新を確認してください）。
注目してほしいのは、クエリ単位の課金が明示されている点です。 利用が増えれば費用も増えるため、社内展開の計画と費用計画を同時に立てる必要があります。
費用の考え方を試算例で確認する
アズくんワンポイント: うーん、結局うちの場合はいくらになるんだろう？外の会社に払うお金だけ見ておけばいいのかな？
金額感をつかむために、仮定を置いた試算例を1つ示します。実績値ではなく、費用構造を確かめるための仮説モデルです。
- 前提: 1部署・対象文書1,500件・利用者50名・1人1日2回利用（月およそ2,000クエリ）
- 検索基盤とモデル利用料: クエリ数と文書量に比例する変動費として月額で見る
- 文書整備: 1,500件の棚卸しと旧版廃棄を、担当者1名が週4時間×2か月で実施
- 評価設計: 想定質問50問の作成と初回採点を、現場2名で計20時間
この置き方をすると、自社側だけで約52時間（担当者1人の1か月分に近い工数）がかかることが見えてきます。外部への支払額と並べる前に、この社内工数を確保できるかを先に確認してください。ここを見積もりに入れずにPoCを始めると、担当者の残業で吸収する形になり、2か月目で止まります。
投資対効果を見るときは、削減時間だけで判断しないでください。問い合わせ件数の減少に加えて、利用率、再検索の回数、未回答率、誤答が直るまでの日数まで並べると、続ける価値があるかを判断できます。
この記事もおすすめ｜AIコンサル費用は無料診断から1,000万円超の開発まで支援範囲で決まる｜RAGに限らずAI支援全般の料金体系と内訳を比較したい場合に役立ちます。｜
精度は「検索」と「生成」を分けて発注仕様に書く
RAGの提案書で最も差が出るのが、精度をどう定義しているかです。「精度95%を目指します」とだけ書かれた提案は、何を測るのかが決まっていないので、後から検証できません。
RAGの誤答には、原因が2つあります。正しい文書を取ってこられなかったのか、取ってきた文書を正しく読めなかったのかで、直す場所がまったく違います。 前者は検索側、後者は生成側の問題です。
| 分けて測る対象 | 見る指標 | 外れたときに直す場所 |
|---|---|---|
| 検索 | 正解文書が上位に入った割合 | 分割単位、検索方式、同義語 |
| 生成 | 取得文書だけで答えているか | 指示文、出力形式、出典表示 |
| 拒否 | 答えられない質問を断れたか | 閾値、回答不能時の文面 |
Microsoftのドキュメントは、RAGの難しさとして質問の理解、複数データソースへの接続、トークン制約、応答時間、セキュリティとガバナンスの5つを挙げています。対策には、キーワード検索とベクトル検索を組み合わせた hybrid search と、意味に基づいて並べ替える semantic ranking が示されています。詳しくはAzure AI SearchのRAG概要で確認できます。
発注仕様には、次の3点を入れてください。評価用の質問セットを誰が何問作るか、正解の判定を誰がするか、検索と生成のどちらの指標を合格条件にするかです。この3点が書かれていない提案は、納品後に「精度が出ない」の押し問答になります。
ワンポイントアドバイス: 評価用の質問には、あえて答えられない質問を1割ほど混ぜてください。断れるかどうかは、業務で使えるかを分ける実務的な条件です。
権限の設計はRAG固有の最難関になる
一般的なAIガバナンスの整備とは別に、RAGには固有の難所があります。それは、検索対象を増やすほど、権限設計の漏れが「回答」という形で表に出てしまうことです。閲覧できないはずの文書の内容が、要約された回答として返る事故が起こり得ます。
Microsoftのドキュメントでは、この対策としてデータソース別の手段が整理されています。SharePoint の権限継承はリモート SharePoint への agentic retrieval 時、Microsoft Entra ID の権限メタデータ継承は Azure Storage から索引した内容が対象で、それ以外は文書単位のセキュリティトリミングやクエリ時のフィルタで制御します。どのデータソースでも既存権限が自動で引き継がれるわけではない点が、設計時の分岐になります。要点は、権限を後から足すのではなく、索引を作る段階で権限情報を一緒に持たせるという設計です。
!!顧客情報、契約書、人事情報、未公開の資料を、権限設計を決めないまま索引対象に入れないでください。!! 一度索引に入った内容は、検索の結果としてではなく回答の一部として現れるため、閲覧ログだけでは事故に気づきにくくなります。
外部支援会社へ確認する項目は5つに絞れます。
- 既存のIDやグループ権限をそのまま引き継げるか
- 権限が変わったとき、索引側に何日で反映されるか
- 退職者や異動者のアカウントをどう扱うか
- 質問と回答のログをどこに、何日間保存するか
- 回答に出典を表示し、原文へたどれるか
社内ルールや利用ポリシーそのものの整備は、RAG導入とは別の作業として進めたほうが早く片づきます。法務や情報システム部門へ相談するときは、「AIを使いたい」ではなく、検索対象、閲覧権限、ログ保存、削除条件を先に見せると、確認が具体化します。
この記事もおすすめ｜生成AIガイドラインで整える社内ルール5領域とリスク管理の実務｜RAG以前に社内の利用ルールから整えたい場合は、こちらで5領域を確認できます。｜
なお、AIの取り扱い全般については、NISTのAI Risk Management Frameworkや経済産業省のAI事業者ガイドラインが、確認観点の整理に使えます。RAG固有の権限設計と、組織としてのAIガバナンスは、担当も期限も分けて進めてください。
RAG導入支援会社をRFPで見極める7つの質問
会社選びでは、AIモデル名やツール名の比較に時間を使わないでください。同じモデルを使っても、結果を分けるのは分割単位、検索の調整、権限連携、評価の設計です。次の7問への答え方で、実務経験の有無はかなり判別できます。
| 質問 | 良い答えの特徴 |
|---|---|
| マネージドで足りない理由は何か | 具体的な制約を1つ挙げる |
| 文書の分割単位はどう決めるか | 文書種別ごとに変えると答える |
| 検索と生成のどちらを先に評価するか | 検索を先に測ると答える |
| 権限はどこから引き継ぐか | 既存IDの名前が出てくる |
| 答えられない質問はどう扱うか | 断る動作を設計に含めている |
| PoC後に社内へ何が残るか | 質問セットと評価表を挙げる |
| 使われなかったときどう直すか | ログの見方を具体的に話す |
特に3問目と5問目は、RAGを実際に運用したことがあるかが出ます。 検索を測らずに生成の出力だけを見ている提案は、改善の打ち手が「プロンプトを直す」に偏りがちです。
==会社選びで見るべきは、RAGを作れるかではなく、失敗した質問をどう直すかを説明できるかです。== RAGは作って終わりではなく、利用ログを見ながら文書と検索を更新し続ける仕組みだからです。
提案書では、想定質問の作り方、正誤判定の基準、出典確認の方法、未回答時の扱い、そして誤答を文書側で直すのか検索側で直すのかが説明されているかを見てください。PoC後に社内へ残る文書分類表、評価表、権限表、改善ログのひな形まで示されていれば、内製化にもつなげやすくなります。
7つの質問を投げる前の段階、つまりRFPや発注仕様のたたき台を書くところで手が止まっているなら、そこだけ外部に相談する方法もあります。LOadsでは、対象業務の絞り込み、評価基準の置き方、発注仕様のレビューといった発注前の整理を、AI活用の支援の範囲としてご相談いただけます。構築を依頼する会社を決める前でも、仕様の切り分けだけ先に進められます。
相談前に埋めておくチェック項目
すべてを決めてから相談する必要はありません。ただ、次の項目が埋まっていると、初回の相談で範囲と概算まで話が進みます。
チェックリスト
- 改善したい業務と部署を1つに絞っている
- 対象にしたい文書の保管場所を把握している
- 文書の更新責任者が決まっている、または決められる
- 索引に入れてはいけない情報を挙げられる
- 部署別・役職別の閲覧権限をおおまかに把握している
- 現場が実際に聞く質問を10個書き出している
- 答えられなくてよい質問の範囲を決めている
- 評価の合格ラインを誰が判定するか決めている
- 既存のIDやグループ権限の仕組みを説明できる
- 予算と希望スケジュールの幅を持っている
10項目のうち埋まらないものがあっても、そこで検討を止める必要はありません。支援の現場では、埋まらなかった項目こそ初回相談で最初に整理するテーマになります。たとえば文書の更新責任者が決められないなら、それは発注の障害ではなく、文書整備をどこまで支援範囲に含めるかを決める材料です。
この記事もおすすめ｜AIコンサルとは？依頼内容・費用相場・会社選び・導入手順を解説｜課題整理・PoC・実装・定着まで実務手順｜相談から定着までの工程と各段階でやることを、発注前に通しで確認できます。｜
相談前に見る数字
対象業務の問い合わせ件数、資料を探す時間、同じ質問の発生頻度、回答までの時間、想定利用者数を確認してください。数字がそろっていなくても、見えていない数字を把握するだけで、RAGで解決すべき範囲がはっきりします。
よくある質問
Q. マネージドのRAGサービスを使えば、外部支援は不要ですか？
構築の工数は下がりますが、対象業務の選定、文書整備、評価設計、権限の擦り合わせは残ります。情報システム部門にクラウドの運用経験があれば、構築は内製し、評価設計と運用改善だけ外部と組む形が現実的です。
Q. マネージド型でも、自社の専門用語だらけの文書で精度は出ますか？
マネージド型かどうかと精度は、直接は結びつきません。専門用語で精度が落ちる主因は検索側にあり、分割単位の見直しと同義語の登録で改善できる余地が大きい部分です。マネージド型でもこの調整はできるため、方式より先に、評価用の質問セットで検索の取りこぼしを測れる体制を作れるかを確認してください。
Q. 権限設計が社内で固まっていなくても、設計から依頼できますか？
現状の権限構造の棚卸しと設計案の作成は依頼できます。ただし、部署別・役職別にどこまで見せてよいかの最終決定は自社にしか下せません。既存のIDやグループ権限の仕組みを説明できる人を相談の場に同席させると、設計案までの往復が一度で済みます。
Q. PoCはどのくらいの範囲で始めるべきですか？
1部署、1用途、1データソースに絞ってください。対象を広げるほど、精度が出ない原因が文書なのか検索なのか権限なのかを切り分けられなくなります。
Q. 精度が出ないと言われたとき、最初に何を確認しますか？
正解の文書がそもそも検索で取れているかを確認してください。取れていれば生成側、取れていなければ分割単位か検索方式の問題です。この切り分けをせずにプロンプトだけを直すと、時間だけが過ぎます。
Q. 社内文書が散らかったままでも相談できますか？
相談はできます。ただし、散らかり方によって最初の一手が変わります。保管場所が分散しているなら一本化が先、旧版が混在しているなら廃棄が先です。相談時に、対象文書の置き場所と件数のおおよそだけ持参してください。
Q. RAGの費用は何年で回収を見込むべきですか？
回収期間より先に、利用が定着するかを見てください。月次で利用率と未回答率が改善しているなら継続、3か月経っても利用が伸びないなら対象業務の選定に戻る、という判断のほうが実務的です。
まとめ
RAG導入の相談は、「作れる会社を探す」ところから始めなくてよくなりました。2026年時点では、取り込みから検索までの中核をマネージドサービスが担っており、フルスクラッチが必要かどうかは条件で判断できます。
発注範囲は、業務設計、文書整備、構築、運用改善の4つに分けてください。買えるのは構築だけで、文書整備と評価判定は自社に残ります。費用は対象範囲、文書の状態、権限の複雑さ、評価の厳しさで動くため、金額の前にこの4点を揃えるほど見積もりは小さく、確かになります。
精度は検索と生成を分けて測ること、権限は索引を作る段階で設計すること。この2つを発注仕様に書けているかが、提案書の質を見分ける基準になります。まずは、改善したい業務を1つ選び、現場が実際に聞く質問を10個書き出すところから始めてください。
質問を書き出してみて、対象業務の絞り込みや評価基準の置き方で判断が割れるなら、その切り分けから外部と一緒に進めたほうが早い状態です。LOadsでは、RAGを含むAI活用の支援として、発注前の範囲整理と仕様の言語化からご相談いただけます。
参考にした公式情報
- AWS: Amazon Bedrock Managed Knowledge Base の一般提供開始（2026年6月17日） — マネージドRAGの提供機能とデータソースコネクタの確認に使用
- AWS: Amazon Bedrock 料金 — 検索呼び出しのクエリ単位課金の構造の確認に使用
- Google Cloud: RAG Engine の概要 — 取り込みから生成までの工程とベクトルストアの選択肢の確認に使用
- Microsoft Learn: Azure AI Search の課金モデルとティア — Dedicated の正式提供と Serverless のプレビュー状況・提供リージョンの確認に使用
- Microsoft Learn: Azure AI Search における RAG — RAGの課題整理、検索方式、文書単位の権限制御の確認に使用
- NIST: AI Risk Management Framework — AIリスク管理の確認観点の整理に使用
- 経済産業省: AI事業者ガイドライン — 国内でのAI利用時の確認事項の整理に使用
