RAG 導入 企業の分岐点2026｜PoCで止まる会社と回収の目安

社内の規程や設計書、過去のトラブル対応履歴を生成AIに読ませたい、というご相談をよくいただきます。その手段としてRAG 導入を検討する企業は、2026年に入って明らかに増えました。一方で、試したところまでは進んだのに本番に届かず立ち消えになった、という話も同じくらい耳にします。本記事は、RAGをどう作るかではなく、自社が投資すべきかをどう判断するかに絞って整理します。PoCで終わる会社と本番運用に進む会社を分ける条件、費用がどのレンジに収まるか、そして回収が成立する業務量の目安までを、稟議を書く前に押さえておきたい順序で並べました。

RAGとは何か｜社内データ 生成AI 活用の前提を先に揃える

RAGはRetrieval-Augmented Generation（検索拡張生成）の略です。生成AIに答えさせる前に社内文書から関連箇所を検索して取り出し、それを根拠として渡したうえで回答を作らせる仕組みを指します。

投資判断の文脈で押さえるべきは、この仕組みが検索と生成の2階建てだという点だけです。利用者から見れば社内向けのチャット検索に見えますが、内部では「意味の近い文書の断片を取り出す」処理が先に走り、その取り出した文章の範囲内で回答が組み立てられます。渡された紙に答えが書いていなければ、どれだけ高性能なモデルを使っても正解は返りません。

この構造から、RAGが得意な質問と苦手な質問がそのまま導けます。

この線引きを社内で共有しないままPoCを始めると、利用者は苦手な3種類を試し、答えられない様子を見て「使えない」と結論します。設計どおりに動いているのに評価だけが下がる、という残念な結果になります。検討の最初の会議で、答えられる質問の型を具体例つきで示しておいてください。

なお、検索精度を上げるための技術的な手法や、チャンク分割・リランキングといった構築側の設計論は本記事では扱いません。工場のナレッジ検索を題材にした具体的な構築手順はRAG構築の費用と進め方｜タイの工場で多言語ナレッジ検索を作るで詳しく解説していますので、作り方の検討段階に入ったらそちらを参照してください。本記事はその手前、作るかどうかを決める段階に必要な材料だけを扱います。

RAG 導入 企業の分岐点｜PoCで止まる会社は何が違うのか

ここからが本題です。RAGの導入を検討する企業にとって最大の関心事は、投じた費用が本番運用まで到達するかどうかです。

Gartnerの2つの予測が示す落とし穴

Gartnerは2024年7月29日のプレスリリースで、少なくとも30%の生成AIプロジェクトが2025年末までにPoC（概念実証）の後で断念されると予測しました。断念の原因として挙げられたのは、データ品質の低さ、リスク統制の不備、コストの膨張、ビジネス価値の不明確さのいずれかです。

さらにGartnerは2025年2月26日のプレスリリースで、より的を絞った予測を出しています。2026年までに、企業はAI-readyなデータに支えられていないAIプロジェクトの60%を放棄するというものです。ここで見落とせないのは、AIプロジェクト全体の60%が失敗するという話ではない点です。対象は「AIに使える状態に整えられたデータに支えられていない」プロジェクトに限定されています。この限定詞こそが、この予測の実務的な価値です。

同じリリースでは、2024年第3四半期に248名のデータマネジメント責任者を対象に行った調査で、63%の組織が、AIに適したデータ管理の実践を持っていない、あるいは持っているかどうか分からないと回答したことも示されています。3社に2社が、自社のデータがAIに使える状態かどうかを把握できていない、ということです。

キヤノンITソリューションズの実測が示す「悪いのはLLMではない」

予測だけでは実感が湧かないので、実際にRAGを社内導入した日本企業の公表データを見ます。キヤノンITソリューションズは、社員向けサポートセンターでRAGの試験運用を行った結果を技術レポートとして公開しています。実際の問い合わせ内容をそのままシステムに入力し、有用な回答が得られるかを担当者が採点する形式で、合計228件が評価されました。

結果は率直なものです。「Good」と評価されたのは全体の約3分の1にとどまりました。注目すべきはその先で、「Bad」評価の原因の内訳が公表されています。

