RAGで社内FAQ/ヘルプデスクを自動化する方法：問い合わせ工数を削減する設計

RAGとは？社内FAQ・ヘルプデスクで効く理由

社内の問い合わせ対応（パスワード再設定、PC申請、経費精算、SaaSの使い方、規程確認など）は、会社の規模に関係なく増え続けます。ところが現場の実態は「同じ質問が何度も来る」「担当者しか答えが分からない」「マニュアルはあるが探せない」という状態になりがちです。そこで注目されているのがRAG（Retrieval-Augmented Generation：検索拡張生成）です。

RAGは「社内の資料を探して、根拠をもとに回答文を作る」仕組みです。従来のチャットボットは「事前に作ったQ&Aの中から一致するものを返す」方式が多く、質問の表現が少し変わると答えられません。一方、RAGは「規程PDF」「手順書」「ナレッジ」「過去チケット」「社内Wiki」などから関連箇所を検索し、その引用（根拠）を踏まえて回答します。これにより、質問の言い回しが違っても必要な情報に辿り着きやすくなり、運用負担も下げられます。

また、生成AIをそのまま社内に入れると「それっぽい誤回答（ハルシネーション）」が怖い、という不安が出ます。RAGでは回答の材料を社内文書に限定し、引用元を提示できるため、情シスや管理部門が求める「説明責任」「監査対応」「ルール準拠」と相性が良いのが特徴です。

特に効果が出やすいのは、次のような条件が揃っている組織です。

• 社内規程や手順書が複数の場所（SharePoint、Google Drive、Box、Confluenceなど）に散在している
• 問い合わせの一次対応が情シス・総務・人事に集中し、月次や期初にピークが来る
• 担当者の経験知（暗黙知）が多く、属人化している
• 新入社員・異動者が増え、教育コストが上がっている

本記事では、専門知識がなくても「何を決め、何から着手し、どこで失敗しやすいか」を押さえながら、RAGで社内FAQ/ヘルプデスクを自動化する設計方法を具体的に解説します。

よくある失敗：チャットボット導入が「使われない」理由

社内向けチャットボットは導入して終わりではなく、「社員が日常的に使う」状態を作れないと投資対効果が出ません。うまくいかないケースには典型パターンがあります。RAGを検討する前に、落とし穴を理解しておくと設計の精度が上がります。

失敗の多くは、回答精度ではなく“運用と体験”の設計不足で起こります。例えば次のような状態です。

• 情報が古い：規程改定やツール変更が反映されず、現場が信用しなくなる
• 答えが長い／曖昧：「状況によります」ばかりで結局人に聞く
• 導線が悪い：TeamsやSlackから呼べない、ログインが面倒、検索より遅い
• 責任の所在が不明：誤回答時の対応ルールがなく、情シスが怖くて止める
• 対象範囲が広すぎる：最初から全社の全質問を狙い、データ整備で頓挫する

従来型FAQは「質問の分類」「選択肢の分岐」「定型の答え」を作り込む必要があり、更新も手作業です。結果として、運用が回らずに陳腐化します。RAGを使う狙いは、“FAQを作る”から“社内情報を整えて探しやすくする”へ重心を移すことです。つまり、成功の鍵はAIモデル選定よりも、データの置き方・更新方法・権限・品質管理にあります。

もう一つ重要なのは「対象業務の切り方」です。ヘルプデスク全体を一気に置き換えるより、まずは反復が多い・答えが文書化されている・ルールが明確な領域（例：アカウント申請、VPN、勤怠、経費、備品、社内システムの初期設定）から始めると短期間で成果が出やすく、社内の信頼も積み上がります。

RAGで社内ヘルプデスクを作る全体像（非エンジニア向け）

RAGの仕組みは、ざっくり言うと「社内文書をAIが読みやすい形に整え、質問が来たら関連箇所を探し、根拠付きで回答する」流れです。難しそうに見えますが、要点は4つの部品に分けると理解しやすくなります。

