社内文書や業務データを生成AIで活用する手段として、RAG（検索拡張生成）の導入を検討する企業が増えています。一方で、実際にプロジェクトを始めようとすると、次のような疑問に直面します。
- RAG構築にはどのくらいの費用がかかるのか
- PoCから本番導入まで何か月必要なのか
- どのようなデータを準備すればよいのか
- 文書だけでなく、Excelやデータベースも活用できるのか
- PoCの成功をどう判断すればよいのか
結論から言うと
この記事でわかること
- RAGの仕組みと、構築にかかる期間・費用の目安
- 費用を左右する6つの要素と、Prototype・PoC・本番開発の違い
- RAG構築を進める6つのステップ
- SQL×RAGを組み合わせた8週間のPoC事例と、成功を判断するポイント
RAGとは
RAGは「Retrieval-Augmented Generation」の略で、日本語では「検索拡張生成」と呼ばれます。ユーザーの質問に関連する情報を社内文書やデータベースから検索し、その情報をLLMに渡して回答を生成する仕組みです。
STEP 1
検索
質問に関連する情報を社内文書・DBから探す
STEP 2
コンテキスト化
検索結果をLLMへ渡す
STEP 3
回答生成
取得した情報を根拠に回答をつくる
通常の生成AIは、モデルが学習した知識だけで回答します。RAGを使えば、社内規程・製品マニュアル・技術資料・過去の問い合わせ履歴など、自社の情報を根拠に回答でき、参照元を回答と一緒に表示することも可能です。
注意
RAG構築に必要な期間
RAG構築は一般的に、技術検証 → PoC → 本番開発 → 全社展開の順に進めます。
| 開発段階 | 期間の目安 | 主な目的 |
|---|---|---|
| 技術検証・Prototype | 2〜4週間 | 限定データで検索と回答を確認 |
| 小規模PoC | 1〜2か月 | 実データで精度と有効性を評価 |
| 複合データを扱うPoC | 2〜3か月 | 文書とデータベースを組み合わせて検証 |
| 部門向け本番開発 | 2〜4か月 | 認証・権限・ログ・システム連携を実装 |
| 全社・顧客向け展開 | 4〜8か月以上 | 高可用性・監査対応・複数部門への展開 |
2〜4週間の技術検証では、対象文書と質問を絞って基本的な実現可能性を確認します。業務PoCでは、実際の利用者が入力する質問を使い、検索精度・回答内容・業務効果を評価します。データ整備や複数システムとの連携が必要な場合は、2〜3か月かかることもあります。
RAG構築の費用相場
RAG構築に一律の価格はありません。国内で公開されているRAG開発の情報をもとにすると、費用の目安は次のとおりです。
| 開発規模 | 費用の目安 | 含まれる内容の例 |
|---|---|---|
| Prototype | 50万〜200万円 | 限定データ、基本的な検索・回答 |
| 小規模PoC | 150万〜500万円 | 要件整理、データ処理、精度評価 |
| 複合データを扱うPoC | 300万〜800万円以上 | 文書・DB統合、業務適合性の評価 |
| 部門向け本番システム | 500万〜1,500万円以上 | 認証、権限、ログ、外部連携 |
| 全社・顧客向けシステム | 個別見積もり | 高可用性、監査、負荷対策 |
※市場における概算であり、BAPの提供価格を示すものではありません。実際の費用は、対象業務・データ・必要な精度・システム連携・セキュリティ要件を確認したうえで算出します。
RAG構築の費用を左右する6つの要素
| 要素 | 費用・期間への影響 |
|---|---|
| データの種類 | 文書検索のみのRAGと、Excel・DBを組み合わせるシステムでは開発範囲が異なる。構造化データはSQL検索、文書はベクトル検索など、データに合わせた設計が必要 |
| データの状態 | 古い文書・重複ファイル・複数バージョンが混在すると整理に時間がかかる。スキャンPDF・画像・複雑な表にはOCRやレイアウト解析も必要 |
| 必要な回答精度 | 一般的な社内検索と、契約・金融・品質管理などでは求められる精度が違う。重要な判断に関わる業務では、評価データの拡充や人による承認が必要 |
| アクセス権限 | 全員が同じ文書を見られる場合と、部署・役職ごとに閲覧範囲が異なる場合では設計の難易度が大きく変わる。権限要件はPoC段階から確認する |
| 既存システムとの連携 | SharePoint、Google Drive、Box、CRM、ERP、文書管理システムなどと接続する場合、API・認証・データ更新方法の設計が必要 |
| 本番導入後の運用 | 文書更新、回答品質の監視、APIコスト管理、障害対応、モデル変更への対応が必要。初期開発費とは別に月額の保守費用が発生する |
Prototype・PoC・本番開発の違い
| 段階 | 目的 | 主な成果物 |
|---|---|---|
| Prototype | RAGの基本的な仕組みが動くかを確認する | 簡易画面、限定的な検索インデックス、基本的な回答機能（業務効果や権限は評価しないことが多い） |
| PoC | 実データと代表的な質問で、業務に適用できるかを検証する | 検証用RAGシステム、評価用の質問と期待回答、精度・品質の評価結果、課題と改善案、本番構成案、本番開発の概算スケジュール |
| 本番開発 | 日常業務で安全に使い続けられるようにする | ユーザー認証、アクセス権限、操作・監査ログ、データ更新、回答品質とAPIコストの監視、バックアップ、障害対応、セキュリティ対策 |
ポイント
RAG構築の進め方：6つのステップ
対象業務を決める
「社内情報を検索できるようにする」では範囲が広すぎます。次のように具体化し、最初のPoCは1つの業務・部署・製品に絞ると評価しやすくなります。
人事規程に関する社内問い合わせ 製品マニュアルを使ったサポート回答 設備トラブルの過去事例検索 経営数値の差異分析 営業担当者の提案資料検索
データを棚卸しする
ファイル形式、文書数とデータ量、DB構造、保存場所、更新頻度、古い版や重複、個人情報・機密情報、閲覧権限を確認します。Excelの数値とPDFの業務資料では適した検索方法が異なるため、データの種類と状態を把握してから検索方式を設計します。
評価用の質問を作成する
実際のユーザーが入力する質問を用意し、それぞれに「期待する回答」「参照すべき文書」「使うべき数値」「許容できない回答」「人の確認が必要な条件」を整理します。評価用の質問がなければ、文章が自然に見えても業務で使える品質かどうかを判断できません。
検索基盤を構築する
文書はテキスト抽出・分割（チャンキング）・メタデータ付与・Embedding生成を行い、ベクトルDBに格納します。構造化データはデータ型・項目名・テーブル間の関係・集計方法を確認し、DBに格納します。
質問に応じて処理を振り分ける
質問内容を判定し、文書に関する質問はRAG検索、数値に関する質問はSQL検索、複合的な質問は両方を実行し、対象外の質問には回答しないよう制御します。手順が明確な業務は定義済みのワークフローで、質問によって手順が変わる場合はAIが処理計画を立てる方式も検討します。
検索と回答を分けて評価する
誤回答の原因が「関連文書を取得できなかった」「正しい文書は取れたが生成に失敗した」「古いデータを参照した」「計算を誤った」「根拠にない内容を加えた」「権限外の情報を取得した」のどれかを切り分けます。原因がわかれば、データ・検索ロジック・プロンプト・LLMのどこを改善すべきか判断できます。この考え方はMicrosoftのガイド「Design and develop a RAG solution」でも解説されています。
BAPのRAG PoC事例：計数管理業務での8週間
BAP Solution Japanは、日本企業の計数管理業務を対象に、RAGと生成AIを活用したPoCを支援しました。
背景・課題
複数の資料から経営数値を集め、形式を整えて集計する作業に多くの工数がかかっていました。さらに担当者は、次の業務を手作業で行っていました。
- 実績と計画の差異確認
- 過去データからの原因調査
- 改善策の検討
- 経営会議向け資料の準備
PoCの目標
- 技術面：過去の数値と関連資料を正しく取得できるか
- 業務面：AIが作成する説明や提案に十分な合理性があるか
- 最終目標：人が確認することを前提に、経営報告資料の下書きとして使える品質
8週間の開発計画と体制
プロジェクト期間は2か月（8週間）。まず日本企業から業務データの構造と使い方の説明を受け、BAPが要件を整理したうえで、機能単位で開発とテストを進めました。各サイクルで実データを使って結果を確認し、フィードバックをもとに回答方法と処理ロジックを改善。最終段階で利用環境とドキュメントを整備し、計画どおりのスケジュールで引き渡しました。
プロジェクトマネージャー 日本語で要件を整理するBrSE AIエンジニア フルスタックエンジニア インフラエンジニア
AIモデルだけでなく、業務要件・データベース・Webアプリケーション・クラウド環境まで一貫して設計できる体制です。BAPの体制については「日本企業向けのAI開発体制」でも紹介しています。
採用技術
| 領域 | 使用技術 |
|---|---|
| AI基盤 | Amazon Bedrock |
| LLM | Claude Sonnet 4.5 |
| RAG・ベクトル検索 | PostgreSQL、pgvector |
| バックエンド | Python、FastAPI、Uvicorn、Gunicorn |
| フロントエンド | React、TypeScript |
| データ | Excelなどの構造化データ、Office文書などのナレッジデータ |
※本PoCの業務要件とデータ構造にもとづく選定です。実際のプロジェクトでは、データ量・セキュリティ・既存環境・必要な精度を確認したうえでLLMとインフラを決定します。
SQLとRAGを組み合わせたシステム構成
本PoCでは、すべての質問をベクトル検索だけで処理するのではなく、質問内容に応じてSQL検索とRAG検索を使い分ける構成を採用しました。
STEP 1
データ取り込み
Office文書は解析・分割してEmbeddingとメタデータをベクトルDBへ。Excelは内容と形式を検証してPostgreSQLへ登録
STEP 2
Intent Router
質問内容を判定。定型的な質問は定義済みワークフロー、手順が変わる質問はAIが実行計画を作成
STEP 3
SQL検索
売上・計画・実績などの数値を、SQL ToolがPostgreSQLから正確に取得
STEP 4
RAG検索
業務ルールや過去の説明資料を、RAG Toolがベクトル検索で取得。参照元情報を保持
STEP 5
統合・回答
両方の結果を共通のコンテキストにまとめ、Claude Sonnet 4.5が回答と説明文を生成。参照元とあわせて提示
たとえば「計画と実績の差異を示し、過去資料を参考に原因を説明して」という質問では、PostgreSQLから数値を取得し、関連する過去資料をRAGで検索したうえで、両者を統合して回答します。文書検索だけのRAGよりも、計数管理業務に適した回答を生成できる仕組みを検証しました。
評価項目と結果
評価したのは「AIが文章を生成できるか」ではなく、「計数管理業務に使えるか」です。過去の数値を正しく取得できるか、関連資料を検索できるか、差異を合理的に説明できるか、統計データにもとづく提案ができるか、説明に説得力があるか、経営報告資料の下書きとして使えるか、担当者が確認・修正しやすい形で出力されるか――を確認しました。生成結果はそのまま経営判断に使わず、担当者が根拠を確認して修正する運用を前提としています。
8週間
計画どおりにPoC完了
SQL × RAG
構造化データと社内文書を統合
根拠を追跡
参照元を確認できる構成を実装
引き渡し完了
PoC環境と関連資料を納品
経営報告資料の下書き作成を想定した業務検証を行い、お客様からは肯定的なフィードバックをいただきました。
※工数削減率や回答精度など、確認されていない定量的な数値は成果に含めていません。
RAG PoCの成功を判断するポイント
「AIが動いた」だけでは、PoCが成功したとは言えません。精度に加えて、本番化を見据えた次の条件を確認しましょう。
品質・リスク
- 必要な文書とデータを取得できる
- 回答に根拠があり、ユーザーが確認できる
- 誤回答が起きる条件を把握できている
- 回答できない質問を適切に処理できる
- 人が確認すべき範囲が明確になっている
業務・運用
- 現行業務と比べて効果（工数削減など）が見込める
- 本番環境の費用を試算でき、許容範囲に収まる
- データ更新の方法と運用担当者が決まっている
- セキュリティ要件を満たせる
リスクの高い業務では
見積もり前に準備しておきたい情報
RAG開発会社に相談する前に、次の情報を整理しておくと、PoCの範囲と見積もりを具体化しやすくなります。
解決したい業務課題 想定ユーザー 対象の文書とデータベース データの形式と保存場所 具体的な質問例 期待する回答 必要なアクセス権限 連携するシステム セキュリティ条件 PoCで確認したい評価指標 希望する導入時期 本番後の運用体制
すべてを事前に決める必要はありません。業務課題、データの所在、実際の質問例がわかれば、最初の検証範囲を整理できます。
よくある質問
Q. RAGのPoCは2〜4週間で実施できますか？
A. 対象業務・データ・質問が明確であれば、2〜4週間程度の技術検証は可能です。実際の業務データでの評価、複数システムとの連携、詳細な精度改善まで含める場合は、1〜3か月程度が必要です。
Q. ExcelのデータもRAGで使えますか？
A. 使えます。ただし数値を正確に集計する必要がある場合は、Excelの内容をデータベースに取り込み、SQLで取得する方法が適しています。文書検索用のRAGと組み合わせれば、数値と説明資料の両方を使った回答を生成できます。
Q. RAGを導入すれば誤回答はなくなりますか？
A. 完全にはなくなりません。参照データの限定、回答への出典表示、回答不能時の制御、ルールによる検証、人による確認などを組み合わせて対策します。
Q. どのLLMを選べばよいですか？
A. 精度だけでなく、データの取り扱い、利用料金、応答速度、対応言語、クラウド環境との相性を確認して選定します。BAPの計数管理PoCでは、Amazon Bedrock上のClaude Sonnet 4.5を採用しました。
Q. RAG導入後も運用保守は必要ですか？
A. 必要です。文書・データの更新、回答品質の確認、検索設定の改善、APIコストの監視、モデル変更への対応を継続的に行います。
まとめ
- RAG構築の期間と費用は、文書数ではなく、対象業務・データの種類・必要な精度・権限・連携・運用で決まる
- 技術検証は2〜4週間、業務PoCは1〜3か月が目安
- BAPの事例では、SQL検索とRAG検索を組み合わせたPoCを8週間で完了
RAG導入では、まず対象業務と評価基準を決め、限定したデータでPoCを実施する。その結果をもとに、本番化に必要な機能・費用・運用体制を判断する――この進め方が最も現実的です。
RAG構築・生成AI PoCについてBAPに相談する
BAPは、業務課題の整理からRAGのPoC、本番開発、既存システムとの連携、導入後の運用改善まで一貫して支援します。社内文書だけでなく、Excel・データベース・既存の業務システムを組み合わせたAI活用にも対応しています。次のような段階からご相談いただけます。
- どの業務からRAGを導入すべきか整理したい
- 社内文書と数値データを一緒に活用したい
- PoCに必要な期間と体制を確認したい
- 既存システムに生成AIを組み込みたい
- PoCで止まっている生成AIプロジェクトを本番化したい
ユースケースが決まっていない段階でも、対象業務・必要なデータ・PoCで確認すべき項目から一緒に整理します。サービスの詳細は「BAPの生成AI・RAG開発サービス」をご覧ください。
