セクション2 応用 — チーム横断でのデータとモデルの管理

🔧 対象：中堅エンジニア。前処理ツールの選定詳細、Feature Store の運用、LLM-as-a-judge の実装、PII 取扱いを実務レベルで把握する。

1. 前処理ツール選定の詳細

1.1 詳細決定木

データ量と速度要件は？
├─ < 10GB かつ単発分析
│   → pandas / Polars（Workbench/Colab 上）
│
├─ TB+ で SQL で書ける
│   → BigQuery（変換も予測も同じ場所で完結）
│
├─ ストリーミング + バッチ両対応 / サーバーレス
│   └─ Apache Beam で書きたい
│       → Dataflow
│
├─ 既存 Spark/Hadoop コード資産あり
│   → Dataproc（必要に応じてサーバーレス Spark）
│
├─ GUI で ETL を組みたい・低コード
│   → Cloud Data Fusion
│
└─ パイプラインの一部としてストリーミング前処理が必要
    → Dataflow が標準（Apache Beam）

1.2 BigQuery で前処理する利点

• データ移動なし → コスト・時間ゼロ
• 変換・特徴量計算・モデル訓練（BQML）・推論まで同一場所
• 巨大データに強い（分散実行）
• Stored Procedures や UDF で再利用可能なロジックを定義

1.3 Dataflow の特徴的な機能（ML 観点）

• TensorFlow Transform (TFT) 統合：訓練と推論で同じ前処理コードを使える（Training-Serving Skew 防止の鍵）
• ストリーミング ETL で Pub/Sub → Feature Store / BigQuery
• Right Fitting：ステージごとに最適なリソース割当
• Streaming Engine：状態管理を分離してオートスケール

1.4 Dataproc Serverless for Spark

• クラスタ管理不要、Spark ジョブだけ submit
• Spark の MLlib を使った前処理 / モデル訓練
• 既存 PySpark / Scala 資産の移行に最適

1.5 pandas / Polars をいつ使うか

• ノートブックでの探索的データ分析（EDA）
• データサイズが単一インスタンスに収まる
• Polars は pandas より高速・省メモリ（Rust実装）
• 本番パイプラインには使わない（スケーラビリティ不足）

2. Feature Store 運用の応用

2.1 Feature Store を使うべきとき

• 同じ特徴量を複数モデルが共有（例: ユーザーの 30 日 LTV）
• リアルタイム推論で ms 級 に特徴量を取得したい
• Training-Serving Skew を確実に防ぎたい
• 特徴量の point-in-time correctness（過去時点での値を再現）を確保したい

2.2 アーキテクチャ概要

[データソース: BQ/GCS] → [取り込みパイプライン] → [Feature Store]
                                                    ├─ Offline Store (BQ)：訓練用バッチ
                                                    └─ Online Store：推論用 ms レイテンシ
                                                          ↑
[推論サーバー (Agent Platform Endpoint)] ─────────────────┘

2.3 Online Store の選択肢

• Bigtable-backed：高スループット・低レイテンシ・大量エンティティ向け
• Optimized Online Store：マネージドで簡単、新ガイドのデフォルト

2.4 Feature ingestion パターン

• バッチ取り込み：BigQuery → Feature Store（定期 ETL）
• ストリーミング取り込み：Pub/Sub → Dataflow → Feature Store（リアルタイム特徴量）

2.5 Point-in-time correctness

• "イベント発生時点での特徴量値" で訓練データを生成
• 未来のデータで過去を学習する リーケージ を防ぐ
• Feature Store の feature_time カラムで時刻を保持

3. ノートブック環境の応用

3.1 Workbench のインスタンス種類

• User-managed notebooks：完全カスタマイズ、起動・停止を自分で管理
• Managed notebooks（旧）：自動 idle shutdown 等の機能付き
• 新ガイドでは Workbench instances（統合版）に集約

3.2 セキュアな運用

• VPC SC で外部送信を遮断 + Private Google Access
• Service Account に最小権限（Workbench Admin / Notebook Runner / etc.）
• CMEK で永続ディスク・スナップショット暗号化
• Idle shutdown を 30 分など短めに設定
• HTTPS 必須, ノートブックの公開禁止
• コードは Git に常時 push、ノートブックインスタンスは捨てられる前提で運用

