LASSIC Media らしくメディア
RAG構築を外注する費用と進め方｜社内文書検索AI解説
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- RAGは社内文書を参照して根拠付きで回答するAI手法で、汎用の生成AI導入とは異なる専用構築が必要になります
- 外注費用はデータ整備・ベクトルDB構築・LLM連携・UIの工程ごとに異なり、プロジェクト規模や品質要件で大きく変わります
- PoCから本番移行まで段階的に進めることで、失敗リスクを抑えながらRAGを実用化できます
目次
RAG構築の外注とは何か
RAG（Retrieval-Augmented Generation、検索拡張生成）の外注構築とは、社内ドキュメント・マニュアル・議事録などの自社固有データを参照し、根拠付きで回答する生成AIシステムを、専門ベンダーに委託して設計・開発・運用する形態を指します。汎用チャットbot（ChatGPTなど）とは異なり、RAGは自社データに紐づいた回答精度が問われるため、データ整備からインフラ構築まで専用の技術工程が必要になります。
RAGが注目される背景には、LLM単独では自社固有の情報（社内規程・製品仕様・過去議事録など）を回答に反映できないという限界があります。RAGはその限界を補う手法として、企業の社内文書検索・ヘルプデスク自動化・コンプライアンス対応などへの適用が増えています。
外注を選ぶ企業の多くは、「AIエンジニアを採用する時間的余裕がない」「PoC（概念実証）から本番まで一貫して任せたい」というケースです。RAG構築には埋め込みモデルの選定・ベクトルDBの設計・LLMのプロンプト設計など複数の専門領域が絡むため、それらを統合できるベンダーへの外注が現実的な選択肢になります。
RAGの仕組み：検索＋LLM生成の6工程
RAGシステムは大きく「インデックス化フェーズ」と「回答生成フェーズ」に分かれます。この2フェーズを理解しておくと、外注時の工程別見積もりを適切に評価できます。
インデックス化フェーズ：文書をベクトルDBに格納するまで
インデックス化フェーズの最初の工程はデータ整備・クリーニングです。PDF・Word・Excelなどの社内文書をテキストとして抽出し、OCRが必要な紙ベース文書の対応やフォーマット統一を行います。この工程が不十分だと後続の検索精度に直結するため、工数がかかりやすい箇所です。
次にチャンク化を行います。長文ドキュメントを検索に適したサイズの断片（チャンク）に分割します。チャンクのサイズや分割方法（段落単位・文字数固定など）は、検索精度に大きく影響します。
続いて埋め込み（エンベディング）で、各チャンクをベクトル（数値の配列）に変換します。埋め込みモデルはOpenAI Embeddingsなどを使うことが一般的ですが、日本語精度を高めるためにはモデル選定に専門知識が求められます。
最後にベクトルDBへの格納を行います。変換されたベクトルをベクトルデータベース（Pinecone・Weaviate・pgvectorなど）に格納し、類似検索が高速にできるようインデックスを構築します。
回答生成フェーズ：クエリへの回答を生成するまで
ユーザーが質問を入力すると、まずクエリのベクトル化を行い、同じ埋め込みモデルで検索クエリをベクトルに変換します。次に類似検索でベクトルDB内から意味的に近いチャンクを取得します。
取得したチャンクを文脈としてプロンプトに組み込み、LLM（GPT-4o・Claude・Geminiなど）に渡すことで、社内データに基づいた根拠付き回答が生成されます。この「検索結果をLLMへのコンテキストとして注入する」点がRAGの本質です。*1
外注構築の費用構造：工程別の費用要因
RAGの外注費用は、工程・データ規模・品質要件・インフラ構成によって変わります。以下では費用に影響する主な要因を工程別に整理します。なお、以下の費用レンジは市場参考値であり、一次資料ではありません。実際の費用は要件定義時に複数ベンダーへの見積もり取得を推奨します。
| 工程 | 費用に影響する主な要因 | 工数が増えやすいケース |
|---|---|---|
| データ整備・クリーニング | 文書種別数・総ページ数・OCR対象の有無・フォーマット統一の複雑度 | 紙ベース文書が多い場合、OCR精度検証と補正作業が増加します。 文書フォーマットが部署ごとに異なる場合も工数が膨らみます。 |
| チャンク化・埋め込み | 文書総量・チャンク戦略の複雑度・日本語対応モデルの選定 | 専門用語が多い業界（医療・法律・製造）では日本語モデルの評価・チューニングに時間がかかります。 |
| ベクトルDB構築 | DBの種類（クラウドマネージド vs 自前）・格納ベクトル数・冗長化要件 | オンプレミス環境への構築やセキュリティ要件が厳しい場合は、設計・検証工数が増えます。 |
| 検索精度評価 | 評価クエリ数・精度指標の設定・改善イテレーション回数 | 回答精度のKPIを厳格に設定する場合は、評価→チューニングの繰り返しサイクルが長くなります。 |
| LLM連携・プロンプト設計 | LLM選定・プロンプトの複雑度・API連携実装・ハルシネーション対策 | 複数LLMの比較評価や、回答に出典URLを付ける要件がある場合は設計工数が増えます。 |
| UI・フロントエンド | 既存システムとの連携有無・認証連携・モバイル対応・デザイン要件 | 既存の社内ポータルやSlackなどのツールへの組み込みは、連携仕様の調整に工数がかかります。 |
| 保守・運用設計 | 監視体制・文書更新頻度・SLA要件・サポート範囲 | 文書の更新頻度が高い場合は再インデックス化の自動化設計が必要になり、初期構築費に追加されます。 |
費用構造を理解するうえで大切なのは、RAGの外注費用が「システム開発費」だけでなく「データ整備費」「LLM利用料（従量課金）」「運用保守費」に分かれることです。特にLLMのAPI利用料は月次の従量費用として継続的にかかるため、長期的なTCO（総保有コスト）を試算してから外注先と交渉することが大切です。
プロジェクト規模の目安として、PoCフェーズのみなら比較的コンパクトに検証できますが、本番システムへの移行・社内認証連携・高可用性対応などを加えると費用と工期は大きく変わります。「市場参考値・一次資料ではない」ことを前提に、複数ベンダーから見積もりを取得して比較することを推奨します。
外注で得られること：内製との比較
RAG構築を内製するか外注するかは、社内のAI人材体制と時間的制約によって変わります。内製には中長期的なノウハウ蓄積というメリットがありますが、RAGに必要な技術スタックは広範です。
内製でRAGを構築するには、少なくとも次の領域の知識が必要です。自然言語処理（NLP）エンジニア・MLOps（機械学習システムの運用）担当・クラウドインフラエンジニア・フロントエンドエンジニアを組み合わせたチームが求められます。これらを社内で揃えるには、採用から一定のリードタイムがかかります。
外注のメリット：即戦力チームと失敗リスク低減
外注の主なメリットは3点あります。第一に、RAG構築の経験を持つエンジニアチームをすぐに活用できます。第二に、過去のPoC失敗事例や精度改善のノウハウを持つベンダーは、自社固有の落とし穴を事前に回避できます。
第三に、プロジェクト管理の負担を軽減できます。RAGは工程間の依存関係が複雑で、データ整備の遅れがベクトルDB構築に直接影響します。専任プロジェクトマネージャーを持つ外注先であれば、スケジュール管理のリスクを分散できます。
内製のメリットと現実的な課題
内製のメリットは長期的なコスト最適化と自社ノウハウの蓄積です。ただし、RAGはモデルの陳腐化が速く、LLM・埋め込みモデルの更新対応を継続的に行う必要があります。内製チームを維持するには、継続的な学習投資とエンジニアの定着率管理が必要になります。
外注と内製のハイブリッドとして、「PoC・初期構築は外注し、運用保守から内製に移管する」という段階的移行も現実的な選択肢です。この場合、外注先に技術移転（ドキュメント・ソースコード・運用手順書の引き渡し）を要件として明示することが大切です。
外注先の選定ポイント：3つの確認軸
RAG構築の外注先を選ぶ際には、「汎用のAI開発実績」ではなく「RAG固有の構築経験」を持つかを確認することが重要です。以下の3軸を評価の基準にすると、選定の精度が上がります。
軸1：日本語RAGの構築実績と品質評価の方法論
日本語は形態素解析の複雑さや同音異義語の多さから、英語環境と比べて埋め込みモデルの選定と評価に専門的知識が求められます。「日本語のRAGを何件構築したか」「検索精度をどの指標（Precision・Recall・MRR等）で評価しているか」を確認してください。
提案書にRAGの評価指標（Recall@k・NDCG・RAGASスコアなど）が具体的に記載されているベンダーは、品質管理の方法論を持っている証拠です。指標の記載がない提案書は、品質の基準が曖昧なリスクがあります。
軸2：データセキュリティとクラウド構成の透明性
社内文書には機密情報が含まれるため、データの保管場所・暗号化方式・アクセス制御の設計を事前に確認することが大切です。特に「LLMへの問い合わせ時にどのデータが外部APIに渡るか」は、情報漏えいリスクに直結します。
オンプレミス構成やプライベートクラウド（Azure Government・AWSのVPC隔離環境など）での構築実績があるベンダーは、セキュリティ要件の厳しい企業でも対応できます。セキュリティ要件を事前にRFP（提案依頼書）に明記して比較することを推奨します。
軸3：PoC後の本番移行支援と保守体制
RAG構築で陥りやすい失敗は、「PoCは成功したが本番移行で品質が下がった」というケースです。本番環境では同時アクセス数・文書更新頻度・エラー監視など、PoC時には想定しなかった要件が加わります。
外注先に「PoCから本番移行まで一貫して担当した事例」の提示を求め、移行時の課題と対処方法を確認してください。また、本番稼働後の問い合わせ対応・モデル更新対応・再インデックス化の保守体制が契約に含まれているかも確認が必要です。
PoCから本番移行までの進め方
RAGの外注プロジェクトは「PoC → パイロット → 本番移行」の3段階で進めることが現実的です。一気に全社展開を試みると、データ品質や精度の問題が本番環境で顕在化しやすくなります。
フェーズ1：PoC（概念実証）——限定スコープで精度を確認する
PoCでは、全社文書を対象にするのではなく、「特定部署のマニュアル30〜50文書」「製品FAQページのみ」など限定スコープでシステムを構築します。PoCの目的は、精度目標（例：上位3件以内に正解文書が含まれる率）を定めて、外注先の技術力と自社データとの相性を検証することです。
PoCフェーズでは、外注先と共同でテストクエリセット（代表的な質問20〜50問）を作成し、定量的に精度評価することが大切です。感覚的な評価だけでは本番移行の判断基準が曖昧になります。
フェーズ2：パイロット——対象部署を限定して本番環境に近い形で検証する
PoCで精度目標を達成できたら、パイロット展開に移行します。パイロットでは特定の業務部門（例：カスタマーサポート・法務・人事）に限定して実際の業務フローに組み込みます。
パイロット期間中に重要なのは、利用者フィードバックの収集です。「回答が役立たなかった質問」を記録し、チャンク設定やプロンプトの改善に反映させます。外注先にフィードバックループの仕組みをあらかじめ設計してもらうことが、本番品質を高めるポイントです。
フェーズ3：本番移行——スケール対応とセキュリティ強化
本番移行では、同時アクセス数の増加・文書の継続更新・アクセス権限管理・監視・アラート設定が加わります。外注先と本番移行チェックリストを作成し、移行前の負荷テストと認証連携の検証を確認してから切り替えることが大切です。
本番稼働後は、文書更新に伴う再インデックス化のサイクルを定めてください。文書の追加・削除・改訂が発生した際に、ベクトルDBへの反映が遅れると古い情報に基づく回答が出てしまいます。この「文書更新フロー」を運用手順書として外注先から受領しておくことが、引き継ぎ後の内製運用をスムーズにします。
内製移管を見越した技術移転の確認
外注先を選ぶ段階で、「将来的に内製チームへ移管する可能性がある」と明示しておくことが大切です。技術移転の範囲（ソースコード・インフラ構成図・運用手順書・チューニング記録）を契約書に明記してもらうことで、ベンダーロックインのリスクを低減できます。
まとめ：RAG外注を成功に導く3つの判断軸
本記事では、RAGの仕組みから工程別費用構造・外注先選定・PoCから本番移行までの進め方を整理しました。要点を3つにまとめると次のとおりです。
第一に、RAG構築費用は「データ整備の難度」と「セキュリティ要件の厳しさ」によって変わります。費用レンジは市場参考値であり、複数ベンダーからの見積もり比較が欠かせません。第二に、外注先選定では「日本語RAGの構築実績」「品質評価指標の明示」「PoC後の本番移行支援」の3軸で評価することで、精度と品質管理の水準を見極められます。第三に、PoCから段階的に進めることで失敗リスクを抑えられます。限定スコープでの検証→パイロット→本番移行という段階的なアプローチが、社内展開の成功率を高めます。
よくある質問
RAG構築の外注費用はどのくらいを目安にすればよいですか？
費用はデータ規模・品質要件・インフラ構成によって大きく異なります。市場参考値であることを前提に、PoCフェーズのみなら比較的コンパクトな構成で検証でき、本番移行・社内認証連携・高可用性対応を含む場合は費用と工期が大幅に増加します。複数ベンダーから見積もりを取得し、工程別の内訳（データ整備・構築・LLM利用料・保守）を分けて比較することを推奨します。
ChatGPTをそのまま使う場合とRAGを外注構築する場合の違いは何ですか？
ChatGPTなどの汎用LLMは学習済みの知識をもとに回答しますが、自社固有の情報（社内規程・製品仕様・過去議事録など）は含まれていません。RAGは社内文書を参照して回答するため、「根拠付き回答」と「情報の最新性担保」が実現できます。また、自社データを外部モデルに渡す際のセキュリティコントロールも、RAG構築の重要な設計要素になります。
PoC（概念実証）から本番移行まで、どのくらいの期間がかかりますか？
プロジェクトのスコープと品質要件によって変わります。PoCフェーズのみであればデータ規模が小さければ短期間で完了する場合もありますが、本番移行まで含めると、データ整備の難度や社内承認プロセスによって期間が変動します。外注先と要件定義時にマイルストーンを明確にし、各フェーズの完了条件（精度目標・セキュリティ要件など）を書面で合意することが、スケジュール遅延の防止につながります。
RAG構築の外注でデータが漏えいするリスクはありますか？
リスクはゼロではありませんが、適切な設計で大幅に低減できます。確認すべきポイントは、①文書データの保管場所（国内データセンター・プライベートクラウドなど）、②LLMへのAPI呼び出し時に外部送信されるデータの範囲、③アクセス制御と暗号化の仕様、の3点です。RFP（提案依頼書）にセキュリティ要件を明記し、外注先の回答を書面で確認してから契約することを推奨します。
RAGの検索精度が低い場合、どのような対処が有効ですか？
精度が低い場合の主な原因は「チャンク設計の不適切さ」「埋め込みモデルの選定ミス」「プロンプト設計の問題」の3点に分けられます。まずテストクエリセットで「どの質問で精度が落ちているか」を特定し、原因を切り分けることが大切です。チャンクサイズの調整・日本語特化の埋め込みモデルへの変更・プロンプトのリランキング手法の導入などが改善策として有効です。外注先とPDCAサイクルを回せる体制を契約に含めておくことで、本番稼働後の品質改善がスムーズになります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Amazon Web Services「検索拡張生成（RAG）とは」（2024年）
