Zendesk自動化ガイド：トリガー、オートメーション、マクロ、そしてAI

Zendesk自動化を支える3つのツール

誰かが「Zendeskを自動化したい」と言うとき、それはほぼ常に3つの異なるものの1つを指しており、間違ったものを選ぶことが私たちが目にする最も多いミスです。3つとも同じ場所、管理センターの「オブジェクトとルール > ビジネスルール」にありますが、動作はまったく異なります。

それぞれを一言で言うと:

• トリガー はイベントベースです。条件をチェックし、チケットが作成または更新された瞬間に発火します。ルーティング、タグ付け、通知を思い浮かべてください。
• オートメーション は時間ベースです。1時間ごとにすべてのクローズされていないチケットに対して実行され、「このチケットは解決から96時間以上経過している」のような時間条件が満たされたときに発火します。
• マクロ は手動です。エージェントが「マクロを適用」をクリックすると、フィールドの変更と定型返信がまとめて一度にチケットに反映されます。自動的な部分はまったくありません。

この3つすべてが作用するフィールド、ステータス、優先度、タグ、担当者は、エージェントワークスペースで目にするものと同じです。ここでは、エージェントが実際にマクロを適用する場所と、トリガーやオートメーションが背後で静かにタグや優先度を変更する場所を示します。

Zendesk自身のドキュメントにある良い経験則はこうです。ワークフローを平易な言葉で書き出し、時間に関する言葉を探すこと。「X時間後」や「X日後」に起きるべきことはオートメーションです。「これが変化したとき」に起きるべきことはトリガーです。エージェントが特定のチケットで判断して行うことはマクロです。

トリガー：即座に発火するイベントベースのルール

トリガーは主力です。チケットが作成または更新されるたびに、アクティブなすべてのチケットトリガーが順番に実行され、条件をチェックし、満たされていればアクションを発火させます。トリガーはメール通知を実際に配信するレイヤーでもあるため、すべてのトリガーを無効化してはいけません。そうすると、顧客は「お問い合わせを受け付けました」というメールをまったく受け取れなくなります。

各トリガーは2つの部分から構成されます。条件（「もし」）とアクション（「その場合」）です。条件は「すべて真である必要がある」または「いずれかが真であればよい」としてグループ化でき、1つのチケットトリガー内で両方を組み合わせることもできます。チームがトリガーを構築する最も一般的な用途は次のとおりです。

• ルーティング：メールのチケットをあるグループに、チャットを別のグループに送る、または組織のドメインによって自動割り当てする。
• タグ付け：件名のキーワードに基づいてbillingやurgentのタグを付け、それをルーティングやレポートに利用する。
• 通知：何かが起きたことを担当者、グループ、または顧客に伝える。
• 連携：Webhookを発火させてSlackに投稿したり、Jiraのissueを開いたりする。

Zendeskは新規アカウントごとに一連の標準トリガーを用意しており、これにより最初から通知が機能します。知っておく価値があるのは次のものです。

この「Notify all agents」は多くのチームを悩ませます。少数のエージェントを超えて有効なままにしておくと、新しいチケットのたびにすべての受信箱があふれてしまいます。早めに無効化しましょう。

トリガーサイクルこそ見落とされがちな部分

「なぜトリガーがこんな動きをしたのか」という頭痛の種の大半を引き起こす仕組みがこれです。トリガーはリストの順序に従って上から下へ実行されます。しかし、あるトリガーが発火してチケットを更新すると、サイクル全体が最初からやり直されます（今発火したばかりのトリガーは、再スタート時にはスキップされます）。だから順序は非常に重要です。上のほうにあるルーティングトリガーが値を変更し、それを下のほうにある通知トリガーが後で読み取ることがあります。

実際に起きる影響と、それを防ぐベストプラクティスは次のとおりです。

