Zendeskの自動化が実行されない：完全なトラブルシューティングガイド

本来動作するはずの自動化を構築し、すべてのテストに合格するのを見守り、それが実際には本番環境で何もしていないことを発見するほど、イライラすることはありません。もしあなたがここにいるなら、おそらくそのような経験があるでしょう。あなたのZendeskの自動化は正しく設定されており、条件は正しいように見えますが、チケットは触れられずにそこに座っているだけです。

朗報は？ほとんどの自動化の失敗は、いくつかの一般的な問題から生じており、何を探すべきかを知っていれば、比較的簡単に修正できることです。このガイドでは、Zendeskの自動化が実行されない理由を診断し、軌道に乗せるための体系的なアプローチについて説明します。

そして、Zendeskのルールベースのシステムでできることの限界に達していることに気づいた場合は、従来のトリガーや自動化では苦労するインテリジェントなルーティングと自動化を、当社のeesel AIのような最新のAI代替手段がどのように処理できるかについても見ていきます。

Zendeskの自動化の仕組み（およびその故障理由）

修正に入る前に、自動化が実際にどのように機能するかを簡単に説明しましょう。Zendeskの自動化は、チケットに何かが起こったときにすぐに発動するトリガーとは異なり、スケジュールに基づいて実行される時間ベースのルールです。

知っておくべきことは次のとおりです。

• クローズされていないすべてのチケットに対して、1時間に1回実行されます。 正確に60分ごとではありませんが、各時間の「ある時点」で実行されます。
• 1サイクルあたり最大1,000件のチケットを処理します。 一致するチケットがそれ以上ある場合、残りは次の時間まで待機します。
• クローズされたチケットには触れません。 チケットがクローズされると、自動化はそれを変更できません。
• 各チケットは、そのライフサイクル中に自動化によって100回までしか更新できません（チケットをクローズする自動化には1つの例外があります）。

覚えておくべき重要なことは、自動化はリアルタイムではないということです。24時間後にアクションを実行するように自動化を設定した場合、正確に24時間後に発動するわけではありません。24時間経過後に発生する自動化の実行中に発動します。このタイミングの変動が、多くの「Zendeskの自動化が実行されない」問題の根本原因です。

最も一般的な理由：「～時間経過」の条件の間違い

Zendeskの自動化が実行されない場合、最初に確認することは、時間ベースの条件で「～は」の代わりに「～より大きい」を使用しているかどうかです。

問題は次のとおりです。「保留になってから24時間～は」のような条件を設定すると、Zendeskにそのチケットを正確に24時間でキャッチするように求めていることになります。しかし、自動化は1時間ごと（予測可能な時間ではなく）に実行されるため、その正確なウィンドウを見逃すのは非常に簡単です。

たとえば、チケットが午前10時03分に保留になったとします。自動化が午前11時01分に実行された場合、チケットは58分間しか保留になっていないため、条件は満たされません。次の実行が午後12時06分の場合、チケットは2時間3分間保留になっています。「～は24」の条件はもはや真ではなく、自動化は決して発動しません。

dominik.jemecという名前のZendeskコミュニティメンバーは、まさにこの問題に遭遇しました。彼らは2つの自動化を持っていました。1つは3日後に動作し、もう1つは7日後にトリガーされるはずでした。3日間の自動化は正常に動作しましたが、7日間の自動化は決して発動しませんでした。彼らは、Zendeskが複数の自動化を連続して実行できないのではないかと疑っていました。実際の問題は？時間の条件に「～は」の代わりに「～より大きい」を使用していたことです。

「Zendeskの自動化がトリガーされないという問題があります... 3日間の自動化は期待どおりに動作しました... しかし、7日間の自動化はまったくトリガーされません... これについてZendeskの自動化スペシャリストと話し合ったところ、Zendeskは2つの自動化を連続して実行することを許可していない可能性があると考えています。」 dominik.jemec、Zendeskコミュニティ

「～より大きい」に切り替えた後、自動化は完全に動作しました。

「魔法のように動作しました。ありがとうございます！」 dominik.jemec

修正： 時間ベースの条件には、常に「～より大きい」（または「～より小さい」）を使用してください。「～より大きい24」は、24時間以上保留になっているすべてのチケットに対して真と評価され、自動化がそれをキャッチするための広いウィンドウが与えられます。

もう1つ理解しておくべきこと：Zendeskは「時間ゼロ」から時間をカウントします。イベントが発生した後に自動化が最初に実行される時間は、ゼロ時間としてカウントされます。後続の1時間ごとの実行は、1時間としてカウントされます。したがって、チケットが午前9時15分に保留になり、自動化が午前9時47分（32分後）に実行された場合、それはゼロ時間です。午前10時47分の次の実行は、1時間としてカウントされます。

