Difyの使い方は業務フローから

はじめに

Difyを触ると、最初の手応えはかなり早い。画面上でプロンプトを書き、ナレッジをつなぎ、ワークフローを組む。小さなAIアプリなら、その日のうちに形になる。

ただ、企業で使うとなると話が変わる。動くものを作るだけなら速い。問題は、誰の業務のどこに入れるのか、どの情報を読ませるのか、どこで人間に戻すのかだ。ここを飛ばすと、Difyの使い方を覚えても、現場では「便利そうな試作品」で止まりやすい。

2026年7月時点のDify公式ドキュメントを見ると、アプリ、ワークフロー、エージェント、ナレッジを組み合わせられる設計になっている。公式のGitHubリポジトリでも、ワークフロー、RAG、エージェント、モデル管理、観測性に関わる機能が紹介されている。つまり、Difyは単なるチャット画面ではない。業務アプリを組むための部品箱に近い。

部品箱だからこそ、先に設計が要る。

Difyの使い方で最初に見る論点

Difyの使い方で最初に決めたいのは、どのボタンを押すかではない。対象業務を一行で言えるかだ。

たとえば「社内問い合わせをAIで返す」では、まだ広すぎる。

• 誰からの問い合わせか
• どの部署のナレッジを使うのか
• 回答だけで止めるのか
• チケット起票まで進めるのか
• 誤回答時は誰が直すのか

このあたりが決まっていないと、Dify上ではそれっぽく動く。ところが、本番に近づくほど確認が増える。ナレッジの範囲、回答の責任、ログの見方、更新担当。後から決めるほど、ワークフローを組み直すことになる。

最初は小さくていい。おすすめは、業務を次の形にすることだ。

「誰が、何を入力し、AIが何を返し、人間がどこで確認するか」

この一行が書けると、Difyの画面操作はかなり楽になる。アプリを作る前に、入力、判断、出力、承認の線が見えるからだ。

プロンプトより先に入力を分ける

Difyでは、チャットアプリ、ワークフロー、ナレッジ連携などを組み合わせられる。だから最初にプロンプトを磨きたくなる。もちろん大事だ。だが、実務ではプロンプトの前に入力を分けた方が安定する。

入力には、少なくとも3種類ある。

この3つを混ぜたままプロンプトを書くと、後で辛い。質問文に含まれる情報と、会社側が管理すべき情報が同じ場所に入ってしまうからだ。

DifyのKnowledge機能は、ナレッジをアプリに接続する入口になる。ただし、何でも入れれば精度が上がるわけではない。古い資料、未承認のメモ、担当部署が違う手順が混ざると、回答は一気に曖昧になる。

ここは生成AI PoCの成功基準は本番化の前に決めるで触れた話と同じだ。PoCの段階で「どの情報を正とするか」を決めないと、本番前に必ず詰まる。

Difyに落とすなら、対応は次のように考えると見通しがよい。

この対応表があると、顧客や社内メンバーへの説明も楽になる。「Difyで何ができるか」ではなく、「この業務条件をDifyのどこに置くか」で話せるからだ。

ワークフローは「通常系」だけで組まない

Difyの強みは、単発の応答だけでなくワークフローを組めるところにある。Workflowの公式ガイドでも、ノードをつないで処理を進める考え方が中心になっている。

ここで現場がやりがちなのは、通常系だけをきれいにつなぐことだ。

問い合わせを受ける。ナレッジを検索する。回答を生成する。Webhookや外部連携を使って通知先に返す。ここまでは気持ちよく進む。

でも、業務で止まるのは通常系ではない。

• ナレッジに根拠が見つからない
• 似た規程が複数ある
• 個人情報が入力された
• 回答に社外共有できない情報が混ざる
• ユーザーの権限では見せられない資料を参照している

この例外を後回しにすると、Dify上のワークフローは動いても、現場の承認に通らない。だから、最初のワークフローには「成功したら進む線」と同じくらい、「失敗したら止まる線」を入れる。

具体的には、次の4点を先に置く。

1. 根拠が足りない時は回答せず確認待ちにする
2. 外部送信の前に人間承認へ戻す
3. 機密語や個人情報らしき入力は別フローへ逃がす
4. ナレッジ更新日が古い場合は注意表示を出す

これはDifyに限らない。AIアプリの業務導入では、作れるかより止められるかが効く。AI社員とは?導入前に見る3つの違いでも書いた通り、読む権限と実行する権限を分けるだけで、事故の形はかなり減る。

料金を見る前に運用単位を見る

