その社内FAQ、Difyで自動化しませんか？RAGボットを「小さく始めて、確実に成果を出す」ための完全ガイド

はじめに

「また同じ質問が来た……」その対応、もう終わりにしませんか？

社内の問い合わせ対応に追われていませんか？ 「有給の申請方法」「VPNの接続手順」「経費精算のフロー」——何度も同じ質問に答え続ける毎日。社内Wikiを整備したのに誰も見てくれない。ChatGPTを導入してみたけれど、社内の情報は参照できず、結局使われなくなった。

この記事では、そんな悩みを抱える情シス・DX担当・総務人事の皆さまに向けて、 オープンソースのLLMアプリ開発プラットフォーム「Dify」¹ を使った社内問い合わせボット（RAG）の導入方法を、「小さく始めて、確実に成果を出す」というアプローチで解説します。

---

1. 社内問い合わせ対応、なぜ"詰む"のか

ありがちな現状

多くの企業で、社内問い合わせ対応は次のような悪循環に陥っています。

この問題の本質は 「情報はあるのに、届いていない」 ということ。必要なのは「もっとドキュメントを書くこと」ではなく、 既存の情報を適切に届ける仕組み です。

問い合わせ対応の"隠れコスト"

1件の問い合わせに平均15分かかるとして、1日10件なら 月間50時間。これは正社員1人の約3割の工数に相当します。しかも、この時間は「答えを知っているベテラン社員」が消費しているケースがほとんど。つまり、 最も生産性の高い人材が、最も定型的な作業に時間を奪われている のです。

---

2. ChatGPT単体では解決できない3つの壁

「じゃあChatGPTに聞けばいいのでは？」——その発想は自然ですが、社内問い合わせの自動化にChatGPT単体で取り組むと、3つの壁にぶつかります。

壁1：情報の非公開性

ChatGPTは公開情報で学習しています。 自社の就業規則、社内システムの操作手順、独自の業務フロー といった非公開情報には答えられません。「うちの会社の有給申請の方法を教えて」と聞いても、一般的な回答しか返ってきません。

壁2：ハルシネーション（もっともらしいウソ）

社内規程のような正確性が求められる領域で、AIが「それっぽいが間違った回答」を返すのは致命的です。ChatGPT単体では、回答の根拠となるソースを明示することが難しく、 回答の信頼性を担保できません。

壁3：カスタマイズ性の限界

「回答トーンを自社に合わせたい」「特定の部署だけに公開したい」「回答できない質問は有人対応にエスカレーションしたい」——こうした 業務に合わせた細かいカスタマイズ は、ChatGPTの標準機能だけでは実現が困難です。

これらの壁を越えるために必要な技術が「RAG（検索拡張生成）」であり、それを手軽に実装できるプラットフォームが「Dify」です。

---

3. なぜDifyなのか？

——RAGボットに最適な理由

RAG（Retrieval-Augmented Generation）とは

RAGとは、ユーザーの質問に対して社内ドキュメントを検索し、その情報をもとにLLMが回答を生成する仕組みです。

LLM単体では社内情報を知らず、根拠も示せません。RAGはこの弱点を「社内DBの検索」で補い、根拠のある正確な回答を実現します。

Difyが選ばれる5つの理由¹

Difyと他の選択肢の比較

---

4. 「小さく始める」導入ステップ5段階

RAGボットの導入で最も重要なのは、 いきなり全社展開しないこと。小さく始めて、成功体験を積み重ねながらスケールさせるのが鉄則です。

Step 1：対象領域を1つに絞る（1〜2日）

まず、 最も問い合わせが多く、回答が定型的な領域 を1つ選びます。

おすすめの初手：

• 情シス → 「PC・ネットワーク関連のFAQ」
• 総務・人事 → 「勤怠・有給・福利厚生のFAQ」
• 経理 → 「経費精算の手順」

選定基準：

• 月に10件以上、同じような質問が来ている
• 回答がドキュメント化されている（または短時間で整理できる）
• 間違った回答をしても重大なリスクがない

Step 2：ナレッジ（ドキュメント）を整備する（3〜5日）

RAGの精度は 「入れるドキュメントの質」 で8割が決まります。

やりがちなNG：

• 100ページの規程集をそのまま丸ごとアップロード → チャンクが不適切になり精度が低下
• 古い情報が混在 → 誤った回答の原因に

Step 3：Difyでボットを構築する（1〜2日）²

Difyの管理画面から、以下の手順で構築します。

1. ナレッジベースを作成 — 整備したドキュメントをアップロード
2. チャンクの設定を調整 — デフォルト設定で開始し、後から最適化
3. チャットボットアプリを作成 — ナレッジベースを「コンテキスト」に紐づけ
4. プロンプトを設定 — 回答のトーン、範囲、回答できない場合の対応を指示
5. テストと調整 — 想定質問で動作確認し、プロンプトとチャンク設定をチューニング

プロンプト設定例：

あなたは〇〇株式会社の社内問い合わせ対応アシスタントです。
以下のルールに従って回答してください。

1. 提供されたナレッジベースの情報のみを使って回答すること
2. ナレッジベースに該当する情報がない場合は「この質問については担当部署（△△部）にお問い合わせください」と案内すること
3. 回答の末尾に、参照した資料名を記載すること
4. 丁寧かつ簡潔に回答すること

