契約更新の直前になって利用が減っていたことに気付き、担当者が慌てて状況を確認する。顧客の数が増え、全件を同じ頻度で確認するのが難しい。こうした業務では、支援が必要かもしれない顧客を担当者が確認するためのPoCを検討できます。

解約兆候の予測は、顧客が解約する理由や、連絡すれば継続することまで証明するものではありません。確認の優先順位を作る工程と、実際に支援する内容を決める工程を分け、小さく試します。

解約と判定期間を先に定義する

契約終了、更新しなかったこと、一定期間利用がないことは別の状態です。最初に、どれを対象にするかを決めます。一時休止、プラン変更、法人統合による契約変更などを、通常の解約と同じに数えるかも確認します。

予測する日と、その後どこまでの期間を見るかをそろえます。例えば月初時点の情報から、その後の契約状況を確認する設計です。期間の長さは、担当者が対応できる時期や契約更新の周期に合わせます。一律に何日先を予測すればよいとは限りません。

まだ結果が分からない顧客を継続扱いしない

判定期間の途中で集計すると、その後に解約する顧客まで継続と記録してしまいます。評価には結果を観察できた期間を使い、期間が終わっていない顧客や記録が欠けた顧客は別に管理します。

当時の情報だけで過去を再現する

利用履歴、問い合わせ、契約プラン、担当者の対応履歴を使う場合は、予測時点で利用できた内容に限定します。解約申請後の対応メモや、契約終了後に付けた理由は、解約前の兆候を予測する入力には混ぜません。

scikit-learnの公式資料は、予測時点で使えない情報の混入により、評価結果が楽観的になる問題を説明しています。学習用と評価用を先に分け、欠損補完などの前処理も学習用データから学習することが基本です。

本記事の設計例では、過去の期間で条件を作り、その後の未使用期間で評価します。同じ契約の更新記録を無作為に別々へ分けず、顧客・契約単位の対応関係と期間の境界を管理します。既存顧客の次期を予測するのか、新規顧客へ広げるのかでも評価の分け方は変わります。

用意する情報 確認する内容
顧客・契約の識別子 重複、契約移行、複数契約を区別できるか
予測時点の履歴 当時利用できた情報と更新時刻が分かるか
解約・継続の結果 定義と観察期間がそろっているか
利用条件 プラン、契約期間、利用開始時期を区別できるか
支援の記録 既に連絡した内容や、連絡を控える条件が分かるか

検証に不要な個人情報を集める前提にはせず、利用目的、アクセス範囲、保持する情報を確認します。問い合わせ内容を丸ごと使わず、必要な項目だけで試せるかも検討してください。

単純な抽出条件と同じ対象で比べる

現在の確認方法や「利用が一定期間減った顧客を抽出する」といった単純な条件を比較対象にします。AIの候補だけを詳しく調べると比較が偏るため、同じ顧客群・同じ判定期間で結果をそろえます。

仮例：担当者が確認できる候補数に合わせる

以下は実績ではなく設計の仮例です。担当者が週に確認できる件数を先に決め、現在の抽出方法とAIで選ぶ方法を、同じ件数の候補で比べます。候補の契約状況、既に行った支援、記録の欠けを担当者が確認します。

AIのスコアをそのまま「解約確率」と表示するのではなく、確率として扱えるか検証できていない場合は、確認の優先度を示す値として扱います。高いスコアだけを理由に値引きや自動連絡を行う範囲は、最初のPoCに含めません。

見逃しと不要な確認を分けて評価する

解約する顧客が少ない場合、全員を継続と予測しても正解率が高く見えることがあります。全体の正解率だけで導入を決めないようにします。

scikit-learnの評価指標の説明では、適合率と再現率を区別しています。この用途では、候補のうち実際に対象期間に解約した割合と、実際に解約した顧客のうち候補に入れられた割合として確認できます。どちらも件数と併記し、評価対象が少ない場合は判断を急ぎません。

併せて、プランや契約期間別の結果、見逃した顧客、候補にしたが継続した顧客、情報不足で保留した顧客を見ます。候補数を増やした際に担当者の確認時間がどう変わるかも測ります。許容する見逃しや確認負担は、支援の目的と体制に合わせて事前に決めます。

顧客への対応は担当者が判断する

利用が減った理由は、繁忙期の違い、担当交代、業務の終了などさまざまです。予測から理由を断定せず、担当者が契約履歴や既存のやり取りを確かめます。最近連絡した顧客へ重複して連絡しない手順も必要です。

候補を見つける精度と、支援によって継続が増えたかは別の評価です。支援の効果まで確認する場合は、実施条件や比較方法を改めて設計します。「解約しそうな顧客が分かったので解約率が下がる」とは言い切れません。

未経験のプラン、履歴が少ない顧客、情報更新が止まった場合は保留にします。画面や出力には対象期間と情報の更新時点を残し、担当者が確認の根拠へ戻れる形にします。

費用と導入に向かない条件を整理する

費用には、契約・利用履歴の整理、予測処理、担当者の確認画面、既存システムとの連携、定期的な再評価が含まれ得ます。外部サービスの費用と、候補を確認する社内の時間も分けて見積もります。

AiPHAのPoC開発は開発・検証20万円〜で、対象業務と開発範囲に応じた見積もりです。AIサービスなど別途必要な費用は事前に案内します。一定の予測精度や解約率の改善を保証する料金ではありません。

解約の定義がそろわない、評価できる履歴がない、担当者が候補へ対応できない場合は、記録や支援体制の整備を先に進める選択があります。現在の単純な方法で十分に対応できるなら、個別開発が必要かも比較してください。

契約の種類、解約の記録方法、今の顧客確認作業、扱えるデータの範囲を用意すると、検証する範囲を相談しやすくなります。顧客の解約兆候を確認するPoCを相談する