AI
5 min read

社内ナレッジを活用するRAG(検索拡張生成)システムの構築

#RAG 構築 社内ナレッジ#社内検索 AI 導入#ナレッジベース 設計#RAG 精度 改善
Definition

RAG(検索拡張生成)とは、LLMが学習していない社内データや最新情報を、外部データベースから検索(Retrieve)して回答生成(Generate)に組み込む技術のことです。

TL;DR (要約)

RAGの精度は、モデルよりも「データ整備・権限・更新フロー」で決まります。最初は用途(FAQ/手順/規程)を絞り、検索対象と品質基準を明確にします。監査可能性(ログ)と運用(更新・廃止)まで設計して、継続利用できる形にします。

この記事でわかること

  • RAGとは(何が解決できるか/できないか)
  • 失敗パターン(データ品質・権限設計・更新フローの不備)
  • 設計の要点(ソース選定・権限・メタデータ)
  • 精度改善の進め方(評価→改善→再評価)
  • 運用設計(更新、廃止、監査ログ、責任分界)
  • 導入ロードマップ(PoC→本番の要件)
  • チェックリスト(最小構成で始める)

RAGとは(何が解決できるか/できないか)

LLM(大規模言語モデル)は、インターネット上の一般的な知識は持っていますが、「御社の就業規則」や「先月の売上データ」は知りません。これらをAIに「カンニング」させる技術がRAG (Retrieval-Augmented Generation) です。

  • できること:社内ドキュメントに基づく回答、根拠(ソース)の提示、最新情報の反映。
  • できないこと:データが存在しないことへの回答(推測で答えてしまう)、カオスなデータからの正確な抽出。

RAG vs ファインチューニング (Fine-tuning) 比較表

比較軸 RAG (推奨) ファインチューニング
知識源 外部データベース (Vector DB) モデル自体の重み (Weight)
コスト 安価 (DB料金 + API利用料) 高額 (GPU計算リソースが必要)
更新頻度 リアルタイム (DB更新のみ) リードタイム長 (再学習が必要)
ハルシネーション 根拠を提示できるため抑制しやすい 抑制が難しく、不正確な情報を生成するリスクがある
向き不向き 知識検索、FAQ、マニュアル 特定文体への矯正、医療用語理解

ベクトルDB(Vector DB)とは?

例え話:図書館の司書さん

  • 従来の検索(キーワード)は、「タイトルに『売上』が含まれる本」しか探せません。
  • ベクトル検索(意味検索)は、「『景気が良い』雰囲気の本」といった意味の近さで探せます。
  • これを実現するために、文章を数値(ベクトル)に変換して保存する場所がベクトルDBです。

仕組み(3ステップ)

  1. Embedding:文章をAIで「数値の座標」に変換する。
  2. Indexing:その数値をベクトルDBに保存する。
  3. Search:質問文も数値に変換し、座標が近いデータを引っ張ってくる。

失敗パターン(データ品質・権限設計・更新フローの不備)

RAG導入において成果が出ない典型的な原因は、技術選定よりも「データ」の管理状態にあります。

  • データの品質(Garbage In, Garbage Out):古いマニュアルや未確定の議事録などが検索対象に含まれていると、AIの回答精度が著しく低下します。
  • アクセス権限の不備:機密情報が検索対象に含まれ、権限のないユーザーがAI経由で閲覧できてしまうリスク。
  • 情報の不整合:元ドキュメントが更新されてもRAG側へ反映されず、回答が陳腐化する問題。

この3つの失敗パターンの中で、実務で最も頻繁に発生し、かつ発覚が遅れるのが「情報の不整合」です。弊社が伴走支援したある50名規模の企業では、RAG導入から3ヶ月後に「AIが旧規定に基づいて回答している」ことが判明しました。原因は、クラウドストレージ上のドキュメントを改訂した際に、RAG側の再学習が行われなかったことです。この問題を解決するために、ドキュメントに「最終更新日」と「責任者」のメタデータを付与し、API連携によって更新を検知し自動的に再インデックスを行うフローを構築しました。RAGは一度構築して終わりではなく、「データのメンテナンス責任者を明確にし、運用体制を確立する」ことで初めて本来の価値を発揮します。

設計の要点(ソース選定・権限・メタデータ)

成功の鍵は「検索対象を絞ること」です。ファイルサーバー全体を検索対象にするのではなく、「AIに読ませて良い(品質が担保された)フォルダ」を作成し、そこだけを参照させます。

対象データ 判断基準
確定情報 (推奨) 就業規則、公式マニュアル、プレスリリース、FAQ。
優先的にインデックス対象とする
フロー情報 (慎重) 日報、Slackログ、議事録。
文脈が不明瞭なため、回答のノイズとなる可能性が高い。事前の要約や加工を推奨。
機密情報 (対象外) 個人情報、パスワード、人事評価、インサイダー情報。
情報の漏洩リスクを考慮し、物理的に検索対象から隔離する

推奨技術スタックの選定観点

