自社データで生成AIを活用するRAGの始め方|必要なデータ量と準備手順

RAG生成AI社内データナレッジマネジメントDX

自社データで生成AIを活用するRAGの始め方|必要なデータ量と準備手順自社データで生成AIを活用するRAGの始め方|必要なデータ量と準備手順

「自社データで生成AIを動かしたい、でも何から始めれば?」で固まっていませんか

「役員から『うちのデータで生成AIを動かしてくれ』と言われたが、何のデータをどう食べさせれば良いのか分からない」「RAGという言葉は聞いたが、自社の文書がそのまま使える状態にあるのかどうかさえ判断できない」「ベンダーから『データを整えてからお持ちください』と言われたが、何をどこまで整えれば『整った』と言えるのかが分からない」「PoCで成功したのに、本番に拡げようとした瞬間にデータ整備の沼にハマって半年止まっている」——いま、こうした行き詰まりに直面している経営企画・情シス・DX推進担当の方が、本当に増えています。

RAG(Retrieval-Augmented Generation:検索拡張生成)は、いま最も現実的な企業向けAI活用手段です。社内のPDF・Word・Wiki・議事録などを生成AIに読ませて、自社固有の業務質問に答えさせる、という使い方は、ChatGPTの一般機能ではどうしても再現できません。一方で、RAG導入を阻む最大の壁は、技術ではなくデータの状態にあります。本記事は、その壁の正体と、最初の一歩の踏み方を、現場感覚で解説します。

「データ量さえあればRAGは動く」というのは、よくある誤解です

RAG導入の相談を受けるとき、最初によくある質問が「データはどれくらい必要ですか?」というものです。実はこの問いは、本質的にはあまり意味がありません。RAGに必要なのは「量」ではなく「業務質問に答えるための、最新で・正確で・検索しやすい状態の情報」だからです。

たとえば10年分の社内文書20万件があっても、その7割が古い版数・8割が表記揺れだらけ・5割が誰がいつ書いたか分からない、という状態なら、RAGに食わせた瞬間に「過去の誤った情報を堂々と答えるAI」が誕生します。生成AIは、与えられた情報の中から「もっとも質問に近い文書」を取ってきて答えを組み立てるため、ゴミを食べさせればゴミを答えます。

逆に、業務手順書がたった50ページでも、それが最新版で、用語が統一されており、章立てが整っていれば、RAGはその50ページの中から驚くほど精度の高い回答を組み立てます。「データ量を増やせばAIが賢くなる」のは、生成AIモデル自体の学習の話であって、RAGに必要なのは、量より「使える状態」です。これを最初に経営層と共有しておかないと、プロジェクトは必ずデータ整備の沼にハマります。

この記事を読み終える頃に、自社の「最初の一歩」が見えています

本記事では、RAG導入のためのデータ量の現実的な目安、社内文書を「使える状態」に整える準備手順、PoC〜本番展開のロードマップ、そしてプロジェクトを止めないための優先順位の付け方を整理します。読み終える頃には、自社で「来週、まずこの業務領域のこのデータから始めてみよう」と言える最初の一歩が、頭の中で組み立てられる状態を目指します。

データ量の感覚値、文書整備の作業工程、社内合意形成の進め方、ベンダー選定のときに見るべき視点まで、生成AI導入を本格的に検討している段階の方が、社内稟議の前に整理しておきたい論点を一通り盛り込みました。

RAGに必要なのは「量」より「使える状態」RAGに必要なのは「量」より「使える状態」

RAGに必要なデータ量と「使える状態」の現実的な目安

データ量と質の両面から、現実的な目安を整理します。

量の目安:PoCなら数百ページ、本番でも数万ページレベル

PoC(試験運用)レベルであれば、特定の業務領域に関する社内文書が数十〜数百ページあれば、RAGの効果を体感する材料として十分です。たとえば人事規程・経理マニュアル・特定製品の技術仕様書・営業の提案書テンプレート集——いずれかの1領域に絞れば、1,000ページを超えることはまずありません。

