Zendeskの自動化設定：トリガー、オートメーション、マクロの完全ガイド（2026年版）

Zendeskにおける「自動化設定」が実際に意味するもの

「Zendeskの自動化設定」という言葉が人を混乱させるのは、それが三つの異なるツールを指しているにもかかわらず、Zendeskが「オートメーション」という言葉をそのうちの一つだけに使っているからだ。何か一つでも設定に触れる前に理解しておく価値のあるメンタルモデルを紹介する。

• トリガーはイベント駆動だ。チケットが作成または更新された瞬間に条件をチェックし、すぐに発火する。これがルーティング、タグ付け、通知を担うレイヤーになる。Zendeskのドキュメントによると、アクティブなチケットトリガーは最大7,000件まで持てる。
• オートメーションは時間駆動だ。1時間ごとにクローズされていないすべてのチケットに対して実行され、「解決から96時間以上経過」のような時間条件が満たされたときに発火する。これがエスカレーション、リマインダー、自動クローズを担うレイヤーになる。
• マクロは手動だ。フィールドの変更と定型の返信文をあらかじめ一式にまとめておき、エージェントがワンクリックで適用する。自動な部分は何もなく、実行するかどうかはエージェントが選ぶ。

何かを構築するときに最も役立つ問いはこれだ。何かが変わったその瞬間に起こる必要があるのか、それとも一定期間経過後に起こる必要があるのか。瞬時ならトリガー。X時間・X日後ならオートメーション。人間が適用を決めるならマクロだ。ルールエンジン全体をより詳しく知りたいなら、Zendeskビジネスルール設定ガイドがさらに深く掘り下げており、Zendeskの自動化全般についての継続的な解説記事も用意している。

自動化設定の見つけ方

すべては一つの場所にまとまっている。Admin Center > Objects and rules > Business rulesに行くと、トリガー、オートメーション、マクロが別々のセクションとして表示される。このレイアウトに慣れていない場合は、Zendesk Admin Centerの概要で各設定グループがどこにあるかを確認できる。

事前に知っておくべきことが一つある。Enterprise以外のプランでは、ビジネスルールはすべてのエージェントに表示されるが、編集できるのは管理者のみだ。Enterpriseでは、カスタムロールと権限で誰が閲覧・編集できるかを範囲指定できる。つまり設定が見えるのに変更できない場合、それはバグではなく権限の制限だ。

トリガーの設定（即時レイヤー）

新しいZendeskアカウントには、標準トリガーの一式がすでに有効な状態で搭載されており、それらは実際に重要な役割を果たしているため、むやみに無効化してはいけない。標準チケットトリガーは、顧客とエージェントが頼りにするメール通知を処理している。「リクエスト受信を申請者に通知」「担当割り当てを担当者に通知」「コメント更新を担当者に通知」などだ。

トリガーに関する最も重要なルールは、絶対にすべてを無効化しないことだ。トリガーはまさにメール配信レイヤーそのものだ。すべてオフにすれば、顧客へのメールは一切届かなくなる。

カスタムトリガーを作成するには：

1. Admin Center > Objects and rules > Business rules > Triggersに移動し、Add triggerをクリックする。
2. 将来の管理者が理解できるような名前を付け、条件を追加する。条件は category | operator | value の形式で、例えば Ticket | Channel | Email のようになる。
3. 範囲を絞り込むために Ticket | Is | Created または Ticket | Is | Updated の条件を追加する。これがないと、トリガーはあらゆる作成・更新のたびに評価され、トリガーサイクルを肥大化させる。
4. アクションを追加する。グループへの割り当て、タグの設定、通知の発火、Webhookの呼び出しなどだ。
5. 保存する。トリガーはリストの順番に上から下へ実行されるので、正しい位置にドラッグする。

後で苦労しないための設定習慣をいくつか紹介する。

• **標準トリガーを変更する前にクローンする。**元のトリガーを無効化し、クローンを編集する。こうすればいつでも元に戻せる。Zendeskのメールトリガーと通知のガイドでは通知系トリガーについて具体的に解説している。
• **「リクエスト受信を全エージェントに通知」の無効化を検討する。**これはデフォルトで有効になっており、小規模チーム以上では全エージェントの受信箱を埋め尽くす。
• **再割り当ての通知が欲しい場合は Is created ではなく Assignee | Changed の条件を使う。**これはZendeskコミュニティで「トリガーが発火しない」という問い合わせの中で最もよくある原因の一つだ。
• **サイクルに注意する。**トリガーが発火してチケットを更新すると、サイクル全体がリスタートする（発火済みのトリガーは再実行時にはスキップされる）。そのため、上位にあるルーティング用のトリガーが、下位にある通知用トリガーが見る内容を変えてしまうことがある。順序は重要であり、担当者を設定する二つのトリガーが競合すると、予測しづらい結果になる（最後に発火したものが勝つが、どれが最後かは分かりにくいことが多い）。

トリガーはWebhookも呼び出せるため、多くのチームがこれを使ってZendeskをSlack、Jira、Salesforceと連携させている。AI支援によるルーティングを目指しているなら、Zendeskのトリガーとワークフロー設定がより高度な自動化にどうつながるか、また基本的なタグが整った後にチームがAIによるチケットタグ付けをどう扱っているかを読んでおく価値がある。

