Zendeskの自動化によるチケット再オープン条件：2026年完全ガイド
Stevia Putri
Stanley Nicholas
Last edited 2026 2月 24
Expert Verified
チケットの再オープンを管理することは、簡単そうに見えて、そうではないワークフローの1つです。チケットを解決すると、顧客が簡単な「ありがとう」と返信し、突然そのチケットがオープンキューに戻り、ワークロードが煩雑になります。さらに悪いことに、実際にはフォローアップが必要だったチケットが解決済みのまま数日間放置され、支援する機会を逃してしまうことがあります。
Zendeskの自動化によるチケット再オープン条件を正しく設定するということは、これらのシナリオをインテリジェントに処理するワークフローを構築することを意味します。すべての顧客の返信が再オープンを必要とするわけではありません。すべての解決済みチケットが永久に解決済みのままにしておくべきではありません。重要なのは、いつどのツールを使用するかを知ることです。
このガイドでは、再オープンシナリオの自動化とトリガーを構成する方法を正確に説明します。エージェントに再オープンされたチケットを通知したり、後でフォローアップをスケジュールしたり、厄介な「ありがとう」再オープンループを停止したりする場合でも、必要な特定の条件と手順が見つかります。
また、ニュアンスのあるシナリオを処理するために、ますます複雑なトリガーチェーンを構築している場合は、eesel AIでこれらの課題にどのように異なるアプローチを取っているかを見ていきます。
Zendeskのチケット再オープンメカニズムを理解する
条件と構成に入る前に、Zendeskでチケットの再オープンが実際にどのように機能するかを明確にしましょう。このプラットフォームは、各段階で何が起こり得るかを決定する厳格なライフサイクルに従います。
標準的なチケットのライフサイクルは次のようになります：新規 → オープン → 保留 → 解決済 → クローズ (Zendeskドキュメント)
各ステータスの意味は次のとおりです。
- 新規：チケットが作成されたばかりで、まだ担当者が割り当てられていません
- オープン：エージェントがチケットに積極的に取り組んでいます
- 保留：エージェントが顧客からの情報を待っています
- 解決済：エージェントが問題を解決したと考えています
- クローズ：チケットはロックされており、変更できません
再オープンの重要なルール：チケットは解決済みのステータスからのみ再オープンできます。 チケットがクローズに達すると、それは永続的です。これは設計によるものです。クローズされたチケットは、レポートおよびコンプライアンスのためにデータの整合性を維持する履歴レコードになります。
顧客が解決済みのチケットに返信すると、Zendeskは自動的にステータスをオープンに戻します。これは最も一般的な再オープンシナリオです。しかし、それはまた最も頭痛の種を引き起こします。幸せな顧客からの「どうもありがとうございます！」というメールですか？それは「これはうまくいかなかった」というフォローアップと同じようにチケットを再オープンします。
このライフサイクルを理解することが重要なのは、自動化条件がそれを考慮する必要があるためです。クローズされたチケットを再オープンする自動化を作成することはできません（Zendeskはそれを許可しません）。ただし、解決済みからオープンへの移行をインテリジェントに処理する洗練されたワークフローを作成できます。
これらのネイティブの制限が制限的であると感じるチームのために、当社のZendesk連携は、ステータスフィールドをチェックするだけでなく、意図を読み取る代替アプローチを提供します。
トリガー対自動化：再オープンシナリオでそれぞれをいつ使用するか
Zendeskは、自動化のための2つのツール、トリガーと自動化を提供します。それらは似ているように聞こえますが、非常に異なる方法で動作します。再オープンワークフローに間違ったものを使用することは、不満の種です。
トリガー：イベントベースで即時
トリガーは、チケットが条件を満たすとすぐに発動します。ステータスの変更に対するリアルタイムの応答に最適です。Zendeskのトリガードキュメントで詳細をご覧ください。
トリガーは次の場合に使用します。
- チケットが再オープンされたときにすぐに通知を受けたい場合
- チケットを更新した人に基づいてアクションを実行する必要がある場合
- ステータスの移行（解決済み → オープン）に対応している場合
再オープントリガーのコア条件：
チケット：ステータスカテゴリ | 変更 | オープン
この条件は、チケットのステータスが実際にオープンに変更された場合にのみ発動し、単に「オープンである」場合には発動しません。それが、トリガーが再オープンシナリオで機能する区別です。
自動化：時間ベースでスケジュール
自動化はスケジュールに従って実行されます（約1時間に1回）。一定の時間が経過した後に発生する必要があるアクションのために設計されています。詳細については、Zendeskの自動化ガイドを参照してください。
自動化は次の場合に使用します。
- X時間解決されたチケットをフォローアップしたい場合
- 特定の時間にチケットが再オープンするようにスケジュールしている場合
- 時間ベースのエスカレーションが必要な場合（チケットが24時間以上オープン）
一般的な時間ベースの条件：
チケット：解決されてからの時間 | より大きい | 24
チケット：保留になってからの時間 | より大きい | 48
チケット：期日からの時間 | より大きい | 0
意思決定フレームワーク
選択方法は次のとおりです。
| シナリオ | 使用 | 理由 |
|---|---|---|
| 顧客が再オープンしたときに担当者に通知する | トリガー | すぐに発生する必要がある |
| チケットが24時間オープンになっている場合はエスカレートする | 自動化 | 時間ベースの条件 |
| 来週チケットが再オープンするようにスケジュールする | 自動化 | 将来の時間の条件 |
| レポート用に再オープンされたチケットにタグを付ける | トリガー | 発生時にイベントをキャプチャする |
| 96時間解決されたチケットをクローズする | 自動化 | 時間ベースのアクション |
覚えておくべき重要なこと：トリガーはイベントに反応し、自動化は時間に反応します。ほとんどの再オープンワークフローは実際には両方を必要とします。トリガーを使用して担当者にすぐに通知し、チケットがオープンのままになっている場合は自動化を使用してエスカレートする場合があります。
時間ベースの自動化の詳細については、ステータス変更後の時間に基づいて行動するためのZendesk自動化条件に関するガイドをご覧ください。
チケット自動化を再オープンするための必須条件
効果的な再オープンワークフローを構築するには、利用可能なすべての条件を理解する必要があります。実際に使用する条件の完全なリファレンスを次に示します。
ステータスベースの条件
これらは再オープンシナリオの基本です。
ステータスカテゴリ | 変更 | オープン
- チケットがオープンステータスに移行すると発動します
- 即時通知のためにトリガーで使用します
- 最も一般的な再オープン検出条件
ステータス | 変更元 | 解決済み
- チケットが解決済みステータスから離れると発動します
- 「オープンに変更」よりも具体的です（解決済み → 任意のステータスをキャッチします）
- 解決済みからの動きを追跡したい場合に便利です
ステータスカテゴリ | は | オープン
- 移行ではなく、現在の状態を確認します
- 継続的な監視のために自動化で使用します
- 例：「ステータスはオープンであり、オープンからの時間は24時間より大きい」
時間ベースの条件
自動化はこれらに大きく依存しています。
解決されてからの時間 | より大きい | [数値]
- 解決後のフォローアップに最も一般的です
- 「は」ではなく「より大きい」を使用します（より信頼性が高い）
- 自動化は1時間ごとに実行されるため、タイミングは正確ではありません
保留になってからの時間 | より大きい | [数値]
- 古いチケットをエスカレートするため
- 一般的な値：48時間（2営業日）
期日からの時間 | より大きい | 0
- スケジュールされた再オープンワークフロー用
- 期日があるタスクタイプのチケットでのみ機能します
オープンからの時間 | より大きい | [数値]
- オープン状態が長すぎるチケットをエスカレートするため
- SLAおよび優先度の引き上げに役立ちます
参加者条件
これらは、誰が再オープンを引き起こしたかを区別するのに役立ちます。
現在のユーザー | は | (エンドユーザー)
- トリガーが顧客のアクションでのみ発動するようにします
- エージェントがトリガーする再オープンループを回避するために重要です
現在のユーザー | は | (エージェント)
- エージェントのアクションが重要なワークフロー用
- 再オープンシナリオではあまり一般的ではありません
コメント | は | 公開
- 顧客のコメントと内部メモを区別します
- 「顧客が返信した」ワークフローに不可欠です
コメント | は | 非公開
- 内部専用ワークフロー用
- 再オープンシナリオではめったに使用されません
無効化条件（ループの防止）
最も一般的な自動化の間違い：自動化が繰り返し実行されるのを防ぐことを忘れること。常に無効化条件を含めます。
タグ | 次のいずれも含まない | [your-tag]
- 自動化が発動したときにタグをアクションとして追加します
- 同じチケットで再実行されるのを防ぎます
- 例：最初の通知後にタグ「reopen_notified」
時間条件で「より大きい」が「は」に勝る理由
Zendeskの自動化は1時間ごとのサイクルで実行されます。「解決されてからの時間 | は | 24」を使用すると、自動化は23.5時間でチェックし（見逃し）、次に24.5時間でチェックする可能性があります（再び見逃し）。「より大きい」を使用すると、すべての対象チケットを確実にキャッチできます。
ステップバイステップ：再オープン通知トリガーの作成
解決済みのチケットが再オープンされたときに担当者に通知する実用的なトリガーを作成しましょう。これは最も一般的な再オープンワークフローの1つです。
ステップ1：トリガーページに移動します
管理センター > オブジェクトとルール > ビジネスルール > トリガーに移動します。既存のトリガーのリストが表示されます。それらが何をするかを正確に知らない限り、標準のものを削除しないでください。完全な条件オプションについては、Zendeskのトリガー条件リファレンスを参照してください。
ステップ2：新しいトリガーを作成します
トリガーを追加をクリックします。次のような説明的な名前を付けます。
- 「顧客によってチケットが再オープンされたときに担当者に通知する」
- 「再オープンされたチケットの通知」
「トリガー1」のようなあいまいな名前は避けてください。将来のトラブルシューティング時に、現在のあなたに感謝するでしょう。
ステップ3：条件を設定します
「次のすべての条件を満たす」で、次を追加します。
チケット：ステータスカテゴリ | 変更 | オープン
オプションですが、推奨される追加事項：
チケット：コメント | は | 公開
（これにより、内部メモではなく、顧客の返信でのみ発動することが保証されます）
チケット：現在のユーザー | は | (エンドユーザー)
（これにより、エージェントではなく、顧客が再オープンを引き起こしたことが確認されます）
チケット：タグ | 次のいずれも含まない | reopen_notified
（これにより、同じチケットでトリガーが2回発動するのを防ぎます）
ステップ4：アクションを構成します
「これらのアクションを実行する」で、次を追加します。
担当者に通知：
通知：ユーザーにメールを送信 | (担当者)
件名：「顧客によってチケットが再オープンされました：{{ticket.title}}」
本文：チケットの詳細とリンクを含めます
追跡タグを追加：
チケット：タグを追加 | reopen_notified
オプション：優先度を設定：
チケット：優先度 | 高
（再オープンされたチケットにすぐに注意が必要な場合に役立ちます）
ステップ5：トリガーをテストします
- トリガーを保存します（自動的にアクティブになります）
- テストチケットを作成するか、既存のチケットを使用します
- チケットを解決します
- エンドユーザーとして公開コメントを追加します（シークレットウィンドウまたは別のアカウントを使用します）
- ステータスがオープンに変更されることを確認します
- 担当者が通知を受け取ったことを確認します
機能しない場合は、トリガーの位置を確認してください。Zendeskはトリガーを上から下に処理します。別のトリガーが最初にチケットを変更すると、トリガーが発動しない可能性があります。
自動化ビルダーは同様のインターフェイスを使用しますが、即時イベントの代わりに時間ベースの条件に焦点を当てています。
ステータス変更トリガーの別のアプローチについては、ステータスがオープンに変更されたときにZendeskトリガーを作成するためのガイドをご覧ください。
レシピ：特定の時間にチケットが再オープンするようにスケジュールする
後でフォローアップするためにチケットを「スヌーズ」する必要がある場合があります。顧客が「来週私に連絡してください」と言ったか、完全にクローズする前に修正が機能することを確認する必要があるかもしれません。スケジュールされた再オープンワークフローを構築する方法を次に示します。
ステップ1：保留ステータスを有効にします
デフォルトでは、保留ステータスはアクティブではありません。管理センター > オブジェクトとルール > チケット > ステータスに移動し、まだ保留ステータスを追加していない場合は追加します。詳細については、Zendeskのスケジュールされた再オープンレシピを参照してください。
ステップ2：エージェント用のマクロを作成します
マクロを使用すると、エージェントはワークフローに一貫して従うことができます。次のマクロを作成します。
- タイプをタスクに設定します
- ステータスを保留に設定します
- カスタムタグを追加します（「schedule_reopen」など）
- エージェントに期日フィールドを設定するように促します
マクロを作成するには：
- 管理センター > ワークスペース > エージェントツール > マクロ
- マクロを追加
- アクション：タイプ = タスク、ステータス = 保留、タグを追加 = schedule_reopen
ステップ3：再オープン自動化を作成します
次に、期日を監視する自動化を作成します。
条件：
チケット：ステータスカテゴリ | は | 保留
チケット：タイプ | は | タスク
チケット：タグ | 次のいずれかを含む | schedule_reopen
チケット：期日からの時間 | より大きい | 0
アクション：
チケット：ステータスカテゴリ | オープン
チケット：タグを追加 | auto_reopened
「期日からの時間 > 0」条件は、「期日が過ぎた」ことを意味します。自動化が実行されると（1時間ごと）、期日を過ぎたチケットはすべて再オープンされます。
エージェントがこのワークフローを使用する方法
- エージェントがチケットにマクロを適用します
- エージェントが期日フィールドで目的の再オープン日を選択します
- チケットが保留になります
- 選択した日に、自動化によって自動的に再オープンされます
このワークフローは、特に次の場合に役立ちます。
- フォローアップリマインダー
- 外部依存関係を待つ
- 季節的または時間的制約のある問題
- 顧客が要求したコールバック
「ありがとう」再オープン問題の解決
Zendeskコミュニティからの統計を次に示します。チケットの再オープンの60〜70％は、顧客が「ありがとう」と言っているだけです。 フォローアップの質問ではありません。苦情ではありません。エージェントに不必要な作業を生み出す丁寧な感謝の気持ちです。
課題は、本物の感謝と「ありがとう、でもまだ助けが必要です」を区別することです。「ありがとう」を含むものを自動的に解決する単純なキーワードトリガーは、最終的に実際の問題を見逃します。
解決策1：ハッシュタグメソッド
実際に再オープンが必要な場合は、特定のハッシュタグを使用するように顧客をトレーニングします。解決済みのチケットメールに、次のような文を含めます。
「さらに支援が必要な場合は、#reopenと返信してください。ご連絡いたします。それ以外の場合は、返信する必要はありません。」
トリガーの設定：
条件：
- ステータスカテゴリ | 変更 | オープン
- コメントテキスト | 次の文字列を含まない | #reopen
アクション：
- ステータス | 解決済み
- タグを追加 | false_reopen
- リクエスターにメールを送信 | 「チケットは解決済みのままです。支援が必要な場合は、#reopenと返信してください。」
これは機能しますが、顧客の教育が必要です。すべての顧客が注意深く読むわけではありません。
解決策2：自動解決トリガー（セーフガード付き）
「ありがとう」または「感謝」を含むチケットを自動的に解決するトリガーを作成しますが、疑問符がない場合にのみ作成します。
トリガーの設定：
条件：
- ステータスカテゴリ | 変更 | オープン
- コメントテキスト | 次のいずれかを含む | thank thanks
- コメントテキスト | 次のいずれも含まない | ?
アクション：
- ステータス | 解決済み
- タグを追加 | auto_solved_thanks
これは「ご協力ありがとうございます！」をキャッチしますが、「ありがとうございます。でも、どうすれば...？」を見逃します。
解決策3：サードパーティ製アプリ
Zendesk MarketplaceのThank You GPTアプリは、AIを使用して本物の感謝とフォローアップの質問を検出します。これは、この問題のために特別に構築されています。
解決策4：AI搭載の検出（高度）
ZapierとOpenAIにアクセスできるチームの場合、洗練されたワークフローを構築できます。
- トリガーが再オープンを検出し、タグを追加します
- Zapierはタグ付きチケットのビューを監視します
- OpenAIはコメントを分析します。「これは単なる感謝ですか、それとも実際の問題がありますか？」
- 単なる感謝の場合、ZapierはAPI経由でチケットを解決します
大手企業のCX責任者の1人は、彼らの設定を共有しました。
推奨事項
解決策2（疑問符セーフガード付きの自動解決）から始めます。これはシンプルで無料で、ほとんどの場合をキャッチします。それでも感謝の再オープンに溺れている場合は、Thank You GPTアプリにアップグレードするか、AI搭載のアプローチを検討してください。
ちなみに、当社のAIエージェントは、キーワードを照合するだけでなく、意図を理解することで、この正確なシナリオを処理します。複雑なトリガーチェーンなしに、「ありがとう！」と「ありがとうございます、でも...」の違いを認識します。
一般的な間違いとトラブルシューティング
経験豊富なZendesk管理者でさえ、再オープン自動化で問題が発生します。最も一般的な問題とその修正方法を次に示します。
トリガーが発動しない
トリガーの位置を確認してください。 Zendeskはトリガーを上から下に処理します。別のトリガーが最初にチケットを変更した場合（特にステータスを変更したり、タグを追加したりするもの）、トリガーが実行される機会がない可能性があります。再オープントリガーを上部に移動します。
「変更」と「は」を確認してください。 これは＃1の間違いです。「ステータスはオープン」は、すべてのオープンチケットに一致します。「ステータスがオープンに変更」は、オープンになったばかりのチケットにのみ一致します。再オープン検出には、「変更」が必要です。
ステータスフィールドを確認してください。 カスタムステータスが有効になっている場合は、「ステータス」ではなく「ステータスカテゴリ」を使用します。カスタムステータスがないチームプランを使用している場合は、「ステータス」を使用します。
自動化が複数回実行される
無効化条件を忘れています。 すべての自動化は、繰り返し実行されないようにする方法が必要です。自動化が発動したときにタグを追加し、条件に「タグに次のいずれも含まれていない」を含めます。
修正例：
条件：
- ステータス | 解決済み
- 解決されてからの時間 | より大きい | 24
- タグ | 次のいずれも含まない | solved_24h_notified
アクション：
- 担当者にメールを送信 | 「チケットは24時間解決されました」
- タグを追加 | solved_24h_notified
APIの更新により予期しないオープンが発生する
API経由でチケットを更新するサードパーティ製のツールは、意図せずに再オープンワークフローをトリガーする可能性があります。一般的な原因の1つ：解決済みのチケットに評価を書き戻すアンケートツール。
修正： この条件を追加します。
チケット：更新元 | ではない | Webサービス（API）
これにより、ユーザーが開始した変更をキャッチしながら、APIベースの更新でトリガーが発動するのを防ぎます。
ステータスとステータスカテゴリの混同
これはほとんどすべての人を混乱させます。
- ステータス（チームプラン）：実際のステータスフィールド（新規、オープン、保留、解決済み、クローズ）
- ステータスカテゴリ（カスタムステータスを備えたGrowth+）：関連するステータスのグループ
カスタムチケットステータスがアクティブになっている場合、標準ステータスはカテゴリになります。すべてのバリエーションをキャッチするには、「ステータスカテゴリ」条件を使用します。チームプランを使用している場合は、「ステータス」を使用します。
時間条件が見逃された
「解決されてからの時間 | は | 24」を使用するのは危険です。自動化は1時間ごとに実行されるため、23.5時間でチェックし（見逃し）、次に24.5時間でチェックする可能性があります（再び見逃し）。
時間条件には常に「より大きい」を使用してください。
代わりにAI搭載の自動化を検討する場合
Zendeskのトリガーと自動化は強力ですが、基本的にルールベースです。彼らはあなたが彼らに言うことを正確に行い、それ以上でもそれ以下でもありません。場合によっては、それは制限されています。
次のシナリオを検討してください。
再オープン処理だけで20以上のトリガーがあります。 トリガーリストが管理不能になっている場合は、ルールベースの自動化が限界に達している兆候です。
キーワードだけでなく、意図を理解する必要があります。 「ありがとう」対「ありがとうございます、でも...」は、トリガー条件で処理するのが驚くほど困難です。AIはコンテキストを読み取ります。
プログレッシブ自動化が必要です。 エージェントのレビューのためにAIが返信を下書きすることから始めます。それがそれ自体を証明するにつれて、それが直接応答を送信するようにします。最終的には、最前線のサポート全体を処理します。あなたはペースを制御できます。
チームは自動化を使用するよりも管理するのに多くの時間を費やしています。 複雑なトリガーチェーンには継続的なメンテナンスが必要です。自然言語条件は管理が容易です。
eesel AIでのアプローチ方法
Zendeskと統合して、既存の設定と連携するAIレイヤーを提供します。厳格なトリガーロジックを構築する代わりに、ビジネスを学習するAIチームメイトを採用します。
主な違い：
- 意図ベースの処理： 当社のAIは、複雑なキーワードルールなしに、本物の感謝とフォローアップの質問の違いを理解します
- 自然言語条件： タグベースのロジックを構築する代わりに、「顧客が請求について不満を持っているようだ」と言います
- プログレッシブ自律性： AIが返信を下書きすることから始めます。自信が高まるにつれて、直接応答にレベルアップします
- より高速なセットアップ： Zendeskに接続すると、既存のチケットとヘルプセンターから数分で学習できます
当社のAIトリアージ製品は、フィールド値だけでなく、実際のチケットコンテンツに基づいてルーティングとタグ付けを特別に処理します。そして、当社のAIエージェントは、通知とタグ付けだけでなく、適切な場合にチケットを自律的に解決できます。
複雑な再オープンシナリオでZendeskのネイティブ自動化が制限されている場合は、当社がどのように役立つかをご覧ください。
よくある質問
この記事を共有
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.
