Zendeskのチケットごとのトリガー制限について解説（2026年版ガイド）

サポートチームは、物事を円滑に進めるために自動化に依存しています。顧客がチケットを送信すると、適切なチームにルーティングされ、正しくタグ付けされ、すぐに承認される必要があります。ここでZendeskトリガーが登場します。

しかし、問題はここにあります。ほとんどのチームは、物事が壊れ始めるまで、制限に近づいていることに気づいていません。通知が送信されなくなります。チケットが割り当てられません。昨日まで機能していたワークフローが、今日突然失敗します。

このガイドでは、知っておく必要のあるすべてのZendeskトリガー制限を解説します。トリガーと自動化の違い（同じではありません）、それぞれに適用される特定の制約、および上限に達した場合の対処法について説明します。

Zendeskトリガーと自動化の理解

制限について詳しく説明する前に、何について話しているのかを明確にしましょう。トリガーと自動化はどちらもZendeskのビジネスルールですが、動作が異なります。

トリガーとは？

トリガーは、チケットに何かが起こったときに即座に実行されるイベントベースのルールです。チケットが作成、更新、または特定の方法で変更されると、トリガーは条件を評価し、それらの条件が満たされた場合に発動します。

トリガーを最初の防衛線と考えてください。トリガーは、リアルタイムのルーティング、通知、およびチケットの変更を処理します。一般的なユースケースは次のとおりです。

• キーワードまたはリクエスタ組織に基づいて、チケットを特定のグループにルーティングする
• チケットを受信したときに確認メールを送信する
• レポートおよび分類のためにタグを追加する
• 件名の内容に基づいて優先度を設定する
• チケットを特定のエージェントに割り当てる

トリガーは上から下の順に実行され、あるトリガーのアクションは、後続のトリガーが発動するかどうかに影響を与える可能性があります。このカスケード動作は、制限とパフォーマンスについて説明するときに重要になります。

自動化とは？

自動化は、クローズされていないすべてのチケットに対して1時間ごとに実行される時間ベースのルールです。イベントに即座に反応する代わりに、スケジュールに基づいて条件を確認し、時間ベースの基準が満たされたときに行動します。

自動化は、即時の応答を必要としないワークフローを処理します。

• チケットが48時間保留になっている場合にリマインダーを送信する
• タイムフレーム内に割り当てられていないチケットをエスカレーションする
• 設定された期間後に解決済みのチケットをクローズする
• 停滞したチケットについてマネージャーに通知する

重要な違いはタイミングです。トリガーは即時です。自動化は1時間ごとです。

混乱が重要な理由

ここでチームが問題に巻き込まれます。トリガー制限と自動化制限を混同します。「Zendeskのチケットごとのトリガー制限」について質問する人が、実際には自動化の制約に達しているか、またはその逆である可能性があります。

トラブルシューティングのアプローチは完全に異なります。

• トリガーの問題は通常、すぐに表示されます（チケットがルーティングされない、通知が送信されない）
• 自動化の問題は遅延として表示されます（リマインダーが1時間遅れて送信される、チケットが期待どおりに自動クローズされない）

実際にどのシステムで制限に達しているかを理解することで、デバッグの時間を節約できます。

Zendeskトリガー制限について解説

次に、実際の制限について具体的に説明します。Zendeskには、使用しているトリガーのタイプに応じて、さまざまな制約カテゴリがあります。

チケットトリガー制限

標準のチケットトリガーの場合、主な制限は次のとおりです。

制限	値	意味
最大アクティブトリガー数	7,000	7,000を超えるアクティブなチケットトリガーを作成することはできません
トリガーサイズ	65 KB	各トリガーは65キロバイト未満である必要があります
実行順序	順番	トリガーは上から下の順に、次々と実行されます

7,000のトリガー制限は寛大に聞こえますが、ほとんどのチームにとってはそうです。ただし、複雑なルーティングルール、複数のブランド、および高度な分類を備えたエンタープライズ運用では、この上限に近づく可能性があります。

65 KBのサイズ制限は、多くの条件とアクションを持つ複雑なトリガーを構築する場合に重要になります。各条件、アクション、およびロジックの一部がスペースを消費します。この制限に達した場合は、トリガーをより小さなトリガーに分割するか、ロジックを簡略化する必要があります。

