RAGシステム開発の進め方/やり方/流れや方法/手法/工程/手順

RAGシステムの開発は、対象業務と正解データの整理から始まり、方式・基盤の選定、設計・開発へ進みます。その後、評価テスト、稼働、定着の順で進めると、回答品質と安全性を継続して高められます。

RAGの仕組みや費用の目安は、この記事の中で具体的に示します。

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

AIシステム開発の工程ごとの進め方と注意点については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。

RAGシステム開発の全体像

RAGは、質問に関連する社内文書やデータを検索し、その結果を文脈としてLLMに回答させる仕組みです。社内情報をLLMに追加学習させる方式とは違い、質問に応じて必要な情報を取り出して渡します。

回答品質は、モデルの性能に加えて、検索対象データの質、チャンク分割、権限設定で決まります。また、引用方法や評価データの品質も、あわせて問われます。

RAGシステムの仕組み

RAGは、文書を集めてOCR処理し、メタデータを付けてチャンクに分割する業務システムです。分割した文書は検索インデックスに登録され、質問に応じて関連箇所を取り出し、LLMへ渡します。

一般的には、文書を扱う部分、検索と生成の部分、運用と評価の部分が連携します。

• データ処理：文書の保管から、OCR、メタデータ、チャンク分割までを受け持ちます。
• 検索と生成：埋め込みモデルやベクトル検索、キーワード検索、ハイブリッド検索を使い、リランキングを経てLLMが回答を作る部分
• 運用と評価：根拠表示やログ、評価・監視の組み合わせ

用途には、社内規程や製品マニュアルの検索、営業提案の支援などがあります。さらに、保守履歴の照会や、問い合わせへの回答案の作成も含まれます。

回答には、文書名、ページ、改訂日などを添えます。

根拠がない場合は「分かりません」と返す条件を設けると、LLM単体より検証しやすくなります。

LLM単体や社内検索ではなくRAGを選ぶ場面

回答に使う自社情報が頻繁に更新される業務では、RAGが候補に挙がります。

製品仕様や社内規程の改訂が多い場合は、モデルを再学習させるより検索インデックスを更新するほうが、運用しやすいことがあります。

一方で、公開情報を単純に要約するだけなら、通常の検索やLLMで足りる場合もあります。そのため、RAGを作ること自体を目的にせず、業務上の必要性を先に確かめます。

• 対象業務：問い合わせの一次回答時間を半分にするなど、効果を測れる業務
• 検索時間：マニュアル検索を10分から2分へ短縮するなど、数値で測る指標
• 比較条件：利用者数や文書量、更新頻度を並べます。機密度や連携、正答率と回答時間、削減工数も一覧にします。

この条件を揃えておくと、パッケージやクラウド、OSS、スクラッチを同じ条件で比べられます。

RAGシステムの進め方と6フェーズ

RAGシステムの開発は6フェーズに分けて進め、要件整理から定着までの各段階で完了条件を決めます。

評価や教育は省かずに進めることが大切です。

期間の目安として、小規模PoCは2〜6週間程度です。

本番導入は、要件と連携範囲によって2〜4か月程度から始まります。

複数部門の利用や基幹連携、閉域環境を含む場合は、4〜9か月以上かかることもあります。

評価や教育を削ると、本番後の精度改善にかかる費用が増えるおそれがあります。

フェーズ1：要件整理で定める対象業務と正解データ

対象業務と正解データは、情報システム部門に加えて、実際に質問する現場の担当者へ聞き取りながら決めます。そのうえで、誰がどの文書をどの頻度で使い、何を判断するのかを確認します。

• 業務と効果：問い合わせ件数と回答時間、誤回答の影響
• 対象候補：社内ITヘルプデスクや営業FAQ、保守マニュアルなどのうち、正解と効果を測りやすい業務
• 文書の洗い出し：所有者と改訂日、機密区分、権限を調べます。形式や重複、廃止文書、更新責任者も確認します。
• 要件と成果物：業務フローや機能・非機能要件をまとめます。データ一覧と権限表、更新ルール、評価質問集も、一式にそろえます。

必須要件と希望要件を分けたうえで、根拠表示と回答拒否を必須にするかを決めます。

利用者認証、監査ログ、削除反映についても、必須かどうかを決めておきます。

フェーズ2：選定で比べる方式・モデル・検索基盤

方式として、既製のRAGパッケージやマネージド基盤、OSSと自社クラウドを比べます。閉域・オンプレミス方式も、比較の対象にします。

たとえば、マネージド基盤には、AWS BedrockやAzure AI Searchなどがあります。

短期間で始める場合は、パッケージが候補になります。ただし、複雑な権限や基幹連携に制約がないかを確かめます。

• 運用負担：マネージド基盤は運用負担を抑えやすい一方で、サービス料金の確認が要ります。
• データと移行：データの所在と、将来の乗り換え条件
• デモ評価：同じ質問集とサンプル文書で、根拠表示と回答拒否を試します。権限遮断と削除反映も確かめます。
• 検索方式：型番や規程番号に強いキーワード検索、表記揺れに強いベクトル検索、ハイブリッド検索の比較

提案書では、各機能が標準機能か、設定で対応するか、追加開発が必要か、対応不可かを分けて示してもらいます。

選定では、回答の自然さに加えて、実データで必要な機能が動くかも確かめます。

フェーズ3：設計・開発で作るデータと権限の境界

文書の取り込みから回答までのデータの流れを図に描き、各処理の入力と出力を決めます。

処理は、文書を集めてOCRで読み取り、メタデータを付けてチャンクに分けるところから始まります。その後、埋め込みを作ってインデックスに登録し、検索とリランキングを経て、プロンプトとLLMで回答を作ります。最後に、根拠表示とログ保存まで含めます。

• 文書品質：PDFの見出しや表が崩れる場合は、チャンクサイズとページ情報の持たせ方を先に検証します。
• 権限連動：部門や役職などの属性を、検索条件に反映します。顧客や案件、拠点の属性も、検索の条件に入れます。
• 非機能要件：SSOや文書単位のACL、暗号化を定めます。監査ログ、外部文書との分離、出力フィルタリングも含めます。
• 継続運用：モデル切替、バックアップ、インデックス更新も、要件に含めます。

利用者が閲覧できない文書は、LLMへ渡さない構成にします。また、評価は文章の確認だけで済ませず、実際のPDFや表を使って行います。

フェーズ4：テストで測る正答率・安全性・運用性

実際の問い合わせから評価セットを作り、回答の正しさに加えて、引用や検索漏れも採点します。「自然な会話ができる」ことだけでは、PoCの合格条件として足りません。

• 評価項目：質問と期待する根拠文書・回答、拒否条件、許容回答時間を、数十問から数百問程度用意します。
• 回答品質：引用の妥当性と根拠の新しさを確かめます。検索漏れや過剰な断定も確認します。
• 権限と攻撃：権限外文書の検索、悪意ある文書による指示、ログへの機密情報の残存
• 再テスト：問題修正後の再検証まで、見積もりに入れます。

デジタル庁の生成AI調達ガイドラインでも、確認項目として、検索先の機密情報へのアクセス権限、プロンプトインジェクション、バックエンドへの意図しない操作が挙げられています。

フェーズ5：稼働で決める切替方法と障害時の判断

稼働前には、対象文書の取り込みと改訂・削除の反映を確かめます。

利用者アカウント、問い合わせ窓口、障害時の連絡先も確認します。

小規模な社内FAQであれば一括での切替も選べます。一方、複数拠点や基幹連携を含む場合は、部門ごとに段階的に移行するほうが安全です。

• 切替計画：旧検索の停止時期と、停止までの二重管理を防ぐ方法
• 利用者案内：簡易マニュアル、回答を鵜呑みにしないルール、誤回答の報告方法を用意します。
• 停止条件：引用ページの欠落、権限外情報の検索、回答不能時の断定などを、安全上の停止条件にします。

重大障害のエスカレーション基準も定めます。さらに、機能不具合とは分けて、安全上の停止判断を用意します。

フェーズ6：定着で回す文書更新と精度改善

RAGシステムは、稼働後も改善を続ける必要があります。文書の更新がインデックスに反映されないと古い回答が出るため、更新の仕組みを先に決めておきます。

文書の所有者と、更新を検知する頻度を決めます。削除の反映時間や、再インデックスに失敗したときの通知も定めます。

• 問い合わせ分類：「操作方法」「データ不備」「検索漏れ」「誤回答」「追加要望」に分けます。
• 改善会議：毎月または毎週、分類をもとに対応の優先順位を見直します。
• 効果指標：一次回答時間と有人引き継ぎ率を比べます。根拠引用率と適切な回答拒否率も、あわせて追います。
• 運用指標：権限エラー、文書反映時間、問い合わせ削減工数を、導入前後で比較します。

デジタル庁が2026年に公開する「源内」でも、行政資料を対象にしたRAGアプリの展開が進んでいます。

RAGを単発のデモで終わらせず、データ整備と業務改善を伴う利用環境として運用する考え方が参考になります。

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

費用は、文書量、利用者数、機密度で変わります。また、OCRや表解析、既存システム連携の有無にも左右されます。権限管理、評価・監視、導入後の改善範囲も、費用を動かす要因です。

金額は、2026年公開の開発会社資料とリサーチノートに基づく企画段階の目安です。全国一律の定価として決まっているものではありません。

特に、閉域・オンプレミスや大規模な基幹連携は、個別の見積もりが必要です。

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

構成の範囲によって、PoCから大規模本番までの費用には幅があります。そのため、方式や連携条件を揃えて比べる必要があります。

• 既製サービス：顧客環境への導入では、初期20万円前後から、期間は約3週間から1か月程度という公開例があります。
• 小規模PoC：50万〜300万円程度で、1業務と1〜2種類の文書を対象にします。評価は数十〜数百問、UIは簡易なものを想定します。
• 拡張PoC：データ整備とOCR、部門別権限、既存ストレージ連携を含む場合で、300万〜800万円程度です。
• 標準本番：1〜2部署を対象とし、SSOと管理画面、監査ログ、根拠表示を含みます。更新処理と運用設計も含めると、300万〜1,500万円程度の見込みです。
• 大規模本番：複数部門と基幹連携、厳格な権限管理、評価自動化を伴う場合は、1,500万〜3,000万円以上になります。

標準本番より費用が高くなる主な要因は、チャット画面以外の認証や監査です。データ更新や評価、自動化なども、費用を押し上げます。

本番レンジは、2026年公開のルートチーム資料とソフィエイト資料、従来の業務システム開発の工数をもとにした目安です。

閉域・オンプレミスや大規模な独自開発では、3,000万円から1億円規模になることもあります。

月額費用と従量課金の分け方

運用・保守費は、文書更新や精度改善、障害対応を含めて、月10万〜80万円程度を仮置きする公開の目安があります。ルートチーム資料では月20万〜80万円程度で、利用量と窓口時間、改善会議、SLAによって変わります。

予算には、開発会社の保守費に加えて、社内のデータ管理者や業務責任者、評価担当者の工数も含めます。

• モデル利用：LLMの入力・出力トークンと埋め込み生成を含みます。
• 基盤利用：検索インデックスやベクトルDB、ストレージ、ログを含みます。ネットワークとガードレールも対象です。

AWSのAmazon Bedrock料金表でも、モデルの入出力や埋め込み、ガードレールなどを分けて示しています（出典：AWS「Amazon Bedrock Pricing」、2026年確認）。

利用者数、1人あたりの質問回数、平均の入力・出力長から、月次の上限を試算します。また、モデルの変更や利用増加に備えて、予算枠も設定します。

RAGシステムの見積もりを取る際のポイント

見積もりは、画面の作り込みだけでなく、データ整備や権限・認証、精度評価を含めて考えます。連携やテスト、教育、保守も、見積もりに入れておきます。

初期費用、月額、従量課金と5年TCOを分けて比べます。

RFI・RFPに書くべき前提条件

依頼書では、業務の規模とデータの状態を具体的に書きます。文書の形式は、PDFやスキャン、Excelに加えて表や画像も挙げ、形式ごとに取り込みと更新の方法も確認します。

• 利用条件：対象業務や利用者数、部門・拠点を記載します。利用端末と希望時期も示します。
• 文書条件：種類と件数、1ファイルの容量、更新頻度を整理します。保存場所と機密区分も添えます。
• 連携条件：認証方式と連携先を挙げます。SharePointとファイルサーバー、基幹システムも含めます。
• 機能要件：根拠・ページ表示と回答拒否、権限反映を定めます。改訂・削除の指定時間内反映、ログ監査、評価質問の追加も盛り込みます。
• 納品物：ソースコードと構成図、プロンプトを明記します。評価データや運用手順、データ返却形式も含めます。

文書の改訂・削除を反映する期限や、ログ監査の範囲などを、受け入れ条件として具体的に示します。

同じ評価シナリオによる複数社の比較

価格の異なる3社程度に、同じ資料と質問集を渡し、条件を揃えて比較します。

• 評価軸：業務適合性と取り込み、検索精度を確認します。権限・セキュリティや連携、操作性、拡張性も確認します。
• 導入後の条件：体制や保守、データ可搬性、5年TCOを比べます。
• デモ質問：表記揺れや型番、旧版と新版の違いを含む質問で試します。答えのない質問、権限外の質問、悪意ある指示も入れます。
• 契約確認：自社データでの評価と削除反映時間、LLM・検索基盤の変更、契約終了時の返却を質問します。

価格だけでなく、標準機能と追加開発の境界も確認します。口頭での回答は、提案書や契約書に反映します。

契約前に確かめる追加費用と受け持ちの範囲

追加費用が出やすい作業と、契約上のデータの扱いを、事前に整理します。

• 追加作業：想定外の形式やOCR改善、表・画像解析を確認します。権限連携やSSOを含め、APIや移行、評価質問の追加も確認します。
• テストと利用量：レッドチーミングや再テストを含め、利用量が増えた場合の費用条件も確かめます。
• 範囲と完了条件：「データ連携一式」「精度改善一式」には、対象データと件数、回数、完了・除外条件を求めます。
• データ保護：個人情報や営業秘密を扱う場合は、利用目的、第三者提供・再委託、保存場所を確かめます。学習利用、ログ保管期間、削除方法、事故時連絡も確かめます。

経済産業省・総務省のAI事業者ガイドライン第1.2版は、RAGで参照するデータの最新性と信頼性への留意を示しています（出典：経済産業省「AI事業者ガイドライン第1.2版」、2026年）。

データ更新の責任者と、誤回答が業務に影響した場合のエスカレーション先も、契約前に決めておきます。

RAGシステムの進め方でよくある質問

RAGの導入では、方式やデータ、評価について疑問が生じます。また、費用や稼働後の運用についても疑問が出てきます。発注前によくある質問に答えます。

RAGシステムのPoCはどのくらいの期間と費用がかかりますか？

小規模PoCの場合、期間は2〜6週間、費用は50万〜300万円程度が企画段階の目安です。

• 対象範囲：1業務と限定した文書、簡易UI、評価質問
• 評価項目：精度と根拠表示、拒否に加えて、回答時間や基本的な権限動作も確かめます。
• 拡張時の費用：データ整備や複数システム連携を含む場合は、300万〜800万円程度になることがあります。
• 見積書の確認：PoCの範囲を分けて確認します。

RAGの回答精度はどのように評価すればよいですか？

実際の質問ごとに、期待する根拠文書と回答を付けておきます。そのうえで、正しさや根拠の妥当性、引用漏れを測ります。拒否の適切さや回答時間も確かめ、権限外の文書や古い版が出ないことも合格条件に含めます。

答えがない場合に断定しない条件も設けておきます。なお、業務ごとに許容リスクが異なるため、最終判定は現場責任者が行います。

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

安全かどうかは、RAGという名称ではなく、複数の条件を組み合わせて判断します。

• 判断の観点：保存場所と契約、認証、権限を確認します。暗号化やログ、モデル学習利用、入出力制御も確認します。
• 対策要件：ACLやSSO、多要素認証を含めます。監査ログやプロンプトインジェクション対策、回答拒否、人手承認も入れます。

個人情報保護委員会の注意喚起や、業界の規制も確認します。

そのうえで、機密区分ごとに、クラウドと閉域、オンプレミスを比べます。

PoCと本番システムの見積もりは何が違いますか？

PoCと本番では、見積もりに入る要件の範囲が変わります。

• PoC：限定したデータと利用者で、技術や業務効果を検証します。
• 本番の認証と権限：SSOや文書単位の権限、監査ログが必要になります。
• 本番の運用：障害対応やバックアップ、更新・削除、性能も本番の要件に入ります。
• 本番の追加項目：教育やSLA、改善、データ返却も必要です。

PoC成果の引き継ぎ条件と作り直す範囲を、提案書に記載してもらうと、後の追加請求のリスクを抑えられます。

まとめ

RAGシステムは6フェーズで進めることで、技術の選定と業務の判断を分けて管理できます。

最初は、正解データと評価質問を用意しやすい1業務からPoCを始めます。

根拠表示や回答拒否、権限連動を検証し、更新反映と回答時間も確かめます。検証の結果は、本番条件に反映します。

小さく始めて本番条件を先に見極める進め方

費用の目安は、小規模PoCが50万〜300万円程度、標準本番が300万〜1,500万円程度です。複数部門や厳格な連携を含む場合は、1,500万〜3,000万円以上になります。

金額はデータ量、機密度、連携数で変わります。初期費用に加えて、従量課金や月額保守を確認します。文書更新と精度改善、5年間の総保有コストも押さえます。

見積もりでは機能より運用と責任分界

発注時は、モデル名や画面の見栄えより、自社データでの評価と権限外情報の遮断、攻撃耐性を比べます。文書の最新性と保守体制、データと仕様書の引き渡しも、あわせて確かめます。

PoCの合格条件と本番移行の条件を決めておき、現場のデータ管理者と業務責任者を定めておけば、導入後も回答品質を改善できます。

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

▼開発を相談する前に読みたい無料ホワイトペーパー
・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を創業。