Zendesk自動化条件：チケット作成時の完全ガイド（2026年）

「Zendesk（ゼンデスク） automation conditions ticket created（自動化条件 チケット作成）」と検索すると、実際には存在しないものを探している可能性があります。簡単に言うと、Zendeskの自動化（automation）は時間ベースであり、1時間ごとに実行されます。「チケット作成（ticket created）」という条件はありません。実際には**トリガー（trigger）**を探しているのです。

トリガーと自動化はどちらもZendeskのビジネスルールですが、完全に異なるタイムラインで動作します。この混乱は、経験豊富な管理者（admin）でさえ困惑させます。これらのツールがどのように機能し、いつどちらを使用するか、そして期待どおりに機能するチケット作成ワークフローを設定する方法を正確に説明します。

混乱を理解する：トリガー vs 自動化

Zendeskが使用する用語は、混乱を招く可能性があります。トリガーと自動化はどちらも、一般的な意味では「自動化（automation）」です。定義したルールに基づいて、チケットを自動的に処理します。ただし、動作スケジュールが異なり、目的も異なります。公式な区別については、Zendeskのトリガーと自動化に関するドキュメントを参照してください。

トリガーはイベントベースです。 チケットに何かが起こるとすぐに発動します。顧客が新しいリクエストを送信すると、トリガーはすぐに適切なチームにルーティングし、優先度を設定し、確認メールを送信できます。これらはすべて数秒以内に行われます。

自動化は時間ベースです。 1時間ごとに実行され、時間の経過に関連する条件を確認します。「48時間後にフォローアップ」または「解決後96時間後にチケットをクローズ」などを考えます。自動化は、トリガーでは管理できない「様子見」のシナリオを処理します。

重要な区別：トリガーはイベントに応答し、自動化は時間に応答します。チケット作成時に何かをすぐに実行する必要がある場合は、チケット > が > 作成された条件を持つトリガーが必要です。数時間または数日後に何かを実行する必要がある場合は、自動化の出番です。

どちらのツールを使用するかを決定する簡単な方法を次に示します。

結論として、「チケットが作成されたとき」にワークフローが始まる場合は、トリガーを構築しています。「X時間後」に始まる場合は、自動化を構築しています。

「チケットが作成された」条件の説明

チケット > が > 作成された条件は、ほとんどのチケット作成ワークフローの基礎です。これがないと、トリガーはチケットが最初に送信されたときだけでなく、すべてのチケット更新で発動します。利用可能な条件の完全なリストについては、Zendeskトリガー条件リファレンスを参照してください。

条件の構文は次のとおりです。

• カテゴリ（Category）: チケット
• フィールド（Field）: が
• 演算子（Operator）: 作成された（または更新された）

この条件を追加すると、Zendeskに「真新しいチケットがシステムに入った場合にのみ、このトリガーを実行する」と指示します。これにより、エージェントがコメントを追加したり、ステータスを変更したり、チケットフィールドを変更したりした場合に、トリガーが発動するのを防ぎます。

Zendeskトリガーは、次の2種類の条件ロジックを使用します。

すべての条件（ALL conditions）（ANDロジック）： トリガーが発動するには、このセクションのすべての条件がtrueである必要があります。ここには、「チケット > が > 作成された」条件と、その他の要件を記述します。

いずれかの条件（ANY conditions）（ORロジック）： このセクションの少なくとも1つの条件がtrueである必要があります。「件名に「緊急（urgent）」または「非常事態（emergency）」が含まれている場合」などのシナリオに使用します。

「チケットが作成された」と組み合わせて使用​​する一般的な条件は次のとおりです。

• チャネル（Channel）: チケットがメール、Webフォーム、チャット、APIのいずれから来たかに基づいて、異なるルーティングを行います。
• 件名テキスト（Subject text）: 「払い戻し（refund）」、「請求（billing）」、または「緊急（urgent）」などのキーワードを探します。
• 受信日時（Received at）: どのサポートメールアドレスが使用されたかに基づいて、チケットを異なる方法で処理します。
• 組織（Organization）: VIP顧客または特定のクライアントグループに異なるルールを適用します。
• リクエスタータグ（Requester tags）: 定義した顧客セグメントに基づいてルーティングします。

最初のチケット作成トリガーの設定

チケットが作成されたときに発動するトリガーを作成する手順を見ていきましょう。この例では、請求関連のチケットを財務チームにルーティングします。

ステップ1：管理センター（Admin Center）のトリガーに移動する

管理センター（Admin Center） > オブジェクトとルール（Objects and rules） > ビジネスルール（Business rules） > **トリガー（Triggers）**に移動します。詳細なナビゲーションヘルプについては、Zendeskのチケットトリガーの作成に関するガイドを参照してください。

Zendeskが提供する標準のトリガーを含む、既存のトリガーのリストが表示されます。これらは、リクエスターにチケットが受信されたことを通知するなどの基本を処理します。順序に注意してください。トリガーは上から下に実行されるため、位置が重要です。

