Dify MCPとは？できること・注意点・よくあるエラーを初心者向けに解説

DifyのMCPには、「外部のMCPサーバーをDifyから利用する方法」と、「DifyアプリをMCPサーバーとして公開する方法」の2つがあります。同じMCPという名前でも、接続する方向と設定する場所が異なります。

結論から言うと、Difyのエージェントやワークフローに外部ツールを追加したい場合は、外部MCPサーバーをDifyに登録します。一方、Claude DesktopやCursorからDifyアプリを呼び出したい場合は、DifyアプリをMCPサーバーとして公開します。

Webアプリや既存の業務システムからDifyを直接呼び出すだけなら、MCPではなくAPI連携の方が適している場合もあります。そのため、最初に「どこから、何を呼び出したいのか」を整理することが重要です。

この記事では、MCPの基本、Difyにおける2つの使い方、APIや通常のツールとの違い、HTTP transport・認証・Server IDなどの注意点、よくあるエラーの確認方法を初心者向けに解説します。

※本記事は、2026年7月30日時点のDify公式ドキュメントとMCP公式情報を確認して作成しています。

Dify MCPとは何か

MCPは、AIアプリと外部のデータや機能を共通の方法で接続するための仕組みです。

Difyでは、外部のMCPサーバーが提供するツールを利用するだけでなく、Difyで作成したアプリをMCPサーバーとして公開することもできます。

この2つは接続する方向が逆になるため、最初に分けて理解しておくことが重要です。

MCPの意味

MCPは「Model Context Protocol」の略で、AIアプリケーションと外部システムの接続方法を標準化するためのオープンな仕様です。

MCPでは、AIアプリから利用できる機能として、主に次のような要素が定義されています。

MCPサーバーはこれらの機能を公開し、MCPクライアントは必要な機能を確認して呼び出します。

Difyが外部MCPサーバーと接続する場合は、現在のところ、MCPサーバーが提供する「ツール」をDifyへ取り込み、エージェントやワークフローから呼び出す使い方が中心です。

MCP全体の仕組みについては、MCP公式のアーキテクチャ解説でも確認できます。

DifyにおけるMCPの2つの使い方

DifyでMCPを利用する方法は、大きく次の2つに分けられます。

Difyから外部のMCPサーバーを利用する使い方

1つ目は、外部のMCPサーバーが提供するツールをDifyに登録し、エージェントやワークフローから利用する方法です。

現在のDifyでは、ワークスペースの「Integrations」から「Tools」を開き、ツール種別として「MCP」を選択してサーバーを登録します。

MCPサーバーへ接続すると、Difyが利用可能なツールを取得し、通常のツールと同じようにアプリ内から呼び出せるようになります。

この場合、Difyは外部MCPサーバーへ接続する側、つまりMCPクライアントに近い役割を持ちます。

なお、Difyが対応しているのはHTTP transportを利用するMCPサーバーです。詳しい登録条件は、Dify公式のMCPツール解説で確認できます。

DifyアプリそのものをMCPサーバーとして公開する使い方

2つ目は、Difyで作成したアプリをMCPサーバーとして公開し、Claude DesktopやCursorなどの外部ツールから呼び出す方法です。

Difyアプリの設定画面でMCP Server機能を有効にすると、そのアプリ専用のMCP Server URLが発行されます。

このURLをMCP対応クライアントへ登録することで、Difyで作成したプロンプト、ワークフロー、ナレッジ、ツール構成を、外部のAIツールから利用できるようになります。

この場合は、DifyアプリがMCPサーバーとなり、Claude DesktopやCursorなどが接続する側になります。

発行されるURLには認証情報が含まれるため、通常の公開URLではなく、APIキーと同じ秘密情報として管理する必要があります。設定方法は、Dify公式のMCP Server公開手順で確認できます。

API連携や通常のツール機能と何が違うのか

MCP、Difyのツール、APIは競合する機能ではなく、接続したい相手と目的によって使い分けます。

重要なのは、MCPがDifyの「ツール機能」と別の機能ではないという点です。

現在のDifyでは、Tool Plugin、Swagger API、Workflow、MCPなどが、アプリから利用できるツールの提供方法として整理されています。

利用したいサービスのTool Pluginがすでに存在する場合は、最初からMCPを使う必要はありません。既存のプラグインやSwagger APIで目的を達成できない場合や、MCP対応ツールを共通の方法で利用したい場合にMCPを検討します。

Difyのツールとプラグインの基本から確認したい場合は、Lesson6-1：ツールとプラグインの役割と違いも参考にしてください。

あわせて読みたい

【Dify】Lesson6-1：ツールとプラグインの役割の違い・使い分け【外部連携入門】

Dify MCPでできること

DifyでMCPを利用すると、外部サービスの機能をDifyアプリへ追加したり、Difyで作成したアプリをClaude DesktopやCursorなどから利用したりできます。

ただし、MCPへ接続するだけで新しい機能が自動的に増えるわけではありません。実際にできることは、接続するMCPサーバーが公開しているツールと、Difyアプリ側に組み込んだ処理によって決まります。

ここでは、Dify MCPでできることを具体的な利用場面に分けて紹介します。

外部MCPサーバーのツールをDifyで使う

外部MCPサーバーをDifyへ登録すると、そのサーバーが提供しているツールを、Difyのエージェントやワークフローから呼び出せるようになります。

たとえば、接続するMCPサーバーが対応していれば、次のような処理をDifyアプリへ追加できます。

たとえば問い合わせ対応アプリなら、ユーザーから質問を受け取り、外部MCPサーバーの検索ツールで必要な情報を取得し、その結果をもとにDifyが回答文を作成する流れを構築できます。

ワークフローでは呼び出すタイミングや処理順を固定できるため、決められた手順で確実に外部ツールを利用したい場合に向いています。

一方、エージェントでは、利用可能なツールと目的を設定しておくことで、AIにツールを使うタイミングを判断させることもできます。

ただし、書き込み、送信、削除などを行うツールは、AIへ自由に実行させるのではなく、利用範囲を限定したり、人による確認を挟んだりすることが重要です。

DifyアプリをClaude DesktopやCursorから使う

Difyで作成したアプリをMCPサーバーとして公開すると、そのアプリをClaude DesktopやCursorなどのMCP対応クライアントから呼び出せるようになります。

この方法では、Dify側で作成した次のような仕組みを、外部のAIツールから再利用できます。

たとえば、社内ルールを確認するDifyアプリを作成してMCPサーバーとして公開すれば、Claude Desktopから質問して、Dify側のナレッジ検索結果を利用した回答を受け取れます。

Cursorから利用する場合は、コードレビュー、文章のチェック、仕様確認などの処理をDifyアプリとして用意し、開発作業中に呼び出す使い方が考えられます。

Dify側で処理内容を管理できるため、接続するAIツールごとに同じプロンプトやワークフローを作り直す必要がない点もメリットです。

業務別に見るDify MCPの活用例

Dify MCPは、外部情報の取得や外部環境からの呼び出しが必要な業務で活用しやすい仕組みです。

MCPを使うかどうかは、「AIが外部の情報や機能を必要としているか」「Difyアプリを別のAIツールから呼び出したいか」を基準に判断します。

MCPでできることの限界

MCPは接続方法を共通化する仕組みであり、接続先に存在しない機能を新しく作り出すものではありません。

たとえば、接続したMCPサーバーが検索ツールしか提供していない場合、Difyからデータの更新や削除を行うことはできません。

また、MCPを利用しても、次のような問題が自動的に解決されるわけではありません。

単純なAPI呼び出しや、既存のTool Pluginだけで実現できる処理に、無理にMCPを利用する必要はありません。

MCPは、複数のMCP対応ツールを共通の方法で扱いたい場合や、DifyアプリをClaude DesktopやCursorなどから再利用したい場合に、特に効果を発揮します。

Difyで作成できるアプリのイメージを確認したい方は、Difyで作れるAIアプリの無料体験も参考にしてください。

あわせて読みたい

Difyで作れるAIアプリを無料体験｜メール返信・問い合わせ対応をブラウザで試せる

Dify MCPを使うべきケース・使わなくてよいケース

MCPは便利な仕組みですが、Difyと外部サービスを連携するときに必ず必要になるわけではありません。

既存のTool PluginやDify APIで目的を達成できる場合は、MCPを利用しない方が構成や運用をシンプルにできます。

「MCPが使えるか」ではなく、「どこから、どの機能を呼び出したいか」を基準に判断することが重要です。

初心者はどちらのMCPから触るべきか

初心者が最初に試す方法は、現在作りたいものによって異なります。

最初から2種類のMCPを両方試す必要はありません。

まず目的を1つに絞り、Difyから外部ツールを使いたいのか、外部のAIツールからDifyアプリを使いたいのかを決めましょう。

特に目的が決まっていない場合は、MCPを設定する前に、通常のDifyアプリやワークフローを完成させることをおすすめします。呼び出したい処理が明確になってからMCPへ進んだ方が、必要な設定を判断しやすくなります。

MCPが向いているケース

MCPが向いているのは、AIアプリと外部のツールを共通の方法で接続したいケースです。

具体的には、次のような場合にMCPを検討します。

たとえば、Difyアプリから複数の外部システムを利用する場合、サービスごとに独自の接続処理を作るより、MCPサーバーが提供するツールを共通の方法で取り込める方が管理しやすくなることがあります。

また、Difyで作成したナレッジ検索やレビュー用のアプリをClaude DesktopとCursorの両方から使いたい場合も、MCPサーバーとして公開するメリットがあります。

MCPを使わなくてもよいケース

次のような場合は、MCPを使わない方がシンプルに実現できる可能性があります。

MCPを導入すると、接続先の管理、認証、権限、タイムアウト、ツール更新など、運用時に確認する項目も増えます。

そのため、既存のTool PluginやHTTP Requestで十分な処理に、将来使うかもしれないという理由だけでMCPを追加する必要はありません。

また、外部サービスへの書き込み、送信、削除などを行う場合は、MCPを使うかどうかに関係なく、実行権限を最小限にし、必要に応じて人による確認を入れる必要があります。

判断に迷った場合は、次の順番で確認してください。

複数サービスを順番につなぐ業務自動化が主な目的の場合は、MCPだけでなく、Difyとn8nの違いも確認すると判断しやすくなります。

あわせて読みたい

Difyとn8nの違いは？非エンジニアが学ぶならどっちから始めるべきか

Dify MCPを使うときの注意点

DifyでMCPを利用するときは、接続できるかどうかだけでなく、接続方式、識別子、認証情報、ツールの権限、処理速度まで確認する必要があります。

特に、外部サービスへの書き込みや送信を行うツールを利用する場合は、通常の参照専用ツールより慎重な設定が必要です。

HTTP transportへの対応が前提になる

Difyへ外部MCPサーバーを登録する場合は、接続先がHTTP transportに対応している必要があります。

MCP全体では、ローカル環境で利用されるstdioや、リモート接続に利用されるStreamable HTTPなどの通信方式があります。しかし、Difyが外部MCPサーバーとして接続できるのは、HTTP transportに対応しているサーバーです。

そのため、「MCP対応」と書かれているだけでは、Difyから利用できるとは限りません。

登録する前に、少なくとも次の項目を確認してください。

Difyが対応するMCPサーバーの条件は、Dify公式のMCPツール解説で確認できます。

Server IDは運用開始後に変更しない

Difyへ外部MCPサーバーを登録するときは、そのサーバーを識別するためのServer IDを設定します。

このIDは画面上の表示名ではなく、DifyアプリがMCPサーバーのツールを参照するための識別子です。

すでにアプリで利用しているServer IDを変更すると、変更前のIDを参照しているツールが動かなくなります。その場合、影響を受けたエージェントやワークフローで、MCPツールを追加し直す必要があります。

また、Difyアプリを別のワークスペースへ移動する場合も、移動先で同じServer IDを使用してMCPサーバーを登録しなければ、ツールの参照を引き継げないことがあります。

Server IDを決めるときは、一時的なプロジェクト名ではなく、長期間使用できる名前にしてください。

たとえば、次の情報を組み合わせると管理しやすくなります。

表示を整える目的だけで、運用中のServer IDを変更しないことが重要です。

MCP Server URLはAPIキーと同じように管理する

DifyアプリをMCPサーバーとして公開すると、そのアプリ専用のMCP Server URLが発行されます。

このURLには認証情報が含まれているため、一般的なWebページのURLとは異なります。Dify公式でも、APIキーと同じ秘密情報として扱うよう案内されています。

次のような場所には記載しないでください。

MCP Server URLが漏えいした可能性がある場合は、Difyの設定画面からURLを再生成します。

新しいURLを発行すると古いURLは利用できなくなるため、Claude DesktopやCursorなど、接続先に登録しているURLも更新してください。

公開方法とURLの扱いは、Dify公式のMCP Server公開手順で確認できます。

接続先とツールの権限を確認する

外部MCPサーバーへ接続するときは、提供元と公開されているツールの内容を確認してください。

MCPサーバーが公開するツールによっては、情報の読み取りだけでなく、データの登録、更新、送信、削除などを実行できる場合があります。

接続前には、次の点を確認します。

認証情報を登録するときは、可能な限り読み取り専用や対象範囲を限定した権限を使用します。

メール送信、ファイル削除、データ更新、外部公開など、元に戻すことが難しい操作については、AIに完全に任せず、実行前に人が確認する処理を入れることをおすすめします。

最初から本番環境へ接続せず、検証用のデータやアカウントで動作を確認してから利用範囲を広げる方が安全です。

遅いワークフローは利用体験に影響する

MCPは接続方法を共通化する仕組みであり、Difyアプリや外部MCPサーバーの処理を高速化するものではありません。

DifyアプリをMCPサーバーとして公開した場合、Dify側のワークフローに30秒かかれば、Claude DesktopやCursorから呼び出したときも同じように待ち時間が発生します。

外部MCPサーバーをDifyから利用する場合は、次の処理時間が合計されます。

処理が遅い場合は、最初からタイムアウト時間だけを長くするのではなく、どの処理に時間がかかっているかを確認してください。

対策としては、次の方法があります。

タイムアウトを長くするとエラーを回避できる場合もありますが、処理自体の遅さは解消されません。まずワークフローと外部ツールの処理内容を確認することが重要です。

Dify MCPを利用する前に、次の項目を確認しましょう。

Dify MCPのよくあるエラーと対処法

DifyでMCPが動かない場合は、設定をすべてやり直す前に、接続、認証、ツール取得、アプリ側の参照、タイムアウトの順番で原因を切り分けます。

よくある症状と主な原因は次のとおりです。

接続できないとき

外部MCPサーバーをDifyへ追加できない場合は、次の順番で確認してください。

特に注意したいのが、MCPには対応していても、stdioによるローカル接続しか提供していないケースです。

Difyが外部MCPサーバーへ接続する場合はHTTP transportが必要になるため、ローカル環境でコマンドを実行するだけのMCPサーバーは、そのままでは登録できません。

認証が不要なサーバーだと思っていても、実際にはOAuthや固定トークンが必要なことがあります。接続先の公式ドキュメントで認証方法を確認してください。

また、URLが正しくても、接続先がツールを1つも公開していない場合や、Difyがツール一覧を取得できない場合は利用できません。

ツールが表示されないとき

MCPサーバーの登録には成功しているのに、利用したいツールがDifyに表示されない場合は、ツール一覧を更新します。

Difyの「Integrations」から「Tools」を開き、対象のMCPサーバーで「Update Tools」を実行してください。

それでも表示されない場合は、次の項目を確認します。

「Update Tools」を実行すると、MCPサーバーが現在公開しているツール一覧がDifyへ反映されます。

ただし、すでにアプリで利用しているツールがサーバー側で削除・変更されている場合は、ツール一覧の更新によって既存アプリが動かなくなる可能性があります。

本番で利用しているMCPサーバーについては、更新前に変更内容を確認し、必要であれば検証用アプリで先に動作を確認してください。

認証エラーが発生するとき

401や403などの認証エラーが発生する場合は、接続先の認証方式を確認します。

Difyで外部MCPサーバーへ接続するときは、主に次の認証方法があります。

