ストーリー
田
田中VPoE
DataFlow社のチャーン予測モデルをMLOps基盤に載せる設計をしてもらう
あなた
現在は手動（Level 0）なんですよね。Jupyter Notebookで月1回学習して、手動でデプロイしている
あ
田
田中VPoE
そうだ。これをLevel 1（パイプライン自動化）に引き上げる。フィーチャーストアの導入、学習パイプラインの自動化、モデルモニタリングの設計を含む
あなた
データ基盤のGold層からフィーチャーを抽出して、フィーチャーストアに格納し、MLパイプラインで利用する流れですね
あ
田
田中VPoE
その通り。データ基盤とMLOpsの接続点を明確に設計することが重要だ
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | MLOps基盤の設計 |
| 想定時間 | 45分 |
| 成果物 | チャーン予測MLOps基盤設計書 |
Mission 1: フィーチャー設計
要件
DataFlow社のチャーン予測モデル用フィーチャーを設計してください。
- フィーチャーを10個以上定義する
- 各フィーチャーのデータソース（Gold層テーブル）を特定する
- オフライン/オンラインの提供方式を決定する
解答例
フィーチャー一覧
| フィーチャー名 | 定義 | データソース | オフライン | オンライン |
|---|---|---|---|---|
| avg_purchase_90d | 過去90日間の平均購入額 | fact_subscription | BigQuery | Redis |
| total_logins_30d | 過去30日間のログイン回数 | fact_user_activity | BigQuery | Redis |
| days_since_last_login | 最終ログインからの経過日数 | fact_user_activity | BigQuery | Redis |
| support_tickets_90d | 過去90日間のサポートチケット数 | 外部連携テーブル | BigQuery | Redis |
| feature_usage_count_30d | 過去30日間の機能利用回数 | fact_user_activity | BigQuery | Redis |
| plan_type | 現在の契約プラン | dim_plan | BigQuery | Redis |
| contract_months | 契約からの経過月数 | dim_customer | BigQuery | Redis |
| email_open_rate_30d | 過去30日間のメール開封率 | fact_campaign_performance | BigQuery | Redis |
| mrr | 当月MRR | fact_subscription | BigQuery | Redis |
| segment | 顧客セグメント | dim_customer | BigQuery | Redis |
| session_duration_avg_30d | 過去30日間の平均セッション時間 | fact_user_activity | BigQuery | Redis |
| campaign_click_rate_30d | 過去30日間のキャンペーンクリック率 | fact_campaign_performance | BigQuery | Redis |
Mission 2: MLパイプラインの設計
要件
チャーン予測モデルの学習・デプロイパイプラインを設計してください。
- パイプラインの各ステップを定義する
- 使用するツールを選定する
- Continuous Trainingのトリガーを定義する
解答例
パイプライン構成
| ステップ | 処理内容 | ツール |
|---|---|---|
| 1. データ取得 | フィーチャーストアから学習データを取得 | Feast |
| 2. データ検証 | フィーチャーの品質チェック | Great Expectations |
| 3. 学習 | XGBoostモデルの学習 | XGBoost + MLflow |
| 4. 評価 | AUC, Precision, Recall の計算 | MLflow |
| 5. モデル登録 | モデルレジストリに登録 | MLflow Model Registry |
| 6. 承認 | AUC >= 0.80 ならStaging → Production | 自動 + 手動承認 |
| 7. デプロイ | エンドポイントにデプロイ | Vertex AI Endpoints |
| 8. モニタリング | データドリフト、モデルドリフト監視 | Evidently |
オーケストレーション
| 項目 | 設定 |
|---|---|
| オーケストレーター | Airflow (Cloud Composer) |
| スケジュール | 毎週月曜日 3 AM |
| CTトリガー | PSI > 0.25 or AUC < 0.80 |
| 通知 | Slack #ml-ops |
Mission 3: モデルモニタリングの設計
要件
本番環境でのモデルモニタリング設計を行ってください。
- 監視すべきメトリクスを定義する
- ドリフト検知の閾値とアクション定義する
- A/Bテストの設計を行う
解答例
監視メトリクス
| カテゴリ | メトリクス | 閾値 | アクション |
|---|---|---|---|
| モデル性能 | AUC | < 0.80 | アラート + 再学習トリガー |
| モデル性能 | Precision | < 0.75 | アラート |
| データドリフト | PSI (各フィーチャー) | > 0.25 | 調査 + 再学習検討 |
| 予測分布 | 予測スコア分布 | KS検定 p < 0.01 | アラート |
| レイテンシ | P99推論時間 | > 100ms | インフラ調査 |
A/Bテスト設計
| 項目 | 設定 |
|---|---|
| トラフィック分割 | 新モデル20% / 既存モデル80% |
| 評価期間 | 2週間 |
| 主要メトリクス | チャーン予測的中率、誤アラート率 |
| 統計的有意性 | p < 0.05 で判定 |
達成度チェック
| 観点 | 達成基準 |
|---|---|
| フィーチャー設計 | 10個以上のフィーチャーが定義され、データソースが特定されている |
| パイプライン | 学習→評価→デプロイの各ステップとツール選定が設計されている |
| モニタリング | ドリフト検知の閾値とアクション、A/Bテスト設計が含まれている |
| データ基盤連携 | Gold層からフィーチャーストアへの接続が明確に設計されている |
推定所要時間: 45分