この表は、RAG導入を検討するすべての企業が最初に見るべき数字だと考えています。悪い回答の原因のうち、生成AIそのものに起因するものは12%しかありません。残りの88%は、元になる文書が足りない・整っていないことと、必要な文書を見つけられないことに起因しています。「もっと賢いLLMに変えれば良くなる」という発想が届かない領域が、圧倒的に大きいということです。

前節でRAGを検索と生成の2階建てだと述べたことが、ここで効いてきます。1階の検索と、その手前にある文書の状態が全体の成否を握っており、2階の生成はほとんど問題になっていない、という構図です。これは1社の試験運用の結果なので自社にそのまま当てはまるとは限りませんが、近い分布になるのであれば、モデルの性能やパラメータ数の話が中心の提案書は、原因の1割強しか対象にしていないことになります。提案を受けるときの見方として覚えておいて損はありません。

分岐点1　データ品質を「後で整える」と決めた時点で負けている

PoCで終わる会社と本番に進む会社を分ける最大の要因が、データ品質への向き合い方です。AQUA合同会社がRAG導入の失敗要因を整理した記事では、データ準備にプロジェクト全体の40%から60%の工数を要するにもかかわらず、多くの組織がこれを過小評価していると指摘されています。

具体的に何が問題になるかというと、次のような状態です。同じ規程の新旧2版が両方ともサーバーに残っていて、検索は古いほうを拾う。スキャンしただけのPDFで文字情報が入っておらず、検索対象にすらならない。表だけで説明文がない資料で、取り出した断片からは何の表か分からない。担当者しか意味の分からない略語で書かれていて、質問文と語彙が一致しない。誰も更新していない共有フォルダに、3年前に廃止された手順書が置いたままになっている。

これらはRAGの技術で解決できる問題ではありません。しかもPoCの段階では表面化しません。PoCでは対象文書を数十本に絞り、その数十本だけは人手で整えてから投入するため、精度が良く見えるからです。ところが本番で数千本を投入した瞬間に、上記の問題が一斉に噴き出して精度が崩れます。PoCが成功して本番で失敗する典型的な経路がこれです。

対策は単純です。PoCの対象文書を選ぶときに、「整えた文書」と「現状のまま投入する文書」を意図的に混ぜてください。現状のままの文書がどれだけ足を引っ張るかをPoCで計測しておけば、本番のデータ整備に要る工数を見積もる材料になります。ここを測らずに本番の見積もりを出すベンダーがいたら、その見積もりは後で必ず膨らみます。

分岐点2　スコープクリープは「全社展開」という言葉から始まる

2つ目の分岐点は、対象範囲の際限ない拡大です。最初は情報システム部門のFAQに限定していたはずが、検討の途中で人事規程が加わり、次に品質マニュアルが加わり、営業から過去の提案書も入れてほしいと言われ、最終的に「社内文書ぜんぶ」になる、という流れです。

範囲が広がると3つのことが同時に起こります。まず、文書の種類が増えるほど整備の工数が線形以上に増えます。次に、部門ごとに閲覧権限が異なるため、権限管理の実装が必要になります。そして、評価の基準が曖昧になります。対象が10業務あると、どの業務でどれだけ改善したのかが測れず、効果を説明できなくなります。効果を説明できないプロジェクトには、次年度の予算がつきません。

Gartnerが挙げた断念理由のうち「コストの膨張」と「ビジネス価値の不明確さ」は、多くの場合スコープクリープの結果として現れます。費用を抑える最も確実な方法は、最初から全社展開を狙わず、1つか2つの業務でPoCを行い、効果を確認してから広げることです。

分岐点3　運用体制を決めずに本番稼働させない

3つ目は、稼働後の体制です。RAGは作って終わりの仕組みではありません。文書が更新されれば入れ直しが要り、答えられなかった質問を集めて文書を補う作業が要り、利用者の評価を見て検索の設定を調整する作業が要ります。

前出のAQUA合同会社の整理では、年間の運用費として初期開発費の15%から25%程度を見込む必要があるとされています。金額よりも重要なのは、この作業を誰がやるかを稼働前に決めておくことです。情報システム部門の兼務担当者が「余裕があるときに」やる建て付けにすると、3か月で更新が止まります。更新が止まったRAGは、古い情報を自信たっぷりに答える、導入前より危険な仕組みに変わります。

