Zendeskの自動化を徹底解説：機能、限界、代替手段

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

人々が「Zendeskの自動化」と言うとき、たいていは3つの異なるもののうちのどれかを指しており、この混同こそが理解の半分の壁になっています。3つとも同じ場所（管理センター > オブジェクトとルール > ビジネスルール）にありますが、発火するタイミングはまったく異なります。

それぞれを一言で表すと以下の通りです。この後、順に詳しく見ていきます。

• **トリガー**は、チケットが作成または更新されると即座に実行されます。リアルタイムのルーティングと通知を担うレイヤーです。
• **オートメーション**は1時間ごとに実行され、「このチケットが解決してから96時間経過した」といった時間ベースの条件に基づいて動作します。
• **マクロ**は、エージェントがクリックすることで一連の変更と定型返信を一度に適用する手動ショートカットです。

トリガーとオートメーションは自動で動きますが、マクロには人の手が必要です。トリガーはイベントに反応し、オートメーションは時計に反応します。この2つの軸さえ押さえておけば、システム全体の理解が進みます。もし1つだけ覚えておくなら、Zendesk公式ドキュメントによれば、公式のルールはワークフローを平易な言葉で書き出し、各ステップが時間ベース（オートメーション）かイベントベース（トリガー）かで振り分けることです。

Zendeskトリガー：即時実行のイベント駆動ルール

トリガーは主力ツールです。チケットが作成または更新されるたびに、Zendeskは有効なチケットトリガーをすべて順番に実行し、条件を満たしたものを発火させます。トリガーは古典的な2つの要素、条件（「もし」の部分）とアクション（「そうすれば」の部分）で構成されており、詳細はZendeskトリガーについてで解説されています。

チームが日常的にトリガーを使う場面：

• 通知： リクエストを受け付けたことを顧客にメールで知らせる、新しいアサインをエージェントに通知する、チケットがキューに入った際にグループへ知らせる。
• ルーティング： メールのチケットを1つのグループに、チャットを別のグループに振り分ける、チャネルごとに自動タグ付けする、VIP組織を優先グループへ回す。
• インテグレーション： Webhookを呼び出してSlackに投稿する、Jiraの課題を作成する、Salesforceに通知する。

新規アカウントには最初から便利な標準トリガーのセットが用意されているため、初日からメール通知がそのまま機能します。

トリガーサイクルの実際の仕組み

つまずきやすいのがサイクルの部分です。チケットが変更されると、トリガーは上から下へ順に実行されます。1つが発火してチケットを変更すると、サイクル全体がリスタートします（ただし、すでに発火したトリガーは次のパスではスキップされます）。だからこそトリガーの順序が重要なのです。上位にあるルーティング用トリガーがフィールドを変更すると、その下にある通知トリガーが発火するかどうかを左右することがあります。

これがトリガーのデバッグが非常に難しいと言われる理由でもあります。シミュレーションツールが存在しないため、誤動作するルールを解きほぐすには、通常トリガーを1つずつ無効化していくしかありません。この問題があまりにも一般的なため、Zendeskは汎用的な「トリガーループ」警告バナーまで追加しています。覚えておくべきいくつかの事実として、有効なチケットトリガーは最大7,000件まで作成でき、各ルールは65KB未満に収める必要があり、トリガーはクローズ済みチケット（およびAIエージェントのチケット）では実行されません。標準トリガーを変更する必要がある場合、安全な方法は複製を作成し、その複製を編集し、元のトリガーを無効化することです。

具体的な手順については、eeselが最もよく使われるパターンについてステップバイステップのガイドを用意しています。ステータスが保留中に変わったとき、解決済みまたはクローズ済みチケット、タグの追加と削除、カスタムフィールドの設定のトリガーです。

Zendeskオートメーション：1時間ごとに実行される時間ベースのルール

オートメーションは見た目こそトリガーとほぼ同じ（同じ条件とアクションの構造）ですが、答える問いが異なります。それは*一定期間が経過した後に何が起きるべきか？*という問いです。イベントに反応する代わりに、1時間ごとにクローズされていないすべてのチケットをチェックし、時間条件が満たされたときに発火します。

典型的な例はすべてのアカウントに標準で付属しています：解決済みになってから4日後にチケットをクローズするというものです。その条件は「ステータスがSolved」と「ステータス変更からの経過時間 > 96時間」で、アクションはチケットをClosedに設定します。この最後のアクションが重要な理由は、この後で説明します。

時間ベースの一般的なジョブには以下のようなものがあります：

• オープンから24時間経過後に優先度をNormalからHighへエスカレーションする。
• 返信待ちが48時間続いている顧客にリマインダーを送信する。
• 7日間更新のない放置チケットを自動的に解決済みにする。

一度だけ実行されるべきというルール（そして1時間ごとの落とし穴）

