過去のチケットからAIでサポートマクロを生成する方法

「過去のチケットからマクロを生成する」とは実際どういうことか

マクロとは、定型の返信文とチケットアクション(ステータス設定、タグ追加、担当者変更など)をひとまとめにした保存済みの塊で、エージェントがワンクリックで適用するものです。Zendeskのドキュメントにもある通り、マクロは自動で発火するトリガーやオートメーションとは異なり、あくまでエージェントが選んで適用する設計になっています。

難しいのはマクロを適用することではなく、マクロを書くことです。多くのチームには2年前に誰かが慌てて作った少数のマクロがある一方で、エージェントの午後の時間を本当に食っている繰り返しの質問は、誰もチケット履歴を丹念に洗い出す時間がなかったために、いまだにテンプレート化されていません。

AIが埋めるのはまさにそのギャップです。AIがチケット履歴に対してできることには明確に異なる2つがあり、この2つを混同しているケースが後を絶ちません。

1つ目の既存マクロの適用は、多くのヘルプデスク純正AIが行っているものです。オープン中のチケットを読み、過去のチケットと照合し、保存済みのマクロのどれが合うかを提案します。便利ではありますが、あくまですでに書かれているマクロしか推奨できません。

2つ目の新規マクロの作成こそ、このガイドが本当に扱いたいテーマです。AIが解決済みチケットを読み込み、エージェントが手作業で何度も打ち込んでいる繰り返しの返信を見つけ出し、まだ埋まっていない部分に対して新しいマクロテンプレートを提案します。ここにこそ時間節約の本体があり、これはチームから最もよく依頼される部分でもあります。私たち自身のセールスコールを見ても、会社独自の過去チケットでAIを学習させることは、断トツで最も要望の多い機能です。

始める前に必要なもの

これはハウツー記事なので、前提条件を具体的にしておきましょう。

• 解決済みチケット履歴へのアクセス。 多くのヘルプデスクではチケットをCSVにエクスポートしたり、APIで取得したりできます。必要なのは解決済みのチケット、つまりエージェントが実際に回答したものであり、スパムや自動クローズされたノイズではありません。
• 自社の件数感覚。 よくあるトピックごとに数百件の解決済みチケットがあれば健全な最低ラインです。それを下回ると、AIは少なすぎるシグナルから推測することになります(Zendesk自身のモデルは100件未満だと有効化すらされません。詳しくは後述します)。
• 下書きをレビューする場所。 スプレッドシートでもドキュメントでも、AIツールのレビュー画面でも構いませんが、エージェントが各下書きを読み、実際のマクロになる前に編集できる場所が必要です。
• AIレイヤー。 ヘルプデスクのネイティブAIアドオン、チケットを貼り付けて使う汎用LLM、あるいはヘルプデスクに接続して一連の流れ全体をこなしてくれるeesel AIのような専用ツール、いずれかです。

各ステップを見ていく前に、エンドツーエンドのパイプライン全体を示しておきます。

ステップ1:過去のチケットを取得してクリーンアップする

まずは解決済みチケットの代表的なサンプルをエクスポートすることから始めます。この一文の「代表的」という言葉には重い意味があり、実はここがマクロの出来を静かに左右するステップです。

押さえておくべきポイントがいくつかあります。

• 直近1週間ではなく、時間軸を通してサンプリングする。 1か月分のチケットだけだと、その月に起きた出来事に偏ります。季節的なスパイクが支配的にならないよう、もっと長い期間から抽出しましょう。あるGorgias利用の生花配達ブランドは、この点をかなり意識していました。バレンタインデーと母の日のスパイク週は除外したうえで、10か月にわたって月300件のランダムなチケットを取得したいと望んでいたのです。なぜなら、あの週は普段の日とはまるで違い、すべてのマクロが「私のブーケはどこ?」に偏ってしまうからです。
• 本物の、エージェントが対応したチケットだけを使う。 自動返信、スパム、エージェントの回答なしにクローズされたチケットは除外しましょう。ここで学びたいのはあなたのチームがどう応答しているかであって、既存のオートメーションがすでにカバーしていることではありません。
• 質問だけでなく、解決内容も残す。 ここで役に立つチケットは、エージェントの実際の返信が含まれているものだけです。その返信こそがマクロ文の原材料になります。

自社のチケットデータをこの視点で見たことがないなら、サポートチケット分析を単独で行う価値があります。1行もマクロを書く前に、どのトピックがテンプレート化に値するかを教えてくれます。

ステップ2:AIに繰り返しの質問をクラスタリングさせる

次に、その山のようなチケットをAIに渡し、意図ごとにグループ化させます。狙うのは「注文はどこにありますか」「パスワードのリセット方法」「返金のリクエスト」「配送先住所の変更」といった、細部だけが違って何百回も出てくる質問のクラスターです。

