Dify MCPサーバー化とは？v1.6.0双方向対応を徹底解説

クイックサマリー: Dify v1.6.0では、外部のMCPサーバーをツールとして呼び出す機能と、Dify自身のアプリ・ワークフローをMCPサーバーとして外部に公開する機能の両方がビルトインで提供されるようになりました。いわゆる双方向対応です。Claude Desktop、Cursor、Cline、Windsurfといった主要なMCP対応クライアントや、別のDifyインスタンスからも、Difyで作ったワークフローを1つの「ツール」として呼び出せます。

DifyのMCP対応とは？v1.6.0で何が変わったか

これまでDifyの主な使われ方は、Dify自体がオーケストレーターとしてLLM・外部API・ナレッジベースを束ね、Webアプリやチャットボットとして完成させるというものでした。公式ブログの表現を借りると、「AIアプリケーションはシンプルな会話の域を超えて急速に進化しつつあり、エージェントが効果的に動作するには外部のデータ・API・カレンダー・コードベースに到達する必要がある。これまではそのために大量のカスタムなグルーコードを書く必要があり、コストが高くスケールしにくかった」とされています（Dify公式ブログ「Dify v1.6.0: Built-in Two-Way MCP Support」より）。この課題に対する解として、Model Context Protocol（MCP）への対応がv1.6.0でビルトイン機能として組み込まれました。単なる機能追加ではなく、Difyの位置づけそのものを「完結したアプリを作るツール」から「他のAIエージェント基盤とも接続できるハブ」へと拡張するアップデートです。

何ができるか：外部MCP呼び出し＋Difyアプリの公開

双方向対応の中身は大きく2つです。1つ目は、外部のMCPサーバー（Notion、Zapier等の外部アプリがMCP対応している場合）をDifyのワークフローやAIエージェントからツールとして呼び出す機能です。2つ目が今回の記事の主眼で、逆にDifyのアプリ・ワークフローそのものをMCP準拠のサーバーエンドポイントとして公開し、外部のMCPクライアントから呼び出せるようにする機能です。社内で育てた業務ワークフロー資産を、Claude DesktopやCursor、あるいは別のDifyインスタンスからも再利用できる可能性が出てきた点が、単なる連携機能の追加以上のインパクトを持ちます。

導入手順：Dify標準機能（Access Point）でアプリをMCPサーバー化する

Dify v1.6.0の最大のアップデートは、プラグインを別途導入しなくてもアプリの「Access Point（公開/アクセスポイント）」設定にある「MCP Server」カードのトグルをONにするだけで、ネイティブにMCPサーバーとして公開できるようになった点です。対象のDifyアプリを開き、Access Point画面でMCP Serverを有効化すると、以下のような一意のエンドポイントURLが発行されます。

https://api.dify.ai/mcp/v1/workspaces/{workspace_id}/apps/{app_id}

Cursorと連携させる場合は、プロジェクト直下の .cursor/mcp.json に以下を定義します。

{
  "mcpServers": {
    "dify-invoice-workflow": {
      "url": "https://api.dify.ai/mcp/v1/workspaces/YOUR_WORKSPACE_ID/apps/YOUR_APP_ID",
      "headers": {
        "Authorization": "Bearer app-xxxxxxxxxxxxxxxx"
      }
    }
  }
}

この設定を保存してCursorを再起動すれば、Difyのワークフローが1つのMCPツールとしてツール一覧に現れます。なお、Difyコミュニティが提供するmcp-serverプラグイン（Extensionタイプ）も引き続き選択肢として存在します。公式ドキュメント「Turn Your Dify App into an MCP Server」によると、このプラグインは特定のクライアント（Cherry Studio等）向けの設定手順や、Access Pointとは別の公開形態を必要とする場合の補助的な選択肢として案内されています。基本的にはAccess Point機能を第一候補とし、プラグイン経由の設定はクライアント側の制約で必要になった場合の代替手段と位置づけるのが実務上わかりやすい整理です。

MCPサーバー化する際の入力変数・プロンプト設計のコツ

Difyのアプリを外部MCPクライアントから呼び出す際、CursorやClaude Desktop側のLLMは、Difyアプリに設定した入力変数（Query欄やカスタム変数）の「変数名」と「説明（Description）」だけを手がかりに、呼び出し引数を組み立てます。ここが曖昧だと、クライアント側のLLMが意図した値を渡せず、呼び出し自体が失敗したり、期待と違う値が入ったまま実行されてしまうことがあります。実務でつまずきやすいポイントとして、次の3点を押さえておくと安定します。

