Dify で社内ドキュメントを使う RAG チャットボットを作る

Dify は、ノーコードで LLM アプリを構築できる開発プラットフォームです。

社内マニュアルや就業規程、製品ドキュメントが年々増え、必要な一文を探すだけで数十分かかる——そんな状況に心当たりはありませんか。検索窓にキーワードを打ち込んでも、ファイル名が違う、用語の表記が揺れている、そもそもどのフォルダに入っているか分からない。担当者に聞けば早いけれど、その担当者も毎回同じ質問に答えるのは負担です。

この「探す手間」を肩代わりさせるのが、社内ドキュメントを参照して答える AI チャットボット。Dify のナレッジ機能を使えば、コードを一行も書かずに、自社の文書に基づいて回答する RAG チャットボットを組み立てられます。

以下では、RAG の仕組みの理解から、準備、ナレッジ登録までを順を追って解説します。設定画面のどこを触ればよいか、初心者がつまずきやすいポイントも合わせて押さえていきましょう。

DifyとRAGの基礎｜なぜ社内ドキュメント検索に向くのか

Dify は、ChatGPT のような対話アプリや、文書を要約するワークフローなど、LLM を使ったアプリケーションを画面操作で組めるプラットフォームです。公式はオープンソースプラットフォームとして案内していますが、リポジトリのライセンスは Apache License 2.0 をベースに追加条件を設けた Dify Open Source License です。クラウド版をそのまま使うことも、自社サーバーや手元の PC に導入して自前運用することもできます。ただしセルフホストで使う場合、マルチテナント環境の運営や、フロントエンドのロゴ・著作権表示の変更にはライセンス上の条件があります。エンジニアでなくても、ブロックを並べる感覚でアプリを設計できる点が大きな特徴です。はじめて触るなら、Dify の基本と始め方をまとめた記事もあわせて読むと、全体像をつかみやすくなります。

Dify は LLM アプリケーション開発のためのオープンソースプラットフォームであり、RAG パイプラインやエージェント機能を備えている。（Dify 公式ドキュメント docs.dify.ai より）

数あるDifyの機能のなかで、社内ドキュメント検索の土台になるのが「ナレッジ」です。ここに文書を登録しておくと、チャットボットが質問のたびにその文書を検索し、関連する箇所を踏まえて回答を生成します。

Difyのナレッジ機能とは

ナレッジ機能は、登録したドキュメントを検索しやすい形に整えて保管する役割を担います。文書をそのまま丸ごと AI に渡すのではなく、検索単位となる小さなかたまり（チャンク）に分割し、選んだインデックス方式に応じて検索用の索引を作ります。

索引の作り方には大きく2つあります。High Quality 方式では、埋め込みモデルを使って各チャンクを数値の並び（ベクトル）に変換し、意味の近さで検索できるようにします。キーワードが完全に一致しなくても、「有給はいつから使える？」という質問から「年次有給休暇の付与時期」という見出しの段落を引き当てられる。表記の揺れに強いのは、このベクトル化の強みです。一方の Economical 方式は、キーワードと転置インデックスで検索する仕組みで、埋め込みモデルは呼び出しません。社内文書を意味の近さで探したいなら、High Quality 方式が候補になります。

登録できるドキュメントの形式や、High Quality 方式で使う埋め込みモデルの選択肢は、バージョンや契約プランによって変わります。対応形式の最新情報は公式ドキュメントで確認するのが確実です。

RAGの仕組みを社内利用シーンで理解する

RAGとは、検索拡張生成（Retrieval-Augmented Generation）の略で、LLM に外部の文書を検索させて回答に反映させる仕組みです。

素の ChatGPT に「うちの会社の経費精算の締め日は？」と聞いても、正しく答えられません。当然です。あなたの会社の規程は、AI が学習したデータのなかに含まれていないのですから。学習していない情報を無理に答えさせると、もっともらしい嘘——いわゆるハルシネーション——が返ってくることもあります。

RAG はこの問題を軽減するために、次の3つの流れを使います。