部署単位の本番運用に拡げるフェーズでも、文書量としては数千〜数万ページのレンジに収まることが多く、これは大規模な社内文書管理基盤の話とは、桁が違います。RAGは、検索エンジン的に「質問に近い文書を数件取ってくる」仕組みのため、社内のすべての文書を食べさせる必要は無く、業務質問の対象範囲を絞り込むほど精度が上がる、という特性があります。

数十万ページの社内文書を全部食べさせる、という設計は、初期の段階では避けるべきです。データ量が増えるほど、検索精度の調整・データ整備コスト・運用コスト・誤った情報を答えるリスク、いずれも非線形に膨らみます。最初は「業務質問の頻度が高い1領域」に絞って、効果を体感してから拡張するのが鉄則です。

質の目安:「最新性・正確性・検索可能性」の3条件

データ量より重要なのが、文書が次の3つの条件を満たしているかです。

第一に最新性。社内に散らばっている同じ文書の複数版数のうち、どれが現行版なのかが明示されており、古い版がRAG投入対象から除外されている状態。第二に正確性。誤情報・誤った数値・廃止された手順が混入していないこと、文書の責任所在が明確であること。第三に検索可能性。PDFが画像のスキャンではなくテキスト抽出可能であること、用語表記が統一されていること、章立てや見出しが付いていること。

この3条件を満たしていない文書は、量がいくらあってもRAGの精度を引き上げません。むしろ、満たさない文書を食べさせると、生成AIは「古い情報・誤った情報・検索ノイズ」を堂々と答え始めます。最初の準備工程の8割は、この3条件を満たすための文書クレンジングと言ってよいです。

自社データをRAGに乗せる準備手順(5ステップ)

具体的な準備手順を、PoC立ち上げを想定して5ステップで整理します。

ステップ1:業務質問の棚卸し——「答えさせたい質問」を100個書き出す

最初にやるべきは、データの棚卸しではなく、業務質問の棚卸しです。「自社のRAGで、社員から飛んでくるであろう質問を100個書き出す」という作業を、最初の1週間で完了させます。

これをやらないと、データ整備の優先順位が立ちません。たとえば「人事規程に関する質問が60件、製品仕様に関する質問が30件、経理処理に関する質問が10件」と判明すれば、最初に整えるべき文書群は人事規程である、と即座に決まります。逆にいきなり社内Wiki全体のクレンジングから始めると、ゴールが見えないまま半年が溶けます。

ステップ2:対象業務領域の選定——1領域に絞り込む

業務質問の集計を見て、「最も質問頻度が高い」「答えの正解が明確である」「文書がある程度整っている」3条件が揃う領域を、PoC対象として1つだけ選びます。複数領域を同時に進めようとすると、必ず空中分解します。

迷ったら、人事規程・経理処理・社内システム操作マニュアル、のいずれかから始めるのがおすすめです。これらは「正解が文書として確実に存在し」「質問頻度が高く」「誤答時の業務影響が比較的限定される」という、PoCに向いた条件を満たしています。

ステップ3:文書クレンジング——版数・表記・形式を統一する

選んだ業務領域の文書について、版数管理を整理し、現行版だけをRAG投入対象として明確化します。次に表記揺れを統一し(「顧客」「お客様」「クライアント」のような揺れを、業務語彙集としてまとめる)、画像スキャンのPDFはテキスト抽出ができるOCR処理を実施します。

この作業は、想定よりはるかに重いです。たとえ100ページの規程集でも、複数の改定履歴・添付別紙・参照先のリンク切れ・表記の揺れ、を整えると、延べ数十〜数百時間規模の作業量になります。社内人員だけで進めると、本業を圧迫してプロジェクトが頓挫するパターンがよくあります。

データ整備の工数を、最初の段階で経営層と合意しておくことが、プロジェクト存続の鍵になります。社内に専任の整備リソースが無く、技術選定と並行してデータ整備の伴走パートナーが必要であれば、アトリエ・バイナリ(atelier binary) のような、生成AI業務活用に伴走するパートナーに、要件整理とデータ整備の両面で支援を入れるのが、現実的な選択肢になります。「ベンダーに丸投げしたが、データだけは社内で整えなければならず、結局誰も動かなかった」という失敗を防ぐためのリソース確保は、最初に手をつけるべき論点です。

