「社内マニュアルの内容、毎回同じ質問に答えるの面倒だな」と思ったことはないだろうか。DifyのRAG機能を使えば、プログラミング不要で社内文書Q&Aチャットボットを構築できる。
ただし「とりあえず文書をアップロードすれば動く」と思うと精度で苦しむ。この記事では構築手順だけでなく、チャンク設計・Embeddingモデル選び・検索パラメータ調整まで踏み込んで解説する。
RAG（検索拡張生成）とは？仕組みを30秒で理解
RAG = Retrieval Augmented Generation（検索拡張生成）。通常のAIは学習データにない情報には「分かりません」としか答えられない。RAGは「まず関連する社内文書を検索し、その内容をAIに渡して回答させる」仕組み。
処理の流れは3ステップ:
- インデックス化: 文書をチャンク（小さなテキスト断片）に分割し、各チャンクをベクトル（数値の配列）に変換して保存
- 検索（Retrieval）: ユーザーの質問もベクトル化し、意味が近いチャンクを上位N件取得
- 生成（Generation）: 取得したチャンクを「参考情報」としてLLMに渡し、回答を生成
| 質問例 | RAGなし | RAGあり |
|---|---|---|
| 「有給休暇は何日？」 | 一般的な労働基準法の話をする | 就業規則第15条を参照し「入社6ヶ月で10日」と回答 |
| 「製品Aの耐荷重は？」 | 「情報がありません」 | 製品カタログから「500kg」と回答 |
| 「先月の売上実績は？」 | 学習データが古く答えられない | 最新の月次レポートを参照して回答 |
DifyでRAGチャットボットを構築する全手順
事前準備: APIキーとEmbeddingモデルの設定
Difyは裏側でOpenAIやAnthropicのLLM APIを呼ぶ。最初にAPIキーを設定しないと何も動かない。
- dify.aiにサインアップ（無料のSandboxプランでOK）
- 右上のアカウントメニュー →「Settings」→「Model Provider」
- OpenAI / Anthropic等のAPIキーを入力
- Embeddingモデルも必ず設定する（これを忘れるとナレッジベース作成時にエラーになる）
Embeddingモデルの選び方:
| モデル | 特徴 | おすすめ用途 |
|---|---|---|
| text-embedding-3-small | 安価（$0.02/100万トークン）・精度十分 | コスト重視・一般的な社内文書 |
| text-embedding-3-large | 高精度・コスト高め | 精度重視・技術文書・法務文書 |
| text-embedding-ada-002 | 旧世代・コスパ悪い | 非推奨（3-smallの方が安くて高精度） |
迷ったらtext-embedding-3-smallで始めて、精度が足りなければ3-largeに切り替えるのが合理的。
Step 1: ナレッジベースの作成と文書アップロード
- 左メニュー「Knowledge」→「Create Knowledge」
- ナレッジベース名を入力（例:「社内規程集」「製品マニュアル」）
- 文書ファイルをドラッグ＆ドロップ
対応フォーマット: PDF、Word（.docx）、テキスト（.txt）、Markdown（.md）、HTML、CSV、Excel。日本語文書も正常に処理される。
Step 2: チャンク設定（RAG精度の8割はここで決まる）
文書アップロード後、チャンク分割の設定画面が表示される。RAGの回答精度はチャンク設計でほぼ決まるため、ここは妥協しない。
| 設定項目 | 推奨値 | 理由 |
|---|---|---|
| チャンクサイズ | 500〜1,000文字 | 大きすぎると無関係な情報が混入。小さすぎると文脈が失われる |
| チャンクオーバーラップ | 50〜100文字 | チャンク境界の情報欠落を防ぐ（前後のチャンクと内容を重複させる） |
| セパレータ | 見出し・改行 | 意味の区切りで分割すると検索精度が上がる |
| インデックスモード | 高品質（High Quality） | Embeddingベクトル検索を使用。「経済的」モードはキーワード検索のみで精度が低い |
よくある失敗: デフォルトの「Automatic」のまま大量の文書を投入すると、チャンクの区切り位置がズレて回答精度が下がる。特に日本語PDFは改行位置が不自然なことが多いため、Manual設定でセパレータを指定する方が精度が出やすい。
Step 3: チャットボットアプリの作成
- 「Apps」→「Create App」→「Chatbot」を選択
- アプリ名を入力（例:「社内マニュアルQ&A」）
- LLMモデルを選択（GPT-4o / Claude 3.5 Sonnet等）
Step 4: ナレッジベースの接続とプロンプト設計
チャットボット設定画面の「Context」セクションでStep 1のナレッジベースを追加。次にシステムプロンプトを設計する。
プロンプト設計のポイント:
あなたは社内文書に基づいて回答するQ&Aアシスタントです。
ルール:
1. 提供されたコンテキスト（社内文書）の内容のみに基づいて回答してください
2. コンテキストに情報がない場合は「該当する情報が見つかりませんでした。○○部門にお問い合わせください」と答えてください
3. 回答の最後に参照元の文書名・セクション名を記載してください
4. 推測や一般論で補完しないでくださいルール2の「見つからない場合の回答」を明確に指定することで、AIが知らないことを勝手に作り出すハルシネーション（事実と異なる回答の生成）を抑制できる。
Step 5: 検索パラメータの調整
Context設定で以下のパラメータを調整する:
| パラメータ | デフォルト | 推奨 | 効果 |
|---|---|---|---|
| Top K | 3 | 5〜8 | 検索で取得するチャンク数。増やすと情報量が増えるが、無関係な情報も混入しやすくなる |
| Score Threshold | なし | 0.3〜0.5 | 類似度スコアの下限。低品質なチャンクを除外できる |
| 検索方式 | ベクトル検索 | ハイブリッド検索 | ベクトル検索＋キーワード検索の組み合わせ。固有名詞に強くなる |
ハイブリッド検索を推奨する理由: ベクトル検索だけでは「製品A-3200X」のような型番・固有名詞の検索精度が低い。キーワード検索を併用するハイブリッド方式なら、意味検索と完全一致検索の両方の利点を活かせる。
Step 6: テスト・改善・公開
右パネルのプレビューで実際に質問してテスト。以下のパターンで検証する:
- 正常系: 文書に答えがある質問 → 正確に回答されるか
- 異常系: 文書に答えがない質問 → 「見つかりませんでした」と返すか
- 曖昧系: 複数の文書にまたがる質問 → 情報が混同されないか
問題なければ「Publish」で公開。URLが発行され、チームメンバーに共有できる。
RAG精度が低い時のトラブルシューティング
| 症状 | 原因 | 対処法 |
|---|---|---|
| 関係ない情報が回答に混入する | チャンクサイズが大きすぎる | 500文字以下に縮小。Score Thresholdを0.4以上に設定 |
| 「情報がありません」と返される | チャンクが細かすぎて文脈が失われている | チャンクサイズを800〜1000に増やす。Top Kを増やす |
| 固有名詞（型番等）が検索にヒットしない | ベクトル検索は意味検索のため完全一致に弱い | ハイブリッド検索に切り替える |
| PDF文書の回答精度が特に低い | PDFのテキスト抽出で改行・空白が不自然に入る | PDFをMarkdownに変換してからアップロード |
| 複数文書の内容が混同される | 異なる文書のチャンクが類似度が高い | ナレッジベースを文書カテゴリ別に分離する |
RAGの活用例と導入効果
| 部門 | 活用例 | 読み込む文書 | 導入効果 |
|---|---|---|---|
| 人事 | 就業規則Q&Aボット | 就業規則PDF | 人事への問い合わせ対応工数の削減 |
| IT | 社内ヘルプデスクAI | 社内マニュアル・FAQ集 | ヘルプデスクの一次対応を自動化 |
| 営業 | 製品仕様の即時回答 | 製品カタログ・仕様書 | 商談中の「持ち帰り」を削減 |
| 法務 | 契約書条項の検索 | 契約書テンプレート集 | 条項の見落とし防止 |
| カスタマーサポート | FAQ自動応答 | 過去の問い合わせ履歴 | 一次対応の自動化で応対速度向上 |
特に効果が高いのは構造化された文書（就業規則・マニュアル・仕様書等）。自由記述の議事録や日報はRAGの検索精度が下がりやすいため、見出し付きのMarkdown形式に整理してからアップロードするのがおすすめ。
Dify RAG vs 他のRAGツール
| ツール | 特徴 | 向いている人 | 難易度 |
|---|---|---|---|
| Dify | ノーコードでRAGを構築。GUI上で完結 | 非エンジニア・PM | 低 |
| LangChain + Python | コードでRAGパイプラインを自由にカスタマイズ | エンジニア | 高 |
| ChatGPT（GPTs） | ファイルアップロードで簡易RAG | 個人利用・手軽に試したい人 | 最低 |
| Amazon Bedrock Knowledge Base | AWSインフラと統合。S3から文書を自動取り込み | AWS利用企業 | 中〜高 |
Difyの強みはノーコードでRAGが組めることとチーム共有が容易なこと。LangChainほどの柔軟性はないが、社内Q&Aボット程度の用途なら十分な精度が出る。セルフホスト版ならDocker Composeで自社サーバーに構築でき、機密文書を外部に出さずに済む。
よくある質問
Q: 無料プランでRAGは使える？
使える。ただしSandbox（無料）プランはアップロード容量5MB・メッセージ200回/月の制限がある。本格運用するならProfessional（$59/月）か、制限のないセルフホスト版を検討する。→「Dify料金ガイド」
Q: 日本語の文書でも精度は出る？
出る。ただしEmbeddingモデルに多言語対応のtext-embedding-3-small以上を選ぶこと。旧世代のada-002は日本語の精度が低い。また、PDF文書は日本語の改行位置がズレやすいため、Markdownに変換してからアップロードすると精度が上がる。
Q: RAGの回答精度が低い場合はどうする？
まずチャンクサイズを調整する（500〜1000文字）。次にハイブリッド検索に切り替える。それでも改善しなければ、アップロード文書のフォーマットを見直す（見出し構造を明確にする・PDFをMarkdownに変換する）。上記のトラブルシューティング表も参照。
Q: 社内の機密文書をアップロードしても大丈夫？
Difyクラウド版のデータは暗号化されるが、機密性の高い文書を扱う場合はセルフホスト版（Docker）を使えばデータを自社サーバーに留められる。公式のセルフホストガイドに手順がある。
Q: 文書を更新したらRAGの内容も自動で更新される？
自動更新はされない。文書を更新した場合は、ナレッジベースで該当ファイルを削除→再アップロードする必要がある。Dify APIを使えばこの更新作業をスクリプトで自動化することも可能。
まとめ
DifyのRAG機能を使えば、ノーコードで社内文書Q&Aチャットボットを構築できる。ただし「文書をアップロードして終わり」ではなく、チャンクサイズ・検索方式・プロンプト設計の調整が回答精度を大きく左右する。特にハイブリッド検索の有効化とチャンクオーバーラップの設定は忘れがち。Difyの基礎は「Difyとは？使い方ガイド」、ワークフロー機能は「Difyワークフローの作り方」、サービス連携の自動化なら「n8nとは？」、料金は「Dify料金ガイド」で解説。
