1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ローカルMCPサーバにアクセスするための、Difyプラグインを作ってみた話

Last updated at Posted at 2025-05-28

なぜプラグインを作った?

  • もともとローカルで動くMCPサーバがあり、そのサーバにDifyからアクセスしたい
  • 最初pluginを作った時は、MCPサーバにアクセスするからMCPクライアントが必要と思い込んでいたため、MCPクライアントのプラグインを作ってみたが上手く動かなかった。(一旦あきらめた)
  • MCPサーバーは、Streamable HTTPで構築していたので、MCPクライアントでなくても、HTTPクライアントでアクセスできると知った。
  • HTTPクライアントで、MCPサーバのツールを動かすpythonアプリを書くと簡単にアクセスできた。
  • HTTPクライアントから、MCPサーバにアクセスできたので、Difyのコードブロックでテストしてみたら、15秒タイムアウトでエラーになる
  • タイムアウトを回避するには、プラグインしかないと知ったため再度作成した。

準備したもの


作成中のイメージ(上記ドキュメントをAIが理解してるので、AIが必要なことを全部教えてくれます。)

  • 初期化コマンド(dify-plugin-daemon)実行するためのツールをダウンロード
  • 初期化コマンド実行したら、いろいろ聞かれるのでAIに質問
  • pluginの各種のファイルが空で作成されるので、AIに1個づつ教えてもらいながら中身を埋める
  • cloudのDifyのplugin設定などを調べて、設定ファイルを記述する
  • 中身が埋まったら、python -m main.py でpluginを起動
  • エラーがなければ、Difyのpluginに表示される

Difyプラグイン(ツール)ソースコード全体


図解

image.png


動画

実際のAI駆動開発

1. 指示:difyプラグインドキュメントの理解依頼

以下は、difyプラグイン開発のためのドキュメントです。詳細に理解してください。
https://docs.google.com/document/d/1QkoUibB_VXhqTiccjlM-nuNTk0uq1IHHDf5MaDyq7uM/edit?usp=sharing

1. AIの回答:詳細に理解した

提供されたDifyプラグイン開発ドキュメントを詳細に理解しました。以下にその内容を構造的にまとめます。

1. Difyプラグインの概要

  • 目的: Difyプラットフォームの機能を拡張するためのサードパーティ製モジュール。開発者が特定のニーズに合わせて機能をカスタマイズ・追加できるようにする。
  • メリット:
    • 柔軟な機能拡張: 多様なプラグインタイプにより、様々なシナリオに対応。
    • アジャイル開発: Difyコアへの直接的な統合より迅速な開発が可能。
    • エコシステムの活用: Difyマーケットプレイスを通じて、プラグインを共有・利用可能。
    • カスタマイズ性: アプリケーションの機能を自由に強化。
  • 主な機能:
    • 新しいAIモデルや外部ツールの統合。
    • エージェントの推論ロジックのカスタマイズ。
    • HTTPサービスを通じた迅速な機能拡張。
    • LLMのマルチモーダル対応拡張。
    • 開発者フレンドリーなデバッグ機能。
    • 永続的なデータストレージ。
    • Difyのコア機能との双方向通信(逆呼び出し)。
    • カスタムAPIエンドポイントの作成。

2. プラグインの種類

Difyは5つの主要なプラグインタイプを提供しています。

  1. モデルプラグイン:
    • 様々なAIモデル(主要LLMプロバイダー、カスタムモデルなど)をDifyに統合。
    • LLM APIの設定とリクエスト処理を担当。
    • 例: OpenAIモデルプラグイン、Anthropicモデルプラグイン。
  2. ツールプラグイン:
    • Chatflow、Workflow、Agentタイプのアプリケーションから呼び出せるサードパーティサービスやAPIを実装。
    • Difyアプリケーションの機能を外部連携で拡張。
    • 例: Google検索プラグイン。
  3. エージェント戦略プラグイン:
    • Agentノード内の推論・意思決定ロジックを定義。
    • ツールの選択、呼び出し、LLMからの結果処理などを制御。
  4. 拡張機能プラグイン (Extension):
    • シンプルなシナリオ向けのエンドポイント機能を提供する軽量プラグイン。
    • HTTPサービスを介して迅速な機能拡張を実現。
    • 例: Slack Botプラグイン。
  5. バンドルプラグイン:
    • 複数のプラグインを一つのパッケージにまとめたもの。
    • 厳選されたプラグインセットを一度にインストール可能。

3. プラグイン開発の基本フロー

  1. 開発環境のセットアップ:
    • Difyプラグインスキャフォールディングツール (dify-plugin-daemon): プラグイン開発SDK。プロジェクト初期化、パッケージングなどに使用。
    • Python環境: バージョン3.12以上推奨。
  2. プロジェクトの初期化:
    • dify plugin init コマンドでプロジェクトの雛形を作成。
    • プラグイン名、作者、説明などを入力し、プラグインタイプとテンプレートを選択。
    • 必要な権限(モデル呼び出し、ツール呼び出し、永続ストレージなど)を設定。
  3. 設定ファイル (YAML) の記述:
    • manifest.yaml: プラグインの基本情報(バージョン、作者、アイコン、権限、リソース、プラグインエントリーポイントなど)を定義。
    • プロバイダーYAMLファイル (例: /provider/my_provider.yaml): ツールプロバイダー、モデルプロバイダー、エンドポイントグループなどの設定を定義。認証情報スキーマなどを含む。
    • 個別YAMLファイル (例: /tools/my_tool.yaml, /models/llm/my_model.yaml): 各ツール、モデル、エンドポイント、エージェント戦略の詳細な設定(パラメータ、機能、ソースコードパスなど)を定義。
  4. 機能コード (Python) の実装:
    • 指定されたPythonファイルに、各プラグインタイプに応じたクラスとメソッドを実装。
    • DifyプラグインSDK (dify_plugin ライブラリ) の基底クラスを継承し、必要なメソッド(例: _invoke)をオーバーライド。
    • APIリクエスト、データ処理、Difyサービスへの逆呼び出しなどのロジックを記述。
  5. プラグインのデバッグ:
    • Difyの「プラグイン管理」ページからデバッグキーとリモートサーバーアドレスを取得。
    • プラグインプロジェクトの .env ファイルに上記情報を設定。
    • python -m main コマンドでプラグインをローカルで起動し、Difyプラットフォームからリモート接続してテスト。
  6. プラグインのパッケージ化:
    • dify plugin package ./<project_dir> コマンドで .difypkg (またはバンドルの場合は .difybndl) ファイルを作成。
  7. プラグインの公開:
    • Dify Marketplace、個人のGitHubリポジトリ、またはローカルファイルとして公開・共有。

4. スキーマ仕様 (主要な定義ファイルと構造)

  • manifest.yaml: プラグイン全体のメタデータと設定。
    • version, type, author, name, label, icon
    • resource.permission: ツール、モデル、エンドポイント、アプリ、ストレージ等の利用権限。
    • plugins: 各機能(tools, models, endpoints, agent_strategies)の定義YAMLファイルパス。
    • meta.runner: 実行環境(Pythonバージョンなど)。
  • エンドポイント定義:
    • グループYAML: settings (ProviderConfig)、endpoints (個別エンドポイントYAMLパス)。
    • 個別エンドポイントYAML: path, method, extra.python.source (実装コードファイル)。
    • 実装 (.py): dify_plugin.Endpoint 継承、_invoke メソッドでHTTPリクエスト処理。
  • ツール定義:
    • プロバイダーYAML: identity, credentials_for_provider, tools (個別ツールYAMLパス), extra.python.source
    • 個別ツールYAML: identity, description (human, llm), parameters (入力パラメータ定義), output_schema (出力変数定義), extra.python.source
    • 実装 (.py): dify_plugin.Tool 継承、_invoke メソッドでロジック実行と結果返却 (テキスト、画像、JSON、ファイルなど)。
  • モデル定義:
    • プロバイダーYAML: provider, label, icon, supported_model_types, configurate_methods, provider_credential_schema, model_credential_schema, models (個別モデルYAMLパス/ディレクトリ), extra.python.source
    • 個別モデルYAML: model ID, label, model_type, features, model_properties (コンテキストサイズ等), parameter_rules, pricing
    • 実装 (.py): モデルタイプ毎の基底クラス (例: LargeLanguageModel) 継承。_invoke, validate_credentials, get_num_tokens 等を実装。
  • エージェント戦略定義:
    • プロバイダーYAML: identity, strategies (個別戦略YAMLパス)。
    • 個別戦略YAML: identity, description, parameters (モデル、ツール、クエリ等), extra.python.source
    • 実装 (.py): dify_plugin.AgentStrategy 継承、_invoke メソッドで推論ロジック、モデル呼び出し、ツール呼び出し、ログ記録。
  • 一般的な標準仕様:
    • I18nObject: 多言語対応のラベルや説明。
    • ProviderConfig: フォーム設定の共通構造 (secret-input, text-input, select, model-selector等)。
  • 永続化されたストレージ:
    • self.session.storage を介してKVストアにアクセス (set, get, delete)。
  • Difyサービスの逆呼び出し: プラグインからDifyの機能を呼び出す。
    • self.session.app: アプリケーション (Chat, Workflow, Completion) の呼び出し。
    • self.session.model: モデル (LLM, Embedding, Rerank, TTS等) の呼び出し。
    • self.session.tool: 他のツール (ビルトイン, Workflow as Tool, APIツール) の呼び出し。
    • self.session.workflow_node: ワークフローノード (パラメータ抽出, 質問分類) の呼び出し。

5. プラグインの管理

  • 権限設定: ワークスペース所有者/管理者が、プラグインのインストール・管理・デバッグ権限をユーザーロール (全員/管理者/誰も不可) ごとに設定。
  • 更新: 「プラグイン管理」ページからアップグレード。
  • 削除: 「プラグイン管理」ページから削除。

6. プラグインの公開

  • Dify Marketplace:
    • 公式マーケットプレイス。審査を経て公開。
    • Dify Plugin GitHubリポジトリをフォークし、PRを提出。
    • チェックリスト: 機能性、ドキュメント、価値提案、コミュニティ基準、プライバシーポリシー遵守。
  • 個人GitHubリポジトリ:
    • プラグインコードを自身の公開GitHubリポジトリにプッシュ。
    • Releaseを作成し、パッケージファイル (.difypkg) を添付。
    • ユーザーはリポジトリURLからインストール可能。
  • ローカルファイル (.difypkg):
    • dify plugin package コマンドでパッケージ化。
    • ファイルを直接共有し、Difyの「ローカルからインストール」機能で導入。
  • PRを通じた自動公開:
    • GitHub Actionsを利用し、プラグインソースリポジトリへのpushをトリガーに、パッケージング、フォークリポジトリへのpush、Dify PluginリポジトリへのPR作成を自動化。
  • 第三者署名検証 (コミュニティ版のみ):
    • Dify Marketplace外のプラグインを安全にインストールするための仕組み。
    • 鍵ペア生成、プラグインへの署名、Dify環境での公開鍵設定が必要。

7. ベストプラクティス例

  • Slack Botプラグイン開発: Extensionプラグインとして、SlackからのWebhookを受け取り、Difyアプリと連携して応答するBotを作成。
  • Dify MCPプラグイン (Zapier連携): MCP (Model Context Protocol) を利用して、Zapier経由で多数の外部アプリケーション (Gmailなど) と連携するエージェントを構築。

8. よくある質問 (FAQ)

  • インストール時のエラーとその対処法 (例: authorフィールドの不一致、署名検証エラー)。

総括

Difyプラグイン開発は、Difyプラットフォームの能力を大幅に拡張し、特定のユースケースに合わせたAIアプリケーションの構築を可能にする強力な手段です。スキャフォールディングツール、明確なスキーマ定義、豊富なSDK機能、多様な公開オプションにより、開発者はアイデアを形にし、コミュニティと共有することができます。特に、モデル、ツール、エージェント戦略といった異なる種類のプラグインを理解し、適切に組み合わせることで、高度なAIソリューションを実現できます。

2. 指示:pythonアプリをdifyプラグインに改造できるか確認 Pythonアプリがあります。それをdifyプラグインに改造したいです。 今提示した資料で、それはできますか?
2. AI回答:できると返答

はい、提示された資料に基づいて、既存のPythonアプリケーションをDifyプラグインに改造することは十分に可能です。

