- 1. はじめに
- 2. DifyでエージェントとMCPサーバーを使ってみよう
- 2-1. MCPサーバーの設定
- 2-2. エージェントチャットでMCPサーバーを使う
- 2-3. ワークフローでエージェントとMCPサーバーを使う
- 3. まとめ
- 4. Difyのそれは極めて個人的な考察
1. はじめに
ブログをご覧の皆さまこんにちは。エンジニアの小川です。
前回の記事ではDifyの基本操作について解説しました。
今回はDifyでエージェントとMCPサーバーを使用して外部サービスと連携する方法を紹介します。
当ブログでは、これまでMCP（Model Context Protocol）について以下の記事で紹介してきました。
MCPサーバーやエージェントの基本概念については、こちらをご参照ください。
・実体験でわかったMCPサーバー・クライアントの役割と導入メリット
2. DifyでエージェントとMCPサーバーを使ってみよう
2-1. MCPサーバーの設定
それではまずDifyから接続するMCPサーバーの設定を行っていきましょう。
今回使用するMCPサーバーは、以前も紹介したGitHubの公式MCPサーバーを使用していきます。
ヘッダーメニューにある「ツール」を選択し、ツール画面にある「MCP」タブを押下します。
MCPサーバー画面が表示されたら「MCPサーバー(HTTP)を追加」ボタンを押下します。
するとMCPサーバーの設定画面が表示されますので、情報を入力していきます。
サーバーURL: https://api.githubcopilot.com/mcp/ 名前とアイコン: GitHub MCP (※何でも可) サーバー識別子: github-mcp (※何でも可) ヘッダー: ヘッダー名: Authorization ヘッダー値: Bearer <Github Personal Access Token>
※「認証」からGithubのOAuth2を使用して認証することも可能ですが、今回は簡単なのでPersonal Access Tokenを使用します。
※ 設定している権限の詳細は割愛します。
上記のように入力したら、「保存」ボタンを押下して設定を保存します。
接続が成功したらMCPサーバー内のツール一覧が表示されます。
これでMCPサーバーの登録が完了しました！
次にエージェントを使用する為の設定を行いましょう。
ヘッダーメニューにある「プラグイン」を選択し、プラグイン画面にある「マーケットプレイスを探索する」タブを押下します。
次に「エージェント戦略」を選択し、「Dify Agent Strategies」の「インストール」ボタンを押下します。
「Dify Agent Strategies」はDifyのワークフローでのエージェント機能で使用するためのプラグインで、Difyにエージェント戦略を追加します。
個人的にこれなぜ最初から標準で入れていないのか謎なのですが、ともあれ、これでエージェントを使用する準備が整いました。
2-2. エージェントチャットでMCPサーバーを使う
それでは実際にDifyからMCPサーバーに接続し、外部サービスと連携してみましょう。
まずはすぐに試せるDifyのエージェントチャットでMCPサーバーを使用していきます。
ダッシュボードに戻り、「最初から作成」から「エージェント」を選択します。
エージェント画面が表示されました！
ではエージェントを使ってMCPサーバーに接続する設定を行っていきましょう。
画面右上にあるモデル選択ドロップダウンメニューを押下し、使用するモデルを選択します。今回は前回と同様に一定量まで無料枠で使用できる「Gemini 2.5 Flash」を使用します。
次にプロンプトに以下を入力します。
貴方はGithubリポジトリ「McpBlogSample」の管理者です。
[McpBlogSampleリポジトリ]
https://github.com/t-ogawa-dev/McpBlogSample
ユーザから与えられたリポジトリへの指示を適切に行ってください。
最後に画面下にある「ツール」右にある「+」ボタンを押下し、「MCP」タブを選択します。すると先程設定した「GitHubMCP」サーバーが表示されていますので、こちらを押下すると、MCPサーバー内のツールが表示されます。
全て登録しても構いませんが、今回はひとまずIssue関連のみ登録します。
登録するツール一覧：
・list_issues
・issue_read
・issue_write
※豆情報: ツールを個別に登録すると最大10までですが、「すべてを追加する」ボタンを押すと制限を超えてMCP内の全てのツール(GitHubだと40)を登録することもできます。
これでエージェントチャットでMCPサーバーを使用する準備が整いました。
では実際にエージェントチャットでMCPサーバーを使用してみましょう。
今回対象とするプロジェクトは、以前の記事で使用したGitHubリポジトリ「McpBlogSample」です。
次にチャット欄に以下の指示を入力してみましょう。
新しいIssue「デザインを赤基調から緑基調に変更」を作成してください。
またコメント欄には必要と思われる内容を記載してください。
さて、エージェントはどのように動作するでしょうか
エージェントの動き
作成されたIssue
Issueが作成されましたね！
以上の様に、エージェントの「ツール」にはMCPサーバーから取得したツールを登録することで、MCPサーバーを介してDifyのエージェントが外部サービスと連携できるようになりました。
またこの「ツール」はMCPに限らず、Difyの標準ツールやプラグイン、カスタム機能等で追加したDify上のツールも同じ様にエージェントで使用することが可能です。
次はワークフローでMCPサーバーを使用する方法を紹介します。
2-3. ワークフローでエージェントとMCPサーバーを使う
次にワークフローでMCPサーバーを使用する方法を紹介します。
ダッシュボードに戻り、「最初から作成」から「ワークフロー」を選択します。この辺りは前回記事で行っておりますので説明は割愛します。
前回は「LLM」ブロックを使用しましたが、今回は「エージェント」ブロックを使用します。
「エージェント」ブロックをワークフローキャンバスにドラッグ＆ドロップし、ブロックを押下して設定画面を開きます。
画面右側にある「エージェンティック戦略」ドロップダウンメニューを押下すると、「Agent」がリスト内に表示されています。この「Agent」が先に追加した「Dify Agent Strategies」プラグインによって追加されたエージェント戦略です。
ここから「Agent」→「Function Calling」と選択します。
次にモデル選択ドロップダウンメニューを押下し、使用するモデルを選択します。もちろん「Gemini 2.5 Flash」を使用していきます。
次に下部にあるツールセクションから、エージェントチャットと同様にMCPサーバーから取得したツールを登録していきます。
今回は以下を設定します。
・issue_read
次にエージェントブロックの「INSTRUCTIONS」にエージェントの役割を入力します。
あなたは GitHub リポジトリ「McpBlogSample」の管理者兼メンテナーです。
対象リポジトリ：
https://github.com/t-ogawa-dev/McpBlogSample
ユーザーから渡された Issue ID の Issue情報を取得し、
内容を要約してください。
次にQUERYに、ユーザ入力で入力させるIssue IDを指定します。
Issue ID: {{input.issue_id}} ←※ 「/」を入力すると変数選択メニューが表示されますので、そこから選択する
これでエージェントブロックの設定は完了です。早速テスト実行してみましょう！
ワークフロー全体図
ワークフロー実行結果
ワークフローが正常に完了しましたね！
以上の様に、ワークフロー内のエージェントブロックでMCPサーバー内のツールを使用することで、Difyのワークフローから外部サービスと連携できるようになりました。
もっと複雑なことをさせたければ、エージェンティック戦略で「ReAct」を使用することで、ツールの呼び出しと結果の活用を組み合わせて、より複雑なタスクを実行可能です。
[エージェンティック戦略の違い]
・Function Calling: LLMが必要なツールを選択して呼び出し、結果を一度に処理
・ReAct: 思考→行動→観察のサイクルを繰り返し、段階的に問題を解決
要は「Function Calling」はツールを呼び出して結果を得るというシンプルな処理に適しており、「ReAct」は何度も推測しながらツールを複数回呼び出してその結果を活用しながらタスクを進めることに適した用途になっています。
各エージェンティック戦略イメージ。Geminiさんに依頼したらめっちゃ分かりやすいイラスト作ってくれました。
しかしやらせたいことがはっきりと決まっている場合、「ReAct」で都度推測させて処理させるよりは、「Function Calling」ブロックを複数組み合わせて使用する方が安定して動作する様に思います。
また以前の「公式GitHub MCPサーバーを使ってみた」で紹介した様な「Issueからコード作成」をやらせてみた所、プロジェクトファイルを取得してはLLMに渡して解析させて...、といったことを行っているのでトークン使用量が膨大になります(なりました(泣))。
こういった場合はVS CodeやCursor等のコード特化型エージェントを使用した方が効率的ですので、用途に応じて使い分けると良いでしょう。
以上、DifyでエージェントとMCPサーバーを使用する方法の紹介でした。
3. まとめ
今回はDifyでエージェントとMCPサーバーを使用して外部サービスと連携する方法を紹介しました。
DifyでMCPサーバーを使用すると、サーバー内のツール一覧を目で見て直接確認することができたり、Difyのエージェントやワークフローと簡単に連携できる等、非常に便利です。
またこれらのワークフローはDifyのAPI経由で実行することも可能な為、他のシステムやアプリから呼び出して自動化することも可能です。以前は無かったスケジュール機能も実装され、かなり用途は広がってきている印象です。
一方で今回の様なプログラミング周りを自動化する用途に関してはあまり向いていないと思います。まぁそもそもDifyでコーディングを自動化する意味があるのか？という根本的な疑問もあります。
今回は前回のMCPサーバーの紹介時と比較しやすい様にということでGitHubのMCPサーバーを例として使用しましたが、プログラミングするならIDE上で実行すればいいですし、また今ならGitHub画面上でCopilotを実行してIssueの内容を元にコードを生成させることも可能になってきています。正直Difyで動かすメリットは無さそうです。うーん選定ミス。
この様にAIを使用するにあたって、これをさせるのにはどのツールを使用するのが最適か？というのは非常に重要なポイントになってきます。別にどれでも頑張ればできなくはないのですが、その「できなくはない」のお陰で無理に動かそうとしてしまい、結果的に無駄なコストや時間を浪費してしまうことも多々あります。
ですのでAIツールを使用する際は、「これをさせるのに最適なツールは何か？」を常に意識して選定していきたいですね。
4. Difyのそれは極めて個人的な考察
今回紹介したDifyですが、使っていて楽しく、また非常に可能性を感じるツールだとは思いました。
ただし一方でMCPもDifyも出たての技術ということもあり、今は進化の過程にあると感じます。
Difyのワークフローの機能としては、標準のブロックだけでは対応が難しい箇所があり、その為拡張プラグイン/ツールとの組み合わせを前提とした設計になっている印象です。とはいえコードブロックを使用してPythonコード等を使って処理させることも可能ですので、現時点では一定のプログラミング知識があると、活用の幅は広がりそうです。
Dify内のマーケットプレースではコミュニティが作成した拡張プラグイン/ツールが充実していますが、特にサードパーティ製のツール等については、メンテナンス状況やセキュリティ面を考慮した上での選定が重要です。
MCP関連機能に関しても、MCPは本来「tool」「prompt」「resource」の3つのコンポーネントで構成されるプロトコルですが、Difyで対応しているのは現状「tool」のみです。「prompt」「resource」は恐らくDifyでは使われていません。
またエージェントでMCPサーバーのツールを使用する際には、使用するツールを手動で登録する必要があります。
「どのツールを使用するか」を人間が選択することには、以下のようなメリットとデメリットがあります。
メリット：
・トークン量を減らしてコストを抑えられる
・「必要以上のことをさせない」という規制を付けられる為、意図しない操作を防げる
デメリット：
・どのツールが必要かを人間が正しく認識して選択する必要がある
・タスクに応じて都度ツールを追加・削除する手間がかかる
個人的な考えとして、コスト管理や安全性の観点から現状の手動選択方式も理解はできますが、やはり理想的には使用するMCPサーバーを登録しておくだけで、LLM側で最適なツールを自動選択してくれる事が最終目的地なのではないかと思います。ここは特に今後の進化に期待したい所です。
個々の機能に関しては上記の様に感じることはありますが、しかしDifyは単なるワークフローツールでなく「AI機能を使う為のプラットフォーム」を称していることからも、今回紹介したワークフロー/エージェント/MCPサーバー連携は1つの側面であり、他にもRAG(情報検索)機能等の紹介していない機能も搭載されています。
目的をしっかりと定めた上で、Difyが得意不得意なこと、他のツールとの組み合わせなどを考えて構築し、必要な機能を呼び出して使用していくことで、例えば自社開発のシステムにAI機能と連携させたい時等に十分に活用できるのではないかと思います。
以上、個人的な考察でした。今後もっとDifyが面白いツールに進化していくことを期待しています。
インストール完了時の表示
Geminiセットアップ画面
セットアップ完了時のGeminiサービス内モデル一覧
完成したワークフロー
最終実行結果
(※他にもあるかもしれませんが、今のところここしか見つけられていません)
良かった
「Start Building」から入った場合のMCPサーバー画面
ヘッダーからログインした場合のZapierのメインサービス画面
途中でSlackにメッセージを投稿して良いのか？という確認が入りますのでOKします。
