自社RAGシステム構築代行：依頼前に確認すべき要件定義チェックリスト
本記事の費用レンジは、AI開発各社が公開している2025〜2026年の費用事例（gxo.co.jp 2026年4月ほか）をもとに整理した目安です（2026年6月時点）。 相場は変動が速いため、意思決定前に各ベンダーの最新見積もりを直接確認してください。LLM API単価も各LLMプロバイダの公式ページで最新の料金を確認してください。
上から「社内文書をAIで検索できるようにしてほしい」と言われ、開発会社に問い合わせた。「要件を教えてください」と返ってきた。何を伝えればいいのか、正直なところよく分からない。
この状況に心当たりがあるなら、この記事はその担当者のために書いています。
生成AIプロジェクトの多くがPoC後に本番化されず断念される、という調査・報告が複数あります。失敗の多くは、LLMの精度やベンダーの技術力の問題ではありません。発注前の要件定義が曖昧なまま進んだことで、PoCの評価基準が定まらず、承認も取れず、形骸化していくという構造的な問題です。
この記事では次の3点を整理します。
- RAG外注の費用レンジの実態と「相場の幅の大きさ」が意味すること
- 発注前に確定すべき要件定義7項目のチェックリスト
- 外注RAGが失敗する原因の分類と、発注前に防げるかどうかの判定
RAG外注の相場——「いくらかかるか」より「何に払うか」
見積もりを取ると、同じ要件でも100万円と500万円という回答が来ることがあります。これは「ベンダーによる差」というより、「要件の曖昧さがそのまま見積もりの揺れとして現れている」状態です。要件が固まれば、見積もりの幅は自然と縮まります。
フェーズ別の費用レンジ（2026年6月時点）
RAG外注の費用は、フェーズによって大きく異なります。
| フェーズ | 費用レンジ |
|---|---|
| PoCフェーズ | 50〜300万円 |
| 部門向け本番構築 | 200〜1,000万円 |
| 全社展開 | 800〜3,000万円超 |
| 月額運用 | 10〜100万円/月 |
出典: gxo.co.jp（2026年4月・PoC 100〜300万円）ほかAI開発各社の公開費用事例をもとに整理。
PoCフェーズだけで50〜300万円という6倍の幅があります。この幅の正体が「要件の曖昧さ」です。ユースケースが1つに絞られているか、対象データの品質が確認されているか——この差が、見積もりを50万円と300万円に分けます。
内訳4項目——従業員300名規模・情シスFAQ検索の場合
gxo.co.jp（2026年4月）が公開している、従業員300名・社内FAQ検索を対象とした具体的な費用内訳です。
| 工程 | PoC（2週間） | 本番構築（3ヶ月） |
|---|---|---|
| データ整備 | 40万円 | 150万円 |
| ベクトルDB構築 | 10万円 | 60万円 |
| UI開発 | 30万円 | 250万円 |
| 認証・権限管理 | 含む | 80万円 |
| テスト・チューニング | 20万円 | 60万円 |
| 合計 | 100万円 | 600万円 |
| 月額運用 | — | 約20万円/月 |
出典: gxo.co.jp/column/rag-implementation-cost-breakdown-2026（2026年4月）
注目すべきはデータ整備の比率です。PoCで40万円・本番で150万円を占めています。「PDFがある」だけでは不十分で、OCR処理・書式統一・古い情報の分離という作業が発生するためです。対象データの状態を事前に確認していないと、この費用が後から積み上がることになります。
LLM API単価——費用の主役ではない
RAGのランニングコストとしてLLM APIの費用を心配する声がありますが、月1,000クエリ程度の社内利用であれば、APIコストは月数百〜数千円規模に収まることが多いです。費用の大半はデータ整備とUI開発に偏ります。モデル別の正確な単価は変動が速いため、各LLMプロバイダの公式ページで最新の料金を確認してください。「LLMのコストが怖い」という理由でPoC予算を抑えることより、データ整備と要件定義に工数をかける方が、結果的に総費用を下げます。
発注前に確定すべき要件定義7項目
1. ユースケースを1つに絞る
「社内のQAをAIで」という要件では、外注先が設計できません。社内FAQ検索・マニュアル検索・カスタマーサポート・契約書レビュー・営業支援では、最適なアーキテクチャが異なります。誰が・何を・どんな場面で質問するかを1ユースケースに限定することが、要件定義の起点です。
絞り込まないと見積もりが膨らみ、PoCの評価基準も曖昧になります。「使えそう」という感想でGo/No-Goを判定することになるため、本番移行の稟議が通りません。
2. 対象データを棚卸しする
以下の項目を確認し、外注先に渡せる状態にしておきます。
- データ形式: PDF・Word・Excel・Webページ・DBテキスト
- 件数・総ページ数・推定文字数: ベクトル化（テキストを数値に変換してDB格納する処理）のコストに直結します
- 更新頻度: 日次・月次・静的か——インデックス更新の仕組みが変わります
- データ品質: スキャンPDFでOCRが必要か・書式が統一されているか・古い情報と新しい情報が混在していないか
- 機密性レベルの事前分類: 何をナレッジベースに含め、何を除外するかを先に決めます
このリストがない状態で発注すると、データ整備費が後から積み上がります。
3. 精度要件を数値で決める
PoCの「良かった・悪かった」を言語化するためには、事前に数値基準が必要です。
- 正答率の目標値: 例「関連する回答が返ってくる率80%以上」
- 応答時間の上限: 例「3秒以内」
- ハルシネーション（事実と異なる内容を生成するLLMの性質）の許容度: 法務・医療・財務では許容度ゼロが原則。社内FAQであれば許容度を高めに設定できます
PoCのGo/No-Go判定基準を経営層と数値で事前合意してから発注することが重要です。この合意がない状態でPoCを終えると、「もう少し様子を見よう」という判定が続き、本番移行の意思決定ができなくなります。
4. セキュリティ・コンプライアンス要件を確認する
このセクションが「クラウドAPI型かセルフホスト型か」の分岐になります。
- クラウドLLM使用可否: OpenAI APIやClaude APIに社内データを送信してよいか——情報セキュリティポリシーで確認が必要です
- データ保存場所: 国内クラウド限定か・VPC（仮想プライベートクラウド）隔離が必要か
- オンプレミス要件: 機密情報がある場合はLlama・Mistralといったローカルで動くOSSモデルの検討が必要です。この場合はGPUサーバーの選定が別途発生します（ローカルLLMサーバーのGPU選定については別記事で詳しく解説しています）
- アクセス制御: 部門別・役職別で参照できる文書を分けるか
- 監査ログ: 誰がいつ何を質問したかの記録が必要か
- NDA締結とデータ取り扱い契約の整備
クラウドAPIに社内データを送信するか、自社内で完結させるかによって、コスト構造とベンダー選定の軸が大きく変わります（クラウドAPIとセルフホストのコスト比較については以下の記事が参考になります）。
5. 既存システムとの連携範囲を決める
Slack・Teams・社内ポータル・kintone・Salesforceなどとの連携が必要かどうかを、発注前に確定します。連携範囲を曖昧にすると、後から追加見積もりが発生します。
連携先1システムあたり数十万〜150万円規模が追加費用の目安になります。SSO・社内認証との連携、既存DBとのリアルタイム同期が必要かどうかも、この段階で確認します。
6. 導入後の運用体制を決める
- 誰が精度モニタリング・データ更新・改善を担当するか
- 外注先に運用まで委託するか・内製化するか
- 年間保守費の目安: 初期費用の20〜30%/年
運用担当者を決めずに導入すると、数ヶ月で形骸化します。これは技術の問題ではなく体制の問題です。「だれかが使えばいい」という状態のままでは、精度の改善もデータの更新も止まります。
7. PoCを先行させ、Go/No-Go基準を経営層と合意する
本番構築への移行判断は、PoCの結果をもとに経営層が行います。そのため、次の2点を発注前に決めておきます。
- PoCのGo/No-Go判定基準（項目3で設定した数値）を経営層と文書で合意する
- 本番構築への移行予算を承認プロセスに載せるタイミングを決める
PoCなしで本番発注すると、要件のズレが本番フェーズで判明し、手戻りコストが跳ね上がります。PoCは「試してみる」ためでなく「本番移行の判断根拠を作る」ために行うものです。
外注RAGが失敗する原因の分類
RAG導入の各種調査では、導入後に十分な成果を得られたと評価する企業は一部にとどまり、失敗要因は「回答品質」「データ連携」「運用体制」に集中するという報告が複数あります。
各パターンが「発注前に防げたか」という観点で整理すると、次のようになります。
| 失敗パターン | 原因分類 | 発注前に防げるか |
|---|---|---|
| 要件が曖昧なまま発注 | 設計 | 防げる（項目1） |
| データ品質の過信 | データ | 防げる（項目2） |
| PoCなしで本番発注 | プロセス | 防げる（項目7） |
| Go/No-Go基準が曖昧 | 設計 | 防げる（項目3） |
| ベンダーロックイン | 設計 | 防げる（要件定義時にデータ・モデルの可搬性を明記する） |
| 運用担当者の不在 | 体制 | 防げる（項目6） |
| 情報漏洩リスクの確認漏れ | セキュリティ | 防げる（項目4） |
技術面では、2024年のarXiv論文「Seven Failure Points When Engineering a RAG System」（arXiv:2401.05856）が、RAGの失敗パターンを体系的に整理しています。技術的な失敗の多くはLLMそのものではなく、インデクシングやストレージなどデータ整備・設計の段階で発生するとされています。モデルの性能を上げるだけでは解決しない問題が、データ整備と設計の段階に集中しているということです。
発注前チェックリスト一覧
以下の7項目が揃っているかを確認してから、外注先への問い合わせに進みます。
- ユースケースを1つに絞った — 「誰が・何を・どんな場面で」が1文で言える状態でないと、外注先との認識ズレが起きやすいです
- 対象データを棚卸しした — 形式・件数・更新頻度・品質・機密性レベルの5点が未整理のままでは、データ整備費が後から積み上がります
- 精度要件を数値で決めた — 正答率・応答時間・ハルシネーション許容度の目標値がないと、PoCのGo/No-Go判定ができません
- セキュリティ・コンプライアンス要件を確認した — クラウドLLM使用可否・データ保存場所・アクセス制御が未確認だと、設計後に方向転換が必要になります
- 既存システムとの連携範囲を決めた — 後から連携を追加すると、1システムあたり50〜150万円規模の追加費用が発生します
- 導入後の運用体制を決めた — 担当者が決まっていない状態での導入は、数ヶ月以内の形骸化リスクが高いです
- PoCのGo/No-Go基準を経営層と合意した — この合意がない状態でPoCを終えると、本番移行の意思決定が止まります
全項目が揃っていない状態での発注は、PoC後の方向修正コストが膨らみます。揃っていない項目がある場合は、その項目を確定してから問い合わせに進む方が、最終的な総費用を下げます。
まとめ——要件定義は外注先のためではなく、発注者自身の保険です
要件定義は「準備が大変だからやらない」という選択肢ではありません。やらない方が、後から費用と時間が増える構造になっています。
見積もりの幅が大きい理由も、PoCが失敗する理由も、多くの場合は要件の曖昧さです。PoC100万円が無駄になるのは、LLMの精度が足りなかったからではなく、何をもって「成功」とするかが決まっていなかったからです。この損失は、事前の要件定義1〜2週間の工数で回避できます。
要件定義の段階から相談を受け付けています。「まだ要件がまとまっていない」という状況でも問題ありません。整理の仕方から一緒に確認します。