• Descriptionは具体的かつ簡潔に書く。「入力内容」のような曖昧な説明ではなく、「請求書の送付先企業名（例: 株式会社サンプル）」のように、何を渡すべきかが一目でわかる説明にします。英語クライアントとの併用を想定する場合は、平易な英語表記も併記すると誤解が減ります。
• 必須（Required）パラメータは最小限にとどめる。必須項目が多いほど、クライアント側のLLMが会話の文脈だけで全項目を埋めきれず呼び出しに失敗しやすくなります。省略可能な項目はデフォルト値を設定し、必須は本当に欠かせないものだけに絞ります。
• 変数名は人間にも意味が伝わる名前にする。var_1のような機械的な名前ではなく、invoice_company_nameのように内容が推測できる名前にしておくと、クライアント側のLLMが誤った値を割り当てるリスクが下がります。

これらはDifyのUI上で完結する設定変更のみで対応でき、MCPサーバー公開後に「呼び出しても期待通りに動かない」というトラブルの多くは、このDescriptionと必須パラメータ設計の見直しで解消できます。

補足: セルフホスト環境でのエンドポイント公開

本文中のエンドポイント例（https://api.dify.ai/mcp/v1/workspaces/...）は、Difyが提供するクラウドSaaS版（dify.ai）のURLです。多くのユーザーは社内サーバーやDocker（docker composeによるセルフホスト構成）でDifyを運用しているため、その場合はURLのホスト部分が自社のドメインやIPアドレスに置き換わります。たとえば社内向けにセルフホストしている場合、エンドポイントはhttps://dify.your-company.internal/mcp/v1/workspaces/{workspace_id}/apps/{app_id}のような形になります。

セルフホスト環境でCursorやClaude Desktopのようなリモート・ローカルクライアントから接続する際は、以下の点を事前に確認してください。

• 外部から到達可能なURLになっているか。社内LANのみで完結しているDifyインスタンスに社外のPCやクラウド版クライアントから接続する場合、リバースプロキシ（Nginx等）やVPN経由でのアクセス経路を用意する必要があります。ローカルネットワーク内のクライアントから接続するだけであれば、プライベートIPやホスト名の指定で足ります。
• ファイアウォール・ポート開放。DifyのAPIサービスが待ち受けるポート（既定構成では80/443、あるいはdocker-compose.yamlでカスタム指定したポート）が、接続元から到達できるように開放されているかを確認します。
• TLS証明書。社内向け独自ドメインでHTTPS化していない場合、MCPクライアント側が自己署名証明書を許可する設定になっているかを確認してください。証明書エラーで接続がサイレントに失敗するケースが報告されています。

クラウド版とセルフホスト版でMCPサーバーの機能自体（Access Pointのトグル操作や発行されるURLの形式）に違いはありませんが、「そのURLに外部のクライアントが物理的に到達できるか」はネットワーク構成に完全に依存します。導入前に、社内のネットワーク担当者やインフラ構成を確認しておくことをおすすめします。

外部MCPサーバーをツールとして呼び出す設定

逆方向の「外部MCPサーバーをツールとして使う」設定は、ワークフロー編集画面のツール一覧からMCPサーバーを追加する形で行います。Dify社は今後、外部MCPサーバーへの接続とDifyアプリのMCPサーバー公開の両方をワンクリックで行えるようにする方向で開発を続けているとアナウンスしており、現時点（2026年9月時点）では設定手順や対応プラグインの仕様が今後のマイナーバージョンで変わる可能性があります。導入前に必ず公式ドキュメントの最新版を確認してください。

実開発フローでの活用例

Enterprise導入の実務では、たとえば請求書の文面作成やPDFの予定まとめといった定型業務をDifyのワークフローとして構築し、そのワークフローをMCPサーバーとして公開しておけば、開発者はClaude DesktopやCursorのようなAIコーディングツール側から、わざわざDifyのUIを開かずに会話ベースでそのワークフローを呼び出せます。設定は前セクションと同様で、Claude Desktopの場合は設定ファイル（claude_desktop_config.json）のmcpServersキーに、Cursorと同じ形式でエンドポイントURLとAuthorizationヘッダーを追加するだけです。動画解説「MCP Introduction: Automate your business processes with Claude x Dify integration」でも、Claudeと連携させることで「タスクを会話ベースで効率化できる」点、「わざわざDifyのUI操作が不要になる」点がメリットとして挙げられています。開発チームの視点では、社内向けに構築したDifyアプリを、コーディング支援AIのツールチェーンに「1つの関数」として直接組み込めます。

類似ツール・代替との比較

MCPという共通プロトコルでツールを公開し合う動きは、OSS系だけでなくMicrosoft系でも同時並行的に進んでいます。Microsoft Copilot Studioは、既存のMCPサーバーに接続するMCPクライアント機能を2026年7月にGA（一般提供）しました。どちらを主軸に置くかは組織のクラウド戦略やコンプライアンス要件によって変わりますが、MCPを前提に設計しておくことはベンダーロックイン回避の観点でも検討に値します。