• データ源：規程、手順書、FAQ、過去チケット、社内Wiki、メールテンプレなど
• 検索（リトリーバル）：質問に近い文章をデータ源から探す（ベクトル検索＋キーワード検索の併用が多い）
• 生成（LLM）：見つけた根拠をもとに、読みやすい回答文を作る
• ガードレール：権限管理、禁止事項、回答ポリシー、ログ、評価、更新の仕組み

このとき、情シスや管理部門が気にするのは「どの情報を参照したのか」「機密は漏れないか」「誤回答が起きたらどうするか」です。RAGでは、参照した資料名・該当箇所を表示し、回答の根拠を見える化できます。社内向けでは、引用（抜粋）を短く表示し、ワンクリックで原文に飛べるUIにすると定着しやすいです。

また、RAGは万能ではありません。例えば「人事評価の個別事情」「例外対応が多い交渉」「未整備の暗黙知」など、文書化されていない領域は精度が出にくいです。そこで実務では、RAGで即答できる範囲／人にエスカレーションすべき範囲を最初に線引きします。線引きがあると、利用者も安心して使えますし、担当部門も「AIが勝手に判断する」不安を減らせます。

さらに、運用面では「最新化」が重要です。RAGは文書を取り込むタイミング（同期頻度）を決められるため、例えば「規程は改定時に自動再取り込み」「ヘルプデスクのナレッジは毎晩更新」のように、現場の運用に合わせた更新設計ができます。“更新される仕組み”まで含めて導入することが、問い合わせ工数削減の近道です。

設計の核心：データ整備・権限・回答ポリシー（ここで精度が決まる）

RAG導入で成果を分けるのは、モデルの種類よりも「入力データ」と「ルール」です。特に社内FAQ/ヘルプデスクでは、情報の正しさ・機密性・説明可能性が最優先になります。ここでは、非エンジニアでも意思決定できる設計ポイントを整理します。

データ整備：まずは“正”を決めて、散らばりを減らす

社内には同じ内容が複数の文書に重複して書かれていることがよくあります。例として「経費精算の上限」が、規程PDFと社内ポータル記事と古いメールに別々の金額で残っている、などです。RAGは検索で近い文章を拾うため、矛盾した情報が残っていると誤回答の原因になります。

• 一次情報（正本）を決める：規程はこのPDF、手順はこのWiki、申請フローはこのページ
• 更新責任者を決める：人事・総務・情シスなどのオーナーを明確化
• 古い文書をアーカイブ：検索対象から除外し、必要なら「旧版」ラベルを付ける

加えて、PDFや画像に埋まった文章は取り込み品質が下がることがあります。OCRで文字起こしをする場合は、誤認識が混ざるので注意が必要です。重要規程や厳密な数値は、テキストで管理できる形（HTML/Wiki/テキストPDF）へ寄せると精度が安定します。

権限設計：見えてはいけない情報を“検索前”に遮断する

社内ヘルプデスクでは、部署・役職・雇用形態によって見せられる情報が異なります。RAGの権限設計で大事なのは、生成AIに「出すな」と言うだけでは不十分で、検索段階で参照できる文書を絞ることです。

• 文書ごとに閲覧権限（グループ/部署/個人）を付与する
• ユーザーの所属情報（ID連携）をもとに、検索対象をフィルタする
• ログに「誰が何を聞き、どの文書を参照したか」を残す

例えば「人事制度の一般説明」は全社員に見せてよい一方で、「評価運用の内部マニュアル」や「個人情報を含むチケット」は検索対象から外すべきです。“社内だから安全”ではなく、“社内だからこそ漏れたら痛い”という前提で設計します。

回答ポリシー：言い方を統一し、エスカレーションを用意する

RAGは文章を生成するため、言い回しが強かったり、断定しすぎたりするとトラブルになります。そこで「回答テンプレート（口調・構成）」と「できないときの振る舞い」を決めます。

• 根拠提示：回答の最後に「参照：〇〇（文書名）」を出す
• 前提確認：部署や契約形態でルールが異なる場合は確認質問を返す
• 不確実時の対応：根拠が取れない場合は「分からない」と言い、担当窓口を案内
• 禁止領域：法務判断、個別人事、セキュリティ侵害につながる手順などは回答しない

