製品リコール時のカスタマーサポートにAIを活用する:実践プレイブック
Riellvriany Indriawan
Katelin Teen
最終更新 September 22, 2026

なぜリコールは通常のサポートを壊すのか
私はeeselでサポート側の仕事をしており、何年にもわたり、何千件もの実際のチケットが流れるライブのサポートキューにAIエージェントを導入してきました。リコールで見るパターンはいつも同じです。量は凄まじいのに、その形は意外なほど単純です。
リコールが発生すると、3つのことが同時に起こります。チケット数が数時間のうちに、しばしば平常時の数倍に急増します。質問は、延々と繰り返される少数のものに集約されます。そして、その洪水の中に、絶対に間違えられない少数のチケットが埋もれているため、リスクが高まります。負傷を報告する人、コメントを探る記者、弁護士などです。

この組み合わせこそ、人間だけのキューを壊すものです。担当者は、繰り返しをこなすか、繊細なケースに丁寧に向き合うかのどちらかはできても、1日に2,000件のチケットが届けば両方はできません。その結果、プレッシャーの下でトリアージが雑になり、応答時間が膨れ上がり、繊細なチケットが「返金はまだ?」という問い合わせと同じ慌ただしい扱いを受けます。リコールはカスタマーサービスソフトウェアにとっての負荷テストであり、多くのチームがこれに失敗するのは、人材が悪いからではなく、単に時間が足りないからです。
これは、AIの最大の弱点が問題にならなくなる唯一の状況です。AIはまれで、ニュアンスがあり、判断を要するケースが苦手で、リコールにはそれが多くあります。しかしリコールは80%が同じ5つの質問でもあり、AIは同じ5つの質問が2,000回繰り返されることを非常に得意とします。だから、まさにその線に沿って仕事を分けるのです。
AIが扱うべきものと扱うべきでないもの
リコール対応で最も重要な判断は、AIが単独で答えるものと人間に渡すものの境界をどこに引くかです。何でも自動化する方向に間違えると、AIは不安を抱える人に自信満々で誤った安全情報を伝えてしまいます。逆方向に間違えると、何も自動化できていません。
私ならこの分け方から始めます。

左の列は、単調で事実ベースであり、よく訓練されたエージェントに任せて安全なものです。ロット番号やシリアル番号による対象確認、返金や交換の手順、注文の照会、返品ラベルの依頼などです。教科書どおりのティア1の自己解決化ですが、量が10倍になるだけです。
右の列は、人間が腕を発揮するところです。健康や安全に関わるもの、法務や報道に関わるもの、複雑または争いのある補償、そして何より、AI自身が確信を持てないものすべてです。最後のものが安全網であり、チームが飛ばしがちな部分です。
経験豊富なサポートリーダーから、この考え方をいつも耳にします。ある直販のサプリメントブランドのCXリーダーは、哲学全体を一言でこう表現しました。
AIがすべての質問の100%に答えられるようになることはありません。私が必要なのは、自信を持って扱えるチケットだけを扱い、それ以外は手を出さないAIです。
この心構えです。信頼度のしきい値とトピックの除外ルール(「負傷」や「法務」のタグが付いたものには決して自動返信しない)が、AIが助けたリコールとAIが悪化させたリコールを分けます。リコール中の引き継ぎの失敗のコストは不機嫌な顧客ではなく安全上の見落としなので、優れた引き継ぎの実践は通常の日よりここで重要です。
リコールが起きる前の準備
AIサポートを設定する最悪のタイミングは、リコールの最中です。朗報として、最新のAIヘルプデスクエージェントは、Zendesk、Freshdesk、Gorgias、Help Scoutなど、すでに使っているヘルプデスクの上で数分で稼働します。私ならこの順序で進めます。
-
まずリコールの回答を書く。 AI関連の作業より先に、明確な社内回答を1つ公開します。どの製品とロットが対象か、顧客は何をすべきか、返金や交換の正確な手順です。これがAIが参照する唯一の情報源なので、曖昧ならすべてのAI返信が曖昧になります。エージェントがすでに読み込んでいるナレッジベースに入れてください。
-
AIをナレッジとヘルプデスクに接続する。 ヘルプセンター、過去のチケット、リコール文書を参照させます。過去のチケットで学習させることで、汎用的なボットのような話し方ではなく、チームがすでに使っているトーンや具体性に合わせられます。
-
信頼度のしきい値と除外ルールを設定する。 AIが沈黙するスコアと、決して触れてはならないトピックを決めます。前のセクションの引き継ぎラインを具体化するものです。
-
自社の過去のチケットでシミュレーションする。 信頼を得るのがこのステップです。実際の過去のチケットの束にAIを走らせ、ライブの顧客に触れる前に、AIがどう返信したかを読みます。eeselにシミュレーションを組み込んだのは、自信ありげなボットが静かに誤答するのを見てきたからで、リコールはそれを本番で知りたくない最たる場面です。
-
小さく始めて、広げる。 まずリコールのチケットの一部をAIに回し、結果を見て、実績が出るにつれて拡大します。スイッチを入れて祈る必要はありません。
事前に行う理由は、リコールは予測できなくても、設定は予測できるからです。静かな週にAIエージェントを接続しシミュレーションしておいたチームは、午後1つでリコール対応を有効にできます。急増の最中にゼロから始めるチームは、すでに溺れています。
リコールのタイムラインを段階ごとに
リコールは単一の出来事ではなく曲線であり、その進行に合わせてサポートの役割も変わります。

