RAGシステム開発の発注/外注/依頼/委託方法について

RAGシステムの発注は、業務課題と評価基準を整理し、PoCで検証することから始まります。同じ要件で委託先を比べ、本番導入と改善へ進むと継続利用につながります。

発注形態から委託先選定、セキュリティ要件まで、発注時に決めることを順に見ていきます。全体像はRAGシステム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・RAGシステム開発の完全ガイド

AIシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。

RAGシステムを発注・外注するときの全体像

RAGは、社内文書やFAQ、規程、マニュアル、データベースから関連情報を検索し、LLMへ渡して回答を作る仕組みです。検索結果が誤る可能性があるため、回答の正確性を100%保証することはできません。

発注の対象は、生成AIモデルだけではありません。文書の準備から検索、回答生成、引用までの処理に、認証、ログ、評価、監視も含みます。

LLM単体・社内検索とRAGシステムの違い

方式ごとの違いを知っておくと、社内情報の更新方法や回答の検証に合う仕組みを選べます。

• LLM単体：一般知識で生成するため、社内の最新情報を正確に参照できるとは限りません。
• ファインチューニング：応答の傾向を調整できる一方、改訂された文書を反映するには再学習の負担が生じます。
• RAG：索引を更新して情報を差し替えられ、文書名やページ番号を回答に添えられます。

古い文書や重複した文書、表の崩れ、権限漏れ、正解データの不足があると、精度と安全性が下がります。そのため、発注する側は、検索対象外の情報と、回答できない場合の拒否方法を決めておく必要があります。

外注で納品してもらう物

発注側は、設計・設定・評価・運用に必要な資料とプログラムを納品物に含めるよう求めます。

• 設計資料：要件定義書、構成図、データ連携仕様
• 設定・評価：検索・生成の設定、評価データと結果、テスト仕様書
• 運用資料：操作手順書と運用手順書
• 変換資産：検索用テキスト変換、チャンク分割、ベクトル化、プロンプトの扱いを確認します。

デジタル庁の2026年改定資料も、変換・分割・ベクトル化のプログラムを契約で扱う考え方を示しています。そのため、発注側はソースコードや設定値、評価データについて、納品の範囲と権利を確かめます。クラウド構築手順や第三者サービス条件については、納品範囲と権利を決めておきます。

発注形態の選び方

発注形態は、カスタマイズの量と機密性を基準に選びます。加えて、既存システムとの連携や社内の保守人材の有無も、判断材料になります。

PoCと本番導入では適した選択肢が異なります。そのため、方式を分けて比べる方法が有効です。

既製パッケージやクラウド基盤を利用する場合

発注側は、標準機能で要件を満たせるかを確かめ、サービス利用と追加開発の範囲を決めます。

• 選択肢：既製RAG、AWS Bedrock、Microsoft Azure、Google Cloudは、短期検証に使えます。
• 工数：文書登録、検索、画面、モデル接続を標準機能でまかない、開発を抑えられます。
• 適する用途：社内FAQなど、業務範囲が明確で標準連携で足りる場合
• 追加開発：複雑な権限、独自業務、リアルタイム連携、閉域要件は個別対応になりやすいです。

契約前には、データの保管場所と、モデルへの入力や学習利用の扱いを確認します。さらに、解約時の出力や従量課金、仕様変更も、契約の段階で確かめておきます。

個別開発やOSSを組み合わせる場合

発注側は、独自業務や権限への適合と、OSS・閉域環境の保守負担を合わせて判断します。

• 柔軟性：検索の仕組みやチャンク、再ランキング、モデル、画面、認証まで設計できます。
• 既存連携：ファイルサーバーやSharePoint、ERP、CRMなどを横断して扱えます。
• OSS保守：脆弱性への対応、更新、品質監視、障害対応を、自社か委託先が担います。
• 閉域構成：GPU、ネットワーク、バックアップ、冗長化の設計まで含みます。

OSSを使うと、ベンダー依存を抑えられる可能性があります。一方で、オンプレミスや閉域では、クラウドAPI構成と比べて初期費用と運用負担が増えやすいです。

PoCと本番開発を分けて発注する場合

初めて導入するときは、2〜6週間程度の小規模PoCを行い、本番へ移す判断材料を揃えます。

• 検証：質問への引用、権限外情報の遮断、回答拒否を、実データで測ります。
• 契約：本番を同じ会社へ随意発注する前提を置きません。
• 成果物：評価質問、正解文書、検索設定、課題一覧、改善提案を含めます。
• 再利用：評価結果を次のRFPに使い、別の会社との比較にも役立てます。

