title: "RAG導入228件で「良好」は33%だけ。PoC止まりを生む品質46%・検索精度42%の正体" description: "キヤノンITSのRAG社内検索PoCで228件中『Good』は約33%。残りの原因は文書の不備46%・検索精度42%・生成AI精度12%。回答品質とデータ連携でPoC止まりを起こす構造と、本番化に向けた自己診断・改善の打ち手を開発リーダー向けに整理する。" keyword: "RAG 導入 失敗 PoC 止まり 回答品質 データ連携 本番化" slug: "rag-poc-stuck-228-cases-quality-data-integration-20260625" date: "2026-06-25" updatedAt: "2026-06-25" category: "AI・DX" tags: ["RAG","PoC","本番化","データ連携","AI導入"] author: "GXO株式会社" lead_summary: "RAGのPoC止まりは生成AIの精度ではなく、文書品質と検索精度で起きる。本番化の前に直すべき3軸を整理する。"
RAG導入228件で「良好」は33%だけ。PoC止まりを生む品質46%・検索精度42%の正体
結論：RAGがPoCで止まる原因は「生成AIの精度」ではない
RAG（検索拡張生成）の社内導入で「PoCは動いたが本番に進めない」という相談が増えている。原因をモデル選定や生成AIの賢さに求めがちだが、実データはそれを否定している。
キヤノンITソリューションズが自社のサポートセンター内で実施した社内検索のRAG試験運用では、合計228件の問い合わせを評価した結果、「Good」と評価されたのは全体の約3分の1（約33%）にとどまった（※キヤノンITソリューションズ テクニカルレポート「RAG導入で社内検索はどう変わった？」）。
そして「Bad」と評価されたケースの原因内訳が、RAGプロジェクトの本質を示している（※同レポート 表1）。
- 文書の不備や不足：46%
- 検索精度の低さ：42%
- 生成AIの精度：12%
押さえるべき1点：RAGがPoC止まりになる原因の約88%は、生成AIの賢さではなく「読ませる文書の品質」と「正しく引き当てる検索」にある。
つまりRAG導入の失敗は、大きく次の3軸に分解できる。
- 回答品質の問題（文書側）：そもそも社内文書が古い・断片的・矛盾していて、正しい根拠を渡せない
- データ連携・検索の問題（検索側）：データはあるのに、質問に合う箇所を引き当てられない
- 生成AIの問題（モデル側）：渡された根拠を取り違える。ただし割合は最も小さい
この記事は、開発リーダーとAI推進担当が「自社のPoCはどの軸で止まっているのか」を切り分け、本番化に向けて何を直すべきかを判断するためのものである。文書整備・検索設計・評価設計まで含めて本番化を前提に組み直したい場合は、RAG導入の要件定義（enterprise-rag）が起点になる。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
情シス部門の稟議書作成をサポートする無料の30分壁打ち。費用対効果 試算シート・失敗要因チェックリストをその場で共有します。
なぜRAGは本番に行かないのか：検索側の問題の具体
RAGの仕組みは単純化すると「質問 → 社内データから関連箇所を検索 → 取得した文章を根拠にLLMが回答」という流れだ。チャットだけのAIと違い、RAGの品質はLLMの性能より前段の「何を引いてきたか」でほぼ決まる。
LLM単体の素の精度はむしろ高い水準に達している。RAGの根拠忠実性を継続評価するVectaraのHallucination Leaderboard（※Vectara hallucination-leaderboard、2026年5月11日更新）では、要約タスクで上位モデルのハルシネーション率は1.8〜3%台まで下がっている。一方で、同じ評価でも小型・旧世代モデルでは20%超になるものもあり、モデル間の差は大きい。
ここで重要なのは、Leaderboardが測っているのは「与えた文書の範囲内で正しく要約できるか」という根拠忠実性であって、「正しい文書を引いてこられるか」ではない点だ。検索側が間違った文章を渡せば、どれだけ賢いモデルでも誤った前提で回答する。RAGの失敗の大半が検索・文書側に出るのは、この構造の必然である。
検索側でPoCが止まる典型は次のとおり。
| 検索側の症状 | 起きていること | 利用者から見えること |
|---|---|---|
| 関連文書を引けない | 質問の言葉とドキュメントの言葉が一致しない（同義語・略語・社内用語） | 「該当なし」「分かりません」が多い |
| 古い文書を引く | 旧版・廃止済み手順がインデックスに残る | 自信ありげに古いルールを案内する |
| 断片を引く | 1ファイルに情報が分散・表や画像内に情報がある | 回答が中途半端、肝心の条件が抜ける |
| 似て非なる文書を引く | 製品違い・部署違い・例外条件の取り違え | もっともらしいが対象が違う回答 |
| 権限を無視して引く | アクセス制御がインデックスに反映されない | 見せてはいけない情報が回答に混ざる |
これらはモデルを上位版に差し替えても解決しない。検索対象データの構造・鮮度・権限・分割（チャンク）設計の問題だからだ。PoCで「賢いモデルに変えたら少し良くなった」が「本番品質には届かない」とき、原因はほぼ検索側にある。
失敗3軸の自己診断チェック
自社のRAG PoCがどの軸で止まっているかを切り分けるチェックリスト。3軸それぞれで「はい」が多いほど、その軸が本番化の障害になっている。
軸1：回答品質（文書側）— 46%が止まる場所
- 回答の根拠になる社内文書が、最新版かどうか誰も保証できない
- 同じテーマの手順書・FAQ・マニュアルが複数あり、内容が食い違う
- 重要な情報が個人のメール、チャット、口頭、ベテランの頭の中にある
- PDFや画像、スキャン文書が多く、本文がテキストとして取り出せない
- 廃止・改定された古い文書が、現役文書と区別なく保管されている
- 「正解」を定義した評価用の質問・回答セットが存在しない
軸2：データ連携・検索（検索側）— 42%が止まる場所
- 質問に出てくる略語・社内用語・製品名でうまく検索が当たらない
- 複数システム（CRM、基幹、ファイルサーバ、SaaS）にデータが分散している
- 表・箇条書き・階層構造を持つ文書が、ぶつ切りでインデックスされている
- 部署や顧客ごとのアクセス権限を、検索結果に反映できていない
- どの質問でどの文書が引かれたか（検索ログ）を確認する手段がない
- データ更新時にインデックスを自動で再構築する仕組みがない
軸3：生成・運用（モデル/体制側）— 12%＋運用
- 根拠（出典）を示さずに回答だけ返す設計になっている
- 回答の良し悪しを人が評価し、改善に回す担当・サイクルが決まっていない
- 誤回答が出たときに、誰が原因を切り分けるか決まっていない
- 本番運用後の文書更新責任（誰が最新化するか）が未定
割合が示すとおり、優先すべきは軸1と軸2である。生成AIモデルの差し替えは、軸1・軸2を整えた後に効いてくる。順番を間違えると、高性能モデルにコストを払いながらPoC品質のまま停滞する。
品質とデータ連携をどう改善するか
回答品質（文書側）の改善
文書側の46%は、AI以前の「情報管理」の問題である。改善は地味だが効果が大きい。
| 打ち手 | 内容 | 効果 |
|---|---|---|
| 対象文書の棚卸し | RAGに読ませる文書を絞り、最新版だけを残す | 古い回答・矛盾回答の削減 |
| 正本の一元化 | 同テーマの重複文書を統合し、正本を1つに決める | 食い違いの解消 |
| 構造化 | 表・条件・例外を本文テキスト化し、見出しを整える | 引きやすく・読ませやすくなる |
| 評価セット作成 | 想定質問と正解を50〜100問用意する | 改善の良し悪しを数値で判断できる |
| 更新責任の明確化 | 文書ごとに最新化の担当を決める | 本番後の品質劣化を防ぐ |
特に評価セット（質問と正解の組）は本番化の生命線だ。これがないと「良くなった気がする」で意思決定することになり、検収条件も曖昧になる。キヤノンITSの228件評価も、問い合わせ実例を正解基準に照らしたからこそ原因を割合で示せている。
データ連携・検索側の改善
検索側の42%は、設計とエンジニアリングで対処する領域である。
| 打ち手 | 内容 | 効果 |
|---|---|---|
| チャンク設計の見直し | 文書を意味のまとまりで分割し、見出し・メタ情報を付与 | 断片・取り違えの削減 |
| ハイブリッド検索 | ベクトル検索とキーワード検索を併用 | 略語・固有名詞のヒット率向上 |
| メタデータ絞り込み | 部署・製品・有効期限・権限でフィルタ | 対象違い・古い文書の混入防止 |
| 権限の反映 | 利用者の権限を検索段階に連動 | 見せてはいけない情報の遮断 |
| 検索ログの可視化 | 何を引いたかを記録・確認 | 誤回答の原因切り分けが可能に |
| 再インデックス自動化 | データ更新を検索に自動反映 | 鮮度の維持 |
検索側の改善は、回答に出典（どの文書のどこを根拠にしたか）を必ず表示する設計とセットにするとよい。出典が見えれば、誤回答が「文書が悪いのか／検索が悪いのか／モデルが悪いのか」を運用者が切り分けられ、改善が回り始める。
本番化に必要なのは「PoCの作り方」を変えること
PoC止まりの多くは、PoCを「動くか試す」だけで設計してしまうことに起因する。本番に届くPoCは、最初から次を含む。
- 正解を定義した評価セットで、品質を数値（正答率）で測る
- 失敗ケースを3軸（文書／検索／生成）に分類して記録する
- 出典表示・権限制御・検索ログを、PoC段階から本番と同じ考え方で入れる
- 文書更新と評価のサイクル（誰が・いつ）を運用設計として決める
この前提でPoCを設計しておくと、本番審査やセキュリティレビューで止まりにくくなる。逆に、これらが抜けた安価なPoCは、本番化フェーズで要件定義をやり直すことになり、結局割高になる。
自社のPoCが本番に進める状態かを切り分けたい場合は、PoC本番化の準備状況診断で現状の評価設計・データ整備・運用体制のギャップを確認できる。
FAQ
Q. RAGがPoCで止まるのは、選んだLLMが弱いからですか。 A. データ上はそうではない可能性が高い。キヤノンITSの社内検索PoC（228件評価）では、Bad評価の原因のうち生成AIの精度が問題だったのは12%にとどまり、文書の不備46%・検索精度42%が大半を占めた（※キヤノンITソリューションズ テクニカルレポート）。まず文書と検索を疑うのが定石である。
Q. 高性能なモデルに変えれば回答品質は上がりますか。 A. 上限は上がるが、検索側が誤った文書を渡している限り、誤った前提での回答は減らない。Vectaraの評価（※Vectara hallucination-leaderboard、2026年5月11日更新）でも上位モデルの根拠忠実性は高いが、それは「正しい文書を与えた場合」の話である。文書・検索の改善が先である。
Q. まず何から手をつけるべきですか。 A. (1) RAGに読ませる文書を最新版に絞る、(2) 想定質問と正解の評価セットを作る、(3) 回答に出典を表示する。この3つで「どこで失敗しているか」が見えるようになり、改善が回り始める。
Q. データが複数システムに分散しています。全部つなぐ必要がありますか。 A. 最初は不要。問い合わせ頻度の高い1業務に対象を絞り、その業務の正本文書だけを整備して本番品質に到達させる方が、全社一括より成功率が高い。横展開はその後でよい。
Q. PoCの「成功」はどう判定すべきですか。 A. 体感ではなく、評価セットに対する正答率で判定する。あわせて、未回答率・誤回答時の原因分類・出典の妥当性を見る。検収条件として正答率の目標値を先に決めておくと、本番化の意思決定がぶれない。
この記事を読むべき人
- RAGのPoCは動いたが、本番化の判断ができずに止まっている開発リーダー
- 「賢いモデルに変えれば良くなる」という前提で予算を組もうとしているAI推進担当
- 社内文書が古い・分散している状態でRAG導入を検討している情報システム部門
- RAG/社内検索の外注を検討中で、要件定義に何を含めるべきか迷っている担当者
GXOに相談すべきタイミング
- PoCの回答品質が本番水準に届かず、原因が文書側か検索側か切り分けられない
- 社内文書が古い・重複・分散していて、RAGに読ませる前の整備から必要
- 複数システムにまたがるデータ連携と権限制御を、本番運用に耐える形で設計したい
- PoCをやり直さず、本番化を前提としたRAG導入の要件定義から組み直したい
GXOでは、RAGの評価設計・文書整備・検索（データ連携）設計・運用体制づくりを一体で支援し、PoCで終わらないAI導入を伴走する。自社のAI活用余地の見極めから始めたい場合はAIアセスメント、技術伴走を含めて本番化まで進めたい場合はFDE+による導入伴走が起点になる。
関連記事
あわせて読みたい特集
参考資料
- キヤノンITソリューションズ テクニカルレポート「『生成AI導入の知見』 RAG導入で社内検索はどう変わった？ 実践から得た学びと課題」 https://www.canon-its.co.jp/column/tech-report/06
- Vectara "Hallucination Leaderboard"（2026年5月11日更新） https://github.com/vectara/hallucination-leaderboard
本記事は2026年6月25日時点の公開情報をもとに作成。引用した統計は出典元の調査条件（キヤノンITSは自社サポートセンター内の社内検索PoC・228件評価）に基づくものであり、すべての環境に一般化できるとは限らない。RAG導入の判断は各社のデータ・運用要件にあわせて確認すること。
RAGのPoC、文書側で止まっていませんか
GXOでは、評価セット設計・文書整備・検索（データ連携）設計・運用体制を一体で見直し、PoC止まりを本番化につなげます。
PoC本番化の準備状況を診断する RAG導入の要件定義を相談する
※ 既存PoCの評価データがなくても相談可 | 開発リーダー・AI推進・情シスの同席歓迎