オートメーションの設定（時間ベースのレイヤー）

オートメーションで最も多くの人がつまずくのは、設定画面からは分かりにくい一つのルールのためだ。すべてのオートメーションは自分自身を停止できる必要がある。

オートメーションはクローズされていないすべてのチケットを毎時再チェックするため、条件が真のままであり続けるオートメーションは、永遠に何度も発火し続けてしまう。それを防ぐために、Zendeskのオートメーションのドキュメントによると、すべてのオートメーションには次の二つのうちどちらかが必要だ。

1. 自身の条件の一つを打ち消すアクション（典型例：標準の「解決から4日後にチケットをクローズ」オートメーションは Status | Is | Solved をチェックしてからステータスをクローズに変更するため、二度と条件に一致しなくなる）、または
2. 一度しか真にならない条件、例えば Hours since created | Is | 4 など。

実際には、最も信頼できるパターンはタグベースのものだ。Tags | Does not contain | reminder_sent という条件を追加し、reminder_sent タグを付与するアクションを追加する。最初の1時間で条件に一致し、発火し、自身にタグを付ける。それ以降の毎時、そのタグがブロックする。

作成するには：

1. Admin Center > Objects and rules > Business rules > Automationsに移動し、Add automationをクリックする。
2. 名前を付け、ループを止める条件を含めて条件を追加する。
3. 保存する前にPreview match for the conditionsを使う。これにより、既存のどのチケットが影響を受けるかが正確に分かり、誤って何千もの古いチケットにアクションを一斉適用してしまうのを避ける最良の方法だ。
4. アクションを追加して作成する。

重要な設定レベルの細かい点がいくつかある。

• **時間条件には Is より Greater than を優先する。**オートメーションは正時に実行されるわけではなく、各時間の中のランダムな時点で実行されるため、「ちょうど4時間」というウィンドウはトラフィックの多いアカウントでは完全に見逃されることがある。Greater than | 4 なら次のパスで確実に捕捉できる。
• **すべてのオートメーションに追跡用タグを追加する。**Zendeskにはオートメーションのネイティブな利用状況レポートがないため、auto_closed_96h のようなタグがあれば後でExploreで発火回数を数えられ、オートメーション監査ログのワークフローにも役立つ。

チームがよく設定するオートメーションと、それぞれの詳細ガイドを挙げる。

• 解決から24時間後にチケットをクローズ（または標準の96時間版）
• 24時間保留状態が続いた顧客へリマインド
• 未割り当てチケットのエスカレーション、およびより広範なSLAベースのエスカレーションオートメーション
• SLA違反時にマネージャーへ通知、これはエージェントのパフォーマンスとSLA追跡とも相性が良い
• 古いチケットのアーカイブ、複数段階のリマインダー後に古いチケットをクローズ

どちらを使うべきかの比較を完全な形で知りたいなら、Zendesk自身のトリガー対オートメーションの記事が標準的な参照先だ。

マクロの設定

マクロは三つの中で最もシンプルで、最も手軽に得られる成果だ。マクロはチケットフィールドの変更（ステータス、優先度、グループ、タグ）と定型の返信文をひとまとめにしたもので、よくある問題に対応するエージェントは、同じ内容を百回目に入力する代わりに一度クリックするだけで済む。

マクロはAdmin Center > Workspaces > Agent tools > Macrosで作成し、エージェントはチケット内から個人用マクロを保存することもできる。マクロライブラリを使いやすく保つための習慣をいくつか挙げる。

• 一貫した命名をする。[Support] Close - Not reproducible のような形式にしておけば、エージェントがチケット対応の途中でも検索しやすい。出発点としてマクロテンプレートを参照してほしい。
• **フィールド変更には必ず返信をセットにする。**ステータスを解決済みに変えるだけのマクロは、クロージングメッセージを一緒に送る機会を無駄にしている。マクロのアクションガイドでは、一つのマクロに何を組み合わせられるかを解説している。
• **定期的に監査する。**マクロにもネイティブな利用状況レポートはないため、90日間使用がゼロのものは廃止してリストを短く保つ。

マクロはトリガーとも自然に組み合わさる。例えばトリガーやマクロでフォロワーを自動追加する方法があり、また同じパターンを最初から最後まで自動化する返金・交換・配送用のAIマクロテンプレートの、人間が関与するバージョンとも言える。

設定画面には誰も書かない制限

これが「Zendeskの自動化設定」のうち、実際にぶつかるまで表に出てこない部分だ。ルールエンジンは強力だが、明確な上限といくつかの癖があり、その上に重要なものを構築する前に知っておく価値がある。