1. 質問を受け取る
2. 登録済みの社内文書から、質問に関連する箇所を検索して取り出す
3. 取り出した文書を参考情報として LLM に渡し、回答を生成させる

たとえば、締め日が「毎月20日」と規程に書かれていて、その箇所を正しく検索できれば、文書に基づいた回答を返しやすくなります。出典表示を有効にしておけば、利用者は回答がどの文書を参照して生成されたのかを確認できます。

ただし、RAG を使っても誤回答がなくなるわけではありません。検索が質問に合った箇所を拾えなかったり、LLM が文書にない内容を補ってしまったりすることは起こり得ます。だからこそ、文書に記載がない場合の答え方をプロンプトで指定し、出典表示と事前のテストで確認できる運用にしておくことが大切です。

社内利用の場面に当てはめると、就業規程の問い合わせ対応、製品マニュアルからの仕様確認、過去の議事録やナレッジ共有の検索など、「答えはどこかの文書に書いてあるはずだが、探すのが面倒」という業務にぴったりはまります。

構築前に準備するもの｜アカウントとドキュメント整形

実際に手を動かす前に、そろえておくものを確認しておきましょう。準備が整っていれば、構築作業そのものは画面に沿って進めるだけで完了します。

必要になるのは大きく3つです。Dify を使うための環境（クラウド版のアカウント、またはセルフホスト環境）、回答生成や検索に使うモデルの接続設定、そしてチャットボットに参照させる社内ドキュメントです。クラウド LLM や外部の埋め込み・リランクモデルを使う場合は、API キーなどの接続情報が必要になります。一方、Ollama などのローカルモデルでそろえる構成なら、ローカルサーバーの接続設定が中心になります。

社内アプリから直接ローカルLLMを呼び出す構成にしたい場合は、OllamaをローカルAPIサーバーにして社内アプリからLLMを呼ぶ手順も参考になります。

クラウド版とセルフホスト版の選び方

Dify の使い方は、ざっくり2通りに分かれます。

クラウド版は、Web ブラウザからアカウントを作ってすぐ使い始められる形態です。サーバーの用意も保守も不要。まず RAG チャットボットがどんなものか感触をつかみたい初心者は、こちらから入るのが無理のない流れでしょう。

セルフホスト版は、自社サーバーや手元の PC に Dify を導入して動かす形態です。Dify はオープンソースで公開されているため、Docker を使って自分の環境にコンテナとして起動できます。機密文書を扱う場合の選択肢になりますが、セルフホストにしただけでデータの送信が自動的に社内へ閉じるわけではありません。回答生成に使う LLM、埋め込みモデル、リランクモデル、外部データソースや外部ナレッジ API との連携、公開アプリのアクセス設定まで含めて、外部通信が起きないかを一つずつ確認する必要があります。起動に使う正確なコマンドや必要なシステム要件はバージョンによって変わるため、ここでは深追いしません。公式の Getting Started に沿って進めるのが確実です。

どちらを選ぶかの判断軸はシンプルです。扱う文書の機密度と、運用にかけられる手間のバランスで決めます。試す段階ならクラウド版、本番で機密文書を扱うなら、外部通信まで含めて設計したうえでセルフホストを検討する、という順序が現実的でしょう。

登録前にドキュメントを整える

ナレッジに文書を登録する前に、ひと手間かけておくと後の精度が大きく変わります。RAG は「検索して取り出す」仕組みなので、取り出しやすい文書ほど回答の質が上がるからです。

整形のポイントは主に2つあります。まず対応形式に変換しておくこと。Dify が読み込める形式は決まっているので、対象の文書がその形式に収まっているか事前に確認します。具体的にどの形式が使えるかは公式ドキュメントで最新の一覧を見るのが安全です。

もう1つが、文書の構造を整えること。見出しが付いていない長文や、表が画像として貼り付けられただけの資料は、検索でうまく引き当てられないことがあります。見出しで区切る、1つの段落に1つの話題をまとめる、といった基本的な整理をしておくだけで、後段のチャンク分割がきれいに決まりやすくなります。

