DifyでAIエージェントを作るには？問い合わせの回答案で考えるWorkflowとの使い分け

問い合わせへの回答案を作れても、参照資料が古い、必要な条件が抜けている、結局責任者が全部調べ直す。それでは受付担当の手間を移しただけになってしまいます。Difyを検討するときは、どの処理をAIが選び、どこを決まった条件で進めるかを分けると、自社で用意するものが見えてきます。

この記事は、2026年9月11日に確認した公式仕様と、法人サービスの問い合わせを扱う架空の設計例です。Dify上での実行結果や顧客事例ではなく、画面操作や動作の再現を保証する手順書でもありません。導入全体の順番は中小企業のAI導入 完全ガイドをご覧ください。

DifyのAgentとWorkflowは、何が違うのですか？

Workflowは、入力、検索、AIによる文章作成、条件分岐などをつなぐ流れです。その中でAgentを動かすこともできます。両者を別製品のように選ぶのではなく、流れのどの部分でAIによるツール選択が必要かを考えます。

公式資料のclassic Agentノードでは、モデル、使えるツール、指示と文脈、処理対象のQueryを設定します。モデルがツールを選び、結果を見ながら処理を進めます。繰り返し回数の上限も設定できますが、上限を決めただけで回答の正しさが保証されるわけではありません。出典：Dify Docs「Agent」

同じ公式ページには、新しいAgentのベータ版も記載されています。以下はclassic Agentを前提にした比較です。ベータ版の保存済みAgentや出力の指定方法を、従来型の設定と混ぜていません。実装時は利用環境に表示される方式と対応モデルを確認します。

指定資料から答えるだけなら、固定した検索から考えます

たとえば、問い合わせのたびに同じサービス資料を検索し、その結果で回答案を作る場合です。DifyのKnowledge Retrievalノードは、指定したナレッジを検索して結果を後続のLLMなどへ渡します。検索のために必ずAgentを挟む必要はありません。出典：Dify Docs「Knowledge Retrieval」

この構成なら、検索する資料、検索結果の確認、回答案の作成という順番を決められます。問い合わせに応じて別のツールを選ぶ必要がないなら、まずこの流れで足りるかを確かめます。

一方、途中の結果を見て、サービスのFAQを調べるか、申込手順を調べるかを変えたい場合は、Agentが候補です。ただし、その選択も固定の分類と分岐で表現できるなら、両方を比較します。Agentのほうが必ず正確で速いとは考えません。

架空例：問い合わせを受け、回答案と未確認事項を返します

架空の法人サービスに「来月から利用したい。申込後は何を準備すればよいか」という問い合わせが来た場面を考えます。入力は対象サービス、相談文、希望時期です。「来月から」は希望であり、契約済みの開始日として扱いません。

完成させるのは、受付担当が確認する回答案です。顧客への自動送信、申込の確定、CRMの更新は含めません。試作用の入力には架空の名称を使い、顧客の実名、メールアドレス、契約情報は入れません。

この表の検索処理は選択肢です。固定検索とAgentを必ず両方直列につなぐという意味ではありません。まず固定検索で試す構成と、調べ方をAgentに選ばせる構成を分けて検討します。

不足項目は、検索前に返します

対象サービスが空欄なら、もっともらしいサービスを補って検索を始めず、確認事項として返します。If-Elseノードでは、値の空欄や一致などを条件に経路を分けられます。ただし、値が入っているだけで正しい入力とは限らないため、利用できるサービス名かも別に確認します。出典：Dify Docs「If-Else」

ツール名と説明は、参照する資料の違いが分かる形にします

Agentを使う案では、「サービスFAQ検索」と「申込手順検索」という仮想のツールを考えます。これはDifyの標準搭載名ではなく、自社の参照先を整理するための例です。前者は利用条件の説明、後者は申込後に用意するものを調べる、と担当範囲を記述します。

ツールの説明とともに、入力に必要なサービス識別子、返す資料の版や該当箇所、取得できなかった場合の結果を決めます。画面上でツールを追加できても、接続先のAPIや権限が用意されているとは限りません。連携部分の確認は別に必要です。

回答案の形をそろえ、根拠がない部分を残します

受付担当へ返す項目は「回答案」「参照した資料と箇所」「未確認の条件」「人に確認してほしいこと」に分けます。これは今回の出力設計であり、Difyが標準で内容を検証してくれる項目ではありません。

架空の手順書に準備物の説明があり、開始日に関する記載がなければ、準備物の回答案と「来月開始が可能かは担当者への確認が必要です」という未確認事項を分けます。「準備物が分かったので来月開始できる」と結論を広げないようにします。

また、AgentにJSON形式で出力するよう依頼しても、形式と値が常に正しいとは限りません。後段で条件分岐へ使うなら、必要な欄が存在するか、値が許可された範囲かを検証します。人が原文と照合する前に、出力を契約条件や確定情報へ変換しないことが大切です。

試作では、回答できない入力も確認します

次の表は、試作で確認したい期待結果の例です。動作確認済みの結果ではありません。自社で検証するときは、使った入力、資料の版、実際の出力、修正した箇所を同じ記録へ残します。

とくに、資料に答えがない状態と、検索ツールが失敗して読めない状態は分けます。前者は業務担当への確認、後者は接続や権限の確認につながるためです。繰り返しの上限で終了した場合も、調査が完了した回答として扱わないようにします。

固定WorkflowとAgentを比較する際は、同じ架空資料と質問を使います。必要な情報の欠落、根拠のない記述、人が修正する時間、処理時間と利用量を記録します。文章が自然かだけでなく、受付担当が確認を終えられるかで判断します。

プレビューの記録と、運用中のLogsを分けます

公式資料では、WorkflowとChatflowのPreviewやTest Runは通常のLogsに含まれません。試作後に一覧から追えるはずと思い込まず、入力と結果を別に保存します。運用中のWorkflowのLogsでは、入力と出力、状態、トークン使用量、ノードごとの処理を確認できます。出典：Dify Docs「Logs」

利用環境やプランによる保持条件も確認します。実際の問い合わせを扱う段階では、ログに顧客情報が残る範囲と、閲覧・保管・削除を担当する人を決めます。運用まで見据えた試行の進め方は、AIエージェントを小さく試して本番へ進める手順で整理しています。

DifyのAIエージェントでよくある質問

入力と確認の方法を整理するところから始めます

来週の一歩として、架空の問い合わせをひとつ用意し、必須欄、参照資料、回答できない場合の出口を紙に書いてみてください。ここが決まれば、Difyで組む部分と、自社の業務として先に決める部分を分けやすくなります。

資料「業務設計の検討例」では、月次資料の確認と書式合わせという別業務の架空例で、入力の意味や人の照合を練習できます。全10ページ、任意25分の実践付きです。Difyの設定ファイルや問い合わせテンプレートを配布する資料ではありません。

業務設計の検討例を見る

SalesDockでは、業務・データ・システムの接続と運用定着を支援しています。自社の受付票や確認手順をもとに整理したい方は、無料相談を申し込む（60分）。