オブジェクトトリガー制限

オブジェクトトリガーは、Zendeskのカスタムオブジェクトで動作し、独自の、より制限的な制限があります。

制限	値
オブジェクトごとのアクティブトリガー数	最大100
オブジェクトごとの合計トリガー数	最大500（アクティブ+非アクティブ）
トリガーごとの条件数	最大50
トリガーごとのアクション数	最大25
トリガーサイズ	最大64 KB
複数選択の値	条件ごとに最大50

オブジェクトトリガーはエンタープライズプランでのみ利用可能であり、カスタムオブジェクトをアクティブ化する必要があります。アセット管理、ITワークフロー、またはその他の特殊なユースケースにカスタムオブジェクトを使用している場合、これらの制限は標準のチケットトリガー制限よりも重要になります。

オブジェクトごとの100のアクティブトリガー制限は、チームを不意に襲うものです。カスタムオブジェクトを中心に高度なワークフローを構築している場合、トリガーがすぐに蓄積されやすくなります。

「チケットごと」の現実

元の質問に対するニュアンスのある回答は次のとおりです。Zendeskによって文書化された明示的な「チケットごと」のトリガー実行制限はありません。理論的には、1つのチケットはライフタイム中に多くのトリガーを通過できます。

ただし、実際的な制限が存在します。

• トリガーループ：不適切に設計されたトリガーは、トリガーAがチケットを更新し、トリガーBが発動し、チケットを更新してトリガーAが再度発動する無限ループを作成する可能性があります。Zendeskにはいくつかのループ保護がありますが、複雑なカスケードトリガーはパフォーマンスの問題を引き起こす可能性があります。

• システムタイムアウト：チケットの更新が多すぎるカスケードルールをトリガーする場合、操作がタイムアウトする可能性があります。これはまれですが、非常に複雑なトリガーチェーンで発生する可能性があります。

• クローズされたチケット：チケットトリガーはクローズされたチケットでは実行されません。ただし、1つの例外があります。チケットがクローズに設定されている場合は発動できますが、すでにクローズされているチケットでは発動できません。これにより、トリガーの実行はチケットのアクティブなライフサイクルに効果的に制限されます。

実際の「チケットごと」の制限はアーキテクチャです。トリガーが際限なくカスケードしないように、トリガーを効率的に設計してください。

自動化制限（トリガーと混同されることが多い）

多くのチームがこれらのシステムを混同しているため、自動化制限についても明確にしましょう。

1時間ごとの実行制限

自動化には、チケットの処理方法に影響を与えるハードクォータがあります。

制限	値	影響
1時間あたりの自動化ごとのチケット数	1,000	より多くのチケットが条件を満たす場合、処理は次の時間のキューに入ります
チケットのライフタイムあたりの更新数	最大100	100回以上の自動化更新があるチケットは、自動化の実行から除外されます
最大アクティブ自動化数	500	トリガー制限と同じパターン
自動化サイズ	65 KB	ビジネスルールはサイズ制約内に収まる必要があります

1時間あたり1,000チケットの制限は、高ボリュームの運用に影響を与えます。自動化の条件を満たすチケットが5,000件ある場合、最初の1時間で処理されるのは1,000件のみです。残りの4,000件は、条件がまだ満たされていると仮定して、後続の時間のキューに入ります。

チケットごとの100回の更新制限は、すべての自動化で累積されます。チケットが自動化によって100回処理されると、将来の自動化の実行から除外されます。これは通常のチケットにはほとんど影響しませんが、複雑な自動化ワークフローを持つ長期間実行されるチケットには影響を与える可能性があります。

自動化が発動しない場合

自動化が期待どおりに機能しない場合は、これらの一般的な制限関連の原因を確認してください。

• 1時間ごとのクォータを超過：自動化は実行されましたが、1,000チケットの上限に達しました。次の時間を確認して、処理が続行されるかどうかを確認してください。

• チケット更新制限に達した：チケットはすでに自動化によって100回処理されています。チケットのイベントログを確認して確認してください。