運用の担い手を決めるときの現実的な解は、文書の所管部門に更新責任を持たせ、情報システム部門は仕組みの維持だけを担う分担です。人事規程が変わったら人事部が入れ直す、という形にしておけば、更新の遅れが構造的に起きにくくなります。

自社がどちら側かを判定する

3つの分岐点を、稟議の前に自己点検できる形に落とします。左の列に当てはまるなら本番まで到達する見込みがあり、右の列に当てはまるならPoCで止まる可能性が高い、という読み方をしてください。

6項目のうち右側が3つ以上あるなら、RAGの見積もりを取る前に、該当した項目を潰す作業から始めるほうが結果的に早く着地します。特に上の3行は、ベンダーを選んでも解決しない自社側の宿題です。

RAG導入の費用相場2026｜レンジと、見積もりが動く3つの要因

投資判断のためには、総額だけでなく「何によって金額が動くか」を把握する必要があります。動く要因が分かって初めて、相見積もりの比較が成立します。

規模別のレンジ

フェーズで区切った相場は、GXOの公開値でPoCが100万〜300万円（2〜6週間）、本番構築が300万〜1,000万円（2〜4か月）、月額運用が10万〜50万円です。フェーズ別の内訳をさらに層で分解した見方はRAG構築の費用と進め方で扱っているので、ここでは投資判断に直結する別の切り口として、ルートチームが公開している規模別の相場を置きます。自社がどの段階を狙うのかを決めるときには、こちらの区分のほうが使いやすいはずです。

2系統を並べると、PoCと本番構築のレンジはおおむね重なる一方、月額運用はGXOが10万〜50万円、ルートチームが20万〜80万円とレンジ全体がずれています。運用に何を含めるかの定義差なので、見積もりを取るときは金額より先に「保守費に何の作業が入っているか」を確認してください。なおどちらも開発会社自身が公開している目安であり、独立した第三者の市場調査ではありません。自社の見積もりがこのレンジから外れていること自体は問題ではなく、外れている理由を説明できるかどうかが重要です。

注意したいのは、フル本番に事実上の上限がないことです。1,500万円以上という書き方は、連携するシステムの数と権限管理の複雑さ次第で青天井になり得ることを意味しています。ルートチーム自身も、費用を抑えるには最初から全社展開を狙わず小さなPoCで効果を確認してから範囲を広げること、と整理しています。

費用の大半はモデルではなくデータと画面にかかる

金額のレンジより重要なのが、内訳の構造です。GXOは情報システム部門のFAQ検索を対象にした小規模PoCについて、費目ごとの内訳例を公開しています。金額そのものの内訳と、それが本番構築・運用の各段階でどう積み上がるかはRAG構築の費用と進め方に譲り、ここでは投資判断に直結する構成比だけを取り出します。

LLMのAPI利用料が全体の2%しかないことが、この内訳の要点です。世間の議論はどのモデルを使うかに集中しがちですが、少なくともこの費用構造ではモデルの選択はほとんど金額に影響しません。最大項目はデータ整備で、ここに精度評価を足すとこの内訳例では全体の58%が「データを整えることと、どれだけ効いたか測ること」に使われています。前節の分岐点1と整合する構造です。

見積書を受け取ったら、まずこの比率と見比べてください。データ整備の項目が極端に小さい、あるいは「データはお客様側でご用意ください」と書かれている見積もりは、総額が安く見えても、その差額が自社の人件費として後から発生します。

見積もりが動く3つの要因

同じ「本番構築500万円」でも、前提が違えば意味がまったく変わります。相見積もりを取るときは、次の3つを発注側で固定して各社に同じ条件で出させてください。ここを揃えないと金額の比較そのものが成立しません。

• 対象文書の本数と形式。100本を前提にした見積もりと1,000本を前提にした見積もりでは、データ整備の工数が桁で変わります。スキャンPDFの比率も必ず伝えてください。
• 権限管理の要否。誰がどの文書を検索できるかを制御する機能は、PoCの内訳例には費目として現れず、本番で初めて立つのが通例です。人事情報や取引条件を含む文書を扱うなら省略できません。この項目の有無だけで数十万円から百万円単位の差が出ます。
• 既存システムへの組み込み方。専用の画面を新規に作るのか、既存の社内ポータルや業務チャットに載せるのかで、UI開発費が大きく動きます。ここは3要因のなかで最も交渉余地がある項目です。