Step 4：一部のメンバーで「テスト運用」を開始する（2〜4週間）

いきなり全社に公開するのではなく、まずは特定の部署やチームなど、 限定したメンバー（10〜30名程度） で実際に使ってみます。

テスト運用で確認すべきこと：

• 回答の正確性（間違った回答をしていないか）
• ユーザーの利用頻度（どれくらい使われているか）
• 「回答できなかった質問」の履歴 → 追加すべき社内ドキュメントのヒントになります
• 実際に使ってみた社員からの率直な感想

この段階で完璧を目指さないことが重要です。まずは「8割の質問に正しく答えられる」状態を目指しましょう。

Step 5：改善を重ねながら、利用範囲を広げる（継続）

テスト運用の結果をもとにボットを賢く育て、対象領域や利用する部署を段階的に拡大していきます。

[テスト運用] → [ログ分析・改善] → [対象拡大] → [ログ分析・改善] → ...

拡大ステップの目安：

• 1ヶ月目：1部署 × 1領域（例：情シス部門内だけでのテスト）
• 3ヶ月目：2〜3部署 × 2〜3領域（例：管理部門全体へ拡大）
• 6ヶ月目：全社展開を検討

---

5. よくある失敗パターンとその防ぎ方

RAGボットの導入で「とりあえず入れたが使われなかった」というケースは少なくありません。典型的な失敗パターンと、その対策を紹介します。

失敗パターン1：「全部入れればいいだろう」症候群

症状： 社内のあらゆるドキュメントを片っ端からアップロード。結果、関連性の低い情報がヒットし、回答精度が著しく低下。

対策： 最初は対象を絞り、 少量の高品質なドキュメント からスタートする。「広く浅く」より「狭く深く」が鉄則。

失敗パターン2：「作って終わり」放置型

症状： ボットを公開したが、ドキュメントの更新が止まる。3ヶ月後には古い情報で回答するようになり、信頼を失う。

対策： ドキュメントの更新フローを業務に組み込む。 規程が変わったら必ずナレッジベースも更新するルールを設定する。月次のメンテナンス日を設けるのも有効。

失敗パターン3：「便利ですよ」だけのアナウンス

症状： Slackで一度告知しただけ。存在を知らない人が大半で、利用率が上がらない。

対策： 導線の設計が重要。 問い合わせが来たら「まずボットに聞いてみてください」と案内するフローを作る。Slackのチャンネル説明に常設リンクを置く。社内ポータルのトップに配置する。

失敗パターン4：「AIだから完璧」への過剰期待

症状： 経営層が「AI導入で問い合わせゼロに」と期待。実際には対応できない質問もあり、「使えない」という評価に。

対策： 事前に 「自動対応率70〜80%」を目標として合意 しておく。残り20〜30%は有人対応との併用が前提であることを明確にする。

失敗パターン5：「セキュリティが心配」で立ち消え

症状： 情報セキュリティ部門の承認が得られず、プロジェクトが頓挫。

対策： Difyはセルフホストが可能¹。 社内データが外部に出ない構成 を提案する。利用するLLMの選定（API経由 or ローカルLLM）についても、セキュリティポリシーに合わせて検討する。導入前に情報セキュリティ部門を巻き込むのが鉄則。

---

6. 導入効果の測り方

——上司を説得する数字の作り方

「効果がありそう」では予算は通りません。Difyのログ機能を活用した定量的な効果測定の方法を紹介します。

測定すべきKPIとDifyでの計測方法

Difyの「ログ&アノテーション」画面では、会話ごとの内容・ユーザーの評価・参照されたナレッジソースを確認できます。週次でこの画面をチェックし、回答精度の低い質問パターンを特定してプロンプトやナレッジを改善するサイクルを回しましょう。

ROIの試算例

【Before】

• 月間問い合わせ件数：200件
• 1件あたりの対応時間：15分
• 月間対応工数：200件 × 15分 = 50時間
• 人件費換算（時給3,000円）：150,000円/月

【After（自動対応率70%の場合）】

• 自動対応：140件（対応工数ゼロ）
• 有人対応：60件 × 15分 = 15時間
• 月間削減工数：35時間
• 月間削減コスト：105,000円/月
• 年間削減コスト：1,260,000円/年

【Dify運用コスト（目安）】

• サーバー費用：5,000〜20,000円/月
• LLM API利用料：10,000〜30,000円/月
• 年間運用コスト：180,000〜600,000円/年

→ 年間60万〜100万円以上のコスト削減効果 ※担当者の「本来業務に集中できる時間」の価値はさらに大きい

まとめ

社内問い合わせの自動化は、「AIを入れれば解決する」という単純な話ではありません。しかし、 正しいアプローチで、小さく始めて、改善サイクルを回していけば、確実に成果が出る領域 です。

Difyは、そのための最適なプラットフォームです。

• 社内の非公開情報に基づいた正確な回答
• 出典を明示した信頼性の高いレスポンス
• ノーコードで構築可能な手軽さ
• セルフホストによるセキュリティ担保

「同じ質問に答え続ける毎日」を、今日で最後にしませんか？

---

出典一覧

• Dify公式ドキュメント - Introduction
• Dify公式チュートリアル - Customer Service Bot