プロジェクト概要

「これ、どこに書いてありましたっけ?」という社員からの質問が情報システム部門に毎日のように届く。VPN の設定手順、経費精算の締め日、勤怠システムの操作方法、入退社の手続き — どれも社内のどこかには書いてあるのに、誰もそのありかを覚えていない。結果として、本来なら自己解決できるはずの定型問い合わせが情シスに集中し、担当者の手が止まる。

今回ご相談いただいたのは、従業員 1,200 名規模の製造業の情報システム部門です。社内ドキュメントを横断検索できる RAG (Retrieval-Augmented Generation) 基盤を構築し、社員が自然文で質問すれば社内文書を根拠に回答してくれる仕組みを 8 週間で立ち上げました。最終的に情シスへの定型問い合わせを 60% 削減し、社員の自己解決率を大きく押し上げています。

この記事では、どんな課題に対してどう設計し、どんな数値が出たのかを、再利用できる勘所とあわせて率直に共有します。RAG の導入を検討している情シス・社内 DX 担当の方が、自社で何を準備すればよいかをイメージできることを目指しました。

業務上の課題

着手前のヒアリングで見えてきた課題は、技術というより「ナレッジの状態」に起因するものでした。

  • ドキュメントが 4 つのツールに分散していた。社内 Wiki (Confluence)、ファイルサーバー上の Word / PDF、Google ドライブの運用手順、そして情シス担当者の頭の中(暗黙知)。
  • 検索性が低い。各ツールの検索機能はキーワード一致が中心で、「在宅勤務のときの勤怠の付け方」のような自然文では目的の文書にたどり着けない。
  • 回答品質が人に依存していた。ベテラン担当者は即答できるが、新任担当者は調べ直すため、同じ質問でも回答の精度と速度にばらつきがあった。
  • ドキュメント自体が古い。改訂されないまま残った旧手順書が検索上位に出てきて、誤った案内の原因になっていた。

つまり「検索 AI を入れれば解決する」という単純な話ではなく、そもそも検索される側のナレッジが整っていないことが本質的な課題でした。ここを最初に正しく認識できたかどうかが、後の精度を大きく左右します。

アプローチ 1: 分散ドキュメントの棚卸しとチャンク設計

最初の 2 週間はコードをほとんど書かず、ドキュメントの棚卸しに充てました。RAG の精度は検索対象データの質でほぼ決まるため、ここを飛ばすと後工程がすべて崩れます。

棚卸しでは、対象ドキュメントを一覧化したうえで「現役 / 改訂中 / 廃止」のステータスを情シス担当者と一緒に付与しました。約 1,800 件のうち、実際に検索対象とすべき現役文書は 1,100 件ほど。残りは思い切ってインデックス対象から外すことで、古い手順がヒットするリスクを最初から潰しました。

区分件数対応
現役 (検索対象)1,100チャンク化してインデックス
改訂中350改訂完了後に随時追加
廃止350インデックス対象外

次に取り組んだのがチャンク設計です。文書をどの単位で区切ってベクトル化するかで、検索のヒット率が大きく変わります。当初は固定長 (500 文字ごと) で区切っていましたが、手順書の途中で文脈が切れて回答精度が落ちました。そこで、見出し構造を保ったまま区切る 見出しベースのチャンク分割に切り替えています。

  • Markdown / HTML に変換できる文書は、H2・H3 の見出し単位でチャンク化する。
  • 1 チャンクが長くなりすぎる場合のみ、文の境界で分割する。
  • 各チャンクに「出典文書名・章タイトル・最終更新日」をメタデータとして付与する。

このメタデータが、後述する根拠提示と更新運用の両方で効いてきます。チャンク設計は一度で正解にたどり着くものではなく、後述する評価データセットを回しながら何度も調整しました。

アプローチ 2: 検索精度を上げる RAG パイプラインの実装

データの土台が整ったところで、パイプラインの実装に入りました。構成はあえてシンプルに保ち、各段を差し替え可能にしています。

