社内文書を参照して回答するAI（RAG）を導入したものの、「期待した精度が出ない」という相談は多い。回答がずれる、古い情報を返す、根拠が示されない。こうした症状を見て「モデルの性能が足りない」と考えがちだが、原因の多くは参照する社内文書と検索の設計にある。
本記事では、RAGの精度が出ない理由を発注者の視点で整理し、発注前に確認すべき項目と開発会社への質問を示す。RAGの仕組みを細かく理解する必要はない。発注者として「どこを整理すれば精度に効くのか」が分かれば十分である。
結論：RAGの精度はモデルより先に文書と評価で決まる
RAGの回答精度を上げる近道は、いきなり高性能モデルへ替えることではない。GXOがRAG開発の相談で最初に見るのは、参照文書の範囲、最新版の管理、文書分割、権限、根拠表示、評価データの有無である。
- 答えさせる業務と質問範囲を絞る
- 最新版、部署、版、権限などのメタデータを付ける
- 想定質問と正解例を用意し、改善前後を比較する
この土台がないまま発注すると、回答がずれても原因を切り分けられず、感覚的なチューニングに陥りやすい。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
RAGの回答は「参照する文書」で決まる
RAGは、質問に関連する社内文書を検索し、その内容をもとに回答を組み立てる仕組みである。つまり、回答の質は次の3つでほぼ決まる。
- 参照する文書がそろっていて、最新であること
- 質問に対して、関連する文書を正しく見つけられること
- 見つけた文書の内容を、根拠として示しながら答えられること
このどれかが崩れると、モデルがどれだけ高性能でも精度は出ない。逆に言えば、発注者が整理できるのは主に1と2である。ここを放置したままモデルだけを期待すると、精度は安定しない。
なぜRAGの精度が出ないのか
検索対象の文書が決まっていない
「社内のあらゆる文書を参照させたい」という要望は多いが、対象が広すぎると関連性の低い文書まで拾い、回答がぶれる。どの業務の、どの質問に答えさせるのかを絞らないと、検索対象が定まらない。
文書の分割（チャンク）が業務に合っていない
RAGは長い文書を一定の単位に分割して検索する。この分割が雑だと、回答に必要な文脈が途中で切れ、不完全な回答になる。表や図、Q&A形式の文書は特に分割の影響を受けやすい。
メタデータがなく、新旧・部署を区別できない
文書に「作成日」「対象部署」「版」といった情報（メタデータ）が付いていないと、古い文書と最新版を区別できず、古い情報を最新として返してしまう。
権限の設計がない
誰でも全文書を参照できる設計だと、本来は限られた人しか見られない情報が回答に混ざる。逆に権限を厳しくしすぎると、必要な文書が検索対象から外れて精度が落ちる。権限とログの設計はAIエージェントに権限を渡す前の落とし穴にも通じる論点である。
回答の根拠が示されない
根拠となる文書を提示しない設計だと、利用者は回答の正しさを確認できず、信頼されない。結果として使われなくなる。
評価データがなく、精度を測れない
「正しい回答の集合」がないと、精度を客観的に測れない。改善したのか悪化したのかも分からず、チューニングが感覚的になる。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
精度が出ない原因と、発注前の対策
横にスクロールして確認できます
| 症状 | 主な原因 | 発注前に整理しておくこと |
|---|---|---|
| 回答がずれる | 検索対象が広すぎる | 答えさせる業務と質問の範囲を絞る |
| 文脈が途切れた回答になる | 文書の分割が業務に不適 | 文書の種類（表・Q&A・手順書）を共有する |
| 古い情報を返す | メタデータ・版管理がない | 文書の最新版と更新ルールを整える |
| 見てはいけない情報が混ざる | 権限設計がない | 文書ごとの閲覧範囲を整理する |
| 回答を信用できない | 根拠の提示がない | 根拠表示を要件に含める |
| 改善しているか分からない | 評価データがない | 想定質問と正解例を用意する |
精度の改善は、モデルの差し替えよりも、この左の症状を一つずつ潰すほうが効くことが多い。
精度を上げるときに見直す順序
RAGの精度が出ないとき、いきなり高性能なモデルへ乗り換えるのではなく、影響の大きい要素から順に見直すと原因にたどり着きやすい。次の順序が一つの目安になる。
- 検索対象を絞る：答えさせたい質問の範囲に対して、参照する文書が広すぎないかを見直す。関係の薄い文書が混ざっていると、関連性の判定がぶれて回答も揺れる。
- 文書の分割を見直す：回答に必要な文脈が途中で切れていないかを確認する。手順書やQ&Aは、意味のまとまりごとに区切ると改善しやすい。
- メタデータと最新版を整える：作成日や版の情報を付け、古い文書が検索の上位に来ないようにする。
- 根拠の提示を確認する：回答に参照元を示し、利用者が正しさを自分で確かめられるようにする。
- 評価データで測る：想定質問と正解例を用意し、見直しの前後で精度がどう変わったかを比較する。
この順序で一つずつ確認すると、「どこを直したら、どれだけ良くなったか」が見えるようになる。検索の方法（キーワードでの一致と、意味の近さでの検索）をどう組み合わせるかも精度に影響するが、まずは参照する文書と分割を整えるほうが効果が出やすい。モデルの差し替えは、これらを見直した後の選択肢として考えるとよい。
特に評価データは、改善の土台になる。評価データがあれば、改善が前進しているのか後退しているのかを客観的に判断できる。逆に、評価データがないまま手を加えると、感覚的なチューニングになり、ある質問では良くなっても別の質問で悪くなる、といったことに気づけない。発注前に、想定質問と正解例を数件でも用意しておくと、運用開始後の改善が安定する。
発注前に確認すべき項目
RAGを発注する前に、次の項目を社内で確認しておきたい。
- このRAGに答えさせる業務と質問の範囲を一つに絞ったか
- 参照させる文書を洗い出し、最新版がどれか分かる状態か確認したか
- 文書に表・図・Q&A・手順書など、分割が難しい形式が含まれるか把握したか
- 文書の作成日・対象部署・版などのメタデータを付けられるか確認したか
- 文書ごとの閲覧権限（誰が見てよいか）を整理したか
- 回答に根拠（参照元）を表示する要件を入れたか
- 想定質問と、その正解例（評価データ）を用意できるか確認したか
- 文書を更新したとき、誰がいつ反映するかの運用を決めたか
評価データと文書の最新版管理は、発注後では用意が難しい。発注前に着手しておくと精度の立ち上がりが早い。
開発会社に確認する質問
横にスクロールして確認できます
| 質問 | 確認したいこと |
|---|---|
| 参照対象の文書はどう絞り込みますか | 検索対象の設計方針があるか |
| 表やQ&A形式の文書はどう分割しますか | 文書形式への対応力があるか |
| 古い文書と最新版はどう区別しますか | メタデータ・版管理の設計があるか |
| 回答の根拠はどう提示しますか | 根拠表示を標準で実装するか |
| 精度はどの指標で、どう測りますか | 評価の仕組みを持っているか |
| 精度が出ないとき、どこから改善しますか | 改善の手順を説明できるか |
「高性能なモデルを使うので大丈夫」という回答だけでは不十分である。文書と検索の設計にどう踏み込むかを確認したい。
GXOに相談する前に整理するとよい情報
- 答えさせたい業務と、よくある質問の例（数件でよい）
- 参照させたい文書の種類、量、保管場所（共有フォルダ、グループウェアなど）
- 文書の最新版がどこにあり、誰が更新しているか
- 文書ごとに「誰が見てよいか」の制約があるか
- すでにRAGやチャットボットを試したことがあれば、その結果
文書の状態が分かると、「精度を上げるために何を整えるべきか」を具体的に提案できる。RAGの費用感はRAG開発の費用ガイドも参考になる。
参考にした外部観点
RAGは検索、生成、権限、ログが組み合わさるため、品質だけでなくリスク管理も発注前に見る必要がある。NIST AI Risk Management FrameworkはAIのリスク管理を組織的に扱う枠組みであり、OWASP Top 10 for Large Language Model ApplicationsはLLMアプリケーションの代表的なリスクを整理している。
実務では、最初から全社文書を対象にせず、想定質問10件、正解例10件、検証対象文書30件程度から始め、3ヶ月で改善サイクルを確認するほうが原因を切り分けやすい。
関連記事
GXOの見解
AI導入はツール追加ではなく、業務フロー、権限、ログ、停止条件、責任分界を同時に設計する経営課題として扱う。
GXOはPoC単体ではなく、現場業務に残る承認、例外処理、監査証跡まで見て本番運用に落とすべきだと見る。
GXOは、AI活用の構想整理から要件定義、社内ルール、システム連携、運用改善まで一気通貫で支援します。
実務判断のポイント
この記事は、経営者、DX責任者、情シス、開発責任者向けです。AI導入前の業務棚卸し、権限設計、PoC、本番運用、AI利用規程を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。AI開発発注の失敗図鑑｜RAGの精度が出ない理由に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの実務補足
AI導入はツール追加ではなく、業務フロー、権限、ログ、停止条件、責任分界を同時に設計する経営課題として扱う。
GXOはPoC単体ではなく、現場業務に残る承認、例外処理、監査証跡まで見て本番運用に落とすべきだと見る。
GXOは、AI活用の構想整理から要件定義、社内ルール、システム連携、運用改善まで一気通貫で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、AIアセスメント、PoC、業務システム連携、AIエージェント運用設計へ接続。さらに、診断テンプレートと標準設計を使い、短期診断から継続伴走へ展開。
実行までの進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問
Q1. モデルを高性能なものに変えれば精度は上がりますか
モデルの差で改善する部分はあるが、参照する文書や検索の設計が崩れていると、モデルを変えても精度は安定しない。先に文書と検索を整えるほうが効果は大きい。
Q2. 文書がきれいに整理されていないと、RAGは始められませんか
完璧な整理は不要だが、対象を絞り、最新版を特定し、評価用の質問を数件用意するだけでも立ち上がりは大きく変わる。整備の論点は社内データの品質管理で詳しく扱う。
RAGの精度を、発注前に出やすくしませんか
GXOでは、RAGの参照文書、メタデータ、権限、根拠表示、評価データを発注前に整理し、回答精度を改善しやすい設計をご支援します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
