Google PDE: 機械学習、AI、データサービング — 学習ガイド

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

こちらの一部です： Google Professional Data Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloud上で本番環境レベルの機械学習およびデータサービングシステムを構築するには、統制のとれたデータモデリング、堅牢なパイプライン、そして運用上のガードレールが必要です。このセクションでは、BigQuery MLでのモデル開発、Vertex AI上でのマネージドライフサイクル（データセット、トレーニング、パイプライン、エンドポイント、特徴量エンジニアリング、モニタリング）、予測パスの設計（バッチ対オンライン）、特徴量ストアとポイントインタイムの正確性、ラベリングとバイアス制御、ベクトル検索と検索拡張生成（Retrieval-Augmented Generation）パターン、リネージとガバナンス、ドリフト監視と再トレーニングのトリガー、分析サービングレイヤー、プライバシーを意識したデータ利用について説明します。設計上の決定、スケーリング戦略、そして避けるべき一般的な障害モードに重点を置いています。

BigQuery MLと特徴量エンジニアリング

BigQuery MLを使用すると、トレーニング、評価、予測をSQLで直接実行でき、データ移動をなくし、モデル開発を分析データセットと整合させることができます。

• モデル作成: CREATE MODELを使用し、リーケージを回避して入力を標準化するために、ラベル列と特徴量変換を明示的に指定します。 例: CREATE OR REPLACE MODEL ds.churn_model OPTIONS( model_type=‘logistic_reg’, input_label_cols=[‘churned’], l1_reg=0.0, l2_reg=1.0, data_split_method=‘AUTO’ ) TRANSFORM( standardize(tenure_months) AS tenure_std, quantile_bucketize(monthly_spend, 10) AS spend_bkt, one_hot_encoder(region) AS region_ohe, ml.feature_cross(struct(bucketize(lat, 60), bucketize(lon, 60))) AS latlon_cross, (xx + yy) AS r2 – add circular decision boundary support when useful ) AS SELECT churned, tenure_months, monthly_spend, region, lat, lon, x, y FROM ds.customer_features;

• 評価: ML.EVALUATEを使用して、モデルタイプに適したメトリクス（例: 分類の場合はROC AUC、回帰の場合はRMSE）を取得します。ベースラインと信頼区間を追跡し、評価データセットを時系列に保ち、将来のパフォーマンスを近似します。 SELECT * FROM ML.EVALUATE(MODEL ds.churn_model, TABLE ds.eval_features);

• 予測: BigQueryでのオンライン風スコアリングにはML.PREDICTを使用するか、モデルをエクスポートして他の場所でサービングします。BigQueryを同期スコアリングに使用する場合は、モデルのレイテンシ予算を考慮してください。高QPSのAPIの場合は、マネージドエンドポイントにデプロイします。 SELECT user_id, predicted_churn FROM ML.PREDICT(MODEL ds.churn_model, TABLE ds.scoring_candidates);

• 特徴量変換: 再現性を確保し、前処理をモデルアーティファクトに固定するために、宣言的なTRANSFORM関数（standardize, one_hot_encoder, bucketize, quantile_bucketize, ml.feature_cross）を優先的に使用します。変換はべき等かつ決定論的に保ちます。

運用上の考慮事項と障害モード:

• ストリーミング挿入とクエリの鮮度: BigQueryのストリーミングは結果整合性を持ちます。書き込まれたばかりの行を含める必要があるリアルタイム集計の場合、測定されたストリーミングバッファのレイテンシを超える時間遅延を設けてクエリを実行します。保守的な開始点として、観測された平均可用性遅延の約2倍待つか、BigQueryに着地させる前にDataflowでウォーターマークと遅延データ処理を設計します。
• コストと同時実行性: オンデマンドのスロット同時実行数制限がボトルネックになる場合、定額料金またはFlex Slot予約に切り替え、予測可能なキャパシティを確保するためにワークロード管理（予約階層と割り当て）を実装します。
• データ品質: 不正な形式の行を含むGCSバッチロードの場合、Dataflowを使用してレコードをパースおよび検証し、正常な行をBigQueryに、不正な行を調査用のデッドレターテーブルに書き込みます。少数の不正な行のためにBigQueryがファイル全体を拒否する事態を避けます。

Vertex AI のライフサイクル、予測パス、特徴量ストア

Vertex AI は、トレーニング、パイプライン、モデルレジストリ、エンドポイント、モニタリングのためのエンドツーエンドのマネージドサービスを提供します。