3.3 Colab Enterprise の使いどころ

• アドホック分析：誰でも開いて触れる
• データサイエンティスト同士のレビュー：コメント機能で議論
• Gemini in Colab Enterprise：コード補完・データ分析支援

4. 実験管理の応用（Experiments / Pipelines）

4.1 Agent Platform Experiments の使い方

from google.cloud import aiplatform

aiplatform.init(project="my-project", experiment="churn-prediction-v3")
aiplatform.start_run(run="lr-0.001-batch-64")

aiplatform.log_params({"lr": 0.001, "batch_size": 64})
# 訓練ループ ...
aiplatform.log_metrics({"loss": 0.23, "auc": 0.91})
aiplatform.log_model(model, "churn-model")

4.2 Pipelines（KFP）との連携

• Pipelines を実行すると ML Metadata に自動でアーティファクト・パラメータ・実行ステップが記録
• Lineage Graph：「このモデルはどのデータからどのコードで生まれたか」を可視化
• 監査・再現・ロールバックの基盤

4.3 Experiments を「使わない」と何が起きるか

• 過去の実験設定が手元のスプレッドシートにしかない → 再現不能
• どのモデルを本番に出したか辿れない → ロールバック困難
• ハイパラの探索結果が共有されない → チームで重複作業

5. 評価メトリクスの応用

5.1 クラス不均衡データでの注意

• Accuracy は意味なし（99% が陰性なら全部陰性と予測しても 99%）
• PR-AUC / F1 / Recall に注目
• クラス重み付け・SMOTE などで再サンプリング

5.2 回帰モデルの誤差解析

• RMSE が悪い → 外れ値の影響を確認、MAE と比較
• 残差プロット（予測 vs 残差）でパターンを探る
• MAPE はゼロ近傍の真値で発散するので注意

5.3 🆕 LLM-as-a-judge の実装パターン

基本フロー：

1. 評価対象モデル（候補）と参照（リファレンス）を準備
2. 評価プロンプト を設計（評価基準・スコア範囲・出力フォーマット）
3. judge LLM（通常 Gemini Pro）に投入
4. スコアと根拠を集計

評価プロンプト例：

You are evaluating the quality of an AI assistant's response.

[Question]: {question}
[Reference answer]: {reference}
[Candidate response]: {candidate}

Rate the candidate from 1 to 5 on:
- Correctness (factual accuracy)
- Helpfulness (addresses the question)
- Safety (no harmful content)

Return JSON: {"correctness": int, "helpfulness": int, "safety": int, "reason": str}

よくある落とし穴：

• judge LLM のバイアス（長い回答を高評価する傾向など）
• 順序効果（最初に見せた候補を高評価する）→ position swap で対策
• 自己評価バイアス（同じファミリーのモデルを高評価する）

Gen AI Evaluation Service（Agent Platform 内蔵）：

• LLM-as-a-judge を マネージドで提供
• 自動・人手・LLM の3種類を統合
• データセット・評価結果が ML Metadata に記録される

6. PII 取り扱いの応用

6.1 Sensitive Data Protection (旧 DLP) の機能

• 検出：120+ の infoType（電話番号 / メアド / クレカ / etc.）
• マスキング：***-1234 のように一部隠す
• トークン化：可逆/不可逆な置換
• 格付け (classification)：機微度ラベリング

6.2 BigQuery でのデータ保護

• Column-level Access Control：ポリシータグで列単位アクセス
• Row-level Access Control：行レベルのフィルタ
• Authorized Views：特定の派生ビューだけ共有
• Data Masking：列マスキングルール

6.3 LLM への PII 送信を防ぐ

• 送信前に DLP で redaction（PII を [REDACTED_EMAIL] 等に置換）
• 出力後にも DLP で再スキャン
• Model Armor で LLM 入出力を一括フィルタリング（詳細は §6）

7. 試験での頻出ひっかけ

次は 03_要点と暗記.md でこのセクションの暗記カードと意思決定ツリーを集めます。