解約を予測するサポートシグナル：AIでリスクの高い顧客を見つける

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

サポートのチャーンのシグナルとは、顧客のチケット、チャット、通話に現れるパターン（繰り返しの問い合わせ、悪化するトーン、解決しないバグ、エスカレーション、増え続ける手間）のうち、顧客が解約または更新を見送る前に現れやすいものを指します。 AIは、こうして散らばったパターンを1つのアカウント単位のフラグにまとめ、そのフラグを、顧客との関係を担当するカスタマーサクセスマネージャー（CSM）に渡します。

サポートには、社内のほかの部門には見えないものが見えています。ログインしなくなった顧客は静かです。1か月に4回連絡してきて、そのたびに文面が少し短く、少し鋭くなっていく顧客は、声を上げています。問題は、それらのメッセージを足し合わせることを仕事にしている人がいないことです。サポートはチケットを閉じ、カスタマーサクセスは利用状況のダッシュボードを見て、警告はCS側の誰も開かないヘルプデスクに眠ったまま、アカウントは去っていきます。

本記事では、追跡する価値のあるサポートシグナル、AIがそれらを組み合わせる方法、行動できる人にフラグを渡す方法、そしてモデルが機能しているかを確かめる方法を解説します。顧客が不満を言う前に動くという、より広い視点から知りたい方は、まずAIによるプロアクティブなカスタマーサービスをお読みください。

重要なポイント

• IBMの研究者は、250万件を超えるサポートチケットと約10,000件のエスカレーションでチケットのエスカレーション予測モデルを学習させ、再現率87.36%、アナリストの作業負荷88.23%削減を報告しています（Montgomery et al., arXiv）。予測の対象はエスカレーションであって解約ではありませんが、チケット履歴がリスクモデルの強力な原材料になることを示しています。
• このIBMの研究で使われた特徴量には、重大度の上昇、前回の連絡からの日数、顧客が現在受けている応答時間と過去に受けてきた応答時間との比較が含まれています（Montgomery et al., 論文全文）。顧客を、その顧客自身のベースラインと比べることが核心的な考え方です。
• GainsightのZendesk連携では、管理者がチケットデータをGainsightに取り込み、「サポートデータに基づいてヘルススコアをトリガー」できます（Gainsight Marketplace）。これはベンダーが説明している機能であり、測定された成果ではありません。
• 同じ掲載ページには、ヘルプデスクの中からCalls to Action（CTA）を作成してZendeskのチケットに紐付けられるとも記されています。これが、後述する引き渡しの仕組みです。
• 適合率とは、フラグを立てたアカウントのうち実際にリスクがあったものの割合で、再現率とは、リスクのあるアカウントのうちモデルが捉えられたものの割合です（scikit-learnドキュメント）。解約フラグを判断するには、両方の数字が必要です。
• 通常のシャッフルした交差検証は、時系列のデータでは高すぎるスコアを出します。そのため、解約モデルは学習した期間より後の期間でテストする必要があります（scikit-learnドキュメント）。

サポートデータが解約を予測できる理由

製品の利用状況は、顧客が何をしているかを教えてくれます。サポートは、何かがうまくいかなかった瞬間に、顧客自身の言葉で、顧客がそれをどう感じているかを教えてくれます。そのため、非常に直接的なシグナルであり、利用履歴が何か月も溜まる前の初日から手に入ります。

サポートデータが利用スコアと異なる点は3つあります。

• テキストである。 情報の大半は、フィールドではなく、顧客が書いた文章の中にあります。それを大規模に読むことは、まさに言語モデルが得意とする仕事です。
• イベント駆動である。 月次で更新されるヘルススコアでは、3つのものが壊れた週を見逃します。チケットは起きたそのときに届きます。
• アカウント全体の体験が見える。 怒っているユーザーが1人なら、それはインシデントです。同じ会社の5人のユーザーが2週間のうちに問題を訴えていれば、それはパターンです。

だからといって、チケットが判決であるわけではありません。多くのチケットを起票する顧客の中には、活発に使い、喜んで更新するヘビーユーザーがたくさんいます。目的は、問い合わせそのものを悪いものとして扱うことではありません。アカウントのパターンの変化を見つけることです。以下のアプローチが、各顧客をその顧客自身の履歴と比べ続けるのはそのためです。

