Tied Inc.

社内問い合わせBot・マニュアル検索AIの現実:RAG導入が期待どおりに動かない理由と整備手順

Tied株式会社 Read in English

社内問い合わせBotが「期待どおりに動かない」とき、原因の大半はAIモデルの性能ではなく、参照元となる文書と検索の整備不足にあります。 ChatGPTやClaudeの精度が上がったことで、「自社のマニュアルや社内規程を読み込ませれば、社内版ChatGPTが作れる」と考えて導入に踏み切る中小企業は増えています。しかし実際に稼働させると、「聞いたことに答えない」「古い規程を根拠に間違った回答をする」「結局誰も使わなくなる」という壁にぶつかるケースが少なくありません。

本稿では、この現象の裏側にある仕組み(RAG:検索拡張生成)を踏まえながら、うまくいかない原因の切り分け方と、導入前後に整備すべきことを、中小企業の推進担当者・経営者向けに整理します。

社内Botが最初に検討される理由と、期待外れになる典型パターン

社内問い合わせBotが最初の候補に挙がりやすいのには理由があります。効果が説明しやすく(「マニュアル検索の時間を減らす」)、他部署を巻き込まずに情報システム部門や推進担当者だけで着手でき、ツール自体は数万円台から使える場合もあるためです。「社内にAIがわかる人材がいない」企業ほど、まず着手しやすいこのテーマから入る傾向があります(詳しくは「社内にAIがわかる人がいない」問題の構造と3つの解決パターンを参照してください)。

しかし稼働後、次のような期待外れが繰り返し報告されます。

  • 答えが本文からズレる:質問の意図とは異なる箇所を引用し、的外れな回答を返す
  • 古い情報を正解として提示する:改訂前の規程やマニュアルを根拠に、現在は誤った内容を案内する
  • 「わかりません」を返せない:文書に答えがない質問にも、それらしい文章をでっち上げて回答してしまう(ハルシネーション)
  • 利用が定着しない:導入初月は物珍しさで使われるが、精度への不信から数ヶ月で利用率が急落する

これらは個別のバグではなく、多くの場合「同じ根本原因」から派生しています。次章で切り分け方を示します。

原因の切り分け:文書の質 / 分割・検索 / 質問の型 / 評価の不在

社内Botの多くは「RAG(Retrieval-Augmented Generation:検索拡張生成)」という仕組みで動いています。ユーザーの質問に関連しそうな社内文書の一部を検索エンジンで探し出し、その断片をAIモデルに読ませたうえで回答を生成する方式です。モデル自体は社内情報を「記憶」しているわけではなく、毎回の質問のたびに検索で見つけた断片だけを根拠に答えているという点が、うまくいかない原因を切り分けるうえでの出発点になります。

うまくいかない場合、原因は主に次の4層のどこかにあります。

1. 文書の質 古い版が混在/矛盾する記載/そもそも文書化されていない業務知識 2. 分割・検索の設計 文書の切り方が粗すぎ/細かすぎる/検索キーワードと本文表現の不一致 3. 質問の型 曖昧な自然文の質問/複数文書の突合が必要な質問への非対応 4. 評価の不在 「使いものになるか」を測る基準がなく、体感の不満で終わっている
図1:社内Botが「動かない」原因の切り分け

実際には、導入後の不満の多くが1層(文書の質)と2層(分割・検索の設計)に起因しています。AIモデル自体の限界ではなく、その手前の整備不足が原因であるケースが大半だという点は押さえておく必要があります。

文書の質:そもそも根拠が間違っている

社内Botの回答品質は、参照元の文書品質を超えません。改訂版と旧版のマニュアルが同じフォルダに混在している、部署ごとに異なる手順書が矛盾したまま残っている、といった状態では、検索でどちらを引いても正しい回答は保証されません。さらに深刻なのは、日々の判断基準の多くが文書化されておらず、ベテラン社員の頭の中にしかないケースです。この場合、Botは「存在しない答え」を探し続けることになります。

分割・検索の設計:文書の切り方と検索精度の問題

RAGでは長い文書をそのまま検索対象にはせず、一定の単位(チャンク)に分割してインデックス化します。この分割が粗すぎると1つの断片に複数の話題が混在して検索精度が落ち、逆に細かすぎると文脈が失われて断片単独では意味が通らなくなります。加えて、質問文の言い回しと文書内の表現が異なる場合(「有休」と「年次有給休暇」など)、単純なキーワード一致に頼る検索では該当箇所を取りこぼします。ツール選定時にこの検索方式(キーワード検索か、意味的な類似度で探すベクトル検索か、両者の併用か)を確認せずに導入すると、後から精度を上げにくくなります。

