Difyが向く業務パターン
Difyは、LLMアプリをノーコード／ローコードで組み立てられるプラットフォームです。特に次のような業務で試作が速いです。
- 社内ドキュメントを参照した問い合わせ応答（ナレッジ＋チャット）
- 複数ステップの処理（要約→分類→下書き生成）をワークフロー化
- 外部API・Webhookと連携した申請・通知・チケット起票
- 部門ごとに異なるプロンプト／ナレッジを切り替えたい運用
ナレッジ基盤：入れ方で精度が決まる
Difyのナレッジ機能では、文書の取り込み・分割・埋め込み・検索が中心になります。公式ドキュメントやコミュニティの知見でも繰り返し強調されるのは次です。
- 取り込み前にPDFの品質（スキャン／テキスト）を確認する
- チャンクサイズとオーバーラップを業務質問に合わせて調整する
- メタデータ（文書種別・部門・版）でフィルタ可能な設計にする
- 更新頻度が高い文書は再インデックス運用を先に決める
Knowledge Pipeline のような前処理を組み合わせると、OCRや構造化を挟んだうえでナレッジへ流し込みやすくなります。ここはデモクロのデータ処理サービスと相性が良い領域です。
ワークフロー設計の基本
- 入口：ユーザー入力／フォーム／Webhook
- 分岐：意図分類（FAQ／規程照会／申請代行など）
- 検索ノード：必要なナレッジセットだけを参照
- 生成ノード：回答・下書き・チェックリストを出力
- 出口：画面表示／メール／Slack／業務システムAPI
「全部を1プロンプトでやる」より、検索と生成とアクションをノード分割した方が、失敗箇所の特定と権限設計が楽になります。
試作と本番の分岐点
Difyは検証・部門導入に強い一方、次が要件になると独自実装や周辺システム連携の比重が増えます。
- 細粒度の権限制御（文書単位・行単位）
- 既存ID基盤・監査ログとの厳密な統合
- 大量同時接続や厳しいSLA
- オンプレ／閉域での構成制約
デモクロでは、まず Dify で価値検証し、本番要件が固まった段階で「Dify継続／一部自前／全面自前」を判断する進め方を採ります。
最初の2週間でやること（例）
- 対象業務を1つに絞る（例：規程照会、ヘルプデスク一次回答）
- 文書10〜50件でナレッジを構築し、評価質問20件を用意
- ワークフローで「未回答」「要確認」を明示する分岐を入れる
- 現場ユーザーに触ってもらい、失敗例をログで収集
参考：Dify公式ドキュメント（ナレッジ／ワークフロー）、Knowledge Pipeline 関連の解説記事。製品仕様はバージョンにより変わるため、実装時は公式最新情報を確認してください。