「社内の手順書やマニュアルを、ChatGPTのように質問するだけで答えてほしい」——そのための仕組みがRAG（Retrieval-Augmented Generation：検索拡張生成）です。生成AIに社内文書を「検索させてから」答えさせることで、学習し直さずに自社の最新情報へ答えられるようになります。

ただし、RAGは「ツールを入れれば動く」ものではありません。本記事では、RAG構築を検討する事業会社の担当者に向けて、構築の6ステップ・精度を上げる勘所・つまずきやすい落とし穴・PoC（試験導入）の進め方を、実装現場の一次情報をもとに整理します。

結論：RAG構築は「検索8割・文書整備が先・PoCで小さく」が成功の型

先に結論をお伝えします。RAG構築でつまずく企業の多くは、生成AI（LLM）の性能ではなく、その手前で失敗しています。成功の型は次の3点に集約されます。

1. 精度は「検索」の作り込みで9割決まる。 LLMを賢いものに差し替えるより、文書の刻み方や検索方法の改善が効きます。実際、現場でも「良いRAGと悪いRAGの差は、ほぼ常に検索層にある」と語られています（出典：Towards AI / Production RAG）。
2. AI導入より「元文書の整備」が先。 ある試験運用では、回答が不十分だった原因の46%が「文書の不備・不足」でした（出典：キヤノンITソリューションズ）。答えがそもそも文書に書かれていなければ、どんなRAGでも答えられません。
3. 最初から完璧を狙わず、PoCで小さく始める。 「80点は簡単、90点は大変、100%はまず無理」が業界の共通認識です。改善サイクルを前提に設計します。

RAGとは：社内文書を「検索してから生成AIに答えさせる」仕組み

RAGの基本構造は「検索＋生成」

RAGは、ユーザーの質問に対して、(1) 社内文書から関連する箇所を検索（Retrieval）し、(2) その箇所を根拠として生成AIに回答を生成（Generation）させる、2段構えの仕組みです。生成AIは「与えられた資料を読んで答える」役割に徹するため、自社固有の情報にも答えられます。

なぜ社内文書検索にRAGが向くのか

社内文書検索でRAGが選ばれる理由は3つあります。

• (1) 学習し直す必要がない——文書を入れ替えるだけで内容を更新できます。生成AIを自社データで再学習（ファインチューニング）する必要がありません。
• (2) 最新情報を反映できる——規程やマニュアルの改訂にすぐ追従できます。
• (3) 根拠（引用元）を提示できる——「どの文書のどこから答えたか」を示せるため、担当者が回答を検証できます。

社内利用では、この「根拠の提示」が信頼の土台になります。RAGは、社内向けFAQ自動応答やナレッジベース検索、問い合わせ対応の下書き生成といった生成AIの社内導入の中核を担う技術です。

長文コンテキスト・ファインチューニングとの使い分け

「全文をAIに丸ごと読ませれば良いのでは？」という疑問もあります。ClaudeやGeminiは100万トークン超の長文を扱えますが、文書が増えると情報過多で判断品質が落ち、コストも非線形に膨らみます（出典：Starmorph）。精度と引用が求められる社内文書検索はRAG、対話の文脈保持は長文コンテキスト、という使い分けが現実解です。

RAG構築の進め方：6ステップ

RAG構築は、おおむね次の6ステップで進みます。

STEP1 データ収集・前処理：実は「言語化」が最大の壁

社内文書（Word・PDF・Excel・PowerPoint）を集め、テキストに変換します。ここが最大のボトルネックです。スキャンされたPDFや画像、表・図中の情報は、そのままでは検索に乗りません。実装現場でも「RAGではない部分（文書を言語情報に変換する工程）こそが要」と指摘されています（出典：Algomatic Tech Blog）。AI導入の前に文書を棚卸しする発想が欠かせません。考え方は業務可視化のやり方とも共通します。

STEP2 チャンク分割：日本語の実務目安と「表を割らない」

文書は、検索しやすい単位（チャンク）に分割します。日本語では500〜1,000文字程度＋前後100〜200文字の重なり（オーバーラップ）が実務の出発点です（出典：Qiita・Zenn）。用途で変え、FAQは短く（150〜300字）、技術文書は長め（1,000〜1,500字）にします。