資料には、Difyプラグインを開発するために必要な情報が網羅的に記載されています。具体的には以下の点が役立ちます。

  1. プラグインの種類と選択:

    • 既存のPythonアプリの機能に応じて、最適なプラグインタイプ(ツール、拡張機能、モデル、エージェント戦略)を選択するための情報があります。
    • 例えば、外部APIと連携するアプリなら「ツールプラグイン」、特定のHTTPエンドポイントを提供するなら「拡張機能プラグイン」などが考えられます。
  2. 開発環境のセットアップ:

    • Difyプラグインスキャフォールディングツール (dify-plugin-daemon) のインストール方法やPython環境の準備について説明されています。
  3. プロジェクトの初期化と構造:

    • dify plugin init コマンドを使ってプラグインプロジェクトの雛形を作成する方法が示されています。これにより、必要なディレクトリ構造や基本的な設定ファイルが生成されます。
  4. 設定ファイル (YAML) の記述:

    • manifest.yaml(プラグイン全体の定義)、プロバイダーYAML、各機能(ツール、モデル等)のYAMLファイルの書き方について、詳細なスキーマ仕様と例が提供されています。既存アプリの設定情報(APIキーなど)をこれらのYAMLファイルに移行することができます。
  5. Pythonコードの実装:

    • 各プラグインタイプに応じたPythonの基底クラスと、実装すべきメソッド(例: _invoke)が定義されています。既存のPythonアプリのコアロジックをこれらのメソッド内に組み込む形で改造を進めることができます。
    • DifyプラグインSDK (dify_plugin ライブラリ) を利用して、Difyプラットフォームとの連携(入力の受け取り、出力の整形、Difyサービスの逆呼び出しなど)を実装します。
    • 外部ライブラリを使用している場合、requirements.txt に記述することで依存関係を管理できます。
  6. デバッグとパッケージング:

    • ローカルでのデバッグ方法や、最終的に .difypkg ファイルとしてパッケージングする方法が説明されています。
  7. 具体的なクイックスタートガイドとベストプラクティス:

    • 各プラグインタイプ(ツール、モデル、エージェント戦略、拡張機能)の具体的な開発手順を示すクイックスタートガイドがあります。これらは、既存アプリをどのようにプラグインの形に落とし込むかの良い参考になります。
    • Slack Botプラグインのような具体的な応用例も示されており、複雑なアプリケーションをプラグイン化する際のヒントになります。

改造の進め方のイメージ:

  1. 既存Pythonアプリの機能分析: アプリが何を提供し、どのように動作するのかを明確にします。
  2. 適切なDifyプラグインタイプの選択: 分析結果に基づいて、最も適したプラグインタイプを選びます。
  3. Difyプラグインプロジェクトの初期化: スキャフォールディングツールでプロジェクトを作成します。
  4. 設定の移行: 既存アプリの設定(APIキー、エンドポイントURLなど)をプラグインのYAMLファイルに記述します。
  5. コアロジックの移植: 既存Pythonアプリの主要な処理ロジックを、選択したプラグインタイプのPythonクラスとメソッド内に移植・適合させます。Dify SDKのインターフェースに合わせて入出力を調整します。
  6. テストとデバッグ: Difyのリモートデバッグ機能などを使って動作確認を行います。
  7. パッケージングと公開: プラグインをパッケージ化し、必要に応じて公開します。

資料は詳細かつ実践的な内容を含んでいるため、これらを丁寧に読み解くことで、既存のPythonアプリケーションをDifyプラグインとして機能するように改造するための道筋が見えてくるはずです。

3. 指示:pythonアプリを理解してプラグインに改造するための質問をしてください

以下のアプリをdifyプラグインに改造したいです。

事前に意識合わせをしたいので、一旦アプリを理解して、質問があれば質問してください。

import requests
import json
import os
import time # time モジュールをインポート

MCPサーバーのURL (ローカルテスト用に直接指定、Dify上では環境変数や入力変数から取得)

Difyのコードブロック内で実行する場合は、この行はコメントアウトし、

os.environ.get または inputs から取得するロジックを生かします。

今回はローカル実行のテストを想定しているため、ここで直接定義します。

mcp_server_url = "https://mcp-server.veryglad.win/mcp" # または http://localhost:3001/mcp (トンネルなしの場合)

--- Dify コードブロックの入力変数を模倣 ---

Dify のコードブロックでは、'inputs' は事前に定義された辞書として渡される

ローカルでテスト実行するために、ここで辞書として初期化する

inputs: dict[str, str] = {} # ★★★ 空の辞書として初期化 ★★★

inputs['setdir'] = 'google--search_query'

inputs['search_query'] = 'google'

inputs['mcp_server_url_from_input'] = "https://mcp-server.veryglad.win/mcp" # もし入力変数でURLを渡す場合

---

def main(arg1,arg2,arg3) -> dict: # Dify のコードブロックは通常、辞書を return する
# global mcp_server_url # グローバル変数を参照することを明示 (ローカルテスト用)
# Difyの環境変数からURLを取得する場合 (Difyプラットフォーム上での実行時)
# このローカルテストでは上の mcp_server_url を使う
# if 'DIFY_ENVIRONMENT' in os.environ: # Dify環境かどうかを判定する何らかの方法 (これは一例)
# env_mcp_server_url = os.environ.get('MY_MCP_SERVER_URL')
# if env_mcp_server_url:
# mcp_server_url = env_mcp_server_url
# elif inputs.get('mcp_server_url_from_input'): # 入力変数からも試す
# mcp_server_url = inputs.get('mcp_server_url_from_input')

inputs['setdir'] = arg1
inputs['search_query'] = arg2
inputs['mcp_server_url'] = arg3
mcp_server_url: Optional[str] = inputs.get("mcp_server_url")


print(f"Using MCP Server URL: {mcp_server_url}")
if not mcp_server_url:
    print("Error: MCP_SERVER_URL is not defined.")
    return {"error": "MCP_SERVER_URL is not defined."}

# Difyの入力変数からツール呼び出しの引数を取得
setdir: Optional[str] = inputs.get("setdir")
search_query: Optional[str] = inputs.get("search_query")

print(f"Received setdir: {setdir}, search_query: {search_query}")

if not setdir: # isinstance チェックも加えるとより堅牢
    print("Error: 'setdir' input is missing or invalid.")
    return {"error": "'setdir' input is missing or invalid."}

mcp_tool_name = "run_scraper"
mcp_tool_args = {
    "setdir": setdir
}
if search_query: # isinstance チェックも加えるとより堅牢
    mcp_tool_args["search_query"] = search_query

request_id = "dify-python-script-call-" + str(time.time())
jsonrpc_request_body = {
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
        "name": mcp_tool_name,
        "arguments": mcp_tool_args
    },
    "id": request_id
}
headers = {
    "Content-Type": "application/json",
    "Accept": "application/json, text/event-stream"
}

print(f"Sending POST request to {mcp_server_url}")
print(f"Request Body: {json.dumps(jsonrpc_request_body)}") # デバッグ用にボディ全体を表示

try:
    response = requests.post(
        mcp_server_url,
        json=jsonrpc_request_body,
        headers=headers,
        timeout=15.0
    )
    response.raise_for_status()
    response.encoding = 'utf-8'

    print(f"Response status: {response.status_code}")
    print(f"Response headers: {response.headers}")
    
    response_text = response.text
    print(f"Raw response text (first 500 chars): {response_text[:500]}...")
    
    sse_data_payload = ""
    # MCPサーバーはContent-Type: text/event-streamで応答し、
    # 実際のデータは "data: <JSON文字列>" の形式で送られてくる。
    # tools/call の場合、通常は1つの data イベントで完結する。
    for line in response_text.splitlines():
        if line.startswith("data:"):
            sse_data_payload = line[len("data:"):].strip()
            print(f"Extracted SSE data payload: {sse_data_payload[:200]}...")
            break 
            
    if not sse_data_payload:
        print("Error: No 'data:' line found in SSE response.")
        return {"error": "No 'data:' line found in SSE response."}

    try:
        response_data_json = json.loads(sse_data_payload)
        print(f"Parsed data from SSE: {json.dumps(response_data_json, indent=2)}") # 整形して表示

        if "error" in response_data_json and response_data_json["error"]:
            error_detail = response_data_json["error"]
            error_message = error_detail.get('message', 'Unknown MCP server error')
            print(f"MCP Server returned an error: {error_message}")
            return {"error": f"MCP Server Error: {error_message}"}
        elif "result" in response_data_json and response_data_json.get("id") == request_id:
            result_data = response_data_json["result"]
            if result_data.get("isError"):
                content_list = result_data.get("content", [])
                error_text = "MCP Tool Error (no specific message)"
                if content_list and content_list[0].get("type") == "text":
                    error_text = content_list[0].get("text", error_text)
                print(f"MCP Tool execution failed: {error_text}")
                return {"error": error_text}
            else:
                content_list = result_data.get("content", [])
                result_text = ""
                if content_list and content_list[0].get("type") == "text":
                    result_text = content_list[0].get("text", "")
                print(f"MCP Tool execution successful. Result text (first 200 chars): {result_text[:200]}...")
                return {"scraper_result": result_text}
        else:
            print(f"Invalid JSON-RPC response structure: {response_data_json}")
            return {"error": "Invalid JSON-RPC response from MCP server."}
            
    except json.JSONDecodeError as e:
        print(f"Error decoding JSON from SSE data: {e}. Data: '{sse_data_payload}'")
        return {"error": f"Error decoding JSON from SSE: {e}"}

except requests.exceptions.Timeout:
    print(f"Request to {mcp_server_url} timed out.")
    return {"error": "Request to MCP server timed out."}
except requests.exceptions.RequestException as e:
    print(f"Request to {mcp_server_url} failed: {e}")
    return {"error": f"Request to MCP server failed: {type(e).__name__} - {e}"}
except Exception as e:
    print(f"An unexpected error occurred: {e}")
    return {"error": f"An unexpected error occurred: {type(e).__name__} - {e}"}

if name == "main":
arg1 = 'google--search_query'
arg2 = 'google'
arg3 = 'https://mcp-server.veryglad.win/mcp'

result = main(arg1, arg2, arg3)
print("\n--- Final Result ---")
print(json.dumps(result, indent=2, ensure_ascii=False))
3. AIの回答:理解を深めるために質問したい

はい、提供されたPythonスクリプトを拝見しました。Difyプラグインへの改造に向けて、アプリの機能と構造を理解するためにいくつか質問させてください。

アプリの機能と目的について

  1. MCPサーバーとの連携:

    • このスクリプトは、指定されたMCPサーバー (mcp_server_url) に対して、特定のツール (run_scraper) の実行をリクエストするもののようですね。この理解で正しいでしょうか?
    • run_scraper というツールは、具体的にどのような処理(例: ウェブスクレイピング、データ検索など)を行うものと想定されていますか?
    • MCPサーバーは常に Content-Type: text/event-stream で応答し、実際のJSON-RPC応答はSSEの data: 行に含まれるという前提で良いでしょうか?
  2. 入力引数 (arg1, arg2, arg3):

    • arg1 (setdir): MCPツールの引数として渡される setdir ですが、これは具体的に何を指示するパラメータですか?(例: スクレイピング対象のディレクトリ構造、設定ファイルのパス、ツールの動作モードなど)
    • arg2 (search_query): これもMCPツールの引数で、検索クエリのようなものだと推測しますが、どのような種類の検索に使われますか?
    • arg3 (mcp_server_url): MCPサーバーのURLですね。これはプラグイン利用時にユーザーが指定できるようにする想定でしょうか?
  3. 期待される出力:

    • 成功した場合、run_scraper ツールはテキスト形式の結果を返すようですね (result_data.get("content", [])[0].get("text", ""))。このテキストはどのような内容を想定していますか?(例: スクレイピング結果のHTML、抽出されたテキストデータ、検索結果のリストなど)
    • エラーハンドリングは詳細に行われていますが、特にMCPサーバーからのエラー応答やツール実行エラー時の挙動について、Difyプラグインとしてユーザーにどのようにフィードバックするのが望ましいでしょうか?