回収が成立する業務量の目安

ベンダーの試算をそのまま稟議に転記することは勧めません。削減額の前提となる「1件あたり何分短縮されるか」「月に何件あるか」「その時間の単価はいくらか」は企業ごとに大きく違うためです。公開されている試算例でも、初年度は本番稼働を6か月目と想定した按分で削減効果を見積もっており、定常状態の年間削減額をそのまま初年度に当てはめてはいません。

実務的には、自社で次の3つの数字を先に押さえてから試算し直してください。対象業務の月あたり件数、1件あたりの現在の平均対応時間、対応者の時間単価です。この3つが分かれば、削減率を何%と置いても回収期間を幅で出せます。

仮に1件20分の問い合わせ対応を、時間単価3,000円の担当者が行っているとします。RAGで対応時間が30%短縮されるとすると、1件あたりの削減額は20分の30%にあたる6分ぶん、つまり300円です。この300円を軸にすると、必要な業務量が逆算できます。投資側の前提には、前掲した規模別レンジのうち最も重いフル本番（全社展開・複数システム連携）を置きます。初期投資は500万〜1,500万円以上というレンジの中ほどを取って1,000万円、年間運用費は保守・運用の月20万〜80万円のうち下寄りの月40万円として、12か月ぶんの480万円とします。段階を追って小さく始める場合の投資額はRAG構築の費用と進め方にPoC・本番構築・運用の3段階で整理してあるので、同じ手順で自社の規模に置き直してください。

この置き方では年間運用費480万円が初期投資1,000万円の48%にあたり、前出のAQUA合同会社が示す15%から25%という目安を大きく超えます。全社展開を前提にすると、運用費レンジの下寄りを取ってもなおこの比率になるということです。実際の運用費は対象文書の本数と更新頻度で上下します。自社で試算するときは運用費の想定を上下させた2通りを出しておくと、判断がぶれません。

上の表が示すのは、全社展開の規模で投資するなら、問い合わせ件数が月1,330件に届かない業務では時間削減だけで年間運用費すら賄えないという現実です。狙う規模を落とせば必要件数も比例して下がるので、自社が現実的に取り得るレンジで置き直したうえで読んでください。これは悲観的な結論ではなく、対象業務の選び方と投資規模の決め方を同時に縛る基準になります。件数が足りない場合の打ち手は3つあります。1つ目は、件数の多い業務を対象に選び直すこと。2つ目は、削減効果を時間短縮だけでなく、属人化の解消や新人の立ち上がり期間短縮といった別の効果と合わせて評価すること。社内問い合わせ対応を題材に、一次対応の時間削減だけでは収支が合いにくいことを別の前提で試算した例は社内問い合わせ自動化2026｜答えが古くなる4つの版ズレにまとめています。1件あたりの所要時間も単価も本記事とは違う置き方をしているので、2通りのモデルとして読み比べてみてください。3つ目は、既存システムに載せて初期費用と運用費そのものを圧縮することです。

タイ・ASEAN拠点でRAG 導入 企業が追加で踏む論点

ここまでは日本国内でも共通する話です。タイをはじめとするASEAN拠点で導入する場合には、判断材料が4つ増えます。いずれも稟議の前に整理しておくと、承認の往復が減ります。なお、現地スタッフのリテラシーや本社ガイドラインとの整合といった、RAGに限らず生成AI全般で共通して起きる論点は生成AI導入の失敗2026｜95%が停滞する構造とタイ拠点の分岐点で整理しています。ここではRAG固有の判断に絞ります。

多言語文書の版ずれ。タイの日系工場では、同じ内容の文書が日本語・英語・タイ語で存在し、しかも3言語が同期していないことが普通にあります。日本語版だけが最新で、タイ語版は2年前、というような状態です。RAGは質問した言語と同じ言語の文書を優先して拾う傾向があるため、タイ人スタッフがタイ語で質問すると古い版が根拠として返り得ます。どの言語版を正本とするか、翻訳をどの段階で挟むかという設計判断は導入初期にしか変えられません。翻訳の入れ方には全文翻訳・クエリ翻訳・多言語埋め込みという3案があり、それぞれ初期費用と更新負荷が異なります。この比較は前掲のRAG構築の費用と進め方で表にまとめていますので、要件定義の前に目を通しておいてください。

