著者：Evan Chen（プロダクトマネジャー）
Dify Blog 掲載ページ：Attention, Hijacked by 100 SaaS Tools

手動クリックに頼るのではなく、今や我々はイベントを購読する。

毎朝10時、オフィスに満ちるのは音楽ではない。満ちているのは通知音だ。

Slackの@メンションが顧客フィードバックの更新を求め、Notionがデイリーレポートを思い出させてくる。

あらゆるクリック、あらゆるコンテキストスイッチ、あらゆるログインが、気付かないうちにあなたの注意力の予算を削っていく。

Backlinkoの統計によると、2024年時点で平均的な企業は112個のSaaSツールを維持している。
より小規模な企業（従業員200人未満）でも約42個のツールをやりくりしており、大企業になると一度に扱うソリューションは最大158個にものぼる。

ツールが増えれば増えるほど、クリックも増える。私たちは自分自身がエージェントのように、イベントに機械的に反応しながら、どれか1つを実際に終わらせることにも苦労するようになる。

想像してみてほしい：

営業メールを受け取り、「興味なし」と判断して手動でアーカイブする
商品が「在庫復活」するのを待ち、毎日ページをリロードする
Redditで業界スレッドを探し、リンクをコピーし、要点をまとめ、それをレポートに貼り付ける

これらはすべて自動化できる。それなのに私たちは、情報を自分の注意力でひとつずつ運んでいる。日々イベントを待ち続けているのに、そのイベントに自動で反応してくれる仕組みがない。

必要なのは新しいアプリではなく、新しい働き方なのかもしれない。何かが起きたとき、自動的にエージェントが動くという働き方だ。

イベントの洪水を生き抜くために必要なのは、もっと多くのソフトウェアではなく、もっと賢いつながりだ。

仕事は注意力に依存すべきではない。イベントに依存すべきだ。

それこそが、トリガーが設計の中心に置いている考え方だ。これは不安を減らすためのデザインでもある。あらゆる「開始」を「自分で覚えてクリックする」行為から、「イベントが起きてプロセスが進む」形へ変えてくれる。

もう「自分で在庫を確認しに行く」のではなく、「在庫がOut of Stockに切り替わったら自動で通知してくれればいい」
もう「自分で手動でリードを仕分ける」のではなく、「メールに返信が来たら、エージェントが意図を判断し、ルールに基づいて次のステップを実行する」

何が重要かを決め、ルールを定義するのは人間だ。
イベントの監視、コンテキストの保持、手順の遂行といった作業は、エージェントに任せられる。

二種類の開始ノード：ユーザー入力とトリガー

Difyのワークフローアプリには、開始ノードが2種類ある：ユーザー入力とトリガーだ。

ユーザー入力：従来の「開始」ノード。ワークフローが必要とする入力変数を定義する。関数のパラメータリストのようなものだ。UIでパラメータを入力して実行することもできるし、後からMCPサーバーツールとして公開し、他システムから呼び出せるようにすることもできる。

トリガー：もう1つの開始ノードで、イベントを起点として動き出すエントリーポイントだ。「run」をクリックしてくれるのを待つのではない。外部世界の変化を購読し、条件が整った瞬間、ワークフロー全体を自動で立ち上げる。

三種類のトリガー：スケジュールトリガー、Webhookトリガー、プラグイントリガー

Difyのトリガーには、スケジュールトリガー、Webhookトリガー、プラグイントリガーがある。ざっくり言えば、時間で購読するか、Webhookイベントで購読するか、プラグインイベントで購読するかの3種類だ。

スケジュールトリガー：時間で購読する
定期的なチェックや繰り返しタスクには、スケジュールトリガーが最適だ。例えば：

GoogleSheetのデータを定期的に読み込み、2つのターゲットシートへ書き込んでデータを分配し、複数のテーブルを同期させる
5分ごとに特定のWebサイトのステータスコードを確認し、もし200でなければ、即座に指定のSlackチャンネルへアラートを送る

これまで人間が「run」をクリックするのを覚えておく必要があったタスクも、トリガーに一度時間ルールを設定するだけでよくなる。その後はバックグラウンドで静かに実行され続ける。

Webhookトリガー：コールバックイベントで購読する

Webhookトリガーは、外部システム内の特定のイベントとワークフローを結びつける。作成すると、システムはコールバックURLを発行する。外部システムがこのURLにリクエストを送ってくるタイミング――たとえば「顧客が支払いを完了した」「誰かがフォームを送信した」「新しいリードがデータベースに書き込まれた」など――で、ワークフロー全体を起動できる。

クエリパラメータやリクエストヘッダーを自由にカスタマイズでき、実際の業務データを渡すことも可能だ。受け取ったデータは後続ノードで解析し、そのまま活用できる。

プラグイントリガー：プラグインイベントで購読する

プラグイントリガーは、Gmailで新しいメールを受信した、Notionで新しいページが作成された、タスクのステータスがDoneに変更された――といったサードパーティアプリ内部のイベントを購読するために使われる。

一般的に利用されているSaaSツール向けのプラグインはすでに用意されている。Dify側で自分のアカウントを認可するだけで、そのまま購読を作成できる。

同じワークフローの中で、異なるイベントに対して複数のルートノードを作ることも可能だ。EventFilterと組み合わせれば、自分が必要とするイベントだけを残し、不要なノイズはすべて遮断できる。

スケジュールトリガーとWebhookトリガーは、Difyで標準機能としてすぐに使える。

一方、プラグイントリガーを使うには、対応するプラグインを先にインストールする必要がある。Dify Marketplace にアクセスすれば、ワンクリックでインストールできる。