質問の型:Botが想定していない聞き方をされている

「有給休暇の申請方法は?」のような単一文書内で完結する質問には強い一方、「A制度とB制度、自分にはどちらが有利か」のように複数文書を横断して比較・判断する質問には弱い、という特性がRAGにはあります。ツールの守備範囲を超えた質問への期待値がそもそも高すぎるケースも、「使えない」という評価につながっています。

評価の不在:良し悪しを判断する基準がない

最も見落とされやすいのがこの層です。多くの導入では「なんとなく試して、なんとなく微妙」という体感で終わり、どの質問カテゴリで、どのくらいの割合で正しく答えられているかを定量的に測っていません。評価の仕組みがないままでは、改善すべきなのが文書なのか検索設定なのかの判断もできず、対策が場当たり的になります。

導入前に整備すべきもの:文書の棚卸し・更新責任・FAQ化

原因の多くが「文書」と「評価」にあることを踏まえると、着手すべき整備は次の3点に集約されます。

  1. 文書の棚卸し:対象範囲の文書を一覧化し、最終更新日・重複・矛盾をチェックする。同一テーマの文書が複数バージョン存在する場合は、どれが正とするかをこの段階で決める
  2. 更新責任の明確化:文書が古いまま放置される最大の原因は、更新責任者が決まっていないことです。部署ごとに「この文書群の正本を最新に保つ担当者」を割り当て、更新のたびにBotのインデックスへ反映する運用を組み込む
  3. よくある質問のFAQ化:過去の問い合わせ履歴やベテラン社員へのヒアリングから、頻出する質問と模範回答を先にFAQとして文書化する。FAQは検索対象として質が高く(質問と回答が1対1で明確なため)、暗黙知の文書化にも直結する

この3点は、AIツールを何にするかを決める前に着手できます。逆に、この整備を飛ばしてツール選定から入ると、どのツールを使っても同じ壁にぶつかります。

段階的な進め方:限定領域で評価してから広げる

全社展開を最初から狙うのではなく、範囲を絞って精度を検証してから広げる進め方が失敗を減らします。目安は次のとおりです。

フェーズ期間目安やること判断基準
1. 限定領域での試験運用1〜2ヶ月1部署・1テーマ(例:総務からの問い合わせ)に絞り、文書整備とFAQ化を実施想定質問セット(30〜50問)に対する正答率を評価する
2. 評価と改善2〜4週間正答率が低いカテゴリを特定し、文書の追記・分割設定の見直しを実施正答率が実用ラインまで改善しているか(目安として8割前後)
3. 対象範囲の拡大継続部署・テーマを段階的に追加し、都度フェーズ1〜2を繰り返す利用率と、誤答時に「わからない」と正直に答えられているか

このプロセスで重要なのは、フェーズ1で使う想定質問セットを、実際の問い合わせ履歴から作ることです。想定問答を作った担当者自身が用意した「答えやすい質問」だけで評価すると、実運用での崩れを見逃します。

現場伴走で行う具体的な作業

ここまでの整備作業は、情報システム部門だけで完結させるのが難しい性質を持っています。文書の正本を決める判断や、部署ごとの更新責任の割り当てには業務ナレッジが必要で、外部のAIベンダーに丸投げしても進みません。かといって、社内にAI・検索技術に詳しい人材がいなければ、分割設定や評価の仕組みづくりは手探りになります。

この文書棚卸し・FAQ化・評価設計の作業は、現場に入って進めるのが効果的です。想定質問セットを実際の問い合わせ履歴から作成し、正答率を計測しながら分割・検索設定を調整する、という反復作業は、資料を納品して終わる支援形態では実施しきれません。現場に入って業務知識を持つ担当者と一緒に文書を精査することが、Botの精度を実用水準まで引き上げる近道です。中小企業向けの現場伴走型技術支援そのものの考え方は、現場伴走型技術支援とは何かで詳しく解説しています。

まとめ

社内問い合わせBotが期待どおりに動かない原因は、多くの場合モデルの限界ではなく、文書の質・検索設計・評価の不在にあります。ツール選定の前に文書棚卸しと更新責任の割り当てを行い、限定領域での試験運用と定量評価を経てから範囲を広げることで、「導入したが使われない」という失敗を避けられます。AI活用の全体的な進め方は中小企業のAI活用はどこから始めるかで解説していますので、あわせて参照してください。

Tied株式会社

Tied株式会社

技術経営の専門家による技術支援サービス。スタートアップから成長企業まで、技術戦略の策定から実装、チーム構築まで包括的にサポートします。

お問い合わせはこちら →