現地スタッフが実際に使う入り口。製造現場のリーダー層は、ブラウザで社内ポータルを開く習慣がない場合があります。専用のWebアプリを作っても、そこに辿り着かなければ使われません。現場で確実に開かれているのは、日常的に使うチャットアプリか、現場に設置された端末です。入り口をそこに寄せるだけで利用率が変わります。前節でUI開発費が動く要因だと述べましたが、既存のチャットに載せられるなら費用を抑えつつ利用率を上げられるという、費用と効果が同じ方向を向く数少ない判断になります。

データの置き場所と社内規程。タイでは個人データ保護法（PDPA）が施行されており、個人情報を含む文書を扱う場合には処理の根拠と越境移転の扱いを整理する必要があります。加えて、日本本社が定めた情報管理規程が海外拠点にも適用される場合、規程上どこまでのデータを外部APIに送れるかの解釈を先に取っておかないと、稼働直前で止まります。RAG固有の落とし穴として、確認すべき対象が文書の原本だけではないという点があります。原本、そこから抽出したテキスト、検索用に数値化したデータ、そして利用ログの4種類それぞれについて保存先を確認する必要があり、この整理は前掲のRAG構築の費用と進め方に詳しく書いています。外部APIを使うのか、自社環境にモデルを置くのか、両者を使い分けるのかという基盤側の選択は費用にも精度にも大きく効くため、RAGの設計とは別に整理する価値があります。判断軸はLLM 導入は基盤の持ち方で決まる｜API・自社ホスト・ハイブリッドにまとめています。

本社と現地の役割分担。本社主導で進めると本社の文書と日本語を前提とした構成になり、現地の実務に合わないものができます。逆に現地単独で進めると、本社の情報管理規程との整合が後から問題になり、稼働後に作り直しになります。実務的には、基盤とルールは本社、対象文書と運用は現地という分担が機能しやすい形です。どの文書を対象にするか、誰が更新するか、どの言語を正本にするかは現地でなければ判断できません。一方で、どのモデルを使うか、データをどこに置くか、どこまで外部に出してよいかは本社の統制事項です。この線引きを稟議の前に文書化しておいてください。

業務自動化 AIへ広げる前に線を引く

RAGを入れた企業の多くが、次に業務自動化 AIへの拡張を検討します。検索して答えるだけでなく、そのまま処理まで実行させたいという発想です。方向性としては自然ですが、間に1本線を引く必要があります。

まず両者の違いを言葉のうえで揃えておきます。RAGは社内文書を検索して答える仕組みで、その役割は本質的に読んで答えることに限られ、書き込んだり実行したりはしません。対して業務自動化 AIは、判断した内容をもとに実際の処理まで実行します。社内では同じ「AI導入」としてひとくくりに語られがちですが、この差は稼働後に効いてきます。

違いが表に出るのは失敗したときです。RAGなら間違った回答が返っても、利用者が読んで判断する余地があります。ここに実行機能を足すと、間違った判断がそのまま行動になります。誤りの影響範囲が質的に変わるということです。

したがって拡張の順序は、まずRAGで答えの正しさを一定期間測り、どの種類の質問なら十分な精度が出ているかを実データで確認してから、その範囲に限って実行機能を足す、という順になります。精度の測定なしに自動化へ進むことが、Gartnerの言う「リスク統制の不備」に該当します。

この順序を守るうえで前提になるのが、回答がどの文書のどこを根拠にしたかを必ず返す設計です。根拠が追えない仕組みの上に自動実行を載せることはできません。設備マニュアルを題材にした具体的な設計例はマニュアル検索AI 2026｜精度より出典を返す設計が事故を防ぐで扱っていますが、そこで述べている「精度より出典」という優先順位は、業務自動化へ進む際の必要条件でもあります。

ベンダー選定で提案書のどこを見るか

最後に、依頼先を選ぶときの見どころを整理します。提案書の厚さや実績数ではなく、次の5点への答え方で判断してください。