もし必要なプラグインがまだ見つからない場合は、dify-plugins の GitHub リポジトリで Issue を立てるか、仕様に従って自分でプラグインを開発し、チーム全体で再利用することもできる。

または、プラグイン開発用のドキュメントをご参照ください。

Agentsではなく不安を減らす仕組みとして：トリガーが“開始”を再定義する

Zapierはシステム同士をつなぐ点では優秀だが、ナレッジワーカーはいまだにツール間を行き来しながら、「いつフローを起動するか」「イベントをどう分類するか」「どれをエスカレーションすべきか」といった判断を自分で行っている。
つまり接続の問題は解決しても、判断の問題は人間に残ったままなのだ。多くの状態変化は、今でも人が画面を見つめて手順を実行することで成り立っている。

トリガー＋エージェントは、その機械的な意思決定まで引き受けるための設計になっている。イベントが発生した瞬間、システムがあなたの定義したルールに基づいてルーティングし、処理し、記録する。
人間が介入するのは、本当に判断が必要な場面だけだ。

クリックから購読へ —— 4つのシナリオ：

シナリオ	課題	以前（手動）	現在（トリガー）	主要な価値
1. Webページのステータス監視 → Discord通知ルーティング	「在庫切れかどうか」を確認するために手動でページを更新するのは注意力を消耗し、重要な瞬間も見逃す。	5〜10の販売ページを開き、1つずつ更新し、ステータスをコピーしてグループチャットに貼り付ける。	URLをルールで購読 → 「在庫あり/在庫なし」を自動解析 → Discordのチャンネル（赤/緑、リンク、価格、タイムスタンプ付き）に自動投稿。	① 中断ゼロの自動化 ② 在庫状況別のスマートルーティング ③ 後から見返せる監査可能な履歴
2. GoogleMapsのビジネススクレイピング → メール抽出/準拠リスト生成	手動でメールをコピーすると遅く、重複やノイズが多い。	手作業で検索 → コピー&ペースト → 手動で重複排除。	地域/キーワード条件で定期クロール → ビジネスページを自動スクレイピング → メール/電話/サイトを抽出 → 重複排除&スコアリング → CSV/CRMへエクスポート。	① 調達時間を約90%削減 ② メール品質スコアリング ③ CRMへワンクリック同期
3. Reddit検索 → LLMによる分類と要約	スレッドを読み、要点を抜き出す作業は反復的で時間がかかる。	手動で投稿検索 → スレッドを読み取る → 結論をコピー。	キーワード購読 → 投稿をストアに自動取り込み → モデルで分類（肯定/否定/質問/トレンド）→ 日次要約を生成しSlack/Notionに配信。	① 日次サマリーを定時で取得 ② ノイズ削減とシグナル抽出 ③ 元投稿へのリンクで追跡可能
4. 営業メール返信のトリアージ → 自動フォローアップ（音声連絡含む）	意図判断・転送・フォローアップを手動で行うため遅延や取りこぼしが発生する。	人がメールを読み → ラベル付け → 転送 → 手動フォローアップ。	メールイベントでトリガー → 分類（興味あり/興味なし/追加情報必要）→ 自動アクション（Slack通知/購読解除/タスク作成）。	① 興味あるリードの取りこぼしゼロ ② 営業の反復作業削減 ③ 個別化された追跡可能なフォローアップ

トリガーによって、Dify Workflow と Dify Agent はさらに強化される。自動化は「データフロー」から「イベントフロー」へ移行し、エージェントは外界に非同期で反応する能力を獲得する。

以前は、エージェントを本番環境に投入するには多くの手作業が必要だった。エージェント自体はタスクを実行できても、各トリガーは依然として人が手動でメンションすることに依存していた。たとえば、異なるタイプの問題を処理するエージェントAとエージェントBがいて、今後数十件の通知が来ると分かっていたとしても、そのたびに誰かが創造的な仕事を中断し、繰り返されるトリアージとルーティングに戻らなければならなかった。注意力は常に分断され続ける。

今では、Dify Agent と今後登場する Human in the loop ノードを組み合わせれば、これらの判断を事前にコード化できる。エージェントは継続的に監視し行動し、人間の入力は重要な判断ポイントで短時間介入するだけでよくなる。

仕事は予測可能になり、設定可能になり、委任可能になる――人間はもはや個々の通知に振り回されず、イベントによって動けるようになる。

今後のバージョンでも、さらに多くのトリガータイプと Human in the loop ノードを追加していく予定だ。関心のあるイベントに適したトリガーを選び、最初のイベント駆動型ワークフローを構築しよう。そうすれば、100ものSaaSツールに分散してしまっている注意力を解放できる。

Learn More

トリガーはすでに1.10.0のコミュニティ版で利用可能だ。変更履歴やインストール手順はGitHubで確認できる。クラウド版もまもなく提供予定なので、続報を待ってほしい。

バージョン1.10以降、各トリガーは異なるブランチの開始ノードとして配置できるようになった。つまり、1つのキャンバス上で複数の相互関連するブランチを作成し、複数のイベントに応答できるようになるということだ。同時に、トリガー専用のリスニングベースのデバッグ手法も導入した。これにより、トリガーのデバッグが容易になり、その出力を下流ノードに直接適用しやすくなる。詳細は「デバッグドキュメント」を参照してほしい。

プラグイントリガーを使うには、事前にサブスクリプションを設定する必要がある。詳しくは「サブスクリプション作成ドキュメント」をご参照してください。