トリガーの登場により、ワークフローは手動操作や API 呼び出しに依存せず、外部イベントの変化に応じて自動的に走るようになりました。
本日、新たに Dify Trigger（トリガー） 機能を提供開始しました。
これまで Dify の ワークフローは、ユーザーの操作や API リクエストを受けたときにだけ起動し、単発の実行に限定されていました。
しかし トリガーのリリース後は、ワークフローがバックグラウンドサービスのように常時オンラインとなり、外部で発生するイベントを継続的に監視します。イベントが発生すれば、自動的にワークフローが立ち上がり、ワークフローの起動方式は「受動的な呼び出し」から「イベントドリブン」へと拡張されます。
なぜトリガーが必要なのか
ワークフローを自動化して規模を拡大していくと、最初に問題が表面化するのは実行ステップそのものではなく起動ロジックです。
ワークフローが数本しかない段階では、誰がどのタイミングで起動するかを取り決めで運用できます。しかし本数が増えると、起動方式は自然にバラバラになります。
- ボタン押下による起動
- 定時スクリプト
- 業務システム側からの直接呼び出し
起動ポイントが散在すると、管理コストは指数関数的に増大します。
「このイベントはどの ワークフローを起動するのか？」
「不具合が起きたとき、どこから調査すればよいのか？」
「いつのまにか使われなくなった起動ポイントはどれなのか？」
— こういった問いに答えづらくなるのです。
根本的な理由は 「トリガーと実行が分離している」 ことにあります。
トリガーが取り組むのは、この「いつ起動するか」を再びオーケストレーション層に戻すことです。
単なるタイマーや webhook の追加にとどまらず、イベントリスニングをワークフローのネイティブ能力にすることが狙いです。スケジュール、SaaS の状態変化、業務システムからのコールバックなどを同じキャンバス上で統合的に定義し、フィルタリングし、ルーティングし、下流の LLM・Agent・各種ツールノードに渡せるようになります。
ワークフローにおける トリガーの位置づけ
トリガーの導入により、ワークフローの開始点は次の 2 種類になります。
1. ユーザー入力：一度限りのトリガー
ユーザー入力や API 呼び出しによって実行される単発のフロー。
ツール型やインタラクション型のシナリオに適しています。
2. トリガー：イベントドリブン
外部イベントを継続的に監視し、条件を満たすとそのイベント内容を構造化変数に変換して ワークフローに渡します。
同じキャンバス内で複数の トリガーを設定でき、それぞれが別の処理分岐を駆動することも、後続で合流することもできます。
3 種類の トリガータイプ
Dify v1.10.0 では、トリガーは「スケジュールイベント」「サードパーティプラットフォームのイベント」「内部システムイベント」という 3 種のイベントソースに対応する 3 タイプを提供します。
1. スケジュールトリガー：時間ベースのトリガー
Schedule トリガーは、定時で ワークフローを起動します。
- 日報作成
- 定期データ集計
- ステータスヘルスチェック
など、安定周期のタスクに最適です。
時間指定は「毎時／毎日／毎週／毎月」または cron 表現に対応。
実行時にはタイムスタンプなどの変数が提供され、後続ノードでデータ取得やレポート生成、通知送信などに活用できます。
2. プラグイントリガー：サードパーティ アプリのイベント
プラグイントリガーは、外部アプリのイベントをプラグインで購読し、変化が起きた際にワークフローを起動する方式です。
典型的な例：
- リポジトリの Pull Request
- 工数管理・チケットシステムの新規チケット
- コラボレーション文書の更新
よく使われる SaaS には、あらかじめトリガープラグインを用意しています。
プラグインをインストールして認可すると、購読可能なイベント一覧が表示されます。ワークフローでプラグイントリガーを追加して必要なイベントを選択すると、外部アプリから送られてくるイベントが自動でワークフローを起動し、プラグインが解析した構造化データが渡されます。
同じ購読を複数ワークフローで共有できるため、設定の重複もありません。
3. Webhookトリガー：自社システムや既存サービスとの連携
Webhook トリガーは、プラグインが存在しない自社システムやサービスを接続するための トリガーです。
トリガーごとに固有の HTTP アドレスが発行されるため、業務システムは必要なタイミングでそのアドレスにリクエストを送るだけでワークフローを起動できます。
リクエストのパラメータ・ヘッダ・ボディはワークフローの後続のノードの変数として利用可能です。必要であれば、Webhook は処理結果やステータス、エラー情報を呼び出し元へ返すこともできます。
実際の活用シナリオ
トリガーの登場により、Dify ワークフローは完全な業務プロセスを担えるようになります。
条件分岐、LLM 分析、Agent 推論、ループ処理、HTTP コール、ナレッジベース検索などのノードを組み合わせることで、イベントドリブンな自動化システムを構築できます。
例：
営業リード処理
フォーム送信後、LLM がリードの品質を評価して分類します。
高品質なリードは Slack への通知と CRM への登録を行い、併せて背景調査を実施します。
中程度のリードは育成キューに追加し、低品質のものは自動的に配信停止（購読解除）します。
コードレビュー支援
GitHub に Pull Request が作成されると、変更されたファイルを解析し、関連する設計ドキュメントを検索します。
その結果を基に LLM がレビューの要点を生成して返信します。
API 仕様に変更が含まれる場合は、ドキュメントを自動更新し、技術文書チームへ通知します。
サービス監視と自動復旧
5 分ごとにサービスのヘルスチェックを実行し、異常が検知された場合はエラーの種類を分析します。
既知の問題であれば修復スクリプトを自動実行し、未知の問題であればオンコール担当者へエスカレーションします。
併せて、発生内容をドキュメントシステムに記録します。
クイックスタート：GitHub PR インテリジェントアシスタント
コードレビューを例に、3 つのノードで簡潔なフローを構築できます。
流れ：リポジトリが新規 PR を検知 → 変更を分析 → 要点を Slack に通知。
1. プラグイントリガーを設定
「ブロックを追加」→「始める」→ GitHub トリガーのプルリクエスト（統合） を選択 → 「＋新しいサブスクリプション」 → 監視したいリポジトリを選ぶ。
プルリクエスト（統合） トリガーは PR のライフサイクル（作成、更新、クローズ、マージなど）に対応。
右側パネルでは、どの PR がこのワークフローを起動するかを細かく設定可能。
イベントタイプ（opened、synchronize）やブランチ、作者、ドラフトフラグ、規模などでの絞り込みもできます。
設定例：
main ブランチ向けの非 draft PR を、作成・更新・commit push・クローズ時に起動。
2. LLM で分析
LLM ノードを追加し、トリガーの出力（action / pull_request / repository / sender）をもとに、今回の PR の内容を要約し、レビュー観点を生成します。
構造化データからタイトル、説明、ブランチ、作者などを抽出し、変更点やリスクを自動で整理します。
3. Slack へ通知
Slack ノードを追加し、LLM 出力をメッセージ本文として送信。
Incoming Webhook URL を設定し、content フィールドに LLM の出力を指定するだけです。
PR 作成後数秒で、Slack に結果が送られます。
まとめ
トリガーにより、ワークフローは「呼び出されて実行されるもの」から「イベントに応じて自律的に動くもの」へと進化しました。
外部環境の変化を感知し、能動的に振る舞うエージェント的な特性を備えたことになります。
今後は、さらに多様なイベントタイプ・プラグインを拡充し、human-in-the-loop による「重要箇所で人間の確認を挟む」実行制御も導入予定です。
既に Dify を活用して自動化を進めている方は、まずは簡単なシナリオからトリガーを試してみてください。各所に散在していた起動ロジックをオーケストレーション層に統合し、イベントドリブンワークフローの効果を実感できるはずです。