Difyのプラグインがインストールできない原因と対処法【署名検証・容量・バージョン】

Difyでプラグインが「インストールできない」場合、原因はほぼ5つに絞れる。署名検証で弾かれる、パッケージが容量上限を超える、依存インストールがタイムアウトする、Difyのバージョンが古い、Marketplaceやgithub.comへ到達できない、のいずれかだ。プラグイン機構はDify 1.0.0（2025年2月28日リリース）で導入され、モデルもツールもすべてplugin_daemonサービス経由で読み込まれる。そのため多くの対処は、セルフホスト環境のdocker/.envを編集してplugin_daemonを再起動する作業になる。本記事はDifyの概要を前提に、症状から原因を切り分け、一次情報で確認した設定値とコマンドで解決するための実務ガイドである。

まとめ：インストールできない原因と対処の早見

まず症状から当たりを付ける。ほとんどのケースは下表のどれかに該当し、対処は「該当設定を書き換えてplugin_daemonを再起動」で完結する。個別の手順と根拠は本文で解説する。

Difyのプラグイン機構とインストール3経路

Dify 1.0.0でモデル・ツールがコアから分離され、すべて「プラグイン」として扱われるようになった。プラグインはmanifest.yamlとコード・依存・アセットを1ファイルに同梱した.difypkg形式で配布される。インストール経路は次の3つで、失敗時はどの経路を使ったかで切り分けが変わる。

どの経路でもプラグインの実処理はplugin_daemonコンテナが担う。管理画面で「Failed to request plugin daemon」が出る場合はプラグイン本体ではなくこのサービスの起動・到達性の問題だと切り分けられる。前提としてプラグインはDify 1.0以降専用で、0.x系にはプラグイン画面もMarketplaceも存在しない。

署名検証エラー：bad signatureとFORCE_VERIFYING_SIGNATURE

最も多いのが署名検証による拒否だ。Marketplaceに載っていない（＝未署名の）プラグインを、GitHubやローカルから入れようとすると次のエラーで止まる。

PluginDaemonBadRequestError: plugin verification has been enabled,
and the plugin you want to install has a bad signature

Difyは既定で署名検証が有効（docker/.env.exampleにFORCE_VERIFYING_SIGNATURE=trueが定義済み）だからだ。開発・検証環境で手早く通すなら、docker/.envに次を追記して再起動する。

# docker/.env
FORCE_VERIFYING_SIGNATURE=false

cd docker
docker compose down
docker compose up -d

本番で検証を全部切るべきでない理由と第三者署名

ただしFORCE_VERIFYING_SIGNATURE=falseは、出所不明のプラグインまで無検証で許可する設定だ。プラグインはサーバー側でコードを実行するため、本番環境で恒常的にオフにするのは避けたい。検証を保ったまま自前プラグインだけ通したい場合は、第三者署名を使う。鍵ペアで署名し、plugin_daemonに公開鍵を登録する方式だ。

# plugin_daemon に設定
FORCE_VERIFYING_SIGNATURE=true
THIRD_PARTY_SIGNATURE_VERIFICATION_ENABLED=true
THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS=/app/storage/public_keys/my_key_pair.public.pem

公開鍵はホスト側のdocker/volumes/plugin_daemon/public_keys/に置き、コンテナ内の/app/storage/public_keys/へマウントされる。これらの第三者署名用変数は既定の.env.exampleには含まれず手動追記が前提になる。署名の作り方は後述のCLI節で解説する。

パッケージ容量オーバー：50MB上限とNginxの413

モデルプロバイダ系など大きめのプラグインをローカルアップロードすると、容量制限で失敗する。プラグインパッケージの上限は既定で約50MB（PLUGIN_MAX_PACKAGE_SIZE=52428800バイト）に設定されている。加えてリバースプロキシのNginxが本文サイズで413 Request Entity Too Largeを返すこともある。両方を引き上げてから再起動する。

