Difyでエージェントを作ると、ユーザーの質問に答えるだけのチャットボットと違い、目的に応じて自分でツールを選び、調べて、手順を踏んで答えを返すAIを、コードを書かずに組み立てられます。結論から言えば、作り方は「アプリを作成する→役割と指示を書く→ツールを追加する→モデルと推論方式を選ぶ→テストして公開する」の5ステップです。この記事では、実際にDifyで問い合わせ一次対応エージェントを組んだ手順を、ツール設定やナレッジ連携、そして完成したエージェントを自社ツールからAPIで呼び出すコードまで示します。従来のチャットボットやコードで書くエージェントと何が違うのかも、比較表で整理します。
この記事の要点
- Difyエージェントの作り方は作成→指示→ツール追加→モデル/方式選択→テスト・公開の5ステップ。ノーコードで組めます。
- ツールは組み込みツールとカスタムAPIツールで拡張でき、ナレッジ（RAG）を紐付ければ社内文書も参照させられます。推論方式はFunction CallingとReActから選びます。
- 公開したエージェントはWeb App・埋め込み・APIで使えます。
Authorization: Bearer app-xxxのAPI呼び出しで、自社ツールや定期実行にも組み込めます。
01Difyのエージェント機能とできること
Difyは、生成AIアプリをノーコードで作れる開発プラットフォームです。その中の「エージェント」は、あらかじめ与えられた役割に沿って、自分で必要なツールを呼び出しながらタスクを進めるAIを指します。天気を調べる、社内文書を検索する、外部APIを叩くといった動作を、LLMが状況を見て自律的に選ぶのが、通常のチャットボットとの違いです。まずは、エージェントで何ができるのか、そして通常のチャットボットやワークフローとどう役割が異なるのかを整理します。
エージェントとチャットボット・ワークフローの違いは？
役割が違います。チャットボットは入力に対して1回答える対話特化で、ワークフローは「この順で処理する」と人が決めた固定の流れを実行します。エージェントはその中間で、ゴールだけを与えると、どのツールをどの順で使うかをLLMが判断します。手順が毎回変わる調べ物や、複数ツールをまたぐ処理はエージェント、決まった定型処理はワークフロー、と使い分けるのが基本です。
2種類の推論方式（Function CallingとReAct）の使い分け
Difyのエージェントは、ツールを選ぶ推論方式をFunction CallingとReActから選べます。Function Callingは、モデル自身が関数呼び出しに対応している場合に使う方式で、対応モデルなら精度と速度の面で有利です。ReActは「考える→行動する→結果を見る」を繰り返す方式で、関数呼び出しに未対応のモデルでもツールを使わせられます。使うモデルが関数呼び出しに対応していればFunction Calling、そうでなければReActを選ぶ、と考えておけば十分です。
入力に1回答える対話特化。
→ FAQ・案内
ゴールを与えるとツールを自分で選ぶ。
→ 調べ物・複数ツール連携
人が決めた固定の流れを実行。
→ 定型の連続処理
02Difyでエージェントを作る前の準備
作り始める前に、どこでDifyを動かすかと、使うLLMのAPIキーを決めておきます。この2つが揃っていれば、あとはブラウザの操作だけでエージェントが組めます。
事前に用意するもの
必要なのは、Difyの環境とモデルのAPIキーです。Difyには、すぐ使えるクラウド版と、自社サーバーに置くセルフホスト版があります。社内文書や顧客データを扱うならセルフホストが安心で、構築手順はDify セルフホスト Docker構築の手順にまとめています。まず試すだけならDify セルフホスト 無料構築ガイドも参考になります。モデルは、エージェントで使うならFunction Callingに対応したものを選ぶと構築が楽になります。Difyの設定画面でLLMプロバイダーのAPIキーを登録しておきます。
クラウド版とセルフホスト版の選び方
迷ったら、扱うデータで決めます。一般的な調べ物や社外に出しても問題ない情報だけなら、すぐ使えるクラウド版が手軽です。顧客情報や社内文書など外に出したくないデータを参照させるなら、自社サーバーで動かすセルフホスト版にします。後からの移行もできるため、まずクラウドで作って検証し、本番でセルフホストに移す進め方も現実的です。
03Difyエージェントの作り方【5ステップ】
ここからは、社内の問い合わせに一次対応するエージェント（受け取った質問を分類し、社内FAQを検索して回答案を出す想定）を例に、作成から公開まで5つのステップで組み立てます。実際の設定内容をそのまま示すので、自社の用途に置き換えて試せます。
①アプリを作成して種類を選ぶ
Difyにログインし、「最初から作成」から新しいアプリを作ります。アプリの種類で「エージェント」を選び、名前（例：問い合わせ一次対応）と説明を入力して作成します。チャット形式で自律的にツールを使わせたい場合は、この「エージェント」タイプが土台になります。より複雑な分岐や複数ステップを組みたくなったら、Chatflow/Workflowのエージェントノードに移行する選択肢もあります。
②役割と指示（プロンプト）を設定する
エージェントの性格と守るべきルールを、指示欄に書きます。ここが回答品質を左右する中心です。役割・使ってよいツール・禁止事項・出力形式を、次のように具体的に書きます。
あなたは社内の問い合わせ一次対応担当です。
- 受け取った質問を「勤怠」「経費」「システム」「その他」に分類する
- 社内FAQナレッジを検索し、根拠のある回答案だけを出す
- ナレッジに無い場合は断定せず「担当部署へ確認が必要」と返す
- 個人情報や金額の断定はしない
- 回答は結論→根拠→次のアクションの順で、です・ます調で書く「ナレッジに無ければ断定しない」と明記しておくと、根拠のない回答を防げます。エージェントは自由度が高いぶん、禁止事項を先に書くことが安全につながります。
③ツールを追加する（組み込み＋カスタムAPI）
エージェントに使わせるツールは、この画面で登録できます。Difyには検索や計算などの組み込みツールがあり、追加するだけでLLMが必要に応じて呼び出します。社内システムと連携させたい場合は、カスタムAPIツールを使います。自社APIのスキーマ（OpenAPI形式）を貼り付けると、そのエンドポイントをエージェントのツールとして扱えます。今回の例では、社内FAQを検索する自社エンドポイントをカスタムツールとして追加し、ナレッジ検索の代わりに使わせる構成が取れます。加えて、Difyのナレッジ機能に社内FAQのドキュメントを取り込み、RAGとして参照させる方法もあります。
ツールの説明文は「いつ使うか」まで書く
ツールを追加したら、その説明文に「どんなときに使うツールか」を1文で書き添えます。エージェントは、この説明を手がかりにツールを選ぶためです。「社内FAQを検索する。勤怠・経費・システムの質問で使う」のように用途まで書くと、呼び出しの精度が上がります。説明が曖昧だと、ツールがあるのに使わずに憶測で答えることがあります。
④モデルとエージェント方式を選ぶ
使うLLMと、01で触れた推論方式を選びます。Function Callingに対応したモデルなら方式もFunction Callingにし、対応していないモデルを使う場合はReActを選びます。あわせて、エージェントが1回のやり取りでツールを呼び出せる最大回数を設定します。回数を絞りすぎると途中で答えを打ち切り、多すぎると無駄な呼び出しが増えるため、まずは数回に設定して挙動を見ながら調整するのが安全です。
⑤テストして公開する
右側のプレビューで、想定質問を投げて動作を確認します。分類が正しいか、ナレッジに無い質問で断定していないか、ツールを適切に呼んでいるかを見ます。問題なければ「公開する」を押し、Web App・埋め込み・APIのいずれかで提供します。テスト時に、どのツールをどの順で呼んだかのログを確認すると、指示の直し所が見えてきます。想定通りに動かない場合は、②の指示を具体化するか、ツールの説明文を分かりやすく書き直します。
04従来のチャットボット・コード実装と何が違うのか【比較表】
同じ「問い合わせ対応AI」でも、従来のシナリオ型チャットボット、コードで書くエージェント（LangChainなどのフレームワーク）、Difyエージェントでは、作り方も運用も変わります。次の表で違いを整理します。
| 項目 | シナリオ型チャットボット | コードで書くエージェント | Difyエージェント |
|---|---|---|---|
| 作り方 | 質問と回答の分岐を人が全部登録 | フレームワークで実装・デプロイ | 画面で指示とツールを設定（ノーコード） |
| 手順の柔軟さ | 登録した分岐しか通れない | 自由だが実装コストが高い | ゴールを与えるとツール選択をLLMが判断 |
| ツール連携 | 個別に作り込みが必要 | コードで実装 | 組み込み＋カスタムAPIツールを登録 |
| 社内文書の参照 | 手動でFAQ整備 | RAGを自前構築 | ナレッジに取り込むだけで参照 |
| 変更・保守 | 分岐を手で直す | コード改修・再デプロイ | 指示とツールを画面で編集 |
| 外部からの利用 | 専用チャネル | 自前でAPI公開 | Web App・埋め込み・APIが標準で用意 |
アウトプットにはどんな差が出る？
実測した工数削減は断定できませんが、仕様の差から想定できる変化があります。シナリオ型は想定外の聞き方に弱く、分岐から外れると答えられませんでした。エージェントはLLMが意図をくんでツールを選ぶため、聞き方のゆらぎに強くなると想定されます。またコードで書く方式は変更のたびに改修と再デプロイが要りましたが、Difyは画面で指示とツールを直せるため、非エンジニアでも回答の調整に関与しやすくなると考えられます。いずれも「どの作業の手戻りが減るか」という定性の差で、削減率のような数値は自社の運用で実際に測って確認する前提です。
05サイト制作・自社ツールでのDifyエージェント活用【実践】
作ったエージェントは、Difyの画面の中だけで使うものではありません。公開時に発行されるAPIを使えば、自社のツールやサイトの裏側から呼び出せます。ここでは、制作・運用の現場でエージェントを組み込む形を示します。
問い合わせ一次対応エージェントをサイトに載せる
制作するサイトに問い合わせフォームがある場合、送信内容をDifyエージェントに渡し、分類と回答案を受け取る構成が作れます。フォーム送信をトリガーに、エージェントが「勤怠」「経費」などの分類とFAQベースの回答案を返し、担当者はそれを確認して返信する、という一次対応の下書き役です。エージェント自体はDifyで組み、サイト側はAPIを叩くだけで済みます。
自社ツールからAPIで呼び出す
公開したエージェントには、アプリごとのAPIトークン（app-で始まる文字列）が発行されます。これを使って、次のように自社ツールからHTTPで呼び出せます。会話メッセージを送るエンドポイントに、ユーザーの質問を渡す形です。
curl -X POST 'https://api.dify.ai/v1/chat-messages' \
-H 'Authorization: Bearer app-xxxxxxxx' \
-H 'Content-Type: application/json' \
-d '{
"inputs": {},
"query": "先月の交通費はどの科目で精算すればいい？",
"response_mode": "blocking",
"user": "form-user-001"
}'セルフホストの場合は、ホスト部分を自社のDifyのURLに置き換えます。返ってきたJSONの回答本文を、自社ツールの画面やSlack通知に流し込めば、エージェントを既存の業務フローに組み込めます。APIキーはコードに直書きせず、環境変数で管理します。
定期実行や社内ツールに組み込むには
毎朝の問い合わせ集計や、特定条件での自動下書きなど、定期的に走らせたい処理は、上のAPI呼び出しをスクリプトにまとめ、cronやlaunchdで実行します。外部の多様なデータソースとつなぎたくなったら、MCP（Model Context Protocol）のような標準化された連携と組み合わせる方法もあります。エージェント設計そのものを比較検討したい場合は、コード側の選択肢としてMastraでエージェントを作る手順もあわせて確認してください。
06Difyエージェントでよくある失敗と注意点
エージェントは自由度が高いぶん、つまずき方にも型があります。筆者が組んでみて見えた失敗と打ち手を、症状から引ける形で整理します。
| 症状 | 起きていること | 打ち手 |
|---|---|---|
| ツールを呼ばず憶測で答える | ツールの説明文が曖昧で、使いどころを判断できていない | 各ツールの説明に「いつ使うか」を1文で明記する |
| 根拠のない回答を断定する | ナレッジに無い場合の振る舞いを指示していない | 「ナレッジに無ければ確認が必要と返す」を指示に入れる |
| 途中で回答が止まる | ツール呼び出しの最大回数が少なすぎる | 最大回数を段階的に増やして挙動を見る |
| 意図をくまず脱線する | 役割と禁止事項が抽象的 | 役割・対象・出力形式・禁止事項を具体化する |
| 機密情報が外部モデルに渡る | クラウド版で社内データをそのまま扱っている | セルフホストにする／渡す項目を必要最小限にする |
共通するのは、「エージェントに何を任せ、何を任せないか」を指示で先に固めることです。自由に動けるからこそ、境界を明文化した設計が安定につながります。セキュリティ面をさらに詰めるなら、扱うデータの範囲と保存先を社内ルールで決めておきます。
よくある質問
Difyエージェントの作成にプログラミングは必要ですか？
基本の作成はノーコードで、画面の操作と指示文の記述だけで組めます。ただし社内システムと連携するカスタムAPIツールを追加する場合は、APIのスキーマを用意する必要があります。公開後にAPIで自社ツールへ組み込む段階でも、簡単なHTTP呼び出しのコードを書けると幅が広がります。
Function CallingとReActはどちらを選べばいいですか？
使うモデルが関数呼び出しに対応していればFunction Callingを選びます。対応していないモデルを使う場合はReActにすると、ツールを使わせられます。まずはFunction Calling対応モデルで組むと、構築がシンプルになります。
社内の文書をエージェントに参照させられますか？
できます。Difyのナレッジ機能に社内文書を取り込み、エージェントに紐付ければ、RAGとして検索・参照させられます。機密文書を扱う場合は、クラウド版ではなくセルフホストで運用し、扱うデータの範囲を社内ルールで決めてください。
作ったエージェントを自社サービスに組み込めますか？
組み込めます。公開時に発行されるAPIトークンを使い、POST /v1/chat-messagesのエンドポイントに質問を渡せば、回答を自社ツールやサイトから利用できます。セルフホストの場合はホスト部分を自社のURLに置き換えます。
Difyエージェントとコードのエージェントフレームワークはどちらがいいですか？
ノーコードで早く形にし、非エンジニアも保守に関わるならDifyが向きます。細かい制御や独自ロジックを作り込みたい場合は、コードのフレームワークが向きます。まずDifyで検証し、要件が固まってからコードへ移す進め方も現実的です。
08まとめ：小さく作って業務に一つだけ載せる
Difyエージェントを使うかは、「手順が毎回変わる調べ物や、複数ツールをまたぐ対応を任せたいか」で判断できます。決まった定型処理ならワークフローで足ります。始め方は、問い合わせ一次対応のような役割が明確な業務を一つ選び、指示とツールを最小構成で組んでテストすることです。手応えがつかめたら、公開してAPIで自社ツールに繋ぎ、定期実行や社内フローへ広げます。エージェントに任せる範囲と禁止事項を指示で固める——この設計さえ守れば、ノーコードでも実務に載る自律AIが作れます。環境づくりはDify セルフホスト Docker構築、コード側の比較はMastraでエージェントを作る手順でまとめています。
09出典
- Dify「Docs（Agent / Tools / Knowledge）」https://docs.dify.ai/
- Dify「Service API（chat-messages）」https://docs.dify.ai/guides/application-publishing/developing-with-apis
- Dify 公式サイトhttps://dify.ai/