【Dify解説】Dify v1.10.0-rc1リリース ─ イベント駆動型ワークフローを可能にする新トリガー機能の全貌

2025年11月4日

運営会社：合同会社サステックス

元Microsoftエンジニアが立ち上げたAI・システム開発に特化したテクノロジーカンパニー。
機械学習や生成AIを活用したPoC開発や業務効率化、プロダクト構築を支援。
累計200件以上のAI開発・技術支援の実績があり、伴走型支援が強み。

サステックスのエンジニア、鈴木です。

2025年10月30日、オープンソースのAIノーコードアプリ開発プラットフォーム「Dify」の最新バージョンとなる v1.10.0-rc1 がリリースされました。先日2.0.0-beta版が登場したものの、今回の1.10.0（リリース候補版）は1.x系のアップデートとして位置づけられており、そのリリース名 “Event-Driven Workflows” が示す通りイベント駆動型のワークフロー実行を可能にする「トリガー」機能が大きな目玉となっています。このトリガー機能はコミュニティでも以前から要望が高く、先に正式リリースされたナレッジパイプライン機能（Dify 1.9.0で導入）と並ぶ今年注目のアップデートとされています。

前回のアップデートに関しては、こちらの記事も参考にしてください。

Difyとは?

DifyはChatGPTやClaudeなど複数のLLM（大規模言語モデル）を用いたAIアプリをプログラミング不要で構築できるオープンソースの次世代AI開発プラットフォームです。社内チャットボットやFAQシステム、社内データを活用した検索ツールなどエンジニアでなくとも簡単に作成できる点が特徴で、急速にコミュニティの支持を集めています（2025年6月にはGitHubスター数10万を突破し、記事執筆時点で約118kに達しています）。

2025年前半までのアップデートではワークフロー機能の正式実装やRAG（Retrieval Augmented Generation）強化、プラグインSDK公開による外部サービス連携の充実、AIエージェントの自律性向上などが次々と行われました。直近のリリースでは、1.7.0（2025年7月）でOAuth2.0連携やプラグイン自動アップデートといった企業利用を見据えた機能が追加され、1.8.0（8月）ではマルチモデル対応やUI改善が進み、現場での運用性が高まりました。そして1.9.0（9月）では「知識のオーケストレーション（ナレッジパイプライン）」と「ワークフロー実行エンジン刷新（キュー駆動型グラフエンジン）」という二本柱による大規模アップデートが実現し、企業向けRAG開発や複雑なワークフロー構築の基盤が強化されています。

この流れを受け、2025年秋に登場した v1.10.0-rc1 は「イベントドリブンなワークフローの実現」をテーマとしたアップデートとなっています。具体的には、新機能「トリガー」によって時間スケジュールや外部サービス上のイベントを契機にDify内のワークフローを自動実行できるようになりました。加えて、トリガー導入に伴うワークフローUIの改善やテスト実行機能の強化など、開発者の体験を向上させる様々な改良も含まれています。以下、Dify v1.10.0で追加された機能・アップデート内容を詳しく解説します。

Dify v1.10.0-rc1 アップデートの概要

Dify v1.10.0-rc1では、新機能であるトリガー（Trigger）の導入により、ワークフローをイベント駆動型で実行できるようになりました。これにより、スケジュール（日時）・Webhook・外部SaaS連携（Slackなど）といった様々なトリガー条件を設定し、「When something happens → then do something」をDify上で完結させることが可能になります。

企業システムにおいて、決まった時刻での処理実行や他システムからのイベント通知をきっかけにAI処理を走らせたいニーズに応える強力な機能です。また、トリガー機能追加に伴いワークフロー編集画面のUI改善やテスト実行機能の強化などのアップデートも行われ、複雑なフロー開発やデバッグがより快適になっています。以下で主な新機能と改良点を順に見ていきましょう。

トリガー機能 ─ イベント駆動型ワークフローの実現

機能概要

トリガー機能とは、特定のイベント発生をきっかけに自動でワークフローを開始できるDifyの新機能です。「何かが起きたら → 何かをする」という自動化ルールを、これまでの手動実行に代えて組み込めるようになります。対応するイベントとして、現在は次の3種類が用意されています。