# docker/.env（例：100MBまで許可）
PLUGIN_MAX_PACKAGE_SIZE=104857600
NGINX_CLIENT_MAX_BODY_SIZE=100M

片方だけ上げても、もう片方で頭打ちになる点に注意する。一般ファイルのアップロード上限を管理するUPLOAD_FILE_SIZE_LIMITも存在するが、こちらは既定の.env.exampleに収録されておらず既定値は環境依存のため、容量エラーが続く場合の確認項目として押さえておくとよい。

インストールのタイムアウト：plugin_daemonと依存インストール

「インストール中」のまま進まない、あるいはfailed to install dependenciesで落ちる場合は、依存パッケージの取得・ビルドがタイムアウトしている。プラグインの初回導入時はPython仮想環境を作って依存を入れるため、依存が重いと既定の120秒では足りない。plugin_daemonのタイムアウトを延ばす。

# plugin_daemon の環境変数
PLUGIN_PYTHON_ENV_INIT_TIMEOUT=300
PLUGIN_MAX_EXECUTION_TIMEOUT=600

ネットワークが不安定でMarketplace/GitHubからの取得が途切れる場合は、対象プラグインの.difypkgをあらかじめ手元に落とし、「ローカルファイルからインストール」に切り替えるのが確実だ。なおdifypkg: not a valid difypkg fileと出るときはファイル破損か拡張子違いなので、ダウンロードし直す。設定変更後は必ずplugin_daemonを含めて再起動し、反映させる。

Marketplace/GitHubへの到達不可：ネットワークとプロキシ

Marketplaceタブが真っ白、あるいは検索結果が出ないときは、外部到達性を疑う。DifyはMarketplaceの接続先を環境変数で持っている。

MARKETPLACE_ENABLED=true
MARKETPLACE_API_URL=https://marketplace.dify.ai

企業プロキシ配下では、プロキシのCA証明書が信頼されずplugin_daemonが外部へTLS接続できずに失敗する既知の問題がある。GitHub経由の導入はgithub.comへの到達が前提になるため、社内ネットワークで塞がれていると同様に失敗する。完全なオフライン／閉域環境では、外部で取得した.difypkgを持ち込み、依存を同梱した上でローカルインストールする運用に切り替える。

Difyのバージョン非対応：プラグインは1.0以降専用

そもそもプラグイン画面が見当たらない場合は、Dify本体が0.x系のままである可能性が高い。プラグイン機構はv1.0.0で入った機能なので、0.xでは利用できず、まずv1系への移行が必要になる。2026年7月時点の安定最新は1.15系、次期の1.16.0はリリース候補（rc）段階だ。移行時はアプリ設定を後述のDSLでバックアップしてから上げると安全に戻せる。

GitHub・Confluence・OCIなど個別プラグイン導入のつまずき

特定プラグイン名で検索して来た読者向けに、混同しやすい点を整理する。

GitHubプラグインと「GitHubからのインストール」は別物

Marketplaceにはlanggenius/githubという公式ツールプラグインが実在し、リポジトリ検索などをワークフローから呼び出せる。これは「GitHub連携ツール」であって、前述の「GitHubリポジトリからプラグインを導入する経路」とは意味が異なる。後者はリポジトリURLを指定し、そのReleaseに添付された.difypkgを読み込む導入方式を指す。エラー時はどちらの話かを最初に区別する。

Confluenceプラグインはナレッジ連携系

Confluence連携はlanggenius/confluenceとして提供され、Notion・Google Drive・S3などと並ぶデータソース（Knowledge Pipeline）系のコネクタだ。認証情報の設定漏れが動作不良の主因になりやすい。

「dify oci」はOracle Cloud Infrastructure

「dify oci」で探している対象は、コンテナのOCIレジストリではなくlanggenius/oci＝Oracle Cloud InfrastructureのGenerative AI（Cohere Command R/R+などをOCI経由で利用）モデルプロバイダを指すことが多い。別途langgenius/oracle_ai_db（Oracle DB接続）も存在するため、モデル系かデータ系かを取り違えないようにする。

