よくある質問

Dify プラグインのビルド、パッケージ化、デバッグ、インストールに関するよくある問題と解決方法

このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。

パッケージ化とインストール

dify plugin package が plugin_unique_identifier is not valid で失敗するのはなぜですか？

manifest.yaml とすべての provider/*.yaml ファイル内の author フィールドは、ご自身の GitHub ハンドルと一致している必要があります。すべてのファイルで更新し、dify plugin package で再パッケージ化してから再インストールしてください。

plugin verification has been enabled, and the plugin you want to install has a bad signature が表示されるのはなぜですか？

セルフホスト版 Dify は、デフォルトでプラグインパッケージに対する署名検証を強制します。対処方法は 2 つあります。

1. 本番環境での推奨：パッケージに署名します。サードパーティ署名検証 を参照してください。

2. 開発および信頼できる内部利用：検証を無効にします。docker/.env に FORCE_VERIFYING_SIGNATURE=false を追加してから、再起動します。

   cd docker
   docker compose down
   docker compose up -d
   

   これにより、マーケットプレイス外のものを含むあらゆる未署名プラグインをインストールできるようになるため、自分が管理する環境でのみ行ってください。

.difypkg ファイルにサイズの上限はありますか？

あります。プラグインデーモンは、設定可能な上限（デフォルト 50MB）を超えるパッケージを拒否します。大きなモデルの重みや静的アセットを同梱する場合は、外部にホストして初回利用時にダウンロードするか、マーケットプレイスプラグインの上限引き上げについて Dify サポートにお問い合わせください。

プラグインに Python 3.13 が必要です。ランタイムを変更できますか？

できません。プラグインは管理された Python 3.12 環境内で実行されます。依存関係は 3.12 と互換性のあるバージョンに固定してください。デーモンは manifest.yaml 内の異なるランタイムバージョンを採用しません。

リモートデバッグ

プラグインは起動するのに、ワークスペースに表示されないのはなぜですか？

次の 3 点を順番に確認してください。(1) デーモンログに登録リクエストが記録されている、(2) REMOTE_INSTALL_KEY がデバッグダイアログに表示されているものと一致している、(3) REMOTE_INSTALL_URL が host:port 形式を使用している（個別の変数ではない）。トラブルシューティングの一覧全体は プラグインのデバッグ を参照してください。

コードの変更はホットリロードされますか？

されません。変更のたびに Ctrl+C でプラグインプロセスを停止し、python -m main を再実行してください。

OAuth と認証情報

上流の OAuth プロバイダーに設定するコールバック URL は何ですか？

ツールプラグインには https://<your-dify-host>/console/api/oauth/plugin/<author>/<plugin-name>/tool/callback を使用し、他のプラグインタイプの場合は tool を datasource または trigger に置き換えます。正確な形式は、Dify 内のプラグインの OAuth 設定カードに表示されます。

OAuth トークンが更新されないのはなぜですか？

プロバイダーの実装が初回認可で有効な refresh_token を返していれば、プラグイン SDK はトークンの期限切れ時に自動的に更新します。OAuthCredentials.refresh_token が設定されていること、および _oauth_refresh_credentials メソッドが実装されていることを確認してください。

マーケットプレイスへの公開

マーケットプレイスへの PR が自動チェックで却下されたのはなぜですか？

Marketplace ワークフローは、パッケージ、メタデータ、依存関係、開示、インストールを確認します。正確なチェック項目はリポジトリとともに更新されます。主なブロッキングエラーは次のとおりです。

• 複数の .difypkg を変更している：1 つの PR につき 1 つのプラグインパッケージを提出します。
• PR テンプレートまたはリスク選択が不完全である：すべてのセクションを残し、リスクレベルを 1 つ選択して機密性の高い機能を開示します。
• シークレット、開発成果物、説明のないバイナリが含まれている：パッケージから削除して再ビルドします。
• manifest、README、プライバシー、ソース、連絡先が無効である：メタデータと PR の説明を一致させます。
• 依存関係ポリシーに違反している：Python プラグインでは dify-plugin >= 0.9.0 を使用し、インストールと脆弱性の問題を解決します。
• バージョン重複またはインストール・パッケージテストの失敗：バージョンを上げ、再ビルドして現行 daemon でテストします。

PR チェックとレビューへの対応 では、結果の読み方と対応が必要かどうかの判断方法を説明しています。

マーケットプレイスのレビューにはどのくらいかかりますか？

レビュー時間は保証されません。完全なパッケージ証拠と PR テンプレートを用意し、CI の指摘を解決すると、確認の往復を減らせます。PR のコメントを監視し、同じブランチで対応してください。

マーケットプレイスにすでにあるプラグインの更新を公開するにはどうすればよいですか？

manifest.yaml の version を上げて再ビルドし、新しい .difypkg で langgenius/dify-plugins へ PR を開きます。メンテナーから指示がない限り、公開済みパッケージはリポジトリに残します。Marketplace Pull Request の提出 を参照してください。

プラグインを収益化できますか？

現時点ではできません。マーケットプレイスは無料プラグインのみを受け付けています。今後の価格設定ポリシーは別途お知らせします。

ストレージと制限

プラグインのログはどこに出力されますか？

セルフホスト：プラグインデーモンのコンテナログ（docker compose logs plugin_daemon）。クラウド：リモートデバッグ中のみワークスペースのプラグインデバッグパネルに表示され、永続化されたログは UI には公開されません。構造化された出力には プラグインのロギング を使用してください。

プラグインのストレージはワークスペースごとにスコープされますか？

されます。KV ストレージ API（self.session.storage）は、ワークスペースごと、プラグインのインストールごとに分離されます。同じプラグインを使用する 2 つのワークスペースがキーを共有することはありません。永続ストレージ（KV） を参照してください。