既存顧客の解約の兆しを利用状況と問い合わせから拾って、フォローの順番を決める

処理の起点を決める

毎週月曜のスケジュールクエリで動かします。

日次にしないのは、解約の兆しが日単位では動かないためです。週次で十分で、費用も抑えられます。ただし「更新日まで残り90日を切った顧客」だけは別枠で毎日見ます。 年間契約では、この期間を逃すと打つ手がなくなります。

入力データを集める

データの取得方法を決める

特徴量の作り方が、この構成のいちばん重要な部分です。 現在の値ではなく、変化を特徴量にします。

「ログイン数が少ない」は、もともと少ない顧客では兆しになりません。 その顧客にとっての平常値からどれだけ落ちたかを見てください。

AIへ渡す前に整形する

1. 契約期間の短い顧客を分ける … 契約から6か月未満の顧客は、立ち上がりの途中なので同じモデルで扱えません。別に分けます
2. 解約ラベルの定義 … 「解約の申し出をした日」を基準にします。契約終了日を基準にすると、申し出から数か月後になり、予測が手遅れになります
3. クラスの不均衡への対処 … 400社のうち年間の解約は40社です。学習データは偏ります。BigQuery ML の auto_class_weights を TRUE にすると、クラスの頻度に反比例する重みが計算され、偏りの影響を軽くできます
4. 問い合わせ本文の切り出し … 署名、定型の案内文、引用を落とします。落とさないと、どの顧客も同じ文面に見えます

AIに処理させる

予測モデルと生成AIで役割を分けます。

予測モデル（BigQuery ML）にさせること： 解約の確率を数値で出すこと。model_type = 'LOGISTIC_REG' でロジスティック回帰モデルを作り、input_label_cols に解約フラグの列を指定します。ML.PREDICT は予測されたラベルの列と、各クラスの確率の列を返します。確率の数値を生成AIに出させないでください。 根拠が説明できず、精度も測れません。

生成AIにさせること：

指示内容を固定する

あなたはカスタマーサクセス担当を支援する分析担当者です。
この顧客の直近90日の問い合わせを読み、解約につながりうる兆しを拾ってください。

【厳守事項】
- 解約の確率や点数を書かないでください。
  数値はモデルが出したものを使います。
- 兆しを挙げるときは、問い合わせ本文からそのまま引用してください。
  引用のない兆しは出さないでください。
- 「解約しそうだ」と断定しないでください。
  「〜という記述がある」と事実だけを書いてください。
- 問い合わせが3件以下の場合は、「材料が少ない」と明記してください。
- 担当者個人の評価（対応が悪かった等）を書かないでください。
  問い合わせの内容だけを見てください。

【顧客の基本情報】
{account_info}

【利用状況の変化】
{usage_trend}

【直近90日の問い合わせ】
{tickets}

【前回までの担当者の記録】
{past_notes}

「解約の確率を書かない」の1行が重要です。 生成AIに確率を出させると、モデルが出した数値と食い違う2つの数字が画面に並びます。担当者はどちらを信じてよいか分からなくなります。

出力形式を固定する

Claude API の structured outputs でJSONスキーマを指定します。

{
  "account_id": "",
  "account_name": "",
  "churn_probability": 0,
  "rank": 0,
  "contract_value": 0,
  "days_to_renewal": 0,
  "usage_change": {
    "login_ratio": 0,
    "unused_features": 0
  },
  "signals": [
    {
      "category": "機能への不満 | 価格 | サポート | 社内体制の変更 | 他社検討 | その他",
      "quote": "",
      "ticket_date": ""
    }
  ],
  "evidence_thin": false,
  "why_ranked": "",
  "questions_to_ask": [],
  "needs_review": []
}

churn_probability はモデルの出力をそのまま入れます。生成AIには渡すだけで、書き換えさせません。

システムへ連携する

出力先は3通りあります。

解約を止めるための施策（値引きの提案、上位プランへの案内など）を自動で送らないでください。 兆しの読み違いで見当違いの連絡が届くと、かえって関係を損ないます。

人が確認する

上位に並んだ顧客は、全件、人が中身を見てから連絡します。

理由は、モデルが出すのは確率であって理由ではないためです。ログイン数が落ちた理由が「担当者の産休」であることもあります。数値だけを見て「解約しそうな顧客」として扱うと、失礼な連絡になります。

確認を速くするための設計が重要です。

• 一覧で、確率・契約金額・更新日までの日数を横並びで出す
• why_ranked を一覧の行に直接表示する（詳細画面を開かせない）
• 問い合わせの引用は、原文へのリンクつきで出す
• evidence_thin: true（問い合わせが少ない）の顧客は、別のグループにまとめる

下位の顧客を一覧から消さないでください。 「見なくてよい」ではなく「順番があとになる」だけです。

例外に対処する

記録を残す

この業務では、予測が当たったかどうかの記録が仕組みの寿命を決めます。

• 週次の予測結果（全社ぶん）
• 生成AIが拾った兆しと引用
• 担当者が連絡したかどうかと、その結果
• 実際に解約した顧客と、その時点の予測順位
• モデルの評価指標の推移

「予測上位だったが連絡しなかった顧客がどうなったか」を必ず残してください。 これがないと、仕組みが効いているのか、担当者の頑張りなのかが分かりません。

問い合わせ本文には顧客の担当者個人の言葉が入ります。閲覧権限を絞り、保存期間を決めてください。