これは手作業だと本当に骨が折れる一方、モデルにとっては本当に速いステップです。良いAIパスなら、たとえば「チケットの47%が9つの繰り返しトピックに分類され、件数の多い順に9つ、それぞれサンプルチケット付きで示す」といった結果を返してくれます。この順位付けこそ、あなたのためにすでに書き上げられたマクロのToDoリストです。

同じクラスタリングのロジックは、AIチケット分類やトリアージの裏側でも使われているため、すでに自動タグ付けやルーティングを導入しているなら、この作業の半分はすでに終わっているかもしれません。タグそのものがクラスター作りの下地になります。

ステップ3:各クラスターをマクロの下書きに変える

各クラスターについて、AIにマクロの下書きを作らせましょう。あなたのチームのトーンで書かれた再利用可能な返信文で、実際にエージェントが送った返信を一般化し、細部を入れるプレースホルダーを含めます。

ここで、あなた自身のチケットで学習させることが汎用テンプレート集を上回る理由が見えてきます。ありきたりな「返金リクエスト」マクロなら誰でも渡せます。しかし、あなたのチームが必ず「ご不便をおかけして申し訳ございません」から書き始め、必ず返品ポリシーへのリンクを貼り、必ず同じ流れで注文番号を尋ねている、ということを知っているのは自社のチケット履歴だけです。自社の履歴から下書きされたマクロはあなたのチームらしく響き、既製品はどうしても定型文のように聞こえます。

ここには読者層という見落としやすい落とし穴があります。ナレッジベースは管理者向けに書かれているのに、チケットはエンドユーザーから来ている、というチームを何度も見てきました。たとえばある交通系テック企業では、ドキュメントはバス車両の管理者向けだったのに、実際のチケットは利用者からのものでした。過去の返信が正しい読者に向けて書かれていれば、AIマクロもその特性を引き継ぎます。そうでなければ、まず元の返信を直しておかないと、マクロは読み手にとって自信満々に間違ったものになってしまいます。

良いマクロは、組織の知識が失われる前に閉じ込める役割も果たします。あるフランスの公共セクターIT企業がまさにこの理由で私たちのもとを訪れました。深いERPトラブルシューティングの知識を持つ2名のベテランエージェントがその年に退職を控えており、その専門知識が失われる前に「AIに閉じ込めておきたい」と考えていたのです。そうしたエージェントの過去チケットからマクロを生成することは、その知識を瓶詰めするもっともクリーンな方法のひとつです。

ステップ4:レビューし、編集し、アクションを追加する

AIが下書きしたマクロをそのまま顧客に送ってはいけません。すべての下書きはあくまで「たたき台」です。

レビューでは、エージェントは次のことを行うべきです。

• 事実を確認する。 AIがポリシーの詳細や返金期限をでっち上げていないか。あれば修正します。
• トーンを調整する。 ブランドの雰囲気から少しでも外れている箇所を整えます。
• チケットアクションを追加する。 返信文だけではマクロの半分にすぎません。もう半分は、チケットに何が起きるか、つまりステータスを解決済みにする、refund-processedタグを追加する、請求グループに再割り当てする、優先度を設定する、といった処理です。AIは履歴のパターンからこれらを提案できますが、最終確認は人が行います。
• プレースホルダーに注意する。 Zendeskを使っている場合、問題チケットやインシデントチケットではプレースホルダーを正しくエスケープしましょう(例:Hello \{{ticket.requester.first_name}})。そうしないとリクエスターの名前がリンクされた別チケットに漏れることがあります。

このレビューステップこそ、ループの中に人を残しておく理由そのものです。AIは白紙のページという問題を取り除き、エージェントは判断力を保持します。返金、交換、配送に関する返信については、AIマクロテンプレートの専用ガイドをぜひ参考にしてください。

ステップ5:公開前に実際の履歴でテストする

ここが、ほとんどの人が省いてしまうステップであり、役に立つマクロライブラリと、静かに手戻りを生み続けるマクロライブラリとを分けるポイントです。

新しいマクロを公開する(あるいはAIエージェントに適用を始めさせる)前に、それを過去のチケットのバッチに対して実行し、実際に何が起きたかを確認しましょう。「注文はどこですか」マクロは正しいチケットに反応したか。誤ったチケットに反応してしまったことはないか。実際のカバレッジはどのくらいで、確信度が怪しい部分はどこか。

これはまさにeesel AIのシミュレーションモードが想定している用途です。あなたの設定を実際の過去チケット数千件に対して実行し、たった一人の顧客に見せる前に、予測される解決率とカバレッジを表示します。数値が納得できるものになるまで、調整して再実行してから初めて導入します。

専用ツールがなくても、この原則は成り立ちます。マクロがマッチするはずの最近のチケットを50件抽出し、手動で適用してみて結果を目視で確認しましょう。規模を拡大したときに誤作動するマクロに対する、安価な保険になります。