このうち最も差が出るのは2番目です。評価用の質問セットを一緒に作りましょうと言えるベンダーは、精度が測定可能な指標だと理解しています。逆に形容詞でしか説明できない場合、稼働後に「思ったより使えない」となったときの改善の当てがありません。これは前節の判定表で挙げた「評価方法」の項目と対になっています。発注側が評価方法を決めていない状態でベンダーに丸投げすると、双方とも成否を判定できないまま費用だけが積み上がります。

なお、ここに挙げたのは提案書を受け取った時点での見分け方です。実際の面談で投げる技術寄りの質問リストは、前掲のRAG構築の費用と進め方に8項目としてまとめてありますので、候補を2社3社に絞ったあとの比較で使ってください。

TOMAS TECHが支援できること

TOMAS TECHはタイ・バンコクを拠点に、日系製造業のタイおよびASEAN拠点向けに生産管理システムPEGASUSの導入とAI活用支援を行っています。RAGに関しては、作るかどうかを決める前の段階から、以下の範囲でご相談をいただいています。

• 対象業務の切り出しと回収試算。どの業務なら件数と削減効果が投資に見合うかを、本記事の3つの数字を実データで埋めながら一緒に確認します。
• 文書の現状調査と整備工数の見積もり。スキャンPDFの比率、多言語版のずれ、版管理の状態を実際に見てから工数を出します。
• PoCの設計と評価。評価用の質問セットの作り方と、整えた文書と現状のままの文書を混ぜた測り方をご提案します。
• 既存システムとの接続方針。生産管理や設備データを持つシステムがある場合、文書検索とどう役割分担させるかを整理します。
• 本社と現地の分担整理。情報管理規程との整合を含め、稟議に必要な論点を文書化します。

現地に拠点を持ち、タイの製造現場の実務を前提に設計できることが、日本国内のベンダーとの違いです。本社の規程と現地の実務の両方を見ながら要件を整理できる点も、越境案件では効いてきます。

よくある質問(FAQ)

RAGとは何ですか。どんな質問に向いていますか

RAGはRetrieval-Augmented Generation（検索拡張生成）の略で、生成AIに答えさせる前に社内文書から関連箇所を検索して取り出し、それを根拠として渡したうえで回答を作らせる仕組みです。向いているのは、答えが社内のどこかの文書に文章として書かれている質問です。規程の解釈、手順の確認、過去の類似案件の探索などが該当します。逆に、答えが基幹システムの数値として存在する質問、複数の文書を横断した集計や比較を要する質問、そもそも文書化されていない暗黙知は苦手です。この線引きを社内で共有してからPoCに入らないと、苦手な質問ばかり試されて評価だけが下がります。

RAG導入の費用はどれくらいですか

2026年時点でフェーズごとに区切ったGXOの価格ガイドでは、PoCが100万〜300万円、本番構築が300万〜1,000万円という水準です。月額運用は公開元によって幅があり、GXOが10万〜50万円、ルートチームが20万〜80万円としています。規模別では、1〜2業務に特化した小規模PoCが50万〜200万円、1〜2部署で権限管理を含む軽量本番が300万〜500万円、全社展開で複数システムと連携するフル本番が500万〜1,500万円以上とされています。公開されているPoCの内訳例では、LLMのAPI利用料が費用全体のわずか2%で、最大項目はデータ整備の40%でした。このように費用の大半がモデルではなくデータと画面にかかるという構造を知っておくと、見積もりの妥当性を判断しやすくなります。段階ごとの金額の内訳は関連記事のRAG構築の費用と進め方にまとめています。

PoCで終わらせないために、何を確認すればよいですか

3点です。1点目は対象文書の状態で、最新版がどれかを担当者が即答できるか、スキャンしただけのPDFがどれだけあるかを先に把握してください。2点目は範囲で、1つか2つの業務に絞り、どうなったら広げるかの条件を先に決めます。3点目は運用担当で、どの部門が何をいつ更新するかを稼働前に決めます。この3点が曖昧なままPoCに進むと、PoCでは良い結果が出て本番で崩れる、という最も費用が無駄になる経路を辿ります。

社内データを生成AIで活用する場合、情報漏えいは大丈夫ですか