注意したいのは、機械的な固定長分割が「表」を途中で割ってしまうこと。実際に「料金表が不完全だ」というクレームの原因が、表をチャンク間で分断していたことだった、という報告があります（出典：Towards AI）。見出しや論理セクション単位で分け、各チャンクに「どの章・節か」のパンくずを付けると精度が上がります。実際、論理セクション単位にしたことで法的文書の応答精度が65%→89%に改善した例も報告されています（出典：Zenn / RAG改善手法）。

STEP3 埋め込み：日本語で精度の出るモデルを選ぶ

各チャンクを「埋め込み（ベクトル）」という数値表現に変換します。日本語では、Gemini embedding、bge-m3、multilingual-e5-large などが高精度との検証結果があります（出典：note/NITI・Zenn/FP16）。OpenAIのtext-embedding-3-small/largeも定番で、自社サーバー内で完結させたい場合はruri-v3のような軽量ローカルモデルも選択肢になります。

STEP4 ベクトルDB：既存環境から逆算して選ぶ

埋め込みを保存・検索する「ベクトルデータベース」を用意します。選び方は環境から逆算するのが早いです。すでにPostgreSQLを使っていて件数が500万件未満ならpgvectorが最短。運用の手間を最小化したいならPinecone（マネージド）、オンプレ必須ならMilvusやQdrant、というのが実務の住み分けです（出典：Zenn）。コストはマネージドが月数千ドル規模になることもあり、自己ホストとの差は事前に見積もる必要があります。

STEP5 検索：セマンティック・ハイブリッド・リランキング

質問を埋め込みに変換し、近いチャンクを取り出します（セマンティック検索）。キーワード検索（BM25）と組み合わせるハイブリッド検索は強力ですが、万能ではありません。ある実験では、埋め込み単独のヒット率0.8355が、無調整のハイブリッドで0.7819にむしろ低下し、全文検索側を日本語向けにチューニングして初めて0.8954へ改善しました（出典：Ahogrammer）。検索結果を並べ替える「リランカー」も、初期検索が悪いときほど効きますが、すでに検索精度が高いと効果は限定的でレイテンシだけ増えます。

STEP6 生成：グラウンディングと引用の提示

最後に、取り出したチャンクを根拠として生成AIに回答させます。ここで効くのが、プロンプトでの「与えられた資料だけに基づいて答えよ」という強い制約と、引用元の提示です（出典：Taskhub）。さらに、類似度が一定（例：0.7）に満たないときは「正確に答えられません」と返す閾値設計を入れると、当てずっぽうの回答を抑えられます。

精度を上げる勘所：検索層とチャンク設計に投資する

RAGの精度改善は、LLMの差し替えより検索層への投資が効きます。優先順位は概ね次の通りです。

• チャンク設計を最優先で。 見出し単位＋パンくず付与、表の構造保持。改善幅が最も大きい領域です。
• ハイブリッド検索は「チューニング前提」で。 入れれば上がるとは限りません。日本語の全文検索（形態素解析）の調整とセットで。
• リランカーは費用対効果を見て。 改善が5〜10%でレイテンシに見合わないなら無効化する判断も現場では珍しくありません。
• 評価は数値で。 RAGASのような指標で「忠実性（根拠に沿っているか）」「関連性」を測り、どの指標が低いかを起点に施策を選びます（出典：RAGAS論文）。

よくある落とし穴：技術より「元文書」と「期待値」で失敗する

RAG構築の失敗は、技術以前のところに集中します。

• 元文書の不備・不足が最大の原因。 前述のとおり、回答が不十分な原因の約半数は文書側にあります。「返却期間が文書に書かれておらず答えられない」といった、AIではなく情報の欠落による失敗です。文書整備は業務改善コンサルティングの文脈で先に着手すべき領域です。
• ハルシネーション（もっともらしい嘘）はRAGでもゼロにならない。 RAGを採用した法務向けAIツールでも、誤りが17〜33%残ったというスタンフォード大学の検証があります（出典：Stanford RegLab）。残存を前提に、引用提示と閾値設計で「検証できる導線」を作ります。
• 100点を狙わない。 80点→90点→100%とコストは急増します。最初から全社展開を狙わず、改善サイクルを要件に含めます。
• 権限管理を後付けにしない。 「誰がどの文書を見られるか」は検索段階でデータベースレベルに組み込みます。後付けは事故と性能劣化の元です。

PoCの進め方：小さく作り、「正答率」と「根拠提示率」で判断する

RAGは、PoC（試験導入）で小さく始めて検証するのが定石です。進め方のポイントは3つです。

(1) スコープを1業務に絞る。 全社文書をいきなり対象にせず、「特定部署のFAQ」「ある製品の手順書」など、答えの正解が明確な領域から始めます。

(2) KPIに「根拠提示率」を併設する。 正答率だけでなく、「引用元が正しく示されているか」を必ず測ります。担当者が答えを検証できることが、社内展開の前提条件になるからです。あわせて撤退基準（この水準に届かなければ見直す、という線）も先に決めておきます。

(3) 改善サイクルを要件に入れる。 一度作って終わりではなく、回答ログを見てチャンク・検索・文書を直し続ける運用を前提に設計します。

規模感の目安として、最初のPoCは対象を1業務（数十〜数百件の文書）に絞り、期間4〜8週間・体制2〜3名で回すのが現実的です。いきなり全社展開を狙わず、ここで「使える水準か」を見極めます。

費用感も「ツール代」だけで見ないことが大切です。PoC段階でかかるのは、主に(1) 埋め込み・生成AIのAPI利用料（社内文書の検証規模なら少額に収まることが多い）、(2) ベクトルDBの利用料（pgvectorなら既存DB内で実質ゼロ、マネージドは月数百〜数千ドル規模）、そして最も大きいのが(3) 人件費（前述の2〜3名×4〜8週）と文書整備の工数です。コストの中心は「AI」ではなく「文書整備と検証の人手」にある、と見積もっておくと判断を誤りません。

キュリオシティの社内文書検索PoC（匿名化した実務知見）
製造業向けの社内文書検索PoC（対象は特定部門の手順書、数十件規模）では、初期に固定長チャンクを使ったことで「手順書の途中で答えが切れる」事象が頻発し、初期の体感正答率は半分程度にとどまりました。見出し単位＋パンくず付与に切り替えたところ、実用域（おおむね8割前後）まで改善しました。最大のつまずきは技術ではなく元文書側——古い版・PDF画像・言語化されていない表が多く、AI以前に文書整備が必要でした。そこでKPIは正答率に加え「根拠提示率」を併設し、評価は業務を知る担当者が想定質問リストに対して回答と引用元の正誤を1件ずつ目視判定する方式としました。担当者が自分で答えを検証できる状態を、社内展開の条件としています。
※案件特定を避けた匿名表現。数値はレンジで記載。

RAGは「現場の業務と文書」を理解せずには作れません。私たちは現場主義 × AIの立場から、業務の棚卸しから一緒に設計します。RAGを含む生成AIの開発・PoCの支援内容は生成AI開発・PoC支援にまとめています。RAG・生成AIの社内活用をどう小さく始めるかは、まず無料テンプレートで企画の型を確認するところからどうぞ。実際の進め方は業務改善の事例集も参考になります。

まとめ：RAG構築は「検索・文書・PoC」で決まる

RAG構築の要点を、もう一度整理します。

• 精度は「検索」の作り込みで9割決まる。 チャンク設計と検索方法に投資する。
• AI導入より「元文書の整備」が先。 失敗原因の最大は文書の不備・不足。
• PoCで小さく始める。 1業務に絞り、正答率＋根拠提示率で判断し、改善サイクルを要件に入れる。

社内文書を生成AIで検索する取り組みは、ツール選定の前に「どの業務から・何を根拠に・どこまでを目標にするか」を決めることが成否を分けます。まずは小さなPoCから、確実に前へ進めましょう。

監修：大槻 伸夫（キュリオシティ株式会社 代表取締役CEO）。現場主義 × AI を掲げ、生成AI・PoC・PMI支援を統括。事業会社の業務改善とAI活用の実装を一気通貫で支援している。