見栄えや担当者の印象だけを成功条件にすると、本番に移った後で、権限や運用の課題が見つかりやすくなります。

RAGシステム開発の発注を進める手順

発注は、課題とデータの整理から、提案の比較、実データでの検証、本番導入へと段階を踏んで進みます。

1. 業務課題、成功指標、検索対象データの整理
2. 要件をまとめたRFPを渡し、提案と見積を比べる
3. PoCで実データの検索精度と業務効果を検証する
4. 本番導入後、ログをもとに運用と精度を改善する

RAGの成否は、モデルの選択だけでなく、業務、情報システム、セキュリティ、データ管理の担当者を早く巻き込めるかにもかかっています。

業務課題と成功指標の設定

「RAGの導入」そのものを目的にせず、解決する業務と成功指標を先に定めます。

• 業務例：ITヘルプデスク、保守マニュアル、営業提案書、規程の問い合わせ
• KPI：根拠適合率や拒否率、回答時間、再質問率、月間削減工数を組み合わせて使います。
• 評価セット：質問と、期待回答、正解文書と版、利用者権限を結びつけたもの
• 件数目安：実際の質問を50〜200問程度集め、各社を同じ条件で比べます。

その件数は必須ではなく、業務の種類と文書量に応じた目安です。ただし、共通の評価セットがないと、各社の価格と品質を公平に比べられません。

検索対象データの洗い出し

発注側は、対象文書の形式と状態、連携方法、更新後の管理責任を洗い出します。

• データ属性：形式、容量、頻度、管理部署、機密区分、利用者を整理します。
• 抽出方法：テキストとスキャンPDFを区別したうえで、Excelや図表の意味を保つ
• 連携条件：既存システムとの接続方式
• 文書管理：所有者、更新責任者、現行版、重複の扱い、改訂・廃止時の処理
• 運用手順：再インデックス、回答への版数表示、定期確認を要件にする

連携先として確認するのは、SharePoint、ファイルサーバー、Box、文書管理システム、基幹データベースです。あわせて、APIの有無、更新通知、削除反映、権限の取得方法を調べます。

古い規程が残っていると、検索方式に問題がなくても誤回答につながります。そのため、運用部門は毎月、または改訂のたびに確認します。

PoCから本番・運用への段階的な移行

PoCで方式を比べたうえで、本番に必要な機能と改善方法を、段階を踏んで準備します。

• PoC：代表データ1〜2種類で、検索方式、チャンク、メタデータ、プロンプト、モデルを比べます。
• 評価：引用、根拠の有無、権限、許容できる応答時間を確かめます。
• 本番：SSO・IAM、ACL、監査ログ、障害通知、バックアップなどを追加します。
• 改善：ログから未回答や誤回答を探し、文書、チャンク、検索、回答文を見直します。

本番では、再インデックスとモデルの切り替えに備え、利用状況が見える状態にします。問い合わせ窓口も用意します。そのうえで、精度改善を保守契約に含めるか、月次の作業時間を別に確保するかを決めます。

RFPと要件整理の内容

RFPは機能の一覧にとどまらず、背景や業務、利用者、データ、セキュリティ、既存環境を共有するものです。納期や予算、評価、契約条件も伝えることで、提案と見積の差を小さくできます。要件をMUST、SHOULD、WANTに分けると、予算を超えたときに削る範囲を判断しやすくなります。

業務要件と利用者の具体化

誰が、どの場面で何を質問し、どんな回答を求めるかを記載します。たとえば、営業担当者による過去提案書の検索、工場保全担当者による設備マニュアルの検索、総務担当者による就業規則の確認が挙げられます。

また、所属や役職、顧客・案件との関係、閲覧できる文書の範囲も整理します。全社で共通か部門別かによって、認証と検索フィルターが変わります。

回答を顧客へ直接送るのか、担当者が確認してから使うのかによって、承認画面や監査ログの必要性も変わります。

データ・検索・評価要件の明記

データ、検索、評価の要件を具体化し、納品後に合否を判定できる状態にします。

• データ：種類、件数・容量、頻度、形式、OCR、表・画像、メタデータ
• 連携：連携先と、削除反映の期限を示す
• 検索：方式、再ランキング、フィルター、表示件数、引用方法の取り決め
• 評価：検索・回答・引用、拒否、権限分離、応答時間の測定
• 試験：曖昧さ、旧文書、権限外、悪意ある指示への質問を使い、合格基準を定める

文書を更新してから検索に反映されるまでの時間は、求める情報の最新性に関わります。また、基準に届かなかった場合の追加改修費もRFPに書き、検収時の争いを減らします。

セキュリティ・連携・運用の責任分界

