フィットネスクラブが成人の会員の来館・契約・支払いの記録から、翌月に退会の届けを出しそうな会員を Python で見込み、店舗ごとの声かけの予定にする

処理の起点を決める

毎月1日の未明に、3つのシステムの書き出しが決まったフォルダにそろった時点で動かします。 書き出しが終わったら各システムの側で「そろった」の印のファイルを置き、ジョブ管理の仕組みが15分ごとにその印を見に行きます。印が3つそろわないまま動かすと、ある店舗の入館の記録だけが欠けた一覧ができます。

見込む先は「前月末の時点で在籍している会員が、翌月10日の締め日までに退会の届けを出すか」です。 休会の届けは別に数えます。休会は退会の手前にあることが多い一方で、けがや出張で一時的に休む会員もいます。 休会を的に入れると、声をかける理由の違う会員が混ざるので、休会の届けは特徴の側に「過去の休会の回数」として入れます。

週の単位ではなく月の単位で動かします。 締め日が月に1回なので、月の途中で確率を出し直しても、声をかけるべき会員の顔ぶれはほとんど変わりません。 来館が途切れた会員を週ごとに拾う使い方は、第9章の本格構成の先で考えます。

入力データを集める

質を決めるのは、入館の記録の会員番号のそろい方です。 会員証を忘れてフロントで入館の手続きをした日の記録が別の番号で残っていると、その会員は来館が減ったように見えます。 フロントで入館の手続きをしたときの記録のしかたを、最初に店舗でそろえます。

入れない列を、表で決めておきます。

1行目を外すのが、いちばん大事な判断です。 健康の申告書は、運動を安全に行うために預かっているものです。それを退会の見込みに使うことは、会員が申告したときの目的から外れます。

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

3つのシステムの画面から自動で取ってくる仕組みは作りません。各システムの定時の書き出しの機能で、決まったフォルダに置いてもらいます。 書き出しの機能が無いシステムなら、マネージャーの1人が月初に画面から書き出します。

来館の回数は、その会員のいつもの回数と比べます。 店舗ごとの一律の基準ではなく、直近4週の回数を、その会員の直近26週の4週あたりの回数で割った比を特徴にします。週1回のプランの会員が週1回来ていれば比は1に近く、毎日来ていた会員が週3回に減れば比は小さくなります。第3章の（a）を、ここで解きます。

学習用の正解から、引っ越しなどで届けの理由がはっきりしている退会を外しません。 理由は届けを受けた後にしか分からず、月末の時点では区別がつかないからです。 見込む先は、理由を問わず「届けが出るか」です。

AIへ渡す前に整形する

1. つなぐ … 会員番号で3つの書き出しをつなぎます。つながらない入館の記録の件数を店舗ごとに残します
2. 対象を絞る … 前月末の時点で在籍している会員だけにします。休会中の会員、すでに退会の届けを出している会員、入会から1か月未満の会員は除きます
3. 時点をそろえる … 特徴はすべて「前月末の時点」で作ります。月末より後の入館や予約を混ぜると、学習のときに答えを見てしまいます
4. 特徴を作る … 直近4週の来館の回数といつもの回数の比、最後の来館からの日数、来館の時間帯の変化、在籍の月数、プランを下げてからの日数、過去の休会の回数、口座振替の不能の回数、予約の当日の取消・無断の欠席の割合、パーソナルトレーニングの残りの回数、料金の改定の適用からの月数、プラン、店舗
5. 入れない列を落とす … 入力データの表で決めた4つの列を、読み込みの段階で読まないようにします
6. 退会の相談の記録を外す … フロントで「退会したい」と相談された記録は、届けの手前の出来事そのものなので、特徴に入れません

6番目を外さないと、学習のときだけよく当たるモデルになります。 相談の記録はほぼ届けとセットで残り、モデルはそれだけを見て確率を上げます。 本番で予定表を作る時点で、相談をしている会員はもう声をかける段階を過ぎています。

AIに処理させる

させるのは、会員ごとに「翌月10日の締め日までに退会の届けが出る確率」を出すことだけです。 学習には、過去2年分の毎月末の時点の特徴と、その翌月10日までの結果を使います。

2行目の分け方は、TimeSeriesSplit をそのまま使いません。 公式の説明では、TimeSeriesSplit は時間の順に並んだ記録を行の位置で分けるもので、分け目ごとの成績を比べられるようにするには、記録が等しい間隔で並んでいる必要があるとされています。この記録は「会員×月」の行で、月ごとの会員の数が違います。行の位置で分けると、1つの月が学習と確かめの両方にまたがります。 月の番号で行を束ね、月の境目で分けます。考え方は同じで、未来の月で学んで過去の月を確かめることを避けます。

3行目は、既定のままにしないでください。 公式の説明では、early_stopping の既定は 'auto' で、学習の件数が1万件を超えるか、X_val と y_val を fit に渡すと有効になります。 渡さないと学習の記録の一部が取り分けられて見張りに使われ、月の新旧が混ざった記録で止めどきを決めることになります。

退会は会員の数パーセントなので、class_weight は使いません。 公式の説明では 'balanced' を指定すると件数の少ない側の重みが自動で上がりますが、確率そのものが実際の割合からずれます。 この構成では確率をスタッフの人数の見積もりに使うので、重みは付けずに較正で合わせます。較正は公式の説明のとおり、学習に使った記録と重ならない月で行い、順番を保つために sigmoid を選びます。