完璧に整える必要はありません。最初は小さなドキュメントセットで試し、回答のズレを見ながら整形を足していく。この進め方なら、いきなり全社の文書を放り込んで収拾がつかなくなる事態を避けられます。

ナレッジに社内ドキュメントを登録する手順

準備が整ったら、いよいよナレッジへの登録に進みます。ここが RAG チャットボットの心臓部。流れ自体は画面に沿って進めるだけですが、途中の設定に「考え方を知らないと迷う」項目がいくつかあります。順を追って見ていきましょう。

以下では、初めての人にも分かりやすい Quick Create（ファイルからナレッジを作成する基本手順）を使う流れを扱います。Dify には、データ処理の流れをより細かく設計できる Knowledge Pipeline から作成する方法もあり、アップロードの上限や設定画面は作成経路によって変わる場合があります。なお、画面上の表記やボタンの位置も更新で変わることがあるため、以下は操作の骨子として読み、細部は実際の公式画面に合わせて操作してください。

ナレッジを作成してドキュメントを取り込む

最初に行うのは、ナレッジの新規作成です。Dify の管理画面でナレッジのメニューを開き、新しいナレッジを作るところから始めます。名前を付けたら、そこに社内文書をアップロードしていきます。

取り込み方法は、ファイルを直接アップロードする方法が基本です。サービスによっては、外部のデータソースと連携して文書を取り込む選択肢が用意されている場合もあります。まずは手元のファイルを数件アップロードして、登録の流れをつかむのがよいでしょう。

ファイルを選ぶと、Dify がその中身を読み取り、後続の分割とインデックス作成の準備に入ります。大きな文書を一度に大量に入れると処理に時間がかかるため、最初の検証では1〜2件の代表的な文書に絞るのがおすすめです。なお Quick Create でローカルファイルを取り込む場合、公式ドキュメント上は通常1回あたり最大5ファイル・1ファイル最大15MB が目安です。Dify Cloud の有料プランでは最大50ファイルのバッチアップロードに対応し、セルフホストでは環境変数で上限を調整できます。一方、Knowledge Pipeline から作成する場合は、公式ページ上で最大50ファイル・1ファイル15MB と案内されています。

チャンク分割とインデックス方式の設定

ここが初心者の最初の関門です。文書をどう分割するか、どの方式でインデックス（検索用の索引）を作るかを選ぶ画面が出てきます。

チャンク分割は、文書を検索単位の小さなかたまりに切り分ける設定です。1つのチャンクをどのくらいの長さにするか（チャンクサイズ）、隣り合うチャンク同士をどれだけ重ねるか（オーバーラップ）を指定します。

オーバーラップは、チャンクの境目で文章が不自然に途切れるのを防ぐための重なりです。段落の途中で分割されても、前後のチャンクが少し重なっていれば文脈が保たれます。

インデックス方式は、検索の精度とコストのバランスを決める設定です。一般的に、ベクトル検索で意味の近さから引き当てる高品質寄りの方式と、よりシンプルで処理が軽い経済的な方式が用意されています。社内文書の検索で精度を重視するなら前者が向きますが、どちらを選ぶかは扱う文書量と求める精度しだい。埋め込みモデルの選択肢もここで関わってくるため、利用可能なモデルは公式ドキュメントで確認してください。

取り込み結果を確認する

設定を決めて取り込みを実行すると、Dify が文書をチャンクに分割し、選択したインデックス方式に応じて検索用の索引を作成します。High Quality 方式では埋め込みモデルによるベクトル化が、Economical 方式ではキーワードベースの索引づくりが行われます。完了したら、必ず結果を確認しましょう。

確認のポイントは、文書が意図した単位で分割されているかです。多くの場合、取り込んだ文書のチャンクをプレビューで一覧表示できます。1つのチャンクに複数の話題が混ざっていないか、逆に1つの説明が不自然に途中で切れていないかをざっと眺めます。

ここで分割が不自然だと感じたら、チャンクの設定を変えて再インデックスを行います。再インデックスは、すでに取り込んだ文書を新しい設定で作り直す操作です。文書を入れ直す手間なく、設定だけを試行錯誤できるため、精度調整の段階で繰り返し使うことになります。