Dynamic Client Registrationは初期状態で有効になっています。接続先が自動登録に対応している場合は、そのまま認証を進めます。

接続先がDynamic Client Registrationに対応していない場合や、会社で用意したOAuthアプリを利用する場合は、この設定を無効にしてClient IDとClient Secretを入力します。その際は、Difyに表示されるリダイレクトURLを接続先のOAuth設定へ登録してください。

固定トークンやAPIキーを使用するサーバーでは、Custom headersに認証情報を設定します。

例として、Bearerトークンを使用する場合は、次のようなヘッダーを設定します。

Authorization: Bearer <token>

認証情報をURLへ直接追加したり、公開される資料へ記載したりしないでください。

一度接続できたサーバーで認証エラーが発生した場合は、次の順番で確認します。

なお、DifyアプリをMCPサーバーとして公開している場合は、外部MCPサーバーのOAuth認証とは仕組みが異なります。

DifyアプリのMCP Server URLを再生成すると、古いURLはすぐに利用できなくなります。Claude DesktopやCursor側に古いURLが残っていないか確認してください。

タイムアウトになるとき

接続や認証には成功しているものの、ツールの実行が途中で止まる場合は、処理時間とタイムアウト設定を確認します。

Difyでは、外部MCPサーバーに対して次のタイムアウトを設定できます。

タイムアウトエラーが発生した場合は、最初から待機時間を大幅に長くするのではなく、次の項目を確認してください。

処理内容を見直しても時間が必要な場合に、Request timeoutやSSE read timeoutを調整します。

設定値を長くするとエラーが表示されるまでの時間も長くなるため、本番利用前に実際の処理時間を測定してください。

既存アプリが動かなくなったとき

以前は動いていたアプリが、MCPサーバーの設定変更後に動かなくなった場合は、次の変更が行われていないか確認します。

Server IDを変更した場合は、変更前のIDを参照しているツールが動かなくなります。影響を受けたエージェントやワークフローを開き、MCPツールを追加し直してください。

利用していたツールが変更・削除された場合は、新しいツールを選び直し、入力変数と後続ノードへの出力を再設定します。

MCPサーバーを削除した場合は、サーバーを再登録するだけでなく、各アプリでツールの参照が復旧しているか確認してください。

アプリを別のワークスペースへ移動した場合は、移動先でも同じServer IDを使用してMCPサーバーを登録し、認証情報を設定します。

原因が分からない場合は、Difyの実行履歴やログを確認し、どのノードまたはツールでエラーが発生しているかを特定してください。

Dify MCPのエラーは、次の順番で切り分けると原因を見つけやすくなります。

MCPサーバーの登録、認証、タイムアウト設定については、Dify公式のMCPツール解説も確認してください。

まとめ

DifyでMCPを利用する方法は、大きく次の2つに分かれます。

Difyのエージェントやワークフローに外部ツールを追加したい場合は、外部MCPサーバーをDifyへ登録します。

一方、Claude DesktopやCursorからDifyアプリを呼び出したい場合は、DifyアプリをMCPサーバーとして公開します。

独自のWeb画面や業務システムからDifyを利用したい場合はDify API、既存のTool Pluginだけで目的を達成できる場合はTool Pluginを選ぶなど、接続する相手と目的に応じた使い分けが必要です。

MCPを利用する前には、少なくとも次の項目を確認してください。

MCPは、接続するだけですべての外部連携を自動化できる機能ではありません。

まずはDifyで小さなアプリやワークフローを完成させ、「外部のどの機能が必要なのか」または「どのAIツールからDifyアプリを呼び出したいのか」を明確にしてからMCPを追加しましょう。

Difyの基本から順番に学びたい方は、Dify学習館を確認してください。

外部連携へ進む前にツールとプラグインの違いを整理したい方は、Lesson6-1：ツールとプラグインの役割と違いも参考になります。

あわせて読みたい

Dify学習館｜生成AIアプリ開発の基礎から実践まで

あわせて読みたい

【Dify】Lesson6-1：ツールとプラグインの役割の違い・使い分け【外部連携入門】

ながみえ