構成次第です。外部のLLMサービスにデータを送る構成では、送信するデータの範囲、提供者側での学習利用の可否、保存場所を契約と設定の両面で確認する必要があります。自社環境にモデルを置く構成であれば外部送信は発生しませんが、初期費用と運用負荷は上がります。タイで運用する場合は個人データ保護法（PDPA）の観点から、個人情報を含む文書の扱いと越境移転の整理も必要です。加えてRAG固有の論点として、閲覧権限のない文書が検索結果として返らないよう権限管理を実装することが挙げられます。この機能はPoCの内訳例には費目として現れず、本番で初めて立つのが通例なので、見積もりの比較時に有無を必ず揃えてください。

まとめ

RAG 導入を検討する企業にとっての判断は、技術の良し悪しではなくデータと運用の準備状況で決まります。Gartnerは少なくとも30%の生成AIプロジェクトが2025年末までにPoCの後で断念されると予測し、さらに2026年までにAI-readyなデータに支えられていないAIプロジェクトの60%が放棄されると予測しました。この限定詞は重要で、データを整えたプロジェクトが同じ確率で失敗するとは述べていません。

キヤノンITソリューションズが公開した228件の実測では、悪い回答の原因のうち生成AIそのものに起因するものは12%にとどまり、文書の不備や不足が46%、検索精度の低さが42%を占めていました。投資判断で見るべきは、どのモデルを使うかではなく、自社の文書がどれだけ整っているかです。

費用は、PoCが100万〜300万円、本番構築が300万〜1,000万円というレンジが各社の価格ガイドの水準で、月額運用は公開元により10万〜80万円と幅があります。ただし総額より重要なのは内訳で、公開されているPoCの内訳例では費用の58%がデータ整備と精度評価に使われ、LLMのAPI利用料は2%にすぎません。そして回収の可否は業務量で決まります。1件20分・時間単価3,000円・削減率30%という前提で、全社展開規模（初期投資1,000万円・年間運用費480万円）を置くと、月におよそ1,330件を超えないと年間運用費すら賄えず、初期投資まで3年で回収するには月およそ2,260件が要ります。この試算を自社の数字で置き換えることが、稟議を書く前の最初の作業になります。

タイ・ASEAN拠点では、多言語文書の版ずれ、現地スタッフが実際に使う入り口、データの置き場所と社内規程、本社と現地の役割分担という4つの判断材料が加わります。いずれも導入初期にしか決められない設計判断なので、要件定義の前に整理しておいてください。

始め方としては、件数の多い1業務に絞り、整った文書と現状のままの文書を混ぜてPoCを行い、正答率と出典の妥当性を数値で押さえる。この最初の設計さえ正しければ、その後の判断はデータが教えてくれます。

自社のどの業務から始めるべきか、手元の文書がRAGに使える状態なのか、件数から見て回収が成立しそうかといった点は、文書の量と状態、既存システムの構成によって答えが変わります。TOMAS TECHでは、タイの日系工場・拠点での生産管理システム導入やAI活用支援を通じて、こうした前提の整理からご相談をいただいています。まだ社内で方向性が固まっていない検討段階でも構いませんので、現在の課題感や対象にしたい業務をお問い合わせページからお聞かせください。対象業務の選び方や、PoCで何を測るべきかといった具体的なところからご一緒します。

参考情報

• GXO: RAG導入の費用相場と内訳。PoC・本番構築・月額運用のレンジと、従業員300名規模の企業を想定したPoC内訳例
• ルートチーム: RAG開発の費用相場と外注のポイント。小規模PoCからフル本番までの規模別費用と保守運用費
• Gartner: 少なくとも30%の生成AIプロジェクトが2025年末までにPoC後に断念されるとの予測（2024年7月29日）
• Gartner: AI-readyなデータに支えられていないAIプロジェクトの60%が2026年までに放棄されるとの予測と、248名調査での63%（2025年2月26日）
• キヤノンITソリューションズ: 社内RAG試験運用228件の評価結果。Bad評価の原因内訳は文書の不備や不足46%、検索精度の低さ42%、生成AI 12%
• AQUA合同会社: RAG導入が失敗する原因の整理。データ準備が全体工数の40〜60%、年間運用費は初期開発費の15〜25%