⚠️ このドキュメントはAIによって自動翻訳されています。不正確な部分がある場合は、英語版を参照してください。
トリガープラグインとは?
トリガーは Dify v1.10.0 で新しいタイプの開始ノードとして導入されました。コード、ツール、ナレッジベース検索などの機能ノードとは異なり、トリガーの目的はサードパーティのイベントを Dify が認識して処理できる入力形式に変換することです。new email イベントの受信者として設定すると、新しいメールを受信するたびに、Gmail はワークフローをトリガーするために使用できるイベントを Dify に自動的に送信します。しかし:
- Gmail の元のイベント形式は Dify の入力形式と互換性がありません。
- 世界中には数千のプラットフォームがあり、それぞれ独自のイベント形式を持っています。
技術概要
Dify のトリガーは、Web 全体で広く採用されているメカニズムである webhook に基づいて実装されています。多くの主要な SaaS プラットフォーム(GitHub、Slack、Linear など)は、包括的な開発者ドキュメントと共に webhook をサポートしています。 webhook は HTTP ベースのイベントディスパッチャーとして理解できます。イベント受信アドレスが設定されると、これらの SaaS プラットフォームは、購読したイベントが発生するたびに、イベントデータをターゲットサーバーに自動的にプッシュします。 異なるプラットフォームからの webhook イベントを統一的に処理するために、Dify は 2 つのコアコンセプトを定義しています:Subscription と Event。- Subscription:Webhook ベースのイベントディスパッチには、サードパーティプラットフォームの開発者コンソールで Dify のネットワークアドレスをターゲットサーバーとして登録する必要があります。Dify では、この設定プロセスを Subscription と呼びます。
- Event:プラットフォームは複数のタイプのイベント(メール受信、メール削除、メールを既読にマークなど)を送信する可能性があり、これらはすべて登録されたアドレスにプッシュされます。トリガープラグインは複数のイベントタイプを処理でき、各イベントは Dify ワークフロー内のプラグイントリガーノードに対応します。
プラグイン開発
トリガープラグインの開発プロセスは、他のプラグインタイプ(ツール、データソース、モデルなど)と一貫しています。dify plugin init コマンドを使用して開発テンプレートを作成できます。生成されるファイル構造は標準のプラグイン形式仕様に従います。
-
manifest.yaml:プラグインの基本的なメタデータを記述します。 -
providerディレクトリ:プロバイダーのメタデータ、サブスクリプション作成のコード、webhook リクエスト受信後のイベント分類のコードを含みます。 -
eventsディレクトリ:イベント処理とフィルタリングのコードを含み、ノードレベルでのローカルイベントフィルタリングをサポートします。関連するイベントをグループ化するためにサブディレクトリを作成できます。
トリガープラグインの場合、最小必要 Dify バージョンは
1.10.0 に設定し、SDK バージョンは >= 0.6.0 である必要があります。サブスクリプションの作成
Webhook の設定方法は、主要な SaaS プラットフォーム間で大きく異なります:- 一部のプラットフォーム(GitHub など)は API ベースの webhook 設定をサポートしています。これらのプラットフォームでは、OAuth 認証が完了すると、Dify は自動的に webhook をセットアップできます。
- 他のプラットフォーム(Notion など)は webhook 設定 API を提供しておらず、ユーザーが手動で認証を行う必要がある場合があります。
github.yaml と github.py の 2 つのファイルを変更する必要があります。
- github.yaml
- github.py
GitHub の webhook は暗号化メカニズムを使用しているため、受信リクエストを復号化して検証するためにシークレットキーが必要です。そのため、
github.yaml で webhook_secret を宣言する必要があります。イベント処理
イベントが抽出されると、対応する実装は元の HTTP リクエストをフィルタリングし、Dify ワークフローが受け入れられる入力形式に変換する必要があります。 Issue イベントを例にとると、events/issues/issues.yaml と events/issues/issues.py を通じてイベントとその実装を定義できます。イベントの出力は issues.yaml の output_schema セクションで定義でき、ツールプラグインと同じ JSON Schema 仕様に従います。
- issues.yaml
- issues.py
イベントフィルタリング
特定のイベントをフィルタリングするには(例えば、特定のラベルを持つ Issue イベントのみに焦点を当てる場合)、issues.yaml のイベント定義に parameters を追加できます。その後、_on_event メソッドで、設定された条件を満たさないイベントをフィルタリングするために EventIgnoreError 例外をスローできます。
- issues.yaml
- issues.py
OAuth または API キーによるサブスクリプション作成
OAuth または API キーによる自動サブスクリプション作成を有効にするには、github.yaml と github.py ファイルを変更する必要があります。
- github.yaml
- github.py
github.yaml に以下のフィールドを追加します。subscription_constructor は、サブスクリプションの構築方法を定義するために Dify が抽象化した概念です。以下のフィールドが含まれます:-
parameters(オプション):購読するイベントタイプやターゲット GitHub リポジトリなど、サブスクリプション作成に必要なパラメータを定義します -
credentials_schema(オプション):API キーまたはアクセストークンを使用してサブスクリプションを作成するために必要な認証情報を宣言します(GitHub のaccess_tokensなど)。 -
oauth_schema(オプション):OAuth によるサブスクリプション作成を実装するために必要です。定義方法の詳細については、ツールプラグインに OAuth サポートを追加するを参照してください。
これら 2 つのファイルを変更すると、Dify インターフェースに Create with API Key オプションが表示されます。 OAuth による自動サブスクリプション作成も同じ
Constructor クラスで実装できます:subscription_constructor の下に oauth_schema フィールドを追加することで、OAuth 認証を有効にできます。

さらに詳しく
トリガープラグイン開発におけるコアクラスのインターフェース定義と実装方法は以下の通りです。Trigger
TriggerSubscriptionConstructor
Event
Edit this page | Report an issue