取り込みが終わった直後は「文書を入れたのに、テストで質問しても反映されない」と感じることがあります。その多くは、インデックスの作成がまだ完了していない、もしくはチャットアプリ側にこのナレッジを紐付けていないことが原因です。紐付けの手順は次のパートで扱いますが、まずはこのナレッジ単体で取り込みが正常に終わっているかを、この確認画面で見届けておきましょう。

RAGチャットボットを作成して公開する

ナレッジへの取り込みが終われば、いよいよチャットボット本体を組み立てる段階に入ります。ここからは「文書を検索対象にする」作業から、「その文書を使って実際に答えるアプリを作る」作業へと軸が移ります。Dify ではアプリ作成とナレッジ接続が画面操作で完結するため、コードを書く場面はありません。流れは、アプリを作る → ナレッジをつなぐ → 振る舞いを指示する → テストして公開する、という4ステップ。

チャットアプリを作りナレッジを接続する

最初に行うのは、アプリの新規作成です。Dify には複数のアプリ種別がありますが、社内文書に答えさせる用途ならチャットボット型を選ぶのが基本になります。会話形式で質問を受け、ナレッジを参照しながら回答を返す形に最も近いからです。

アプリを作ったら、そこに先ほど登録したナレッジを紐付けます。この接続こそが RAG チャットボットの心臓部。ナレッジを紐付けて初めて、ユーザーの質問に対してアプリが社内文書を検索し、その内容を踏まえて回答するようになります。逆に言えば、ここで紐付けを忘れると、アプリは社内文書をまったく見ないまま、素の LLM として一般論だけを返してしまう。「文書を入れたのに反映されない」というつまずきの多くは、この接続漏れが原因です。

紐付けの設定では、複数のナレッジを1つのアプリにつなぐこともできます。たとえば「就業規程」と「経費精算マニュアル」を別々のナレッジとして登録し、両方を同じチャットボットに接続すれば、どちらの質問にも一台で対応可能。ただし最初は1つのナレッジに絞って動作を確かめ、感触をつかんでから増やすほうが、問題の切り分けが楽になります。

プロンプトと出典表示を設定する

ナレッジをつないだら、次はチャットボットの振る舞いを決めるプロンプトを設定します。プロンプトとは、AI に対する役割や回答方針の指示文のこと。ここに何を書くかで、同じナレッジを使っても回答の質感が大きく変わってきます。具体的な書き方のコツは、プロンプト作成の実践テクニックをまとめた記事も参考になります。

社内文書 QA で有効なのは、回答の範囲を絞る指示です。たとえば「登録された社内文書の内容に基づいて回答し、文書に記載がない場合は『該当する情報が見つかりませんでした』と答える」といった方針を書いておく。こうすると、AI が文書にない情報を推測で埋めてしまう振る舞いを抑えられます。RAG を使う最大の狙いがハルシネーション（もっともらしい嘘）の抑制である以上、プロンプトでも同じ方向に念を押しておく価値があります。

出典表示は、社内利用では特に効いてきます。AI の回答をそのまま鵜呑みにするのではなく、「この回答は経費規程の第3条が根拠か」と一次情報に当たれる導線があるかどうか。これが、現場で安心して使えるチャットボットと、使われなくなるチャットボットの分かれ目になります。

テストして公開する

設定が一通り済んだら、公開の前に必ずテストします。Dify には作成画面の中で会話を試せるプレビュー機能が用意されているのが一般的。ここで、実際に社内の人が聞きそうな質問をいくつか投げてみます。

テストで見るべきは3点。期待どおりの文書を参照できているか、出典が正しく表示されるか、文書にない質問に対して無理に答えていないか。ここで違和感があれば、後述する精度調整に進みます。問題がなければ、いよいよ公開です。

公開方式は、用途によって使い分けます。手軽さ重視なら独立した Web アプリ、既存サイトへの組み込みなら埋め込み、システム連携なら API という整理になります。

最も簡単なのは Web アプリ方式です。発行された URL を社内チャットや掲示板で共有すれば、受け取った人はリンクを開くだけで使えます。

