--- title: "Difyのプラグインがインストールできない原因と対処法｜bad signature・依存エラー・容量【1.17.1対応】" url: "https://www.issoh.co.jp/tech/details/7098/" published: 2025-06-04 updated: 2026-10-17 categories: ["Dify"] publisher: "株式会社一創" --- # Difyのプラグインがインストールできない原因と対処法｜bad signature・依存エラー・容量【1.17.1対応】 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年版】](/tech/details/2758/)を参照してください。 ## まとめ：症状別の原因と対処（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](https://docs.docker.com/reference/cli/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`より優先される（[環境変数の優先順位](https://docs.docker.com/compose/how-tos/environment-variables/envvars-precedence/)）ため、`docker/envs/core-services/plugin-daemon.env`に書いても効きません。値は`docker/.env`に書きます。 Difyの`.env`の読まれ方は、ストレージ設定を例に[DifyのストレージをAmazon S3に切り替える設定手順と.envの優先順位](/tech/details/4131/)でも解説しています。 ## インストール経路と画面の場所：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）](https://docs.dify.ai/en/self-host/use-dify/workspace/plugins)によると、プラグインをインストールできるメンバーは、オーナーと管理者が「権限」で決めます。日本語UIの設定項目は「誰がインストールおよび管理できますか？」で、選択肢は「みんな」「管理者」「誰もいない」です。権限が無いメンバーには「連携管理の権限がありません」と表示されます。削除はこの設定に関係なく、オーナーと管理者しかできません。 Dify Enterpriseでは、管理者がデプロイ全体でインストールできる範囲を、公式のみ、公式と認証済みパートナー、マーケットプレイスからのみ、に絞れます。「このプラグインはインストールを許可されていません。」と出る場合は、この制限を疑います。 ### GitHubから入れるときの失敗 [GitHubリポジトリからの配布手順](https://docs.dify.ai/en/develop-plugin/publishing/marketplace-listing/release-to-individual-github-repo)では、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 signature ``` 1.17.1の`docker/.env.example`は`FORCE_VERIFYING_SIGNATURE=true`を既定にしています。デーモンは、この値が`true`でパッケージが検証済みでないとき、保存の前にこのエラーを返します。マーケットプレイスのプラグインはDifyの鍵で署名されているので通り、自作や第三者のパッケージは、未署名の場合や、登録された信頼済み公開鍵で署名を検証できない場合に弾かれます。 ### 開発環境：署名検証の無効化によるインストール [公式FAQ](https://docs.dify.ai/en/develop-plugin/publishing/faq/faq)は、開発用と信頼できる社内用途に限って、検証を切る方法を案内しています。 ``` # docker/.env の末尾に追記 FORCE_VERIFYING_SIGNATURE=false ``` ``` cd docker docker compose down docker compose up -d ``` この設定では、マーケットプレイス外の未署名プラグインがすべて入るようになります。検証用の環境で動作を確かめたら、本番へは次の署名方式で持ち込みます。 ### 本番環境：自前の鍵による署名と検証の維持 Community Editionには、検証を有効にしたまま、管理者が信頼した鍵で署名されたパッケージだけを通す仕組みがあります（[第三者署名検証](https://docs.dify.ai/en/develop-plugin/publishing/standards/third-party-signature-verification)）。鍵の作成と署名は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.pem ``` `docker/volumes/plugin_daemon`はコンテナ内の`/app/storage`にマウントされるので、公開鍵のパスはコンテナ内のパスで書きます。複数の鍵はカンマで区切ります。`docker compose down`と`up -d`のあと、`.signed.difypkg`をローカルパッケージファイルとして入れます。この機能はセルフホスト専用で、Dify Cloudでは署名の設定を変えられません。 ## plugin\_unique\_identifier is not valid：authorの不一致 アップロードの段階で`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=83886080 ``` APIのコード（`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 seconds ``` 2行目は、`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=300 ``` `NO_PROXY`には、デーモンがHTTPで呼ぶAPIコンテナのサービス名`api`を入れて、内部の通信がプロキシへ流れないようにします。デーモンは`uv`を起動するときに、この3つの値を明示的に渡します。ミラーを指定すると、デーモンは`uv.lock`のURLに縛られないよう`requirements.txt`を優先して使います。[dify-plugin-daemonのREADME](https://github.com/langgenius/dify-plugin-daemon)は、ミラーを使う場合に`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](https://github.com/langgenius/dify/issues/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のリリースノート](https://github.com/langgenius/dify/releases/tag/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月版】](/tech/details/2725/)や[DifyをPodmanのrootlessで動かす手順とNotion連携の設定](/tech/details/2791/)にまとめています。Kubernetesで動かしている場合は、[DifyをHelm chartでAWS EKSに構築する手順｜コミュニティ版0.38.0のvalues設定と落とし穴](/tech/details/7097/)のとおり、デーモン用の永続ボリュームの設定も確認してください。 ## 自作プラグインの導入：Dify Plugin CLIによるパッケージ化 「dify cli」で探すと2つの別物が出てきます。プラグインを作る`dify`コマンド（Dify Plugin CLI）と、Difyのアプリを端末やCIから実行する`difyctl`（Dify CLI）です。インストールの失敗に関係するのは前者だけで、マーケットプレイスやローカルファイルからの導入はGUIだけで完結します。 [Dify Plugin CLIの公式手順](https://docs.dify.ai/en/develop-plugin/getting-started/cli)では、macOSはHomebrew、LinuxとWindowsは[dify-plugin-daemonのReleases](https://github.com/langgenius/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年版】](/tech/details/6172/)で扱っています。 社内の業務にDifyとプラグインを組み込む設計から任せたい場合は、[生成AI導入支援](/service/ai/genai/)で構成の検討から支援しています。 ## よくある質問 ### 「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で使う設定です。 ## 関連記事 - [Difyでチャットボットを作る手順｜種別の選び分けと社内ナレッジ設定【2026年版】](/tech/details/2758/) - [Difyワークフローの作り方と使い方｜ノード選定・ループ・トリガーを実装手順で解説【2026年版】](/tech/details/4679/) - [DifyとChatGPT（OpenAI）を連携する手順｜プラグイン設定とGPT-6系のモデル選定【2026年10月版】](/column/details/2256/) - [DifyのストレージをAmazon S3に切り替える設定手順と.envの優先順位](/tech/details/4131/) - [DifyをHelm chartでAWS EKSに構築する手順｜コミュニティ版0.38.0のvalues設定と落とし穴](/tech/details/7097/) --- 出典: [Difyのプラグインがインストールできない原因と対処法｜bad signature・依存エラー・容量【1.17.1対応】]()（株式会社一創）