「うちの育児休業規程では男性の取得期間は何日ですか？」と社内ChatGPTに聞いたら、「一般的な日本企業では〜」と当たり障りのない一般論が返ってきた。就業規則の最新版はSharePointにあるはずなのに、AIはそこを見に行ってくれない。
こういう経験、社内で生成AIを触っていると一度はぶつかるのではないでしょうか。ChatGPTやGeminiに社内文書を貼り付けて回答させる運用でしのいでいる会社も少なくないと思います。
正直に言うと、これは基盤モデル（LLM）そのものが賢くないわけではありません。モデルはあなたの会社の規程を見たことがないだけです。この「見たことがない情報」を毎回渡してから答えさせる仕組みが、RAG（Retrieval-Augmented Generation：検索拡張生成）です。
RAGの仕組みと構成要素、なぜ社内AIに必須なのか、実装で本当に必要になるデータ基盤の要件と落とし穴、そしてどこから手をつければ最短で動かせるかまで、情報システム部・データ基盤担当のマネージャーが発注や内製の判断に使える形でまとめます。
RAG（Retrieval-Augmented Generation：検索拡張生成）とは、大規模言語モデル（LLM）に回答させる前に、社内の文書データベースから関連情報を検索して取り出し、それをお手本として渡してから答えさせる仕組みです。
イメージとしては、AIを「賢いが自社のことは何も知らない新入社員」、社内文書を「書庫」、RAGを「書庫に資料を取りに行く調べもの係」だと考えるとわかりやすいと思います。質問が来るたびに、まず書庫から関連する棚を検索して該当ページを取り出し、そのコピーとともに「この資料をもとに答えて」とAIに渡す。この一連の流れがRAGです。
図のように、RAGは3つのフェーズで動きます。
決定的なポイントは、LLMは渡された資料の範囲でしか答えられないという制約を、逆手に取っていることです。渡す資料を自社の最新の規程・マニュアル・議事録に絞ることで、AIは「うちの会社では育児休業を最大1年取得できます（就業規則第32条）」のように、根拠つきで答えられるようになります。
この考え方はなぜAI時代にこそデータ基盤が必要か｜生成AIが失敗する理由でも触れていますが、本記事ではさらに一歩踏み込んで、実装の構成要素と落とし穴を扱います。
「ChatGPTのプロに聞けばだいたい答えてくれるのに、なぜわざわざRAGを作るのか」という疑問はよく出ます。ここは3つの理由で整理できます。
ChatGPTやGeminiの学習データには、あなたの会社の就業規則も、商品マスタも、去年の顧客とのやりとりも含まれていません。当然です。公開情報しか学習していないからです。
社内文書を貼り付けて質問する運用で当座はしのげますが、「毎回コピペするのは面倒」「文書量が多いと入りきらない」「社員が古い版を貼ってしまう」という問題が出てきます。RAGは、社内文書の検索と受け渡しを自動化する仕組みだと理解すると、位置づけがはっきりします。
「モデルに自社のデータを覚えさせればいい」と考えるのは自然ですが、これがファインチューニング（追加学習）です。実務で使ってみると、次の弱点が見えてきます。
対してRAGは、社内文書を更新すれば次の質問から即座に反映されます。回答に出典（どの文書から引いたか）を添えられるため、監査や責任の観点でも扱いやすい。知識の追加はRAG、振る舞いや文体の調整はファインチューニング、という使い分けが2026年時点の実務での定説です。
生成AIには、事実と異なる内容をもっともらしく作る「ハルシネーション（幻覚）」という弱点があります。2026年3月時点の調査でも、生成AIを業務利用しにくい理由として「ハルシネーション」を挙げた企業は35.2%と、根強い懸念になっています。
RAGは、AIの回答を信頼できる自社データに結びつける「グラウンディング」の代表的な手段です。「渡された資料の範囲で答えて」「根拠がなければ答えないで」と指示することで、幻覚の発生率を実務レベルまで下げられます。完全にゼロにはならないため、UIで出典リンクを必ず表示し、人間の目視チェックと組み合わせる運用が現実的です。
ここまでを踏まえて、なぜデータマネジメントそのものがDXやAIの成否を分けるかは、なぜ今データマネジメントが必要なのか？DX成功の本質を解説で整理しています。
もう少し踏み込んで、RAGを実装するときに何を用意することになるのかを見ていきます。ここは発注前の要件定義でも必ず出てくる話題です。
RAGは、質問が来る前に「書庫」を作っておく必要があります。この事前処理は次の順番で走ります。
このパイプラインは、社内文書の更新に合わせて日次または週次で回します。裏側は結局、ETL/ELTのデータパイプラインそのものです。データ基盤の議論と地続きになる部分で、データ基盤とは？企業が導入すべき3つの理由と構成要素を解説でも解説している「収集→蓄積→加工」の考え方がそのまま効いてきます。
社員が質問を投げた瞬間から、次の順番で処理が走ります。
理想は「質問から回答まで数秒」ですが、リランキングやハイブリッド検索を挟むと10秒前後まで伸びることも珍しくありません。UXとしては、回答を段階的に表示するストリーミング表示と組み合わせるのが定石です。
ここが本題です。RAGは「AIツールを1つ買えば動く」ものではなく、社内のデータ基盤側にいくつかの前提を求めます。ここを軽視すると、PoCは動いても本番運用で崩れます。
RAGは、複数のシステムに散らばった文書を横断検索させたいケースが多いはずです。しかしSharePointの一部、Confluenceの一部、共有フォルダの一部……とバラバラのままAPIを叩きに行くと、権限管理・鮮度・重複排除がすべて個別実装になります。
現実的なのは、文書メタデータを1か所に集めて棚卸ししたうえで、埋め込みパイプラインを1本に統一することです。この考え方は「ELTでDWHにデータを集約する」のと同じ発想です。
「営業部の資料を人事の社員から検索できてしまう」という事故は、RAGでは頻発します。ベクトル検索は意味が近いものを引いてくるため、権限をシステム側で切っておかないと、検索結果に他部署の機密が混ざります。
これらをチャンクごとにメタデータとしてベクトルDBに持たせ、検索時にフィルタリングします。「この社員の権限で見える文書だけを検索対象にする」というアクセス制御を、検索の瞬間に効かせる仕組みが要ります。
ここは技術的な話ですが、精度に直結します。
小さな失敗は許容できますが、「チャンクサイズを後から変えると全文書の再埋め込みが必要になる」ため、最初の設計は慎重に。
エンタープライズRAGでは、ベクトル検索だけに頼らず、BM25などのキーワード検索と組み合わせるハイブリッド検索が2026年時点の定石です。ベクトルは意味を捉えるのが得意ですが、製品コード・型番・法令番号のような厳密一致が必要な検索は苦手です。「就業規則第32条」を「32条」で検索したいときに、ベクトルだけでは弱くなります。
ベクトル検索そのものの仕組みと、pgvector・Pineconeといった選択肢の選び方はベクトルデータベースとは？AI活用に必要な理由と選び方｜2026年版で基礎から解説しています。
RRF（Reciprocal Rank Fusion）などの手法で両方の結果を混ぜるのが標準的な作りです。ここまで作り込むかどうかで、精度と実装コストは大きく変わります。
誰が何を質問し、AIがどの文書のどのチャンクを引いて、どんな回答を返したか。この履歴を残せる仕組みは、社内利用でも監査・トラブル対応で必ず必要になります。
BigQueryやSnowflakeなどのDWHにログを流し、あとから「先週の質問傾向」「回答されなかった質問」を分析できるようにしておくと、精度改善のサイクルにも回せます。
ここはPoCから本番に上がる前に、必ずぶつかる論点です。Evastの現場でも繰り返し見てきたパターンを整理します。
数十件の文書で動かしたRAGを、数千件・数万件に広げると精度がガクッと落ちるパターンです。原因は、ノイズ文書が検索結果に混ざり、LLMが「参考資料が多すぎて混乱する」状態になっていることです。
対処は、リランキングを入れる、チャンク数を絞る、メタデータフィルタで対象範囲を絞る、の順で試します。多くの場合は「質問の対象部署を先に絞ってから検索」を入れるだけで大きく改善します。
「A部の役員会議事録が、B部の一般社員に見えてしまった」という事故は、RAGでは実際に起きます。原因はほぼ、メタデータの権限フィルタが検索時に効いていない実装ミスです。
このリスクは技術というより設計の話です。SharePoint・Confluenceなどの元システムの権限を、埋め込み時にメタデータとして持ってこられているか、検索クエリでそれを必ずフィルタに使っているかを、必ずレビューする必要があります。
規程が改訂されたのに、AIが古い版で答え続ける。原因は、埋め込みパイプラインが再実行されていない、または古いチャンクが削除されずに残っていることです。
日次または週次で全文書のインデックスを更新する仕組みは、地味ですが必須です。ここを人手のバッチで回している間は、必ずどこかで抜けが起きます。dbtやAirflowでスケジュール実行できる形にしておくのが安全です。
社員数百人が業務で使い始めると、OpenAIやAnthropicのAPI課金が月数十万円〜100万円を超えることがあります。原因は、1回の質問で渡すチャンク数が多い、質問1件あたりの平均トークン数が想定より大きい、といったところです。
このあたりの運用設計はDWHのコスト最適化と発想が同じです。BigQueryの料金体系とコスト削減｜課金トラップと対策の考え方が転用できます。
一番多い失敗はここかもしれません。せっかく作ったのに、社員が「結局Google検索したほうが早い」と使わなくなるパターンです。
原因は、対象文書の範囲が広すぎて回答がぼやける、質問の書き方が難しい、UIが使いにくい、といった複合要因です。対策は、対象範囲を1〜2部署に絞って狭く始めること、そして社員へのオンボーディングで「こういう質問には強い/こういう質問は苦手」を明示することです。
最後に、実際にどこから手をつければよいかの段取りです。全社一斉ではなく、狭く始めて広げる進め方が現実的です。
「就業規則・人事Q&A」「営業提案書の検索」「システム運用マニュアルの参照」など、対象を1つに絞ります。目安は、対象文書100〜1,000件、想定利用者20〜200人、質問頻度が明確なもの。
同時に、対象文書の権限・更新頻度・重複を洗い出します。ここが雑だと後の設計がすべて崩れるため、地味ですが最重要のステップです。
NotebookLM、Azure OpenAI on Your Data、Dify、AWS Kendra + Bedrock、Google Vertex AI Searchなど、マネージドRAGサービスで最小構成を組みます。ここではベクトルDBもLLMも既製サービスに任せ、動く形を最速で作ります。
この段階の狙いは、技術検証よりもユースケースの妥当性を確かめることです。想定していた質問にちゃんと答えられるか、社員が実際に使いたくなるかを、10〜20人のトライアルで見ます。
マネージドRAGで手応えが得られたら、本番向けに次のいずれかで作り込みます。
多くの企業はセミカスタムに落ち着きます。ここで権限フィルタ、ハイブリッド検索、監査ログを実装します。
50〜200人規模でパイロット運用に入り、質問ログを分析して精度改善を回します。改善の打ち手は、チャンク設計の見直し、リランキングの追加、プロンプトの調整、対象文書の追加・削除、の順で試すのが定石です。
全社展開は、パイロットで運用体制と精度が安定してから。ここまで含めると、対象範囲によりますが3〜6か月見ておくのが安全です。
内製と外注のバランスは、データ基盤は内製と外注どっち？判断基準とハイブリッドの進め方の考え方がそのまま使えます。エンベディングモデルの選定や監査ログ設計は内製が難しい領域なので、初回は外部の知見を借りて型を作り、以降を内製化する進め方が現実的です。
RAGは、生成AIを社内で本当に役立てるための、いま最も現実的な仕組みです。同時に、実装を進めていくと「AIの土台にデータ基盤が要る」という原則をいちばん強く実感できる入口でもあります。
これらは、Evastが日々のデータ基盤構築の中で扱ってきたテーマそのものです。「社内AIを進めたいが、どこから手をつけていいかわからない」という段階でも、まずは対象データの棚卸しと、既存のSaaSを組み合わせたPoCから小さく始められます。
自社のRAG導入やAI活用に向けたデータ基盤構築についてご相談されたい方は、Evastのデータ基盤構築サービスからお気軽にお問い合わせください。ユースケースの選定、PoC設計、本番構成のアーキテクチャレビューまで、フェーズに応じた形で伴走します。
社内AIやRAGを検討すると、構成図に必ず「ベクトルデータベース」という箱が登場します。埋め込み（エンベディング）で意味を数値化して検索する仕組み、キーワード検索との違い、RAGでの役割、Pinecone・pgvector・BigQueryなど主要製品の特徴、専用DBと既存DB拡張の選び方、導入時の落とし穴までを、非エンジニアのマネージャー向けに整理します。
生成AIを導入しても成果が出ない、PoCで止まる。その原因の多くはモデルではなくデータにあります。日本企業がつまずく理由、AIが整ったデータを必要とする仕組み、BI向けとは違う「AIに使えるデータ」の条件、独自データが差別化を生む理由、AIの土台になるデータ基盤の全体像と始め方までを、海外の最新調査と現場目線で整理します。生成AI活用を成果につなげたいDX担当・情シス向けの実務記事です。
毎月の売上集計にExcelで30〜60時間かかる、共有ファイルが壊れる、関数エラーで会議が延びる。100〜1000名規模の企業でよく起こる「表計算の限界」を、構造・共同編集・自動化・信頼性の4方向から整理し、データ基盤（DWH）への移行アプローチ3種類、3〜6か月のステップ、費用の目安、よくある落とし穴までまとめました。ラーメンチェーン・ディスカウントストア・ブランドリユースの実案件で、集計時間をほぼゼロにした数値も掲載。情シス・DX推進・経営企画のマネージャーが、次の一歩を判断するための実務記事です。
BigQueryの導入を、試す前に知るべき基本から実務の立ち上げまで通しで解説します。メリットとデメリット、オンデマンドとEditionsの料金体系と無料枠、導入手順5ステップ、GA4・Looker Studio・スプレッドシートとの連携、Redshift・Snowflakeとの比較、導入後にコストが膨らむ落とし穴、外部に構築を依頼する場合の費用相場と進め方まで、2026年7月時点の情報で整理します。