Difyプラグイン化に向けた考慮事項

  1. プラグインタイプ:

    • このアプリの機能をDifyプラグインとして提供する場合、どのプラグインタイプが最も適切だとお考えですか?
      • ツールプラグイン: Difyのワークフローやエージェントから呼び出される独立したツールとして提供する。
      • 拡張機能プラグイン: 特定のHTTPエンドポイントとしてこの機能を提供し、外部からDify経由で利用できるようにする。
      • (その他、もしあれば)
  2. 認証情報:

    • MCPサーバーへのアクセスに認証(APIキー、トークンなど)は必要ですか?もし必要であれば、Difyプラグインの設定でどのように管理するのが望ましいでしょうか?(例: プラグインの設定画面で入力、環境変数など)
  3. 設定の柔軟性:

    • mcp_tool_name (run_scraper) は固定ですか、それともユーザーが他のMCPツールを指定できるようにしたいですか?
    • mcp_tool_args のキー(setdir, search_query)や構造は固定ですか?
  4. Dify環境での動作:

    • スクリプト内には、os.environ.getinputs を使ってDify環境から情報を取得する想定のコメントアウトされたコードがあります。これは、Difyのコードブロック (Code Node) での利用を想定していた名残でしょうか?
  5. タイムアウト値:

    • timeout=15.0 と設定されていますが、MCPサーバーの応答時間は通常どの程度を想定していますか?この値は固定で良いですか、それとも設定可能にすべきですか?

これらの質問にご回答いただくことで、アプリの理解を深め、Difyプラグイン化の具体的な設計についてより建設的な議論ができるかと存じます。

4. AIの質問に返答

返答します。

どの程度意識合わせできたか、先に教えて欲しいです。

このスクリプトは、指定されたMCPサーバー (mcp_server_url) に対して、特定のツール (run_scraper) の実行をリクエストするもののようですね。この理解で正しいでしょうか?
=> 正しいです。

run_scraper というツールは、具体的にどのような処理(例: ウェブスクレイピング、データ検索など)を行うものと想定されていますか?
=> ウェブスクレイピングします。

MCPサーバーは常に Content-Type: text/event-stream で応答し、実際のJSON-RPC応答はSSEの data: 行に含まれるという前提で良いでしょうか?
=> はい

入力引数 (arg1, arg2, arg3):
arg1 (setdir): MCPツールの引数として渡される setdir ですが、これは具体的に何を指示するパラメータですか?(例: スクレイピング対象のディレクトリ構造、設定ファイルのパス、ツールの動作モードなど)
=> 設定ファイルのパスです。これを変化させると、違うサイトにアクセス可能になってます。上記の例ではgoogleに行くようになってますが、amaonやメルカリに行くことも可能です

arg2 (search_query): これもMCPツールの引数で、検索クエリのようなものだと推測しますが、どのような種類の検索に使われますか?
=> googleの場合なら、google検索文字列になるので、大阪の天気、日本の首相など、自由に変更かのうです。

arg3 (mcp_server_url): MCPサーバーのURLですね。これはプラグイン利用時にユーザーが指定できるようにする想定でしょうか?
=> はい。ユーザーは自分のローカル環境にツールを入れます。そのツールをインターネットに公開するためのURLがarg3です。
今回はcloudflareを使って公開しています

成功した場合、run_scraper ツールはテキスト形式の結果を返すようですね (result_data.get("content", [])[0].get("text", ""))。このテキストはどのような内容を想定していますか?(例: スクレイピング結果のHTML、抽出されたテキストデータ、検索結果のリストなど)
=>抽出されたテキストデータがjsonでかえってきます

エラーハンドリングは詳細に行われていますが、特にMCPサーバーからのエラー応答やツール実行エラー時の挙動について、Difyプラグインとしてユーザーにどのようにフィードバックするのが望ましいでしょうか?
=>エラーコードが分かってデバッグできれば良いです。 詳細を求めません

このアプリの機能をDifyプラグインとして提供する場合、どのプラグインタイプが最も適切だとお考えですか?
=> ツールプラグイン: Difyのワークフローやエージェントから呼び出される独立したツールとして提供する。

MCPサーバーへのアクセスに認証(APIキー、トークンなど)は必要ですか?もし必要であれば、Difyプラグインの設定でどのように管理するのが望ましいでしょうか?
=> 不要です。 MCPサーバ側で事前にAPIキーを設定しています。

mcp_tool_name (run_scraper) は固定ですか、それともユーザーが他のMCPツールを指定できるようにしたいですか?
=> 固定です

mcp_tool_args のキー(setdir, search_query)や構造は固定ですか?
=> setdir, search_query は固定です。 setdir, search_queryに設定できる文字列は可変です。
例:
setdir : google-serch-query や setdir : amazon
search_query : 大阪の天気 や search_query : 日本の首相

スクリプト内には、os.environ.get や inputs を使ってDify環境から情報を取得する想定のコメントアウトされたコードがあります。これは、Difyのコードブロック (Code Node) での利用を想定していた名残でしょうか?
=> はい

timeout=15.0 と設定されていますが、MCPサーバーの応答時間は通常どの程度を想定していますか?この値は固定で良いですか、それとも設定可能にすべきですか?
=> これはdifyの制限を模擬して15秒にしてましたが、プラグイン化して、15秒の制限が緩和されるなら、是非是非緩和して欲しい!!

15秒の壁を緩和できるのではないかと思って、プラグイン化します。

4. AIの回答

ご回答ありがとうございます。いただいた情報で、アプリの機能と目的、そしてDifyプラグイン化へのご要望について、かなり明確に理解できました。

意識合わせ状況の確認と理解のまとめ

  • コア機能: 提供されたPythonスクリプトは、ユーザー指定のMCPサーバーに対して、ウェブスクレイピングを行う run_scraper ツールを呼び出し、その結果(抽出されたテキストデータがJSON形式で返される)を取得するクライアントアプリケーションである。
  • MCPサーバーの挙動: MCPサーバーはSSE (Server-Sent Events) を使用し、text/event-stream で応答する。実際のJSON-RPC応答は data: 行に含まれる。
  • 主要な入力:
    • setdir (引数1): スクレイピング対象サイトや動作を定義する設定ファイルのパス (例: google--search_query, amazon)。
    • search_query (引数2): 検索クエリなど、スクレイピング時の具体的な指示 (例: 大阪の天気, 日本の首相)。
    • mcp_server_url (引数3): ユーザーが自身のローカル環境等でホストし、Cloudflareトンネル等で公開したMCPサーバーのURL。
  • 期待される出力: 成功時はスクレイピング結果のJSONデータ(テキストとして抽出)、エラー時はデバッグに役立つエラーコード。
  • プラグイン化の目的: Difyのワークフローやエージェントから呼び出せるツールプラグインとして提供する。
  • 認証: MCPサーバー側で事前設定済みのため、プラグイン側での認証情報管理は不要。
  • 固定パラメータ: MCPツール名 (run_scraper) および引数キー (setdir, search_query) は固定。
  • タイムアウト: 現在15秒に設定されているのはDifyのコードノードの制限を模倣したものであり、プラグイン化によってこの15秒の制限を緩和したいという強いご要望がある。

現状の理解度としては、ほぼ齟齬なく把握できていると考えます。 特に、MCPサーバーとの連携方法、入力引数の意味、そしてプラグイン化の大きな動機の一つであるタイムアウト制限の緩和については明確に理解できました。

追加の質問や確認事項は、現時点では特にありません。

次のステップとして、この理解に基づいて、具体的にDifyのツールプラグインとしてどのように構成していくか(YAMLファイルの定義、Pythonコードの構造、入力パラメータの受け渡し方法など)を検討していくことになります。

もし、この理解に誤りや補足があればご指摘ください。なければ、プラグイン化の具体的な設計に進む準備が整ったと言えます。

5. 指示:進めて

進めてください

5. AIの回答:Difyの「ツールプラグイン」として改造するための具体的な設計案と手順を提示

承知いたしました。それでは、提供されたPythonスクリプトをDifyの「ツールプラグイン」として改造するための具体的な設計案と手順を提示します。