関係者ごとの役割を明確にするため、前提と分担を次のとおり整理します。

• 環境：クラウド、閉域、オンプレミス、ハイブリッドの前提
• 保護：保存場所、暗号化、学習利用、ログ期間、管理権限を確認します。再委託と事故通知も確認の対象です。
• 連携：API、移行、SSO、ネットワーク、既存改修の担当の分け方
• 責任分界：発注者、開発会社、クラウド会社、既存保守会社の役割を図に表す

デジタル庁の調達チェックシートは、検索先の権限不備による要機密情報の出力対策を確認項目にしています。また、文書整理、権限連携、更新通知、テストデータは、追加費用になり得ます。

契約形態と見積範囲の決め方

発注の時点で、データ品質や最適な検索方式が決まっていないことは珍しくありません。そのため、PoC、要件定義、本番開発、運用改善を一つの契約にまとめず、分けて発注する方法が安全です。

完成条件が明確な工程は請負、調査や改善を伴う工程は準委任とするなど、成果の確定度に応じて組み合わせます。

請負契約と準委任契約の使い分け

完了条件と報告内容は、請負か準委任かに合わせて決めます。

• 請負：完成と検収を行い、画面、認証、登録、検索、引用、管理機能の条件を定める
• 変更：仕様変更の手続きと追加費用の合意
• 品質評価：評価セット、測定法、対象データ、許容できる未回答率を定義します。
• 準委任：調査、データ整備、検索調整、精度改善、運用支援で使う
• 定期成果：作業時間・体制・会議、評価報告、課題、変更履歴、翌月計画の合意

RAGでは回答品質を完全に保証できません。そのため、「正答率100％」のような曖昧な条件を避け、測定できる基準を契約に置きます。

データ・成果物・知的財産の扱い

契約では、データや成果物の権利と、契約終了後の利用範囲を整理します。

• 対象資産：文書、加工テキスト、埋め込み、索引を分けます。プロンプト、評価データ、ログも別に扱います。
• コード・設定：ソースコードとクラウド設定の所有権と利用権を定めます。
• 再利用・移行：汎用コードと個別成果物を分けたうえで、契約終了後の利用範囲を決めます。
• データ利用：学習・品質改善への利用、保存期間、再委託先、削除証明
• 基盤変更：将来の変更に備え、特定のサービスに閉じない構成とデータの出力方法を定めます。

個人情報や営業秘密は、利用目的や第三者提供・委託、越境移転の扱いを、法務・情報セキュリティ部門と確認します。事故報告、秘密保持、監査権限も、あわせて確かめます。

RAGシステムの費用相場とコストの内訳

費用は、文書量、形式、利用者数によって変わります。連携先や権限管理、セキュリティ、評価・運用の範囲も、費用を左右します。

この節の数字は、2026年公開の複数社資料と一般的な業務システム開発の工数を照合した目安で、公的な一律相場や固定価格ではありません。

PoCから本番までの費用レンジ

各社資料と類似する業務システムの工数をもとにした目安は、次のとおりです。既製RAGの公開例は初期20万円前後からで、クラウドやモデルの利用料は別途かかります。

• 小規模PoC：1業務・1〜2種類の文書が対象で、50万〜300万円程度です。
• 拡張PoC：OCR、分類、部門権限、連携を含めると、300万〜800万円程度になります。
• 本番：標準は300万〜1,500万円程度、複数部門・複数データソース・厳格な権限や監査を含むと1,500万〜3,000万円以上です。
• 大規模案件：閉域、GPU、マルチモーダル、基幹連携、冗長化を含む場合は、3,000万〜1億円規模の例もあります。
• ルートチーム資料：PoC50万〜200万円、軽量本番300万〜500万円、全社展開500万〜1,500万円以上です。

ソフィエイトの資料も、データ整備や権限検証を含むPoCと、複数部門への展開の費用を示しています。

これらの金額は各社の見積もりの目安で、公的統計ではありません。また、費用は作業範囲、データ整備、評価の深さによって変わります。

見積書で確認する開発費の内訳

「AI開発一式」とだけ書かれた見積もりでは、作業範囲や追加費用が分かりません。そのため、費目と数量を分けて見積もってもらいます。

• 企画・開発：企画、要件定義、画面、認証・権限、導入支援
• データ整備：クレンジング、OCR、索引、表・画像の構造化、重複・旧版の整理
• 連携・試験：既存連携、評価、テスト、セキュリティ検証を分けて記す
• 数量：文書種・容量、連携・利用者・質問・環境の数、納品物、会議回数を示す