flowchart LR
  Q["社員の質問 (自然文)"]
  E["クエリ埋め込み"]
  V["ベクトル検索 (pgvector)"]
  RR["リランキング"]
  G["回答生成 (Claude)"]
  C["根拠リンク付き回答"]

  Q --> E --> V --> RR --> G --> C

ベクトルストアには、既存の PostgreSQL を活かせる pgvector を採用しました。新たに専用のベクトル DB を契約・運用するより、社内ですでに運用ノウハウのある PostgreSQL に寄せたほうが、運用負荷とコストの両面で現実的だったためです。

精度向上で効果が大きかったのは、次の 3 点です。

  1. ハイブリッド検索。ベクトル検索だけだと「FAQ-2024-031」のような型番・固有名詞の一致に弱いため、全文検索 (キーワード一致) と組み合わせ、両者のスコアを統合しました。
  2. リランキング。ベクトル検索で上位 20 件を取り出し、リランカーで質問との関連度を測り直して上位 5 件に絞ります。これで「なんとなく似ているが的外れ」なチャンクの混入が大きく減りました。
  3. クエリ書き換え。社員の質問は省略が多い (「経費いつまで?」など) ため、回答生成の前に質問を補完・正規化する前処理を挟みました。

実装には Claude Code を使い、パイプラインの各段とテストを並行して書き進めました。Claude Code を実プロジェクトで効率よく回すための具体的な工夫は Claude Code × MCP の実践パターン にまとめているので、開発フローの参考にしてください。

アプローチ 3: 回答の根拠提示と権限制御・継続評価

社内ナレッジ検索で信頼を得るには、回答の正しさと同じくらい「どこに書いてあるか」を示せることが重要です。根拠が見えれば、社員は最終確認を自分の目で行えますし、誤りにも気づけます。

そこで回答には必ず 出典リンクと該当章・最終更新日を添えました。回答本文の末尾に「この回答は『リモートワーク規程第 3 章 (最終更新 2026-04)』を参照しています」と表示し、原典の文書へ 1 クリックで飛べるようにしています。これは前段のチャンクにメタデータを持たせておいたからこそ実現できた設計です。

権限制御も社内システムでは外せません。人事評価や給与に関する文書は閲覧権限が限られるため、検索段階で 質問者の所属・ロールに応じてインデックスをフィルタする仕組みを入れました。閲覧権限のない文書はそもそも検索結果に含めないことで、回答経由での情報漏えいを防いでいます。

そして継続評価です。RAG は「作って終わり」では必ず劣化するため、運用に評価の仕組みを組み込みました。

  • 情シス担当者と協力して、想定質問と期待回答のペアからなる 評価データセット (約 150 件) を整備。
  • パイプラインを変更するたびに、このデータセットでヒット率と回答の正確性を自動測定する評価ハーネスを Claude Code で構築。
  • 実運用では「役に立った / 立たなかった」のフィードバックを社員から集め、外したケースを週次でレビューしてチャンクや文書側を改善。

この評価の自動化は、AI エージェント運用の継続改善と共通する考え方です。社内オペレーションへの AI 適用を運用目線で深掘りした AI エージェントによる運用自動化の事例 もあわせてご覧ください。

成果の実数値

導入後 12 週時点での主要指標です。クライアントの許諾を得た範囲で、穏当なレンジで示します。

指標導入前導入 4 週後導入 12 週後
検索ヒット率 (正解文書が上位 5 件に入る割合)—72%89%
情シスへの定型問い合わせ件数 / 月 (基準 100)1006840
社員の自己解決率約 30%58%74%
一次回答までの平均時間半日〜1 日数分数分

定型問い合わせは導入前比で 60% 削減され、自己解決率は 30% 前後から 74% まで上がりました。ヒット率はチャンク設計の見直しとリランキング導入で 72% から 89% へ改善しています。

数値以上に現場が評価したのは、情シス担当者が「調べる」「案内する」作業から解放され、本来注力したかった基盤改善やセキュリティ対応に時間を回せるようになった点でした。問い合わせ削減は手段であって、目的はその先の時間の使い方の変化にあります。

