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

トリガープラグインとは?

トリガーは Dify v1.10.0 で新しいタイプの開始ノードとして導入されました。コード、ツール、ナレッジベース検索などの機能ノードとは異なり、トリガーの目的はサードパーティのイベントを Dify が認識して処理できる入力形式に変換することです。 Trigger Plugin Intro 例えば、Gmail で Dify を new email イベントの受信者として設定すると、新しいメールを受信するたびに、Gmail はワークフローをトリガーするために使用できるイベントを Dify に自動的に送信します。しかし:
  • Gmail の元のイベント形式は Dify の入力形式と互換性がありません。
  • 世界中には数千のプラットフォームがあり、それぞれ独自のイベント形式を持っています。
そのため、異なるプラットフォームや様々な形式からのこれらのイベントを定義・解析し、Dify が受け入れられる入力形式に統一するトリガープラグインが必要です。

技術概要

Dify のトリガーは、Web 全体で広く採用されているメカニズムである webhook に基づいて実装されています。多くの主要な SaaS プラットフォーム(GitHub、Slack、Linear など)は、包括的な開発者ドキュメントと共に webhook をサポートしています。 webhook は HTTP ベースのイベントディスパッチャーとして理解できます。イベント受信アドレスが設定されると、これらの SaaS プラットフォームは、購読したイベントが発生するたびに、イベントデータをターゲットサーバーに自動的にプッシュします。 異なるプラットフォームからの webhook イベントを統一的に処理するために、Dify は 2 つのコアコンセプトを定義しています:SubscriptionEvent
  • Subscription:Webhook ベースのイベントディスパッチには、サードパーティプラットフォームの開発者コンソールで Dify のネットワークアドレスをターゲットサーバーとして登録する必要があります。Dify では、この設定プロセスを Subscription と呼びます。
  • Event:プラットフォームは複数のタイプのイベント(メール受信メール削除メールを既読にマークなど)を送信する可能性があり、これらはすべて登録されたアドレスにプッシュされます。トリガープラグインは複数のイベントタイプを処理でき、各イベントは Dify ワークフロー内のプラグイントリガーノードに対応します。

プラグイン開発

トリガープラグインの開発プロセスは、他のプラグインタイプ(ツール、データソース、モデルなど)と一貫しています。 dify plugin init コマンドを使用して開発テンプレートを作成できます。生成されるファイル構造は標準のプラグイン形式仕様に従います。
  • manifest.yaml:プラグインの基本的なメタデータを記述します。
  • provider ディレクトリ:プロバイダーのメタデータ、サブスクリプション作成のコード、webhook リクエスト受信後のイベント分類のコードを含みます。
  • events ディレクトリ:イベント処理とフィルタリングのコードを含み、ノードレベルでのローカルイベントフィルタリングをサポートします。関連するイベントをグループ化するためにサブディレクトリを作成できます。
トリガープラグインの場合、最小必要 Dify バージョンは 1.10.0 に設定し、SDK バージョンは >= 0.6.0 である必要があります。
次に、GitHub を例として、トリガープラグインの開発プロセスを説明します。

サブスクリプションの作成

Webhook の設定方法は、主要な SaaS プラットフォーム間で大きく異なります:
  • 一部のプラットフォーム(GitHub など)は API ベースの webhook 設定をサポートしています。これらのプラットフォームでは、OAuth 認証が完了すると、Dify は自動的に webhook をセットアップできます。
  • 他のプラットフォーム(Notion など)は webhook 設定 API を提供しておらず、ユーザーが手動で認証を行う必要がある場合があります。
これらの違いに対応するため、サブスクリプションプロセスを 2 つの部分に分けています:Subscription ConstructorSubscription 自体。 Notion のようなプラットフォームでは、サブスクリプションを作成するには、ユーザーが Dify から提供されたコールバック URL を手動でコピーし、Notion ワークスペースに貼り付けて webhook 設定を完了する必要があります。このプロセスは、Dify インターフェースの Paste URL to create a new subscription オプションに対応します。 URL を貼り付けて新しいサブスクリプションを作成 手動 URL 貼り付けによるサブスクリプション作成を実装するには、github.yamlgithub.py の 2 つのファイルを変更する必要があります。
GitHub の webhook は暗号化メカニズムを使用しているため、受信リクエストを復号化して検証するためにシークレットキーが必要です。そのため、github.yamlwebhook_secret を宣言する必要があります。

イベント処理

イベントが抽出されると、対応する実装は元の HTTP リクエストをフィルタリングし、Dify ワークフローが受け入れられる入力形式に変換する必要があります。 Issue イベントを例にとると、events/issues/issues.yamlevents/issues/issues.py を通じてイベントとその実装を定義できます。イベントの出力は issues.yamloutput_schema セクションで定義でき、ツールプラグインと同じ JSON Schema 仕様に従います。

イベントフィルタリング

特定のイベントをフィルタリングするには(例えば、特定のラベルを持つ Issue イベントのみに焦点を当てる場合)、issues.yaml のイベント定義に parameters を追加できます。その後、_on_event メソッドで、設定された条件を満たさないイベントをフィルタリングするために EventIgnoreError 例外をスローできます。

OAuth または API キーによるサブスクリプション作成

OAuth または API キーによる自動サブスクリプション作成を有効にするには、github.yamlgithub.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 認証を有効にできます。 OAuth と API キーオプション

さらに詳しく

トリガープラグイン開発におけるコアクラスのインターフェース定義と実装方法は以下の通りです。

Trigger

TriggerSubscriptionConstructor

Event


Edit this page | Report an issue