1. ルーティングと割り当てのトリガーを通知トリガーより前に置くことで、後者が最終的な状態を確認できるようにします。
2. Ticket | Is | CreatedやTicket | Is | Updatedの条件を使って範囲を絞り込みます。そうしないと、トリガーがあらゆるイベントで評価され、サイクルが肥大化します。
3. ループブレーカーとしてタグを使う：トリガーが発火したときにタグを追加させ、再スタート時に再発火しないようTags | Does not containの条件を加えます。
4. **標準トリガーを変更する前に複製する。**元のトリガーは無効化し、複製した方を編集すれば、いつでも元に戻せます。競合を解きほぐしているなら、トリガーの実行順序を詳しく解説した記事もあります。

覚えておくべき鋭いポイントが1つあります。トリガーはすでにクローズされたチケットには発火せず、AIエージェントのチケットでも実行されません。解決後のワークフローを構築していて、トリガーがクローズ済みチケットを捕捉することを期待しているなら、それは起きません。

オートメーション：1時間ごとの時間ベースエンジン

オートメーションは見た目がトリガーとほぼ同じ（条件とアクション）ですが、発火のロジックは正反対です。イベントに反応する代わりに、1時間ごとに1回すべての未クローズチケットに対して実行され、時間条件が真になったときに発火します。これはSLAエスカレーション、放置チケットのリマインダー、そして定番の解決後の自動クローズ向けのツールです。

タイミングは思っているよりも緩やかです。1時間ごとの実行はきっかり時報に行われるわけではなく、「その時間帯のどこか」で行われ、「X以降の経過時間」は経過した丸1時間を数え、正確な分数ではありません。そのため、9:15に解決されたチケットに「解決から2時間後」というオートメーションが設定されている場合、2時間のマークを過ぎた実行まで発火せず、それは12:00近くになることもあります。時間に敏感なものについては、オートメーションのタイミングはおおよそ1時間単位であり、分単位で正確ではないと考えてください。

すべてのオートメーションにはオフスイッチが必要

これはスキップできない唯一のルールです。オートメーションは1時間ごとに再評価されるため、自分を止める方法がないオートメーションは、同じチケットに対して毎時間、永遠に発火し続けます。Zendeskはこれを「一度だけ実行される必要がある」という要件と呼んでいます。すべてのオートメーションには、条件のどれかを無効化するアクションか、一度しか真になれない条件のどちらかが必要です。

信頼できるパターンはタグベースです。オートメーションはタグが存在しないことをチェックし、処理を行い、その後タグを追加します。次の1時間では、タグが存在するため条件が満たされず、スキップされます。Zendesk自体の標準オートメーション「close ticket 4 days after solved」は、このよりクリーンなバージョンを使っています。「Closed」というアクションが「Solved」という条件を無効化するため、ループすることがありません。

もう少し身につける価値のあるオートメーションの習慣です。

• **時間条件にはIsではなくGreater thanを優先する。**1時間ごとの実行はずれることがあるため、Is exactly 4 hoursのようなウィンドウはトラフィックの多いアカウントでは完全に見逃される可能性があります。Greater than 4 hoursとループブレーカーの組み合わせのほうがはるかに安全です。
• **保存前に「プレビュー一致」でテストする。**これにより、条件がどの既存チケットに当たるかが正確にわかり、一度に数千件のチケットを更新してしまう前に、範囲が広すぎるルールを発見できます。
• **上限に注意する。**オートメーションは1時間あたり最大1,000チケットしか処理できず、各チケットはオートメーションによって最大100回までしか更新できません。大規模な遡及クリーンアップは完了までに何時間もかかることがあり、この100回の上限は静かに存在します。Zendeskはシステムノートを追加しますが、UI上で検索することはできません。
• 各オートメーションのアクションにauto_closed_96hのようなタグを付けて、後でExploreでレポートできるようにします。オートメーションの利用状況を示すネイティブなレポートはないため、タグベースの追跡が回避策になります。

チームがよく構築するオートメーションには、開いてから24時間後に優先度をエスカレーションする、チケットが保留状態のままになったらリマインダーを送る、チケットが長時間未割り当てのままならグループに通知する、そして顧客の返信を7日以上待っているチケットを自動解決する、といったものがあります。

マクロ：エージェントが実際に使うワンクリックのショートカット