2026年7月時点のDifyのPricingページを見ると、クラウド利用、チーム利用、エンタープライズ、セルフホストなどの選択肢がある。料金表を見ること自体は必要だ。だが、先に運用単位を決めないと比較がブレる。

見るべきなのは、月額だけではない。

• 誰がアプリを作るのか
• 誰がナレッジを更新するのか
• 誰がログを確認するのか
• どの部署まで同じ環境で使うのか
• セルフホストが必要な情報を扱うのか

たとえば、営業部門だけのFAQボットなら小さく始められる。一方で、契約、採用、顧客情報を読むアプリに広げるなら、権限管理、監査ログ、データ保持、運用者の分担が前に出る。

ここを見ずに「Difyは安いか高いか」だけで判断すると、あとから運用費が膨らむ。AIツールの費用は、ライセンス費だけではない。ナレッジ整備、レビュー、例外対応、利用ルール作りまで含めて見る必要がある。

最初の1本は問い合わせ対応で試す

企業でDifyを試すなら、最初から全社業務を狙わない方がいい。おすすめは、問い合わせ対応の一部だけを切り出すことだ。

たとえば、情シスの社内問い合わせならこう分ける。SIerが顧客と合意するなら、この時点で責任分界、非機能要件、監査ログ、受け入れ基準も同じ表に置いておく。

• 入力: 社員からの質問文
• ナレッジ: 承認済みFAQと手順書
• 出力: 回答案と参照した資料
• 停止条件: 根拠なし、権限外、個人情報混入
• 人間確認: 送信前、または根拠不足時

このくらいなら、Difyの使い方を学びながら、業務フローの設計も同時に進められる。ワークフローの完成度を見るだけでなく、人間が直した回数、根拠が出なかった質問、ナレッジ更新が必要だった箇所も見える。

要件定義の打ち合わせでは、次の質問を先に置くと進めやすい。

• この回答は誰の名前で出るのか
• 参照元が見つからない時に回答してよいのか
• 回答候補をそのまま送る業務なのか、下書きで止める業務なのか
• ナレッジ更新が必要な質問を誰に戻すのか
• ログから改善する項目を毎週見るのか、月次で見るのか

この質問に答えられないなら、まだワークフローを増やすより、業務条件を決める段階だ。

評価は単純でいい。

• 回答候補が使えた割合
• 人間が直した箇所
• 根拠リンクが出た割合
• 止めるべき時に止まった回数
• ナレッジ更新に回った件数

この指標があると、次に広げるべき業務が見える。逆に、指標がないまま「便利だった」で終わると、PoCから先に進みにくい。

Difyを入れる前のチェックリスト

Difyを企業で使う前に、最低限このチェックリストを埋めたい。

• 対象業務を一行で説明できる
• 入力、ナレッジ、実行条件を分けている
• 参照してよい資料の範囲が決まっている
• 回答の根拠を表示するか決まっている
• 外部送信や更新操作の前に人間確認がある
• 失敗時にどこで止めるか決まっている
• ナレッジ更新の担当者が決まっている
• ログを見る人と頻度が決まっている

この8項目が埋まらないなら、まだアプリを増やす段階ではない。まず業務フローを細く切る。そこからDifyに載せる。順番はこれで十分だ。

AI要件定義ツールの選び方でも、ツール選定は機能数ではなく、現場の要件をどこまで構造化できるかで見るべきだと書いた。Difyも同じで、便利な機能を並べる前に、AIが読める業務の形へ落とす必要がある。

業務フローが見えれば、Difyは強い

Difyは、試作品を早く作るにはかなり便利な選択肢だ。だが、業務で使うなら「早く作れる」だけでは足りない。入力を分け、ナレッジの範囲を決め、ワークフローに停止条件を入れ、人間確認の場所を置く。ここまでできて初めて、Difyの使い方が現場の運用につながる。

AIアプリは、画面より先に業務フローで決まる。作る順番を間違えなければ、Difyは単なるノーコードツールではなく、業務AIを小さく試して育てる土台になる。

Atsumellでは、AIアプリやAIエージェントを作る前に、業務フロー、要件、ナレッジ、権限、評価条件を整理するところから支援している。Difyのようなツールを使う場合でも、最初に決めるべき線は変わらない。AIが読める仕様にしてから、実装へ進める。その順番が、PoC止まりを減らす。

関連記事

• AI要件定義は依存関係を先に決めるべき理由
• 【第6部】AIエージェントの記憶を設計する
• AIが業務フローを描く時代 — FigJam・MiroのClaude連携が変えること