Zendeskでカスタムフィールドに基づいてフォロワーを追加する方法:2026年ガイド
Stevia Putri
最終更新 February 24, 2026
割り当てられた組織からチケットが届くたびに、アカウントマネージャーを自動的にフォロワーとして追加したいとします。または、製品フィールドに基づいて技術スペシャリストを参加させる必要があるかもしれません。これはZendeskのトリガーでネイティブに処理できることのように思えますよね?
問題はここにあります。Zendeskの「フォロワーを追加」アクションでは、特定のユーザーしか選択できません。カスタムフィールドを指定して、「このフィールドにいる人を追加する」と言うことはできません。動的な自動化が必要な世界では、これは静的な選択です。
このガイドでは、この問題を解決するための3つの方法を説明します。小規模チーム向けの最も簡単なアプローチから始め、成長する運用向けの拡張性のあるWebhookソリューションに移行し、コードを書かずにインテリジェントな自動化を必要とするチームのために、eesel AIでこれをどのように処理するかを紹介します。
必要なもの
始める前に、以下を確認してください。
- Zendesk SuiteまたはSupportプラン(Team、Growth、Professional、またはEnterprise)
- トリガー、Webhook、およびAPIトークンを作成するための管理者権限
- Webhookアプローチの場合:JSONとLiquidマークアップの基本的な知識
- 管理センターの設定でCCとフォロワーの機能が有効になっていること
フォロワーが有効になっているかどうかを確認するには、管理センター > オブジェクトとルール > チケット > 設定に移動します。「CCとフォロワー」セクションの「フォロワーを許可する」チェックボックスを探してください。
Zendeskトリガーのカスタムフィールドによるフォロワー追加の制限について
何がうまくいかないのかを明確にしましょう。「組織がAcme Corpである」のような条件でトリガーを作成し、「フォロワーを追加」アクションで{{ticket.organization.custom_fields.account_manager}}のようなプレースホルダーを使用できると考えるかもしれません。概念的には理にかなっていますが、Zendeskはそれをサポートしていません。
「フォロワーを追加」アクションは、特定のユーザーのドロップダウンを表示します。1つ選択します。プレースホルダーまたは動的な値を使用して、誰を追加するかを選択することはできません。これが、管理者が回避策を探すことになる根本的な制限です。
トリガーができることは、カスタムフィールドの値を条件として読み取ることです。フィールドに値があるかどうかを確認したり、特定のテキストと比較したり、空でないことを確認したりできます。ただし、アクション側(実際に何が起こるか)では、フォロワーの選択にこれらの動的な値を使用できません。
これにより、実際の運用上の頭痛の種が生じます。それぞれに独自のアカウントマネージャーがいる50の組織がある場合、回避策がないと50の個別のトリガーが必要になります。それは維持できません。