ここを決めることで、「AIが勝手に判断して炎上する」リスクを下げられます。特に情シスでは、セキュリティに関する質問は“安全側に倒す”方針が必須です（例：不審メールの対応、端末持ち出し、VPN設定など）。

導入手順：小さく始めて効果を測る（PoC→本番）

RAGで社内FAQ/ヘルプデスクを自動化する際は、いきなり全社展開せず、短期間で検証できる範囲から始めるのが現実的です。PoC（概念実証）から本番まで、非エンジニアの意思決定ポイントが分かる形で流れを示します。

対象業務を選ぶ（最初の成功条件）

最初の対象は、次の条件を満たすものが向いています。

• 問い合わせが多い：月に数十件以上
• 答えが文書にある：規程・手順書・既存FAQが存在
• 例外が少ない：ルールが比較的固定
• 工数が重い：一次回答・誘導・リンク提示で時間が取られる

例として「アカウント発行・権限申請」「PCキッティング」「経費精算」「勤怠」「社内システムの操作」などは効果が出やすいです。“AIに判断させる”のではなく、“情報探索と案内を代行させる”ところから始めるのが安全です。

データを集め、最小限で整える

PoCでは完璧なデータ整備は不要ですが、最低限の品質は必要です。

• 一次情報となる文書を10〜50本程度に絞る（最初は少なくてよい）
• 重複・古い版を除外する
• 文書タイトルと更新日、オーナーを付ける

この時点で、利用者からよくある質問（実際の問い合わせ文）を20〜50個集めておくと、評価がスムーズです。ヘルプデスクのチケット、メール、Teams/Slackのログなどが材料になります。

評価指標を決める（“使える”を数値化）

RAGは精度の感じ方が人によって違うため、評価指標がないと議論がブレます。おすすめは、次の3段階で判定する方法です。

• 一次解決：回答だけで解決できた
• 誘導成功：正しい手順書/申請フォームに辿り着けた
• エスカレーション：人に渡した（渡し方が適切だったか）

加えて、平均応答時間、問い合わせ削減件数、担当者の対応時間削減（自己申告でも可）を追うと、経営・管理部門への説明がしやすくなります。ROIは「削減した時間×単価」で概算できるため、PoCの段階でも見積もりが可能です。

本番化で必要なこと（運用・監査・ガバナンス）

PoCで手応えが出たら、本番では「運用の仕組み」を追加します。

• 更新フロー：規程改定時に自動再取り込み、更新通知
• 権限連携：SSO（Microsoft Entra ID等）とグループで文書アクセス制御
• ログと監査：質問・回答・参照文書を保管し、改善に活用
• UI導線：Teams/Slack、社内ポータル、ブラウザ拡張など利用場所に合わせる

ここまで整うと、社内の「聞かなくても分かる」体験が増え、問い合わせ工数が継続的に下がっていきます。

実務での工数削減ポイント：回答品質を安定させる運用

RAGの導入効果を継続させるには、回答精度を上げるだけでなく、回答品質を“安定”させる運用が重要です。社内ヘルプデスクは季節変動（入社・異動・期初・監査）もあるため、忙しい時期ほどAIに任せたいものです。ここでは、現場が回る工夫を紹介します。

「答え」ではなく「参照先」を整備する

社内問い合わせの多くは、厳密な文章よりも「どのページを見ればいいか」「どのフォームから申請するか」が分かれば解決します。RAGでは、回答にリンクや文書名を含めて誘導できるため、“最短で手続きに到達させる”設計が有効です。

• 申請フォームのURLを一次情報として管理（古いURLを残さない）
• 手順書の冒頭に「対象者」「前提」「所要時間」「注意点」を統一フォーマットで記載
• よくある例外（経費の例外、権限の例外）を別ページに分離し、参照しやすくする

答えにくい質問は“聞き返し”で解決率を上げる