ステップ2：新しいトリガーを作成する

**トリガーを作成（Create trigger）**をクリックし、わかりやすい名前を付けます。適切な命名が重要です。「財務チームへの請求チケットのルーティング（Route billing tickets to Finance）」は、「請求トリガー（Billing trigger）」よりも明確です。

トリガーの機能とその理由を説明する説明を追加します。6か月後にトラブルシューティングを行うときに、将来の自分（および他の管理者）に感謝されるでしょう。

整理するためのカテゴリを選択します。まだカテゴリがない場合は、作成できます。多くのチームは、ルーティング（Routing）、通知（Notifications）、エスカレーション（Escalations）などの機能で整理しています。

ステップ3：チケット作成条件を追加する

**次のすべての条件を満たす（Meet ALL of the following conditions）**セクションで、次を追加します。

• チケット（Ticket） > が（Is） > 作成された（Created）

これが基礎です。これがないと、トリガーはすべての更新で発動します。

次に、特定のルーティング条件を追加します。

• チケット（Ticket） > 件名テキスト（Subject text） > 次の単語の少なくとも1つを含む（Contains at least one of the following words）: 払い戻し（refund） 請求書（invoice） 支払い（payment） 請求（billing）

ステップ4：追加の条件を定義する

このトリガーが発動するタイミングを絞り込む必要があるその他の条件を追加します。例えば：

• リクエスター（Requester） > 組織（Organization） > ではない（Is not） > VIP顧客（VIP Customers）（VIP請求を異なる方法で処理する場合）
• チケット（Ticket） > チャネル（Channel） > が（Is） > メール（Email）（メールチケットのみにこれが必要な場合）

覚えておいてください：トリガーが発動するには、すべての条件がtrueである必要があります。「これまたはそれ」ロジックが必要な場合は、いずれかの条件（ANY conditions）セクションを使用します。

ステップ5：アクションを設定する

条件は、トリガーがいつ実行されるかを決定します。アクションは、何が起こるかを決定します。

請求の例では、次のアクションを追加します。

• グループ（Group） > 財務チーム（Finance Team）
• 優先度（Priority） > 通常（Normal）
• タグを追加（Add tags） > billing
• グループに通知（Notify group） > 財務チーム（Finance Team）（必要に応じて、すぐにアラートを受け取る場合）

**作成（Create）**をクリックして、トリガーを保存します。件名に「billing」を含むチケットを作成し、正しくルーティングされることを確認してテストします。

チケット作成のための一般的な自動化レシピ

ワークフローに適用できる5つの実用的なトリガー構成を次に示します。

レシピ1：メールアドレスによる自動ルーティング

ユースケース（Use case）: 部門ごとに個別のサポートアドレスがあります（support@billing.com vs support@technical.com）。

条件（Conditions）:

• チケット（Ticket） > が（Is） > 作成された（Created）
• チケット（Ticket） > 受信日時（Received at） > が（Is） > support@billing.com

アクション（Actions）:

• グループ（Group） > 請求チーム（Billing Team）
• タグを追加（Add tags） > billing-inquiry

レシピ2：VIP顧客の優先度エスカレーション

ユースケース（Use case）: VIP顧客は自動的に高い優先度を取得します。

条件（Conditions）:

• チケット（Ticket） > が（Is） > 作成された（Created）
• リクエスター（Requester） > 組織（Organization） > が（Is） > VIP顧客（VIP Customers）

アクション（Actions）:

• 優先度（Priority） > 高（High）
• グループ（Group） > プレミアムサポート（Premium Support）
• タグを追加（Add tags） > vip-priority

レシピ3：件名のキーワードでタグ付けと分類

ユースケース（Use case）: 顧客が尋ねていることに基づいて、チケットに自動的にタグを付けます。

条件（Conditions）:

• チケット（Ticket） > が（Is） > 作成された（Created）
• チケット（Ticket） > 件名テキスト（Subject text） > 次の単語の少なくとも1つを含む（Contains at least one of the following words）: バグ（bug） エラー（error） 壊れた（broken） 動作しない（not working）

アクション（Actions）:

• タグを追加（Add tags） > technical-issue bug-report
• タイプ（Type） > 問題（Problem）

レシピ4：組織に基づいて自動割り当て

ユースケース（Use case）: 特定のアカウントマネージャーが特定のクライアントを処理します。

条件（Conditions）:

• チケット（Ticket） > が（Is） > 作成された（Created）
• リクエスター（Requester） > 組織（Organization） > が（Is） > Acme Corporation

アクション（Actions）:

• 担当者（Assignee） > Sarah Johnson
• グループ（Group） > エンタープライズアカウント（Enterprise Accounts）

レシピ5：カスタムメッセージングで確認メールを送信する

ユースケース（Use case）: リクエストの種類ごとに異なる自動返信。

条件（Conditions）:

• チケット（Ticket） > が（Is） > 作成された（Created）
• チケット（Ticket） > チャネル（Channel） > が（Is） > Webフォーム（Web form）

アクション（Actions）:

• リクエスターに通知（Notify requester） > メール件名（Email subject）: "リクエストを受け付けました（We received your request）" > 本文（Body）: カスタム確認メッセージ（Custom acknowledgment message）

ベストプラクティスとよくある落とし穴

経験豊富なZendesk管理者でも、これらの間違いを犯します。注意すべき点は次のとおりです。

トリガーの順序が重要です。 トリガーは上から下に実行されます。リストの上位にあるトリガーは、下位のトリガーが発動するかどうかに影響を与える方法でチケットを変更する可能性があります。最も具体的なトリガーを最初に、一般的なトリガーを最後に配置します。

新しいチケットワークフローには、常に「チケットが作成された」条件を含めてください。 これがないと、トリガーはすべての更新で発動します。それはあなたが望んでいることではありません。

ライブに移行する前にテストしてください。 条件に一致するテストチケットを作成し、アクションが正しく実行されることを確認します。チケットイベントをチェックして、どのトリガーが発動したかを正確に確認します。

明確でわかりやすい名前を使用してください。 「VIPチケットをプレミアムサポートにルーティングする（Route VIP tickets to Premium Support）」は、「VIPトリガー2（VIP trigger 2）」よりもはるかに優れています。名前に目的を含めます。

競合するトリガーに注意してください。 同じフィールドを変更する2つのトリガーは、予測できない結果を生み出す可能性があります。トリガーロジックを文書化し、四半期ごとにレビューします。

自動化の制限を覚えておいてください。 時間ベースのフォローアップに自動化を使用している場合は、各自動化が1時間あたり1,000件のチケットしか処理できないことを知っておいてください。条件を満たすチケットが多い場合は、次の時間までキューに入れられます。これらの制限の詳細については、Zendeskの自動化に関するドキュメントを参照してください。

無効化条件はループを防ぎます。 自動化には、条件を無効にするアクション（ステータスを解決済みからクローズ済みに変更するなど）を含める必要があります。これがないと、自動化が繰り返し発動する可能性があります。

eesel AIでZendeskを強化する

Zendeskのトリガーと自動化は、チケットルーティングと基本的なワークフローのメカニズムを処理します。しかし、顧客リクエストの内容を理解していません。チケットを読んで、単純なキーワードマッチングを超えて、意図、感情、または緊急度を判断することはできません。

そこで私たちの出番です。eesel AIはZendeskと統合して、既存のトリガーの上にインテリジェントな自動化を追加します。

当社のAIエージェント（AI Agent）は、チケットを自律的に解決できます。受信リクエストを読み取り、ナレッジベースに基づいて応答を起草し、人間の介入なしに応答を送信することもできます。人間のタッチが必要なチケットについては、完全なコンテキストでインテリジェントにエスカレーションします。

AIトリアージ（AI Triage）は、単純なキーワードタグ付けを超えています。顧客が実際に何を聞いているかを理解し、インテント、感情、および緊急度でチケットを分類します。ルールベースのトリガーだけよりも正確にチケットをルーティングできます。

人間のエージェントのために、AIコパイロット（AI Copilot）はすぐに返信を起草します。エージェントは、過去のチケットとナレッジベースに基づいて、すぐに送信できる応答を確認します。必要に応じてレビュー、編集、送信します。応答時間は劇的に短縮され、品質は一貫しています。

当社が推奨するアプローチ：最初にガイダンスから始め、次に自律性へとレベルアップします。過去のチケットでeeselを実行して、どのように実行されるかを確認します。自信がついたら、レビューのために返信を起草させます。それが証明されたら、完全な自律的な解決に拡大します。

今すぐZendeskワークフローの自動化を開始する

これで、重要な区別を理解できました。トリガーはチケット作成時の即時アクションを処理し、自動化は時間ベースのフォローアップを処理します。チケット > が > 作成された条件は、イベントベースのワークフローの基礎です。

単純なトリガーから始めます。メールアドレスまたは組織でルーティングします。キーワードに基づいてタグを追加します。確認メールを送信します。慣れてきたら、複数の条件を持つより洗練されたワークフローを構築します。

ライブに移行する前に、すべてをテストすることを忘れないでください。わかりやすい名前を使用してください。ロジックを文書化します。四半期ごとにトリガーを確認して、古くなったルールをキャッチします。

ルールベースの自動化を超えて、Zendeskワークフローに真のインテリジェンスを追加したい場合は、eesel AIをお試しください。既存のZendeskアカウントに接続し、過去のチケットとナレッジベースから学習し、チームがチケットをより迅速に解決できるように支援を開始します。料金を確認して、ボリュームに合ったプランを確認してください。ZendeskのAIエージェント機能を調べて、ヘルプデスクで利用できるネイティブオプションを理解することもできます。