方法1:組織ごとの個別のトリガー
最も簡単な解決策は、20未満の組織を持つ小規模な運用に最適です。
仕組み
自動フォロワー割り当てが必要な組織ごとに1つのトリガーを作成します。各トリガーには、ハードコードされたフォロワー選択があります。
設定方法
- 管理センター > オブジェクトとルール > ビジネスルール > トリガーに移動します
- 「トリガーを作成」をクリックします
- 条件を設定します:「チケットが作成された」AND「組織が[特定の組織]である」
- アクションを追加します:「フォロワーを追加」を選択し、特定のエージェントを選択します
- 保存し、各組織に対して繰り返します
長所と短所
| 長所 | 短所 |
|---|---|
| 技術的な複雑さがない | 〜20組織を超えて拡張できない |
| すぐに機能する | スタッフの変更時にメンテナンスが大変 |
| 理解しやすい | すべての更新に管理者アクセスが必要 |
| APIトークンやWebhookがない | 誰が変更を加えたかの監査証跡がない |
いつこれを使用するか
このアプローチは、概念実証の実装、非常に小規模なチーム、またはアカウントの割り当てがめったに変更されない状況に適しています。自動フォロワー割り当てがワークフローを改善するかどうかをテストする場合は、より複雑なソリューションに投資する前に、ここから始めてください。
基本的なトリガーとマクロの設定の詳細については、Zendeskでトリガーまたはマクロを使用してフォロワーを自動的に追加する方法に関するガイドをご覧ください。
方法2:WebhookとAPIアプローチ(スケーラブル)
20以上の組織を管理しているチーム、または頻繁なアカウントの再割り当てを処理しているチームにとって、Webhookアプローチはスケーラブルなソリューションを提供します。組織のカスタムフィールドを使用してフォロワーのメールアドレスを保存し、Zendesk APIを呼び出して動的に追加します。
ステップ1:組織のカスタムフィールドを作成する
まず、各組織レコードにフォロワーのメールアドレスを保存する場所が必要です。
管理センター > ユーザー > 設定 > 組織フィールドに移動します。「フィールドを追加」をクリックし、フィールドタイプとして「Regex」を選択します。
フィールドを構成します。
- 表示名: 自動フォロー
- フィールドキー: auto_follow
- 説明: フォロワーとして追加するエージェントのカンマ区切りのメールアドレス
- 検証Regex:
^([\w+-.%]+@[\w.-]+\.[A-Za-z]{2,4})(,[\w+-.%]+@[\w.-]+\.[A-Za-z]{2,4})*$
このRegexは、スペースなしのカンマ区切りのメールアドレスを検証します。例:manager1@company.com,manager2@company.com
ステップ2:Zendesk APIトークンを作成する
Webhookには、Zendesk APIを呼び出すための認証が必要です。
管理センター > アプリと連携機能 > API > Zendesk APIに移動します。「APIトークンを追加」をクリックし、「フォロワー自動化Webhook」のようなわかりやすい名前を付けます。
トークンをすぐにコピーします(再度表示することはできません)。パスワードマネージャーに安全に保存します。このトークンをyour-email@company.com/token:{api_token}の形式で使用します。
ステップ3:Webhookを作成する
次に、トリガー通知を受信し、Zendesk APIにコールバックするWebhookを作成します。
管理センター > アプリと連携機能 > Webhook > Webhookの作成に移動します。接続タイプとして「トリガーまたは自動化」を選択します。
次の設定を構成します。
- 名前: auto_followフォロワーを追加
- エンドポイントURL:
https://{yoursubdomain}.zendesk.com/api/v2/tickets/{{ticket.id}}.json - リクエストメソッド: PUT
- リクエスト形式: JSON
- 認証: 基本認証
- ユーザー名:
/tokenが付加されたエージェントのメールアドレス(例:admin@company.com/token) - パスワード: 作成したAPIトークン
ステップ4:トリガーを作成する
トリガーは、フォロワーを追加する必要があるチケットを検出し、Webhookを呼び出します。
次の条件で新しいトリガーを作成します。
- すべて満たす: チケットが作成された
- いずれかを満たす: 組織 > 自動フォローが存在する
次のアクションを追加します。
- 通知方法: アクティブなWebhook(作成したWebhookを選択)
- JSON本文:
{"ticket": {"followers": [
{% assign emails = ticket.organization.custom_fields.auto_follow | split: ',' %}
{% for email in emails %}{"user_email": "{{ email | strip }}", "action": "put"}{% unless forloop.last %},{% endunless %}{% endfor %}
]}}
このLiquidマークアップは、カスタムフィールドからカンマ区切りのメールを解析し、API用のJSONオブジェクトとしてフォーマットします。