すべてのオートメーションは自己制御的でなければなりません。そうでなければ永遠に発火し続けてしまいます。Zendeskはこれを非公式なルールとして課しています。各オートメーションは、アクションによって自身の条件のいずれかを無効化する（チケットクローズの例のように、ステータスをClosedに設定することで「Solved」条件を偽にする）か、一度しか真にならない条件を使う必要があります。標準的なパターンはタグです。オートメーションが発火した際にタグを追加し、次に発火する前にそのタグが存在しないことを確認する、という仕組みです。

微妙ながら重要な点として、オートメーションは正確な分単位では発火しません。1時間ごとの実行は「その時間内のどこかの時点で」行われ、「Xからの経過時間」は正確な分数ではなく、経過した丸ごとの時間数をカウントします。時間に敏感な処理では、時間条件に「等しい」ではなく「より大きい」を優先しましょう。忙しいアカウントでは、完全一致のタイミングを丸ごと逃してしまうことがあるためです。知っておくべきハードリミットもあります。有効なオートメーションは最大500件まで、オートメーションが1時間に処理できるチケットは最大1,000件まで、そして1つのチケットがオートメーションによって更新される回数は最大100回までです。

具体的な手順については、eeselのステータス変更からの経過時間に基づいて動作するガイド（最もアクセスの多いオートメーションパターン）、解決から24時間後にチケットをクローズするガイド、そして営業時間向けのスケジュールベースの条件ガイドをご覧ください。

Zendeskマクロ：エージェント向けワンクリックショートカット

マクロは少し毛色が異なります。まったく自動ではなく、エージェントが必要に応じて適用する、あらかじめ用意されたアクションと定型文のセットです。トリガーとオートメーションを補完する、エージェント側のツールと考えるとよいでしょう。

1つのマクロで、担当者の設定、タグの追加、種別・優先度・ステータスの変更、そして定型の公開返信や内部メモの挿入までを、すべてワンクリックで行えます。この「Redirect to Careers Page」マクロのプレビューは、そのバンドル全体を示しています。担当者を設定し、追跡用タグを追加し、種別をQuestion、ステータスをSolvedに設定し、すぐに送信できる返信を貼り付けます。

マクロを作成する際、コメントエディタはリッチテキストと{{ticket.requester.name}}のようなプレースホルダーに対応しており、1つのテンプレートがチケットごとに自動的にパーソナライズされます。

エージェントはチケット画面からマクロを適用でき、Zendeskは「よく使う」リストを表示するため、頻用マクロにワンクリックでアクセスできます。

マクロには2種類あります。個人マクロ（作成したエージェントのみに表示）と、共有マクロ（管理者が全エージェントまたは特定のグループ向けに作成）です。ベストプラクティスは、すべてのマクロにフィールド変更と返信テキストの両方を組み込むことです。ステータスを変えるだけのマクロは、標準メッセージを送る機会を無駄にしてしまいます。詳しくは、eeselのマクロアクション、コメントとステータス変更の組み合わせ、マクロを大規模に管理するについてのガイドをご覧ください。

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

システム全体を一画面にまとめました。ワークフローを設計する際は、該当する行を見つければ、どのツールを構築すべきかがわかります。

これらを実際のワークフローに組み込む方法をさらに深く知りたい場合は、Zendeskワークフロー自動化ガイドと、より広い視点のサポートチケット自動化ガイドがおすすめです。

Zendeskのネイティブ自動化の限界

このルールエンジンは本当に高性能で、ルーティング、通知、細々とした整理業務においては非の打ちどころがありません。しかし、大きく依存し始めると、粗さが見え始めます。これらは単体では致命的な欠点ではありませんが、組み合わさることで、チームがより多くを求め始める理由になります。

オートメーションエディタはトリガーエディタに機能面で遅れている。 トリガーエディタには検索可能な条件ピッカーが追加されましたが、オートメーションエディタにはありません。カスタムフィールドを多く使う管理者は、これを日々実感しています。2026年3月のZendeskコミュニティのコメントで、ある管理者はこう述べています。

「作業していてとにかくイライラします。条件フィールドを見つけるために入力を始めることができません。カスタムチケットフィールドに基づく条件が必要な場合、延々とスクロールし続けなければなりません。」

ネイティブな利用状況分析がない。 Zendeskには、どのトリガーやオートメーションが最も多く発火しているか、あるいはエージェントが実際にどのマクロを使っているかを示す組み込みレポートがありません。標準的な回避策は、すべてのルールに追跡用タグを追加し、Exploreでそのタグの出現回数をカウントすることですが、これはまさに自分で構築する必要のないはずの配管作業です。

100回の更新上限は静かに機能不全を起こす。 各チケットは、オートメーションによって最大100回まで更新できます。チケットがこの上限に達すると、Zendeskはシステムノートを追加しますが、UI上では検索できないため、これを確実に検知する唯一の方法はチケット監査APIです。オートメーションのドキュメントにある2025年1月のスレッドでは、あるチームが何の警告もなくこの上限に真正面からぶつかった様子が説明されています。