ゼロ日目、発表。 リコールが公表された瞬間に、リコールの回答が公開され、AIがそれを参照している必要があります。ここでの速さが出来事全体を左右します。最初の顧客の波が、素早く、正確で、落ち着いた返信を受け取れば、パニックは増幅しません。
1〜7日目、急増。 AIが最も力を発揮する時期で、対象確認や返金の質問の洪水を吸収し、人間が繊細なケースに寄り添えるようにします。引き継ぎ率を注意深く見てください。エスカレーションが多すぎる場合、ナレッジ文書に穴があり、AIがそれを正直に示しているということです。
2〜6週目、解決。 量は減りますが、返金の追跡、交換の催促、返品の確認といった物流関連に移ります。AIはこうした状況確認の質問に向いており、判断よりも注文や配送の照会に依存します。
継続、フォローアップ。 ピークのずっと後も、リコール関連のチケットは時折届き続け、新たな安全報告も含まれます。危機が終わったように思えても、それらが人間に回るよう、除外ルールを有効にしておきましょう。
急増を測定して人員を配置する
見えないリコールは管理できません。ここでAIネイティブのツールを頼るのは、自己解決化だけが理由ではなく、可視性のためです。どれだけの量が来ているか、何が自動処理されているか、AIがどれくらいの頻度で引き継いでいるかをリアルタイムで把握できます。

