Skip to main content

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

langgenius/dify-plugins への Pull Request で、プラグインをマーケットプレイスのレビューに提出します。

必要なもの#

  • 現行の Dify Community Edition または Dify Cloud で動作確認済みのプラグインプロジェクト
  • パッケージ化に使用する Dify プラグイン CLI
  • ローカル検証に使用する Python 3 と yq
  • レビュアーとユーザーが確認できる公開ソースリポジトリ
Note

マーケットプレイスに提出するのはソースツリーではなく、パッケージ化した .difypkg です。パッケージだけでは確認できない動作について、レビュアーはメタデータと PR に記載されたソースリポジトリを確認します。

パッケージの準備#

manifest.yaml、プロバイダーまたはツールの定義、ソースコード、依存関係、README、プライバシーポリシー、アセットなど、実行時に必要なファイルだけを含めます。

.git/、仮想環境、キャッシュ、ログ、.DS_Store、ローカル設定、IDE ファイル、テスト成果物などの開発環境の状態は含めないでください。.env ファイル、アクセストークン、秘密鍵、クラウド認証情報などのシークレットは絶対に含めないでください。

プライバシーとネットワークアクセスの記載#

PRIVACY.md または公開済みのプライバシーポリシーには、プラグインが収集、保存、記録するユーザーデータや、第三者へ送信するデータを記載します。ユーザーデータを収集しない場合も、その旨を明記してください。

プラグインが外部サービスへ接続する場合、想定されるドメインを manifest.yaml で宣言できます。

実行時に組み立てる URL やベンダー SDK 内の URL を、静的解析ですべて検出することはできません。ドメインを宣言すると、スキャナーがソースコードから推測できない接続先も明示できます。

リスク分類#

プラグインに該当する最も高いレベルを選択します。マーケットプレイスの PR テンプレートでは、レベルを必ず 1 つだけ選択してください。

レベル適用条件
Low固定された文書公開済みの HTTPS API だけを呼び出す。

ユーザーが制御するコード、コマンド、SQL、ファイル操作、ブラウザー自動化、任意のネットワークリクエストを実行しない。
Mediumアップロードファイルやユーザー指定の URL を処理する、または第三者サービスで書き込み操作を行う。

ユーザーコンテンツを外部へ送信するか、高度な機密性を持たない個人データを扱う。
Highコードやコマンドの実行、SQL の実行、データベースやファイルシステムへのアクセス、SSH/SFTP、ブラウザー自動化が可能。

任意 URL のプロキシやクロール、実行可能ファイルの同梱、または機微な個人データの処理が可能。
Warning

複数のレベルに該当する場合は、高い方を選択してください。低いレベルを選んでもレビュー範囲は狭まりません。証拠に不整合が生じ、レビューが遅れるだけです。

Medium または High に分類したプラグインでは、セキュリティ境界を記載します。入力の制約、データの送信先、使用する認証情報、タイムアウト、エラー時にシークレットの漏えいを防ぐ方法を説明してください。

ローカルでのビルドと検証#

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

プラグインプロジェクトの 1 つ上のディレクトリで、次のコマンドを実行します。

.difypkg アーカイブが作成されます。続行する前に、ファイル名とファイルサイズを確認してください。

Marketplace Toolkit のクローン

パッケージ検証の実行

機密性の高い機能に関する検出結果を、PR で予定している開示と比較できます。PR の本文をファイルに保存し、--pr-body-file /path/to/pr-body.md を追加してください。

レポートの問題解消

validation-report/summary.md を開き、生成された *.errors.txt ファイルと *.warnings.txt ファイルを確認します。

終了コード 0 は、パッケージレベルのブロッキングエラーが見つからなかったことを示します。終了コード 1 の場合は、ブロッキングエラーまたは環境エラーを解消してください。警告があっても検証は失敗しませんが、レビュアーから説明を求められる場合があります。

ローカル検証では、安全な展開、パッケージ内容とサイズ、シークレットパターン、バイナリ、マニフェストと README のメタデータを確認します。さらに、依存関係ポリシー、Python のコンパイルと安全性パターン、外向きドメイン、依存関係の脆弱性、金融活動の兆候、任意の機密機能開示も確認します。

Tip

ネットワークへ接続するのは、脆弱性の照会だけです。必要に応じて --offline を追加してください。レポートには依存関係が記載されますが、脆弱性がないとは判定されません。

提出タイプの選択#

作成者の名前空間にパッケージディレクトリを作成します。

パッケージのメタデータ、ソースリポジトリ、連絡先、README、プライバシーポリシー、リスク開示は、すべて同じプラグインを示す必要があります。

PR の作成#

リポジトリの fork と同期

langgenius/dify-plugins を fork してクローンし、fork の main ブランチを upstream と同期します。

専用ブランチの作成

ブランチで変更する .difypkg パッケージが 1 つだけであることを確認します。

コミットとプッシュ

Pull Request の作成

fork から langgenius/dify-plugins:main へ PR を作成します。パッケージと説明の両方が自動チェックと人間のレビューに対応できる場合だけ、Draft を解除してください。

Warning

1 つの PR につき .difypkg は 1 つだけ提出してください。複数のプラグインやバージョンを含めると、CI が単一のパッケージパスを特定できず、提出がブロックされます。

提出テンプレートの記入#

現在のテンプレートはレビュー契約の一部です。フィールドを削除したり、短い自由形式の説明に置き換えたりしないでください。