マクロは3つの中で唯一自動ではありません。エージェントがチケットを開き、マクロを適用をクリックすると、あらかじめ用意されたアクションの束が一度に実行されます。ステータスと優先度を設定し、タグを追加し、定型返信を挿入します（{{ticket.requester.name}}のようなプレースホルダー付きで、それでも個人的な印象を保てます）。人間らしさを犠牲にすることなく、繰り返し発生するチケットの対応時間を削減する最速の方法です。

マクロには2種類あります。個々のエージェントが自分のために作る個人用のものと、管理者がグループやチーム全体のために管理する共有のものです。最も効果の高い施策は、上位10〜20件のチケットパターンに対して共有マクロを構築することです。マクロライブラリが陳腐化するのを防ぐポイントをいくつか挙げます。

• **フィールドの変更に返信をセットにする。**ステータスを変えるだけのマクロは半分のマクロにすぎません。標準メッセージも送るバージョンこそが実際に時間を節約します。
• 命名を標準化する。[Support] Close - Not reproducibleのようにしておけば、エージェントがチケット対応中に素早く見つけられます。マクロをカテゴリ別に整理することもできます。
• **定期的に監査する。**マクロの利用状況を示すネイティブなレポートはありません（オートメーションと同じ欠落です）ので、追跡用タグを追加し、90日間使われていないものは廃止しましょう。マクロが設定できるすべてのこと、内部メモやカスタムフィールドを含めて、マクロアクションリファレンスを参照してください。

トリガー vs オートメーション vs マクロ：どれを選ぶべきか

ワークフローを前にしてどのツールが合うか迷ったときは、このスクリーンショットに値する表を使ってください。

判断はほぼ常にタイミングをめぐるものです。「何かが変化したとき」はトリガーです。「一定の時間が経過した後」はオートメーションです。「エージェントが判断するとき」はマクロです。もし「顧客が問い合わせてきたら、それを読んで実際に答えてほしい」と思っているなら、この3つのどれもあなたのツールではありません。そしてそれこそが、次に取り上げる正直な限界です。

ネイティブなZendesk自動化が天井にぶつかる場所

Zendeskのビジネスルールがどれほど表現力豊かかについて、私たちは大いに評価しています。コードを書かなくても、本当に複雑なワークフローをモデル化できます。しかし、十分な数の導入を経ると、同じ壁が繰り返し現れます。ニーズを満たせないルールに過剰投資する前に、それらを名指ししておく価値があります。

• **ルールは決定論的であり、知的ではない。**トリガーは件名に「invoice」が含まれているという理由でチケットにbillingのタグを付けられますが、メッセージを読んで顧客が特定の請求に対する返金を求めていることを理解し、答えを書くことはできません。条件とアクションはパターンにマッチするだけで、理解はしません。
• **ネイティブな利用状況分析がない。**どのトリガー、オートメーション、マクロが実際に使われていて、どれが無駄になっているかを教えてくれる組み込みレポートはありません。誰もがタグベースの追跡とExploreクエリに頼ることになります。
• **エディタが遅れている。**2026年3月になっても、管理者はZendeskヘルプセンターで、オートメーションの条件ピッカーには入力してフィルタリングする機能がないと不満を述べていました。「If I need a condition based on a custom ticket field, I have to scroll and scroll.」
• **ネイティブAI層は見た目より薄い。**Zendeskにバンドルされているアイテム、AI Agents（Essential）ティアはナレッジベースに基づくQ&Aは扱えますが、スクリプト化された対話や権限を持つアクションは扱えず、r/Zendeskでは「AI」と箱に書かれたルーティング層としてしばしば説明されています。能力のあるティアはCopilotアドオンの裏にあり、1エージェントあたり月額約50ドルで、自動化された解決が積み重なると、AIのコストは基本サブスクリプションの2〜3倍に膨らむことがあります。

その価格と機能のギャップこそが、チームが他を探す理由そのものです。あるZendeskを利用する複数企業を運営するeコマース事業者は、営業の電話でネイティブAIを評価した後、それを「expensive and inadequate」と表現し、素早く前に進みたいと語りました。彼らだけではありません。月間約500件のチケットを扱う米国のヘルスケアサポートチームは、私たちに「kicked the tires on Zendesk AI solutions and found it largely inadequate and overpriced」と語りました。