スケジュール（時間間隔・日時）: 指定した日時や間隔で定期実行
Webhook（外部からのHTTPコール）: 特定のURLへのリクエスト受信をトリガーに実行
SaaS連携イベント: 外部のSaaS（SlackやGitHub、Linearなど）上のイベント発生を契機に実行

従来のワークフローはユーザーの入力や開発者の手動操作で開始していましたが、トリガー機能の導入により時間や他システムのイベントに反応して自律的にワークフローを走らせることが可能となりました。
細かな技術的視点ですが、この設計変更に伴い、ワークフローの開始ノード（Start node）が再定義されています。
Difyでは従来、Canvas上の開始ノードから処理を手動で起動していましたが、トリガー導入後は開始ノード自体が上記イベント種別に紐づいた「トリガーノード」として機能します。各トリガーはそれぞれ入力パラメータ形式が異なり（Webhookなら自由なペイロード形式、プラグイン/SaaSならサービス固有の構造、スケジュールなら実行時刻のみ等）、ワークフロー開始時に受け取るデータ形式もトリガー種別ごとに最適化されています。
ただし、トリガー機能は現状ワークフロー機能専用であり、ChatflowやAgent、Basic Chatには適用されないので、その点は気をつけてください。

主なトリガーの種類と動作

スケジュールトリガー（時間指定実行）

スケジュールトリガーは、指定したスケジュールに従ってワークフローを定期実行する機能です。実行間隔は「N時間毎・日次・週次・月次」から選択するか、Cron形式で細かく指定できます。一度設定すれば、後述するDify内部のスケジューラコンテナによって指定時刻に自動でワークフローが開始されます。スケジュール管理はDify v1.7.0から導入された worker_beat コンテナ（内部ではCelery Beatを利用）によって行われており、外部サービスに依存しない組み込み機能として動作します。そのため追加のプラグインや外部接続は不要で、Difyだけで完結して利用できる手軽さと強力さがあります。

例えば「毎日夜間に最新データでレポート生成し、朝に結果を通知」といった定時バッチ処理も、この機能を使えばDify内で自動化可能です。実際、弊社で以前毎朝決まった時刻にAIニュースを自動配信するLINEボットをDify×Google Apps Scriptで構築するケースを紹介しましたが、スケジュールトリガーの登場によりこうした定時実行のトリガーを外部サービスに頼らずDifyだけで完結できるようになります。定例ジョブのために別途サーバーやスクリプトを用意する手間が減り、よりシンプルに運用できるのは嬉しいポイントです。

Webhookトリガー（外部リクエスト受信）

Webhookトリガーは、Difyが発行する専用URLへのHTTPリクエスト受信をきっかけにワークフローを実行する機能です。Canvas上でWebhookトリガーを設定すると、ワークフローの開始ノードごとにユニークなエンドポイントURLが生成されます。このURLに対して外部から POST 等のリクエストを送ると、そのワークフローが自動的に開始され後続の処理が実行される仕組みです。WebhookトリガーもDifyに標準搭載された機能であり、追加プラグインは不要です。つまり任意の外部システムからDifyの特定ワークフローを呼び出すAPIとして機能するため、用途に応じて柔軟な連携が可能になります。

Webhook送信元（外部システム）からDifyのURLにアクセスできさえすればよいため、社内ネットワーク内で閉じた運用も比較的容易です。例えば社内システムからHTTPリクエストを発行してDify上のAI処理を呼び出す、といった使い方もシンプルに実現できます。curlコマンドやWebhooks対応サービスを使って手軽にテストできるのも利点でしょう。注意点としては、Difyを社内サーバーにセルフホストしている場合、Webhookを受信するにはそのサーバーがリクエスト送信元から到達可能である必要があることです（例えば企業内ネットワーク内だけで閉じている場合、外部のSaaSからは直接アクセスできません）。もっとも、これは次項のSaaS連携トリガーよりハードルが低く、多くのケースで問題なく利用できるはずです。

SaaS連携トリガー（外部サービスのイベント連動）

