AIによるチケットと会話の要約：何を押さえるべきか

著者: Linh Ngo · 更新日: 2026年10月11日

AIチケット要約とは、サポートのチケット、チャット、通話を機械が短くまとめたもので、次の担当者に、顧客が何を求めているか、何が試されたか、次に何が起こるかを伝えます。 担当者が最も嫌がる2つの作業、つまり返信する前に40件ものメッセージをスクロールすることと、電話を切った後にまとめのメモを打ち込むことを肩代わりします。うまく使えば、エスカレーションやシフトの交代を最も手早く、スムーズにする方法です。下手に使えば、肝心な1つの詳細をひそかに落とした、自信に満ちた1段落になってしまいます。

このガイドでは、役に立つ要約に含めるべき内容、3つの主要プラットフォームが要約を生成する仕組み、誤りが生まれる原因、そしてチームが信頼できるように要約を展開する方法を扱います。AI for Customer Serviceコレクションの一部なので、先に全体像を知りたい方は、カスタマーサービスにおけるAIから始めてください。

重要なポイント

• ZendeskのAIチケット要約は最大100語までに制限されており、デフォルトでは公開コメントを使用し、サイドカンバセーションは除外されます。
• Salesforceのワークサマリーは、要約、問題、解決策の3つの出力を予測し、管理者は担当者のレビューなしで保存することを選べます。
• ベンダーが報告した事例では、AIによる通話後の要約で、担当者は1通話あたり平均40〜60秒を節約しました（Observe.AIが、顧客のDailyPayについて説明したものです）。
• ASAPPによる大規模な企業のコンタクトセンター1社の分析では、通話の13%に一切の間がありませんでした。通話中にメモを打つのがうまくいかない理由の1つです。
• 対話要約の学術的なベンチマークでは、モデルの大きさにかかわらず、相当な量の事実誤りが見つかっているため、人によるチェックは引き続き必要です。

要約は何のためにあるのか

サポートの要約には2種類の読み手がいて、求めるものが違います。

1つ目は次の対応者です。エスカレーションされたチケットを引き継ぐ担当者、次のシフトの人、火曜の朝にその案件を受け取る専門担当者です。スレッドを読まずに、1、2分で行動する必要があります。

2つ目は記録です。数週間後に、CRMを検索している人、QAのレビュー担当者、レポートを作っているマネージャーは、その問い合わせが何についてのもので、どう終わったのかを知りたがります。この読み手に必要なのは、きれいな段落ではなく、一貫した言葉遣いと構造化されたフィールドです。

最良の仕組みは両方に応えます。短い文章の要約が引き継ぎを担い、同じ出力が（問題、解決策、ステータスなどの）フィールドにマッピングされるので、絞り込みや集計ができます。Salesforceの設計はこれを反映しています。生成AIのワークサマリーは、要約、問題、解決策を出力し、それらの出力はオブジェクトのフィールドにマッピングできます。

ACEの観点では、要約は、テキストと通話音声に対するIngest・Analyze・Generateの仕事です。Meeting Intelligenceパターン（会話が入力され、メモが出力され、そのメモが適切なシステムに送られる）に沿っており、担当者が下書きをレビューして承認する場合は、Workflow Copilotパターンにも該当します。

良い要約に含まれるもの

Zendeskのドキュメントは、要約が扱いうる内容を挙げています。主な問題、顧客が期待していること、実施した対応、結果、現在のステータスです。さらに、根本原因、ビジネスへの影響、期限、そして会話がAIエージェントから人に移った場合は、顧客がすでにそのエージェントと話した内容も挙げています（Zendesk）。これは出発点として悪くないリストで、自社の業務に合わせて絞り込めます。

要約を、読める長さに保つルールが2つあります。1つ目は、依頼内容とステータスを先頭に置き、その後に補足の詳細を続けることです。2つ目は、正確さが求められるものは原文のまま残すことです。注文ID、エラーコード、引用された約束などです。エラーコードを言い換えるモデルは、役に立つ部分を消してしまっています。

主要プラットフォームの要約の生成方法

仕組みは設計に影響するほど違うので、誰に何を見せるかを決める前に、各ベンダーのドキュメントを読む価値があります。

Zendesk。 チケット要約は最大100語に制限されます。デフォルトでは、チケットの公開コメントが含まれます。内部メモはオプトインの設定で、サイドカンバセーションは含まれません。担当者が更新したときに、要約をチケットのフィールドに保存でき、フィールドには最新のバージョンが保持され、Zendeskは、クローズ済みのチケットの要約は保存されないと述べています（Zendesk）。このデフォルトは重要です。エンジニアがサイドカンバセーションで連携している場合、要約はその作業を見ることができません。

Salesforce。 ワークサマリーは、会話の終了時、またはケースページから実行されます。メッセージングと音声では、下書きが自動で生成され、担当者がレビューし、編集して保存します。管理者は自動保存をオンにでき、その場合は担当者のレビューなしで要約が保存されます。音声の要約は、通話の終了時にデフォルトで生成され、担当者はこれをオフにできます（Salesforce）。最も慎重に考えるべきなのは自動保存のオプションです。唯一の人によるチェックがなくなるからです。

Intercom。 AI要約機能は、別のチームメイトに引き継ぐ前に、顧客との会話やチケットのAI生成の要約を作成します。位置づけは、はっきりと引き継ぎのためのツールです。

共通点は次のとおりです。3つとも、要約を人が読む下書きとして扱っており、どのテキストを入力に含めるかについて、それぞれ選択をしています。どのツールを評価するときも、どの元素材を読むのか（公開の返信のみか、内部メモか、添付ファイルか、通話音声か）、何を無視するのか、保存前に出力を編集できるのかを確認してください。

要約がうまくいかない場面

要約が失敗する方法は2つあります。何かを落とすことと、何かを入れてしまうことです。

抜け。 要約はなめらかに読めるのに、詳細が落ちています。エラーコード、期限、約束、あるいは顧客が法的措置をほのめかした1文かもしれません。語数の上限（Zendeskは100語）はトレードオフを強いますが、どの詳細が切り捨てられるかを決めるのはモデルです。抜けは、何も間違って見えないため、見つけにくいものです。次の担当者が、顧客がすでに答えたことを尋ねて、初めて気づきます。

ハルシネーションと、裏付けのない推論。 要約が、会話にないことを述べています。対話要約の研究では、これが繰り返し報告されています。TofuEvalベンチマークは、対話要約においてLLMがモデルの大きさにかかわらず相当な量の事実誤りを生み、LLMによる審査役はそれを見つけるのが下手で、専門の事実性指標のほうが優れていたことを明らかにしました（arXiv）。GPT-4とAlpaca-13Bを対象にした別の研究は、状況的推論というカテゴリを提案しました。会話が実際には述べていないことを、文脈からモデルがもっともらしく結論づけてしまうものです（arXiv）。サポートの場面では、顧客が返金の仕組みを尋ねただけなのに、要約が「顧客は返金を求めている」と書くようなことです。最近の複数シナリオを対象にした研究も、カスタマーサービスを、忠実性の課題が中程度から高い分野として挙げています（arXiv）。

注意すべき失敗のパターンと、実際の現れ方を示します。

これは、要約が使えないという意味ではありません。要約は下書きであり、時間を節約できるか、ひそかな誤りを生むかは、プロセスの質で決まるということです。

実際の業務フローでの要約

ティア1からティア2へのエスカレーション。 古典的な使い方です。ティア1は3つの対処を試しました。要約がなければ、ティア2はスレッド全体を読むか、診断を最初からやり直します。要約があれば、最初の行に、何を試して何が失敗したかが書かれています。エスカレーションでは、「すでに試した手順」の行を必須にしてください。

24時間体制のチームでのシフト交代。 マニラの担当者が、未解決の案件をダブリンの同僚に引き継ぎます。ほとんどのチケットでは、要約が引き継ぎミーティングの代わりになります。それぞれに明確なステータスと次のアクションを加えてください。「顧客の返信待ち」と「エンジニアリング待ち」は、シフトの開始時にはまったく意味が違うからです。

電話サポートでの通話後の作業。 メモを書くには時間がかかります。ベンダーであるASAPPは、メモの作成に実際の通話時間の平均10%がかかると述べており、大規模な企業のコンタクトセンター1社の分析では、通話中のメモ入力は現実的ではないことが示唆されています。通話の半数で、2分間に10秒を超える間が1回もなかったのです（ASAPP）。AIにメモを下書きさせ、担当者がレビューするようにすれば、その作業がクリティカルパスから外れます。Observe.AIは、顧客のDailyPayが、この方法で1通話あたり平均40〜60秒を節約したと報告しています（Observe.AI）。どちらもベンダーが公表した数字なので、自社で測定してください。

アカウントマネジメントとカスタマーサクセス。 アカウントを引き継ぐCSMには、100件のチケットではなく、過去の問題の履歴を1段落で伝えるものが必要です。最近の問い合わせの要約を、テーマごとにまとめれば、更新の商談の前の十分な説明資料になります。

