§2 チーム横断でのデータとモデルの管理
データ探索・前処理・ノートブック協業・実験管理。比重 ~16%。MLOps の入口。
🔧 前処理ツールの選定
データ量と速度要件は？
├─ < 10GB / 単発分析 → pandas / Polars（Workbench/Colab 上）
├─ TB+ で SQL で書ける → BigQuery（変換も予測も同じ場所で完結）
├─ ストリーミング + バッチ両対応 / サーバーレス → Dataflow（Apache Beam）
├─ 既存 Spark/Hadoop コード資産あり → Dataproc（必要に応じて Serverless）
└─ GUI で ETL を組みたい → Cloud Data Fusion
| ツール | 規模 | サーバーレス | ストリーミング | 第一候補 |
|---|---|---|---|---|
| pandas / Polars | GB | – | × | EDA / 小規模 |
| BigQuery | PB+ | ◎ | × | SQL で完結 |
| Dataflow | PB+ | ◎ | ◎ | Apache Beam パイプライン |
| Dataproc / Serverless | PB+ | △ | ○ | 既存 Spark 資産 |
| Data Fusion | TB+ | ○ | ○ | GUI ETL |
🗂 Agent Platform Feature Store
役割
訓練と推論で 同じ特徴量を一貫して使うための保管庫。Online（ms 級）と Offline（BQ）。
なぜ必要
Training-Serving Skew 防止 / 特徴量の再利用 / オンライン推論の低レイテンシ / point-in-time correctness。
[データソース: BQ/GCS] → [取り込みパイプライン] → [Feature Store]
├─ Offline Store (BQ)：訓練用バッチ
└─ Online Store：推論用 ms レイテンシ
↑
[推論サーバー (Agent Platform Endpoint)] ─────────────────┘
point-in-time correctness
"イベント発生時点での特徴量値" で訓練データを生成 → 未来のデータが過去に混入する データリーケージ を防止。
📓 Workbench / Colab Enterprise
| 観点 | Workbench | Colab Enterprise |
|---|---|---|
| インスタンス管理 | 必要（起動・停止） | 不要（サーバーレス） |
| GPU カスタマイズ | 細かく可能 | 限定的 |
| 協業 | 限定的 | Google Docs ライク（コメント・共有） |
| カスタムイメージ | 可 | △ |
| 第一候補 | 長期 ML 開発・GPU 細かく要 | アドホック・ペアプロ・チーム共有 |
セキュリティ Best Practice
- VPC SC 内に配置 + Private Google Access
- サービスアカウント に最小権限
- CMEK で永続ディスク暗号化
- Idle shutdown を 30 分など短めに設定（コスト爆発の最大原因）
🧪 実験管理（Experiments / ML Metadata）
Agent Platform Experiments
Run 単位でパラメータ・メトリクス・成果物・環境を記録。並列比較プロットで容易に比較。
ML Metadata
パイプライン実行のアーティファクト・パラメータ・実行ステップを自動収集。Lineage Graph で「このモデルはどのデータから？」を辿れる。
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")📊 評価メトリクス & 🆕 LLM-as-a-judge
- Accuracy：全正解率（クラス不均衡で誤りやすい）
- Precision：陽性予測のうち実際に陽性（誤検知を抑える）
- Recall：実際の陽性のうち検知できた（取りこぼし防止）
- F1：Precision/Recall の調和平均
- AUC-ROC / AUC-PR：閾値非依存（不均衡には PR-AUC）
- Confusion Matrix：詳細な誤り分析
- RMSE：大きな誤差を重視
- MAE：外れ値に頑健
- MAPE：相対誤差（スケール非依存、ゼロ近傍で発散注意）
- R²：決定係数
| アプローチ | 説明 | 用途 |
|---|---|---|
| 自動メトリクス | BLEU / ROUGE / Perplexity | 翻訳・要約の参照との一致 |
| 🆕 LLM-as-a-judge | Gemini に他モデル出力を評価させる | 指示遵守・有害性・トーンの主観評価 |
| 人手評価 | アノテーター | 最終品質確認 |
| 🆕 Gen AI Evaluation Service | 自動 + LLM + 人手をマネージドで統合 | 本番継続評価の標準 |
LLM-as-a-judge のバイアス
順序効果（最初に提示した候補を高評価しがち）、長文選好、自己評価バイアス。
対策：position swap、ペアワイズ比較、複数 judge での合議。
🛡 PII の取り扱い
Sensitive Data Protection (旧 DLP)
120+ infoType の検出・マスキング・トークン化・分類
BigQuery ポリシータグ
列レベル制御
CMEK + VPC SC
暗号化キー自社管理 + 境界制御
⚠️ 試験での頻出ひっかけ
| シナリオ | 不正解 | 正解 |
|---|---|---|
| "数 TB のデータを SQL で前処理" | Dataflow で複雑なパイプライン | BigQuery で完結 |
| "ストリーミングで特徴量を更新" | バッチ ETL | Dataflow → Feature Store |
| "既存 Spark を活かす" | Dataflow に書き直し | Dataproc Serverless for Spark |
| "オンライン推論で ms 級に特徴量" | BigQuery 毎リクエスト | Feature Store Online Store |
| "訓練/推論で前処理コードがズレて Skew" | 手動同期 | TFT or Feature Store |
| "複数人で同時にノートブック編集" | Workbench パス回し | Colab Enterprise |
| "ノートブック起動しっぱなしで課金" | 手動停止 | Idle shutdown 設定 |
| "生成 AI 品質評価がコスト高" | 全件人手 | LLM-as-a-judge + 人手はサンプリング |
📝 セルフチェック（5 問）
Q1
5 TB データを BigQuery で特徴量化したい。最もコスト効率良い方法は？
正解: B。BQ で書ける処理は BQ 完結が最速・最安。
Q2
Pub/Sub からリアルタイム特徴量を計算し、推論時に ms 級で取得したい。
正解: B。ms 級は Feature Store Online。
Q3 複数選択
Training-Serving Skew を確実に防ぐ手段 2 つ：
正解: A, B。
Q4
データサイエンスチームが ML プロトを Google Docs のように共同編集したい。最適は？
正解: B。コメント・リアルタイム共同編集が標準。
Q5 🆕 新ガイド
LLM の出力品質を低コスト・大規模に評価したい。最適は？
正解: C。マネージドの統合評価サービス。