まず小さく試すなら、この方式から始めるのが現実的でしょう。社内ポータルの一画面として常設したいなら埋め込み、Slack や Teams などと連携して業務フローに溶け込ませたいなら API、と段階的に広げていく形になります。各方式の細かい発行手順や認証まわりの設定は更新で変わりやすいため、最新の手順は Dify 公式ドキュメントで確認してください。

回答精度を高める調整と運用上の注意点

公開して終わり、とはいきません。RAG チャットボットは、作った直後が最も精度の低い状態だと考えておくのが実態に近い。実際に質問を浴びせ、ズレた回答を見つけ、設定を直す。この調整を何度か回して、ようやく現場で使える水準に近づきます。ここでは精度が出ないときの見直しどころと、運用に乗せてからの注意点を整理します。

回答がズレるときに見直す設定

回答が的外れになる原因は、大きく「検索が外している」場合と「検索は合っているのに生成が外している」場合に分かれます。まず疑うべきは前者です。

検索が外している兆候は、出典として表示された文書が質問と無関係なときに出ます。この場合に効くのが、チャンク分割の見直し。1つのチャンクに複数の話題が詰まっていると、検索の精度が落ちます。前のパートで触れたプレビューで分割の様子を確かめ、粒度が粗すぎると感じたら設定を変えて再インデックスします。

検索で引いてくる件数の調整も有効な軸です。AI が回答を作るときに参照する文書の上限件数を増やせば、関連情報を取りこぼしにくくなる一方、無関係な情報まで混ざって回答がぼやけることもある。多すぎず少なすぎずの調整が要点になります。さらに精度を詰めたい場合、検索結果を関連度で並べ替える仕組み（リランク）を挟む方法もあります。検索で広めに集めてから、本当に関連の高いものだけを上位に残す二段構えで、回答の的中率を底上げできます。

検索は合っているのに回答がズレるなら、原因はプロンプト側にあります。指示文が曖昧だったり、回答の範囲を絞る指示が抜けていたりすると、AI は参照した文書から離れて一般論を語りはじめる。「参照した文書の範囲で答える」という制約を明示し、それでも改善しなければ指示の表現を具体的に言い換えていきます。

調整は一度に複数を変えないのがコツ。チャンクとプロンプトを同時にいじると、どれが効いたのか分からなくなります。1つ変えてはテスト、を地道に繰り返すほうが、結局は近道です。

更新・権限・コストの運用ポイント

精度が落ち着いたら、運用フェーズの管理に目を向けます。見落とされがちなのが、社内文書の更新への追従です。

更新のやり方は、文書の取り込み元によって異なります。社内マニュアルや規程は時間とともに改訂されますが、ローカルファイルをアップロードして作ったナレッジでは、元ファイルを差し替えても Dify 上の登録内容が自動で置き換わるわけではありません。古いまま放置すれば、チャットボットは更新前の情報を堂々と答え続けてしまう。この場合は、文書の改訂に合わせて差し替えや再インデックスを行う運用が必要です。一方、Notion など同期に対応したデータソースでは Sync 操作が使え、外部 Knowledge Base を接続する構成では、文書の更新は外部システム側で管理します。どの構成でも、規程を改訂したあとに検索結果と回答が新しい内容を反映しているかを確認する運用は欠かせません。誰がいつ更新するのかを担当として決めておくと、形骸化を防げます。

権限管理も重要な観点です。社内文書には、全社員に見せてよいものと、一部の部署だけが扱うべきものが混在します。誰でもアクセスできる場所にチャットボットを公開すれば、本来は限られた人しか見られない情報まで、質問次第で引き出せてしまう恐れがある。公開範囲とナレッジに入れる文書の機密度は、必ずセットで考えてください。あわせて、Dify の Knowledge Base API を使う場合は、そのアクセス設定にも注意が必要です。公式ドキュメントでは、ナレッジベースの作成時に Service API へのアクセスが既定で有効になり、1つの API キーが同じアカウント内で見える複数のナレッジベースにアクセスし得ると説明されています。API を使わないナレッジではアクセスを無効化し、使う場合もキーはサーバー側で管理してください。