SaaS連携トリガーは、SlackやGitHub、Gmailなど外部SaaS上で発生したイベントを契機にワークフローを実行できる機能です。これは単体で動作するスケジュール/Webhookトリガーとは異なり、サービス毎に専用のプラグインをDifyにインストールすることで実現します。各プラグインに応じて、Dify上で「購読（Subscription）」したい外部イベントを選択・設定すると、そのSubscriptionごとに一意のWebhook URLが発行されます。このURLを対象SaaS側のWebhook送信機能に登録しておくことで、該当イベント発生時にSaaS→DifyへHTTPリクエストが飛び、Dify内でワークフローがトリガされる仕組みです。例えば「Gmailで新メール受信→Difyワークフローで内容要約」「GitHubでプルリク作成→自動レビューを実行」といった高度な自動化が可能になります。

SaaS連携トリガーは非常に強力ですが、性質上セルフホスト環境で使うには注意が必要です。
基本的に「外部SaaSからDify宛てにHTTPでイベントを飛ばしてもらう」必要があるため、Dify側をインターネットからアクセス可能に公開する（かつ正規のSSL証明書付きのHTTPSエンドポイントにする）必要があります。加えて、各SaaS固有の認証プロセス（OAuth連携など）も伴うため、オンプレミス環境ではネットワークとセキュリティポリシー両面でハードルがあるケースも考えられます。実際、現時点（v1.10.0-rc1）では公式のトリガー対応プラグインはまだ少なく、自分でプラグインをソースコードからビルドして導入する必要がある場面もあります。これらの点からセルフホストでSaaS連携トリガーを利用する際は、環境構築（ドメイン公開やSSL設定、プラグインビルド）に手間がかかることを念頭に置くべきでしょう。一方でDifyのクラウド版や公開環境で運用している場合は特別な設定をせずとも利用しやすく、比較的手軽にSaaS連携の恩恵を受けられます。いずれにせよ、ハードルはあるもののうまく活用できれば社内外のサービス連携をシームレスに自動化できる非常に強力な機能であることは間違いありません。

トリガー機能がもたらすメリットと背景

トリガー機能の導入によって、Difyは「待ち受け型」の自動実行シナリオを包括的にサポートするようになりました。これは企業システムの現場において多くのメリットをもたらします。

まず第一に、対応可能なユースケースの拡大です。例えば、これまではDiscordのサポートチケットを受けてLinearに記録するようなワークフローを構築する場合、Dify外部でカスタムの連携コードを書いたり外部RPAツールを組み合わせたりする必要がありました。同様にPull Request発生時の自動AIレビューや特定メール到着時の自動応答といったシナリオも、従来はDifyから独立した手段で「トリガー部分」を実装する必要があり、煩雑でした。トリガー機能により、こうした外部イベント起点の処理をすべてDifyプラットフォーム内で完結できるようになるため、対応できるシナリオの幅が飛躍的に広がります。

第二に、システム構成の簡素化と一元管理です。従来、Difyで実現したい自動処理があっても、時間やイベントで起動する仕掛け自体はAirflowやZapier、n8n等の外部オーケストレーションツールに頼るケースがありました。しかしその場合、AIワークフロー部分（Dify）とイベントトリガー部分（外部サービス）が分散してしまい、設定管理が分散・断片化するという課題がありました。トリガー機能でイベント発火からLLM処理まで一貫してDify上で構築できるようになったことで、設定・認証情報・ログなどをDifyに集約でき、運用管理がシンプルになります。特に外部サービスのOAuth認証やWebhook設定も含めDify側で完結できれば、複数のサービスにまたがる設定変更の手間や連携ミスが減り、運用負荷やエラーリスクの低減につながります。

第三に、リアルタイム性や能動的な働きかけが可能になる点も見逃せません。従来の問い合わせ対応型（ユーザーが質問して初めてAIが回答）のチャットボット運用から一歩進み、AIがスケジュールやイベントに応じて主体的に情報提供や処理実行を行うことができます。定時レポートの自動配信、システム監視アラートへの自動応答、顧客行動トリガーによるレコメンデーション実行など、「待ち」のAIから「攻め」のAI活用への幅を広げられるでしょう。