• データセットとトレーニング: データセットとメタデータを登録し、必要に応じてカスタムトレーニングジョブまたは AutoML を使用します。制約に基づいてアルゴリズムを選択します。

  • リソースに制約のある単一 VM のワークロードでは、メモリ/CPU の要求が低いため、シンプルなモデル（例: 線形回帰やロジスティック回帰）が適しています。
  • 高次元のタスクでは、特徴量選択や冗長な特徴量の組み合わせにより、精度の低下を最小限に抑えながらトレーニングを高速化できることがよくあります。
  • 正例がまれで、将来の異常が既知の異常なシグネチャに類似していると予想される場合、教師なし異常検知が適しています。

• パイプライン: Vertex AI Pipelines を実装して、データ準備、トレーニング、評価、デプロイメントゲートをコード化します。パラメータ、コードのコミット SHA、コンテナダイジェスト、データセットのスナップショットを永続化して、再現性を保証します。

• エンドポイントと予測:

  • 低レイテンシのワークロード向けのオンライン予測。最小および最大レプリカ数と自動スケーリングポリシーを設定し、P95 でのモデルのレイテンシをプロファイリングして、それに応じて SLO を設定します。安全なロールアウトのために、カナリアデプロイとトラフィックスプリッティングを追加します。
  • スループット優先のジョブ（例: 夜間のスコアリング）向けのバッチ予測。バッチはリクエストごとのオーバーヘッドを回避し、大量のデータに対しては安価ですが、レイテンシは高くなります。

• 特徴量エンジニアリングと特徴量ストア: Vertex AI Feature Store を以下に使用します。

  • トレーニング用の BigQuery 内のオフラインストア。
  • エンティティ ID による低レイテンシのルックアップ用のオンラインストア。 同じ変換ロジック（例: Dataflow ライブラリや特徴量の定義）を共有し、特徴量のタイムスタンプを使用してリークを防ぐことで、トレーニングとサービングの一貫性を確保します。時間的な結合（temporal join）でポイントインタイムの正確性を維持します。 SELECT f.* FROM ds.labels l JOIN ( SELECT entity_id, feature_ts, feature_val, ROW_NUMBER() OVER (PARTITION BY entity_id ORDER BY feature_ts DESC) AS rn FROM ds.features WHERE feature_ts <= l.event_ts ) f ON f.entity_id = l.entity_id WHERE f.rn = 1;

設計上のトレードオフ:

• オンラインストアのレイテンシ vs. 鮮度: Bigtable をバックエンドとするオンラインストアは低レイテンシを提供します。バックフィルとストリーミングのアップサートがべき等であることを確認します。過度な書き込みの偏りやホットキーはパフォーマンスを低下させるため、トラフィックを均等に分散するようにエンティティ ID を設計します。
• バッチ vs. オンライン: バッチはサービングの複雑さとコストを削減しますが、古い予測を提供する可能性があります。動的な振る舞い（例: レコメンデーション）に対しては、定期的な再トレーニングとサービング時の最新の特徴量を組み合わせます。

データの品質、ラベリング、バイアス、プライバシー、ガバナンス

高品質のラベルと厳格なガバナンスが、信頼できるモデルの基盤となります。

• ラベリングと不均衡:

  • 明確なラベリングガイドラインと QA サンプリングを使用します。アノテーター間の一致率を追跡します。
  • 層化サンプリング、再重み付け、またはリサンプリングでクラスの不均衡に対処します。全体の精度だけでなく、クラスごとの適合率/再現率を監視します。
  • null は意図的に保持します。モデルが数値入力を必要とする場合、null を明示的にエンコードし（例: 「was_null」インジケーターを付けて 0 にする）、下流への影響を検証します。有益な欠損値を暗黙的に削除することは避けます。

• 過学習と汎化:

  • 緩和策には、より多様なトレーニングデータ、より小さな特徴量セット、より強力な正則化が含まれます。
  • ニューラルネットには早期停止と交差検証が不可欠です。アーキテクチャやハードウェアのスケーリングが現実的でない場合、サブサンプリングによってトレーニング時間を短縮できます。

• ガバナンスとリネージ:

  • Vertex ML Metadata、Model Registry、Data Catalog でリネージを追跡します。データセットのバージョン、変換、ハイパーパラメータ、環境を記録します。
  • 承認ワークフロー: デプロイ前に人間の承認を要求し、Model Registry の状態とポリシーチェック付きの Cloud Build/Deploy を使用します。アーティファクトを Artifact Registry に保存し、コンテナに署名し、ゲート付きのロールアウトのために Binary Authorization を適用します。

