RAGは内製か外注か？予算があっても失敗しない体制の決め方

RAGとは？「社内文書を根拠に答えるAI」を現場で使うための仕組み

RAG（Retrieval-Augmented Generation）は、生成AI（ChatGPTのような文章生成）に社内のデータを検索させ、その結果を根拠として回答させる仕組みです。たとえば「稟議の手順は？」「この契約書の禁止条項は？」「障害対応の初動は？」といった質問に対して、社内規程・マニュアル・FAQ・議事録などを探し、該当箇所をもとに回答します。

重要なのは、RAGは「AIに賢く答えさせる魔法」ではなく、検索（Retrieval）とデータ整備の品質が成果を決めるという点です。社内文書が散在していたり、版管理が崩れていたり、検索対象が曖昧だったりすると、AIの回答もブレます。逆に、文書の所在・更新・権限・用語が整っている組織ほど、RAGは早く効果が出ます。

またRAG導入の目的は、単なる「チャットボット」ではありません。典型的な成果は、問い合わせ対応の削減、ナレッジ共有の加速、属人化の解消、監査対応の効率化、教育コスト低減などです。ただし、成功するためには「何を正解とするか（回答の根拠・引用・最新版の優先）」を最初に決める必要があります。RAGは、モデル選びよりも運用設計（誰がいつ何を更新し、どのデータが正となるか）で勝負が決まります。

内製と外注の違いは「作る」より「回す」：体制の論点を先に整理する

「RAGは内製が良いのか、外注が良いのか」は、開発難易度よりも運用を誰が責任を持って回すかで判断すると失敗しにくくなります。RAGは作って終わりではなく、文書が更新されれば検索インデックスも更新し、アクセス権が変われば参照範囲も変わり、誤回答が出れば原因を潰して改善する…という継続業務が前提です。

内製のメリットは、業務の変化に合わせて素早く改善でき、機密データや権限周りを社内でコントロールしやすいことです。一方で、情シスや開発チームが薄い組織では、RAGの改善に時間を割けず「初期構築だけ立派で、更新が止まり精度が劣化する」リスクがあります。

外注のメリットは、短期間で形にしやすく、設計・実装・評価のノウハウを一気に借りられる点です。ただし、丸投げすると「要件が曖昧なままPoCが終わり、現場が使わない」「改修のたびに費用と時間がかかる」「ベンダーロックインで運用コストが膨らむ」といった問題が起きがちです。予算があっても失敗する典型は、体制（役割分担）を決めないまま発注し、評価軸がないまま納品を迎えるパターンです。

結論として、内製/外注は二択ではありません。おすすめは「外注で最初の型を作り、内製で回せる形に移行する」か、「内製主体でも、要所（設計レビュー・セキュリティ・評価設計）は外部の知見を借りる」というハイブリッドです。RAGは特に、検索品質・データ整備・権限設計・評価指標という“地味だが重要な部分”で差がつきます。

予算があっても失敗する理由：RAGは「要件不在・データ不在・評価不在」で崩れる

RAGプロジェクトでよくある失敗は、「AIを入れたい」だけが先行し、何をもって成功とするかが決まっていないことです。生成AIの画面を用意しても、現場は「それで何が早くなるのか」「誤回答したら誰が責任を持つのか」が見えないと使いません。ここを曖昧にしたまま進めると、PoCは動いたのに本番で止まります。

次に多いのがデータ不在です。RAGは社内データが命ですが、実際には「最新版がどれか不明」「PDFが画像で検索できない」「ファイル名がバラバラ」「アクセス権が複雑で一括で扱えない」など、技術以前の課題が山ほど出ます。ここを解決せずにベクトル検索やLLMの設定に時間をかけても、精度は上がりません。RAGの精度は、AIより“文書管理の成熟度”に強く依存します。

さらに、評価不在も致命的です。「回答が良いかどうか」を人の感覚だけで判断すると、改善が進みません。RAGでは最低限、(1)答えが存在する質問で正しく答えたか、(2)答えが存在しないときに「分からない」と言えるか、(3)根拠（引用元）が妥当か、(4)最新版を参照しているか、(5)権限外の情報を出していないか、という観点で評価が必要です。評価セット（質問集）を作らずに導入すると、納品後に「思ったより使えない」が発生します。

最後に、運用不在です。RAGは業務と一緒に育ちます。文書更新のフロー、改善要望の窓口、ログの確認、月次の精度チェックなど、運用が回る体制がないとすぐ陳腐化します。予算があるほど一気に作ってしまいがちですが、段階導入（小さく始めて確実に拡張）が結果的に最短ルートになります。

内製が向いているケース／外注が向いているケース：判断のためのチェックリスト

内製・外注の向き不向きは、「社内に何があるか」「何を自社で持ちたいか」で決まります。以下の観点で棚卸しすると、判断がブレにくくなります。

実務的には「外注か内製か」ではなく、役割を分けるのが現実解です。たとえば、外部がアーキテクチャ設計・初期構築・評価設計を担い、社内がデータオーナー・運用・改善の意思決定を担う形です。ここで大事なのは、データの最終責任者（業務側）と、運用責任者（情シス側）を明確にすることです。RAGは“誰の仕事か”が曖昧だと止まります。

失敗しない体制設計：RAG導入に必要な役割と、最小チームの作り方

開発に詳しくない組織でも回るようにするには、「役割」を先に決め、各役割の責任範囲を小さく始めることが重要です。おすすめの最小体制は、次の5役です（1人が兼務しても構いません）。