最後に、コミュニティからの強い要望に応えた機能強化である点も重要です。実際、トリガー機能はDifyユーザーフォーラムやGitHub issue上でもたびたびリクエストが寄せられていた機能で、今回満を持して実装されました。
この背景には、現場の開発者が感じていた「あと一歩自動化できれば便利なのに…」という痒い所に手が届く改善をDifyチームが重視したことがあります。筆者自身、クライアント企業へのDify導入支援の中で「社内の〇〇システムと連動して動いてほしい」といった相談を何度も受けてきました。その度にカスタムスクリプトや他サービスとの併用で対処してきましたが、トリガー機能の登場によって今後はDify単体でよりスマートに解決できると期待しています。まさに「現場の声」から生まれたアップデートと言えるでしょう。

使ってみた感想と活用例

筆者も早速v1.10.0-rc1を試し、いくつかトリガー機能の動作検証を行ってみました。まずスケジュールトリガーについては、UI上で時間間隔やCron表記を設定するだけで実行スケジュールを組め、非常に簡単に使い始められました。例えば毎日深夜に社内データを集計し朝に結果をメール送信するワークフローを設定してみたところ、Difyを起動しておくだけで時間通りに処理が走り、無事に結果が出力されました。これまでであればcronや別サービスでトリガーを設定してDifyのAPIを呼ぶ…といった手間が必要でしたが、その分の労力がゼロになるのは非常にありがたいと感じます。

Webhookトリガーについては、発行されたURLに対して手元のターミナルからcurlコマンドでリクエストを送る簡単なテストを行いました。結果は即座にDify上の該当ワークフローが開始し、想定通り後続のノード（LLM応答生成など）が実行されました。Webhookリクエストに含めたペイロードデータ（JSON形式）も問題なくワークフロー内の入力として渡せており、外部システム→Difyへのデータ受け渡しもスムーズです。「特定システムでエラー発生時にDifyが自動で社内チャットに通知」など、Webhook連携で考えられるユースケースは多いですが、その実装ハードルがぐっと下がると実感しました。社内ネットワーク内だけで閉じる場合でも、例えばオンプレミスのNagios（監視システム）のアラート用スクリプトからDifyのWebhookを叩くように修正すれば、容易にLLMによるアラート要約＋通知が実現できそうです。「Webhookを一本仕込むだけで既存システムにAIエージェントの知能を付加できる」のは非常に魅力的でしょう。

SaaS連携トリガーに関しては、GitHubのプルリクエストイベントをトリガーにして自動レビューを行うシナリオを試してみたいと考えました。ちょうどGitHub連携プラグインは公式から提供されていたため（SlackやGoogle向けは現時点では未提供）、それを使ってpull_requestイベント受信→レビュー内容を要約してコメント投稿するフローを構築することにしました。セットアップ自体は、GitHubのPersonal Access Tokenを取得してDify上に設定し、Subscriptionとしてpull_requestイベントを選択するだけで済みました。トリガー発火用のWebhook URLも自動生成されるので、それをGitHubリポジトリのWebhooks設定に登録します。
結果、リポジトリでPRが作成されるたびにDifyが反応し、内容要約と所見を自動コメントしてくれる仕組みが動き始めました。多少のラグはありますが、Devinを使わなくても、Dify上でもAIがレビューを行ってくれるようになっています。社内のコードレビュー負荷軽減やナレッジ共有にもつながる有用な例ではないかと思います。今回利用したGitHubプラグインは比較的スムーズに導入できましたが、他のSaaS（例えばGmail受信トリガーなど）を使いたい場合は現時点でプラグイン自作が必要なため、ハードルは高めだと感じました。
その場合は開発者向けドキュメントを参照しつつプラグイン開発〜インストールを行う流れになります。幸いDifyにはプラグインSDKやCLIツールが用意されており、サンプルコードも提供され始めているので、コミュニティ発のプラグインが今後充実していけばより簡単になるでしょう。

その他の改善点（UI/UXとデバッグ機能の強化）

