ステータスが「オープン」に変更されたときにZendeskトリガーを作成する方法
Stevia Putri
最終更新 February 24, 2026
ヘルプデスクでの自動化の設定は、新しい言語を学ぶように感じられるかもしれません。システムを自分のために機能させようとしていますが、時には自分がシステムのために働いているように感じることがあります。最も一般的な自動化のニーズの1つは、チケットのステータスが「オープン」に変更されたときにアクションをトリガーすることです。エージェントに再オープンされたチケットを通知したり、緊急の問題をエスカレートしたり、単にワークフローのメトリクスを追跡したりする場合でも、このトリガーを正しく設定することが不可欠です。
このガイドでは、ステータスが「オープン」に変更されたときにZendesk（ゼンデスク）トリガーを正確に作成する方法、一般的なユースケース、および計画どおりに進まない場合のトラブルシューティングのヒントについて詳しく説明します。
開始するために必要なもの
トリガーの作成に入る前に、いくつかの基本事項がカバーされていることを確認してください。
- Zendesk Supportへの管理者アクセス。 トリガーを作成および変更するには、管理者権限が必要です。
- チケットワークフローの理解。 チケットがシステム内をどのように移動するか（新規 → オープン → 保留 → 解決済 → クローズ）を把握します。
- トリガーが達成すべき明確な目標。 誰かに通知しますか？フィールドを更新しますか？チケットをエスカレートしますか？
- オプション：カスタムフィールドまたはタグ。 条件を追加する場合は、これらを準備しておきます。
これらのいずれかが欠落している場合は、ここで一時停止して整理してください。明確な計画なしにトリガーを作成すると、解決するよりも多くの問題を作成する自動化につながることがよくあります。
基本的なトリガーを超えることを検討しているチーム向けに、eesel AIはZendeskと統合して、既存のチケットとヘルプセンターのコンテンツから学習するインテリジェントな自動化を提供します。
Zendeskのステータス変更トリガーの仕組み
トリガーの背後にあるメカニズムを理解すると、後で何時間ものフラストレーションを回避できます。短いバージョンを次に示します。トリガーは、条件とアクションから構築されます。条件はトリガーが起動するタイミングを定義し、アクションはトリガーが起動したときに何が起こるかを定義します。
このガイドの重要な区別は、「ステータスが」と「ステータスが変更された」の違いです。
- 「ステータスがオープン」 は、現在の状態を確認します。チケットがすでにオープンになっている場合、この条件は真です。
- 「ステータスがオープンに変更」 は、移行を確認します。チケットが別のステータス（新規、保留、または解決済など）からオープンに移動した場合にのみ起動します。
通常、トリガーを何かが 発生した とき（ステータスの変更）に起動させたいので、何かが ある とき（静的な状態）に起動させたくないため、これは重要です。
トリガーは、条件を満たすイベントが発生した直後に起動します。遅延はありません。顧客が保留中のチケットに返信し、ステータスがオープンに変更された場合、トリガーは数秒以内に実行されます。
Zendeskの標準的なチケットライフサイクルは、次のようになります：新規 → オープン → 保留 → 解決済 → クローズ。チケットは作成時に新規として開始され、エージェントに割り当てられるとオープンになり、顧客の入力を待つときに保留に移動し、解決されると解決済としてマークされ、最後に（通常は設定された期間後に自動的に）クローズされます。
もう1つ：アカウントでカスタムチケットステータスが有効になっている場合（Growthプラン以上で利用可能）、単に「ステータス」の代わりに「ステータスカテゴリ」条件を使用します。標準ステータスは、複数のカスタムステータスを含めることができるカテゴリになります。
ステップバイステップ：ステータスがオープンに変更されたトリガーの作成
次に、トリガーの構築について説明します。次の手順に従って、数分で動作する自動化を実現できます。
ステップ1：トリガーページにアクセスする
管理センター > オブジェクトとルール > ビジネスルール > トリガー に移動します。これは、すべてのトリガー管理のコマンドセンターです。
既存のトリガーのリストが表示されます（Zendeskは、新しいアカウント用にいくつかの標準トリガーを作成します）。これらのトリガーが何をするかを正確に理解していない限り、削除しないでください。多くは、ヘルプデスクの機能を維持する基本的な通知を処理します。
ステップ2：新しいトリガーを作成する
トリガーを追加 ボタンをクリックします。将来の自分（またはチームメイト）が理解できる説明的な名前をトリガーに付けます。次のようなもの：
- 「チケットが再オープンされたときに担当者に通知する」
- 「顧客の返信時に緊急チケットをエスカレートする」
- 「7日後に再オープンされたチケットにタグを付ける」
「トリガー1」や「新しいトリガー」のようなあいまいな名前は避けてください。後で数十のトリガーがあり、1つをトラブルシューティングする必要がある場合に、感謝することになります。
ステップ3：条件を設定する
ここで魔法が起こります。条件セクションで、次を追加します。
次のすべての条件を満たす：
- チケット > ステータスカテゴリ | 次に変更 | オープン
これがコア条件です。ただし、トリガーをより具体的にするために、さらに追加できます。
オプションの追加：
- チケット > コメント | 次に等しい | 公開 （内部メモではなく、顧客の返信でのみ起動するようにするため）
- チケット > タグ | 次のいずれも含まない | [your-tag] （トリガーが同じチケットで2回起動するのを防ぐため）
- チケット > 作成からの時間 | 次より大きい | 1 （新しいチケットと再オープンされたチケットを区別するため）
「ステータスカテゴリ」と「ステータス」の区別はここで重要です。カスタムステータスが有効になっている場合は、「ステータスカテゴリ」を使用して、オープンのすべてのバリエーションをキャッチします。カスタムステータスなしのTeamプランを使用している場合は、代わりに「ステータス」が表示されます。
ステップ4：アクションを構成する
次に、条件が満たされたときに何が起こるかを決定します。ステータスがオープンに変更されたトリガーの一般的なアクションには、次のものがあります。
コメントの更新を担当者に通知する これは、チケットに割り当てられている人にメールを送信します。再オープンされたチケットの最も一般的なアクションです。
タグを追加する 「再オープン」または「顧客が返信」のようなタグは、レポートに役立ち、トリガーループを防ぐことができます。
優先度を設定する 解決済みのチケットが再オープンされた場合は、自動的に優先度を高くしたい場合があります。
カスタムフィールドを更新する 「再オープンの数」や「再オープン後の最初の応答までの時間」のようなメトリクスを追跡します。
グループにメールを送信する 特定のチケットが再オープンされたときに、特定チーム（エスカレーションやTier 2サポートなど）に通知します。
1つのトリガーに複数のアクションを追加できます。ただし、アクションが多いほど、何か問題が発生した場合のトラブルシューティングが複雑になることを覚えておいてください。
ステップ5：テストしてアクティブ化する
トリガーをライブにする前に、テストします。
- トリガーを保存します（自動的にアクティブになります）
- テストチケットを作成するか、既存のチケットを見つけます
- ステータスを保留に変更し、誰か（または別のアカウント）に公開コメントを追加させます
- チケットのステータスがオープンに変更されるのを確認します
- トリガーが起動したことを確認します（メール通知、タグ、またはフィールドの更新を確認します）
期待どおりに動作しない場合は、トリガーの位置を確認してください。Zendeskは、トリガーを上から下の順に処理します。別のトリガーが最初にチケットを変更している場合、トリガーが起動しない可能性があります。
ステータスがオープンに変更されたトリガーの一般的なユースケース
このトリガータイプが輝く実際のシナリオを見てみましょう。
再オープンされたチケットのエージェントへの通知
古典的なユースケース：顧客が解決に満足せず、解決済みのチケットに返信します。ステータスがオープンに変更され、元の担当者にすぐに通知する必要があります。
条件：
- ステータスカテゴリ | 次に変更 | オープン
- コメント | 次に等しい | 公開
アクション：
- ユーザーにメールを送信 | （担当者） | 件名：「顧客によってチケットが再オープンされました」
これにより、チケットがオープンのキューで気付かれずに放置されるのを防ぎます。
緊急の問題のエスカレート
一部の返信には、すぐに注意が必要です。チケットに「緊急」、「エスカレート」、または「マネージャー」のようなキーワードが含まれている場合は、顧客が返信したときに自動的にエスカレートできます。
条件：
- ステータスカテゴリ | 次に変更 | オープン
- コメントテキスト | 次のいずれかを含む | 緊急 エスカレート マネージャー
アクション：
- タグを追加 | 緊急-エスカレーション
- グループにメールを送信 | Tier 2サポート
- 優先度を設定 | 高
顧客の返信の追跡
エージェントによってオープンされたチケットと、顧客によって再オープンされたチケットを区別したいですか？コメント条件を使用します。
条件：
- ステータスカテゴリ | 次に変更 | オープン
- コメント | 次に等しい | 公開
- 現在のユーザー | 次に等しい | （エンドユーザー）
アクション：
- タグを追加 | 顧客-返信
このタグは、レポートに役立ち、他のワークフローをトリガーできます。
ワークフローの競合の防止
プロのヒントを次に示します。タグを使用して、トリガーループを防ぎます。トリガーが起動したときにタグを追加する場合は、条件からそのタグを除外して、トリガーが同じチケットで2回実行されるのを防ぐことができます。
条件：
- ステータスカテゴリ | 次に変更 | オープン
- タグ | 次のいずれも含まない | trigger-fired
アクション：
- タグを追加 | trigger-fired
- （その他のアクション）
このパターンは、相互作用する可能性のある複数のトリガーがある場合に不可欠です。
一般的な問題のトラブルシューティング
慎重に設定しても、トリガーが期待どおりに動作しない場合があります。最も一般的な問題とその修正方法を次に示します。
トリガーが起動しない
トリガーがまったく起動しない場合は、次の順序で確認してください。
-
トリガーの位置。 リストの上部にトリガーを移動します。別のトリガーが最初にチケットを非アクティブ化するか、ステータスを変更した場合、トリガーが実行される機会がない可能性があります。
-
条件ロジック。 「次である」だけでなく、「次へ変更」を使用していることを再確認してください。また、アカウント設定に基づいて、「ステータスカテゴリ」と「ステータス」を正しく使用していることを確認してください。
-
コメント要件。 コメント条件を含めた場合は、更新に実際にコメントが含まれていることを確認してください。コメントなしのAPI更新またはフィールド変更は、コメント条件を満たしません。
他のトリガーとの競合
複数のトリガーが同じチケットを変更する場合、順序が重要です。Zendeskはトリガーを順番に処理し、各トリガーは前のトリガーの結果を確認します。
トリガーAがトリガーBが探しているタグを追加したが、トリガーBが最初に実行された場合、タグは表示されません。トリガーページで「上」および「下」矢印を使用して、トリガーの順序を変更します。
APIの更新が予期しないオープンを引き起こす
これはトリッキーな問題です。サードパーティツール（n8nやMakeなど）がAPI経由でチケットを更新すると、意図せずにステータスの変更がトリガーされる可能性があります。
1つの回避策：APIの更新を除外する条件を追加します。
条件：
- 次経由で更新 | 次に等しくない | Webサービス（API）
これにより、APIベースの更新でトリガーが起動するのを防ぎながら、ユーザーが開始した変更をキャッチできます。
サードパーティ統合でのWebhookの問題
Webhookを使用してZendeskを他のツールと統合している場合は、Webhook IDが変更または削除される問題が発生する可能性があります。n8nコミュニティでユーザーによって報告されたように、Webhookの不安定性によりトリガーの失敗が発生しました。
解決策：Webhookを定期的に監視し、より安定した認証のためにOAuthの代わりにAPIトークンを使用することを検討してください。
ステータスとステータスカテゴリの混同
これは、ほとんどすべての人がいつか陥る問題です。区別を次に示します。
- ステータス （Teamプラン）：新規、オープン、保留、解決済、クローズのような値を持つ実際のステータスフィールド
- ステータスカテゴリ （カスタムステータスが有効になっているGrowth+）：関連するステータスのグループ
カスタムステータスがアクティブになっている場合、標準ステータスはカテゴリになります。「ステータスカテゴリ」条件を使用して、すべてのバリエーションをキャッチします。カスタムステータスなしのTeamプランを使用している場合は、「ステータス」を使用します。
Zendeskトリガーの代わりにeesel AIを使用する場合
Zendeskトリガーは強力ですが、制限があります。これらはルールベースであるため、指示したとおりに正確に実行され、それ以上でもそれ以下でもありません。時には、よりスマートなものが必要です。
そこで、AIを活用したアプローチが役立ちます。eesel AIでは、自動化に異なるアプローチを取ります。厳格なトリガーロジックを構築する代わりに、ビジネスを学習し、インテリジェントな意思決定を行うAIチームメイトを採用します。
Zendeskトリガーの代わりに（またはZendeskトリガーと並行して）eesel AIを検討するタイミングを次に示します。
AIの理解を必要とする複雑な自動化。 感情、緊急度、または顧客の意図に基づいてチケットをエスカレートしますか？当社のAIは、フィールド値だけでなく、チケットの内容を読み取り、理解します。
自然言語条件。 「タグがXに等しい場合」の代わりに、「顧客が請求について不満を持っているように見える場合」のように言うことができます。AIはコンテキストとニュアンスを理解します。
チケットの自動解決。 トリガーは通知とタグ付けを行うことができますが、eesel AIは実際にチケットを自律的に解決できます。過去のチケットとヘルプセンターから学習し、手動で設定しなくても正確な応答を提供します。
段階的な自動化。 エージェントのレビューのためにAIが返信を下書きすることから始めます。それが証明されたら、応答を直接送信させます。最終的には、最前線のサポート全体を処理できます。ペースを制御できます。
簡単な設定。 管理する複雑な条件ロジックやトリガーの順序はありません。Zendeskにeeselを接続すると、数分で既存のデータから学習します。
Zendeskトリガーが自動化のニーズに制限されている場合は、当社のZendesk統合を検討する価値があるかもしれません。
今すぐZendeskワークフローの自動化を開始する
ステータスがオープンに変更されたときにZendeskトリガーを作成することは、メカニズムを理解すれば複雑ではありません。重要なのは、「ステータスが変更された」（「ステータスが」ではない）を使用し、自動化に依存する前に徹底的にテストすることです。
覚えておいてください：シンプルから始めます。再オープンされたチケットの担当者に通知する基本的なトリガーは、すぐに価値を提供します。チームに何が効果的かを学習するにつれて、後でいつでも複雑さを追加できます。
理解と判断を必要とするシナリオを処理するために、ますます複雑なトリガーチェーンを構築している場合は、AIを活用した代替手段を検討する時期かもしれません。eesel AIはZendeskと連携して、ルールベースのトリガーが苦労するニュアンスのある自動化を処理します。
Zendesk自動化をさらに進める準備はできましたか？eesel AIがどのように役立つかをご覧ください。
よくある質問
Share this article
Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.