欠落しているまたは誤った無効化条件

Zendeskの自動化の問題の2番目に一般的な原因は、無効化条件が欠落していることです。それらがないと、自動化は同じチケットで繰り返し実行されます。

ここで何が起こるか：自動化は1時間ごとに条件が満たされているかどうかを確認します。「オープンになってから8時間より大きい」場合にマネージャーに通知する自動化があり、無効化条件がない場合、チケットのステータスが変わるまで、そのマネージャーは毎時間通知を受け取ります。

これを防ぐための標準的なパターンは、タグを使用することです。

1. 条件を追加：「タグに次のいずれも含まれていない：automation_fired」
2. アクションを追加：「タグを追加：automation_fired」

タグが追加されると、チケットは条件を満たさなくなるため、自動化は再び発動しません。タグはチケットのステータスが変わっても保持されるため、ステータスベースの無効化よりも信頼性が高くなります。

注意すべき一般的な間違い：

• 存在しないことを確認した後に、タグアクションを追加するのを忘れる
• 別の自動化またはトリガーによって削除されるタグを使用する
• 複数の自動化が互いのタグを妨害する可能性があることに気づかない

無効化条件が機能していることを確認するには、チケットのイベントログ（チケットURLに/eventsを追加）を確認し、繰り返される自動化アクションを探します。

自動化の失敗のその他の一般的な原因

チケットステータスの問題

クローズされたチケットは、自動化によって変更できません。これは厳密な制限です。自動化の条件がクローズされたチケットと一致する場合、自動化は単にそれに対してアクションを実行しません。Zendeskには「解決済み」と「クローズ済み」の区別もあります。解決済みのチケットはまだ更新できますが、クローズされたチケットはロックされています。

古いチケットでアクションを自動化しようとしている場合は、Zendeskのデフォルトの自動化（解決済みのチケットを96時間後にクローズする）によってクローズされていないことを確認してください。

1000件のチケット制限

各自動化は、1時間あたり1,000件のチケットしか処理できません。大量のバックログがあり、1,000件を超えるチケットが条件を満たしている場合、残りのチケットは次のサイクルまで待機します。

これが問題であるかどうかを特定する方法：

• 自動化のリビジョン履歴を確認して、処理されたチケットの数を確認します
• 正確に1,000件のチケットが処理されていることが一貫して確認できる場合は、制限に達しています
• 大規模な運用では、複数の自動化に作業を分散することを検討する必要があります

条件ロジックエラー（すべて対いずれか）

Zendeskには、条件のための2つのセクションがあります。「次のすべての条件を満たす」と「次のいずれかの条件を満たす」です。ロジックを理解することが重要です。

すべてはANDを意味します。 このセクションのすべての条件が真である必要があります。

いずれかはORを意味します。 このセクションの少なくとも1つの条件が真である必要があります。

一般的な間違いは、複数のステータス条件をすべてのセクションに配置することです。たとえば、「ステータスは新規」AND「ステータスはオープン」がすべてにある場合、チケットは2つのステータスを同時に持つことができないため、自動化は決して実行されません。これらは代わりにいずれかのセクションに配置する必要があります。

自動化の順序と競合

自動化はリストに表示される順序で実行され、1つの自動化のアクションが別の自動化に影響を与える可能性があります。次のシナリオを検討してください。

• 自動化＃1：ステータスが48時間より大きい保留中の場合、担当者に通知する
• 自動化＃2：ステータスが48時間より大きい保留中の場合、優先度を高に変更する
• 自動化＃3：優先度が高い場合、エスカレーショングループに通知する

これらが実行されると、自動化＃1が発動し、次に＃2が発動して優先度を変更します。自動化＃3が実行されると、優先度が高いことがわかり、発動します。この場合、自動化＃3を発動させたくない場合は、条件または自動化の順序を調整する必要があります。

統合とWebhookの問題

n8nやGrowthDotのようなサードパーティの統合を使用している場合、障害モードはネイティブのZendesk自動化とは異なります。

Webhookベースの統合の一般的な問題は、テストWebhookはZendeskに表示されますが、本番環境のものは表示されないことです。または、一度表示されてから消えます。

「Zendeskで新しいタスクが作成されたときにトリガーされるワークフローがあります... ワークフローを作成していたとき、「イベントをリッスン」のテストを行い、Zendeskにテストタスクを送信しましたが、問題なく取得されました。しかし、ワークフローを公開して以来、トリガーはZendeskタスクを取得していません。」 ameliadenormann、GitHubの問題

別のユーザーも同じパターンを確認しました。