5つのシグナルファミリー

サポートから得られる有用な解約シグナルの大半は、5つのファミリーに分類できます。サポートデータをAI向けに整えてあれば、どれも安価に計算できます。

繰り返しの問い合わせ

繰り返しの問い合わせは、最も強力でシンプルなシグナルです。サポートのプロセスがすでに一度失敗したことを意味するからです。定義は慎重に行ってください。同じ顧客、同じ根本的な問題、選んだ期間内（7日間が一般的な出発点です）という条件です。そのためにはチケットをトピックごとにグループ化する必要があり、顧客は1つの問題をさまざまな言葉で説明するため、顧客のインテント検出がそのためのツールになります。

ネガティブな感情

感情が役立つのは、推移として見るときだけです。いつも率直な顧客を、率直だという理由でフラグ付けしてはいけません。1月は温かかったのに3月は素っ気なくなった顧客なら、フラグを立てるべきです。すでにAIによるCSATの予測を運用しているなら、会話ごとのスコアがそのまま入力として使えます。リスクの分析では、メッセージごとにスコアを保存し、アカウントごとに移動する期間での変化を追跡します。

未解決のバグ

多くのチームが見落とすのがこれです。チケットがサポートのキューでは「オープン」ではなく、エンジニアリングに引き渡されて保留として表示されるからです。顧客から見れば、何も変わっていません。チケットをバグのレコードに紐付け、影響を受けたアカウントがそれぞれどれだけ待っているかを測定してください。同じ紐付けによって、どの不具合が最もコストを生んでいるかをプロダクトチームが把握できます。これについてはサポートチケットをプロダクトバックログ項目に変えるで解説しています。

エスカレーション

エスカレーションは、事態がどれほど深刻かを顧客が教えてくれている行為です。ここではIBMのエスカレーション研究が参考になります。その特徴量には、重大度の上昇や、顧客ごとの応答時間の比較が含まれています（Montgomery et al.）。モデルをそのまま真似しなくても、考え方を借りることはできます。重大度の変化、マネージャーを求める依頼、スレッドに新たに加わった上位の担当者を追跡してください。

手間

手間は最も見えにくく、しかしたいてい最も多くを物語ります。解決までに要したメッセージ数、関わった担当者の数、チャネルの切り替え回数（チャットからメール、電話へ）、顧客のメッセージから最初の役に立つ返信までの間隔を数えてください。9通のメッセージと3人の担当者を要して解決したチケットは、2通で済んだチケットとはまったく別の体験です。

AIがシグナルを組み合わせる方法

単一のシグナルはノイズが多いものです。価値が生まれるのは、それらを組み合わせたときと、各アカウントをそのアカウント自身の通常の状態と比べたときです。

パイプラインは4つのステップで、ACE Frameworkのingest、analyze、predict、executeの各機能に対応しています。

1. Ingest。 チケット、チャットの記録、通話の記録、バグの紐付け、CSATの回答を、個々のユーザーではなく顧客アカウントをキーとして、1つのアカウント単位のビューに集めます。
2. Analyze。 言語モデルが、会話ごとにトピック、感情、問題が解決したかどうか、顧客が解約、競合、契約条件に触れているかどうかをラベル付けします。各アカウントの直近30日間のチケット要約があれば、出力が人にとって読みやすいままになります。
3. Predict。 スコアリングモデルが、ラベルと構造化された情報（プラン、契約期間、更新日、利用トレンド）を受け取り、アカウントごとのリスクスコアを出します。単純なロジスティック回帰でも、勾配ブースティングモデルでも構いません。解約の事例が数百件程度であれば、より複雑なモデルが、うまく作られたシンプルなモデルを上回ることはめったにありません。
4. Execute。 しきい値を超えたアカウントについては、担当者向けのタスクが作成されます。これが次のセクションで扱う引き渡しです。

これが機能するかどうかは、2つの設計上の選択で決まります。

アカウント自身のベースラインと比較する。 IBMのチームの応答時間の特徴量はこの方法で作られています。顧客が現在受けているものを、過去に受けてきたものと比べるのです（Montgomery et al.）。同じ考え方を件数、感情、手間にも適用してください。「チケット数が12件」より、「チケット数がこのアカウントの中央値の3倍」のほうがはるかに優れた特徴量です。