ITヘルプデスクと社内サービス。 依頼が、ヘルプデスク、セキュリティ、アプリケーションの責任者の間を行き来します。引き継ぎのたびに要約があれば、従業員が同じ説明を繰り返さずに済みます。同じ規律が当てはまります。依頼、試したこと、ステータス、担当者です。

品質レビューとコーチング。 要約は、レビュー担当者が会話を開く前に、それぞれが何についての会話だったのかを素早くたどれる索引になります。読むことの代わりにはなりませんが、どの会話を読むかを選ぶのに役立ちます。同じデータは、サポートのためのAI品質保証にも使えます。

要約の展開方法

1. 改善する引き継ぎを1つ選ぶ。 エスカレーション、シフト交代、通話後の作業のどれが課題かを選びます。あらゆる場所で一度に要約を始めないでください。
2. テンプレートを定義する。 上の表のフィールドを、その引き継ぎに必要なものに絞って使います。短い仕様として書き留めてください。仕様のない要約は、モデルが書きたいように書いたものになります。
3. 入力を決める。 公開の返信だけか、内部メモも含めるか。通話音声か、トランスクリプトか。添付ファイルは。除外した入力は抜けの原因になりえますし、含めた入力は、機密性の高い内容を取り込むかもしれません。
4. 要約の保存先を決める。 チケットのフィールド、内部メモ、CRMのレコードのいずれかです。フィールドに保存すれば、検索やレポートができます。更新した要約が古いものを上書きするかどうかを、明確にしてください。
5. 最初は承認のステップに人を置く。 保存する前に、担当者に読んで編集してもらいます。エラー率を測定するまでは自動保存をオフにし、規制対象や重大なトピックでは、オフのままにします。
6. 精度チェックの仕組みを作る。 毎週、要約のサンプルを抽出し、元の会話と比較します。それぞれを、完全で正確、重要な何かが欠けている、裏付けのない内容を含んでいる、のいずれかに分類します。これは、AIの解決率を正直に測る方法で説明されているのと同じサンプリングの規律です。
7. 下流のシグナルを追跡する。 受け取る側の担当者が、顧客がすでに答えた質問を再度尋ねる頻度、情報不足でエスカレーションが差し戻される頻度、1件の問い合わせあたりの後処理の分数を数えます。それが、要約が役に立っているかを教えてくれます。
8. テンプレートを調整する。 レビュー担当者が、同じもの（期限、プランのティア）を毎回手作業で加えているなら、仕様に入れます。
9. データのルールを書く。 要約は、顧客の詳細を新しい場所にコピーします。決済情報や健康情報など、除外すべきものと、保存された要約を誰が読めるかのルールを定めてください。

入力も、思われている以上に重要です。チケットのフィールド、タグ、メモに一貫性がなければ、要約もその乱れを映します。AIのためのサポートデータの準備では、これをうまく機能させるためのクリーニングを扱っています。

避けるべき落とし穴

重大なことについて、スレッドより要約を信頼する。 返金、法的措置のほのめかし、安全性の問題、セキュリティインシデントは、元のメッセージを読んでください。要約は全体の把握のためのものです。

自動保存を早く有効にしすぎる。 保存される前に誰も要約を読まなければ、誤りが記録の一部になり、次の担当者はそれを信頼してしまいます。

ツールに見えないものを無視する。 公開コメントだけから作られた要約は、内部の調査を反映しません。ツールの入力を把握してください。

要約を長くしてしまう。 1ページに及ぶ要約は、余計な手間のついたトランスクリプトです。語数の予算を守り、最初の行に依頼内容とステータスを載せてください。

言語のチェックを省く。 チームが複数の言語を扱うなら、それぞれの言語で要約をテストし、要約を顧客の言語で書くか、チームの言語で書くかを決めてください。AIによる多言語カスタマーサポートをご覧ください。

節約した時間だけを測る。 1通話あたりの節約分数は、数えやすく、過大評価しやすい指標です。品質の指標と組み合わせなければ、速くて間違った方向に最適化してしまいます。

人を忘れる。 自分でメモを書いていた担当者は、要約が自分の判断力を軽んじていると感じたり、監視のためのツールではないかと心配したりするかもしれません。何のためのものかを説明し、AIがサポートチームの役割をどう変えるかをご覧ください。担当者がまだ入力している最中にAIが手伝う、このアイデアのリアルタイム版については、AIエージェントアシストをご覧ください。