「私たちも同じ問題を抱えています。テストWebhookはZendeskに表示され、テストが完了すると消えますが、本番環境のものはまったく表示されないか、数回の試行で1回だけ表示され、識別可能な理由もなく消えます。」 tornister76、GitHubの問題

Webhookの問題のトラブルシューティング：

• イベントサブスクリプションがZendeskの管理> Webhookで正しく構成されていることを確認します
• Webhookが正しいイベント（たとえば、「サポートユーザーが作成された」だけでなく「サポートユーザーのタグが変更された」）でトリガーされるように設定されていることを確認します
• ZendeskのWebhookログを見て、リクエストが受信されているかどうかを確認します
• 特にn8nの場合は、本番環境に正しいWebhook URL（テストURLではない）を使用していることを確認します

ステップバイステップの診断プロセス

Zendeskの自動化が実行されていない場合は、次の体系的なアプローチに従ってください。

ステップ1：チケットで条件が実際に満たされていることを確認します 自動化をトリガーしたはずのチケットを開き、すべての条件を手動で確認します。ステータスは期待どおりですか？実際に十分な時間が経過しましたか？それをブロックしている可能性のあるタグはありますか？

ステップ2：チケットイベントを確認します チケットURLの末尾に/eventsを追加して、完全なイベント履歴を表示します。「自動化」を検索して、どの自動化がいつ実行されたかを確認します。自動化がここに表示されない場合は、まったく実行されていません。

ステップ3：自動化のリビジョン履歴を確認します Zendeskは、どの自動化がいつ実行され、処理されたチケットの数を示す自動化アクティビティのログを保持します。これは、自動化が実行されているが、一致するチケットが見つからないかどうかを特定するのに役立ちます。

ステップ4：単一のチケットでテストします キュー全体に展開する前に、テストチケットを作成し、自動化が期待どおりに動作することを確認します。これにより、実際のお客様とのやり取りに影響を与える前に問題をキャッチできます。

ステップ5：競合を確認します 同じチケットを変更している可能性のある他の自動化またはトリガーを探します。1つの自動化のアクションが別の自動化の発動を防ぐ可能性があります。

予防：実際に動作する自動化の構築

自動化の問題を修正する最良の方法は、それらを防止することです。経験豊富なZendesk管理者が従うプラクティスを次に示します。

• 時間条件には常に「～より大きい」を使用してください。 非常に具体的な理由があり、リスクを理解している場合を除き、「～は」は決して使用しないでください。

• 常に無効化タグを含めてください。 タグパターン（不在を確認し、アクションとして追加）は、繰り返しの実行を防ぎます。

• 自動化を文書化します。 各自動化が何をするか、ビジネス時間とカレンダー時間のどちらを使用するか、自動化間の依存関係をメモします。

• 展開前に徹底的にテストします。 テストチケットを使用し、さまざまなシナリオで動作を確認します。

• 自動化アクティビティを定期的に監視します。 リビジョン履歴を定期的に確認して、問題が発生する前にキャッチします。

Zendeskの自動化の代替手段を検討する場合

Zendeskのルールベースの自動化は、簡単な時間ベースのアクションには適していますが、制限があります。次のような場合は、より洗練されたものが必要になる場合があります。

• 常に1,000件のチケット制限に達している
• ルーティングロジックが単純なIF/THENルールには複雑すぎる
• メタデータだけでなく、チケットの内容に基づいてインテリジェントな優先順位付けが必要
• 手動のチケットタグ付けと分類を減らしたい

ここで、AI搭載の代替手段が登場します。eesel AIでは、サポートの自動化に異なるアプローチを取っています。エッジケースが発生すると壊れる厳密なルールの代わりに、当社のAIエージェントは、過去のチケットとヘルプセンターから学習して、インテリジェントなルーティングの決定を行います。

仕組みは次のとおりです。eesel AIは受信チケットを読み取り、お客様が実際に必要としているものに基づいて適切なチームにルーティングします。ルールベースの自動化では不可能な方法で、緊急度、感情、意図を識別できます。次に、時間ベースのZendesk自動化が、スケジュールに従ってフォローアップとエスカレーションを処理します。

また、Zendeskと連携して、自動化がチケットを見る前に、チケットを自動的にタグ付け、ルーティング、優先順位付けするAIトリアージも提供しています。その結果、チケットがより迅速に適切な人に届き、自動化が意思決定ではなくタイミングを処理するワークフローが実現します。

Zendeskの自動化システムから恩恵を受けるよりも、それと戦っていることに気づいた場合は、AIができることを検討する時期かもしれません。eesel AIがZendeskとどのように統合されるかを確認し、自分のチケットで試して、違いを確認できます。