• タイミングの問題：自動化は正確に1時間ごとに実行されるわけではありません。各時間の「ある時点」で開始されます。つまり、10時15分に解決されたチケットは、自動化サイクルがいつ実行されるかに応じて、11時20分まで処理されない可能性があります。

• 条件からの時間：「作成からの時間数が4」のような時間ベースの条件は、トリッキーな場合があります。自動化の実行時間にわずかな変動があるため、タイミングが完全に一致しない場合、「is」条件がtrueと評価されることはありません。

制限に達した場合に何が起こるか

制限に達した場合の動作を理解することは、トラブルシューティングと計画に役立ちます。

制限時のシステムの動作

トリガーの場合：

7,000のアクティブトリガー制限に達すると、Zendeskは新しいアクティブトリガーの作成を許可しません。最初に既存のトリガーを非アクティブ化または削除する必要があります。システムは古いトリガーを自動的に非アクティブ化したり、制限に近づくと警告したりしません。

個々のトリガーで65 KBのサイズ制限に達すると、保存しようとしたときにエラーが発生します。サイズを小さくするまで、トリガーは作成または更新されません。

自動化の場合：

自動化が1時間あたり1,000チケットの制限に達すると、残りのチケットは次の時間のキューに入ります。これにより、高ボリューム期間中にカスケード遅延効果が発生します。自動化の条件を満たすチケットが1時間あたり1,000件を超える場合は、一部のチケットが常に遅延します。

チケットが100回の自動化更新制限に達すると、将来の自動化の実行からサイレントに除外されます。エラーや通知はありません。自動化は単にそのチケットに影響を与えなくなります。

制限に近づいている兆候

次の指標に注意してください。

• チケット処理の遅延：トリガーチェーンが実行されるにつれて、チケットの更新に時間がかかる
• 通知の欠落：トリガーから発動するはずのメールまたはSlackメッセージが届かない
• 自動化アクションの遅延：自動クローズまたはエスカレーションのリマインダーが遅れて到着する
• 監査ログのギャップ：チケットイベントログに、スキップされたアクションまたは不完全なトリガーの実行が表示される
• 保存エラー：Zendeskは、新しいトリガーまたは自動化を作成するときにエラーをスローする

これらの症状に気付いた場合は、トリガーと自動化の数をすぐに監査してください。

実用的な回避策と解決策

制限に近づいている場合は、制約を最適化または回避するためのいくつかのオプションがあります。

既存のトリガーを最適化する

ハード制限に達する前に、トリガーを統合および合理化します。

• 同様のトリガーをマージする：同様の条件に基づいて異なるタグを追加する5つのトリガーの代わりに、関連するすべてのタグを追加する1つのトリガーを作成します

• 無効化条件を使用する：同じチケットでトリガーが複数回発動するのを防ぐ条件を追加します。たとえば、「処理済み」タグを追加し、「タグに次のいずれも含まれていない：処理済み」を条件として含めます

• 未使用のトリガーを削除する：トリガーを四半期ごとに監査します。30日間発動していないものをすべて非アクティブ化します

• 複雑なロジックを簡略化する：トリガーに40の条件がある場合、すべてが必要かどうかを検討してください。場合によっては、広範な条件が特定の条件と同じように機能します

代替アプローチ

Zendeskのネイティブ制限がワークフローを制約する場合は、次の代替手段を検討してください。

外部処理用のウェブフック

Zendeskウェブフックを使用すると、チケットデータを外部システムに送信して処理できます。Zendeskトリガーで複雑なロジックを構築する代わりに、Zendeskの制約外で高度なルーティング、エンリッチメント、または通知ロジックを処理するミドルウェアにチケットをルーティングできます。

このアプローチは、複雑さをZendeskから取り除き、トリガー制限を完全に回避します。トレードオフは、維持するための追加のインフラストラクチャです。

APIベースの自動化

自動化制限を超える時間ベースのワークフローの場合、ZendeskのAPIを使用してカスタム自動化を構築できます。（インフラストラクチャで実行されている）スケジュールされたジョブは、特定の基準を満たすチケットをクエリし、API呼び出しを介して更新できます。

これにより、タイミング、バッチサイズ、およびロジックの複雑さを完全に制御できます。Zendeskのネイティブ自動化のシンプルさは失われますが、無制限のスケーラビリティが得られます。

インテリジェントなトリアージのためのeesel AI

ここで私たちの出番です。ルーティングロジックがZendeskトリガーにとって複雑すぎる場合、またはエッジケースを処理しようとしてトリガー制限に一貫して達している場合は、代替アプローチを提供します。

すべてのシナリオのルールを作成する代わりに、当社のAIは過去のチケットから学習します。キーワードベースのトリガーでは単に一致できない方法で、コンテキスト、感情、および意図を理解します。「ログインできず、上司が今日このレポートを必要としている」と書いた顧客は、「緊急」という単語を使用していなくても正しくルーティングされます。

Zendeskと直接統合し、既存のトリガーと並行して動作します。ルールから始めて、役立つ場所にAIを追加し、手動構成からインテリジェントな自動化に徐々に移行できます。

違いは何ですか？ルールは指示に従います。AIは結果から学習します。

使用状況の監視

プロアクティブな監視は、予期せぬ事態を防ぎます。

• トリガー使用状況レポートを確認する：Zendeskは、どのトリガーが最も頻繁に発動するかを示す使用状況統計を提供します
• 自動化バックログを追跡する：自動化が一貫して1時間ごとのクォータに達しているかどうかを監視します
• トリガーの有効性を監査する：発動するが、チケットの状態を有意に変更しないトリガーを特定します
• 成長を計画する：四半期ごとに100個のトリガーを追加している場合、70週間で7,000の制限に達します

トリガー管理のベストプラクティス

制限管理を超えて、これらのプラクティスはZendeskインスタンスを健全に保ちます。

すべてを文書化する

すべてのトリガーには、その目的を説明する明確な説明が必要です。数百のトリガーがある場合、「VIPチケットのルーティング」は「VIPルーティングv3 FINAL」よりも役立ちます。

カテゴリを使用する

Zendeskでは、トリガーをカテゴリに整理できます。ルーティング、通知、エスカレーション、タグ付けなど、関連するトリガーをグループ化します。これにより、監査とトラブルシューティングが容易になります。

ステージングでテストする

本番環境で直接複雑なトリガーを作成しないでください。サンドボックス環境を使用して、トリガーロジックをテストします。特に、トリガーが相互に作用する場合はそうです。

トリガーアーキテクチャを計画する

構築する前に、全体的なフローについて考えてください。どのトリガーを最初に実行する必要がありますか？どれが他のトリガーに依存していますか？少し計画することで、制限の問題につながるカスケードの複雑さを防ぐことができます。

Zendeskトリガーの代替手段を検討する時期

Zendeskのネイティブトリガーが提供できるものを超えている場合があります。兆候は次のとおりです。

• 一貫して6,000以上のトリガーがあり、定期的にトリガーを追加している
• ルーティングロジックには、トリガーごとに数十の条件が必要
• キーワードだけでなく、コンテキストを理解するAI搭載の意思決定が必要
• トリガー制限を回避するために複雑な回避策を構築している

これらに聞き覚えがある場合は、代替手段を検討する時期かもしれません。

eesel AIがZendeskを補完する方法

eesel AIは、まさにこれらのシナリオを処理するために構築されました。私たちのアプローチは、いくつかの重要な点でルールベースのトリガーとは異なります。

学習ベース vs ルールベース

「件名にXが含まれている場合は、Yにルーティングする」と記述する代わりに、過去のチケットでAIをトレーニングします。AIは、存在することに気づいていないパターンを学習します。その結果、明示的なルールなしでエッジケースを処理するルーティングが実現します。

スケーラブルな複雑さ

ルールを使用していないため、7,000ルールの制限はありません。AIの意思決定は、手動構成ではなく、チケットのボリュームと複雑さに応じてスケーリングされます。

トリガーと連携

既存のZendesk設定を置き換える必要はありません。直接統合し、既存のトリガーが単純なものを処理している間、複雑なルーティングを処理できます。

AIがトリガー設定をどのように補完できるかを知りたい場合は、eesel AIを無料でお試しください。または、デモを予約するして、インテリジェントなトリアージがどのように機能するかをご覧ください。