Zendeskトリガーアクションでカスタムフィールドを設定する方法：完全ガイド2026

チケットフィールドを手動で更新するのは、サポートチームの作業を遅らせる退屈な作業です。VIP顧客が緊急の問題を送信すると、誰かが手動で優先度を設定し、適切なチームを割り当て、正しくタグ付けする必要があります。Zendeskのトリガーアクションは、定義した条件に基づいてカスタムフィールド値を自動的に設定することでこれを解決し、反復的なタスクを排除し、一貫したチケット処理を保証します。

このガイドでは、Zendeskトリガーアクションを使用してカスタムフィールドを設定するために知っておく必要のあるすべてのことを説明します。設定プロセス、理解しておく必要のあるフィールドタイプの制限、実際のユースケース、および一般的な障害に対する回避策について説明します。チケットの分類を自動化する場合でも、複雑なルーティングワークフローを構築する場合でも、今日実装できる実践的な手順が見つかります。

ネイティブのZendesk自動化を超えたチームのために、eesel AIがAI搭載のトリアージと自然言語の指示を通じて、カスタムフィールド管理に対するより柔軟なアプローチをどのように提供するかについても見ていきます。

トリガーにおけるカスタムフィールドタイプの理解

すべてのカスタムフィールドがトリガーで同じように動作するわけではありません。一部は完全な条件とアクション機能をサポートしています。それ以外の場合は、考慮しないと自動化計画を狂わせる可能性のある重大な制限があります。これらの違いを理解することは、信頼性の高いZendesk自動化を構築するために不可欠です。

さまざまなフィールドタイプがトリガーアクションでどのように機能するかを次に示します。

カスタムフィールドタイプ	利用可能なアクション	主な制限事項
ドロップダウン	定義済みのオプションに設定	特になし
複数選択	特定の値を追加または削除	すべての値を一度に設定することはできません
チェックボックス	チェックまたはチェックを外す	一部の機能にはタグの関連付けが必要です
日付	特定の日付を設定するか、プレースホルダーを使用	常にGMTタイムゾーンで評価されます
テキスト	静的なテキスト値を設定	アクションではプレースホルダーはサポートされていません
複数行テキスト	静的なテキスト値を設定	プレースホルダーはサポートされていません
数値/10進数	数値を設定	条件では存在/非存在に限定されます
ルックアップリレーションシップ	通知アクションでのみ値を設定	標準アクションを介して直接変更することはできません
正規表現	値を設定	トリガーのサポートは限定的です

ここで最大の落とし穴は？テキストフィールドは、トリガーアクションでプレースホルダーをサポートしていません。 これは、{{ticket.requester.custom_fields.customer_id}}のようなものを使用して、ユーザーフィールドからチケットフィールドにデータをコピーできないことを意味します。プレースホルダーは、実際の値に解決されるのではなく、リテラルテキストとして表示されます。この制限は、トリガーがユーザー、組織、およびチケットフィールド間のデータ同期を処理することを期待する多くの管理者を混乱させます。Zendeskコミュニティでは、この制限について広範囲に議論されています。

条件とアクションも可用性が異なります。たとえば、テキストフィールドは、条件の有無のみを確認できます。テキストフィールドに特定の単語が含まれているかどうかを確認する条件を作成することはできません。自動化での使用方法に基づいて、フィールドタイプを慎重に計画してください。

---

ステップ1：トリガーページにアクセスする

開始するには、管理センター > オブジェクトとルール > ビジネスルール > トリガーに移動します。このページには、アカウント内の既存のすべてのトリガーがカテゴリ別に整理されて表示されます。Zendesk自動化を初めて使用する場合は、公式のZendeskトリガーのドキュメントで完全な概要を確認してください。

多数のトリガーがある場合は、検索バーを使用して特定のトリガーを見つけます。トリガーは、このページに表示される順に実行されます。これは、複数のトリガーが同じチケットに影響を与える可能性がある場合に重要です。トリガーをドラッグアンドドロップして並べ替えることができます。

新しいトリガーを作成する前に、既存のトリガーを代わりに変更できるかどうかを確認してください。重複するトリガーを多数持つよりも、少数で適切に整理されたトリガーの方が保守が容易です。後でトラブルシューティングを行うときに感謝するでしょう。同様のカテゴリまたは関連するチケットタイプを処理するトリガーを探してください。

---

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

トリガーを追加をクリックして、自動化の構築を開始します。いくつかのセクションを含むフォームが表示されます。

トリガーに明確な名前を付けます。 トリガーの動作を説明するわかりやすい名前を使用します。「優先度トリガー」の代わりに、「VIP顧客の優先度を高に設定」のようなものを使用します。これにより、他の管理者はトリガーを開かなくてもトリガーの目的を理解できます。