より深いポイントは、あるDTCサプリメントブランドのCXリーダーが、AIに本当に求めているものを尋ねたときに完璧に言い表しています。

"The AI will never be able to answer 100% of the questions. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

これがそのギャップです。ネイティブルールが与えてくれるのはオール・オア・ナッシングの自動化ですが、チームが求めているのは自信を持って対応しつつ、きれいな引き継ぎができる自動化です。それは判断の問題であり、判断こそがAIレイヤーが存在価値を発揮する場所です。

ルールが止まる場所からAIが引き継ぐ方法

私たちが提案したい枠組みはこうです。トリガー、オートメーション、マクロには、それらが得意とする決定論的な作業を任せ続け、ルールにはできない部分、つまりチケットを読んで解決する部分のためにAIレイヤーを上に追加します。この2つは競合していません。うまく構築されたeesel AIのセットアップは、既存のトリガー、オートメーション、営業時間ルールを尊重します。それは理解力を追加するだけです。

eesel AIはZendesk内にネイティブなAIエージェントとしてインストールされ（別のウィジェットや受信箱ではありません）、過去のチケット、ヘルプセンターの記事、既存のマクロから学習し、その上でブランドに沿った返信を下書き・送信し、フィールドを更新し、エスカレーションをルーティングします。それがZendeskアカウント内で動いている様子はこちらです。

これが、あらゆることに自動返信するような大雑把なスイッチではなく、CXリーダーが求めていた「自信を持った自動化」に合致する理由がいくつかあります。

• **本番投入前に過去のチケットでシミュレーションする。**Zendeskの過去のチケット履歴に対してAIを実行し、実際の顧客に触れる前に、AIが何と答えていたか、どこが強く、どこにギャップがあるかを正確に確認できます。Zendeskのネイティブなフローには、これに相当する事前シミュレーションはありません。
• **何を任せるかをコントロールする。**まずはドラフトモードから始め、AIはエージェントが承認するための返信を提案するだけにします。その後、自信のあるチケットタイプについては自律モードに切り替えます。自信の低いケースは、あの引用が説明していたとおり、人間に任されます。
• **平易な言葉での設定。**ルールエンジンを構築するのではなく、新入社員をブリーフィングするようにAIに伝えます。どのチケットを扱うか、どう書くか、いつエスカレーションするかを。
• **解決件数ゲームのない料金体系。**対応した1チケットあたり0.40ドルで、席数料金も解決件数への上乗せ料金もありません。これにより、Zendesk Copilotの購入者を悩ませる制御不能なAI料金を回避できます。

決定論的な側面では、eeselはトリガーの束を組んで対応するはずだったタグ付け、トリアージ、ルーティングも扱うことができ、提案された返信を添えた内部メモを残したり、フィールドを自動的に更新したりします。すでに運用しているZendeskの上に乗るだけで再構築を求めないからこそ、ZendeskのAI代替ツールの中でも実際に選ばれる選択肢になっています。

ルールが届かない部分にeeselを試す

eesel AIは、数分でZendeskに接続できるセルフサーブ型のAIエージェントで、過去のチケットとヘルプセンターから学習し、すでに構築済みのトリガー、オートメーション、マクロを尊重しながらティア1チケットを解決します。ほとんどのチームが最初に気づく違いは、実際の顧客に返信する前に、実際の過去のチケット数千件でシミュレーションできることです。だから、望みをかけるのではなく、数字を把握した状態で本番投入できます。

Ecosaは月間10,000件を超えるチケットでZendesk上のeeselを運用しており、ティア1チケットの75%がAIによって処理され、1時間以内に完全に統合されたと報告しています。クレジットカードなしで無料で始めることも、デモを予約して自社のチケット履歴に対して実際に動く様子を見ることもできます。eeselを試して、ルールが得意なことをルールに任せ、ルールでは決して対応できなかったチケットをAIに任せましょう。