ツール名	MCP対応の形態	ライセンス	特徴
Dify	双方向（外部MCP呼び出し＋アプリのMCPサーバー公開、v1.6.0〜Access Pointでネイティブ対応）	OSS（Community）+ Enterprise版	ノーコードでワークフローを構築し、そのままMCPサーバーとして公開できる
Microsoft Copilot Studio	MCPクライアントとして外部MCPサーバーに接続（2026年7月GA）	商用（Microsoft 365/Power Platform）	既存のMCPサーバーへの接続に特化。サーバー公開機能は本記事執筆時点で未確認
Cherry Studio	MCPクライアント	OSS	DifyのAccess PointやCommunity製mcp-serverプラグインから発行されたエンドポイントを直接呼び出せることが公式ドキュメントで説明されている

注意点・制約・セキュリティ（Enterprise視点）

Enterprise導入の観点で気になるのは、社内ワークフローをMCPサーバーとして外部公開する際の権限管理です。Dify Enterpriseにはワークスペースごとのアクセスキー管理や利用ログの仕組みがありますが、MCP経由での呼び出しがそれと同じ粒度で監査できるのかは、機能がまだ発展途上であることも踏まえて、導入前に個別に確認する必要があります。またコミュニティ提供のmcp-serverプラグインを併用する場合は、Dify公式ではなくコミュニティ提供のプラグインである点も、Enterprise環境で採用する際はセキュリティレビューの対象として扱うべきです。外部に公開したエンドポイントが誰から呼び出せるか、認証をどう設計するかは、Difyのアクセス制御機能だけに頼らず個別に検討してください。

まとめ

要点は次の3つです。1つ目は、Dify v1.6.0で外部MCPサーバーの呼び出しとDifyアプリのMCPサーバー公開という双方向対応がビルトインで提供されるようになったこと。2つ目は、公開されたエンドポイントとクライアント設定を用いれば、既存のDifyアプリをコーディング不要で各AIツールから直接呼び出せること。3つ目は、Enterprise導入では権限管理・監査ログの粒度がMCP経由の呼び出しにどこまで対応しているか、個別確認が必要だということです。より詳しい設定手順はDify公式ドキュメントを参照してください。

よくある質問（FAQ）

DifyのMCPサーバー公開機能はいつから使えますか？

Dify v1.6.0で、外部MCPサーバーの呼び出し機能とDifyアプリのMCPサーバー公開機能の両方がビルトインで提供されるようになりました。バージョンやプラグインの詳細仕様は変更される可能性があるため、利用前に公式ドキュメントで最新情報を確認してください。

DifyアプリをMCPサーバーにするには何が必要ですか？

コミュニティ提供のmcp-serverプラグイン（Extensionタイプ）をインストールし、Endpointなどの設定項目を入力することで、任意のDifyアプリをMCP準拠のサーバーエンドポイントに変換できます。詳細な設定項目は公式ドキュメント「Turn Your Dify App into an MCP Server」を参照してください。

公開したDifyアプリはどんなクライアントから呼び出せますか？

Claude Desktop、Cursor、Cline、Windsurfといった主要なMCP対応クライアントのほか、Cherry Studioや別のDifyインスタンスからも呼び出せることが公式情報で説明されています。

Dify Community版とEnterprise版でMCP機能に違いはありますか？

本記事の参照情報では、Community版とEnterprise版でのMCP機能の差分は明記されていません。Enterprise版特有の権限管理・監査ログとMCP呼び出しの統合度については、導入前にDifyへ個別に確認することを推奨します。

MCPサーバーとして公開したワークフローのセキュリティは大丈夫ですか？

mcp-serverプラグインはDify公式ではなくコミュニティ提供のプラグインです。外部公開するエンドポイントへの認証・アクセス制御は、Difyの標準機能だけに頼らず、社内のセキュリティレビュープロセスに沿って個別に検討することをおすすめします。

Copilot StudioのMCP対応とDifyのMCP対応はどう違いますか？

Copilot Studioは2026年7月に、既存のMCPサーバーに接続するMCPクライアント機能をGA（一般提供）しました。一方Difyはv1.6.0で、外部MCPサーバーへの接続に加えて、自身のアプリをMCPサーバーとして公開する機能もビルトインで提供している点が特徴です。

DifyのMCP機能は今後どう発展する予定ですか？

Dify社は、外部MCPサーバーへの接続とDifyアプリのMCPサーバー公開の両方をワンクリックで行えるようにする方向で開発を続けているとアナウンスしています。現時点では発展途上の機能という位置づけで捉えておくのが妥当です。