• モニタリング、ドリフト、再トレーニング:

  • 予測のスキュー、特徴量のドリフト、パフォーマンスの低下に対してモデルモニタリングを有効にします。分布メトリクス（例: PSI、KL ダイバージェンス）と、正解ラベルが後から到着する場合の遅延を考慮した評価を使用します。
  • 統計的に有意なドリフト、SLO 違反、またはビジネスイベントのウィンドウに基づいて再トレーニングのトリガーを設定します。再トレーニングパイプラインを自動化しますが、昇格は評価とバイアスチェックでゲートします。
  • 上流のスキーマ変更によるサイレントなデータドリフトに注意し、スキーマ契約を適用し、欠損または変化した特徴量についてアラートを発します。

• プライバシーを意識した設計:

  • Data Catalog のポリシー タグを使用してデータを分類し、BigQuery でデータマスキングポリシーを用いて列レベルおよび行レベルのセキュリティを適用します。
  • データ収集を最小限に抑え、目的の制限に紐付いたデータ保持および削除の SLA を実装します。
  • DLP を適用して検出と非識別化を行い、CMEK でデータを暗号化し、VPC Service Controls でサービスを分離し、きめ細かい IAM を確保して最小権限の専用サービスアカウントを使用します。
  • モニタリングとロギングでは、PII を編集し、不要なペイロードのロギングを避けます。

ベクトル検索、RAG パイプライン、分析サービングレイヤー

最新の検索とサービングには、ベクトルネイティブなコンポーネントと実績のある分析ストアの両方が必要です。

• ベクトル検索と埋め込み:

  • 大規模で低レイテンシな最近傍検索には Vertex AI Vector Search または BigQuery のベクトル検索を使用します。アプリケーション中心のセマンティクスとトランザクションのニーズには、pgvector を備えた AlloyDB for PostgreSQL を選択します。
  • Vertex Pipelines を使用して埋め込みをバッチ生成し、ベクトルを詳細なメタデータと共に保存します。レイテンシを抑制するために、インテリジェントにパーティション分割とインデックス作成（例：ドキュメントのドメイン別）を行います。

• 検索拡張生成（RAG）パイプライン:

  • Dataflow または Dataproc を介してコンテンツを取り込み、テキストを抽出し、チャンク化、埋め込みを行い、ベクトルストアにインデックスを作成します。トレーサビリティのために、信頼できる情報源（source-of-truth）への参照を維持します。
  • 鮮度戦略を実装します：定期的な再埋め込み、ソース更新時の無効化、インデックスを交換する前に品質を検証するためのカナリアインデックス作成。
  • 検索品質（ヒット率、MRR、nDCG）とコンテンツの安全性を監視し、制限されたデータに対してガードレールとアクセス制御を適用します。

• 分析サービングレイヤーとデータプロダクト:

  • BigQuery で bronze/silver/gold のデータプロダクトをキュレートし、パーティショニングとクラスタリングを使用してスキャンコストを最小化します。マテリアライズドビューは、一般的なクエリを高速化できます。
  • 低レイテンシのキーバリューや高 QPS のカウンターには、適切に分散された行キーを持つ Bigtable を使用します。プレフィックスにソルトを追加したりハッシュ化したりすることで、ホットスポットを回避します。
  • OLTP ワークロードと強い整合性には、Cloud SQL または Spanner を使用します。スケジュールされた ELT を介して分析を BigQuery にオフロードします。
  • ストリーミング設計: Pub/Sub → Dataflow → BigQuery/Bigtable（自動スケーリング付き）。バックログとウォーターマークのメトリクスを監視します。デフォルトの自動スケーリングは、コストを制御しながら、弾力性のある負荷に対応するのに十分です。

運用のヒント:

• 特定の BigQuery テーブル挿入ジョブで通知をトリガーするには、高度なフィルターを使用して関連する Cloud Logging エントリを Pub/Sub にエクスポートし、そのサブスクリプションからアラートを接続します。

undefined

実践的な問題シナリオ

ファッションマーケットプレイスの AcmeStyle は、ユーザーの嗜好が時間単位で変化するのに合わせて、サイト内のレコメンデーションを最新の状態に保ちたいと考えています。彼らはクリックや購入行動をストリーミングしており、これをカタログのコンテキストと組み合わせて、低レイテンシかつコストを抑えながらレコメンデーションを更新する必要があります。

アプローチ:

1. ストリーム取り込みと品質ゲート