• 業務オーナー：どの業務課題をRAGで解くか決める。回答の正解定義（根拠・最新版）を持つ。
• データオーナー：対象文書の範囲を決め、更新ルール・版管理・機密区分を統括する。
• 情シス／運用責任者：アカウント・権限・監査ログ・障害対応・問い合わせ窓口を持つ。
• 技術リード（内製 or 外部）：検索設計、RAGの構成、品質評価、改善サイクルを主導する。
• 利用部門代表：実際の質問を出し、使い勝手と業務効果を検証する。

この体制で最初に決めるべきは、(1)対象業務、(2)対象データ、(3)回答の出し方（引用・リンク・注意書き）、(4)権限、(5)評価方法、の5点です。特に「引用」を必須にすると、利用者が根拠を確認でき、誤回答時の切り分けが速くなります。RAGは“それっぽい回答”が出てしまうので、根拠提示をUI/仕様として組み込むのが安全です。

運用面では、月次で「よく聞かれた質問」「答えられなかった質問」「誤回答」トップ10を見て、原因を分類します。原因は多くの場合、データ不足（文書がない）、データ品質（古い/表現ゆれ）、検索設定（分割単位やメタデータ不足）、権限（見せるべき人に見えていない）に分かれます。ここを潰していくのがRAG運用の本質です。担当者が1人で抱えないよう、改善の意思決定は業務オーナーが持ち、技術側は選択肢を提示する構造にすると回りやすくなります。

導入の進め方：PoCで終わらせないためのロードマップ（要件→データ→評価→運用）

RAGは「まず作ってみる」も可能ですが、予算がある組織ほど遠回りになりがちです。おすすめの進め方は、業務価値から逆算し、データと評価を先に固めることです。

小さく始める対象を決める（業務を1つに絞る）

最初は「社内の何でも答えるAI」ではなく、たとえば「経費精算」「購買・稟議」「ITヘルプデスク」「製品FAQ」「契約レビュー」など、質問が定型で効果が測りやすい領域に絞ります。成功条件を「問い合わせ件数を30%削減」「一次回答までの時間を半分」など、測れる指標に落とすのがポイントです。

データ整備は“完璧”より“運用可能”を優先する

文書の統合や全社ポータル整備を先にやると、導入が進みません。最初は「信頼できる一次情報（正となる文書）」を決め、更新責任者を置きます。PDFしかない場合はテキスト化、表現ゆれが多い場合は用語集を作るなど、最低限の整備でスタートし、ログを見ながら増強します。ここで重要なのは、“誰が更新するか”を決めないデータ整備は意味がないということです。

評価セット（質問集）を作り、合格ラインを決める

PoCで「良さそう」を避けるため、現場の質問を30〜100件集め、答えと根拠文書を紐づけます。合格ラインは、正答率だけでなく「根拠が提示される」「権限外が出ない」「分からないと言える」を含めます。RAGは“知らないことを知らない”と危険なので、回答不能時の挙動を仕様化します。

本番で必須の運用を先に設計する

本番導入では、アクセス権、監査ログ、問い合わせ窓口、障害時の切り戻し、データ更新のタイミング（毎日/週次/随時）を決めます。特に情シス視点では、SaaS連携やSSO、端末制御、ログ保管などが論点になります。外注する場合でも、運用の責任者は社内に置くことが失敗回避につながります。

ベンダーに外注するなら：見積もり前に決めるべき要件と、RFPで押さえるポイント

外注で多い失敗は、要件が曖昧なまま「RAGを作ってください」と発注してしまうことです。これだと、ベンダーは無難な構成を提案するしかなく、納品後に「想定と違う」「追加費用がかかる」が発生します。見積もり前に、最低限次を決めておくと精度が上がります。

• 対象業務と利用者：誰が何のために使うか。利用シーン（PC/スマホ、社内のみ等）。
• 対象データ：どのフォルダ/システムを対象にするか。更新頻度、機密区分、版管理。
• 権限と監査：部署別・役職別の参照制御、ログの保管期間、監査対応。
• UI要件：引用表示、参照リンク、回答の注意書き、フィードバック導線。
• 品質要件：評価セット、合格基準、改善サイクル、SLA/サポート範囲。
• データ持ち出し条件：クラウド利用可否、学習への利用禁止、保管場所。

提案比較の観点としては、費用だけでなく「運用をどう設計するか」「評価をどう回すか」「データ更新をどう吸収するか」を見てください。RAGは、最初に作った検索設定が永遠に正しいわけではありません。ログをもとに改善する前提の提案になっているかが重要です。また、納品物がブラックボックスだと内製移管ができません。設計書・評価結果・運用手順・権限設計・データフローが成果物に含まれるかを確認すると、将来のコストを抑えられます。

契約上も、PoCで終わらせないために「PoC→本番」のゲート条件（合格基準）を明文化すると揉めにくくなります。外注の狙いは“作業の丸投げ”ではなく、“成功確率を上げるための知見の獲得”だと整理すると、発注の質が上がります。

まとめ

RAGは、生成AIに社内データを検索させて根拠付きで答えさせる仕組みで、問い合わせ削減やナレッジ共有に大きな効果があります。一方で、成功の鍵はモデル選定よりもデータ整備・権限設計・評価設計・運用体制にあります。

• 内製は改善が速いが、運用に継続リソースが必要
• 外注は立ち上げが速いが、要件と評価がないとPoC止まりになりやすい
• 失敗の原因は「要件不在・データ不在・評価不在・運用不在」に集約される
• おすすめは、外部の知見で型を作り、社内が運用責任を持つハイブリッド体制

予算があるほど「とりあえず作る」ができてしまいますが、RAGは“回る仕組み”を先に作った組織が勝ちます。まずは業務を1つに絞り、評価セットを用意し、運用責任者を置いたうえで、内製と外注の役割分担を決めてください。そうすれば、RAGは現場で使われる戦力になります。