CLI・SDKで自作プラグインを作りパッケージ化する

「dify cli」「dify plugin sdk」で来る読者は、既製品の導入ではなく自作を目的としていることが多い。Difyの公式CLIはdifyコマンド（Dify Plugin CLI）で、macOSはHomebrew、Linux/WindowsはGitHub Releasesのバイナリで入る。

brew tap langgenius/dify
brew install dify
dify version

プラグイン本体はPython SDK（dify_pluginパッケージ）で書く。雛形の生成からパッケージ化、署名まで次の流れだ。

dify plugin init
dify plugin package ./my_plugin
dify signature generate -f my_key_pair
dify signature sign my_plugin.difypkg -p my_key_pair.private.pem

dify plugin packageが.difypkgを生成し、dify signature signがmy_plugin.signed.difypkgを作る。この署名済みファイルを、前述の第三者署名を有効にしたDifyへ入れれば、検証をONに保ったまま導入できる。開発中はローカルでpython -m mainとして起動し、リモートデバッグ（既定ポート5003）でDify本体につなぐ。Playwright MCPのDify連携のように、既存ツールをプラグイン経由で組み込む設計もこのSDKで実装できる。

アプリ・プラグインのエクスポート：DSL(.yml)と.difypkgの違い

「dify エクスポート」には2つの意味があり、混同すると目的のファイルが得られない。移行やバックアップで使うのは前者だ。

アプリのDSLエクスポートはAPIでも取得でき、Secret型の環境変数を含めるかを選べる。

GET /console/api/apps/{app_id}/export?include_secret=true

別環境へアプリを丸ごと移すならDSL、プラグインだけを配布するなら.difypkg、と使い分ける。エクスポートしたDSLはDifyワークフローの基本機能と使い方で組んだ構成の再現や、バージョン移行前の退避にそのまま使える。

よくある質問

Difyのプラグインが「bad signature」で入らないときの最短対処は？

開発環境ならdocker/.envにFORCE_VERIFYING_SIGNATURE=falseを追記し、docker compose down→up -dで再起動する。本番では検証を切らず、自前公開鍵を登録する第三者署名方式を使う。

モデルプラグインのインストールが失敗するのはなぜ？

モデル系はパッケージが大きく、既定約50MBのPLUGIN_MAX_PACKAGE_SIZEとNginxの413で弾かれやすい。PLUGIN_MAX_PACKAGE_SIZEとNGINX_CLIENT_MAX_BODY_SIZEを両方引き上げて再起動する。

Difyプラグインのインストールにコマンド（CLI）は必須ですか？

Marketplaceやローカルアップロードでの導入はGUIだけで完結し、CLIは不要だ。CLI（difyコマンド）が要るのは、自作プラグインの雛形生成・.difypkg化・署名を行うときに限られる。

「dify oci」プラグインとは何ですか？

Oracle Cloud InfrastructureのGenerative AIを使うためのモデルプロバイダプラグイン（langgenius/oci）を指すことが多い。コンテナのOCIレジストリとは無関係で、Oracle DB接続用のlanggenius/oracle_ai_dbとも別物だ。

プラグイン設定やアプリを別環境に移すにはエクスポートを使いますか？

アプリはDSL（.yml）でエクスポートして移行・バックアップする。プラグイン自体を配布するときはdify plugin packageで.difypkgを書き出す。両者は別の成果物なので目的に応じて使い分ける。

関連記事

• 最近話題の「Dify」で社内チャットボットを作成しよう！概要と魅力
• AWS EKSにDifyを導入するための事前準備と環境構築のポイント
• Difyワークフローの基本機能と使い方の詳細
• Playwright MCPとは？設定・使い方からDify連携まで実務ガイド【2026年版】
• MarkItDown（マークイットダウン）とは｜各種ファイルをMarkdownに変換するMicrosoft製Pythonツール