• ウェブとモバイルからのイベント取り込みに Pub/Sub を使用します。Dataflow ストリーミングジョブがスキーマを検証し、カタログデータでエンリッチし、以下を書き込みます。
  • クリーンなイベントを BigQuery のパーティション分割テーブル（event_date）に。オフライン分析とトレーニング用。
  • 集約されたユーザー特徴量の更新を Vertex AI Feature Store（オンラインストア）に。user_id をキーとする。 理由: Pub/Sub はプロデューサーとコンシューマーを分離します。Dataflow はべき等なアップサートによる exactly-once セマンティクスを提供します。パーティション分割された BigQuery はコストと保持期間を管理します。オンラインストアはミリ秒単位のルックアップを可能にします。

2. ポイントインタイムの正確性を持つ特徴量定義

• ローリング CTR、ブランド親和性、リーセンシーなどの特徴量を、明示的な event_time を用いて定義します。以下にマテリアライズします。
  • BigQuery のオフラインストアに。feature_ts <= label_ts に制約された時間的結合を用いたトレーニング用。
  • オンラインストアに。TTL を設定して古い値の使用を防ぐサービング用。 理由: 明確なタイムスタンプはラベルリークを防ぎます。オフラインとオンラインで一貫した定義は、トレーニングとサービングのパリティ（一貫性）を保証します。

3. モデルのトレーニングとリネージ

• 以下の処理を行う Vertex AI Pipeline を実装します。
  • 時間ウィンドウ（例：過去 30 日間）を使用して BigQuery からトレーニングデータを抽出します。
  • サービングで使用されるのと同じ変換を適用します（共有ライブラリ）。
  • ランキングモデルをトレーニングし、メタデータ（データセットのスナップショット ID、コードのコミット SHA、ハイパーパラメータ）を ML Metadata に記録し、モデルを Model Registry に登録します。 理由: パイプラインは実行を再現可能かつ監査可能にします。Model Registry はバージョンと承認を集中管理します。

4. バッチ予測とオンライン予測のパス

• 夜間のバッチ予測で、カタログとユーザーの全組み合わせをスコアリングし、バックフィルと A/B テストのために BigQuery に書き込みます。
• Vertex エンドポイントを介したオンライン予測。以下の処理を行います。
  • オンラインストアから最新のユーザー特徴量を取得します。
  • 在庫と利用可能性でフィルタリングされた上位 K 個の候補をスコアリングします。
  • バーストを吸収するために、結果を短期間キャッシュします。 理由: バッチは網羅性とコスト効率を提供します。オンラインは価値の高いセッションの最新の行動を捉えます。自動スケーリングするエンドポイントはレイテンシの SLO を維持します。キャッシングはテールレイテンシとコストを削減します。

5. モニタリング、ドリフト検出、再トレーニングポリシー

• 特徴量のドリフトと予測のスキューに対してモデルモニタリングを有効にし、トレーニングのベースラインと分布を比較します。CTR/CVR の SLO を追跡し、悪化した場合にアラートを送信します。
• 過去のデータと新しいデータを組み合わせたローリングウィンドウを使用して継続的に再トレーニングします。ドリフトがしきい値を超えた場合、または最低でも週次で再トレーニングをトリガーします。 理由: ファッショントレンドは急速に変化します。過去のデータと最近のシグナルを組み合わせることで、最新の状態を保ちながら学習を安定させます。

6. プライバシーとガバナンス

• PII を含む列に Data Catalog のポリシー タグを付け、BigQuery で列レベルのセキュリティを適用し、必要に応じてマスキングします。生のイベントに対して DLP スキャンを実行し、必要なフィールドのみを保存します。
• Model Registry の承認ステータスと統合された Cloud Build トリガーを介して、ステージングから本番環境へモデルを昇格させる際に、人間の承認を要求します。 理由: 最小権限アクセスはリスクを低減します。デプロイにゲートを設けることで、コンプライアンスと安全性を確保します。

7. コストとキャパシティの制御

• BigQuery の予約を使用して、トレーニングウィンドウのために予測可能なスロットキャパシティを保証します。
• バックログに基づいて Dataflow ワーカーを自動的にスケーリングします。ホットスポットを防ぐために、user_id のプレフィックスをハッシュ化して特徴量ストアのホットキーをシャーディングします。 理由: 予測可能なキャパシティは競合を回避します。自動スケーリングは支出を需要に合わせます。バランスの取れたキーは低レイテンシの更新を維持します。

この設計は、ストリーミング特徴量をサービングに利用し、最近のデータで定期的に再トレーニングすることで、レコメンデーションを最新の状態に保ちます。同時に、正確性、ガバナンス、そしてスケーラブルで予測可能なパフォーマンスを維持します。

← ワークフローのオーケストレーションとパイプラインの自動化 · すべてのドメイン · データガバナンス、セキュリティ、信頼性、コスト運用 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →