DifyとほかのAIをつなぐ手順：モデル提供会社、外のMCPサーバー、DifyのアプリをMCPサーバーにしてClaudeやCursorから使う、difyctlでAIエージェントに使わせる、API、Webhook

この記事は、公式の資料を2026年10月25日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。

先に結論

• 連携は、画面の置き場所で見分けられます。 モデルは「Integrations」→「Model Provider」、道具（ツール）とMCPの取り込みは「Integrations」→「Tools」、アプリの公開（MCPサーバー、API、Webアプリ）はアプリの「Access Point」、コマンドは difyctl、外からの起動はワークフローの「Webhook Trigger」です。
• 「鍵に当たるもの」を見分けておきます。 MCPサーバーのURL、アプリのAPIキー、difyctl のトークンのファイル（tokens.yml）、MCPの取り込みのカスタムヘッダーの値。公式の各ページが、それぞれ注意を書いています。
• 渡るデータは、つないだ先で決まります。 Dify の外のAI（Claude など）に使わせると、そのAIが、Dify のアプリに入力を渡します。逆に Dify から外へつなぐと、Dify のアプリの入力が、モデル提供会社や外のMCPサーバーに渡ります。
• 公式の資料に書かれた範囲だけ、手順にしました。 たとえば、Claude Desktop や Cursor 側の画面は、Dify の公式ページが書く範囲だけです。各アプリ側の画面は、それぞれの公式の説明で確かめてください。
• この記事の最後に、組み合わせの案を置きます。 公式のページに書かれた機能を、この記事で組み合わせたもので、動作は確かめていません。

前提：用語をそろえる

• MCP：AIが外の道具やデータを呼ぶための、標準の取り決めです（この記事の説明）。呼ばれる側がMCPサーバー、呼ぶ側がクライアントです。
• トランスポート（HTTP）：MCPの通信の方式の1つです。公式は、Dify が取り込めるのは HTTP のものだけ、と書いています。
• OAuth / Dynamic Client Registration：外のサービスに、パスワードを渡さずに権限を与える仕組みと、その資格情報を自動で取る方式です。
• サービスAPI：アプリを外のプログラムから呼ぶための窓口です。
• ベアラートークン：Authorization: Bearer <token> の形で、リクエストに付ける鍵です。
• スキル（SKILL.md）：AIエージェントに、作業の手順を教える小さなファイルです。公式の difyctl のページは、SKILL.md を書き込むと説明しています。
• デバイスフロー：コマンド画面に出る1回きりの番号を、ブラウザで入力して、サインインを承認する方式です。difyctl のサインインがこれです。
• ワークスペース / Access Point：01、03、06を参照。

連携の一覧：どの画面で、何が渡り、どう外すか

連携1：モデル提供会社（OpenAI など）をつなぐ

05のFと同じ画面です。公式の「Model Providers」のページの手順を、連携の見方で並べます。

手順

1. 「Integrations」→「Model Provider」を開きます（ワークスペースのオーナーと管理者だけ）。
2. 入っていないプロバイダーは、「Install model providers」か Marketplace から入れます。
3. カードの「Setup」で、APIキーなどを入れます。Dify が確かめてから、使えるようにします。
4. Dify Cloud のクレジット（AI credits）の対象のモデルは、キーなしで使えます。キーを入れた場合は、「Usage Priority」で、キーとクレジットのどちらを先に使うかを決めます。
5. 既定のモデルは「Default Models」で決めます（System Reasoning、Embedding、Rerank、Speech-to-Text、Text-to-Speech）。

渡るデータ

• Dify のアプリが、LLM ノードや Agent でモデルを呼ぶと、その入力が、選んだモデルの接続先に送られます（モデルを呼ぶ仕組みそのもの）。学習への利用の扱いは、そのモデル提供会社と、Dify Cloud のプライバシーポリシーで決まります（03、04を参照。このページでは読み直していません）。

外し方と確認点

• 公式のページは、キーの管理（「Configure」「Manage Credentials」）は書いていますが、プロバイダー自体を外す手順は書いていませんでした。
• うまくいかないとき（Agent）：ツール呼び出しに対応したモデルを選ぶ。OpenAI互換のモデルでは、「Token parameter name」と、資格情報の「API Protocol」（Responses API）を確かめる（06の表）。

連携2：外のMCPサーバーを Dify に取り込む（Dify がMCPクライアントになる）

公式の「Dify Tools」のページの手順です。

手順

1. 「Integrations」→「Tools」で、MCPサーバーを足します。公式は、対象は HTTP のトランスポートのサーバーだけと書いています。標準入出力（stdio）で動くサーバーの扱いは、そのページには書かれていませんでした。
2. 次の3つを入れます。

1. 認証を決めます。
2. 「Dynamic Client Registration」は、既定でオンです。サーバーが対応していれば、そのまま使い、Dify が OAuth の資格情報を自動で取ります。
3. 対応していない、または既存のOAuthアプリを使うときは、オフにして、「Client ID」と「Client Secret」を入れ、Dify が画面に出すリダイレクトURLを、OAuthアプリに登録します。
4. 固定の鍵が要るサーバーには、「Custom Headers」を使います。公式の例は、名前 Authorization、値 Bearer <token> です。
5. 呼び出す人ごとに別の鍵を渡したいときは、値に {{request.headers.X-Custom-Auth}} のような動的な値を使えます。Dify が、起点のHTTPリクエストの、そのヘッダーの値に置き換えます。リクエストにそのヘッダーがなければ、空になります。起点のHTTPリクエストがない実行では、プレースホルダーが、置き換えられずにそのまま送られる、と書かれています。
6. 必要なときだけ、「Timeouts」を変えます（リクエストのタイムアウト、SSE の読み取りのタイムアウト）。
7. あとでサーバーの最新のツールを取り込み直すときは、ツール一覧を更新します。使っているツールが消えたり変わったりすると、アプリが壊れることがある、と公式は書いています。

アプリやエージェントに使わせる

公式のページは、ツールの置き場として、ワークフロー／チャットフローのツールノードか Agent ノード（Classic Agent）、Agent アプリのツール設定、旧型のAgentアプリのツール設定を挙げています。細かい手順は、そのページには書かれていませんでした。新しい Agent では、「Configure」の「Tools」に、MCPサーバーも入れられます（06の場面4）。

渡るデータ

• ツールを呼ぶときの入力が、そのMCPサーバーに送られます。カスタムヘッダーの値も、毎回のリクエストに付いて、そのサーバーに送られます。
• 取り込む前に、そのサーバーの提供元が誰か、何を受け取るかを確かめる必要があります（これは僕らの見立てです）。

外し方と確認点

• 識別子を変えると、そのサーバーのツールは、使っていたアプリで動かなくなり、アプリごとにツールを足し直す必要があります（公式）。別のワークスペースで、書き出したアプリを動かすには、同じ識別子でサーバーを作り直します。
• サーバーを削除する手順は、読んだページに記載が見つかりませんでした。

連携3：ワークフローとOpenAPIをツールにする

• Workflow as a Tool：「User Input」で始まるワークフローを、ツールにできます。チャットフローは、ツールにできません。公式は、ツールを作ると、先にワークフローが公開される、と書いています。
• Swagger API：OpenAPI の仕様を、貼る、URLから読む、または公式の例から始める、のどれかで渡すと、Dify がツールの形を作ります。
• どちらも、「Integrations」→「Tools」で扱います。作成のボタンの名前は、読んだページに書かれていませんでした。

連携4：DifyのアプリをMCPサーバーにして、ClaudeやCursorから使う

公式の「MCP Server」（公開）のページの手順です。これは、外のAIが、Dify のアプリを「ツール」として呼ぶ向きです。

手順（Dify側）

1. アプリを開き、「Access Point」のタブへ進みます。
2. 「MCP Server」のカードを探します。初期状態は無効（disabled by default）です。
3. オンにすると、アプリごとに固有のMCPサーバーのアドレスができます。
4. そのアドレスは、認証の資格情報を含むので、公式は「APIキーのように」扱うよう書いています。
5. ツールの説明と、入力パラメーターの説明は、具体的に書きます。AIが、呼ぶかどうか、どう呼ぶかを決める材料になるためです。公式の例は、「何かのデータ」のような曖昧な書き方でなく、「必須の項目を持つ、ユーザープロファイルのJSONオブジェクト」のような書き方でした。

手順（Claude Desktop 側、公式のページの記載）

1. Claude のプロフィールから、「Settings」→「Integrations」→「Add integration」へ進みます。
2. 「Integration URL」を、Dify のアプリのサーバーのURLに置き換えます。
3. 公式のページの記載は、この短い経路だけです。Claude 側の画面は変わるので、Claude の公式の説明で確かめてください（今回読んでいません）。

手順（Cursor 側、公式のページの記載）

プロジェクトのルートの .cursor/mcp.json を作るか、編集します。公式のページの形は次のとおりです（公式の例の写し）。

{
  "mcpServers": {
    "your-server-name": {
      "url": "your-server-url"
    }
  }
}

your-server-name は好きな名前、your-server-url は、Dify の「MCP Server」のアドレスです。Dify のアプリを増やすときは、mcpServers に、項目を足します。公式のページは、Cursor が自動で検出する、と書いています。

渡るデータ

• 外のAIが、入力をアプリに渡し、アプリが、設定どおりに動いて出力を返します。アプリの中で使うモデルやツールに、その入力が流れます（連携1、2）。
• 認証はURLそのものです。公式のページは、別の認証の方法を書いていません。URLを知る人は、アプリを呼べる、と読めます。

外し方

• URLが漏れた疑いがあるときは、「regenerate」のボタンで新しいURLにします。古いURLは、すぐ使えなくなります（公式）。
• Claude Desktop と Cursor の側の設定を消す手順は、読んだページに書かれていませんでした。
• スイッチをオフに戻す操作の説明は、読んだページに記載が見つかりませんでした。

うまくいかないときの確認点

連携5：difyctl とAIエージェント（Claude Code、Codex など）

公式の difyctl のページの手順です。エージェントが、シェルのコマンドとして difyctl を動かし、Dify のアプリを呼ぶ形です。

公式の仕組みの説明

• エージェントは、difyctl をサブプロセスとして動かし、JSONの出力を読みます。「アプリを探す → 入力を調べる → 実行 → 結果を読む」の4ステップです。
• エージェントは自分ではサインインしません。その端末の既存のセッションを使います。

手順

1. 入れる：05のGの手順で、difyctl を入れ、difyctl version で確かめます。
2. サインインする（Cloud）：公式のクイックスタートの手順です。

difyctl auth login --host https://cloud.dify.ai

• 1回きりのコードと、確認用のURLが出ます。ブラウザでURLを開き、コードを入れ、サインインします。
• 端末に承認が戻ると、アカウントとワークスペースが表示されます。
• セルフホストでは、先に OPENAPI_ENABLED と ENABLE_OAUTH_BEARER を true にし、--host に、コンソールのAPIのURLを使います。
• サーバーやコンテナ（画面のない環境）：ブラウザが使えないときのコマンドです（公式の記載）。

difyctl auth login --host https://cloud.dify.ai --no-browser
difyctl auth whoami

• 1回きりのコードとURLが出るので、別の端末のブラウザで承認します。whoami で確かめます。
• アプリの一覧：

difyctl get app

• 列は NAME、ID、MODE、UPDATED です。使いたいアプリのIDを控えます。
• アプリを動かす（公式のクイックスタートの例）：

difyctl run app 0a1b2c3d-4e5f-6789-abcd-ef0123456789 "What are your business hours?"
difyctl run app 7f3e9a2b-1c4d-4e8f-9a0b-2d5c8e1f4a7b --inputs '{"topic":"quarterly report","audience":"executives"}'

• 前者は Chatbot／Chatflow／Agent／Text Generator（位置引数のメッセージ）。返答は標準出力に出ます。会話を続けるための会話IDが、標準エラーに出ます（--conversation）。
• 後者は Workflow（--inputs にJSONオブジェクト）。出力はJSONで標準出力に出ます。
• エージェントに教える：エージェントの種類で2つに分かれます。

スキルの入れ方（公式の記載）

• 公式の例は、claude-code を検出して、~/.claude/skills/difyctl/SKILL.md に書きます。公式のページが名前を挙げているのは、Claude Code、Codex、OpenCode、Cursor、pi で、「SKILL.md をスキルのディレクトリから読む実行環境なら動くはず」という趣旨も添えています。エージェントごとの書き込み先は、別の「Skills reference」にあります（読んでいません）。
• エージェントは、その設定ディレクトリがあるときだけ検出されます。先に、各エージェントを一度起動します。
• 確かめ方：新しいセッションで、「difyctl でできることは何か」と聞くと、正しく教えられたエージェントは、difyctl help -o json --compact を動かします。スキルのバージョンは、difyctl version と比べられます。
• 更新：difyctl skills install --yes を再実行します。
• 公式は、スキルが、write や destructive のコマンドの前に、利用者に確認を取る、と書いています。

権限と渡るデータ

• エージェントの権限は、サインインしたアカウントの権限と同じです（公式）。何でもできるアカウントでサインインすると、エージェントも同じことができます。公式は、エージェントが動かすアカウントを慎重に選ぶよう書いています。
• トークンは、画面のない Linux では tokens.yml（既定の場所は ~/.config/difyctl）に保存されます。公式は、生きた資格情報なので、パーミッションは 0600 のままにし、イメージやバージョン管理に入れず、ランタイムでマウントするよう書き、読み取り専用のマウントは、アプリを動かすだけのエージェントに合う、と書いています。OSのキーチェーンに保存されているときは、書き出す方法はない、と書かれています。
• コンテナで使う例（公式）：-v /path/to/difyctl-config:/config:ro と -e DIFY_CONFIG_DIR=/config。

外し方

• サインアウト：difyctl auth logout。
• 盗まれた疑いのあるセッションの失効：auth devices revoke（公式のページは、書式の全体を書いていません）。
• 期限切れ（終了コード4、auth_expired）は、エージェントが自分で直せません。公式は、エージェントは止まって、人がサインインし直すよう書いています。
• スキルの削除：公式のページに、記載が見つかりませんでした。書き込まれるのは SKILL.md の1ファイルと書かれているので、その場所を、手で確かめられます（これは僕らの見立てです）。
• difyctl 自体の削除：macOS・Linux は rm ~/.local/bin/difyctl、Windows は Remove-Item -Recurse "$env:LOCALAPPDATA\difyctl"（05のG）。

うまくいかないときの確認点

連携6：API で、自分のプログラムやAIから呼ぶ

公式の「API Get Started」のページの内容です。

手順

1. ベースのURL：Dify Cloud は https://api.dify.ai/v1、セルフホストは、自分のインスタンスのAPIのURLです。
2. キーを作る：アプリのキーは、アプリの中で作ります（メニューの経路は、そのページに書かれていませんでした）。ナレッジのキーは、「Knowledge」の右上の「Service API」で作ります。
3. 認証：Authorization: Bearer $DIFY_API_KEY の形で送ります。
4. 動作の確認（公式の例）：

curl https://api.dify.ai/v1/info \
  -H "Authorization: Bearer $DIFY_API_KEY"

• 返るのは、アプリの名前、説明、タグ、mode、作者名などのJSONです（公式の例のレスポンス）。
• ノーコードで試すなら、「Get App Info」を開き、「Try it」を押し、「Authorization」の欄にキーを貼り、「Send」を押します。
• エンドポイントは、アプリの種類ごとに違い、mode の値は、Chatflow が advanced-chat、Workflow が workflow、Agent が agent、Chatbot と旧型の Agent が chat／agent-chat、Text Generator が completion です。

キーの種類

渡るデータ・注意

• キーを持つ呼び出しだけが、アプリを動かせます。公式は、「Call the API from your backend only」と書き、画面側（フロントエンドやクライアントのアプリ）のコードに入れたキーは、抜き出されて悪用されうる、と警告しています。
• ブロッキングとストリーミングの違い、レート制限、SDK は、そのページには書かれていませんでした。
• キーの失効の手順は、読んだページに記載が見つかりませんでした。

連携7：Webhook で、外のシステムから Dify のワークフローを起動する

公式の「Webhook Trigger」のページの内容です。手順の細部は06の場面7にあります。ここでは連携の観点だけを置きます。

• 設定する画面：ワークフローのキャンバスの「Add Node」→「Start」→「Webhook Trigger」。トリガーは、ワークフローのアプリでだけ使えます。
• 渡るデータ：外のシステムが送るリクエストの、クエリ、ヘッダー、本文のうち、設定した項目が、変数としてワークフローに入ります。
• URL：テスト用のURLと、本番のURL（Dify Cloud のドメインに作られ、外から届く）。セルフホストでは、TRIGGER_URL が公開側のベースです。
• 認証：公式のページに、認証の設定は書かれていませんでした。ヘッダーの値を変数として取り出せますが、これは取り出しであって、認証の設定ではない、と読めます。
• 制限：本文の大きさ、レートの数値は書かれていません（413のエラーの言及があるだけ）。
• 外し方：記載が見つかりませんでした。

連携8：プラグイン（Integrations）

公式の「Integrations (Plugins)」のページの内容です。

• 入手元：「Marketplace」（Dify、パートナー、コミュニティの開発者のものが、公開の前に審査とテストを受け、公開者が保守する）、「GitHub」（公開リポジトリのURLと版）、「Local Package File」（私的や社内用の .difypkg）。
• 権限：ページの下の「Who can install and manage?」（インストールと更新）と「Who can debug?」（デバッグ用のキー）を、全員、管理者のみ、誰もなし、から選びます。削除は、ワークスペースのオーナーと管理者だけです。
• 自動更新：種類ごとに、オフ、パッチのみ、常に最新、から選べます。全部、または一部の対象に当てられます。
• 公式のページに、署名や検証の説明は、書かれていませんでした。
• クリックごとの手順は、そのページには書かれていませんでした。

この記事の案：組み合わせの例

ここは、公式のページに書かれた機能を、この記事で組み合わせた案です。動作は確かめていません。画面の表記は、手元の画面と照らしてください。

案の注意：案1・2でMCPのURLを使う前に、06の公開が済んでいるか、画面で確かめてください。案3では、サインインに使うアカウントの権限が、そのままエージェントの権限になります。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。公式ページを要約の形で取得して読んだ範囲です。コマンドと設定の例は、公式ページの写しか、「この記事の案」と書いたものだけです。
• 公式のページに記載が見つからなかったこと（MCPサーバー機能の対象アプリ、スイッチをオフにする手順、スキルの削除、APIキーの失効、Webhook の認証など）は、手順にしていません。
• MCPのURL、アプリのAPIキー、tokens.yml、カスタムヘッダーの値は、公開のリポジトリやチャットに貼らないでください。
• Claude Desktop、Cursor、Claude Code、Codex などの側の画面や設定は、それぞれの公式の説明で確かめてください。
• この記事の Dify 側の画面の説明は、公式のクラウド版のドキュメント（/en/cloud/ の配下）に基づきます。セルフホスト版の画面との違いは、読んだページには書かれておらず（ツールのページ、Webhook のページも「違いは書かれていない」状態）、確認できていません。difyctl のセルフホストでの前提は、05のD-4とGを参照してください。
• 公式のページ同士で、書き方が違う所があります。たとえば、スキルが動くと書かれるエージェントの名前は、スキルのインストールのページ（Claude Code、Codex、OpenCode、Cursor、pi）と、エージェント連携の概要のページ（例として Claude Code と Codex）で、挙げ方が違います。
• 規約や契約の解釈は、必要なら専門家や公式に確認してください。この記事は法律の助言ではありません。

出典

• MCP Server（公開、Dify Docs、確認日 2026-10-25）
• Dify Tools（Dify Docs、確認日 2026-10-25）
• Model Providers（Dify Docs、確認日 2026-10-25）
• Integrations (Plugins)（Dify Docs、確認日 2026-10-25）
• API Get Started（Dify Docs、確認日 2026-10-25）
• Webhook Trigger（Dify Docs、確認日 2026-10-25）
• Install difyctl（Dify Docs、確認日 2026-10-25）
• Dify CLI Overview（Dify Docs、確認日 2026-10-25）
• difyctl Quick Start（Dify Docs、確認日 2026-10-25）
• Integrate Your Agents with Dify（Dify Docs、確認日 2026-10-25）
• Install the difyctl skill（Dify Docs、確認日 2026-10-25）
• Auth for agent deployments（Dify Docs、確認日 2026-10-25）
• Build an Agent（Dify Docs、確認日 2026-10-25）
• Environment Variables（Dify Docs、確認日 2026-10-25）
• Dify Docs 索引（クラウド、Dify Docs、確認日 2026-10-25）