プラグイン情報

作成者、プラグイン名、バージョン、公開ソースリポジトリ、定期的に確認する連絡先を記載します。これらの値は manifest.yaml とパッケージのドキュメントに一致させてください。

提出タイプと変更内容

New plugin または Version update を選択し、プラグインの用途または今回の変更点を説明します。更新時は、移行や破壊的変更を含むリリースノート相当の詳細を記載してください。

リスクレベル

Low risk、Medium risk、High risk のいずれか 1 つを選択します。リポジトリが対応する risk:* ラベルを付与します。未選択または複数選択の場合、risk: missing と bot コメントが追加されます。

必須チェック

パッケージの健全性、テスト、README の品質、プライバシーの記載、英語ローカライズを確認してから、各項目を選択します。要件に制限がある場合は、無条件にチェックせず Reviewer notes で説明してください。

セキュリティとプライバシー

コマンドやコードの実行、SQL、SSH/SFTP、ブラウザー自動化、ファイル操作、任意 URL の取得、プロキシ、機密データ処理を記載します。すべて該当しない場合だけ None と記載してください。

ローカル検証とレビュアー向けメモ

検証コマンドと結果を貼り付けます。既知の制限、パッケージやバイナリの例外、移行事項、警告の判断に必要な背景を追加してください。

レビューに必要な情報#

推奨回避
PR のタイトル、本文、メイン README を英語で記述する。主要な提出フィールドに未翻訳の CJK テキストを混在させる。
パッケージに対応する正確な公開ソースリポジトリをリンクする。組織のホームページや、場所を説明しない monorepo のルートをリンクする。
機密性の高い動作が必要な理由と制約を説明する。オプション機能という理由で高リスク機能を低リスクと説明する。
具体的な検証コマンドと結果を記載する。環境や結果なしで「テスト済み」とだけ記載する。
パッケージ内容と開示を一致させる。変更後のバージョンに古い PR 本文を流用する。

PR チェックとレビューへの対応 #

PR の作成、コミットのプッシュ、または Draft の解除によって、自動チェックが始まります。結果を確認し、対応が必要か判断してください。

結果対応
Passメンテナーのレビューを待つ。チェックに合格しても、承認されるとは限らない。
ブロッキングエラーパッケージまたは PR を修正し、必要に応じて再ビルドして、同じ PR を更新する。新しい PR は作成しない。
警告検出内容を確認する。実際の問題は修正し、意図した動作であれば背景を追記する。警告だけではチェックは失敗しないが、レビュアーから変更を求められる場合がある。
変更リクエストソースを更新し、必要に応じてパッケージを再ビルドする。同じ PR に修正をプッシュし、レビュアーへ返信する。

承認とマージ後、リポジトリがパッケージを再検証し、本番のマーケットプレイスへアップロードします。CI を手動で開始したり、承認済みパッケージを自分でアップロードしたりする必要はありません。

クリエイターセンターでプラグインのパフォーマンスとフィードバックを確認 #

プラグインがマーケットプレイスに表示されたら、クリエイターセンター の プラグイン ページでパフォーマンスを確認できます。個別の評価、いいね、フィードバックメッセージは 受信トレイ で確認できます。

公開済みプラグインの確認#

個人アカウントで、プラグインの公開に使用した GitHub アカウントを連携します。複数のアカウントを連携している場合は、表示するプラグインを公開したアカウントを選択してください。

各プラグインカードには、ダウンロード数、総合評価、評価件数、いいね数が表示されます。

チームでプラグインのパフォーマンスとフィードバックを確認#

チームで使用する組織を選択します。ここに表示されるプラグインは、組織の全メンバーが確認できます。

プラグイン用の組織を新しく作成する場合は、マーケットプレイスのプラグイン詳細ページでプラグイン ID を確認します。/ より前の部分を ユニークハンドル に入力してください。たとえば、プラグイン ID が team-name/plugin-name なら、team-name と入力します。

Marketplace 詳細ページのプラグイン ID

Marketplace 詳細ページのプラグイン ID

その組織が公開者として確認されると、組織名義で公開されたプラグインが プラグイン ページに表示されます。チームメンバーを招待すると、それぞれが GitHub アカウントを連携しなくても同じプラグインを確認できます。

表示されない組織プラグインの申請#

組織名義で公開したプラグインが、その組織の プラグイン ページに表示されない場合があります。プラグインを申請 を開き、パフォーマンスデータとフィードバックへのアクセスを申請します。

  1. 個人アカウントで プラグインを申請 を選択します。
  2. 各プラグインのマーケットプレイス詳細ページからプラグイン ID をコピーし、初回公開時の PR と組み合わせます。
  3. 連絡先メールアドレスを確認し、プラグインの保守における自身の役割を説明します。別の GitHub アカウントで PR を作成した場合は、その理由も記載してください。
  4. 申請を送信 を選択します。

申請状況は 申請履歴 で確認できます。承認されると、その公開者のすべてのプラグインを確認できます。却下された場合は理由を確認し、新規申請 を選択して証拠を更新し、再提出してください。

関連リソース#

PR テンプレート

提出前に現在のテンプレートを確認してください。リポジトリの要件は更新される場合があります。

プラグインレビューガイドライン

メンテナーがドキュメント、依存関係、プライバシー、機密性の高い機能を確認する方法を説明します。