説明を追加します。 説明フィールドはオプションですが、強くお勧めします。トリガーの動作、存在する理由、および起動する時期を文書化します。このコンテキストは、6か月後にトラブルシューティングを行ったり、新しいチームメンバーをトレーニングしたりするときに非常に貴重です。そうしてよかったと思うでしょう。

カテゴリを選択または作成します。 カテゴリは、管理センターでトリガーを整理するのに役立ちます。「ルーティング」、「SLA管理」、または「顧客層の自動化」のようなカテゴリがある場合があります。関連するトリガーをグループ化すると、大規模な検索と管理が容易になります。

トリガー編成のベストプラクティス：

• チーム全体で一貫した命名規則を使用する
• チームメンバーではなく、機能でトリガーをグループ化する
• トリガーの依存関係を説明に文書化する
• 非アクティブなトリガーを四半期ごとに確認してクリーンアップする

---

ステップ3：トリガー条件を設定する

条件は、トリガーがいつ起動するかを決定します。すべて満たす必要がある条件（ANDロジック）またはいずれかを満たすことができる条件（ORロジック）を設定できます。

すべての条件を満たすとは、トリガーが起動するためにすべての条件がtrueである必要があることを意味します。正確な基準が必要な場合に使用します。たとえば、「チケットが作成された」AND「組織がVIP顧客である」などです。Zendeskのドキュメントでトリガー条件の構築の詳細をご覧ください。

いずれかの条件を満たすとは、少なくとも1つの条件がtrueの場合にトリガーが起動することを意味します。これは、「件名に緊急が含まれている」OR「件名に緊急事態が含まれている」のような、より広範なシナリオに使用します。

カスタムフィールドの自動化の一般的な条件は次のとおりです。

• チケットステータスの変更：チケットが新規からオープン、または解決済みからクローズに移動したときに起動します
• タグの存在：ルーティングのニーズを示す特定のタグを確認します
• リクエスター属性：組織、ユーザータグ、またはカスタムユーザーフィールド
• 件名またはコメントテキスト：チケットの種類または優先度を示すキーワード
• チケットの作成と更新：新しいチケットとフォローアップで異なるトリガー

トリガーループの防止は重要です。 トリガーが同じチケットで繰り返し起動するのを防ぐ無効化条件を常に含めます。たとえば、トリガーがカスタムフィールドを「エスカレーション済み」に設定する場合、フィールドがまだ「エスカレーション済み」ではないことを確認する条件を追加します。これがないと、トリガーが継続的に起動し、手に負えない状態になります。

VIPルーティングの構成例：

条件カテゴリ	演算子	値
チケット：は	作成済み	-
組織：は	-	VIP顧客
カスタムフィールド：優先度	ではない	-

---

ステップ4：カスタムフィールドの設定アクションを追加する

次に、実際にカスタムフィールドを設定するアクションです。アクションを追加をクリックし、ドロップダウンから変更するフィールドを選択します。

利用可能なオプションは、フィールドタイプによって異なります。

ドロップダウンフィールドの場合、リストから特定のオプション値を選択します。フィールド構成ですでに定義した値のみを選択できます。

チェックボックスフィールドの場合、ボックスをオンにするかオフにするかを選択します。チェックボックスフィールドは、一部のビジネスルールで機能するために、関連付けられたタグが必要であることに注意してください。

複数選択フィールドの場合、特定の値を追加または削除します。すべての値を一度に「設定」することはできません。個々の選択肢を操作します。

日付フィールドの場合、特定の日付を入力するか、{{ticket.created_at}}のようなプレースホルダーを使用します。ビジネスルールの[日付]フィールドは、アカウントのタイムゾーンではなく、常にGMTタイムゾーンに対して評価されることに注意してください。

テキストフィールドの場合、設定する静的なテキスト値を入力します。プレースホルダーはここでは解決されないことを忘れないでください。{{ticket.requester.name}}と入力すると、実際のリクエスター名ではなく、フィールドに正確に表示されます。

単一のトリガーに複数のアクションを追加できます。これにより、同じ条件に基づいて「カテゴリ」と「優先度」の両方を更新するなど、複数のフィールドを一度に設定できます。

---

一般的なユースケースと例

サポートチームがトリガーアクションを使用してカスタムフィールドを設定する実際的な方法を次に示します。

キーワードで自動分類します。 チケットの件名に「払い戻し」、「請求」、「請求書」などの単語が含まれている場合、「カテゴリ」フィールドを「請求に関する質問」に自動的に設定します。これにより、チケットが手動トリアージなしで適切なチームに確実に届きます。

構成例：

• 条件：チケット：は | 作成済み; 件名テキスト：次の単語を含む | 払い戻し、請求、請求書
• アクション：カスタムフィールド：カテゴリ | 設定 | 請求

顧客層による優先度のエスカレーション。 エンタープライズ顧客またはVIPアカウントからのチケットの優先度を「高」に設定します。これをグループ割り当てと組み合わせて、完全なルーティング自動化を実現します。

構成例：

• 条件：組織：は | エンタープライズ顧客; チケット：は | 作成済み
• アクション：優先度 | 設定 | 高; グループ | 設定 | エンタープライズサポート

タグからの製品ルーティング。 タグを使用してチケットが関連する製品を識別する場合は、「製品」カスタムフィールドを設定して、レポートとルーティングを容易にします。

ステータスワークフローの追跡。 標準のZendeskステータスにマッピングされない内部ワークフローを通じてチケットを追跡するには、カスタムフィールドを使用します。「レビュー状況」フィールドは、トリガー条件に基づいて「レビュー待ち」から「承認済み」に移動できます。

日付フィールドを使用したSLA追跡。 フォローアップリマインダーのカスタム日付フィールドを設定します。チケットが作成されたら、プロアクティブな顧客への働きかけのために、「フォローアップ日」フィールドを3日後の日付に設定します。

---

制限事項と回避策の理解

ネイティブのZendeskトリガーには、自動化の目標を妨げる可能性のある実際の制限があります。知っておく必要のあることと、それらを回避する方法を次に示します。これらの制限に達しているチームの場合、カスタマーサービス向けのAIソリューションを検討すると、より柔軟性が得られます。

テキストフィールドのプレースホルダーの制限。 これは最も一般的な不満です。テキストフィールドのアクションで{{ticket.requester.custom_fields.customer_id}}のようなプレースホルダーを使用することはできません。システムは、値の代わりにリテラルプレースホルダーテキストを挿入します。

回避策のオプション：

1. 可能な場合は代わりにドロップダウンフィールドを使用します。特定の値を設定することをサポートし、トリガーで確実に機能します。

2. **Zendesk Integration Services (ZIS)**は、より堅牢な自動化レイヤーを提供します。ZISフローは、トリガーサイクルが完了した後に実行され、競合状態を回避し、複雑なデータ操作をサポートします。これにはより多くの技術的な設定が必要ですが、ネイティブトリガーでは処理できないシナリオを処理します。

3. 外部システムとのAPIは、トリガーの実行後にフィールドを更新できます。API呼び出しとトリガーが同時に同じチケットを変更しようとする競合状態に注意してください。

Webhookの競合状態。 Webhookを使用してトリガーからチケットを更新している場合、Webhookとトリガーが同時に同じチケットを変更しようとする競合状態が発生する可能性があります。ZISフローは、トリガーの実行が完了した後に実行されるため、設計上これを回避します。

ルックアップリレーションシップフィールドの制限。 これらのフィールドは、標準のフィールド設定アクションではなく、通知アクションでのみ使用できます。これにより、自動化ワークフローでの有用性が制限されます。

自動化アプローチの意思決定マトリックス：

シナリオ	最適なアプローチ
チケット属性に基づく単純なフィールド設定	ネイティブトリガー
ユーザー/組織/チケットフィールド間のデータのコピー	ZISフロー
複雑な条件ロジック	ZISまたは外部API
時間ベースのフィールド更新	自動化（トリガーではない）
リアルタイムのデータ同期	慎重なエラー処理を備えたAPI

---

一般的な問題のトラブルシューティング

トリガーが期待どおりに機能しない場合は、これらの一般的な原因を確認してください。

トリガーが起動しない。 すべての条件が実際に満たされていることを確認します。同様の条件を持つ別のトリガーが最初に起動し、チケットを変更しているかどうかを確認します。トリガーは順番に実行され、以前のトリガーからのチケットの変更が、後のトリガーが起動するかどうかに影響を与える可能性があることを忘れないでください。予期しない動作が発生している場合は、トリガーの順序を再確認する価値があります。

フィールドが更新されない。 トリガーがアクティブ（無効になっていない）であることを確認します。カスタムフィールドがまだ存在し、非アクティブ化されていないことを確認します。フィールドがエージェントに表示され、チケットフォームで編集可能であることを確認します。

プレースホルダーがリテラルテキストとして表示される。 これは、テキストフィールドのアクションでプレースホルダーを使用しようとしていることを示しています。テキストフィールドは、トリガーアクションで動的なコンテンツをサポートしていません。ZISを使用するか、静的な値を受け入れる必要があります。ネイティブトリガーでは、この制限を回避する方法はありません。

複数のトリガーが競合している。 トリガーの順序を確認します。より具体的なトリガーは、一般的なトリガーの前に配置する必要があります。2つのトリガーが同じフィールドを異なる値に設定しようとすると、後のトリガーが優先されます。

トリガーを安全にテストする。 可能な場合は、テストチケットまたはサンドボックス環境を使用します。一時的なタグアクションを追加して、重要なフィールドを変更せずにトリガーが起動するかどうかを確認することもできます。チケットイベントログを確認して、どのトリガーがどの順序で実行されたかを確認します。

---

高度：トリガーでのカスタムオブジェクトの使用

Zendesk Enterpriseプランの場合、カスタムオブジェクトを使用すると、より高度な自動化が可能になります。カスタムオブジェクトを使用すると、標準のチケット、ユーザー、および組織を超えて構造化データを保存できます。製品カタログ、サービス契約、または資産インベントリについて考えてください。

ルックアップリレーションシップフィールドは、チケットをカスタムオブジェクトレコードに接続します。「製品」ルックアップフィールドは、チケットをカタログ内の特定の製品レコードにリンクできます。仕様、保証日、および関連ドキュメントがすべて含まれています。

オブジェクトトリガーは、チケットだけでなく、カスタムオブジェクトレコードが作成または更新されたときに起動します。これにより、次のようなワークフローが可能になります。

• サービス契約が更新に近づいたときの通知の送信
• チケットが解決されたときの資産ステータスの更新
• 製品レコードが変更されたときのフォローアップタスクの作成

カスタムオブジェクトのプレースホルダーは、2024年7月に利用可能になりました。{{ticket.ticket_field_123456789.name}}のような構文を使用して、マクロと通知でカスタムオブジェクトデータを参照できるようになりました。リンクされたカスタムオブジェクトレコードの名前を取得します。

カスタムオブジェクトの恩恵を受けるユースケース：

• 資産管理：リンクされたチケットを使用して、ラップトップ、ソフトウェアライセンス、または機器を追跡します
• サービス契約：契約の詳細を保存し、更新ワークフローを自動化します
• 製品カタログ：完全な仕様アクセスを備えた特定の製品にチケットをリンクします
• 場所の追跡：チケットを物理的な場所または部門に接続します

---

eesel AIでカスタムフィールドの自動化を合理化する

ネイティブのZendeskトリガーは、簡単な自動化には適していますが、すぐに制限に達します。ユーザーフィールドとチケットフィールド間でデータをコピーしたり、複雑な条件ロジックを処理したり、複数のシステムで自動化を管理したりする必要がある場合は、プラットフォームの制約を回避する必要があります。AIチームメイトが実際に違いを生むことができるのはそのためです。

eesel AIは、これに異なるアプローチを取ります。厳格なトリガーロジックの代わりに、必要なものをわかりやすい英語で説明します。「VIP顧客が請求に関するチケットを送信したら、優先度を高に設定し、請求チームに割り当て、ユーザーレコードからアカウントIDをコピーします。」AIが実装を処理します。

ネイティブのZendeskトリガーとの主な違い：

• 競合状態なし。 eesel AIは、Zendeskのトリガーサイクルが完了した後にチケットを処理するAIチームメイトとして動作し、Webhookベースの回避策を悩ませる競合を回避します。競合する更新について心配する必要はありません。

• 自然言語の指示。 トリガー構文またはAPI呼び出しを学習せずに、複雑な自動化を定義します。AIに必要なことを伝えるだけで、コーディングは必要ありません。

• コンテキストを認識したフィールド設定。 AIは、チケットの内容、会話履歴、および接続されたデータを読み取り、どのフィールドを設定し、どの値を使用するかについてインテリジェントな決定を下します。

• 段階的なロールアウト。 チームがレビューしている間、eesel AIが応答を下書きすることから始めます。信頼が高まるにつれて、特定のチケットタイプの完全な自動化に拡張します。常に制御できます。

Zendeskをすでに使用しているチームの場合、当社の統合は数分で接続します。eesel AIは、既存のチケット、マクロ、およびヘルプセンターのコンテンツから学習するため、初日からビジネスコンテキストを理解できます。過去のチケットでシミュレーションを実行して、ライブになる前に品質を確認できます。顧客にとって驚きはありません。

Zendeskの自動化の制限事項を回避するのに、それらから恩恵を受けるよりも多くの時間を費やしている場合は、最新のサポートワークフロー用に構築されたアプローチを検討する時期かもしれません。eesel AIの価格の詳細、またはAIエージェントの機能を調べて、サポート業務の合理化にどのように役立つかをご覧ください。

---