権限付与や定期取得も、データ整備に含まれます。認証基盤、ネットワーク、文書管理システムを変える場合には、相手側の改修費やテスト調整費が加わる可能性があります。

月額運用費とクラウド・モデル利用料

運用作業と従量課金は分けて考え、通常月と繁忙月の利用量を仮定して試算します。従量課金の単価は、Bedrockではモデル別に入力・出力トークン、バッチ、推論方式、埋め込みで異なり、Google Cloudではモデルと品質設定で異なります。

• 運用：文書更新、精度改善、障害対応、監視、バックアップ、脆弱性対応
• 基盤利用：検索、ストレージ、ログ、LLMの入出力、埋め込み生成
• 保守相場：公開資料では月10万〜80万円程度、別の資料では月20万〜80万円程度
• 従量料金：利用したトークン量などに応じて課金されます。
• Google料金例：モデル最適化チャットは、入力が100万トークンあたり約0.16〜1.89ドル、出力が約0.63〜7.50ドルです。

出典：Google Cloud Vertex AI生成AI料金表（2026年確認）。料金は、モデル、リージョン、契約によって異なります。

AWSの料金ページは、一部のモデルに2026年8月31日までの期間限定価格を案内しています（出典：AWS Amazon Bedrock料金表、2026年8月確認）。

試算に使うのは、月間の質問数、平均の入出力トークン、再検索の回数、埋め込みの更新頻度です。また、利用料を保守費に含めるか、発注者が直接契約するかも決めます。

監視のみか、毎月の評価と改善まで含むかによって工数が異なります。対応時間と作業内容も、あわせて比べます。

委託先選定と見積比較のポイント

委託先は、生成AIのデモができる会社としてではなく、業務データを扱うシステムインテグレーターとして比べます。

自社に近い事例や評価方法、権限連動、既存連携について、同じ質問で確かめます。運用体制、契約、納品物についても、各社に同じ問いを投げかけます。

自社データでの実績と評価方法

導入実績の有無だけでなく、どのような条件での実績か、運用後にどう改善したか、同じデータでどう評価したかを確認します。

• 実績条件：業務、文書量、利用者数、検索方式、残った課題
• 改善内容：運用後に何を改善したかを確かめる
• 同条件評価：匿名化した質問・文書で、根拠、拒否、表・画像、応答時間を試します。

NTTデータは2025年、碧海信用金庫へ、独自情報を文書ストアに格納して回答するRAG機能付きサービスを導入しました。対象は、金庫内で毎日約4,000件発生する問い合わせの効率化です。

出典：NTTデータグループ「碧海信用金庫がNTTデータの生成AI活用サービスを導入」（2025年）。

金融機関のセキュリティ要件や根拠文書の扱いを確認し、自社に応用できる点を聞きます。

同じRFPでの見積比較

強みの異なる会社へ同じRFPを渡し、作業範囲と費用を同じ基準で比べます。

• 候補：業務連携、クラウド、閉域・セキュリティの強みを比べます。
• 比較：3社程度の機能、整備、評価、運用、契約、費用を確認します。
• 費目：初期、PoC、本番に分けます。連携、クラウド・モデル、保守、改修単価も、別々に示してもらいます。
• 見積条件：「含む・含まない・前提・追加単価」の明記

低価格の案では、データ整備やセキュリティ試験が抜けている場合があります。一方で、高額な案に不要なマルチモーダル対応や閉域基盤が含まれている場合もあります。

失敗リスクと発注前の確認事項

デモの段階で、更新、権限、安全性、障害対応の具体策を質問します。

• 削除反映：文書の削除が検索に反映されるまでの時間を確認します。
• 権限・引用：取得元、検索時の絞り込み、引用文書と版を聞く
• 回答拒否：根拠がない場合に拒否できるかを確かめる
• 安全性試験：間接注入や権限外情報の抽出方法
• 障害対応：一次対応者と、精度悪化を検知する指標

IPAは2025年、RAGのレッドチーミング手順を含むガイドを改訂しました。試験の対象には、悪意ある文書による間接注入、権限外情報の抽出、出力安全性、外部ツールの意図しない操作も含まれます（出典: IPA・AIセーフティ・インスティテュート「AIセーフティに関するレッドチーミング手法ガイド」、2025年）。

2026年のRAG発注で追加すべきセキュリティと最新要件

2025〜2026年のRAGでは、図表や画像を扱うマルチモーダルRAGや、複数データを横断するハイブリッド検索が広がっています。また、複数段階の処理を行うAgentic RAGもあります。

新機能は、必要性を見てから選びます。そのうえで、データ形式、モデル変更、検索基盤の移行、監査ログの保存は、将来の拡張に備えて発注条件に入れておきます。