• **1チケットあたり100回更新の上限は静かに存在する。**オートメーションは単一のチケットを最大100回まで更新できる。それに達すると、Zendeskはシステムノート（「The maximum number of ticket updates that can be made by automations has been exceeded」）を残すが、そのノートはUI上では検索できない。チケット監査APIを通じてしか気付けない。
• **オートメーションは1時間あたり1,000チケットに制限される。**大規模な遡及クリーンアップ用のオートメーションは、後続の時間帯にあふれ出てしまい、どのオートメーションが制限されているかを示すビルトインのビューは存在しない。
• **タイミングはおおよそのものだ。**オートメーションは各時間内のどこかの時点で実行されるため、分単位の精度が必要なもの（SLAと密接に結びついたアクションなど）は、オートメーションだけに頼ることはできない。
• **トリガーはクローズ済みのチケットでは実行されない。**データクリーンアップや遅延CSATトリガーのようなクローズ後のワークフローには、回避策が必要になる。
• **オートメーションエディタは依然として入力検索ができない。**これはユーザーが最も不満を持っている点だ。あるアドミンが2026年3月にZendesk自身のオートメーションドキュメントのコメント欄でこう述べている。

"It's so annoying to work in. We can't start typing to find any of the condition fields. If I need a condition based on a custom ticket field, I have to scroll and scroll."

Admin comment on Creating and managing automations for time-based events, Zendesk Help Center

これらはどれも単独では致命的な欠点ではない。しかし合わせて見ると、より大きな制約を示す良い兆候になっている。トリガー、オートメーション、マクロはチケットを動かすことには非常に優れているが、そのいずれもチケットに実際に回答することはできない。トリガーは請求に関する質問を請求グループへルーティングできるが、その質問を読み、アカウントを確認し、返信を書くことはできない。それがこの壁だ。

Zendeskの自動化が壁にぶつかる場所と、その対処法

チームがビジネスルールから得られるものをすべて絞り尽くすと、次に出てくる要望はたいてい「システムが簡単なチケットを最初から最後まで自動で処理できないのか」というものだ。これは種類の異なる自動化であり、ここで多くのチームがネイティブなルールエンジンの先を、そしてしばしばZendesk自身のAIアドオンの先までも見始める。

正直なところを言えば、Zendeskには独自のAIエージェントとCopilotがあり、一部のチームにはそれで十分な場合もある。しかし二つの不満が繰り返し挙がる。一つはコストだ。高度なAIは別料金で、多くの場合解決件数ごとの課金となる。この点はZendesk AI料金計算ガイドで詳しく掘り下げている。もう一つは、それでもなお設定プロジェクトであり続けるという点だ。私たちの顧客調査では、月に約500件のZendeskチケットを処理する米国のヘルスケア・理学療法系チームが、ネイティブのZendesk AIを「kicked the tires」（試してみた）した結果、他の選択肢を探し始める前に「largely inadequate and overpriced」だと感じたと語ってくれた。

ルールが与えられないものは判断力だ。そして購入を検討する側の最も多い懸念は、AIが弱すぎることではなく、むしろその逆で、対応すべきでないことにも自信満々に答えてしまうことだ。あるサポートリーダーは、自分が求めているものを説明する中で、AIに一切通したくない「certain tickets I don't want to go through AI」があるとはっきり述べていた。この制御、つまりどのチケットにAIが触れることを許可するかを決めることこそ、優れたAIレイヤーが既存のトリガーとオートメーションの上に追加してくれるものだ。完全な違いを知りたい場合はAIエージェント対ルールベースのチャットボットを、またZendesk AIの代替ツールのまとめや無料プランの比較も参照してほしい。

Zendesk向けeeselを試す

eesel AIは、あなたのZendeskアカウント内にネイティブなAIエージェントとしてインストールされ、たった今設定したトリガー、オートメーション、マクロを再構築するよう求めるのではなく、それらと並行して動作する。過去のZendeskチケット、ヘルプセンターの記事、既存のマクロから学習し、ブランドに合った返信を下書きし、チケットフィールドを更新し、すでに設定済みのビジネスルール、SLA、営業時間を尊重する。

Zendesk自身のAIとは異なる二つの点がある。第一に、本番のチケットに触れる前に、実際の過去のチケットに対してシミュレーションできるため、実際にどう返信していたか、どこにギャップがあるかを正確に確認できる。第二に、別のルールツリーを構築するのではなく、平易な言葉で説明することで動作を設定でき、どのチケットを処理させるかを正確に選び、それ以外は触れないようにできる。

料金体系もよりフラットだ。処理したチケット1件あたり0.40ドルで、席数課金も解決件数に応じた不意な追加料金もない。Ecosaは月に10,000件以上のチケットをZendesk上のeeselで処理しており、Tier-1チケットの75%を処理し、1時間足らずで導入できたと報告している。他のツールと直接比較評価したGcoreのMikita Tsybulka氏はこう述べている。

"I've tested many AI agent solutions, but so far Eesel is one of the best. It has many features we need, such as broad sources availability, variety of options, integrations, and so on. Highly recommended."

Mikita Tsybulka, Gcore, via Zendesk向けeesel AI

Zendeskの自動化設定はすでに整っていて、次のボトルネックが依然として人間が実際に読む必要のあるチケットの量だという段階にあるなら、それこそが試す価値のあるギャップだ。無料で始めて、自社のチケット履歴を使ったシミュレーションを午後の時間だけで実行できる。