コスト面も運用に乗せてから効いてきます。外部のクラウド LLM を使う構成では、質問のたびに API の利用料が発生するのが一般的。社内で広く使われるほど呼び出し回数は増えます。料金体系やプランは変動が速いため、最新の情報は各 LLM 提供元と Dify 公式サイトで確認するのが確実です。利用が読めないうちは、まず小さな範囲で公開して使われ方を観察し、規模に応じて構成を見直していくのが堅実なやり方になります。

よくある質問

Q. Dify は無料で使えますか？

Dify はセルフホストで利用できますが、ライセンスは Apache License 2.0 をベースに追加条件を設けた Dify Open Source License です。単一組織内での利用と、複数テナント向けサービスとしての提供では条件が異なるため、商用提供やマルチテナント運用を予定している場合は公式 LICENSE を確認してください。また、サーバー費用やストレージ費用、利用する LLM・埋め込み・リランクモデルの料金は別途発生し得ます。クラウド版の料金と無料枠は、公式の料金ページで最新情報を確認してください。

Q. プログラミングの知識は必要ですか？

基本的な RAG チャットボットの構築なら、画面操作だけで完結するためコードを書く必要はありません。ナレッジへの文書登録、アプリ作成、ナレッジの紐付け、公開まで、すべて管理画面のメニューから行えます。API を使って自社システムと連携させる段階になると、多少の技術知識があると役立ちます。

Q. 社内の機密文書を扱っても安全ですか？

構成と運用しだいです。クラウド版に文書を登録する場合は、文書が外部サービス上で処理・保存される前提で、社内ポリシーとの整合を確認してください。セルフホスト版を使う場合でも、クラウド LLM、外部の埋め込みモデルやリランクモデル、外部データソース、外部ナレッジ API を接続すれば、問い合わせ内容や文書由来の情報が外部へ送信され得ます。機密文書を扱うなら、保存先だけでなく、検索・生成・公開・ログを含む構成全体を確認してください。

Q. Excel やスプレッドシートも登録できますか？

テキスト系のファイルや一般的な文書形式に幅広く対応していますが、対応する具体的なファイル形式は更新で追加・変更されることがあります。表形式のデータは、そのまま取り込むより検索しやすい形に整えてから登録したほうが、回答の精度が安定する場合が多いです。対応形式の最新情報は公式ドキュメントで確認してください。

Q. 日本語のドキュメントでも問題なく動きますか？

日本語の文書を登録して、日本語で質問・回答するチャットボットを構築できます。回答の品質は、つないだ LLM の日本語性能と、チャンク分割の設定に左右されます。日本語特有の長い文章は分割の粒度が効いてくるため、プレビューで分割結果を確かめながら調整するのがおすすめです。

まとめ

Dify を使えば、コードを書かずに社内ドキュメントを参照する RAG チャットボットを構築できます。流れはシンプルで、ナレッジに社内文書を登録し、チャットアプリを作ってナレッジを紐付け、テストして公開し、回答のズレを見ながら設定を調整する、という一本道。一通りの手順を踏めば、現場での利用に向けて検証を始められるチャットボットの土台が形になります。

最初から完璧を狙う必要はありません。まずは機密性のない小さなドキュメントセット、たとえば公開可能なマニュアルや検証用の資料だけを登録し、クラウド版で動作を確かめるところから始めるのが現実的です。感触をつかんだうえで、扱う文書を増やし、機密要件があればセルフホストやローカル LLM の構成へ広げていく。この順番なら、つまずいても原因を切り分けやすく、無理なく実用レベルへ近づけられます。Dify を介さずに手元で RAG を組む方法は、ローカル RAG の作り方でも紹介しています。

Difyのナレッジ機能は、外部データを取り込んでアプリケーションのコンテキストとして利用するための仕組みを提供する。（Dify 公式ドキュメントより）
出典: https://docs.dify.ai/

参考資料

• Dify 公式: ドキュメント（Getting Started）
• Dify 公式: ナレッジの Index Method（High Quality / Economical）