ACL・SSO・ログの必須要件

画面で利用者を制限するだけでなく、検索時の文書権限の照合と回答履歴も設計します。

• 権限照合：所属、役職、案件、顧客の権限を、利用者情報と照合する
• 検索除外：文書・チャンク単位のACLで、権限外の情報を除く
• ログ項目：利用者、質問、文書IDと版、回答を残します。拒否理由、修正、モデルとプロンプトの版も残します。
• ログ管理：機密を含む場合の閲覧権限、保存期間、マスキング、削除

生成後に機密語を消しても、モデルの文脈への混入は防げません。そのため、業務判断や顧客説明に使う場合は、根拠を確認する画面と人の承認履歴も用意します。

最新動向を踏まえた要件の絞り込み

新機能の効果と、評価・権限・障害対応にかかる負担を比べて、導入する範囲を決めます。

• 段階導入：まずテキスト検索と根拠表示で、業務効果を確かめる
• 追加機能：図表やエージェントは、価値と安全性の試験計画を見て選ぶ
• 更新運用：改訂日、更新失敗の通知、所有者の承認、定期評価を要件とする

経済産業省とIPA・AISIのAI事業者ガイドライン第1.2版は、RAGの検索・参照データの最新性と信頼性に留意するよう示しています（出典：AI事業者ガイドライン検討会、2026年3月31日）。そのうえで、技術の新しさより、安全に継続して使えるかを基準にします。

よくある質問（FAQ）

発注では、費用だけでなく、社内データの扱いや本番運用の責任範囲も疑問になりやすいです。

RAGシステムの外注費用はいくらですか？

小規模PoCは50万〜300万円程度、データ整備や権限検証を含むPoCは300万〜800万円程度、本番導入は300万〜1,500万円程度が目安です。

複数部門や閉域、オンプレミス、厳格な監査が加わると、1,500万〜3,000万円以上になる可能性があります。これは公開資料に基づく幅です。

費用は、文書量、利用者数、連携数、セキュリティ要件に応じて、個別に見積もられます。

社内の機密文書をRAGで扱っても安全ですか？

安全性は、製品の名称だけでは決まりません。保存場所やモデル提供者のデータ利用条件、認証、文書単位のACLで決まります。ログや暗号化、回答拒否、監視も、安全性を左右する要素です。

個人情報や営業秘密を扱う場合は、匿名化やマスキング、最小権限を、契約と設計の両面で確認します。学習利用や削除、委託先と再委託先、事故通知も、契約と設計の両方で確かめます。

RAGのPoCだけ先に外注してもよいですか？

はい。初めての導入では、PoCを分ける方法が有効です。実データと質問を使い、検索精度、引用、権限、回答拒否、応答時間、業務削減効果を評価します。

また、成功条件、評価セット、成果物、本番移行時の再利用範囲、追加開発の扱いを、契約前に決めておきます。

RAGの委託先は何社くらい比較すべきですか？

同じRFPを3社程度に渡し、提案と評価方法、責任分界を比べる方法が現実的です。さらに、開発費、クラウド費、モデル費、保守費も、あわせて比べます。

比較の数を増やしすぎると、確認に時間がかかります。そのため、自社に近い実績や必要なセキュリティ、既存連携、PoC後の運用体制を満たす会社に絞ります。

最安値の会社ではなく、作業範囲と本番後の改善責任が明確な会社を選びます。

まとめ

発注の対象は、チャット画面に限りません。データ整備や検索品質、根拠表示まで含みます。さらに、権限連動や既存連携、セキュリティ試験、運用改善も対象になります。

まず、業務課題と成功指標、対象データを整理し、MUST/WANTを分けたRFPを作成します。

発注前の優先事項

PoCと本番を分ける場合は、評価質問と成果物を契約に含め、請負と準委任を工程ごとに使い分けます。

費用は、小規模PoCで50万〜300万円程度、本番で300万〜1,500万円程度です。複数部門、厳格な権限、閉域要件を含めると、1,500万〜3,000万円以上になり、要件によって幅が出ます。

公開資料に基づく目安として捉え、前提をそろえたうえで見積もりを比べます。

委託先を比較するときの結論

委託先は、デモの有無だけでなく、自社データでの評価や文書の更新・削除、権限外情報の遮断について説明できるかで選びます。根拠表示やレッドチーミング、障害対応、基盤移行の説明も求めます。

3社程度に同じRFPを渡し、価格と機能に加えて、除外作業、納品物、データ・成果物の権利、保守責任を比べると、本番で使える仕組みに近づきます。

▼全体ガイドの記事
・RAGシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。