社内ナレッジをAIチャットボットにする最短ルート
ミドリ： タツヤさん、うちの会社、マニュアルが200ページ以上あるのに誰も読まないんですよ。同じ質問がSlackで毎日飛んできて、ベテラン社員が回答bot化してます。
タツヤ： あるあるだね。「マニュアル読め」って言っても読まないのが人間だから、逆にAIに読ませてチャットボットにしちゃうのが正解。
ミドリ： それってLangChainとかPythonでゴリゴリ書く系ですか？ 正直、社内にそこまでの開発リソースないんですけど……。
タツヤ： そこでDify.aiの出番。ノーコードでRAGチャットボットが作れるオープンソースプラットフォームだよ。
RAGチャットボットって何？
ミドリ(thinking)： そもそもRAGって何の略でしたっけ？
タツヤ： Retrieval-Augmented Generation。日本語だと「検索拡張生成」。LLM単体だと社内の情報は知らないでしょ？ だからまず社内ドキュメントを検索して、関連する部分だけをLLMに渡して回答を生成させる仕組みだよ。
ミドリ(thinking)： つまり、LLMが社内マニュアルを「カンペ」として参照しながら答えてくれる感じ？
タツヤ： まさにそう。だからハルシネーション（嘘の回答）も大幅に減る。回答の根拠となったドキュメントの箇所も一緒に返せるから、「この回答本当？」って確認もできる。
Dify.ai vs LangChain vs n8n：どれを選ぶ？
ミドリ： RAGを構築するツールって他にもありますよね。どう選べばいいんですか？
タツヤ： 代表的な3つを比較してみよう。
| 項目 | Dify.ai | LangChain | n8n + AI |
|---|---|---|---|
| 開発方式 | ノーコードGUI | Pythonコード | ローコード |
| RAG構築の手軽さ | ドラッグ&ドロップ | 自前実装 | プラグイン組み合わせ |
| セルフホスト | Docker Compose一発 | 自前構築 | Docker対応 |
| ナレッジ管理UI | 標準搭載 | なし（自作） | なし |
| ベクトルDB | 内蔵（Weaviate/Qdrant） | 自分で選定・接続 | 外部連携 |
| LLM対応 | OpenAI/Claude/Ollama等50+ | ほぼ全対応 | OpenAI中心 |
| エンタープライズ向け | SSO/RBAC標準 | 自前実装 | Enterprise版あり |
| 学習コスト | 低（1日で構築可能） | 高（Python必須） | 中 |
| GitHub Stars（2026年3月） | 72,000+ | 105,000+ | 52,000+ |
ミドリ： Difyが一番ハードル低そうですね。
タツヤ： 用途次第だけどね。ガチガチにカスタマイズしたいならLangChain、既存の業務フローにAIを組み込みたいならn8n、社内ナレッジのRAGチャットボットを最速で作りたいならDifyが最適解だよ。
Dify.aiのセットアップ ── 30分で完了
ミドリ： じゃあ実際にDifyを立ち上げてみたいんですけど、何が必要ですか？
タツヤ： 選択肢は2つ。
方法1：クラウド版（即利用可能）
タツヤ： cloud.dify.ai にアクセスしてサインアップ。無料プランで200回/月のメッセージが使える。検証にはこれで十分。
方法2：セルフホスト（推奨）
タツヤ： 社内データを扱うなら断然こっち。手順はシンプルだよ。
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -dミドリ： これだけ？
タツヤ： これだけ。localhost:80 でDifyのUIが立ち上がる。初回セットアップでは管理者アカウントを作成して、使いたいLLMのAPIキーを設定する。
ミドリ： APIキーってことはOpenAIとかのAPIは別途必要なんですか？
タツヤ： そう。ただしOllamaと連携すればローカルLLMが使えるから、APIコスト完全ゼロも可能だよ。Llama 3.1やQwen2.5をローカルで動かせば、機密データが一切外部に出ない完全クローズド環境の完成だ。
ナレッジベースの構築
ミドリ： セットアップできました。次は社内ドキュメントをAIに覚えさせるんですよね？
タツヤ： Difyでは「ナレッジ」って機能を使う。ステップは3つ。
ステップ1：ドキュメントのアップロード
タツヤ： 対応フォーマットはかなり広い。
- PDF — 社内マニュアル、規定集
- Word/Excel — 業務手順書、FAQ一覧
- Markdown/テキスト — 技術ドキュメント
- Webページ — 社内Wiki、Notionページ（URL指定でクロール）
- Notion連携 — Notionワークスペースから直接同期
ミドリ(smiling)： Notion連携は嬉しい！ うちNotionに情報まとまってるんで。
ステップ2：チャンク設定
タツヤ： ここが精度を左右する重要ポイント。ドキュメントを小さな「チャンク」に分割してベクトル化するんだけど、その分割方法を選べる。
| 分割方式 | チャンクサイズ | 適用ケース |
|---|---|---|
| 自動分割 | 500トークン | 一般的なドキュメント（デフォルト推奨） |
| 段落分割 | 可変 | 構造化されたマニュアル |
| カスタム分割 | 任意設定 | Q&A形式のFAQ |
ミドリ： デフォルトでいいんですか？
タツヤ(smiling)： 最初はデフォルトで十分。運用しながら「回答が微妙だな」と感じたらチューニングすればいい。一般的にはチャンクサイズ500〜1,000トークン、オーバーラップ50〜100トークンがベストプラクティスだね。
ステップ3：インデックス方式の選択
タツヤ： 3つの検索方式がある。
- ベクトル検索 — 意味的に近い文書を検索。「有給の取り方」で検索して「年次有給休暇の申請手順」がヒットする
- 全文検索 — キーワード一致。固有名詞や型番の検索に強い
- ハイブリッド検索 — 両方を組み合わせる。これが一番おすすめ
ミドリ： ハイブリッド一択ですね。
タツヤ： 正解。精度が段違いだよ。
プロンプトテンプレートの設計
ミドリ： ナレッジを登録しました。次はチャットボットの「性格」を設定する感じですか？
タツヤ： いいセンスしてる。Difyではアプリを作成するときに「システムプロンプト」を設定できる。ここが回答品質を左右する。
おすすめのシステムプロンプト構成
タツヤ： 社内ナレッジボットなら、こんな構成にするといい。
あなたは{{company_name}}の社内アシスタントです。
以下のルールに従って回答してください：
1. 提供されたナレッジベースの情報のみに基づいて回答する
2. ナレッジベースに該当する情報がない場合は「この質問については社内ドキュメントに情報がありません。○○部門にお問い合わせください」と回答する
3. 回答には必ず参照元のドキュメント名を記載する
4. 専門用語は平易な言葉で補足する
5. 日本語で丁寧に回答するミドリ： 「情報がない場合は正直に言え」ってのが大事ですね。ハルシネーション防止。
タツヤ： そう。RAGで一番やっちゃいけないのは「知らないのに知ったふりをする」こと。ここを明示的に指示するだけで品質が全然違う。
デプロイメントの選択肢
ミドリ(thinking)： ボットができました！ これをどうやって社内に展開するんですか？
タツヤ： Difyは5つのデプロイ方法を用意してる。
| 方法 | 特徴 | 適用シーン |
|---|---|---|
| Web埋め込み | iframeで既存サイトに埋め込み | 社内ポータル |
| API公開 | RESTful APIとして公開 | 自社アプリ連携 |
| Slack連携 | Slackボットとして動作 | 全社展開 |
| チャットウィジェット | ポップアップ型チャット | 顧客向けFAQ |
| 共有リンク | URLを共有するだけ | 即時検証 |
ミドリ： Slack連携が社内展開には最強じゃないですか？ みんなSlack使ってるし、わざわざ別のサイトに行かなくていい。
タツヤ(nodding)： その通り。Slack連携なら「@社内ボット 有給の申請方法教えて」って書くだけで回答が返ってくる。利用率が桁違いに上がるよ。
パフォーマンスチューニング
ミドリ： 運用始めたら「回答がイマイチ」って声が出てきそうなんですが、どう改善すればいいですか？
タツヤ： よくある問題と対策を整理しよう。
問題1：関係ない情報を引っ張ってくる
タツヤ： 検索のスコア閾値を上げる。Difyの設定で「類似度スコア」の最低値を0.5→0.7に変更するだけで、的外れな回答が大幅に減る。
問題2：回答が断片的で不完全
タツヤ(thinking)： トップKの値を増やす。デフォルトは3チャンクだけど、5〜6に増やせばLLMに渡す情報量が増えて、より包括的な回答になる。ただし増やしすぎるとコストとレイテンシが上がるから注意。
問題3：特定の質問に答えられない
タツヤ： ナレッジベースに情報が不足してる可能性が高い。Difyの「ログ」機能で未回答の質問を確認して、該当するドキュメントを追加する。このサイクルを月1回は回すべき。
問題4：回答が遅い
タツヤ(nodding)： まずモデルの選択を見直す。GPT-4oやClaude 3.5 Sonnetは高精度だけど遅い。FAQ的な定型質問にはGPT-4o-miniやClaude 3.5 Haikuで十分。Difyは質問のカテゴリによってモデルを切り替える「ルーティング」機能もあるから活用するといい。
ミドリ： モデルを使い分けるのは賢いですね。コスト削減にもなるし。
導入コストの現実
ミドリ： 実際いくらかかるんですか？ 上に報告するのに数字が必要で。
タツヤ： 3パターン試算しよう。
| 項目 | 完全無料構成 | 小規模構成 | 本格構成 |
|---|---|---|---|
| Dify | セルフホスト（無料） | セルフホスト（無料） | クラウド版Pro（$159/月） |
| LLM | Ollama + Llama 3.1（無料） | OpenAI API（月$50〜$150） | Claude API（月$200〜$500） |
| インフラ | 既存社内サーバー | VPS 4GB RAM（月$20） | 専用サーバー（月$100） |
| 月額合計 | $0 | $70〜$170 | $459〜$759 |
| 想定利用者数 | 〜20名 | 〜100名 | 〜1,000名 |
ミドリ： 完全無料で始められるのが衝撃です。
タツヤ： ただしOllamaのローカルLLMは精度面でAPIモデルに劣る場面がある。まず無料構成で検証して、効果を確認できたらOpenAI APIに切り替えるのが現実的なステップだよ。
実導入事例：問い合わせ対応の83%を自動化
ミドリ： 実際にDifyでRAGボットを導入した事例ってありますか？
タツヤ： 従業員150名のIT企業の事例を紹介しよう。社内の情報システム部門に月800件の問い合わせが来ていて、3名のスタッフが対応に追われてた。
ミドリ： 1人あたり月270件弱……。それは厳しい。
タツヤ： Difyで社内FAQとマニュアル150ページ分をナレッジベース化して、Slack連携で展開した結果がこれだ。
| 指標 | 導入前 | 導入3ヶ月後 | 改善率 |
|---|---|---|---|
| 月間問い合わせ件数 | 800件 | 800件（変化なし） | — |
| ボットで解決 | 0件 | 664件 | — |
| 人間が対応 | 800件 | 136件 | 83%削減 |
| 平均回答時間 | 4時間 | 即時（ボット）/ 2時間（人間） | — |
| スタッフの残業時間 | 月40時間/人 | 月8時間/人 | 80%削減 |
ミドリ： 83%が自動化って、スタッフ3人分の仕事が実質0.5人分に！
タツヤ： 空いたリソースでセキュリティ強化やインフラ改善に着手できたそうだ。「火消し」から「価値創出」にシフトした好例だね。
まとめ：RAGチャットボットは「作れる」時代
ミドリ： 今日の話をまとめると？
タツヤ： 3つのポイントだね。
- RAGチャットボットはもはや開発案件じゃない。 Dify.aiを使えばノーコードで構築できる。エンジニアじゃなくても作れる時代になった
- セルフホストなら完全無料で始められる。 社内データが外に出ないからセキュリティ面でも安心。経営層への説明もしやすい
- 精度は運用で上げるもの。 最初から完璧を目指さず、まず動かして、ログを見て、ナレッジを追加する。このサイクルが一番大事
ミドリ： 「まず動かす」のハードルがDifyで劇的に下がったのが大きいですね。
タツヤ： そう。ツールの進化で「作れるか」は問題じゃなくなった。問題は「どのナレッジを、どう整理して、どう運用するか」。これは技術じゃなくて業務理解の話だから、現場の人こそ主役になれるんだよ。
次のアクション
社内ナレッジのAI活用を始めてみましょう。
- Dify.aiのクラウド版（cloud.dify.ai）に無料サインアップして、小さなFAQで試してみる
- 社内で「同じ質問を何度も聞かれている」部門をリストアップする
- セルフホスト構築やナレッジ設計のご相談は、Shimanto AI SolutionsのRAGチャットボット構築コンサルティングへ