学びと再利用可能なナレッジ

精度はデータ整備が支配的

8 週間の工数配分を振り返ると、ドキュメント棚卸しとチャンク設計・評価データ整備に半分以上を費やしました。モデルやプロンプトの調整で稼げる精度は限定的で、検索される側のナレッジの状態が精度の上限を決めるというのが最大の学びです。古い文書を外し、見出し構造を整え、メタデータを付ける。この地道な整備こそが、後から効いてくる資産になります。

評価を仕組みにすると改善が回る

「なんとなく良くなった気がする」では改善は続きません。評価データセットと自動測定をはじめに作っておくと、変更のたびに数値で良し悪しを判断でき、チャンク分割やリランキングの調整に確信を持って踏み込めます。評価ハーネスはモデルを乗り換えても再利用できるため、長期的な投資対効果が高い部分です。

モデル非依存に設計しておく

検索パイプライン (埋め込み・ベクトル検索・リランキング・権限フィルタ) と回答生成を疎結合にしておけば、回答生成のモデルを差し替えても全体を作り直す必要はありません。AI モデルの進化は速いため、特定モデルに密結合しない構成が運用の安心につながります。

ありがちな落とし穴

ハルシネーション対策を後回しにする

RAG にしても、検索でヒットしなかったときにモデルが知識をでっち上げる余地は残ります。対策として、検索スコアが一定に満たない場合は無理に回答させず「該当する社内文書が見つかりませんでした。情シスへお問い合わせください」と返すしきい値設計を入れました。根拠リンクの併記も、社員が誤りに気づける安全弁として機能します。

更新運用を設計に組み込まない

導入直後は快適でも、文書が改訂されてもインデックスが追従しなければ、3 ヶ月後には古い回答を返すようになります。本案件では、文書の更新を検知して差分だけを再インデックスする同期処理を最初から組み込み、廃止文書はステータス変更で検索対象から外せるようにしました。更新の運用フローまで含めて初めて RAG は完成すると考えてください。

いきなり全社展開する

最初から全部門・全文書を対象にすると、精度が出ない領域に足を引っ張られて全体の信頼を失います。本案件では情シス関連のナレッジに範囲を絞ってヒット率を作り込み、社内の信頼を得てから対象部門を広げました。スモールスタートと段階展開が、社内浸透の近道です。

よくある質問

Q. RAG 構築の費用感はどのくらいですか?

A. 本案件相当 (ドキュメント棚卸し + RAG パイプライン + 権限制御 + 評価の仕組み) で 8 週間、500 万〜800 万円が目安です (税抜)。対象ドキュメントの量や形式の多様さ、外部システム連携・権限制御の複雑さで変動します。まずは対象範囲を絞った小さな実証から始めるご提案も可能です。

Q. 社内文書をクラウドに出すのが不安です。セキュリティはどう担保しますか?

A. ベクトルストアを自社環境 (オンプレや専用クラウド) に置く構成や、質問者のロールに応じて閲覧権限のある文書だけを検索対象にするフィルタリングを標準で設計します。本案件でも人事・給与関連の文書は権限制御の対象とし、回答経由で権限外の情報が漏れない設計にしています。要件に応じて通信・保管の暗号化やログ監査も組み込みます。

Q. 将来 AI モデルが変わったら作り直しになりますか?

A. なりません。検索パイプラインと回答生成を疎結合に設計しているため、回答生成のモデルだけを差し替えれば移行できます。評価ハーネスで品質を確認しながら切り替えられるので、モデルの進化に追従しやすい構成です。RAG を含む AI エージェント基盤のサービス内容は AI エージェント開発サービス でも紹介しています。

社内に眠っているナレッジを、社員が自力で引き出せる状態にしませんか。RAG・AI エージェントの構築について、要件整理から精度の作り込みまで 無料相談 で承っています。自社のドキュメント状況を伺ったうえで、現実的な進め方をご提案します。