ステップ4:メタデータ付与——文書に「タグ」を付ける

文書本文だけでなく、各文書に「業務領域」「責任部署」「最終更新日」「機密度」「対象社員」のようなメタデータをタグとして付与します。これは、RAG運用時の検索精度と、機密情報の取り扱い精度を、両方押し上げます。

たとえば「役員のみ閲覧可能な人事資料」が、一般社員からの質問に対する回答に紛れ込まないようにするには、機密度タグが必須です。最終更新日のタグがあれば、「半年以上更新されていない文書を回答候補から外す」というような運用ルールを設計できます。メタデータ設計は、PoC段階では最小限で構いませんが、本番展開フェーズで必ず必要になる前提作業です。

ステップ5:PoC実装と振り返り——回答精度を業務質問で評価する

ステップ1で書き出した「業務質問100個」のうち、対象業務領域に該当するものを、PoC実装後のRAGに投入し、回答精度を評価します。評価軸は3つで十分です。回答が事実として正確か、回答に根拠となる文書出典が示されているか、回答のトーンが業務利用に耐える日本語になっているか。

精度が低い質問群があれば、原因が「データの欠落」「データの古さ」「検索チューニング不足」のいずれかを特定し、必要なデータを補強したり、検索パラメータを調整します。PoCの目的は完璧な回答を出すことではなく、「データ整備の方向性が正しいか」「本番展開時のコスト感が見積もれるか」を確認することです。

自社データをRAGに乗せる5ステップ自社データをRAGに乗せる5ステップ

こんな方にRAG導入の準備手順を整理することをおすすめします

  • 経営層から「うちのデータで生成AIを動かして」と言われたが、何から手をつけるべきか分からず止まっている経営企画・DX推進担当の方
  • ベンダーから「データを整えてからお持ちください」と言われ、何をどこまで整えれば良いのかの基準が掴めていない情シス・業務改善担当の方
  • PoCで成功したものの、本番展開しようとした瞬間にデータ整備の沼にハマって半年止まっており、進め方を立て直したいプロジェクト責任者の方

RAG導入は、技術選定よりもデータの状態整理のほうが、成否を分ける比重がはるかに大きい領域です。1領域に絞って、業務質問から逆算してデータを整える、というアプローチを取れば、3ヶ月以内に最初の効果体感まで到達できます。逆に「全社の文書をとにかく整えてから」と総花的に進めると、9割のプロジェクトが1年経っても動きません。手をつけるなら、業務質問頻度の高い1領域から、来週にも始めるのが正解です。

まとめ

RAGは「使える状態のデータ」から立ち上がるRAGは「使える状態のデータ」から立ち上がる

自社データでRAGを動かす最初の一歩は、データ量を集めることでもベンダーを選ぶことでもなく、「業務質問を100個書き出して、対象業務領域を1つに絞る」ところから始まります。RAGに必要なのは量ではなく、最新性・正確性・検索可能性の3条件を満たした、業務質問に答えるための文書群です。PoCレベルなら数百ページ、部署単位の本番運用でも数千〜数万ページのレンジで十分機能します。

準備手順は5ステップ——業務質問の棚卸し、対象業務領域の選定、文書クレンジング、メタデータ付与、PoC実装と振り返り——で構造化できます。特にステップ3の文書クレンジングは、想定の3〜5倍の工数になりがちで、ここを最初に経営層と合意しておくか、外部の伴走パートナーを入れておくかが、プロジェクト存続の分かれ目になります。

大切なのは、最初から完璧を目指さないことです。1領域に絞って、業務質問から逆算して、3ヶ月で最初の効果体感まで到達する——この小さな成功体験が、社内の生成AI活用の機運を一気に動かします。来週、社員から飛んでくる業務質問を100個書き出す、というたった1つの作業から始めてみてください。ここから先のロードマップが、自然と見えてきます。

関連記事