チケット重複排除のためのAIは、実は同じ依頼であるチケットを見つけ、1人の顧客のチケットは統合し、多数の顧客のチケットは1つの親チケットにリンクします。これで同じ内容に2度回答することがなくなり、チケット数が実態を歪めることもなくなります。この2つは別の作業で、混同するのが最もよくある間違いです。障害に関する40件の報告を1つのチケットに統合すると、39人の顧客は返信を受け取れません。
ほとんどのヘルプデスクは、すでに1つ目の作業を備えています。Zendeskは、チケットの前後2週間以内の同じ依頼者のチケットについて統合を提案します。monday serviceのSidekickは、過去30日間の同じ依頼者のペアにフラグを付けます。HappyFoxには、監督モード付きのDuplicate Ticket Detectorがあります。Zendeskの統合は元に戻せません。そのため、どのネイティブツールも提案までで止まり、統合のクリックは人に任せています。
最も安いのは、誰も2度作業しない重複です。eeselのようなAIチームメイトは、最初のメッセージで依頼者の未解決チケットを確認し、繰り返しにタグを付け、メモに元のチケットをリンクして、回答を1回で済ませます。Dokument 24では、顧客の最初のメッセージにだけeeselを動かしているため、チームがすでに対応しているスレッドのフォローアップには手を出しません。
なぜ重複チケットは何度も現れるのですか？
私は検索データを扱う時間が長いのですが、「チケット重複排除」は、1つのキーワードの裏に2つの別の問題が隠れている言葉の1つです。これを検索する人の中には、せっかちな顧客が3回メールしてきたという人もいます。一方で、障害が起きて200人が報告したという人もいます。前者の対策は後者を壊してしまうので、何かを買う前に、自分がどちらなのかを把握しておく価値があります。
重複が生まれるのは、次のようなかなり限られた場所です。
- 顧客が返信せずに新しいスレッドを始める。 こちらのフォローアップに新規メールで返したり、途中でチャットからメールに切り替えたりします。
- 1通のメールが2つの受信箱に届く。 2つのサポートアドレスやヘルプデスクが別々の2チームをCCに入れると、1通のメッセージが2つのチケットになります。
- インシデントが同時に多くの顧客に影響する。 決済のバグやログイン障害は、影響を受けた顧客ごとに1件の報告を生みます。
- チケットIDのない自動メール。 ベンダーのアラートやシステム通知は、元の参照番号を含まないため、毎回新しいチケットを作ります。
- AI自身。 アクションを再試行したり、自分の返信を新しい顧客メッセージと読み取ったりするエージェントは、どの顧客よりも速く重複を作れます。
1つ目のケースについて、あるシステム管理者の説明は痛いほど見覚えがあります。
"However end users such as they are fail to reply with an attachment - and just send in a new job."
そして、人事部門用に2つ目のZendeskインスタンスを追加したチームの、2つの受信箱のケースです。
"At times the requester emails both the teams. When one of the instances reply to the email the other team gets a new ticket instead of the same conversation getting appended to the existing ticket."
リストの最後の原因は、2026年に私が最も真剣に捉えるものです。自社側で実際に起きるのを見てきたからです。eeselでは、共有トリガーで2つ目のAIエージェントが最初のエージェントと衝突し、メモの重複や二重返信が起きた顧客がいました。また、AIが自分の返信を新しい顧客メッセージとして扱いループし続けたことで、最優先のバグをエスカレーションした顧客もいました。これらは修正済みで、教訓は残っています。トリガーごとにエージェントは1つ、そして行動する前に必ず、すでに開いているものを確認するということです。まさにこの問題のためのガードを作った開発者は、こう端的に述べています。
"While experimenting with LLM agents calling tools, I ran into a reliability problem: retries can easily trigger irreversible actions more than once."
重複チケットとは何を指しますか？
重複チケットとは、チームがすでに対応している依頼についての2枚目のチケットです。どう扱うかという観点で役に立つ分け方は、誰が送ったかです。
| 同じ顧客、複数のチケット | 多数の顧客、1つのインシデント | |
|---|---|---|
| 例 | 注文についての質問をメールで、次にチャットで、さらに「進捗はありますか？」というメールで送る | リリース後に60人が同じログインエラーを報告する |
| 正しい対応 | 1つのチケットに統合する | 各チケットを1つの親にリンクし、開いたままにする |
| 理由 | 1人、1つの会話、1つの回答 | 各顧客にはそれぞれ返信とステータスの更新が必要 |
| そうしないと起きること | 2人の担当者が返信し、ときに回答が食い違う | 統合で59件が閉じられ、その顧客には何も届かない |
| ネイティブのツール | 統合の提案、自動統合アプリ | Zendeskの問題とインシデントのタイプ、Freshdeskの親子チケット |
重複に見えて重複ではない、3つ目のグループもあります。「注文はどこですか？」のように、異なる顧客が同じよくある質問をするケースです。これらは繰り返し発生するサポートチケットであり、解決策は統合ではなく、より良い回答やFAQによる自己解決の促進です。
AIはどのように重複チケットを検出しますか？
AIは2段階で重複を検出します。まずキューを少数の有力な候補に絞り込み、次に各候補がどれだけ近いかをスコアリングします。安全性を担っているのは主に候補の絞り込みで、私が調べたどのベンダーも、AIが1語を読む前に、同じ依頼者と期間で絞り込むところから始めています。
monday serviceは、これまで見つけた中で最も明確なルールを公開しています。Sidekickの重複検出は、同じボードで、同じ依頼者のメールアドレスから過去30日間に作成された未解決のチケットだけを対象にします。チケット名と説明を意味で比較し、両方が一致する必要があります。カテゴリが一致しても「確信度は高まるが、それだけでは提案のトリガーにならない」とされています。Zendeskの統合の提案は、現在のチケットの前後2週間にある同じ依頼者のチケットを使い、同じブランド内に限られます。
実際のシグナルは次のようになります。
- 同じ依頼者。 最も安全なシグナルです。ほぼすべての組み込みツールが必須としています。
- 期間。 数か月ではなく数日。HappyFoxでは、さかのぼる期間を自分で選べる設定にしています。
- 件名と説明の意味。 「チェックアウトでカードが拒否された」と「支払えない、決済に失敗したと出る」は、共通の単語がなくても一致するべきです。
- 共通の識別子。 注文番号、エラーコード、デバイスID。チームからよく求められます。
"We put our order number in a custom field and it would be very helpful to merge tickets based on this field."
次に、各確信度で何をしてよいかを決めます。ここが最も重要な部分です。
確信度の高い一致にはタグと元のチケットへのリンクを付け、中程度の一致は担当者が承認できる提案として表示し、低い一致は別のチケットのままにします。統合そのものは、少なくともAIがどれくらいの頻度で正しいかを計測するまでは、人のクリックにしておきます。これは、AIタグ付けの誤検出を調整するのと同じ規律です。
自治体のチケットシステムについて研究した人の、私が何度も立ち返る知見があります。
"Research showed that pure AI and pur human outperformed co-working. Human oversight often e.g. overcorrected machine work."
レビューキューへの妥当な警告です。担当者が良い提案のすべてを疑えば、両方のコストがかかるのにどちらの速さも得られず、誰も満足しません。対策は、AIの仕事を狭く測定可能なもの（タグ付けとリンク）に保ち、人の確認が全面的な再調査ではなく、すばやい「はい」で済むようにすることです。
すでにAIでチケットを重複排除しているヘルプデスクはどれですか？
大手のヘルプデスクの多くは、今では何らかの形でこれを備えており、ほぼ常に同じ依頼者に限定されています。各社が実際に何をするかを、ベンダー自身のドキュメントから示します。
| ヘルプデスク | 機能 | 何を照合するか | 何をするか | 誰が統合するか | プランまたは価格 |
|---|---|---|---|---|---|
| Zendesk | 統合の提案 | 同じ依頼者、±2週間、同じブランド | 関連チケットに候補を表示 | 担当者が確定 | SuiteまたはSupport Professional以上、月ごとのCopilot利用枠 |
| Zendesk | Auto Mergeアプリ（マーケットプレイス） | 任意のチケットフィールドのルール、期間 | リアルタイムまたはスケジュールで統合 | ルール | 14日間の試用後、月額99ドル、199ドル、または999ドル |
| monday service | Sidekickの重複検出 | 同じ依頼者、未解決、過去30日、同じボード | 統合を準備し、ペアを一致度順に並べる | 担当者が確定 | AIの提案はデフォルトでオン、管理者はオフにできる |
| HappyFox | Duplicate Ticket Detector | 同じ連絡先、設定した期間 | 重複の可能性があるものにフラグとタグを付ける | 監督モードまたはオートパイロット | HappyFox Autopilotが必要 |
| Freshdesk | Merge Duplicate Ticketsアプリ（マーケットプレイス） | 同じ依頼者またはカスタムルール | 自動で統合し、溜まった分の統合も可能 | ルール | アプリの掲載ページを参照 |
| Freshservice | 手動の統合、Auto Ticket Mergerアプリ | 送信者や件名などのルール | メモを付けて二次チケットを閉じる | 担当者またはルール | ネイティブの自動統合なし |
Zendesk。統合の提案は、関連チケットのアイコンに赤いバッジで表示されます。チケットにチェックを入れ、統合をクリックし、統合コメントを確認して確定します。異なる依頼者、組織、ブランドをまたいで統合する場合は、先にZendeskが警告を表示します。利用がCopilotの枠に数えられるのは、確認して統合をクリックしたときだけなので、見るだけなら無料です。Zendesk CopilotのバンドルとZendeskのAI料金については、別の記事で詳しく説明しています。
クリックなしで統合したい場合は、ZendeskマーケットプレイスのAuto Mergeアプリが、同じ依頼者の重複をルールで統合します。任意のチケットフィールドで照合し、期間を設定し、新しいチケットと古いチケットのどちらに統合するかを選び、溜まった分に対してスケジュールジョブを実行できます。AIではなくルールベースですが、元に戻せない操作については、正直なところ利点です。
**monday service。**Ticketsボードを開くと、Sidekickが最近の未解決チケットをスキャンし、重複の可能性があるものの横にアイコンを表示します。主となるチケットを選んで確定します。重複は閉じられ、共同作業者は主のチケットに移されます。顧客が後で閉じたチケットのメールスレッドに返信しても、その返信は閉じたチケットに残ります。管理者は、これらのプロアクティブな提案をオフにして、バックグラウンドでのAIクレジットの消費を止められます。
HappyFox。Duplicate Ticket Detectorは、HappyFoxのAutopilot AIエージェントの1つです。同じ連絡先から来た重複の可能性があるものにフラグを付け、選択したチケットカテゴリに限って、自分で決めた重複チケットのタグを追加します。設定で私が最も気に入っているのは、HappyFoxが狭く始めて、チームが結果を確認するまで監督モードを使うよう勧めている点です。費用については、HappyFoxの料金の解説をご覧ください。
**FreshdeskとFreshservice。**Freshdeskの統合は標準では手動です（Freshdeskのチケット統合のガイドを参照）。自動統合はマーケットプレイスから提供され、たとえばMerge Duplicate Ticketsアプリは、同じ依頼者のチケットや独自のルールに基づいて統合します。Freshserviceの公式ヘルプ記事は、ネイティブにはチケットを自動統合しないと明記し、Auto Ticket Mergerアプリを案内しています。
重複チケットは統合すべきですか、リンクすべきですか？
1人の顧客なら統合、多数の顧客ならリンク、迷ったらリンクです。リンクは後で外せますが、統合は通常そうはいきません。
Zendeskの統合のルールを見れば、慎重になる価値がわかります。
- 統合は元に戻せません。
- 統合するには、チケットのステータスが「解決済み」より前である必要があります。
- 閉じられたチケットの依頼者は、CCが有効であればCCに追加されます。
- 統合で閉じられたチケットには
closed_by_mergeタグが付き、統合済みのチケットをレポートから除外するのに使えます。 - ZendeskのAIエージェントが対応しているチケットは統合できません。
ほかのヘルプデスクにも、それぞれ落とし穴があります。Freshserviceでは、統合すると二次チケットが閉じられてプライベートメモが追加され、ほかの依頼者は担当者が一度手動でCCフィールドに追加する必要があります。monday serviceでは、古いメールスレッドへの返信が閉じたチケットに届きます。どれも致命的ではありませんが、自動統合ルールが午前2時につまずきやすい、まさにそうした細部です。
インシデントには、代わりに親チケットを使います。Zendeskの問題とインシデントのタイプや、Freshdeskの親子チケットでは、1つのチケットで調査を進めつつ、各顧客は返信を受け取るチケットを持ち続けられます。AIが各報告に回答するこの構成は、SaaS障害時のAIカスタマーサポートのガイドで詳しく説明しています。
重複チケットにはいくらのコストがかかっていますか？
重複は2回コストがかかります。1回目は担当者の時間、2回目はレポートです。重複が10%あるキューは、実際より10%忙しく見えるからです。先月の数字を入力して、両方を確認してください。
4番目の数字は、見落とされがちです。ほとんどのAIエージェントは、eeselを含めてチケット単位または会話単位で課金されるため、AIに届いた重複は他のチケットと同じように請求されます。これも、両方が処理された後ではなく、入口で繰り返しを捕まえるべき理由の1つです。
重複排除はどこで行うべきですか：到着時、キュー内、それともレポートですか？
3つすべてです。そしてそれぞれ別の作業です。ネイティブのツールの多くは真ん中をカバーしていますが、最も節約になるのは最初のものです。
**到着時。**誰かが返信する前に、依頼者のほかの未解決チケットを確認します。一致するものがあれば、タグを付け、内部メモに元のチケットをリンクし、回答が付くチケットを1つだけにします。ここは、すべての新規チケットをすでにトリアージのために読んでいるAIが真価を発揮する場面です。検索に追加コストがかからないからです。スパムとノイズのフィルタリングもここに属します。不在通知や通知メールは、誰も対応するべきでないもう1種類のチケットだからです。
**キュー内。**統合の提案、スケジュールされた自動統合ルール、すり抜けたものを拾う毎日のスイープ。Zendeskの提案や一括統合ビューがここに当たります。
**レポート内。**チケットではなく、ユニークな依頼を数えます。Zendeskではclosed_by_mergeを除外し、重複タグをフィルタに追加して、次の3つの数字を追跡します。重複率、担当者がAIの提案を受け入れる頻度（適合率）、AIが見逃してチームが今も手動で統合している重複の数（捕捉率）です。これらが全体のレポートにどう収まるかは、サポートレポートのAI活用の記事とAIカスタマーサービス指標の一覧で説明しています。
AIによるチケット重複排除を安全に導入するには？
最も安全な一致から始めて2週間観察し、その後で網を広げます。私ならこの順序で進めます。
- **まず問題を測定する。**先月の手動統合の件数を数え、50件のチケットをサンプリングして繰り返しを確認します。重複が全体の2%未満なら、統合提案パネルで十分です。
- **対処できる発生源を直す。**ベンダーにチケットIDを件名に残すよう依頼し、1つのアドレスを2つのインスタンスに振り分けるのをやめ、テンプレートで「このメールに返信してください」をわかりやすくします。
- **ヘルプデスクにすでにある機能をオンにする。**Zendeskの統合提案、mondayのSidekick、または監督モードのHappyFoxのディテクターです。
- **統合する前にタグを付ける。**AIに
possible_duplicateタグと、元のチケットをリンクしたメモを追加させます。毎週サンプルを確認し、タグがいくつ正しかったかを記録します。 - **最も狭いルールに限って統合を自動化する。**同じ依頼者、同じ件名、24〜48時間以内。依頼者をまたぐものは、リンクにとどめます。
- **インシデントは別に扱う。**異なる顧客から似たチケットが急増したら、親チケットを1つ作り、AIに各報告をリンクさせ、既知の問題についての更新で回答させます。リリース時の同じパターンは、季節的なピークのガイドで紹介しています。
- **ユニークな依頼でレポートする。**タグが信頼できるようになったら、週次レポートの見出しの数字を切り替えます。
eeselは重複チケットをどう扱いますか？
eeselは、チケットをトリアージして回答するのと同じ処理の中で、到着時に重複を扱います。できないことは正直にお伝えします。eeselには統合アクションがありません。eeselのZendeskアクションは、返信、内部メモ、下書き、タグの追加、割り当て、クローズ、フィールドの更新、作成、そしてチケットの読み取り、検索、一覧表示です。つまり統合は、ネイティブツールとその警告がある自社のヘルプデスクに残り、eeselはそれらが行わない部分、つまり2枚目のチケットに作業が行われるのを防ぐ役割を担います。
実際には、指示は次のようになります。eeselのAIヘルプデスクエージェントで、普通の言葉で書きます。
- 顧客の最初のメッセージで、その顧客の過去14日間の未解決チケットを検索する。
- 同じ内容のものがあれば、新しいチケットに
possible_duplicateタグを付け、元のチケットをリンクした内部メモを残し、2つ目の回答の下書きは作らない。 - 新しい内容であれば、いつもどおりトリアージして回答する。
- 障害の場合は、新しい報告をそれぞれ親チケットにリンクし、現在のステータス更新を送る。
これを機能させる設定が2つあります。1つ目は、eeselが最大15分間処理前に待機できることです。これにより、Zendeskの自社トリガー、スパムルール、新規チケットで動くそのほかのものが先に実行されます。2つ目は、スケジュール実行ができることです。朝のスイープで重複に見えるチケットを一覧にし、何も変更せずにリーダーへメールで送れます。
実際のお客様の例です。
- **Dokument 24**は、Zendeskでeeselを稼働させ、顧客の最初のメッセージでだけ起動しています。"so follow-ups in a thread the team is already handling are left alone." 1か月で約
680件のチケットをチーム向けに準備し、約670件のデンマーク語の返信下書きを内部メモとして残しました。 - **Rúngne**は、Gorgias上のトリアージエージェントが、固定のリストからすべてのチケットにタグを付け、ソーシャルのコメント、不在通知、スパムを閉じています。下書きエージェントは、何かを書く前にまずスレッド全体を読み、チームメイトがすでにした約束がないかを確認します。その結果、1か月で約
2,100件のチケットを処理しました。 - **Cape Coffee Beans**は、すり抜けたチケット（グループ未設定、フォローアップ日なし、フォームの誤り）に対して、5つのスケジュールされたZendeskのスイープを、ほとんど毎朝実行しています。スイープは読み取り専用で、創業者宛ての短いメールで終わります。これは、まさに重複のスイープがとるべき形です。
本番に移す前に、eeselのシミュレーション機能が過去のチケットを再生し、実際のチケットに対して何をしたかを確認できます。また、チームがターミナルを好む場合は、eesel CLIで同じエージェントを操作できます。eesel activityは実行内容を新しい順に表示し、スクリプトやClaude Codeから重複タグを監査する最速の方法です。
AIによるチケット重複排除にはいくらかかりますか？
提案ツールはすでに支払っているプランに含まれていることが多いため、追加料金がかからないことも多いです。各オプションの位置づけは次のとおりです。
| オプション | 課金方法 | 備考 |
|---|---|---|
| Zendeskの統合提案 | SuiteおよびSupport Professional以上に含まれる | 統合を確定したときだけ月ごとのCopilot利用枠に数えられる |
| ZendeskのAuto Mergeアプリ | 月額99ドル、199ドル、または999ドル | 14日間の無料試用、ルールベース |
| monday service Sidekick | monday service内のmonday AIの一部 | プロアクティブな提案はバックグラウンドでAIクレジットを使うことがある |
| HappyFox Duplicate Ticket Detector | HappyFox Autopilotの一部 | アカウントでAutopilotへのアクセスが必要 |
| FreshdeskのMerge Duplicate Ticketsアプリ | マーケットプレイスの掲載 | 溜まった分の統合はアドオンサービスとして販売 |
| eesel | 100クレジットの無料プラン、その後は500クレジットで月額299ドル | チケットまたはチャット1件が1クレジット、全機能込み、料金の詳細 |
Zendeskをお使いなら、まず統合の提案から始めて、どこまで対応できるか確認してください。自動統合アプリは、同じ依頼者という狭いルールにだけ追加します。実際のコストが統合のクリックではなく2回目の返信にあるときに、AIチームメイトを追加します。Zendesk、Freshdesk、Gorgiasを使っていて、すでに初回問い合わせでの解決や対応時間の支援を求めているチームでは、たいていそうなります。
重複チケットにeeselを試す
2人の担当者が同じ顧客に回答し続けているなら、eeselは新しいチームメイトのように、お使いのZendesk、Freshdesk、またはGorgiasのキューに加わります。返信する前に依頼者の未解決チケットを確認し、繰り返しにタグを付け、元のチケットをリンクして、回答を1回で済ませます。本番のチケットに触れる前に、過去のチケットを再生して何をしたかを確認することもできます。無料プランは100チケットまで対応しており、自社のキューで試すには十分です。eeselを試す。
