Zendeskのオートメーションスタックの正体
「Zendeskのオートメーション」という言葉を使うとき、人によって指しているものが3つのうちどれかであることがあります。Zendeskはこれらすべてを「ビジネスルール」と呼んでいますが、それぞれの動作の仕組みは全く異なります。
この3つはすべてAdmin Center > Objects and rules > Business rulesにあります。どれを使うべきかを決めるルールは、拍子抜けするほど単純です。
- 時間的な要素があるか？ オートメーションを使う。
- チケットが変更された瞬間に発火させたいか？ トリガーを使う。
- エージェントが手動で適用するか？ マクロを使う。
この区別を理解してしまえば、設定に関する疑問のほとんどは自然と解決します。
トリガー：イベントベースのルール
トリガーはこのシステムの主力です。チケットが作成または更新されるたびに、Zendeskはアクティブなすべてのトリガーを順番に実行し、条件をチェックして、条件が満たされたアクションを発火させます。Zendeskチケットステータスのライフサイクルはトリガーのロジックに直接関わってくるため、複雑なトリガーチェーンを構築する前にステータスの移り変わりを理解しておくことが重要です。
トリガーサイクルの仕組み
多くの管理者が十分に理解していない点があります。トリガーが発火してチケットを更新すると、サイクル全体が再スタートします。しかし、たった今発火したトリガー自身は再実行されません。先に実行されたトリガーが、後から実行されるトリガーがチェックする条件を作り出すことがあります。2つのトリガーが同じフィールド（例えば「担当者」）に同時に書き込むと、予測不能な結果になります。サイクルは、新たな更新が発生しないまますべてのトリガーが評価された時点で終了します。
事前に知っておくべき厳格な制限（Zendesk公式ドキュメントより）：
- 1アカウントあたり最大7,000件のアクティブなチケットトリガー
- 各トリガーは65KB未満である必要がある（条件とアクションのテキストを合わせて約65,000文字）
- トリガーはクローズ済みチケットでは実行されない - チケットがクローズに設定される瞬間には発火できるが、その後は発火しない
Zendeskが標準搭載しているもの
新規アカウントには、あらかじめ一連の標準トリガーが有効になっています。
| トリガー | 発火条件 |
|---|---|
| Notify requester of received request（リクエスト受信を依頼者に通知） | エンドユーザーによって新規チケットが作成されたとき |
| Notify requester of comment update（コメント更新を依頼者に通知） | 公開コメント付きでチケットが更新されたとき |
| Notify assignee of comment update（コメント更新を担当者に通知） | コメントが追加され、担当者が現在のユーザーでないとき |
| Notify assignee of assignment（アサインを担当者に通知） | 担当者が別の人に変更されたとき |
| Notify assignee of reopened ticket（再オープンされたチケットを担当者に通知） | 解決済みチケットが再オープンされたとき |
| Notify group of assignment（アサインをグループに通知） | グループのアサインが変更されたとき |
| Notify all agents of received request（リクエスト受信を全エージェントに通知） | 新規チケットが作成されたとき（5人を超えるチームでは無効化する価値があることが多い） |
「全エージェントに通知」トリガーは、ほとんどの管理者が最初に停止するトリガーです。数人を超えるチームでは受信ボックスがあふれてしまいます。2人体制のサポートチームでは害がありませんが、30人のチームでは大混乱を招きます。
トリガーの設定方法
- Admin CenterでObjects and rules > Business rules > Triggersに移動する
- Add triggerをクリックする
- わかりやすい名前を付ける -
Trigger 47よりRoute billing tickets to billing groupの方が良い - Meet ALL of the following conditionsの下に条件を追加する
- 必要であればMeet ANY of the following conditionsの下に「または」の条件を追加する
- Actionsの下に、条件が満たされたときの動作を定義する
- 保存する - トリガーは即座に有効になる
新しい管理者がつまずきがちな設定の細部があります。範囲を絞るために、必ずTicket | Is | CreatedまたはTicket | Is | Updatedの条件を追加してください。これを追加しないと、トリガーは条件を満たす作成イベントと更新イベントの両方で評価されるため、すでに処理したはずのチケットで予期しない再発火が起こります。
特定のトリガー設定に関する詳しいガイドはこちらです。チャネルごとにチケットを自動タグ付けする方法、トリガーアクションでカスタムフィールドを設定する方法、高度なルーティングのためのトリガー条件での正規表現の使い方、そしてトリガーによる内部メモの追加。
よくあるトリガーの使用例
ルーティングとアサイン：
- 特定のメールドメインからのチケットをVIPサポートグループにルーティングする
- Exploreレポート用にチャネルごとにチケットをタグ付けする
- 件名にキーワードが含まれるチケットを適切なチームにアサインする
通知：
- チケットに
urgentタグが付いたときにWebhookでSlackチャンネルに通知する - チケットの担当が変わったときに新しく割り当てられたエージェントに通知する -
Is CreatedではなくAssignee | Changed条件を使う - チケットのタイプがBugに設定されたときにJiraのイシュー作成を発火させる
ステータスワークフロー：
- 顧客フォローアップのシーケンスを開始するためにステータスがPendingに変わったときにトリガーを発火させる
- CSATサーベイをキューに入れるためにチケットが解決またはクローズされたときにトリガーを発火させる
- メールチャネル固有のルーティングのためのメールトリガーと通知
ルールセットが大きくなるにつれて、トリガーの実行順序を理解することが重要になります。どのトリガーが先に実行されるかによって、後続のトリガーがどの条件を見ることになるかが決まります。
オートメーション：時間ベースのルール
オートメーションは、ほとんどのZendesk管理者が使いこなせていないツールです。すべての未クローズチケットに対して1時間ごとに実行され、時間ベースの条件をチェックし、条件が満たされたときに発火します。Zendeskには標準で1つのオートメーションが搭載されています。解決済みチケットを96時間後にクローズするというものです。ほとんどのチームは、これ以上のオートメーションを構築できるし、構築すべきです。
1時間ごとの実行の仕組み
1時間ごとに（正時とは限らず、その時間内のランダムなタイミングで）、Zendeskはすべてのアクティブなオートメーションを、未クローズのすべてのチケットに対して評価します。オートメーションはリストの順序で実行されます。あるオートメーションのアクションがチケットを変更すると、同じ1時間の実行パス内で後続のオートメーションはその更新された状態を見ることになります。
例：オートメーション#1は、48時間以上Pending状態のチケットの優先度をHighにエスカレーションします。オートメーション#2は、優先度がHighになったときにエスカレーショングループに通知します。48時間の境界を超えたばかりのチケットは、同じ1時間の実行パスで両方が発火します - #1が発火してHighに設定し、#2がHighを検知してグループに通知します。
多くのチームが気づかないうちに突き当たる厳格な制限があります。各チケットはオートメーションによって合計最大100回まで更新できます。この制限に達すると、Zendeskはチケットにシステムノートを追加しますが、メールアラートもダッシュボードでの表示もありません。チケット監査APIを使うか、動作が止まったことに気づくことで発見するしかありません。
「一度だけ実行する」ルール
すべてのオートメーションには、無効化アクション（発火後に条件をfalseにするもの）か、自然に一度限りとなる条件のいずれかが必要です。これがないと、オートメーションは1時間ごとに無限にループしてしまいます。
標準的なループ防止パターン：
- アクションを追加する：
Tag | Add | automation_sent_24h - 条件を追加する：
Tags | Does not contain | automation_sent_24h
タグは最初の発火時に追加され、以降の実行では条件が満たされなくなります。追加のコーディングは一切不要で、常に機能します。このタグは、そのオートメーションがどのくらいの頻度で発火しているかをExploreで確認できる指標にもなります。
タイミングに関する1つの注意点：時間条件には「Is」ではなく「Greater than」を使いましょう。hours since created | Is | 24という条件は、チケットがちょうど24〜25時間経過したタイミングを捉える、1回だけの実行でしか発火しません。Zendeskのスケジューラが23.5時間や25.5時間の時点でチェックすると、そのタイミングを完全に取りこぼしてしまいます。Greater than 24であれば、24時間を過ぎたあとのどの実行でも発火するため、SLA関連の処理には圧倒的に信頼性が高くなります。タイミングの仕組みについてはZendeskオートメーション条件ガイドで詳しく解説しています。
よくあるオートメーションの使用例
エスカレーション：
- 24時間経過後に優先度をNormalからHighにエスカレーションする
- チケットが48時間経過しても未解決の場合、エージェントのマネージャーグループに通知する
- 契約上の応答義務があるチームのためのSLA違反オートメーション
フォローアップ：
- 顧客からの返信がない場合に24時間後にPendingのリマインダーを送信する
- 7日以上経過した顧客の返信待ちチケットを自動解決する
- 自動クローズが発火する前に最終的なクローズノートを追加する
自動クローズ：
- 解決から24時間後にチケットをクローズする（96時間のデフォルトより早い - 大量のチケットを処理するチームで一般的）
- 放置されたチケット（14日以上更新がないもの）をSolvedとしてマークする
営業時間外：
- 営業時間外にチケットが届いた際のルーティングのための営業時間外オートメーション条件
- 複数のタイムゾーンにまたがるチームのためのスケジュールベースの条件
合わせて参照：チケットのライフサイクル全体で自動化できることの概要についてはZendeskチケットの自動化、返信レベルの自動化についてはZendeskで返信を自動化する方法をご覧ください。
マクロ：手動レイヤー
マクロはトリガーやオートメーションとは種類が異なります。マクロはエージェントのショートカットであり、自動的なルールではありません。エージェントはチケットを見ながらマクロをクリックして適用します。何かが自動的に発火することはありません。この区別は重要です。マクロは、条件を満たすすべてのチケットで実行すべきものではなく、実行前に人間の判断が必要なワークフローを置く場所です。
マクロが1クリックでできること：
- チケットフィールドを設定する：ステータス、優先度、担当者、タイプ、タグ、カスタムフィールド
- テンプレート化されたテキストで公開コメントを追加する
- 内部メモを追加する
- 上記の任意の組み合わせ
マクロの価値は、複数のステップをまとめられることにあります。メッセージを送らずにフィールドを変更するだけのマクロは、そのスロットを無駄にしています。価値の高いマクロのほとんどは、少なくとも2つのことを行います。ステータスを設定し、それに付随する定型メッセージを送信するというようにです。
よくあるマクロのパターン：
- 返信待ち - 内部メモを追加 + Pendingに設定 + 送信：「こんにちは[name]さん、続けるために[X]を送っていただけますか？」
- エンジニアリングへエスカレーション - 優先度をUrgentに設定 + Engineeringグループにアサイン + 内部メモを追加：「[reason]によりエスカレーション」
- 解決済み - クローズ - ステータスをSolvedに設定 + 送信：「[issue]を解決しました。他に何かあればお知らせください！」
- 追加情報のリクエスト - 内部メモを追加 + Pendingに設定 + 具体的な詳細を求めるコメントを追加
命名については、数十個のマクロを持つようになると[Team] Action - Contextという規則が役に立ちます。例：[Billing] Refund - request received、[Engineering] Bug - escalated to Jira。これにより、別途分類体系を作らなくてもリストをフィルタリングしやすい状態に保てます。
詳しいリファレンスはこちら：マクロアクションリファレンス、マクロで内部メモを追加する方法、マクロでコメントとステータス変更を組み合わせる方法、そしてチーム内で誰が各マクロを見られるかを決める個人用マクロと共有マクロの違い。
そのまま使える10のオートメーションテンプレート
これらは、ほとんどのチームが最終的に構築することになるオートメーションとトリガーです。すべてAdmin Centerで簡単に設定できます。
1. チャネルごとにチケットをルーティングする
トリガー。Ticket channel | Is | [channel] → タグchannel_[name]を追加 + グループ[channel team]にアサイン。チャネルごとに1つのトリガーを作成し、順番に実行する。
2. VIP顧客のエスカレーション
トリガー。Organization | [VIP custom field] | Is | true + Ticket | Is | Created → 優先度をUrgentに設定 + VIP Supportグループにアサイン + グループに通知。
3. 未アサインチケットのアラート
オートメーション。Ticket: Assignee | Is | (nobody) + Ticket: Hours since created | Greater than | 4 + Tags | Does not contain | unassigned_alerted → Supportグループに通知 + タグunassigned_alertedを追加。
4. Pendingフォローアップのリマインダー
オートメーション。Ticket: Status | Is | Pending + Ticket: Hours since pending | Greater than | 48 + Tags | Does not contain | pending_reminder_sent → チケットにコメント（情報のリクエスト） + タグpending_reminder_sentを追加。詳しい設定方法：Pending24時間後にリマインダーを送信する。
5. 放置されたチケットの自動解決
オートメーション。Ticket: Status | Is | Pending + Ticket: Hours since pending | Greater than | 168 → ステータスをSolvedに設定 + コメント：「7日間返信がなかったため、このチケットをクローズします。いつでも再オープンできます。」
6. Openチケットの優先度エスカレーション
オートメーション。Ticket: Status | Is | Open + Ticket: Priority | Is | Normal + Ticket: Hours since created | Greater than | 24 + Tags | Does not contain | priority_escalated → 優先度をHighに設定 + タグpriority_escalatedを追加。エスカレーションパターンについて詳しくはオートメーション条件：SLA違反を参照。
7. 解決済みチケットの早期クローズ
オートメーション。Ticket: Status | Is | Solved + Ticket: Hours since status | Greater than | 24 → ステータスをClosedに設定。キューをより早くクリアしたい大量処理チームのために、デフォルトの96時間ルールを置き換える。
8. 緊急チケットでSlackにWebhookを送信する
トリガー。Ticket: Priority | Is | Urgent + Ticket | Is | Created → {{ticket.title}} - {{ticket.url}}とともにWebhook [Slack webhook URL]に通知。
9. タグに応じた内部メモ
トリガー。Ticket: Tags | Contains | needs_legal_review → 内部メモを追加：「法務レビューが必要 - 規定に従いLegalチームにアサインしてください。」詳しい設定ガイド。
10. 営業時間外の自動返信
トリガー。Ticket | Is | Created + Ticket: Schedule | Outside business hours → コメント（公開）：「お問い合わせありがとうございます - 現在チームは営業時間外のため、[次の営業日]までにご返信いたします。」その他の営業時間外オートメーションオプションについてはZendeskの自動返信を参照。
ベストプラクティスと落とし穴
やるべきこと
トリガーの順序を意図的に決める。 ルーティングとアサインのトリガーは、通知トリガーより常に先に実行すべきです。「グループに通知する」トリガーが送信先を確認する前に、チケットが正しいグループに入っている状態にしたいからです。トリガーの順序はAdmin Centerでドラッグ&ドロップにより管理します。順序が複雑な設定にどう影響するかの詳細な解説はトリガーの実行順序を参照してください。
標準トリガーを変更する前に複製する。 標準トリガーはメール通知の配信システムそのものです。元のトリガーは無効化し、複製したものを使って作業しましょう。何か問題が起きた場合は、デバッグしている間は元のトリガーを再度有効にしてください。
オートメーションを保存する前に「Preview match」を使う。 Admin Centerの「Preview match for the conditions」ボタンを使うと、オートメーションが実行される前に、現在何件のチケットが条件に一致しているかを正確に確認できます。150件のはずが15,000件のチケットに対して発火するよう設定してしまっていたことに気づくのは、保存前に発見できればストレスがはるかに少なくなります。
すべてのオートメーションの発火にタグを付ける。 アクションとしてトラッキングタグ（例：auto_followup_sent）を追加すると、ループ防止、Exploreレポート、そして静かな失敗の検知という3つのことを同時に実現できます。オートメーションが想定していた頻度で発火しなくなったことに気づいたら、チケットのタグの蓄積パターンを確認してください。たいていは100回の更新制限か、条件が変更されたことが原因です。
何が問題を引き起こすか
トリガーのループ。 互いのアクションによって発火する2つのトリガーは、サイクルが尽きるまで無限にループします。デバッグの手段としては、予期しない動作をしているトリガーにTicket: Update via | Is not | Triggerを条件として追加します。そのうえで、前述のループ防止タグを追加してください。
正確な時間条件。 Hours since created | Is | 24は、Zendeskの1時間ごとのスケジューラによって完全に取りこぼされる可能性があります。常にGreater thanを使ってください。
静かな100回の更新制限。 チケットが制限に達すると、Zendeskはノートを追加しますが、アラートはなく、UI上で検索することもできません。これを検知する唯一のネイティブな方法はチケット監査APIです。オートメーションの発火をタグで追跡しておけば、静かに失敗する前に、通常より多いオートメーション更新回数に達しているチケットを見つけ出すExploreクエリを組めます。
オートメーションエディタのUX遅れ。 2026年3月現在、オートメーションの条件ピッカーには入力によるフィルタリング機能がなく、カスタムフィールドを見つけるにはリスト全体をスクロールする必要があります。トリガーエディタには検索機能がありますが、オートメーションエディタには（まだ）ありません。対処法：カスタムフィールド名を短く、英数字のみにしておくことで、リスト内で予測可能な形にまとまります。
クローズ済みチケットの死角。 オートメーションはクローズ済みチケットでは一切実行されません。クローズ後の処理（CSATフォローアップ、データクリーンアップ）が必要な場合は、チケットがクローズされる前にアクションを発火させてください。クローズ用オートメーションの一部としてタグを追加し、チケットがまだSolved状態にある間にWebhookまたはAIオートメーションレイヤーを使って後続のワークフローを処理します。
Zendesk標準のオートメーションが限界に達するとき
ルールベースのオートメーションはかなり多くのことをカバーします。しかし、できないこともあります。チケットの内容を理解する、感情を検知する、チケット履歴のパターンから学習する、ナレッジベースの知識のギャップを埋める、あるいは今まで見たことのないチケットにどう対応すべきか判断を下す、といったことです。
この限界は、いくつかの予測可能な場面で現れます。
- 定型テンプレートではなく、顧客が実際に書いた内容に合わせた返信をしたい
- キーワードマッチングではなく、意図に基づいたチケット分類が必要
- プロダクトの進化に合わせてマクロや定型応答を最新に保つのに何時間もかけている
- AIにtier-1のチケットをルーティングだけでなく、最初から最後まで対応してほしい
この限界に達したチームは、ZendeskのネイティブなAIを「自分たちに必要なものには不十分」だと表現することが多くあります。ルールは決定論的なワークフローには適していますが、サポートの会話は決定論的ではありません。サポートチケットの自動化を取り巻く状況は大きく成熟しており、今ではZendeskのルールレイヤーを置き換えるのではなく補完するために作られたツールが登場しています。
eeselはここに当てはまります。eeselはZendesk内でネイティブに動作するAIエージェントであり、別のインボックスでもワークフローの外にあるチャットボットウィジェットでもありません。チケットを読み、ヘルプセンターや過去のチケットに基づいた返信を作成・送信し、フィールドを更新し、エスカレーションをルーティングし、既存のトリガー、オートメーション、営業時間ルールを設定どおりに尊重します。これまで構築してきたものはすべてそのまま機能します。ルールベースのオートメーションの上に重ねるレイヤーの選択肢を検討しているなら、Zendesk AIの代替ツールの比較記事もご覧ください。
eeselを試す
eeselは、Zendesk内にネイティブなエージェントとしてインストールされるAIチームメイトです。受信したチケットを読み、顧客の言語で返信を作成・送信し、チケットフィールドを更新し、ルーティングとエスカレーションを処理し、SLAのタイムラインを管理します。それらすべてを、既存のトリガー、オートメーション、営業時間ルールを尊重しながら行います。設定は30分以内で完了し、eeselは実際のチケットに触れる前に、ヘルプセンターの記事、過去のチケット、マクロをナレッジソースとして自動的にインポートします。
料金は1チケットあたり$0.40 - プラットフォーム利用料もシート単位の費用もなく、「解決」課金による予期しない請求もありません。Smavaはドイツ語で月10万件以上のチケットをeeselで処理しています。Gridwise社のKim Simpson氏は率直にこう述べています。
"In the first month, eesel is resolving 73% of our tier 1 requests. eesel offers easy Zendesk implementation and setup. Our team implemented and achieved results quickly during our 7-day trial. The platform even includes automations for ticket tagging, assignment, and status updates!"
Kim Simpson, Gridwise (G2 review)
eeselを無料で試す - $50クレジット、クレジットカード不要。
よくある質問
Zendeskでオートメーションはいくつ作成できますか？
Zendeskのオートメーションが発火しないのはなぜですか？
Zendeskのオートメーションはクローズ済みチケットでも実行されますか？
Zendeskトリガーのループを防ぐにはどうすればいいですか？
notification_sent）を追加し、そのタグがまだ存在しないことを確認する条件を追加することです。これにより、トリガーはイベントサイクルごとに一度だけ発火するようになります。また、条件にTicket: Update via | Is not | Triggerを追加することで、下流のトリガーがループを開始することを防げます。詳しくはZendeskトリガーの実行順序ガイドをご覧ください。
Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.
