Difyのプラグインがインストールできないときは、セルフホスト環境なら、まずplugin_daemonのログで失敗した段階を確認します。この記事では、署名検証で弾かれる、依存パッケージの取得が止まる、パッケージが容量上限を超える、画面や権限の場所が変わっている、の4系統に分けて対処を示します。プラグインはDify 1.0.0（2025年2月28日）で導入された仕組みで、モデルもツールもこのデーモンが読み込みます。
この記事では、2026年10月時点の最新安定版Dify 1.17.1（2026年9月10日）と、同梱のdify-plugin-daemon 0.6.10のソースと公式ドキュメントを確認したうえで、エラー文言から原因を絞り込み、どの設定をどう変えるかを示します。Difyそのものの概要はDifyでチャットボットを作る手順｜種別の選び分けと社内ナレッジ設定【2026年版】を参照してください。
まとめ：症状別の原因と対処（Dify 1.17.1）
画面やログに出た文言で、下の表のどれに当たるかを先に決めます。docker/.envを書き換えたら、docker compose restartではなくdocker compose up -dでコンテナを作り直してください。restartでは環境変数の変更が反映されません。
| 症状・エラー文言 | 主な原因 | 対処 |
|---|---|---|
| has a bad signature | 未署名・信頼済みの鍵で検証できない | 第三者署名か、検証を切る |
| plugin_unique_identifier is not valid | authorとGitHub名の不一致 | author修正→再パッケージ |
| File size exceeds the maximum allowed size | 50MiB超のパッケージ | PLUGIN_MAX_PACKAGE_SIZE |
| failed to install dependencies | PyPIに届かない・無出力120秒 | プロキシ・ミラー・タイムアウト |
| Permission denied (os error 13) | WindowsのフォルダにDifyを置いている | WSL側のLinuxディレクトリへ移す |
| 互換性がありません。最小バージョンは… | Dify本体が古い | 本体を更新 |
| 連携管理の権限がありません | ワークスペースの権限 | オーナー・管理者が権限を変更 |
| プラグインのメニューが無い | 1.15以降は「連携」に移動／0.x系 | 左ナビの「連携」／1.x系へ移行 |
| Failed to request plugin daemon | APIからデーモンへ届かない | plugin_daemonの起動とログを確認 |
本番環境でFORCE_VERIFYING_SIGNATURE=falseを恒常的に使うのは避けてください。プラグインはサーバー上でPythonコードを実行するので、出所を確かめられないパッケージまで通す設定になります。本番では自前の鍵で署名して通す方法（後述）を選びます。
最初の切り分け：plugin_daemonのログとバージョン確認
画面の「インストールに失敗しました」だけでは原因が分かりません。公式FAQのとおり、セルフホストのプラグインのログはplugin_daemonコンテナに出ます。最初に次の3つを見てください。
cd docker
docker compose ps plugin_daemon
docker compose logs --tail 200 plugin_daemon
grep -n "image: langgenius/dify-" docker-compose.yaml最後の行で本体とデーモンの版が分かります。1.17.1のdocker-compose.yamlはlanggenius/dify-api:1.17.1とlanggenius/dify-plugin-daemon:0.6.10-localを指定しています。デーモンの最新は0.6.11（2026年10月10日）ですが、1.17.1のComposeにはまだ入っていません。
画面にFailed to request plugin daemonと出る場合は、プラグインの中身ではなく、APIコンテナからデーモンへのHTTPリクエストが失敗しています（api/core/plugin/impl/base.pyの例外処理）。docker compose psでplugin_daemonが起動しているか、ログにデータベース接続のエラーが出ていないかを先に確認します。
.envを変えても直らない2つの理由
「FORCE_VERIFYING_SIGNATURE=falseにしたのに直らない」ときは、設定値に加えて、変更がコンテナへ反映されているかを確認します。
- restartでは反映されない：Docker Docsのdocker compose restartには、環境変数の変更は再起動後も更新されないと書かれています。
docker compose up -d（またはdownのあとup -d）でコンテナを作り直します。 - 書くファイルが違う：1.17.1のComposeは、
plugin_daemonのenvironmentにFORCE_VERIFYING_SIGNATURE: ${FORCE_VERIFYING_SIGNATURE:-true}と書いています。Composeではenvironmentの値がenv_fileより優先される（環境変数の優先順位）ため、docker/envs/core-services/plugin-daemon.envに書いても効きません。値はdocker/.envに書きます。
Difyの.envの読まれ方は、ストレージ設定を例にDifyのストレージをAmazon S3に切り替える設定手順と.envの優先順位でも解説しています。
インストール経路と画面の場所：1.15以降は「連携」
プラグインの入れ方は3つあり、どれで失敗したかによって疑う場所が変わります。
| 経路 | 前提 | 失敗したら疑う所 |
|---|---|---|
| マーケットプレイス | marketplace.dify.aiへ届く | 外部通信・依存の取得 |
| GitHub | 公開リポジトリのReleaseに.difypkg | Release・author・署名 |
| ローカルパッケージファイル | 手元の.difypkg | 署名・容量 |
画面の場所は1.15.0（2026年6月25日）で変わりました。日本語UIでは、以前の右上の「プラグイン」に代わり、左のナビゲーションに「連携」と「マーケットプレイス」が並びます。「連携」の画面にある「インストール」から、GitHubとローカルパッケージファイルを選べます。古い/pluginsのURLは新しい画面へ転送されます。日本語の表記は1.15.0以降のweb/i18n/ja-JP/common.json（"mainNav.integrations": "連携"）で確認しました。「プラグイン」というメニュー名が見当たらない場合は、まず「連携」を確認してください。プラグイン機能自体がない0.x系の場合は、本体の移行が必要です（後述）。
「インストール」が押せない：ワークスペースの権限
公式ドキュメント（Integrations）によると、プラグインをインストールできるメンバーは、オーナーと管理者が「権限」で決めます。日本語UIの設定項目は「誰がインストールおよび管理できますか？」で、選択肢は「みんな」「管理者」「誰もいない」です。権限が無いメンバーには「連携管理の権限がありません」と表示されます。削除はこの設定に関係なく、オーナーと管理者しかできません。
Dify Enterpriseでは、管理者がデプロイ全体でインストールできる範囲を、公式のみ、公式と認証済みパートナー、マーケットプレイスからのみ、に絞れます。「このプラグインはインストールを許可されていません。」と出る場合は、この制限を疑います。
GitHubから入れるときの失敗
GitHubリポジトリからの配布手順では、Dify は指定したReleaseに添付された.difypkgを取りに行きます。「リリースは見つかりません。」と出るのは、リポジトリにReleaseが無いか、Releaseの「Assets」に.difypkgが添付されていない場合です。URLはhttps://github.com/owner/repoの形で入力します。ソースだけをpushしたリポジトリからは入れられません。
bad signature：署名検証エラーの原因と対処
マーケットプレイスに無いプラグインをGitHubやローカルファイルから入れると、次のエラーで止まることがあります。dify-plugin-daemon 0.6.10のplugin_decoder.goにある文言そのものです。
plugin verification has been enabled, and the plugin you want to install has a bad signature1.17.1のdocker/.env.exampleはFORCE_VERIFYING_SIGNATURE=trueを既定にしています。デーモンは、この値がtrueでパッケージが検証済みでないとき、保存の前にこのエラーを返します。マーケットプレイスのプラグインはDifyの鍵で署名されているので通り、自作や第三者のパッケージは、未署名の場合や、登録された信頼済み公開鍵で署名を検証できない場合に弾かれます。
開発環境：署名検証の無効化によるインストール
公式FAQは、開発用と信頼できる社内用途に限って、検証を切る方法を案内しています。
# docker/.env の末尾に追記
FORCE_VERIFYING_SIGNATURE=falsecd docker
docker compose down
docker compose up -dこの設定では、マーケットプレイス外の未署名プラグインがすべて入るようになります。検証用の環境で動作を確かめたら、本番へは次の署名方式で持ち込みます。
本番環境：自前の鍵による署名と検証の維持
Community Editionには、検証を有効にしたまま、管理者が信頼した鍵で署名されたパッケージだけを通す仕組みがあります（第三者署名検証）。鍵の作成と署名はDify Plugin CLIで行います。筆者がCLI v0.6.11で実行した結果は次のとおりです。
$ dify signature generate -f test_key
INFO key pair generated successfully private_key=test_key.private.pem public_key=test_key.public.pem
$ dify signature sign hello_check.difypkg -p test_key.private.pem
INFO plugin signed successfully output_path=hello_check.signed.difypkg
$ dify signature verify hello_check.signed.difypkg -p test_key.public.pem
INFO plugin verified successfully
$ dify signature verify hello_check.signed.difypkg
ERROR failed to verify plugin with official public key error="crypto/rsa: verification error"署名で12,100バイトのパッケージが12,998バイトの.signed.difypkgになりました。-pを省くとマーケットプレイスの公開鍵で照合するため、自前の署名は失敗します。この失敗は正常な結果です。次のコマンドはDifyリポジトリのルートで実行し、コピー元の公開鍵パスを鍵の保存場所に合わせて指定してください。
mkdir -p docker/volumes/plugin_daemon/public_keys
cp test_key.public.pem docker/volumes/plugin_daemon/public_keys/# docker/docker-compose.override.yaml
services:
plugin_daemon:
environment:
FORCE_VERIFYING_SIGNATURE: "true"
THIRD_PARTY_SIGNATURE_VERIFICATION_ENABLED: "true"
THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS: /app/storage/public_keys/test_key.public.pemdocker/volumes/plugin_daemonはコンテナ内の/app/storageにマウントされるので、公開鍵のパスはコンテナ内のパスで書きます。複数の鍵はカンマで区切ります。docker compose downとup -dのあと、.signed.difypkgをローカルパッケージファイルとして入れます。この機能はセルフホスト専用で、Dify Cloudでは署名の設定を変えられません。
アップロードの段階でplugin_unique_identifier is not validが出る場合、署名ではなくパッケージのメタデータに問題があります。公式FAQは、manifest.yamlとprovider/*.yamlのauthorを、すべてGitHubのユーザー名に揃えてからdify plugin packageで作り直すよう案内しています。片方のファイルだけ直して再パッケージすると、同じエラーが続きます。
なお、CLI v0.6.11のdify plugin init --helpでは、--authorに使える文字は1〜64文字の英小文字・数字・ハイフン・アンダースコアとされています。
容量オーバー：File size exceeds the maximum allowed size
大きなモデルファイルや画像を同梱したパッケージは、アップロード時にFile size exceeds the maximum allowed sizeで止まります。上限はPLUGIN_MAX_PACKAGE_SIZEで、1.17.1の.env.exampleでは52428800バイト（50MiB）です。Composeはこの1つの値を、APIコンテナのPLUGIN_MAX_PACKAGE_SIZEとデーモンのMAX_PLUGIN_PACKAGE_SIZEの両方に渡します。
# docker/.env（例：80MiBまで許可）
PLUGIN_MAX_PACKAGE_SIZE=83886080APIのコード（api/configs/feature/__init__.py）での既定値は15728640バイト（15MiB）で、Composeを使わずに環境変数で上限を指定していない場合はこちらが適用されます。1.17.1のComposeでは、古い.envにこの変数がなくても、Compose側の既定値50MiBが適用されます。リバースプロキシのNginxの上限NGINX_CLIENT_MAX_BODY_SIZEは1.17.1で既定100Mなので、アップロードのHTTPリクエスト本文がこの上限を超える場合は、こちらも上げます。ファイル以外の送信情報も含まれるため、パッケージ容量だけで判定しないでください。公式FAQは、大きなモデルの重みなどは外部に置き、初回利用時に取得する作りを勧めています。
依存インストールの失敗とタイムアウト
プラグインを入れると、デーモンはプラグインごとにPython 3.12の仮想環境を作り、依存パッケージをuvで入れます。0.6.10のsetup_python_environment.goでは、pyproject.tomlがあればuv sync、無ければrequirements.txtをuv pip installします。ここで失敗すると、ログに次の形で出ます。
failed to launch plugin: failed to install dependencies: ... output: ...
init process exited due to no activity for 120 seconds2行目は、PLUGIN_PYTHON_ENV_INIT_TIMEOUT（既定120秒）を超えて出力が無かったときにデーモンが処理を止めた印です。合計時間の上限ではないので、延ばしても通信できない状態は解決しません。インストール全体の上限は、デーモンのPLUGIN_INSTALL_TIMEOUT（既定15分）です。ただし0.6.10では、依存導入のuvプロセスに別途10分の上限があり、出力が続いていても停止します。output:の後ろにあるuvのログで、PyPIの名前解決に失敗しているのか、ビルドに失敗しているのかを見分けます。
社内プロキシ・閉域環境：PyPI接続とミラーの設定
デーモンの設定（internal/types/app/config.go）はHTTP_PROXY・HTTPS_PROXY・NO_PROXYを読みます。1.17.1のComposeはdocker/.envをenv_fileとしてデーモンに渡すので、docker/.envに書けば届きます。社内にPyPIのミラーがあるならPIP_MIRROR_URLで指定します。
# docker/.env
HTTP_PROXY=http://proxy.example.local:8080
HTTPS_PROXY=http://proxy.example.local:8080
NO_PROXY=api,localhost,127.0.0.1
PIP_MIRROR_URL=https://pypi.example.local/simple/
PLUGIN_PYTHON_ENV_INIT_TIMEOUT=300NO_PROXYには、デーモンがHTTPで呼ぶAPIコンテナのサービス名apiを入れて、内部の通信がプロキシへ流れないようにします。デーモンはuvを起動するときに、この3つの値を明示的に渡します。ミラーを指定すると、デーモンはuv.lockのURLに縛られないようrequirements.txtを優先して使います。dify-plugin-daemonのREADMEは、ミラーを使う場合にPLUGIN_IGNORE_UV_LOCK=trueも挙げています。
PyPIミラーの自動選択（daemon 0.6.5以降）
デーモン0.6.5以降には、起動時に公式PyPIと候補のミラーへの応答時間を測り、10%以上速いミラーがあれば自動で使う機能があり、既定で有効です。候補を指定しない場合は、mirrors.aliyun.comとpypi.tuna.tsinghua.edu.cnの2つを測ります。1.16系に同梱の0.6.3には無く、0.6.10を同梱する1.17.0以降で動きます。選ばれたときは、ログにIMPORTANT: pip mirror auto-detect selected a mirrorと出ます。
社内の通信ポリシーで許可していないミラーへ接続を試みると、ファイアウォールで遮断されてインストールが失敗することがあります。外部ミラーを使わない方針の環境では、docker/.envにPIP_MIRROR_AUTO_DETECT=falseを書くか、PIP_MIRROR_URLを明示してください。PIP_MIRROR_URLを設定すると自動選択は行われません。
WindowsでPermission denied (os error 13)
Windows 11のWSL2上で、DifyのフォルダをC:\Users\…（WSLからは/mnt/c）に置いていると、ローカルパッケージのインストールでPermission denied (os error 13)が出ることがあります。Difyのissue #42433（2026年9月17日・1.17.1）では、uvがキャッシュを/app/storage/cwd/.uv-cacheに書き込もうとし、その場所がWindows側のファイルシステムをマウントしたフォルダだったことが原因とされました。
この不具合はdaemon 0.6.11で、キャッシュをコンテナ内の場所に置く修正が入って閉じられています。ただし1.17.1のComposeは0.6.10を指定しているので、修正は含まれません。それまでは、Difyのリポジトリを/home/<ユーザー名>/difyのようなWSL側のLinuxディレクトリにcloneし、docker/volumesがWindowsのファイルシステムに乗らない構成にします。
バージョン非対応：0.x系と最小Dify版
プラグインの仕組みは1.0.0で入ったため、0.x系にはプラグイン画面もマーケットプレイスもありません。まず1.x系へ移行します。
1.x系でも、プラグイン側が要求する本体の版に届いていないと、「現在の Dify バージョンはこのプラグインと互換性がありません。最小バージョンは…です。」と表示されます。この値はプラグインのmanifest.yamlのmeta.minimum_dify_versionです。CLI v0.6.11で--min-dify-version 1.17.1を付けて雛形を作ると、生成されたmanifest.yamlにminimum_dify_version: 1.17.1が書き込まれました。表示された版以上に本体を上げるか、現在の本体に対応する旧版プラグインを選びます。本体を1.17.1へ更新する場合、既存データのある同梱Weaviateは、公式リリースノートに従ってバックアップと段階的更新を先に実施してください。
1.15より前から上げる場合は、1.17.1のリリースノートにあるモデル種別のデータ移行も確認してください。1.16.1と1.17.0ではflask data-migrate legacy-model-typesを手動で実行する必要があり、1.17.1からはflask db upgradeに含まれています。
マーケットプレイスの接続障害と閉域環境での導入
マーケットプレイスの接続先はMARKETPLACE_ENABLED=trueとMARKETPLACE_API_URL=https://marketplace.dify.ai（1.17.1の既定）で決まります。画面が空のまま、または検索結果が出ないときは、ブラウザではなくDifyのコンテナから外へ出られるかを確認します。社内プロキシの配下では、前述のHTTP_PROXY・HTTPS_PROXYをデーモンに渡します。
外部へまったく出られない閉域環境では、外で入手した.difypkgをローカルパッケージファイルとして入れます。ただし、依存パッケージの取得はインストール時にも走るので、社内のPyPIミラーをPIP_MIRROR_URLで指定しておく必要があります。Difyの構築環境ごとの注意は、DifyをAWS EC2に構築しBedrockへIAMロール接続する手順【2026年8月版】やDifyをPodmanのrootlessで動かす手順とNotion連携の設定にまとめています。Kubernetesで動かしている場合は、DifyをHelm chartでAWS EKSに構築する手順｜コミュニティ版0.38.0のvalues設定と落とし穴のとおり、デーモン用の永続ボリュームの設定も確認してください。
自作プラグインの導入：Dify Plugin CLIによるパッケージ化
「dify cli」で探すと2つの別物が出てきます。プラグインを作るdifyコマンド（Dify Plugin CLI）と、Difyのアプリを端末やCIから実行するdifyctl（Dify CLI）です。インストールの失敗に関係するのは前者だけで、マーケットプレイスやローカルファイルからの導入はGUIだけで完結します。
Dify Plugin CLIの公式手順では、macOSはHomebrew、LinuxとWindowsはdify-plugin-daemonのReleasesからバイナリ（dify-plugin-linux-amd64など）を取得します。2026年10月17日時点で、Releasesの最新は0.6.11、Homebrewのformulaは0.6.10でした。
brew tap langgenius/dify
brew install dify
dify version筆者が対話なしの--quickで雛形を作り、パッケージ化した手順は次のとおりです。
$ dify plugin init --quick --name hello_check --author issoh-test \
--description "install check" --category tool --language python \
--min-dify-version 1.17.1
INFO plugin created successfully name=hello_check guide=hello_check/GUIDE.md
$ dify plugin package ./hello_check
INFO plugin packaged successfully output_path=hello_check.difypkg生成されたmanifest.yamlのmeta.runnerはlanguage: pythonとversion: "3.12"でした。公式FAQのとおり、プラグインはPython 3.12の管理された環境で動き、manifest.yamlで別の版を指定しても使われません。依存は3.12で入る版に固定します。
雛形のrequirements.txtはdify_plugin>=0.9.0,<0.10.0でした。PyPIのdify-pluginの最新は0.10.2（2026年8月10日）なので、新しいSDKの機能を使う場合は、必要なバージョンを指定して検証します。雛形にはpyproject.tomlにもSDKの依存指定があるため、requirements.txtと整合させ、使用しているロックファイルも更新してください。マーケットプレイスへの申請ではdify-plugin >= 0.9.0が求められます。開発中は、雛形の.env.exampleを.envにコピーし、INSTALL_METHOD=remote、REMOTE_INSTALL_URL（host:port形式・既定ポート5003）、REMOTE_INSTALL_KEYを書きます。URLとキーは、ワークスペースのデバッグ用の画面に表示される値です。Python 3.12の環境でpip install -r requirements.txtを実行し、python -m mainでワークスペースにつないで動作を確かめてから、パッケージ化と署名へ進みます。既存のツールをプラグインやMCP経由で組み込む例は、Playwright MCPとは？設定・使い方からDify連携まで実務ガイド【2026年版】で扱っています。
社内の業務にDifyとプラグインを組み込む設計から任せたい場合は、生成AI導入支援で構成の検討から支援しています。
よくある質問
「plugin verification has been enabled」と出てプラグインが入らないのはなぜですか？
署名検証が有効（1.17.1の既定）で、パッケージが未署名、または信頼済み公開鍵で署名を検証できないためです。開発環境ならdocker/.envにFORCE_VERIFYING_SIGNATURE=falseを書いてdocker compose downとup -dを実行します。本番では自前の鍵で署名し、公開鍵をデーモンに登録します。
FORCE_VERIFYING_SIGNATUREをfalseにしても直らないのはなぜですか？
確認するのは、docker compose restartで済ませていないか、docker/.env以外のファイルに書いていないか、の2点です。restartは環境変数の変更を反映しません。1.17.1のComposeではenvironmentの値がenv_fileより優先されるので、docker/.envに書いてup -dで作り直します。
「インストール中」のまま終わらないときはどうすればよいですか？
docker compose logs plugin_daemonでuvの出力を確認します。PyPIへの名前解決やミラーへの接続で止まっていないかを調べます。出力が120秒（PLUGIN_PYTHON_ENV_INIT_TIMEOUT）途切れると打ち切られます。インストール処理全体の上限はPLUGIN_INSTALL_TIMEOUTの既定15分ですが、0.6.10の依存導入プロセスには別途10分の上限があります。
プラグインのインストールにDify CLIは必要ですか？
不要です。マーケットプレイス、GitHub、ローカルパッケージファイルのどれも画面から入れられます。difyコマンド（Dify Plugin CLI）が要るのは、自作プラグインの雛形作成、.difypkgへのパッケージ化、署名を行うときです。アプリを実行するdifyctlは別のツールです。
Dify Cloudでも署名検証を切れますか？
切れません。第三者署名検証の公式ページは、Dify Cloudでは署名を一元管理しており、これらの設定を公開していないと説明しています。FORCE_VERIFYING_SIGNATUREや公開鍵の登録は、セルフホストのCommunity Editionで使う設定です。