タイミングが不正確で、クローズ済みチケットは対象外。 1時間ごとの実行は、おおよそ60分単位の粒度しかなく、自動クローズには十分でも、厳密なSLA連動のワークフローにとってはもどかしいものです。そして、トリガーもオートメーションもクローズ済みチケットでは実行されないため、クローズ後の処理（データクリーンアップや遅延CSATトリガーなど）には不格好な回避策が必要になります。

最大の問題：どれもチケットを解決しない。 これが最も重要な限界です。ここで紹介したすべてのツールは、チケットを移動させ、タグを付け、通知し、クローズするだけです。顧客の質問を読んだり、回答を書いたりするものは1つもありません。返信はすべて、依然としてエージェントが入力しています。このルールエンジンは優れた配管ですが、配管はドアを開けて対応してはくれません。

これこそ、Zendesk自身のAIレイヤーが埋めようとしているギャップであり、ここから話（そして請求額）が変わってきます。ZendeskのAI Agentsには、Essentialティア（バンドル済み、ナレッジベース回答のみ）とAdvancedティア（Ultimate.ai由来のフロービルダーでアクションとインテグレーションが可能）があり、さらに1エージェントあたり月額約50ドルのCopilotアドオンもあります。落とし穴は課金方法です。AIの作業は「自動解決」として計測され、レビューによれば、コミット枠を超えると1解決あたり1.20〜1.50ドルを支払っているという報告が一貫して見られます。あるオペレーターはr/Zendeskでその反応をこうまとめています。

"From what I can see in regards to this new 'Automated Resolution' pricing model, we'll be paying about $1.50–$1.20 per resolution."

私たちも営業電話で同じ声を聞いています。月間約500件のZendeskチケットを扱うある米国の医療系サポートチームは、「Zendesk AIソリューションを試してみたが、ほとんど不十分で割高だと感じた」と語り、積極的に代替手段を探していました。ネイティブのルールは優れていますが、ネイティブの解決レイヤーこそが、チームがぐらつき始めるポイントです。

Zendeskのネイティブ自動化に代わる選択肢

ここで言う「代替手段」は、実際に何が足りないかによって変わります。ルーティングやマクロには不満がなく、ただ解決件数課金のメーターを回さずにチケットを解決したいだけなら、Zendeskを離れる必要はまったくありません。その上にAIエージェントレイヤーを追加すればよいのです。Zendeskそのものが摩擦の原因であるなら、それはより大きな決断であり、Zendesk代替ツールと最良のAIヘルプデスクソフトウェアガイドで取り上げています。

「振り分けるだけでなく解決する」というケースでは、eesel AIが最も直接的な答えです。Zendesk内部にネイティブAIエージェントとしてインストールされ、過去のチケット、ヘルプセンター、既存のマクロから学習し、メール、チャット、メッセージングにわたってティア1の会話をエンドツーエンドで解決します。Zendesk自身のAIとの違いは2点あります。

シミュレーション機能は過小評価されがちなポイントです。eeselは実際の会話に触れる前に過去のチケットに対して動作を検証するため、何を解決し、どこでエスカレーションしたかを正確に確認できます。これは、Zendesk AIを有効化して結果を祈るのとは正反対のアプローチです。eeselは既存のトリガー、オートメーション、営業時間をそのまま維持するため、すでに構築したルールを取り除くのではなく、解決レイヤーを追加することになります。私たちが協業しているあるZendesk管理者は、こう簡潔に述べています。

「eesel AIはワークフローを効率化し、生産性を高め、より高いレベルのサービス一貫性を確保してくれます。」

Melissa Ryan氏、Zendesk管理者、Discuss.io（出典）

プラットフォームそのものを乗り換えたい場合は、Freshdeskの自動化やFreshserviceのチケット自動化が同様の領域を独自のAIアドオンでカバーしていますし、すでにそのCRMを使っているチームにはHubSpot Service Hubも検討する価値があります。しかし、ほとんどのチームにとっての正直な答えは、Zendeskのルールエンジン自体は十分に機能しており、足りないのは解決力であり、それは後から追加できるということです。

Zendesk向けにeeselを試す

eesel AIは、Zendesk内部で動作するAIエージェントで、ネイティブのルールエンジンにはできない唯一のこと、つまり実際にチケットを解決することを行います。過去のチケット、ヘルプセンター、マクロから学習し、ブランドに沿った返信を下書き・送信し、チケットフィールドを更新し、エッジケースはエスカレーションします。これらすべてを、すでに構築済みのトリガーやオートメーションを尊重しながら行います。

セットアップはノーコードで30分未満です。Zendesk Marketplaceからインストールし、eeselにナレッジを自動でインポートさせ、実際の顧客が目にする前に過去のチケットでシミュレーションを行います。料金は1チケットあたり定額0.40ドルで、席数課金はなく、自分で設定した支出上限があるため、月末に解決件数課金による予想外の請求に驚くこともありません。

無料で始める（クレジットカード不要）か、デモを予約して、まずは自社の過去のチケットに対する動作を確認できます。eeselを試してみましょう。