理由とスコアを分ける。 「リスク0.82」のような数字だけでは、無視されます。モデルには、寄与の大きい上位2〜3個のシグナルを平易な言葉で返させてください。CSMが読むのは、その理由です。

サポートデータ以外のモデリングについては、解約予測モデルでアルゴリズムと学習データをより深く扱っています。サポートシグナルは、利用状況や商談のデータの代わりではなく、より広いヘルススコアへの入力の1つとして使うのが最適です。

具体例（仮の例）

この例は説明用です。数字はロジックを示すために作った架空のものです。

ミッドマーケットのソフトウェアのアカウントは、普段は月に1件のチケットを起票します。直近3週間では5件を起票しました。そのうち2件は同じエクスポートの失敗に関するもので、1件は再オープンされ、紐付いたバグは19日間オープンのままです。メッセージのトーンは、直近3件のチケットで中立から素っ気ないものに下がりました。最新のものには「ほかの選択肢を検討している」とあります。

どの項目も、単独では警戒すべきものではありません。しかし、普段は静かなアカウントと照らし合わせると、全体として警戒すべき状態です。モデルはこのアカウントにフラグを立て、次のように書きます。「サポートの件数が通常の5倍。同じエクスポートの問題が2回提起され、バグは19日間オープン。感情は悪化傾向。顧客が代替手段の検討に言及」。CSMは、これを見れば1分で行動に移れます。

CSMへのフラグの引き渡し

多くのプログラムが失敗するのはここです。誰も動かないフラグは、ただのダッシュボードです。引き渡しは、モデルと同じくらい慎重に設計する必要があります。

CSMがすでに作業している場所にフラグを置く。 CSMがCRMやカスタマーサクセスのプラットフォームで仕事をしているなら、わざわざ開く必要のあるレポートではなく、そこにタスクを作成します。これを実現する連携は存在します。たとえばGainsightのZendeskの掲載ページには、ヘルプデスクの中からCTAをZendeskのチケットに紐付けられると記されています（Gainsight Marketplace）。

アラートではなく、一式の情報を送る。 各フラグは、CSMがほかに何も開かなくても、次の5つの問いに答えられるようにします。

オーナーと対応時間を決める。 各フラグを誰が担当し、どれだけ早く対応するかを決めてください。そうしなければ、サポートはCSが対応していると思い込み、CSはサポートが対応していると思い込みます。

ループを閉じる。 CSMが行動したら、結果（回復した、誤報だった、すでに解約に向かっていた、顧客が持ち直した）を記録します。このフィードバックが、次のバージョンのモデルの学習データになります。フラグにどれだけの価値があるかを知る方法も、これしかありません。

フラグを溢れさせない。 CSMが週に40件のフラグを受け取れば、3週目には読まなくなります。チームが実際に対応できる数のフラグになるようにしきい値を設定し、毎月見直してください。無視されるフラグで90%を捉えるより、信頼されるフラグでリスクのあるアカウントの60%を捉えるほうが優れています。

すべてのフラグがCSMのものとは限りません。繰り返し発生する不具合が原因のフラグは、プロダクトの問題です。証拠を付けてプロダクト側に回し、どの原因が繰り返し現れるかを追跡してください。

モデルの検証方法

デモでは妥当に見える解約フラグも、実際には間違っていることがあります。検証は、1つの問いに答えます。モデルがフラグを立てたアカウントは、立てなかったアカウントよりも本当に多く解約しているか、という問いです。

ステップ1：解約と予測期間を定義する

何を解約と数えるかを決めます。キャンセル、更新の見送り、大幅なダウングレードなどです。次に期間を決めます。たとえば「このアカウントは、フラグから90日以内に解約するか」といった具合です。期間が定まっていないモデルは、テストできません。

ステップ2：過去からデータセットを作る

過去の各時点の全アカウントについて、その時点でのサポートシグナルと、その後の期間内に解約したかどうかを記録します。ここは厳格に行ってください。特徴量にフラグの日付より後の情報が含まれていれば、モデルはカンニングをしています。典型的なリークは、顧客が解約した時点で設定されるフィールドです。たとえば、最後のチケットに付く「解約理由」のタグがそうです。

