Cronスケジュールとwebhookは基本をカバーします。毎朝8時にこのrecipeを実行する。サードパーティシステムがPOSTリクエストを送信したときにこのworkflowを起動する。多くのユースケースに対応できます。
しかし、真の自動化は起こっていることに反応する必要があります——workflowの完了、メールの到着、接続されたツールでのデータ変更、Webページ上の特定の要素の出現。タイマーでポーリングしてイベントを捕捉することを期待するのは無駄で遅いです。相手側がwebhookをセットアップしてくれることを待つのは、相手側がwebhookをサポートしていることを前提としています。
JieGouは既存のcronおよびwebhookオプションを補完する4つのイベント駆動トリガータイプをサポートするようになりました。各タイプは特定の種類のイベントを監視し、発生時にrecipeまたはworkflowを起動します。
トリガーの全体像
JieGouは2つのカテゴリにわたる7つのトリガータイプをサポートしています：
| トリガー | モデル | レート制限 | ユースケース |
|---|---|---|---|
| Cronスケジュール | タイマー | N/A | 毎時、毎日午前9時など |
| Webhook | プッシュ | トリガーあたり12/分 | 外部システムがHTTP POSTを送信 |
| 実行完了 | プッシュ | トリガーあたり6/分、アカウントあたり30/分 | recipe/workflowを連鎖 |
| コネクタ変更 | ポーリング（60秒〜24時間） | ポーリング間隔あたり | CRM、スプレッドシート、データベースの変更に反応 |
| メール受信 | ポーリング（デフォルト300秒） | サイクルあたり5メッセージ | 受信メールがトリアージをトリガー |
| Slackメッセージ | プッシュ | Slack Events APIあたり | チャネルメッセージが抽出をトリガー |
| ブラウザイベント | プッシュ | ユーザーあたり20/分 | DOM変更が調査をトリガー |
Cronとwebhookトリガーはすべてのプランでご利用いただけます。4つの新しいイベント駆動トリガーはProプラン以上でご利用いただけます。
実行完了チェーン
タイプ：run_completed | **モデル：**インプロセスイベントバスによるプッシュベース
最も一般的な自動化パターンは「Xが完了したらYを開始する」です。要約recipeが完了したら配信workflowを開始すべき。データエンリッチメントworkflowが完了したらスコアリングrecipeを結果に対して実行すべき。
実行完了チェーンはポーリングゼロでこれを処理します。インプロセスイベントバスを使用しています——実行が完了すると、次のポーリングサイクルではなく即座にイベントが発火します。
設定オプション：
- **監視対象：**特定のrecipe、特定のworkflow、または「このアカウント内の任意の実行」
- **ステータスフィルター：**成功のみ、エラーのみ、または両方でトリガー
- **出力マッピング：**完了した実行のペイロードからデータを抽出する3つのモード
3つの出力マッピングモードにより、トリガーされた実行に流れるデータを制御できます：
- Passthrough — イベントペイロード全体が入力になります。下流のrecipeがフルコンテキストを期待する場合に便利。
- フィールドマッピング — ドットパス表記（例：
event.output.summaryがsummary入力フィールドにマッピング）を使用して特定のフィールドを抽出。 - テンプレート — より複雑な変換のためにネストされたパスサポート付きの
{{variable}}置換を使用。
レート制限はトリガーあたり毎分6回で、webhookレートの毎分12回の意図的に半分です。これにより、トリガーのチェーンが数百の同時実行に増幅するカスケードストームを防ぎます。アカウント全体の毎分30回の上限が追加のバックストップを提供します。
**パイプラインの例：**コンテンツ作成recipeがブログ下書きを生成。成功すると配信workflowがトリガーされ、ソーシャルチャネルに投稿しメール送信をスケジュール。配信完了時にレポートrecipeがトリガーされ、エンゲージメントメトリクスを集約。3つのrecipe、完全に自動化、各段階がいつ終了するかを推測するcronスケジュールなし。
コネクタデータ変更検出
タイプ：connector_changed | **モデル：**Cloud Schedulerによるポーリングベース
すべてのシステムがデータ変更時にwebhookを送信するわけではありません。CRMレコードはサイレントに更新されます。スプレッドシートのセルは通知なしに変更されます。データベースの行はバックグラウンドジョブによって変更されます。
コネクタ変更検出は設定可能な間隔（60秒から24時間）で接続されたデータソースをポーリングし、データが実際に変更されたときに起動します。
変更検出の仕組み：
- 各ポーリングサイクルでコネクタから現在のデータを取得
- システムがレスポンスのSHA-256ハッシュを計算
- ハッシュが前回保存されたハッシュと比較される
- ハッシュが異なればトリガーが起動
セットアップ後の最初のポーリングはトリガーを起動せずにハッシュを保存します。これにより偽陽性を回避します——設定した瞬間に「データが何もないのと異なる」というだけですべてのトリガーが起動されることを望みません。
変更タイプフィルター：
- 任意の変更 — ハッシュされたデータの任意の違い
- 新規レコード — レコード数が増加した場合のみ起動
- 特定のフィールド変更 — 特定のフィールドを監視し、他の変更を無視
**例：**CRMコネクタが「リード」オブジェクトを監視。新しいリードが出現するか、既存のリードのステータスが「Qualified」に変わると、トリガーが3つのデータソースからリードをエンリッチし優先度スコアを割り当てるリードスコアリングworkflowを起動します。
メール受信
タイプ：email_received | **モデル：**Gmail OAuthによるポーリングベース
メールは驚くほど多くのビジネスプロセスのエントリーポイントとして残っています。サポートリクエスト、ベンダー請求書、アラート通知、承認レスポンス——すべて受信トレイに届きます。
メールトリガーはOAuth MCPツールを介してGmailと統合し、基準に一致する新しいメッセージをポーリングします。
設定：
- フィルタリング用のGmailクエリ構文——例：
from:alerts@example.com subject:urgentまたはlabel:support-inbox is:unread - **ポーリング間隔：**デフォルト300秒、設定可能
- **サイクルあたりの最大メッセージ数：**最大5（設定可能）——200件のメールのバックログが200の同時実行を生成することを防止
lastProcessedEmailIdによるウォーターマーク追跡——システムは最後に処理したメールを記憶するため、クエリに一致していても同じメッセージを再処理することはありません
例：label:support-inbox is:unreadに一致するサポートメールがトリアージworkflowをトリガー。workflowがカテゴリと緊急度で問題を分類し、関連するKB記事を使用してレスポンスを起草し、高優先度の問題をSlack経由でオンコールチームにルーティングします。
Slackメッセージ
タイプ：slack_message | **モデル：**Slack Events APIによるプッシュベース
一部のチームは運用全体をSlackで行います。ステータス更新、顧客エスカレーション、デプロイ通知、意思決定リクエスト——すべてチャネルで起こります。
SlackメッセージトリガーはSlack Events APIを使用してリアルタイムでメッセージを受信します。ポーリングなし、遅延なし。
フィルタリング：
- チャネルID — 必須。トリガーは1つの特定のチャネルを監視します。
- キーワードまたは正規表現パターン — オプション。パターンに一致するメッセージのみがトリガーを起動します。
- 自動ノイズフィルタリング — トリガーはボットメッセージ、メッセージ編集、システムメッセージを無視します。
subtypeなしのevent.type === 'message'をフィルタリングするため、本物の人間が書いたメッセージのみが得られます。
例：#action-itemsチャネルが1日を通じてメッセージを受け取ります。各メッセージが抽出recipeをトリガーし、アクションアイテムを特定し、@メンションに基づいてオーナーを割り当て、自然言語（「金曜日までに」）から期限を設定し、構造化されたサマリーを#action-trackerチャネルに投稿します。
ブラウザイベント監視
タイプ：browser_event | **モデル：**ブラウザ拡張機能によるプッシュベース
これは他とは異なります。サービスや受信トレイを監視する代わりに、ブラウザ自体で起こっていること——WebページのDOM——を監視します。
ブラウザ拡張機能がページの特定の条件を監視し、発生時にトリガーを起動します。5つのDOM条件タイプがサポートされています：
| 条件 | 監視対象 |
|---|---|
element_appears | CSSセレクタが以前なかった要素にマッチ |
element_disappears | 以前マッチした要素が削除される |
text_changes | マッチした要素のテキスト内容が変更される |
attribute_changes | マッチした要素の属性（class、data-*など）が変更される |
url_changes | ページURLが変更される（ワイルドカードパターンサポート） |
**例：**モニタリングダッシュボードがサービス劣化時に赤いアラートバナーを表示。トリガーが.alert-banner.criticalでのelement_appearsを監視。起動時にextractSelectorsを通じてアラートテキストと影響を受けたサービス名を抽出し、ログをクエリし、最近のデプロイを確認し、インシデントサマリーを起草する調査workflowをトリガーします。
提供状況
イベント駆動トリガー（実行完了、コネクタ変更、メール受信、Slackメッセージ、ブラウザイベント）はProプラン以上でご利用いただけます。Webhookとcronトリガーはすべてのプランでご利用いただけます。すべての機能を見るか、無料トライアルを開始する。