Python × BigQuery ML入門。SQLだけで「来月やめる顧客」を特定するコード公開 -機械学習に「Pythonの壁」はもうない。標準SQLだけで構築する、解約予測（Churn Prediction）モデルの実装ガイド

多くのWebエンジニアやバックエンドエンジニアが、この「MLの壁」にぶつかります。
しかし、もし「普段書いているSQLだけで、機械学習モデルが作れる」としたらどうでしょうか？

Google Cloudが提供する BigQuery ML (BQML) は、その名の通り、データウェアハウスの中で直接MLモデルを作成・実行できる機能です。 データをPython環境（Notebook）に移動させる必要も、複雑なライブラリをimportする必要もありません。

CxxxPJ（シークス）のあるサービスでは、この技術を使って「来月、サービスの利用をやめそうな顧客」を特定し、自動的に対策を打っています。

本記事では、「解約予測（Churn Prediction）」をテーマに、実際に動くSQLコードを公開しながら、エンジニアが明日から使える実装アプローチを解説します。

---

第1章：なぜ「BigQuery ML」なのか？

通常のMLプロジェクトでは、データエンジニアリングの工数が8割を占めます。
通常だと、「DBからCSVをエクスポート」→「Pythonで読み込み」→「前処理」→「学習」→「推論結果をDBに戻す」…こんな感じ
だが、このデータの移動（ETL）こそが、バグの温床であり、システムの複雑性を招く原因です。

BigQuery MLのアプローチはシンプルです。
「データがある場所（BigQuery）で、計算もやってしまおう」。

• 移動ゼロ: ペタバイト級のデータでも移動不要。
• SQLのみ: CREATE MODEL と書くだけで学習開始。
• 即デプロイ: 学習が終わった瞬間から、SQLで推論（予測）が可能。

これにより、ML実装のハードルは劇的に下がりました。

---

第2章：【実装】解約予測モデルを作る

では、実際にコードを書いてみましょう。 シナリオは、サブスクリプション型サービス（またはECサイト）における「来月解約しそうなユーザー（churn）の特定」です。

1. 学習データの準備

まず、過去のユーザー行動ログから特徴量（Features）を作ります。 以下のようなテーブル user_features があると仮定します。

• user_id: ユーザーID
• recency: 最終アクセスからの経過日数
• frequency: 月間アクセス回数
• monetary: 月間購入額
• is_churned: 解約したかどうか（正解ラベル：1=解約, 0=継続）

2. モデルの作成（学習）

驚くかもしれませんが、学習に必要なコードはこれだけです。

例えば、SQL

-- ロジスティック回帰モデルを作成
CREATE OR REPLACE MODEL `project_id.dataset.churn_prediction_model`
OPTIONS(
  model_type='LOGISTIC_REG', -- ロジスティック回帰（2値分類）
  input_label_cols=['is_churned'] -- 正解ラベルのカラムを指定
) AS
SELECT
  recency,
  frequency,
  monetary,
  is_churned
FROM
  `project_id.dataset.user_features_training`
WHERE
  data_date BETWEEN '2025-01-01' AND '2025-06-30';

このクエリを実行するだけで、BigQueryが裏側でトレーニングを行い、モデルが生成されます。 Pythonで scikit-learn を書く必要すらありません。

---

第3章：【推論】未来を予言する

モデルができたら、次は「来月の予測」です。 これもSQLの標準関数 ML.PREDICT を使うだけです。

例えば、SQL

-- 来月の解約確率を予測
SELECT
  user_id,
  predicted_is_churned, -- 予測結果 (1 or 0)
  prob.label AS prediction_label,
  prob.prob AS churn_probability -- 解約確率 (0.0 ~ 1.0)
FROM
  ML.PREDICT(
    MODEL `project_id.dataset.churn_prediction_model`,
    (
      SELECT
        user_id,
        recency,
        frequency,
        monetary
      FROM
        `project_id.dataset.user_features_current` -- 最新のユーザーデータ
    )
  ),
  UNNEST(predicted_is_churned_probs) as prob
WHERE
  prob.label = 1 -- 「解約する(1)」確率だけ抽出
  AND prob.prob > 0.7 -- 解約確率70%以上の危険ユーザーを特定
ORDER BY
  churn_probability DESC;

このクエリの結果として、「解約危険度が高いユーザーリスト」が返ってきます。 エンジニアの皆さんは、このSQLをバッチ処理（Cloud Schedulerなど）で毎日回すだけでいいのです。

---

第4章：Pythonで「アクション」に繋ぐ

SQLでリストが出せたら、最後はアクションです。
ここで初めて、軽量なPython（Cloud Functions / Cloud Run）が登場します。

「予測」はSQLでやりましたが、「通知」はPythonの得意分野です。

例えば、Python

from google.cloud import bigquery
import requests

def send_retention_coupon(request):
    client = bigquery.Client()
    
    # さっきのSQLを実行して、危険ユーザーリストを取得
    query = """
        SELECT user_id, email FROM `project_id.dataset.high_risk_users`
    """
    query_job = client.query(query)

    for row in query_job:
        # メール配信APIやLINE APIを叩く
        send_email(
            to=row.email,
            subject="【特別なお知らせ】今月限りの50%OFFクーポン"
        )
        print(f"Sent coupon to {row.user_id}")
        
    return "Done"

このように、「重い計算はBigQuery（SQL）」、「軽い連携はPython」と役割分担することで、サーバーレスかつ低コストなMLパイプラインが完成します。

---

まとめ：エンジニアは「モデル」ではなく「価値」を作る

これまで機械学習は、「データサイエンティスト」という専門職の特権でした。
しかし、BigQuery MLの登場により、SQLが書ける全てのエンジニアに機械学習の門戸が開かれました。

• 複雑な環境構築は不要。
• データの移動も不要。
• 標準SQLだけで、解約予測やLTV予測、商品レコメンドが可能。

技術的に難しいことをするのが目的ではありません。
「来月やめそうな顧客」を1人でも多く救い、売上を守ること。 そのための最短ルートが、このアーキテクチャなのです。

---

👇 【戦略】なぜ「生データ」が必要なのか？
:::info 【基礎】GA4の管理画面を見るのはやめなさい

BigQuery MLを使うには、GA4のデータをBigQueryに「生」で溜めておく必要があります。 なぜ管理画面のデータでは機械学習ができないのか？その理由と連携方法。

👉 記事を読む：GA4の管理画面を見るのは、もうやめた！脱GA4

:::

👇 【応用】予測結果でWebサイトを変える
:::info 【実装】AWSで作る「動的LP」実装ガイド

「このユーザーは解約しそうだ」と予測できたら、Webサイトにアクセスした瞬間に「引き止めオファー」を出しませんか？ AWS CloudFrontを使った動的パーソナライズの実装論。

👉 記事を読む：AWSで作る「動的LP」実装ガイド

:::

記事を書いた人