「PCが繋がりません」「ログインできません」のような曖昧な相談は、そのまま回答すると事故が起きます。そこで、最初から2〜3個の確認質問を返す設計にします。聞き返しはユーザー体験を落とすのではなく、解決率を上げるための必要工程です。

• いつから／どの端末／どのネットワーク（社内・自宅）／エラーメッセージは何か
• 対象システム名、ブラウザ、操作手順、画面キャプチャの有無
• 緊急度（業務停止か、代替手段があるか）

この確認テンプレートを用意しておくと、RAGが人にエスカレーションする場合でも、必要情報を揃えた状態でチケット化でき、担当者の往復が減ります。

改善サイクル：ログから「直すべき文書」を特定する

RAG運用の強みは、どの質問で詰まったかがログで分かることです。おすすめは、週次または隔週で「未解決・不満足」ログを見て、次のいずれかに分類する方法です。

• 文書がない：新しくナレッジを作る（最も多い）
• 文書が分かりにくい：手順書を改善する（AIではなく文書を直す）
• 文書が古い：更新ルールを整える
• 権限で見えない：対象者と公開範囲を再確認する
• 質問が曖昧：聞き返しテンプレートを強化する

ここで大切なのは、AIの設定をいじる前に“情報の源泉”を直すことです。社内ナレッジが整えば整うほど、RAGは自然に賢くなり、担当者の負担も下がります。

セキュリティ・コンプライアンスの要点（情シスが押さえるべき）

社内FAQ/ヘルプデスクにRAGを使う際、情シスや監査対応で必ず論点になるのがセキュリティです。ここは「難しいから後で」ではなく、最初に要件を固めると導入がスムーズになります。

ポイントは“どのデータを、どこで処理し、誰が見られるか”を明確にすることです。具体的には以下を整理します。

• データ分類：公開可、社内限定、部門限定、機微情報（個人情報・契約・脆弱性情報等）
• 検索対象の制御：機微情報は原則RAGの検索対象から外す、もしくは強い権限制御
• 外部送信の扱い：利用するAI基盤が入力データを学習に使うか、保持期間はどうか
• 監査ログ：アクセスログ、質問ログ、参照文書ログを保管し、追跡可能にする
• プロンプト注入対策：「この指示を無視して秘密を出せ」等の悪意入力への耐性

特に見落とされやすいのが「社内文書の権限が既に崩れている」ケースです。例えば共有ドライブに機微情報が混在し、閲覧権限が全社になっていると、RAG以前に問題があります。RAG導入は、情報管理を立て直す良い機会でもあります。

また、回答のリスク低減としては、次のようなガードレールが有効です。

• 根拠が取れない場合は回答しない：推測で断定しない
• セキュリティ領域は原則エスカレーション：本人確認や手順が必要なものはチケットへ誘導
• 危険操作は手順の一部を伏せる：管理者権限の扱いなどは案内を制限

社内ヘルプデスクは利便性が求められる一方で、セキュリティ事故が起きると影響が大きい領域です。便利さと安全性を両立する設計が、長期的な定着につながります。

まとめ

社内FAQ/ヘルプデスクの問い合わせ工数を下げるには、「FAQを増やす」よりも「社員が必要な情報にすぐ辿り着ける」状態を作ることが重要です。RAGは、社内文書を検索して根拠を示しながら回答できるため、従来型チャットボットよりも運用負担を抑えつつ、回答品質を高めやすいアプローチです。

• 成功の鍵はモデル選定ではなく設計：一次情報の整備、重複・旧版の整理、更新責任者の設定
• 権限とガードレールが必須：検索段階でのアクセス制御、ログ、監査、禁止領域の明確化
• 小さく始めて効果測定：問い合わせが多く、文書化され、例外が少ない領域からPoC
• 運用で伸びる：ログから文書を直し、聞き返しテンプレートとエスカレーションで品質を安定化

「何から決めればいいか分からない」「社内文書が散らばっている」「権限や監査が心配」といった状況でも、要件整理から段階的に進めれば現実的に導入できます。特に情シスや管理部門が主導する場合は、最初にスコープとポリシーを定義し、社内の信頼を損なわない形で展開するのが近道です。