理由の事実は、モデルではなく規則で並べます。

指示内容を固定する

この構成は生成AIを使わないため、プロンプトはありません。 代わりに、学習と予定表の作り方を決める設定を、ひとつのファイルにまとめます。

【見込む先】
target: 翌月10日（退会の届けの締め日）までに退会の届けが出る（休会の届けは 0）
as_of: 前月末
population: 前月末に在籍。休会中・届け済み・入会1か月未満は除く

【読まない列（読み込みの段階で除く）】
- 健康の申告書の内容、体組成の測定の記録
- 年齢、性別
- 声かけの結果の自由記述
- フロントでの退会の相談の記録

【モデル】
estimator: HistGradientBoostingClassifier(categorical_features="from_dtype")
class_weight: 指定しない（確率を較正で合わせる）
split: 月の境目で分ける（行の位置で分けない）
validation: 直近2か月の月末時点を X_val / y_val として fit に渡す
calibration: CalibratedClassifierCV(FrozenEstimator(model), method="sigmoid")
             較正用は学習・検証と重ならない月
学習期間: 直近24か月の月末時点

【予定表】
- 店舗ごとに確率の高い順に並べる
- フロント・トレーナー1名あたり最大10名、店舗あたり最大75名
- 入会から3か月未満の会員は、確率にかかわらず「新規」の欄に別に載せる
- 入館の記録がつながらない会員は、確率を出さず「記録不足」

【理由の文】
- 第7章の理由の表の5つの条件だけを使う
- 当てはまる条件が無い会員は「記録上の目立った変化なし（モデルの確率のみ）」と書く

「新規」の欄を分けるのは、入会から3か月未満の会員は記録が短く、確率が当てになりにくいからです。 一方で、この時期の退会は多いので、確率と別の欄で、入会の後の案内が済んでいるかをスタッフが確かめます。

出力形式を固定する

予定表は表で出し、同じ内容を JSON でも残します。 表はスタッフが読むため、JSON は翌月の振り返りのためです。

{
  "as_of": "2026-09-30",
  "model_version": "churn-2026-09",
  "store": "駅前店",
  "staff_id": "F-03",
  "members": [
    {
      "member_no": "",
      "plan": "全日",
      "probability": 0.24,
      "rank_in_store": 3,
      "reasons": [
        "直近4週の来館 2回（いつもは4週で8回ほど）",
        "直近4週の予約 6件のうち取消 4件"
      ],
      "flags": ["new_member | insufficient_records | none"],
      "contact_result": ""
    }
  ],
  "store_summary": { "listed": 75, "expected_cancellations_in_list": 11.4 }
}

expected_cancellations_in_list は、予定表に載せた会員の確率の合計です。 較正をしているので、「この75名のうち11名前後が届けを出す見込み」と読めます。マネージャーはこの数で、スタッフの割り振りが足りているかを見ます。

contact_result の欄は、スタッフが結果のコードを入れる場所です。 「話せた」「来館なし」「退会の意向を聞いた」などのコードにし、自由記述を書かせません。 翌月、この欄を読み込んで効果の測り方に使います。

システムへ連携する

会員の管理システムへは書き込みません。 確率をシステムに入れると、次の月にその確率がまた記録として書き出され、 モデルが自分の出した数字を学ぶことになります。

スタッフが見られるのは、自分の店舗の予定表だけにします。 本部の担当は全店の store_summary だけを見ます。

人が確認する

1. 書き出しの警告 … つながらない入館の記録が多い店舗、そろわなかったシステムがあれば、予定表を配る前に原因を確かめます
2. 確率の上位10名 … 理由の事実が管理システムの記録と合っているかを確かめます
3. 「新規」の欄 … 入会の後の案内が済んでいるかを確かめます
4. 「記録不足」の会員 … 会員証の番号の取り違えがないかを確かめます

マネージャーは、配る前に順番を入れ替えてかまいません。 「けがで休んでいると本人から聞いている」のように、記録に無い事情を知っていることがあります。 入れ替えたときは理由のコードを予定表の欄に入れます。

目標は、600件をならして1件2分です。 上の4つに入る会員だけを管理システムで開き、残りは予定表の確率と理由を流し見ます。

例外に対処する

最後の行の料金の改定は、退会が増える月です。 過去の改定と同じ程度の改定なら、モデルは「改定の適用からの月数」で学んでいますが、初めての大きな改定では、過去の記録に答えがありません。 そうした月は、マネージャーが規則の理由の欄を中心に順番を見直します。

3行目は、見落とすと店舗全体が「来館が減った」になります。 ゲートの停止は店舗では知られていても、記録には残りません。停止の日を本部に知らせる決まりを、店舗の運用に入れます。

記録を残す

• 月ごとの3つの書き出しの件数、つながらなかった記録の件数
• モデルの版、学習・検証・較正に使った月、確かめた結果（上位の会員のうち実際に届けを出した割合）
• 予定表の JSON の全文と、配った日時
• マネージャーが順番を入れ替えた記録と、その理由のコード
• スタッフの声かけの結果のコード
• 予定表を見た人と日時

4つ目の入れ替えの記録が、モデルの見落としを知る材料になります。 同じ理由で入れ替えが続くなら、その事情を表す記録を足せないかを考えます。