ステップ3：ランダムではなく、時間で分割する

早い期間で学習し、後の期間でテストします。標準的なシャッフルした交差検証は、サンプルが独立していることを前提としており、時系列のデータでは、テストのサンプルが学習のサンプルと時間的に近いために、高すぎるスコアが出ます（scikit-learnドキュメント）。時間による分割は、実際の使われ方を再現します。モデルは過去から学び、まだ見ていない未来で評価されるのです。

ステップ4：正しい指標を測る

適合率は、フラグを立てたアカウントのうち本当に陽性だったものの割合で、再現率は、すべての陽性のうちモデルが見つけたものの割合です（scikit-learnドキュメント）。両者は互いに引っ張り合います。しきい値を上げると、フラグは少なく、より信頼できるものになりますが、解約者をより多く見逃します。CSMが対応できるフラグの数に基づいて、バランスを選んでください。

ステップ5：シンプルなベースラインと比較する

地味なものと比べてみてください。「30日間に3件以上のチケットがあるアカウントにフラグを立てる」や、既存のヘルススコアなどです。AIモデルがシンプルなルールをわずかに上回る程度なら、ルールを使ってください。既存のヘルススコアにサポートシグナルを加えたモデルでリフトが改善するなら、それがモデルを残すべき証拠になります。

ステップ6：現場でテストし、検証を続ける

更新サイクルを1回、シャドーモードで運用します。CSMの働き方は変えずにアカウントにフラグを立て、フラグ付きのアカウントとそれ以外を比較します。公開後はドリフトに注意してください。新しい製品リリース、価格の変更、新しいサポートチームは、いずれも「通常」の姿を変える可能性があります。適合率と再現率を四半期ごとに再確認し、CSMの結果メモを使って誤報を見つけてください。

因果関係の主張には注意が必要です。フラグが示すのは、誰が離れそうか、ということです。自分たちの介入が顧客を引き留めたことを示すわけではありません。アウトリーチの効果を測るには、事業として許容できるなら、フラグを立てたアカウントの一部を無作為にしばらく対象外として残し、結果を比較してください。

導入チェックリスト

1. 解約の定義と期間を1つずつ選ぶ。 最初から3つ使わないでください。
2. サポートをアカウントのレコードに接続する。 チケットは、ユーザー単位ではなく、アカウントに集約されなければなりません。
3. 5つのシグナルファミリーから始める。 さらに追加するのは、それだけの価値を示したときだけにします。
4. 各アカウント自身のベースラインに対してシグナルを計算する。
5. 先にベースラインのルールを作り、それからモデルを試します。
6. すべてのスコアに理由を添えて返す。
7. CSMのツールにタスクを作成する。 オーナーと対応時間を付けます。
8. すべてのフラグで結果を記録する。
9. 時間による分割で検証し、適合率、再現率、リフト、リードタイムを報告します。
10. 四半期ごとに見直し、役に立たなくなったシグナルは外します。

よくある落とし穴

あらゆる問い合わせを悪いものとして扱う。 ヘビーユーザーはより多くのチケットを起票します。生の件数ではなく、アカウントのベースラインからの変化を見てください。

アカウントではなく、ユーザーをスコア化する。 解約は通常、アカウント単位の決定です。1人の不調な週が、アカウントのリスクではありません。

答えを漏らしてしまう。 解約の判断より後に作られた特徴量は、テストではモデルを素晴らしく見せ、本番では役に立たなくします。

アラート疲れ。 フラグが多すぎると、チームは読まなくなります。キャパシティに合わせてしきい値を調整してください。

打ち手のないフラグ。 フラグが出たときに何をすべきかを誰も知らなければ、モデルに価値はありません。先にプレイブックを書いてください。

エンジニアリングが持つバグを無視する。 エンジニアリング待ちのチケットは、顧客が最も長く待たされる場所です。必ず含めてください。

顧客を罰する。 リスクのフラグは助けるためのものであり、サービスを出し渋るためのものではありません。フラグ付きの顧客を遅いキューに回したり、スコアを理由に妥当な依頼を断ったりしないでください。

プライバシーを忘れる。 チケットのテキストには個人データが含まれます。記録をモデルに送る前に、データ処理の条件で何が許されているかを確認し、CSMに見せるフラグの内容を限定してください。