ステップ6:公開し、鮮度を保ち続ける

マクロがレビューとテストを通過したら、公開しましょう。特定のエージェントのリストに埋もれた個人用マクロではなく、チーム全体が恩恵を受けられる共有マクロとしてです。そのうえで、ライブラリを「完成品」ではなく「生き続けるもの」として扱いましょう。

製品は変わり、ポリシーは変わり、前四半期には存在しなかった新しい繰り返しの質問が生まれます。定期的に(月次あたりが妥当なペースです)マイニングパスを再実行し、新しいクラスターを見つけ、誰も適用していないマクロを引退させましょう。これはAIでチケット件数を減らすときと同じループです。履歴はいつまでも、次に何を自動化すべきかを教え続けてくれます。

Zendesk、Freshdesk、Gorgiasでネイティブに行う場合

もしヘルプデスクの中だけで完結させたいなら、ネイティブAIがどこまでカバーし、どこで力尽きるかを見ておきましょう。

Zendesk

Zendeskにはマクロ関連のAI機能が2つ独立して存在し、先ほどの2つのモードにきれいに対応しています。マクロの提案(エージェント向け)は、既存の共有マクロのどれを適用すべきかを推奨するもので、そのモデルはオープン中のチケットを、マクロが適用された過去9か月間のチケットと比較します。管理者センターの「エージェントツール」でオンにできます。

エージェント画面では、提案マクロが「このチケットへの提案」セクションに表示され、Copilotアドオンを使えばそれぞれに確信度が付きます。

履歴から実際にマクロを作成する機能はマクロコンテンツの提案(管理者向け)です。アカウント内のすべてのエージェント返信を横断して繰り返し出てくる内容を検出し、直近1か月のデータを使って新しいマクロの作成を提案します。注意点として、これはZendesk AIアドオンの一部であり、有効化には少なくとも100件の条件を満たすチケットと3つの共有マクロが必要で、新しいマクロがモデルに反映されるまで2週間かかります。強力ではあるものの、プランに縛られ、立ち上がりも遅めです。

Freshdesk

Freshdeskは、返信の提案や定型文アシストにFreddy AIを活用し、自動トリアージは過去のチケットから分類を学習します。履歴からマクロを生成するという機能はZendeskに比べると薄く、Freddyの強力な機能の多くは上位プランに限られているため、多くのチームは重い処理を専用のAIレイヤーと組み合わせています。

Gorgias

GorgiasはEコマース特化型で、Shopifyの注文データと連動したマクロに強みがありますが、他のツールと同様、「チケット履歴全体から学習して新しいテンプレートを下書きする」というワークフローは、目的特化型のツールのほうが一枚上手になりやすい領域です。

共通するのは、ネイティブの機能はすでに特定のプラットフォームに深く入り込んでいて、適切なプランに加入していれば便利だということです。しかし、そのプラットフォームに縛られ、アドオンやしきい値によって制限を受け、公開前にマクロを履歴でテストする方法がほとんど、あるいはまったくないという点です。

避けるべきよくある間違い

• 単発の質問をテンプレート化する。 ある質問が年に3回しか出てこないなら、マクロは不要です。件数順にランクづけし、上位からテンプレート化しましょう。
• 人によるレビューを省略する。 AIの下書きはあくまでたたき台です。読まずに出荷すると、誤った返金期限が4,000件の返信に紛れ込むことになりかねません。
• アクションを忘れる。 素晴らしい返信文を書くだけでステータスやタグを設定しないマクロは、もう一度クリックする手間を作るだけです。チケットアクションを必ず含めましょう。
• マイニングパスを二度と再実行しない。 一度作って更新しないライブラリは、四半期のうちに陳腐化します。
• 公開前にテストしない。 ツールが過去チケットでシミュレーションできるなら使いましょう。できないなら、50件のチケットで手動のスポットチェックを行いましょう。

過去のチケットからマクロを作るならeeselを試そう

eesel AIは、まさにこのループを中心に作られています。Zendesk、Freshdesk、Gorgiasをはじめ100以上のツールに接続し、過去のチケットとナレッジベースを学習してチームの言葉遣いで返信を下書きします。そして他ではなかなか見つからない特徴として、実際の過去チケット数千件にわたって全体をシミュレーションし、本番投入前に予測精度とカバレッジを確認できます。

シート課金も、解決件数ごとの予期せぬ追加料金もありません(料金ページを参照)。無料で始められるので、何かに本格的にコミットする前に、自社のチケット履歴を実際にマイニングさせて、どんなマクロが下書きされるかを確かめることができます。繰り返しの返信を減らし、チームの実際の働き方を反映したマクロライブラリを目指すなら、これが最短の道です。