テストと検証
本番環境に移行する前に:
- 最初にZendeskサンドボックスでテストします
- 自動フォローフィールドに自分のメールアドレスを入力してテスト組織を作成します
- エンドユーザーとしてチケットを送信します
- フォロワーとして追加されたことを確認します
- 管理センターでWebhookログをチェックして、エラーがないか確認します
一般的な問題のトラブルシューティング
競合状態: 同じチケットを更新する複数のWebhookが同時に発生した場合、更新の競合が発生する可能性があります。この場合、APIは409 Conflictエラーを返します。大量のインスタンスの場合は、トリガーサイクルが完了した後に実行が保証されるため、Webhookの代わりにZIS(Zendesk Integration Services)フローの使用を検討してください。
メール検証の失敗: Regexが無効なメールを許可する場合、APIは存在しないユーザーをサイレントに無視します。検証パターンを再確認し、さまざまなメール形式でテストします。
Webhookのタイムアウト: Zendesk Webhookは10秒後にタイムアウトします。インスタンスが遅い場合、またはAPIで遅延が発生している場合は、Webhook呼び出しが失敗する可能性があります。重要なワークフローには、再試行ロジックを実装するか、ミドルウェアサービスを使用してください。
方法3:eesel AIによるAI搭載の自動化
WebhookとJSONペイロードの管理をせずにインテリジェントなフォロワー割り当てを必要とするチームには、別のアプローチを提供します。当社のプラットフォームはZendeskに接続し、技術的な構成ではなく、自然言語ルールを通じてフォロワーの自動化を処理します。
Zendeskをどのように補完するか
Zendeskと直接統合して、次のことを行います。
- チケットの内容、組織データ、およびカスタムフィールドを読み取る
- インテリジェントなルールを適用して、各チケットをフォローする必要がある人を決定する
- 同じAPI Webhookを使用してフォロワーを自動的に追加する
- 手動介入なしに、エラー、再試行、およびエッジケースを処理する
Webhookアプローチに対する利点
| 特徴 | Webhookメソッド | eesel AI |
|---|---|---|
| セットアップの複雑さ | JSON/Liquidコーディングが必要 | 自然言語ルール |
| エラー処理 | 手動監視が必要 | 組み込みの再試行ロジック |
| ロジックの複雑さ | フィールドマッチングに限定 | AI搭載のルーティング決定 |
| メンテナンス | 技術管理者が必要 | ビジネスユーザーフレンドリー |
| スケーラビリティ | 手動Webhook管理 | 自動スケーリング |
Liquidマークアップを記述する代わりに、「従業員が500人を超える組織からのチケットについては、エンタープライズアカウントマネージャーをフォロワーとして追加する」または「製品フィールドに「エンタープライズスイート」が含まれている場合は、テクニカルリードを含める」のようなルールを定義します。
当社のAIトリアージは、チケットの内容を読み取ってコンテキストを理解し、フィールド値を照合するだけではありません。これは、感情、緊急信号、または標準トリガーでは不可能な要因の複雑な組み合わせに基づいてルーティングできることを意味します。
セットアップの概要
- Zendeskアカウントをeesel AIに接続します
- プレーンな英語でフォロワールールを定義します
- 過去のチケットに対してテストします
- 自信を持ってデプロイします
このアプローチを選択する場合
次の場合にeesel AIを検討してください。
- Webhookアプローチがチームにとって技術的すぎる
- 単純なフィールドマッチングを超えたAI搭載のルーティングが必要
- カスタム開発なしで組み込みのエラー処理が必要
- フォロワーロジックに複雑なビジネスルールが含まれている
- すでにAIツールを使用しており、統合された自動化が必要
Zendeskトリガーのカスタムフィールド自動化によるフォロワー追加のベストプラクティス
どの方法を選択する場合でも、次の原則に留意してください。
セキュリティ: APIトークンを共有ドキュメントではなく、安全な資格情報マネージャーに保存します。トークンを四半期ごとにローテーションします。Webhook認証には、個人の管理者資格情報ではなく、専用のサービスアカウントを使用します。
パフォーマンス: Webhookは、チケット処理にわずかな遅延(通常1〜3秒)を追加します。1時間あたり数千枚のチケットを処理するインスタンスの場合は、APIレート制限を回避するために、ZISフローまたはバッチ処理を検討してください。
通知のタイミング: フォロワーは、追加されたときにすぐに通知を受け取りません。次の公開コメントまたは内部コメントで通知を受け取ります。チームとそれに応じて期待を設定します。
テスト: 常に最初にサンドボックスで検証します。空のフィールド、不正な形式のメール、および同時更新などのエッジケースをテストしてから、本番環境にデプロイします。
ドキュメント: カスタムフィールドの命名規則、Webhookロジック、およびLiquidマークアップをドキュメント化します。次の管理者は、トラブルシューティングまたは自動化を拡張する必要がある場合に感謝します。
監視: Webhookの失敗に関するアラートを設定します。Zendeskは管理センターでWebhookの試行をログに記録しますが、プロアクティブな監視は、運用に影響を与える前に問題をキャッチします。
スケーラビリティ: 成長を計画します。個々のトリガーは、約20〜30の組織で機能しなくなります。Webhookはさらに拡張できますが、より多くのメンテナンスが必要です。12か月の成長予測に合ったアプローチを選択してください。
Zendeskのビジネスルールのより広い理解については、Zendeskビジネスルールの完全なガイドをご覧ください。
チームに適したアプローチを選択する
決定を支援するための簡単なフレームワークを次に示します。
| チーム規模 | 技術リソース | 推奨アプローチ |
|---|---|---|
| 1〜10組織 | 任意 | 個別のトリガー |
| 10〜50組織 | 技術管理者が利用可能 | Webhookメソッド |
| 50以上の組織 | 任意 | eesel AIまたはカスタム開発 |
| 複雑なルーティングのニーズ | 制限あり | eesel AI |
シンプルに始めましょう。ニーズの進化に応じて、個別のトリガーからWebhookに、またはWebhookからAI自動化にいつでも移行できます。重要なのは、決して実現しない可能性のある将来のシナリオのために過剰なエンジニアリングを行わずに、迅速に価値を得ることです。
フォロワーの割り当ての自動化を開始する
これで、Zendeskトリガーのカスタムフィールド制限によるフォロワー追加を解決するための3つの実行可能なパスが得られました。個々のトリガーのシンプルさ、Webhookのスケーラビリティ、またはAI自動化のインテリジェンスを選択するかどうかにかかわらず、目標は同じままです。手作業なしで、適切な人をチケットに参加させます。
運用上の利点はすぐに積み重なります。アカウントマネージャーはクライアントについて常に情報を把握しています。技術スペシャリストは関連する問題の可視性を得ます。適切な人がすでにフォローしているため、エスカレーションが迅速に行われます。
WebhookとJSONを管理せずにインテリジェントなフォロワー自動化を実装する準備ができている場合は、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.