リコール中に最も重要な数字は2つです。1つ目は時間経過に伴うタスク量で、曲線の前半にいるのか後半にいるのかが分かります。2つ目は人間による承認とエスカレーションの利用状況で、チームが実際にどれだけ求められているか、AIがどこに信頼度の線を引いているかが分かります。特定のトピックでエスカレーションが急増したら、AIを責めるのではなく、ナレッジ文書を磨くべきというサインです。これを通常のサポート指標と合わせれば、推測ではなく実際の負荷に合わせて人間側の人員を配置できます。
コスト面の観点もあります。リコールは一時的なスパイクなので、2か月後に削減することになる席を増やすより、規模を変えられるプランのほうがはるかに合います。eeselの料金では、AIが対応したチケット1件につき1クレジットで、席数ごとやプラットフォームの料金はありません。月2,500件なら2,500クレジットのプラン($999)に収まり、いつでも上げ下げできます。臨時スタッフの採用の慌ただしさとはまったく違う計算です。
避けるべきよくある間違い
チームが陥るのを見てきた罠をいくつか挙げます。いずれも避けられます。
- 時間を節約するために繊細なチケットを自動化する。 すべてを自己解決させたいというプレッシャーは、最も危険なときに最も高まります。負傷、法務、報道のケースは常に人間に任せてください。
- シミュレーションを省く。 過去のチケットでテストせずに本番に出ると、自信満々の誤回答が不安な顧客に届きます。10分のシミュレーションは安い保険です。
- 曖昧なリコール文書。 AIは読み込む情報源の質以上にはなれません。曖昧な社内回答は、大規模に曖昧な返信を生みます。
- ピークが過ぎたらAIを止める。 リコールのチケットは何か月も少しずつ届き、新たな安全報告も含まれます。除外ルールをそのままに、エージェントを稼働させ続けてください。
- リコールを通常のSLAの週として扱う。 サービスレベル目標や人員の前提は、急増の間は成り立ちません。平均ではなく曲線に合わせて計画しましょう。
リコール対応にeeselを試す
リコールに直面している、あるいは備えておきたいなら、eeselは、すでに使っているヘルプデスクに接続して数分で使えるAIヘルプデスクのチームメイトです。過去のチケットとヘルプセンターで学習し、繰り返しのリコール質問に自力で答え、確信のないものや、繊細として指定したものを直接担当者に引き継ぎます。
リコールで最も重要なのは、ライブの顧客に返信する前に、自社の過去のチケットでシミュレーションできることです。そのため、どう動くかを把握した上で臨めます。さらに、プランはクレジット単位(1チケットにつき1クレジット)で席ごとの料金がないため、急増に合わせて拡大し、その後縮小でき、後悔する採用サイクルも不要です。あるeeselの顧客は、繰り返しの業務で最大80%の時間削減を報告しており、これはまさにリコールが押し寄せる負荷そのものです。
100の無料クレジットで、クレジットカード不要で無料で始め、ヘルプデスクに接続して、必要になるずっと前の今週中にシミュレーションを実行できます。
よくある質問
製品リコール時のカスタマーサポートにおけるAIとは何ですか?
リコールで生じるチケットの急増をAIヘルプデスクエージェントに吸収させることです。繰り返しの質問(自分の製品は対象か、返金はどうすればよいか、交換品はどこか)には自動で回答し、負傷の報告のようなリスクの高いものは人間に引き継ぎます。既存のヘルプデスクを置き換えるのではなく、その中で動作します。
AIは新規採用なしでリコールのチケット急増に対応できますか?
ほとんどの場合は可能です。リコール対応の大半は少数の繰り返しの質問であり、まさにティア1の自己解決化が得意とするものです。安全に関わるケースや感情的なケースには引き続き人間が必要ですが、AIが単調で大量の負荷をキューから取り除くため、チームが溺れずに済みます。
リコール対応のAIサポートにはいくらかかりますか?
eeselのクレジットプランでは、1クレジットで1件のチケット対応をカバーし、席数ごとやプラットフォームの料金はありません。そのため、月2,500件のリコール対応は2,500クレジットのプラン($999)に収まります。いつでもプランを上げ下げできるので、現れては消えるスパイクに向いています。
リコール中にAIが自動回答してはいけないものは何ですか?
報告された負傷や被害、法務やメディアからの問い合わせ、複雑な補償、そしてモデルが確信を持てないものすべてです。信頼度のしきい値と除外ルールを設定し、これらが直接担当者に届くようにしましょう。優れた引き継ぎの実践は、リコール時にこそ他のどの時期よりも重要です。
本番稼働前にリコールのチケットでAIをテストするには?
まず自社の過去のチケットでシミュレーションを実行し、実際の顧客に触れる前にAIがどう返信したかを確認します。これにより、通常の日よりもリコール時にはるかに大きな害をもたらす自信満々の誤回答を避けられます。