特定の製品ありきで選ぶのではなく、要件(データ量・セキュリティ・コスト)に合わせて選びます。

  • Vector DB (保存場所)
    • Pinecone:フルマネージドで手軽。小規模〜中規模向け。運用負荷が低い。
    • Weaviate / Qdrant:オープンソースあり。オンプレミスや自社VPC内で完結させたい場合。
    • pgvector (PostgreSQL):既存のRDB運用に乗せたい場合。SQLと混ぜて使えるのが強み。
  • Framework (開発ツール)
    • LangChain:機能豊富でデファクトだが、抽象度が高くブラックボックスになりがち。
    • LlamaIndex:データロード(取り込み)機能が強力。RAGに特化するならこちらが便利。

精度改善の進め方(評価→改善→再評価)

RAGの精度が出ない場合、以下のどこに問題があるか切り分けます。

  1. 検索(Retrieval)の失敗 :必要なドキュメントがヒットしていない。
    → キーワードの類義語登録、チャンク(分割)サイズの調整、ハイブリッド検索(キーワード+ベクトル)の導入。
  2. 生成(Generation)の失敗 :ドキュメントは渡せているが、AIの回答が変。
    → プロンプトの改善(「以下の情報を元に答えて」という指示の強化)、モデルの変更(GPT-3.5 → GPT-4o)。

運用設計(更新、廃止、監査ログ、責任分界)

作ってからが本番です。ドキュメントは日々増え、古くなります。「マニュアルが更新されたのに、AIが古い回答をし続ける」のが最大のリスクです。

これを防ぐには、データ更新をトリガーにAIを再学習させる自動化フロー(正確にはRe-indexing)を組むか、運用担当者が定期的にデータを入れ替える業務フローを確立する必要があります。

システムは生き物です。データの鮮度を保つ仕組みが必要です。

  • 更新フロー:元のマニュアルが更新されたら、Webhook等で即座に再インデックス(学習)される自動化フローを組む。
  • 監査ログ:ユーザーが「どのドキュメントを参照して」回答を得たのか、ソースへのリンクを必ず表示させる。
  • 責任分界:「回答が間違っていた場合、責任はAIではなく、元ドキュメントの管理者か、確認しなかったユーザーにある」という免責事項をUIに明示する。

導入ロードマップ(PoC→本番の要件)

いきなり全社展開せず、以下のステップで進めます。

  1. PoC(概念実証):IT部門や特定のプロジェクトチーム(10名程度)に限定し、特定のドキュメント(例:社内PCセットアップ手順)のみで試す。
  2. ドキュメント整備:PoCで見えた「AIが答えにくい形式(画像の多いPDF、スキャンPDF)」を修正する。Markdown形式が最も精度が出やすい。
  3. 本番展開:部署単位で権限設定を行いながら対象範囲を広げる。

チェックリスト(最小構成で始める)

RAG構築前に確認すべき項目です。

重要ポイント

RAGは「魔法の箱」ではありません。検索エンジンの進化版です。「整理されたデータ」があって初めて、その真価を発揮します。まずは「社内規定FAQ」など、データが構造化されている領域から始めるのが成功への近道です。

チェックリスト

  • □ 検索対象にするドキュメントの範囲は明確か(全部入れない)
  • □ ドキュメントの中に個人情報や機密情報が含まれていないか確認した
  • □ ドキュメントのファイル形式はAIが読みやすいか(テキスト抽出可能か)
  • □ 元ファイルが更新された際、どうやってRAG側に反映するか決まっているか
  • □ 「アクセス権限」の設計ができているか(役職ごとの閲覧制限)
  • □ AIが回答に「参照元(ソース)」を提示するUIになっているか
  • □ 回答精度を誰がどうやって評価するか決まっているか(評価データセット)
  • □ プロンプトインジェクション対策(「以前の命令を無視して」等)は考慮されているか
  • □ ログ(質問と回答)を保存し、定期的にモニタリングできるか
  • □ 利用者に対し「AIは間違う可能性がある」ことの周知徹底ができているか

よくある質問

Q. RAGのハルシネーション(嘘)を完全に防ぐことは可能ですか?

LLMの性質上「完全」に防ぐことは困難ですが、検索精度の向上(ハイブリッド検索)や、プロンプトでの「知らない場合は回答しない」という制約設定により、実用レベルまで大幅に抑制することは可能です。

Q. 社内規程PDFやマニュアルをそのまま読み込ませて良いですか?

そのままでは精度が出ないケースが多いです。LLMが文脈を解釈しやすいよう、事前処理で「見出しごとにチャンク(分割)する」「図表のメタデータを付与する」などのデータ加工(クリーニング)が必須になります。

AI活用でビジネスを変革

RAG構築から生成AIの業務組込まで、実践的なAIソリューションを提供します。

AIソリューションについて
Theme Overview

実務で使えるビジネスAI導入:生成AIと自動化の融合

このテーマの全体像を把握し、より体系的な理解を深めましょう。

全体像を読む

ビジネスの課題解決を、
もっと具体的に。

Malakeは、テクノロジーと戦略の両面から
貴社のビジネス変革をサポートします。