Difyツールプラグイン化 設計案

  1. プラグインの基本情報 (manifest.yaml)

    • author: あなたのGitHub IDなど
    • name: 例: mcp-scraper-tool
    • label: 例: MCP Scraper (多言語対応も可能)
    • description: 例: 指定されたMCPサーバー上のスクレイパーツールを実行します。
    • icon: 適切なアイコンファイル (_assets/icon.svg など)
    • resource.permission.tool.enabled: true (ツールプラグインなので必須)
    • plugins.tools: ["provider/mcp_scraper_provider.yaml"] (プロバイダー定義ファイルへのパス)
  2. ツールプロバイダー定義 (provider/mcp_scraper_provider.yaml)

    • identity: プロバイダーの基本情報 (author, name, label, description, icon, tags: ["scraping", "mcp"] など)
    • credentials_for_provider: 今回は認証不要なので、このセクションは空または省略可能。
    • tools: ["tools/run_mcp_scraper.yaml"] (実際のツール定義ファイルへのパス)
    • extra.python.source: provider/mcp_scraper_provider.py (プロバイダーのPython実装ファイル)
  3. ツール定義 (tools/run_mcp_scraper.yaml)

    • identity: ツールの基本情報 (name: run_mcp_scraper, author, label, description)
    • description.human: ユーザー向けのツールの説明
    • description.llm: LLMがツールを理解するための説明 (Agentで利用する場合に重要)
    • parameters:
      • name: mcp_server_url
        • type: string
        • required: true
        • label: MCP Server URL
        • form: form (ユーザーが直接入力)
        • human_description: MCPサーバーのエンドポイントURL (例: https://mcp-server.example.com/mcp)
      • name: setdir
        • type: string
        • required: true
        • label: Scraper Configuration Path (setdir)
        • form: llm (LLMによる推論またはユーザー入力)
        • human_description: スクレイパーの設定ファイルパス (例: google--search_query)
        • llm_description: The configuration path for the scraper, determining the target site and scraping logic (e.g., google--search_query for Google, amazon for Amazon).
      • name: search_query
        • type: string
        • required: false (必須ではない場合) または true (必須の場合)
        • label: Search Query / Parameters
        • form: llm (LLMによる推論またはユーザー入力)
        • human_description: 検索クエリやスクレイピング時の追加パラメータ (例: 大阪の天気)
        • llm_description: The specific search query or additional parameters for the scraping task (e.g., "weather in Osaka", "Prime Minister of Japan").
    • output_schema: (Difyワークフローで結果を構造的に扱いたい場合)
      • type: object
      • properties:
        • scraper_result: type: string (スクレイピング結果のJSON文字列)
        • error: type: string (エラーメッセージ)
    • extra.python.source: tools/run_mcp_scraper.py (ツールのPython実装ファイル)
  4. Python実装ファイル

    • provider/mcp_scraper_provider.py:

      from dify_plugin import ToolProvider
      from dify_plugin.errors.tool import ToolProviderCredentialValidationError # 必要に応じて
      from typing import Any
      
      class McpScraperProvider(ToolProvider):
          def _validate_credentials(self, credentials: dict[str, Any]) -> None:
              # 認証不要なので、基本的には何もしないか、簡単なチェックのみ
              # 例えば、もし将来的にプロバイダーレベルの設定が必要になった場合、ここで検証
              pass
      
    • tools/run_mcp_scraper.py:

      import requests
      import json
      import time
      from typing import Any, Generator # Generator をインポート
      from dify_plugin import Tool, ToolInvokeMessage # Tool と ToolInvokeMessage をインポート
      
      class RunMcpScraper(Tool):
          def _invoke(self, tool_parameters: dict[str, Any]) -> Generator[ToolInvokeMessage, None, None]:
              mcp_server_url: str = tool_parameters.get("mcp_server_url")
              setdir: str = tool_parameters.get("setdir")
              search_query: str = tool_parameters.get("search_query") # Optional
      
              if not mcp_server_url:
                  yield self.create_text_message("Error: MCP Server URL is not provided.") # エラーもテキストメッセージで返す
                  return
              if not setdir:
                  yield self.create_text_message("Error: 'setdir' is not provided.")
                  return
      
              mcp_tool_name = "run_scraper"
              mcp_tool_args = {"setdir": setdir}
              if search_query:
                  mcp_tool_args["search_query"] = search_query
      
              request_id = "dify-plugin-call-" + str(time.time())
              jsonrpc_request_body = {
                  "jsonrpc": "2.0",
                  "method": "tools/call",
                  "params": {"name": mcp_tool_name, "arguments": mcp_tool_args},
                  "id": request_id
              }
              headers = {
                  "Content-Type": "application/json",
                  "Accept": "application/json, text/event-stream"
              }
      
              # タイムアウト値をプラグイン設定から取得できるようにするか、
              # または、より長い値をデフォルトにする (例: 60秒)
              # Difyプラグインの実行環境では、Pythonのrequestsライブラリのタイムアウトは
              # Dify自体のHTTPリクエストタイムアウトとは別個に機能します。
              # Dify Cloud SaaS環境ではLambdaの実行時間上限(通常15分だが、設定による)も考慮。
              # セルフホストならサーバーリソース次第。
              # ここでは一旦300秒(5分)を試してみる
              timeout_seconds = tool_parameters.get("timeout_seconds", 300.0) 
              # ↑ もしタイムアウトもパラメータ化するなら、tools/run_mcp_scraper.yaml にも追加
      
              try:
                  response = requests.post(
                      mcp_server_url,
                      json=jsonrpc_request_body,
                      headers=headers,
                      timeout=float(timeout_seconds) # float型に変換
                  )
                  response.raise_for_status()
                  response.encoding = 'utf-8'
                  
                  response_text = response.text
                  
                  sse_data_payload = ""
                  for line in response_text.splitlines():
                      if line.startswith("data:"):
                          sse_data_payload = line[len("data:"):].strip()
                          break 
                          
                  if not sse_data_payload:
                      yield self.create_text_message("Error: No 'data:' line found in SSE response from MCP server.")
                      return
      
                  try:
                      response_data_json = json.loads(sse_data_payload)
      
                      if "error" in response_data_json and response_data_json["error"]:
                          error_detail = response_data_json["error"]
                          error_message = error_detail.get('message', 'Unknown MCP server error')
                          # output_schema に error があれば、そちらにもセットできる
                          yield self.create_variable_message(variable_name="error", variable_value=f"MCP Server Error: {error_message}")
                          # Difyのツールは通常、最後に主要な結果を返すか、エラーを示すテキストを返す
                          yield self.create_text_message(f"MCP Server Error: {error_message}")
                          return
      
                      elif "result" in response_data_json and response_data_json.get("id") == request_id:
                          result_data = response_data_json["result"]
                          if result_data.get("isError"):
                              content_list = result_data.get("content", [])
                              error_text = "MCP Tool Error (no specific message)"
                              if content_list and content_list[0].get("type") == "text":
                                  error_text = content_list[0].get("text", error_text)
                              yield self.create_variable_message(variable_name="error", variable_value=error_text)
                              yield self.create_text_message(error_text)
                              return
                          else:
                              content_list = result_data.get("content", [])
                              result_text = ""
                              if content_list and content_list[0].get("type") == "text":
                                  result_text = content_list[0].get("text", "")
                              # output_schema に scraper_result があれば、それにセット
                              yield self.create_variable_message(variable_name="scraper_result", variable_value=result_text)
                              # 主要な結果を text として返す
                              yield self.create_text_message(result_text)
                              return
                      else:
                          error_msg = "Invalid JSON-RPC response from MCP server."
                          yield self.create_variable_message(variable_name="error", variable_value=error_msg)
                          yield self.create_text_message(error_msg)
                          return
                          
                  except json.JSONDecodeError as e:
                      error_msg = f"Error decoding JSON from SSE: {e}"
                      yield self.create_variable_message(variable_name="error", variable_value=error_msg)
                      yield self.create_text_message(error_msg)
                      return
      
              except requests.exceptions.Timeout:
                  error_msg = f"Request to MCP server timed out after {timeout_seconds}s."
                  yield self.create_variable_message(variable_name="error", variable_value=error_msg)
                  yield self.create_text_message(error_msg)
                  return
              except requests.exceptions.RequestException as e:
                  error_msg = f"Request to MCP server failed: {type(e).__name__} - {e}"
                  yield self.create_variable_message(variable_name="error", variable_value=error_msg)
                  yield self.create_text_message(error_msg)
                  return
              except Exception as e:
                  error_msg = f"An unexpected error occurred: {type(e).__name__} - {e}"
                  yield self.create_variable_message(variable_name="error", variable_value=error_msg)
                  yield self.create_text_message(error_msg)
                  return
      

改造手順の概要

  1. Difyプラグイン開発環境のセットアップ:
    • 資料に従い、dify-plugin-daemon と Python 3.12+ を準備します。
  2. プラグインプロジェクトの初期化:
    • dify plugin init を実行し、プラグイン名 (例: mcp-scraper-tool)、作者などを入力。
    • プラグインタイプとして tool を選択。
    • 権限設定で Tool を有効にします。
  3. YAMLファイルの作成・編集:
    • 上記の設計案に従い、manifest.yaml, provider/mcp_scraper_provider.yaml, tools/run_mcp_scraper.yaml を作成・編集します。
  4. Pythonコードの作成・編集:
    • provider/mcp_scraper_provider.pytools/run_mcp_scraper.py を作成し、上記の設計案に基づいてコードを実装します。
    • 元のPythonスクリプトの main 関数のロジックを tools/run_mcp_scraper.py_invoke メソッド内に移植・適合させます。
    • DifyプラグインSDKの self.create_text_message()self.create_variable_message() を使って結果やエラーを返すようにします。
  5. 依存関係の管理:
    • requirements.txtrequests を記述します。
  6. デバッグ:
    • Difyの「プラグイン管理」ページでデバッグキーとリモートサーバーアドレスを取得。
    • プロジェクトルートに .env ファイルを作成し、情報を設定。
    • python -m main でプラグインをローカル起動し、Difyのワークフロー等から呼び出してテストします。
  7. パッケージ化:
    • dify plugin package ./<プラグインプロジェクト名>.difypkg ファイルを作成。
  8. 公開 (オプション):
    • Dify Marketplace, GitHub, ローカルファイルなどで共有。

タイムアウトについて

  • Pythonの requests ライブラリの timeout パラメータは、Difyプラグイン内でも独立して機能します。Difyのコードノードの15秒制限とは異なります。
  • tools/run_mcp_scraper.py の中で timeout_seconds = tool_parameters.get("timeout_seconds", 300.0) のように、デフォルト値を長めに設定(例: 300秒=5分)し、さらにこれを tools/run_mcp_scraper.yaml のパラメータに追加してユーザーが設定できるようにすることも可能です。
  • ただし、Dify Cloud (SaaS) 環境でプラグインを実行する場合、背後にあるAWS Lambdaなどの実行時間上限(デフォルト15分程度、設定により変動)も最終的な制約となります。セルフホスト環境であれば、サーバーリソースが許す限り長く設定できます。

この設計案で、元のPythonアプリの機能をDifyツールプラグインとして提供し、かつタイムアウトの懸念にもある程度対応できるかと思います。不明な点や修正点があれば、お気軽にご指摘ください。

6. AIへの質問:dify-plugin-daemon を準備について詳細に教えて

Difyプラグイン開発環境のセットアップ:
資料に従い、dify-plugin-daemon を準備します。

上記を具体的に、詳細に教えてください。

6. AIの回答:dify-plugin-daemonの準備

承知いたしました。Difyプラグイン開発環境のセットアップにおける「dify-plugin-daemon の準備」について、資料に基づいて具体的に、詳細に説明します。

dify-plugin-daemon は、Difyプラグイン開発を支援するコマンドラインインターフェース(CLI)ツールであり、プラグインプロジェクトの初期化、パッケージング、署名などを行うためのSDK(Software Development Kit)と見なすことができます。

1. dify-plugin-daemon のダウンロード

まず、このツール本体をダウンロードする必要があります。

  • アクセス先: DifyプラグインのGitHubリリースページ

    • 資料の該当箇所: プラグイン開発の入門 > 開発環境のセットアップ > 1. Difyプラグインスキャフォールディングツールのインストール方法
    • 具体的なURLは資料中に直接記載されていませんが、通常は langgenius/dify-plugin-daemon のようなリポジトリの /releases ページになります。最新版のリリースを探してください。
      • 例: https://github.com/langgenius/dify-plugin-daemon/releases (このURLは推測です。もし公式ドキュメント内に正確なリンクがあればそちらを優先してください。)
  • 適切なバージョンの選択:

    • お使いのオペレーティングシステム(OS)とCPUアーキテクチャに合ったファイルを選択します。
    • 資料の例では、Mシリーズチップ搭載のmacOS向けに dify-plugin-darwin-arm64 をダウンロードしています。
    • 一般的な選択肢:
      • macOS (Apple Silicon / M1, M2, etc.): dify-plugin-darwin-arm64
      • macOS (Intel): dify-plugin-darwin-amd64
      • Linux (64-bit Intel/AMD): dify-plugin-linux-amd64
      • Linux (ARM64): dify-plugin-linux-arm64
      • Windows (64-bit): dify-plugin-windows-amd64.exe

2. ダウンロードしたファイルの配置と実行権限の付与

ダウンロードしたファイルは実行可能なバイナリファイルです。

  • ファイルの配置:

    • 任意のディレクトリにダウンロードしたファイルを置きます。例えば、~/dify-tools/~/Downloads/ など。
  • 実行権限の付与 (macOS / Linux の場合):

    • ターミナル(コマンドプロンプトやPowerShellではありません)を開きます。
    • ダウンロードしたファイルがあるディレクトリに cd コマンドで移動します。
      cd path/to/downloaded/file/directory
      
    • chmod +x <ファイル名> コマンドで実行権限を付与します。
      # macOS (Apple Silicon) の例
      chmod +x dify-plugin-darwin-arm64
      
      # Linux (64-bit Intel/AMD) の例
      chmod +x dify-plugin-linux-amd64
      
    • Windowsの場合は、通常 .exe ファイルなので chmod は不要です。

3. インストールの確認 (バージョンの確認)

実行権限を付与した後、ツールが正しく動作するかを確認します。

  • ターミナルで、ダウンロードしたファイルがあるディレクトリで以下のコマンドを実行します。
    ./<ファイル名> version
    
    例:
    # macOS (Apple Silicon) の例
    ./dify-plugin-darwin-arm64 version
    
  • コマンドが成功すると、v0.0.1-beta.15 のようなバージョン情報が表示されます。これが表示されれば、ツールの準備は一旦完了です。

4. (推奨) システム全体で利用できるようにする (パスを通す)

毎回 ./<ファイル名> と入力するのは手間なので、ターミナルでどこからでも dify (または任意の短い名前) コマンドでツールを実行できるように設定すると便利です。

  • ファイル名の変更 (オプション):

    • ダウンロードしたファイルの名前を短いものに変更します。一般的には dify という名前にすることが多いようです。
      # macOS (Apple Silicon) の例
      mv dify-plugin-darwin-arm64 dify
      
  • パスの通ったディレクトリへの移動:

    • 変更したファイルを、システムの環境変数 PATH に含まれるディレクトリに移動します。これにより、どのディレクトリからでもコマンド名だけで実行できるようになります。
    • 一般的には /usr/local/bin (macOS / Linux) が使われます。
      # macOS / Linux の例
      sudo mv dify /usr/local/bin/
      # (sudo を使うため、管理者パスワードの入力が求められる場合があります)
      
    • Windowsの場合は、ダウンロードした .exe ファイルを環境変数 PATH に登録されているディレクトリ(例: C:\Windows\System32 や、自分で作成したカスタムディレクトリ)に置くか、そのファイルがあるディレクトリを環境変数 PATH に追加します。
  • 設定後の確認:

    • 新しいターミナルウィンドウを開き、以下のコマンドを実行します。
      dify version
      
    • バージョン情報が表示されれば、システム全体で利用できる設定が完了しています。

トラブルシューティング (資料に記載の例)

  • macOS で「Appleによって検証されていません」という警告が表示された場合:
    • システム設定(システム環境設定)を開きます。
    • 「セキュリティとプライバシー」(または「プライバシーとセキュリティ」)を選択します。
    • 「一般」タブで、ダウンロードしたアプリケーションの実行許可に関するメッセージの横にある「とにかく開く」("Open Anyway")ボタンをクリックします。
    • 場合によっては、Controlキーを押しながらファイルをクリックし、「開く」を選択することで、この警告を回避できることもあります。

まとめ

  1. ダウンロード: GitHubリリースページからOS/アーキテクチャに合ったバイナリをダウンロード。
  2. 配置: 任意の場所に保存。
  3. 実行権限付与: chmod +x <ファイル名> (macOS/Linux)。
  4. 動作確認: ./<ファイル名> version でバージョン表示を確認。
  5. (推奨) パスを通す: ファイル名を dify に変更し、/usr/local/bin などに移動。新しいターミナルで dify version を確認。

これで dify-plugin-daemon (これ以降は dify コマンドとして参照します) を使用する準備が整いました。この後、dify plugin init コマンドでプラグインプロジェクトの初期化に進むことができます。

7. AIへの質問:パラメータの設定方法を教えて

スクリーンショット 2025-05-22 100148.png

7. AIの回答:dify plugin initコマンドの設定方法

この画像は、dify plugin init コマンドを実行した際に表示される、プラグインの権限設定の画面ですね。ここで、作成するプラグインがDifyプラットフォームのどの機能にアクセスできるか(逆呼び出しできるか)を設定します。

今回の「MCP Scraper Tool」プラグインの場合、主な動作は外部のMCPサーバーにリクエストを送信することです。そのため、Difyプラットフォーム内部の複雑な機能を呼び出す必要は基本的にありません。

設定方法は以下の通りです。

  • 操作:

    • 上下の矢印キー (up and down) で項目間を移動します。
    • Tab キーで [X] のチェックボックスを選択/選択解除します。
    • 選択が完了したら Enter キーを押します。
  • 推奨設定:

    Configure the permissions of the plugin, use up and down to navigate, tab to select, after selection, press enter
    Backwards Invocation:
    Tools:
      -> Enabled: [X]  You can invoke tools inside Dify if it's enabled  <-- これを有効にします
    Models:
        Enabled: [ ]  You can invoke models inside Dify if it's enabled
        LLM: [ ]  You can invoke LLM models inside Dify if it's enabled
        Text Embedding: [ ]  You can invoke text embedding models inside Dify if it's enabled
        Rerank: [ ]  You can invoke rerank models inside Dify if it's enabled
        TTS: [ ]  You can invoke TTS models inside Dify if it's enabled
        Speech2Text: [ ]  You can invoke speech2text models inside Dify if it's enabled
        Moderation: [ ]  You can invoke moderation models inside Dify if it's enabled
    Apps:
        Enabled: [ ]  Ability to invoke apps like BasicChat/ChatFlow/Agent/Workflow etc.
    Resources:
    Storage:
        Enabled: [ ]  Persistence storage for the plugin
        Size: N/A  The maximum size of the storage
    Endpoints:
        Enabled: [ ]  Ability to register endpoints
    

設定の理由:

  • Tools: Enabled: [X] (有効)

    • これは、作成するプラグインが「ツール」としてDifyのワークフローやエージェントから呼び出されるために必須の権限です。我々のプラグインはまさにツールとして機能するため、これを有効にします。資料の「プラグイン権限の設定」部分にも、ツールプラグインテンプレートの例でこの権限が付与されていることが示唆されています。
  • Models: Enabled: [ ] (無効)

    • 我々のMCP Scraperは、Difyプラットフォーム内のLLMやその他のAIモデルを直接呼び出す必要はありません。外部のMCPサーバーがその処理を行います。
  • Apps: Enabled: [ ] (無効)

    • Dify内の他のアプリケーション(チャットボットやワークフローなど)をプラグインから呼び出す必要はありません。
  • Resources: Storage: Enabled: [ ] (無効)

    • 現在のスクリプトでは、プラグインが状態を保存したり、永続的なデータをDifyのストレージに書き込んだりする必要はありません。
  • Endpoints: Enabled: [ ] (無効)

    • このプラグインは外部からのHTTPリクエストを受け付けるエンドポイントを提供するものではなく、Dify内部から呼び出されるツールです。

まとめ

基本的には、「Tools」の「Enabled」のみを [X] (有効) に設定し、他の項目はすべて [ ] (無効) のままで問題ありません。

もし将来的に、このプラグインがDify内の他のモデルや機能を利用する必要が出てきた場合には、manifest.yaml ファイル内の resource.permission セクションを後から手動で編集して権限を追加することも可能です。しかし、初期設定としては最小限の権限で始めるのが良いでしょう。

8. AIへの質問:manifest.yamlはこれで良いか?

manifest.yaml は、セットアップしたら以下のようになっています。修正するところありますか?

version: 0.0.1
type: plugin
author: taro-ai
name: mcp-scraper-tool
label:
en_US: mcp-scraper-tool
ja_JP: mcp-scraper-tool
zh_Hans: mcp-scraper-tool
pt_BR: mcp-scraper-tool
description:
en_US: mcp-scraper-tool
ja_JP: mcp-scraper-tool
zh_Hans: mcp-scraper-tool
pt_BR: mcp-scraper-tool
icon: icon.svg
resource:
memory: 268435456
permission:
tool:
enabled: true
model:
enabled: false
llm: false
text_embedding: false
rerank: false
tts: false
speech2text: false
moderation: false
node:
enabled: false
endpoint:
enabled: false
app:
enabled: false
storage:
enabled: false
size: 0
plugins:
tools:
- provider/mcp-scraper-tool.yaml
meta:
version: 0.0.1
arch:
- amd64
- arm64
runner:
language: python
version: "3.12"
entrypoint: main
minimum_dify_version: null
created_at: 2025-05-22T10:04:39.9336627+09:00
privacy: PRIVACY.md
verified: false

8. AIの回答:修正点あり

はい、提示された manifest.yaml の内容を確認しました。初期セットアップとしては非常に良い状態ですが、いくつか推奨される修正点と確認点があります。

修正・確認推奨箇所:

  1. label:

    • 現在の設定:
      label:
        en_US: mcp-scraper-tool
        ja_JP: mcp-scraper-tool
        zh_Hans: mcp-scraper-tool
        pt_BR: mcp-scraper-tool
      
    • 推奨:
      • これはDifyのUI上で表示されるプラグイン名です。mcp-scraper-tool は開発者向けの名前としては良いですが、ユーザー向けにはもう少し分かりやすい名前が良いかもしれません。
      • 例: MCP ScraperMCPウェブスクレイパー など。
      • 日本語ラベル (ja_JP) も適切に設定しましょう。
      label:
        en_US: MCP Scraper Tool 
        ja_JP: MCPスクレイパーツール
        # zh_Hans と pt_BR も必要に応じて翻訳
      
  2. description:

    • 現在の設定:
      description:
        en_US: mcp-scraper-tool
        ja_JP: mcp-scraper-tool
        zh_Hans: mcp-scraper-tool
        pt_BR: mcp-scraper-tool
      
    • 推奨:
      • プラグインの機能を簡潔に説明する内容にしましょう。
      • 例:
      description:
        en_US: Executes a scraper tool on a specified MCP server and returns the results.
        ja_JP: 指定されたMCPサーバー上のスクレイパーツールを実行し、結果を返します。
        # zh_Hans と pt_BR も必要に応じて翻訳
      
  3. icon:

    • 現在の設定: icon: icon.svg
    • 確認:
      • プロジェクトのルートディレクトリ直下に _assets というフォルダを作成し、その中に icon.svg (または他の画像形式) という名前のアイコンファイルが実際に配置されているか確認してください。
      • 資料によれば、アイコンファイルは _assets フォルダに配置する必要があります。
        • (もし _assets フォルダがまだなければ作成し、アイコンファイルをそこへ移動してください。)
        • manifest.yaml での指定は icon.svg のままで良いですが、実際のファイルのパスは _assets/icon.svg になります。Difyのパッケージングプロセスがこれを解決してくれるはずです。
  4. resource.memory:

    • 現在の設定: memory: 268435456 (これは256MB)
    • 確認/考慮:
      • このプラグインは外部HTTPリクエストが主で、それ自体が大量のメモリを消費する処理は少ないと思われます。256MBは十分すぎるか、標準的な値かもしれません。
      • 特にセルフホスト環境でリソースを厳密に管理したい場合や、Cloud版でコスト最適化を考える場合は、より小さな値(例: 134217728 = 128MB)でも動作するかテストしてみる価値はあります。現状のままでも問題になることは少ないでしょう。
  5. plugins.tools:

    • 現在の設定: tools: - provider/mcp-scraper-tool.yaml
    • 確認:
      • ファイル名が mcp-scraper-tool.yaml となっています。これはプラグイン名と同じですが、プロバイダー定義ファイルとしては mcp_scraper_provider.yaml のような命名規則の方が一般的かもしれません(必須ではありません)。
      • このファイルパスが、実際にプロジェクト内に存在するプロバイダー定義YAMLファイルと一致しているか確認してください。もし provider/mcp_scraper_provider.yaml というファイル名で作成する予定なら、ここも修正が必要です。
        plugins:
          tools:
            - provider/mcp_scraper_provider.yaml # ファイル名に合わせて修正
        
  6. meta.minimum_dify_version:

    • 現在の設定: null
    • 考慮:
      • もし、このプラグインが特定のDifyバージョン以降の機能に依存している場合(例えば、特定の逆呼び出し機能など)、ここに最小バージョンを指定することができます。
      • 現状では null のままで問題ありませんが、将来的に必要になるかもしれません。
  7. privacy:

    • 現在の設定: PRIVACY.md
    • 確認/対応:
      • プロジェクトのルートディレクトリに PRIVACY.md という名前でプライバシーポリシーを記述したファイルを作成する必要があります。
      • このプラグインは外部のMCPサーバーにユーザーが指定した情報を送信するため、どのようなデータが送信され、どのように扱われる可能性があるかを明記する必要があります。
      • もしユーザー情報を収集・利用する場合は、資料の「プラグインのプライバシー保護に関するガイドライン」に従って内容を記述してください。
  8. created_at:

    • 現在の設定: 2025-05-22T10:04:39.9336627+09:00
    • これは自動生成されたものなので、そのままで問題ありません。

修正後の manifest.yaml (推奨例):

version: 0.0.1
type: plugin
author: taro-ai # あなたのGitHub IDなどに置き換えても良い
name: mcp-scraper-tool
label:
  en_US: MCP Scraper Tool
  ja_JP: MCPスクレイパーツール
  zh_Hans: MCP网络抓取工具 # 例: 中国語
  pt_BR: Ferramenta de Scraper MCP # 例: ポルトガル語
description:
  en_US: Executes a scraper tool on a specified MCP server and returns the results.
  ja_JP: 指定されたMCPサーバー上のスクレイパーツールを実行し、結果を返します。
  zh_Hans: 在指定的MCP服务器上执行网络抓取工具并返回结果。 # 例
  pt_BR: Executa uma ferramenta de scraper em um servidor MCP especificado e retorna os resultados. # 例
icon: icon.svg # _assets/icon.svg に配置
resource:
  memory: 268435456 # 必要に応じて調整
  permission:
    tool:
      enabled: true
    model:
      enabled: false
      llm: false
      text_embedding: false
      rerank: false
      tts: false
      speech2text: false
      moderation: false
    node:
      enabled: false
    endpoint:
      enabled: false
    app:
      enabled: false
    storage:
      enabled: false
      size: 0
plugins:
  tools:
    - provider/mcp_scraper_provider.yaml # プロバイダーファイル名に合わせて修正
meta:
  version: 0.0.1
  arch:
    - amd64
    - arm64
  runner:
    language: python
    version: "3.12"
    entrypoint: main
  minimum_dify_version: null # 必要に応じて設定
created_at: 2025-05-22T10:04:39.9336627+09:00
privacy: PRIVACY.md # PRIVACY.md ファイルを作成する
verified: false

特に重要なのは以下の点です:

  • labeldescription: ユーザーが理解しやすいように記述する。
  • icon: _assets フォルダにアイコンファイルを配置する。
  • plugins.tools: プロバイダー定義YAMLファイルへのパスを正確に指定する。
  • privacy: PRIVACY.md ファイルを作成し、プライバシーポリシーを記述する。

これらの点を修正・確認することで、より完成度の高い manifest.yaml になります。

9. AIへの質問:provider/mcp_scraper_provider.yamlをどうすれば良い?

provider/mcp_scraper_provider.yaml 
は以下の通り作成されてます。
どのようにすれば良い?

identity:
author: taro-ai
name: mcp-scraper-tool
label:
en_US: mcp-scraper-tool
zh_Hans: mcp-scraper-tool
pt_BR: mcp-scraper-tool
description:
en_US: mcp-scraper-tool
zh_Hans: mcp-scraper-tool
pt_BR: mcp-scraper-tool
icon: icon.svg
tools:

  • tools/mcp-scraper-tool.yaml
    extra:
    python:
    source: provider/mcp-scraper-tool.py
9. AIの回答:修正案

はい、提示された provider/mcp_scraper_provider.yaml の内容を確認しました。こちらも manifest.yaml と同様に、初期セットアップの状態からいくつか改善できる点があります。

ツールプロバイダー定義ファイル (provider/mcp_scraper_provider.yaml) は、Difyがこのプラグインに含まれるツール群をどのように認識し、ユーザーに提示するかを定義します。

修正・確認推奨箇所:

  1. identity.name:

    • 現在の設定: name: mcp-scraper-tool
    • 推奨: この name はプロバイダーの一意な識別子となります。プラグイン全体の名前 (manifest.yamlname) と同じである必要はありません。むしろ、このプロバイダーが提供するツールのカテゴリや性質を示す名前が良いでしょう。
    • 例: mcp_toolsmy_custom_scrapers など。
      • ただ、このプラグインが提供するツールが実質的に「MCP Scraper」という一つの主要機能に集約されるのであれば、mcp-scraper-tool のままでも混乱は少ないかもしれません。しかし、将来的に同じプロバイダーから複数の異なるMCP関連ツールを提供することを考えると、より汎用的なプロバイダー名が良いでしょう。
      • ここでは、シンプルにプラグイン名と合わせて mcp_scraper_provider のような名前にすることも考えられます。
      identity:
        name: mcp_scraper_provider # または mcp_tools など
      
  2. identity.label:

    • 現在の設定:
      label:
        en_US: mcp-scraper-tool
        zh_Hans: mcp-scraper-tool
        pt_BR: mcp-scraper-tool
      
    • 推奨: DifyのUIで、このツールプロバイダー(ツールのグループ)を選択する際に表示される名前です。manifest.yamllabel と同様に、ユーザーフレンドリーな名前にしましょう。
    • 例:
      label:
        en_US: MCP Scraper Tools
        ja_JP: MCPスクレイパーツール群 # 日本語ラベルも追加推奨
        # zh_Hans と pt_BR も適切に翻訳
      
  3. identity.description:

    • 現在の設定:
      description:
        en_US: mcp-scraper-tool
        zh_Hans: mcp-scraper-tool
        pt_BR: mcp-scraper-tool
      
    • 推奨: このツールプロバイダーが提供するツールの概要を説明します。
    • 例:
      description:
        en_US: A collection of tools for interacting with MCP-based scrapers.
        ja_JP: MCPベースのスクレイパーと連携するためのツール群です。 # 日本語ラベルも追加推奨
        # zh_Hans と pt_BR も適切に翻訳
      
  4. identity.icon:

    • 現在の設定: icon: icon.svg
    • 確認:
      • manifest.yaml と同様に、このアイコンも _assets/icon.svg に配置されていることを確認してください。通常、プロバイダーのアイコンとプラグイン全体のアイコンは同じものを使用することが多いです。
  5. tools:

    • 現在の設定: - tools/mcp-scraper-tool.yaml
    • 確認/推奨:
      • このプロバイダーが提供する具体的なツールの定義ファイルへのパスを指定します。
      • ツール定義ファイルの名前が mcp-scraper-tool.yaml となっています。これも、より具体的な機能名(例: run_mcp_scraper.yaml)にする方が分かりやすいかもしれません。
      • 実際に tools ディレクトリ配下にこの名前のYAMLファイルを作成し、その中でツールの詳細を定義します。
        tools:
          - tools/run_mcp_scraper.yaml # ツール定義ファイル名に合わせて修正
        
  6. extra.python.source:

    • 現在の設定: source: provider/mcp-scraper-tool.py
    • 確認/推奨:
      • このプロバイダーに関連するPythonコード(主に認証情報の検証など)を記述するファイルへのパスです。
      • ファイル名が mcp-scraper-tool.py となっています。プロバイダーの識別子と合わせた mcp_scraper_provider.py のような命名が良いでしょう。
      • このファイルは、前回の回答で示したように、認証が不要な場合は非常にシンプルな内容になります。
        extra:
          python:
            source: provider/mcp_scraper_provider.py # Python実装ファイル名に合わせて修正
        

修正後の provider/mcp_scraper_provider.yaml (推奨例):

identity:
  author: taro-ai # manifest.yaml と合わせる
  name: mcp_scraper_provider # プロバイダーの一意な識別子
  label:
    en_US: MCP Scraper Tools
    ja_JP: MCPスクレイパーツール群 # 日本語ラベルを追加
    zh_Hans: MCP网络抓取工具集 # 例
    pt_BR: Ferramentas de Scraper MCP # 例
  description:
    en_US: Provides tools to execute scrapers via an MCP server.
    ja_JP: MCPサーバー経由でスクレイパーを実行するためのツールを提供します。
    zh_Hans: 提供通过MCP服务器执行网络抓取工具的工具。 # 例
    pt_BR: Fornece ferramentas para executar scrapers através de um servidor MCP. # 例
  icon: icon.svg # _assets/icon.svg に配置
  # tags: # 必要に応じてタグを追加 (例: scraping, mcp, web)
  #   - scraping
  #   - mcp
tools:
  - tools/run_mcp_scraper.yaml # このプロバイダーが提供するツールの定義ファイル
extra:
  python:
    source: provider/mcp_scraper_provider.py # このプロバイダーのPython実装

重要なポイント:

  • identity.name: プロバイダーの一意な識別子です。
  • identity.labelidentity.description: Dify UIでの表示に使われるため、ユーザーに分かりやすい内容にします。日本語ラベルも忘れずに追加しましょう。
  • tools: このプロバイダーが実際に提供するツールの定義ファイル(後で作成する tools/run_mcp_scraper.yaml など)への正しいパスをリスト形式で指定します。
  • extra.python.source: プロバイダークラスを定義するPythonファイルへの正しいパスを指定します。

このファイルを修正し、次に tools/run_mcp_scraper.yaml (または指定したファイル名) を作成していくことになります。

10. AIへの質問:tools\mcp-scraper-tool.yamlの修正ポイントを教えて

tools\mcp-scraper-tool.yaml の内容は以下のとおりです。修正ポイントを教えて

identity:
name: mcp-scraper-tool
author: taro-ai
label:
en_US: mcp-scraper-tool
zh_Hans: mcp-scraper-tool
pt_BR: mcp-scraper-tool
description:
human:
en_US: mcp-scraper-tool
zh_Hans: mcp-scraper-tool
pt_BR: mcp-scraper-tool
llm: mcp-scraper-tool
parameters:

  • name: query
    type: string
    required: true
    label:
    en_US: Query string
    zh_Hans: 查询语句
    pt_BR: Query string
    human_description:
    en_US: mcp-scraper-tool
    zh_Hans: mcp-scraper-tool
    pt_BR: mcp-scraper-tool
    llm_description: mcp-scraper-tool
    form: llm
    extra:
    python:
    source: tools/mcp-scraper-tool.py
10. AIの回答

はい、提示された tools/mcp-scraper-tool.yaml の内容を確認しました。これは個別のツールを定義するファイルで、プラグインの核となる機能設定が含まれます。こちらも改善できる点がいくつかあります。特に、元のPythonスクリプトの入力引数 (mcp_server_url, setdir, search_query) を反映させる必要があります。

修正・確認推奨箇所:

  1. identity.name:

    • 現在の設定: name: mcp-scraper-tool
    • 推奨: このツールの一意な識別子です。プラグインやプロバイダー名と同じである必要はありません。より具体的な機能名が良いでしょう。
    • 例: run_mcp_scraperexecute_mcp_web_scraper
      identity:
        name: run_mcp_scraper # または他の具体的な名前
      
  2. identity.label:

    • 現在の設定:
      label:
        en_US: mcp-scraper-tool
        # ... (他言語も同様)
      
    • 推奨: DifyのUIで、このツールを選択する際に表示される名前です。ユーザーフレンドリーで、何をするツールか分かるようにしましょう。
    • 例:
      label:
        en_US: Run MCP Scraper
        ja_JP: MCPスクレイパー実行 # 日本語ラベルも追加
        # ...
      
  3. description.human:

    • 現在の設定:
      human:
        en_US: mcp-scraper-tool
        # ...
      
    • 推奨: ユーザーがこのツールの機能を理解できるように、簡潔で分かりやすい説明を記述します。
    • 例:
      human:
        en_US: Executes a web scraping task via a specified MCP server using a configuration path and an optional query.
        ja_JP: 指定されたMCPサーバー、設定パス、オプションのクエリを使用してウェブスクレイピングタスクを実行します。
        # ...
      
  4. description.llm:

    • 現在の設定: llm: mcp-scraper-tool
    • 推奨: これは、DifyのAgentがこのツールをいつ、どのように使用するかを判断するために非常に重要です。ツールの機能、期待される入力、主要な出力を明確に記述します。
    • 例:
      llm: "This tool calls an external MCP (Model Context Protocol) server to perform web scraping. It requires the MCP server's URL, a 'setdir' parameter specifying the scraper's configuration path (which defines the target site and scraping logic, e.g., 'google--search_query' or 'amazon'), and an optional 'search_query' for specific searches or parameters. The tool returns the scraped text data in JSON format. Use this tool when you need to extract information from websites by providing specific configurations and search terms to an MCP-enabled scraper."
      
      (日本語訳: "このツールは外部のMCPサーバーを呼び出してウェブスクレイピングを実行します。MCPサーバーのURL、スクレイパーの設定パスを指定する'setdir'パラメータ(対象サイトやロジックを定義。例: 'google--search_query'や'amazon')、およびオプションで特定の検索やパラメータのための'search_query'が必要です。ツールはスクレイピングされたテキストデータをJSON形式で返します。特定の構成と検索語を指定してMCP対応スクレイパーからウェブサイト情報を抽出する必要がある場合に使用してください。")
  5. parameters:

    • 現在の設定では query パラメータしか定義されていません。元のスクリプトの入力 (mcp_server_url, setdir, search_query) をここに反映させる必要があります。

    • 必須パラメータ:

      • mcp_server_url
      • setdir
    • オプションパラメータ:

      • search_query
      • (オプション) timeout_seconds (もしユーザー設定可能にするなら)
    • 修正案:

      parameters:
        - name: mcp_server_url
          type: string # または URL 型があればそれを使用 (Difyのスキーマ次第ですが、stringで問題ないことが多い)
          required: true
          label:
            en_US: MCP Server URL
            ja_JP: MCPサーバーURL
          human_description:
            en_US: The endpoint URL of your MCP server (e.g., https://mcp-server.example.com/mcp).
            ja_JP: MCPサーバーのエンドポイントURL(例: https://mcp-server.example.com/mcp)。
          llm_description: "The full URL of the MCP server endpoint that hosts the 'run_scraper' tool."
          form: form # ユーザーが直接入力することが多いと想定
      
        - name: setdir
          type: string
          required: true
          label:
            en_US: Scraper Configuration Path (setdir)
            ja_JP: スクレイパー設定パス (setdir)
          human_description:
            en_US: Path to the scraper's configuration file (e.g., 'google--search_query', 'amazon-product').
            ja_JP: スクレイパーの設定ファイルのパス(例: 'google--search_query', 'amazon-product')。
          llm_description: "The configuration path for the scraper, determining the target site and scraping logic (e.g., 'google--search_query' for Google, 'amazon' for Amazon). This dictates which website or type of content will be scraped."
          form: llm # LLMが文脈から判断するか、ユーザーが指定
      
        - name: search_query
          type: string
          required: false # 元のスクリプトではオプションだったので false に。必須なら true。
          label:
            en_US: Search Query / Parameters
            ja_JP: 検索クエリ / パラメータ
          human_description:
            en_US: The search query or additional parameters for the scraping task (e.g., 'weather in Osaka').
            ja_JP: 検索クエリやスクレイピングタスクの追加パラメータ(例: '大阪の天気')。
          llm_description: "The specific search query or additional parameters for the scraping task (e.g., 'weather in Osaka', 'Prime Minister of Japan'). This is optional."
          form: llm # LLMが文脈から判断するか、ユーザーが指定
      
        # もしタイムアウトを設定可能にするなら追加
        # - name: timeout_seconds
        #   type: number
        #   required: false
        #   label:
        #     en_US: Timeout (seconds)
        #     ja_JP: タイムアウト (秒)
        #   human_description:
        #     en_US: Maximum time in seconds to wait for the MCP server response. Default is 300.
        #     ja_JP: MCPサーバーの応答を待つ最大時間 (秒)。デフォルトは300秒です。
        #   llm_description: "Optional. The timeout in seconds for the request to the MCP server. Defaults to 300 if not specified."
        #   default: 300
        #   min: 10 # 適切な最小値を設定
        #   max: 600 # 適切な最大値を設定
        #   form: form # ユーザーが設定できるようにするなら form
      
    • form フィールドについて:

      • form: form: ユーザーがDifyのUI(例: ワークフローのノード設定画面)で直接値を入力するパラメータ。
      • form: llm: Agentが使用する際、LLMが会話の文脈などからこのパラメータの値を推論して設定することを期待する。ワークフローではユーザー入力も可能。
      • mcp_server_url は通常固定的な値なので form: form が適切でしょう。
      • setdirsearch_query はタスクによって変わるので form: llm が適していますが、ワークフローで使う場合はユーザーが直接指定もできます。
  6. output_schema (オプションだが推奨):

    • このツールがどのような形式で結果を返すかを定義します。これにより、Difyワークフローの後続ノードで結果を扱いやすくなります。
    • 元のスクリプトでは、成功時に {"scraper_result": "..."}、エラー時に {"error": "..."} を返す想定でした。
    • 推奨:
      output_schema:
        type: object
        properties:
          scraper_result:
            type: string
            description: "The scraped data from the MCP server, typically in JSON string format."
          error:
            type: string
            description: "An error message if the tool execution failed."
      
  7. extra.python.source:

    • 現在の設定: source: tools/mcp-scraper-tool.py
    • 確認/推奨:
      • このツールのPython実装コードが記述されるファイルへのパスです。
      • ファイル名が mcp-scraper-tool.py となっています。ツールの識別子 (例: run_mcp_scraper) と合わせた run_mcp_scraper.py のような命名が良いでしょう。
        extra:
          python:
            source: tools/run_mcp_scraper.py # Python実装ファイル名に合わせて修正
        

修正後の tools/run_mcp_scraper.yaml (推奨例):

identity:
  name: run_mcp_scraper # ツールの一意な識別子
  author: taro-ai # manifest.yaml や provider.yaml と合わせる
  label:
    en_US: Run MCP Scraper
    ja_JP: MCPスクレイパー実行
    zh_Hans: 执行MCP抓取器 # 例
    pt_BR: Executar Scraper MCP # 例
description:
  human:
    en_US: Executes a web scraping task via a specified MCP server using a configuration path and an optional query.
    ja_JP: 指定されたMCPサーバー、設定パス、オプションのクエリを使用してウェブスクレイピングタスクを実行します。
    zh_Hans: 通过指定的MCP服务器,使用配置路径和可选查询来执行网络抓取任务。 # 例
    pt_BR: Executa uma tarefa de web scraping através de um servidor MCP especificado, usando um caminho de configuração e uma consulta opcional. # 例
  llm: "This tool calls an external MCP (Model Context Protocol) server to perform web scraping. It requires the MCP server's URL, a 'setdir' parameter specifying the scraper's configuration path (which defines the target site and scraping logic, e.g., 'google--search_query' or 'amazon'), and an optional 'search_query' for specific searches or parameters. The tool returns the scraped text data, typically as a JSON string. Use this tool when you need to extract information from websites by providing specific configurations and search terms to an MCP-enabled scraper."
parameters:
  - name: mcp_server_url
    type: string
    required: true
    label:
      en_US: MCP Server URL
      ja_JP: MCPサーバーURL
    human_description:
      en_US: The endpoint URL of your MCP server (e.g., https://mcp-server.example.com/mcp).
      ja_JP: MCPサーバーのエンドポイントURL(例: https://mcp-server.example.com/mcp)。
    llm_description: "The full URL of the MCP server endpoint that hosts the 'run_scraper' tool."
    form: form

  - name: setdir
    type: string
    required: true
    label:
      en_US: Scraper Configuration Path (setdir)
      ja_JP: スクレイパー設定パス (setdir)
    human_description:
      en_US: Path to the scraper's configuration file (e.g., 'google--search_query', 'amazon-product').
      ja_JP: スクレイパーの設定ファイルのパス(例: 'google--search_query', 'amazon-product')。
    llm_description: "The configuration path for the scraper, determining the target site and scraping logic (e.g., 'google--search_query' for Google, 'amazon' for Amazon). This dictates which website or type of content will be scraped."
    form: llm

  - name: search_query
    type: string
    required: false # 必要に応じて true に変更
    label:
      en_US: Search Query / Parameters
      ja_JP: 検索クエリ / パラメータ
    human_description:
      en_US: The search query or additional parameters for the scraping task (e.g., 'weather in Osaka'). Optional.
      ja_JP: 検索クエリやスクレイピングタスクの追加パラメータ(例: '大阪の天気')。オプションです。
    llm_description: "Optional. The specific search query or additional parameters for the scraping task (e.g., 'weather in Osaka', 'Prime Minister of Japan')."
    form: llm

  # - name: timeout_seconds # 必要であれば追加
  #   type: number
  #   required: false
  #   label:
  #     en_US: Timeout (seconds)
  #     ja_JP: タイムアウト (秒)
  #   default: 300
  #   min: 10
  #   max: 600
  #   human_description:
  #     en_US: Maximum time in seconds to wait for the MCP server response. Default is 300.
  #     ja_JP: MCPサーバーの応答を待つ最大時間 (秒)。デフォルトは300秒です。
  #   llm_description: "Optional. The timeout in seconds for the request to the MCP server. Defaults to 300 if not specified."
  #   form: form

output_schema:
  type: object
  properties:
    scraper_result:
      type: string
      description: "The scraped data from the MCP server, typically in JSON string format."
    error:
      type: string
      description: "An error message if the tool execution failed."
extra:
  python:
    source: tools/run_mcp_scraper.py # Python実装ファイル名に合わせて修正

これらの修正を行うことで、Difyプラットフォーム上でこのツールがより適切に機能し、ユーザーやAgentにとっても理解しやすくなります。

11. AIへの質問:python -m main を実行したらエラー発生

python -m main
Traceback (most recent call last):
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\dify_plugin\core\plugin_registration.py", line 106, in _load_plugin_configuration
self.configuration = PluginConfiguration(**file)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\pydantic\main.py", line 253, in init
validated_self = self.pydantic_validator.validate_python(data, self_instance=self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pydantic_core._pydantic_core.ValidationError: 1 validation error for PluginConfiguration
resource.permission.storage.size
Input should be greater than or equal to 1024 [type=greater_than_equal, input_value=0, input_type=int]
For further information visit https://errors.pydantic.dev/2.11/v/greater_than_equal

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in _run_code
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\main.py", line 3, in
plugin = Plugin(DifyPluginEnv(MAX_REQUEST_TIMEOUT=120))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\dify_plugin\plugin.py", line 44, in init
self.registration = PluginRegistration(config)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\dify_plugin\core\plugin_registration.py", line 83, in init
self._load_plugin_configuration()
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\dify_plugin\core\plugin_registration.py", line 126, in _load_plugin_configuration
raise ValueError(f"Error loading plugin configuration: {e!s}") from e
ValueError: Error loading plugin configuration: 1 validation error for PluginConfiguration
resource.permission.storage.size
Input should be greater than or equal to 1024 [type=greater_than_equal, input_value=0, input_type=int]
For further information visit https://errors.pydantic.dev/2.11/v/greater_than_equal
(venv312) PS C:\Users\sinzy\dify-plugins\mcp-scraper-tool>

11. AIの回答:manifest.yaml修正案

トレースバックを拝見しました。エラーの原因は manifest.yaml ファイル内の resource.permission.storage.size の設定値にあります。

エラーメッセージ:

ValueError: Error loading plugin configuration: 1 validation error for PluginConfiguration
resource.permission.storage.size
  Input should be greater than or equal to 1024 [type=greater_than_equal, input_value=0, input_type=int]

これは、永続ストレージ (storage) を有効にしない場合でも、size フィールドには 0 ではなく、1024 (バイト) 以上の値を指定する必要があることを示しています。Difyプラグインのバリデーションルールによるものだと思われます。

今回のプラグインでは永続ストレージは使用しない (enabled: false) 想定ですが、バリデーションを通過させるために size の値を修正する必要があります。

修正箇所:

manifest.yaml ファイルの以下の部分を修正してください。

修正前:

    storage:
      enabled: false
      size: 0 # <--- 問題の箇所

修正後 (推奨):

    storage:
      enabled: false
      size: 1024 # enabled: false の場合でも、バリデーションのために最小許容値を設定

または、永続ストレージを全く使用しないことが明確であれば、size フィールド自体を省略してもバリデーションが通る可能性があります (Difyのバージョンやスキーマ定義によりますが、試す価値はあります)。ただし、エラーメッセージが size の値について具体的に指摘しているので、まずは最小許容値を設定するのが確実です。

    storage:
      enabled: false
      # size フィールドをコメントアウトまたは削除 (もしこれが許容されるなら)

しかし、エラーメッセージを考慮すると、size: 1024 とするのが最も安全な対処法です。

手順:

  1. manifest.yaml ファイルを開きます。
  2. resource: セクション内の permission: -> storage: -> size: の値を 0 から 1024 (またはそれ以上の適切な値、例えば 1048576 (1MB) でも良いですが、使わないのであれば最小値で十分です) に変更します。
  3. ファイルを保存します。
  4. 再度 python -m main コマンドを実行して、プラグインが正常に起動するか確認してください。

この修正で、Pydanticのバリデーションエラーは解消されるはずです。

12. AIへの質問:python -m main でエラー発生

python -m main
Traceback (most recent call last):
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\dify_plugin\core\plugin_registration.py", line 110, in _load_plugin_configuration
tool_provider_configuration = ToolProviderConfiguration(**fs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\pydantic\main.py", line 253, in init
validated_self = self.pydantic_validator.validate_python(data, self_instance=self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pydantic_core._pydantic_core.ValidationError: 2 validation errors for ToolProviderConfiguration
identity
Field required [type=missing, input_value={'credentials_for_provider': []}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.11/v/missing
extra
Field required [type=missing, input_value={'credentials_for_provider': []}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.11/v/missing

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in _run_code
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\main.py", line 3, in
plugin = Plugin(DifyPluginEnv(MAX_REQUEST_TIMEOUT=120))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\dify_plugin\plugin.py", line 44, in init
self.registration = PluginRegistration(config)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\dify_plugin\core\plugin_registration.py", line 83, in init
self._load_plugin_configuration()
File "C:\Users\sinzy\dify-plugins\mcp-scraper-tool\venv312\Lib\site-packages\dify_plugin\core\plugin_registration.py", line 126, in _load_plugin_configuration
raise ValueError(f"Error loading plugin configuration: {e!s}") from e
ValueError: Error loading plugin configuration: 2 validation errors for ToolProviderConfiguration
identity
Field required [type=missing, input_value={'credentials_for_provider': []}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.11/v/missing
extra
Field required [type=missing, input_value={'credentials_for_provider': []}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.11/v/missing

12. AIからの回答:バリデーションエラーの修正案

新たなトレースバック、ありがとうございます。今度は provider/mcp_scraper_provider.yaml (または manifest.yaml で指定したプロバイダー定義ファイル名) の内容に関するバリデーションエラーのようです。

エラーメッセージの核心部分:

ValueError: Error loading plugin configuration: 2 validation errors for ToolProviderConfiguration
identity
  Field required [type=missing, input_value={'credentials_for_provider': []}, input_type=dict]
extra
  Field required [type=missing, input_value={'credentials_for_provider': []}, input_type=dict]

これは、ツールプロバイダーの設定ファイル (ToolProviderConfiguration) を読み込む際に、必須フィールドである identityextra が見つからない、とDifyプラグインシステムが判断していることを示しています。

input_value={'credentials_for_provider': []} という部分がヒントです。これは、DifyがYAMLファイルをパースした結果、identityextra が期待される階層に存在せず、代わりに credentials_for_provider しか認識できなかった(あるいはそれがトップレベルにあると誤解した)可能性を示唆します。

原因として考えられることと対処法:

  1. YAMLファイルのインデントや構造の誤り:

    • provider/mcp_scraper_provider.yaml ファイルの内容を再度確認してください。特に identityextra がトップレベルのキーとして正しくインデントされているかを確認します。
    • credentials_for_provideridentityextra と同じ階層にあるべきですが、もしこれが誤って identityextra を内包するような形になっていたり、あるいは identityextracredentials_for_provider の子要素になっていたりすると、このエラーが発生します。
  2. credentials_for_provider の記述方法 (もし空の場合):

    • 以前の設計案では、「認証不要なので、このセクションは空または省略可能」と提案しました。もし credentials_for_provider: というキーだけを記述し、その下に何も値を指定していない場合(または空のリスト [] を指定した場合)、パーサーが混乱することがあります。
    • 対処法:
      • 認証が本当に不要であれば、credentials_for_provider セクション自体を完全に削除してみてください。
      • または、明示的に null や空のマップ {} を指定します。
        # 方法1: セクションごと削除
        # (credentials_for_provider: ... の行自体を消す)
        
        # 方法2: null を指定
        credentials_for_provider: null
        
        # 方法3: 空のマップを指定
        credentials_for_provider: {}
        
      エラーメッセージの input_value={'credentials_for_provider': []} を見ると、空のリスト [] を指定しているように見えます。ツールプロバイダーの credentials_for_provider は通常、キーと値のペア(マップ/辞書)のリストを期待するか、あるいはキーと値のペア自体を期待するので、空のリストは型が合わない可能性があります。

確認すべき provider/mcp_scraper_provider.yaml の構造例 (再掲):

identity: # <--- トップレベル
  author: taro-ai
  name: mcp_scraper_provider
  label:
    en_US: MCP Scraper Tools
    ja_JP: MCPスクレイパーツール群
  description:
    en_US: Provides tools to execute scrapers via an MCP server.
    ja_JP: MCPサーバー経由でスクレイパーを実行するためのツールを提供します。
  icon: icon.svg
  # tags:
  #   - scraping
  #   - mcp

# credentials_for_provider: null # もし空ならこのようにするか、セクションごと削除

tools: # <--- トップレベル (identity や extra と同じ階層)
  - tools/run_mcp_scraper.yaml

extra: # <--- トップレベル
  python:
    source: provider/mcp_scraper_provider.py

手順:

  1. provider/mcp_scraper_provider.yaml (または manifest.yaml で指定した実際のプロバイダー定義ファイル) を開きます。
  2. identity:extra: がファイルの最も左(インデントなし)から始まっていることを確認します。
  3. tools:identity:extra: と同じインデントレベルであることを確認します。
  4. credentials_for_provider: セクションが存在する場合、その記述が正しいか確認します。認証が不要な場合は、このセクションを完全に削除するか、credentials_for_provider: null または credentials_for_provider: {} としてみてください。エラーメッセージからすると、[] を指定している可能性があるので、これを修正します。
  5. ファイルを保存します。
  6. 再度 python -m main を実行します。

YAMLはインデントに非常に厳格なので、わずかなズレがパースエラーを引き起こすことがあります。VS CodeなどのエディタでYAMLのリンターを有効にすると、構文エラーを見つけやすくなります。

この修正で、identityextra が正しく認識されるようになるはずです。

更に数回、キャッチボールしたが、長いので省略

13. AIへの質問:プラグインが動いた。エージェントブロックでの設定方法を教えて

一旦、RUN MCP SCRAPERは動きました。
エージェントから、function colling で呼び出したいが、どのように設定すれば良い? 添付資料のInstruction と、 Query に入れる言葉を教えて

13. AIの回答:エージェントブロックでの、`INSTRUCTION` と `QUERY` に入力する内容例

素晴らしいです!Run MCP Scraper ツールがDifyプラグインとして動作するようになったのですね。

それでは、このツールをDifyのエージェントからFunction Callingで呼び出すための設定について説明します。添付いただいた画像のエージェント設定画面を元に、INSTRUCTIONQUERY に入力する内容の例を提案します。

エージェント設定の考え方

エージェントは、INSTRUCTION (指示) とユーザーからの QUERY (問い合わせ) を組み合わせて、どのツールをどのようなパラメータで呼び出すべきかを判断します。Function Calling を使う場合、モデル (この場合は Gemini 2.5 Flash Preview) がツールの説明 (description.llm) とパラメータ定義を理解し、適切なJSON形式でツール呼び出しを生成する必要があります。

設定例

画像のUIに基づくと、以下のようになります。

  • エージェンティック戦略: FunctionCalling (これは適切に設定されています)
  • MODEL: Gemini 2.5 Flash Preview 04-17 (これも適切です)
  • TOOL LIST: MCP_SCRAPER_PROVIDERRun MCP Scraper が有効になっている (これも適切です)

1. INSTRUCTION (指示)

ここには、エージェント全体としての振る舞いや、ユーザーの問い合わせに対してどのようにツールを使うべきかの一般的な指示を記述します。具体的すぎると柔軟性が失われるため、ある程度汎用的な指示が良いでしょう。

例1 (シンプルにツール利用を促す):

あなたはウェブサイトから情報を取得するアシスタントです。ユーザーのリクエストに応じて、利用可能なツール「Run MCP Scraper」を適切に使用して情報を取得し、結果を分かりやすく伝えてください。特にMCPサーバーのURL、スクレイパー設定パス(setdir)、検索クエリ(search_query)を正確にツールに渡してください。

例2 (より具体的な役割を与える):

あなたは専門のウェブ情報収集エージェントです。ユーザーから特定のウェブサイトの情報収集依頼があった場合、「Run MCP Scraper」ツールを使って指定されたMCPサーバーから情報を取得します。必要なパラメータ(MCPサーバーURL、setdir、search_query)をユーザーの意図から正確に抽出し、ツールを実行してください。結果は要点をまとめて報告してください。

重要なポイント for INSTRUCTION:

  • エージェントの役割を明確にする。
  • 使用するツール名 (Run MCP Scraper) を言及する (モデルが認識しやすくなる)。
  • ツールに必要な主要パラメータ (mcp_server_url, setdir, search_query) を意識させる。
  • ユーザーのクエリからこれらのパラメータを抽出するよう促す。

2. QUERY (問い合わせ)

ここには、ユーザーがエージェントに実際に行うであろう具体的なリクエストを入力します。エージェントは、この QUERY と上記の INSTRUCTION をもとに、Run MCP Scraper ツールのパラメータを生成しようとします。

Run MCP Scraper ツールに必要なパラメータ:

  • mcp_server_url (必須)
  • setdir (必須)
  • search_query (オプション)
  • timeout_seconds (オプション、デフォルト300秒)

QUERY の入力例:

例1 (全ての必須情報をQUERYに含める場合):

MCPサーバー https://mcp-server.veryglad.win/mcp を使って、設定パス 'google--search_query' で「東京の明日の天気」について調べてください。
  • 期待されるモデルの解釈 (Function Call の引数として):
    • mcp_server_url: "https://mcp-server.veryglad.win/mcp"
    • setdir: "google--search_query"
    • search_query: "東京の明日の天気"

例2 (MCPサーバーURLを固定値としてプラグイン側で設定し、QUERYではsetdirとsearch_queryのみを渡す場合 - ※このためにはプラグインのツールパラメータ定義でmcp_server_urlform:formにし、事前にUIで設定しておくか、Instructionで固定値を指示する必要があるかもしれません):
もし mcp_server_url が事前にエージェントのどこかで固定的に設定されているか、あるいはInstructionで「常にこのURLを使って」のように指示できるなら、Queryはシンプルになります。
(現在のツール定義では mcp_server_urlform:form なので、エージェントのUIでこのツールを設定する際に固定値を入力しておくのが一般的です。)

仮に、エージェントのツール設定UIで mcp_server_urlhttps://mcp-server.veryglad.win/mcp と設定済みの場合:

設定 'amazon-product-details' で、商品ID 'B0ExampleID' の詳細情報を取得してください。
  • 期待されるモデルの解釈:
    • mcp_server_url: (エージェントのツール設定から取得される想定)
    • setdir: "amazon-product-details"
    • search_query: "B0ExampleID"

例3 (search_query が不要な場合):

MCPサーバー https://mcp-server.veryglad.win/mcp を使って、設定パス 'news-headlines-jp' で最新ニュースを取得してください。
  • 期待されるモデルの解釈:
    • mcp_server_url: "https://mcp-server.veryglad.win/mcp"
    • setdir: "news-headlines-jp"
    • search_query: (指定なし、または空文字列)

Function Calling が成功するためのポイント:

  • ツールの description.llm が秀逸であること: モデルがツールの能力とパラメータの意味を正確に理解できるように、tools/run_mcp_scraper.yaml 内の description.llm および各パラメータの llm_description を詳細かつ明確に記述することが非常に重要です。
  • モデルの能力: Gemini 2.5 Flash Preview はFunction Callingに対応していますが、複雑な指示や曖昧なクエリからのパラメータ抽出精度はモデルの能力に依存します。
  • プロンプトエンジニアリング: INSTRUCTIONQUERY の書き方を工夫して、モデルがパラメータを正しく推論できるように導くことが重要です。Few-shot learningのように、成功例をInstructionに含めるのも有効な場合があります。

テストと調整

まずはシンプルな INSTRUCTION と、全ての必須情報を含む QUERY から試してみて、エージェントが正しくツールを呼び出し、期待通りのパラメータを渡せているかを確認します(エージェントの実行ログで確認できます)。
その後、徐々に QUERY の表現を変えたり、情報を部分的にしたりして、エージェントのパラメータ抽出能力をテストし、必要に応じて INSTRUCTION やツールの説明 (description.llm) を調整していくと良いでしょう。

14. AIへの質問:プラグインのデプロイ方法を教えて

自分用のdifyプラグインをdifyのクラウド環境にデプロイする方法で、かんたんなのある?

14. AI回答:ローカルファイル (`.difypkg`) としてアップロードする方法の提案

はい、Difyのクラウド環境にご自身で開発したプラグインをデプロイする比較的簡単な方法は、ローカルファイル (.difypkg) としてアップロードする方法です。

これは、Dify Marketplaceや公開GitHubリポジトリを経由せずに、開発したプラグインパッケージを直接ご自身のDifyクラウドワークスペースにインストールする手順です。自分専用、あるいは小規模なチーム内での利用に非常に適しています。

手順の概要

  1. プラグインのパッケージ化:

    • dify-plugin-daemon (または dify コマンド) を使用して、開発したプラグインプロジェクトを .difypkg ファイルにパッケージ化します。
    • ターミナルでプラグインプロジェクトのルートディレクトリに移動し、以下のコマンドを実行します(<your_plugin_project_directory_name> は実際のディレクトリ名に置き換えてください)。
      dify plugin package ./<your_plugin_project_directory_name>
      
      例:
      dify plugin package ./mcp-scraper-tool
      
    • これにより、カレントディレクトリに <plugin_name>.difypkg (例: mcp-scraper-tool.difypkg) というファイルが生成されます。
  2. Difyクラウドへのログイン:

    • ブラウザでDifyクラウド (cloud.dify.ai など) にアクセスし、ご自身のアカウントでログインします。
  3. プラグイン管理ページへの移動:

    • Difyのダッシュボード(ワークスペース)の右上にあるアバターアイコンの隣、または設定メニュー内に「プラグイン」(Plugins) という項目があります。それをクリックしてプラグイン管理ページに移動します。
  4. ローカルファイルからのインストール:

    • プラグイン管理ページに、「プラグインをインストール」(Install Plugin) のようなボタンがあります。
    • その中に、「ローカルからアップロード」(Upload from Local) や「ファイルからインストール」(Install from File) といった選択肢があるはずです。
    • このオプションを選択し、手順1で作成した .difypkg ファイルを選択してアップロードします。
    • 資料によっては、プラグインファイルをページの空白部分にドラッグ&ドロップするだけでインストールできるとも記載されています。
  5. インストールの確認:

    • アップロードが完了すると、プラグインが「インストール済み」のリストに表示されます。
    • これで、そのワークスペース内のアプリケーション (エージェント、ワークフローなど) から、インストールしたプラグインのツールを利用できるようになります。

この方法の利点と注意点

  • 簡単さ:
    • GitHubリポジトリの管理やDify Marketplaceへの申請・審査プロセスが不要なため、最も手軽で迅速です。
    • 開発中のテストや、個人・クローズドなチームでの利用に最適です。
  • プライベート性:
    • プラグインのコードを公開する必要がありません。
  • バージョン管理:
    • この方法では、Difyプラットフォーム側での自動的なバージョン管理やアップデート通知は行われません。プラグインを更新した場合は、再度新しい .difypkg ファイルを作成し、手動でアップロード(上書きインストールまたは既存のものを削除して新規インストール)する必要があります。
  • 共有の範囲:
    • インストールしたワークスペース内でのみ利用可能です。他のワークスペースや他のDifyユーザーと共有したい場合は、個別に .difypkg ファイルを渡すか、GitHubリポジトリ経由での共有を検討する必要があります。
  • 信頼性:
    • Dify Marketplaceのプラグインと異なり、Difyチームによる公式な検証や署名は行われません(ただし、セルフホスト環境では自己署名や第三者署名の仕組みがあります)。クラウド環境では、アップロードするプラグインの安全性は自己責任となります。

まとめ

ご自身で開発したDifyプラグインをDifyクラウド環境に最も簡単にデプロイする方法は、.difypkg ファイルをローカルからアップロードする方法です。開発とテストのサイクルを素早く回したい場合に非常に有効です。

以上

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?