v1.10.0ではトリガー以外にも、開発者に嬉しい細かな改善が多数含まれています。
その中でも特に注目すべきポイントをいくつか紹介します。

ワークフローエディタのUI改善

ワークフロー編集画面で選択中のノードにスクロール移動するボタンが追加されました。大規模なCanvasでノードを見失った際もワンクリックで現在の選択箇所にフォーカスでき、編集作業のストレスが軽減します。また、以前は画面右上にあった「Workflow Features（ベータ機能ON/OFF）」ボタンが削除され、UIがスッキリしました。機能自体の統廃合によるものですが、ユーザーに迷わせる要素が減ったのは好印象です。

テスト実行（Test Run）機能の強化

ワークフローを手動実行する際の「Run」ボタンが「Test Run」ボタンに変更され、キーボードショートカット（⌨️）でも実行できるようになりました。さらにTest Run専用のドロップダウンメニューが設けられ、任意のトリガーを選択してテスト実行することが可能です。例えばスケジュールトリガー付きのフローであれば「今すぐテスト実行」、Webhookトリガーであればテスト用のペイロードを指定して実行、といった使い分けができ、様々なトリガー条件を開発時にシミュレートしやすくなりました。特にトリガーは従来の手動実行と異なり発火条件を待たねばならないため、開発段階での挙動確認が難しい懸念がありましたが、この改善によって容易にデバッグできます。

スケジュール設定UIの拡張

スケジュールトリガーの詳細設定として、月次トリガーの複数日選択やタイムゾーン対応などUI上で細かな指定ができるようになりました。特定の曜日を複数指定した毎週実行や、複数日付にまたがる月次実行など柔軟なスケジュールが組めます。UIの表記ゆれ修正やアイコン追加など、細部の改善も施されており、全体的に使い勝手が洗練されています。

その他の不具合修正

このリリースでは他にも、トリガー機能開発に伴うバグ修正やパフォーマンス改善が多数含まれています。例えば「毎時実行の計算ロジックの修正」や「多重スタートノード構成でのバリデーション強化」、「i18nファイルの重複キー削除による翻訳改善」など、細かい点ではありますが安定性と品質が向上しています。全体としてv1.10.0は新機能だけでなく既存機能の磨き込みも進んだリリースと言えるでしょう。

なお、セルフホスト版で本バージョンにアップグレードする場合、基本的な手順は従来と同様です。Docker Compose環境ではアップデート前に必ず docker compose down でサービスを停止し、重要なボリュームデータをバックアップしてから docker compose up -d で最新イメージに切り替えてください。その後、必要に応じてuv run flask db upgradeコマンドでデータベースのマイグレーションを適用します。v1.9.0からの更新であれば大きな移行スクリプトはありませんが、もし0.x系や初期1.x系から直接アップグレードする場合は1.9.0時点で要求されたデータソース認証情報の変換（uv run flask transform-datasource-credentialsの実行）を事前に行っておく必要がある点に留意してください。

今後の展望とまとめ

今回のDify v1.10.0-rc1リリースにより、イベントドリブンな自動実行が公式にサポートされたことで、Difyは社内外のあらゆるイベントとAI処理をシームレスに繋ぐプラットフォームへと大きく前進しました。昨今のエンタープライズAI活用において、「タイミング良く適切な情報を提供する」「異なるシステム間をまたいで自動で処理を回す」といった要件はますます増えています。トリガー機能はまさにそうした現場のニーズに応える切り札となり得るでしょう。

Dify v1.10.0は現時点ではRC版（リリース候補）ですが、近く正式版も公開されるでしょう。本記事で紹介した新機能を一足先に試してみて、業務課題にどう活用できるか検証してみる価値は大いにあります。ナレッジパイプラインによる社内データ活用や強化されたワークフローエンジンと組み合わせれば、社内チャットボットから他システム連携まで統合的にこなす強力なAIソリューションが実現可能です。アップデートに伴う移行手順（バックアップや環境変数設定の見直しなど）には注意が必要ですが、それを踏まえても導入するメリットは大きいでしょう。