20260319_Difyチャットボット構築検証まとめ
背景
組織内ナレッジを活用したチャットボットの構築を目的として、Difyを用いたワークフロー設計および検証を実施した。
特に以下の観点で検証を行った。
- ナレッジベースを用いた回答精度の向上
- 質問分類による適切な応答制御
- 障害対応・仕様・業務フローなどの用途別回答の実現
- 外部連携（Slack等）における制約の把握
- 実運用に向けたUI/UXの確認
構成概要
本検証では以下の構成でチャットボットを設計した。
- ユーザー入力
- 質問分類（Classifier）
- ナレッジ検索
- SPEC_FAQ（仕様）
- TROUBLE_GUIDE（障害対応）
- APPLICATION_FLOW（業務フロー）
- LLM応答ノード（用途別）
- Variable Aggregator
- 条件分岐（IF/ELSE）
- 最終回答（Answer）
参考
◼︎成果物
◼︎ワークフロー
議論内容
1. ナレッジとSYSTEMのバランス
初期状態では以下の問題が発生した。
- SYSTEMを厳しくしすぎたため回答が出ない
- 「参照情報にない場合は回答しない」制約によりESCALATEが多発
一方でSYSTEMを削除すると、
- 回答は出るが、AIが補完し始める
- 誤情報リスクが上がる
このことから以下の理解に至った。
ナレッジの密度 × SYSTEMの厳しさ = 出力品質
2. 変数受け渡しの問題
以下の問題が発生した。
- ユーザー質問がLLMに渡っていない
- contextがプロンプトに反映されていない
原因は以下であった。
- Jinja ON/OFFの違いを誤認
- 変数を手打ちしていた
- 実際の変数参照を使っていなかった
解決方法：
- 変数ピッカーから選択する
- Jinja ON時は {{ query }} / {{ context }} を使用
- PROCESS DATAで実際に埋め込まれているか確認
3. INPUT / PROCESS DATA / OUTPUTの理解
各項目の役割は以下。
-
INPUT
ノードに渡された元データ -
PROCESS DATA
実際にLLMへ渡された内容（最重要） -
OUTPUT
次ノードへ渡す結果
今回の問題は
「INPUTにはあるがPROCESS DATAに反映されていない」
ことが原因であった。
4. ナレッジ設計の問題
以下の問題が発生した。
- 「対象システムのエラー」→「一般的なシステム遅延」へズレる
原因：
- TROUBLE_GUIDEが一般的な障害集になっていた
- ドメイン固有のナレッジが不足
解決：
- 対象システム専用の障害分類を定義
- データ取込エラー
- 処理エラー
- 整合性エラー
- ステータス更新失敗
- 未処理異常
5. 質問の曖昧さ問題
例：
「エラーの範囲」
このような抽象質問は以下のように解釈が分岐する。
- 障害カテゴリ
- 原因
- 対応方法
対策：
- ナレッジ側に「分類・定義」を明示
- SYSTEMで質問意図に応じた出力を指示
6. 分岐ロジックの検証
IF/ELSEにて以下を確認済み。
- ESCALATE判定の分岐
- NORMAL応答の返却
- LLM出力の変数受け渡し
7. DifyとAPI連携の制約
SlackのEvent SubscriptionsのようなリアルタイムWebhook連携と比較した場合、以下の制約がある。
問題点
- Difyは基本的にリクエスト/レスポンス型
- 即時レスポンス要求（3秒以内など）に弱い
- 双方向イベント駆動には不向き
Slackとの違い
Slack Event Subscriptions：
- イベント駆動
- Webhookで即時応答必須
- retryや署名検証あり
参考
slack接続時に必要としているレスポンス
{
"token": "Jhj5dZrVaK7ZwHHjRyZWjbDl",
"challenge": "3eZbrw1aBm2rZgRNFdxV2595E9CY3gmdALWMmHkvFXO7tYXAYM8P",
"type": "url_verification"
}
Dify：
- 非同期寄り
- ワークフロー実行型
- レスポンス時間が長くなる可能性あり
結論
以下のような用途は難しい。
- Slackイベントを直接Difyで処理
- 即時応答が必要なBot
代替案：
- 中間サーバを挟む
- Queueで非同期処理
- API Gatewayで制御
整理された理解
Difyの本質
Difyは以下の用途に強い。
- ナレッジベース型QA
- 業務フロー支援
- 組織内ドキュメント検索
- 意思決定支援
一方で以下は弱い。
- リアルタイムイベント処理
- 高速応答が必要なWebhook
- 双方向ストリーミング
Difyで実現できる業務効率化
1. 組織内問い合わせの自動化
- 仕様質問の自動回答
- 障害対応の一次切り分け
- 業務フローのガイド
2. ナレッジの一元化
- ドキュメント検索
- FAQ統合
- 属人化の排除
3. サポート工数削減
- L1対応の自動化
- エスカレーション判定
- 担当者振り分け
4. 教育コスト削減
- 新人教育支援
- 手順説明の自動化
- ドメイン知識の共有
5. 業務判断支援
- 条件分岐による回答制御
- ケース別ガイド提示
- 意思決定補助
今後の方針
- ナレッジのドメイン特化強化
- SYSTEMの最適化（厳しすぎない設計）
- UI統合（Web/Slack等）
- 中間APIによる外部連携強化
- エスカレーション精度の改善
今後の検討項目
本検証を踏まえ、以下の項目を次のステップとして検討する。
- エスカレーション精度を上げる設計
- Slack連携の最適アーキテクチャ
- 本番運用時のログ設計
- UI/UX改善（Webチャット）