セクション2 問題集 — チーム横断でのデータとモデルの管理
問題 1
5 TB の取引データ を BigQuery から取り出して特徴量化したい。最もコスト効率が良く運用負荷が低いアプローチは？
A. BigQuery から CSV にエクスポートして Workbench で pandas
B. BigQuery 内で SQL の CREATE TABLE AS で特徴量テーブルを作成
C. Dataflow ジョブを書いて再変換
D. Dataproc Serverless で PySpark を実行
解答と解説
正解：B
- 5 TB は BigQuery が得意なサイズ。SQL で特徴量化が最速・最安
- A は pandas にロードできない（メモリ不足）
- C/D は ETL ツールだが、SQL で書ける処理にわざわざ移行する必要はない
問題 2
ストリーミングデータ（Pub/Sub）から リアルタイム特徴量 を計算し、推論時に ms 級 で取得したい。最適な構成は？
A. Dataflow → BigQuery → 推論時に BigQuery クエリ B. Dataflow → Feature Store (Online Store) → 推論時に Feature Store 取得 C. Pub/Sub → Cloud Function → Cloud SQL D. Dataproc Streaming → GCS
解答と解説
正解：B
- リアルタイム特徴量計算 + ms 級取得 = Dataflow + Feature Store Online
- A は BigQuery がレイテンシ要件に不適合
- C は単機能でスケーリングに弱い、ms 級保証なし
- D は GCS は不適切
問題 3
データサイエンスチームが ML プロトタイプを Google Docs のように共同編集 しながら開発したい。最適は？
A. Workbench Instance を全員で共有 B. Colab Enterprise C. ローカル Jupyter + Git D. Cloud Functions
解答と解説
正解：B
- Colab Enterprise は コメント・リアルタイム共同編集 が標準
- A は共有がベストプラクティスではない（セキュリティリスク）
- C は協業に不向き
- D は環境が違う
問題 4（複数選択 — 2 つ選べ）
訓練と推論の 前処理の不一致 (Training-Serving Skew) を確実に防ぐ手法を 2 つ選べ。
A. TFT (TensorFlow Transform) で Transform graph を共有 B. Feature Store で同じ特徴量を取得 C. ノートブックと本番コードを手動で同期 D. クライアント側で前処理を実装
解答と解説
正解：A, B
- A：TFT は訓練時に出力した Transform graph を推論時にも適用
- B：Feature Store は中央保管 → 同じ取得経路を使うことで一貫
- C：手動同期はバグの温床
- D：Skew リスク高い
問題 5
LLM の出力品質 を低コスト・大規模に評価したい。最適なアプローチは？
A. 全件人手評価 B. BLEU スコアのみで自動評価 C. Gen AI Evaluation Service (LLM-as-a-judge) D. ユーザーアンケート
解答と解説
正解：C
- LLM-as-a-judge を統合した Gen AI Evaluation Service がマネージドで提供
- A はスケールしない
- B は主観評価に不適合（指示遵守などは BLEU では測れない）
- D は遅延・サンプル少
問題 6
複数の ML エンジニアが行うハイパラ探索結果を 比較・系統管理 したい。Google サービスは？
A. Cloud Logging B. Agent Platform Experiments + ML Metadata C. BigQuery 手動記録 D. Cloud Source Repositories
解答と解説
正解：B
- Agent Platform Experiments はパラメータ・メトリクス・アーティファクトを記録
- ML Metadata がパイプライン全体の系統 (lineage) を管理
- A はログ汎用
- C はスケールしない
- D はコード管理
問題 7
既存に 数千の PySpark スクリプト がある。これを Google Cloud で動かしたい。クラスタ管理の手間を最小化する選択肢は？
A. Cloud Dataproc（永続クラスタ） B. Cloud Dataproc Serverless for Spark C. Dataflow に PySpark を書き直す D. BigQuery にロードして SQL
解答と解説
正解：B
- 既存 PySpark を維持 + クラスタ管理不要 = Dataproc Serverless for Spark
- A は管理負荷あり
- C は書き直し工数大
- D は SQL に書き換える必要があり工数大
問題 8
機微データを含む ノートブック環境を構築する。セキュリティ要件として最重要な組合せは？（複数選択 — 2 つ選べ）
A. VPC Service Controls で境界を作る B. Service Account に最小権限 C. インスタンスを公開 IP 付きで起動 D. 共有モードで全員アクセス可
解答と解説
正解：A, B
- A：VPC SC で外部送信遮断
- B：最小権限の原則
- C：公開 IP は不要、Private Google Access 推奨
- D：機微データに共有は不適切
問題 9
JAX ベースで開発した新モデルを GPU と TPU の両方 で実験したい。Workbench での選択は？
A. JAX は Workbench では使えない B. Workbench Instance の GPU / TPU 選択で対応可能 C. Colab Enterprise のみ JAX 対応 D. Cloud Run で JAX を動かす
解答と解説
正解：B
- Workbench はインスタンス起動時に GPU や TPU を選択可能
- JAX は GPU/TPU 双方に対応
- C は誤り
- D は推論向け
問題 10
ML パイプライン実行のすべてのアーティファクト・モデル・データセットの 系統 (lineage) を辿りたい。最適なサービスは？
A. Cloud Logging B. ML Metadata（Agent Platform に統合） C. BigQuery Information Schema D. Cloud Audit Logs
解答と解説
正解：B
- ML Metadata は Pipelines 実行で 自動的に系統情報を蓄積
- A はログのみ
- C はテーブル定義
- D は監査用
問題 11
LLM-as-a-judge のバイアスとして 最も注意すべき ものは？
A. 順序効果（最初に見せた候補を高評価しがち） B. データ容量 C. リージョン差 D. 課金通貨
解答と解説
正解：A
- LLM-as-a-judge には 順序効果 (position bias)、長文を高評価 (length bias)、自己評価バイアス等がある
- 対策：position swap、複数の judge、ペアワイズ比較
問題 12（複数選択 — 2 つ選べ）
PII を扱う BigQuery テーブルへの アクセス制御 を強化したい。適切な施策を 2 つ選べ。
A. 列レベルのポリシータグ B. 行レベルアクセス制御 C. テーブルを全員に共有 D. プロジェクトを公開する
解答と解説
正解：A, B
- A：ポリシータグで列単位の機密度を管理
- B：行レベルで「自分が担当する顧客のみ閲覧」等を実装
- C/D は逆効果
問題 13
データ前処理のスケーラビリティ要件：ストリーミング + バッチ + サーバーレス + Beam SDK で開発したい。最適は？
A. Dataflow B. Dataproc C. Cloud Functions D. BigQuery
解答と解説
正解：A
- Apache Beam SDK = Dataflow。ストリーミングとバッチ両対応、サーバーレス
- B は Spark/Hadoop、Beam ではない
- C は単発タスク
- D は SQL のみ
問題 14
Feature Store の point-in-time correctness の意義は？
A. 将来のラベルが訓練に混入することを防ぐ B. ハードウェアの最適化 C. レプリケーションの一貫性 D. GPU 使用効率
解答と解説
正解：A
- 過去時点でその特徴量がどんな値だったか を保持。「イベント時刻」の値を訓練に使うことで データリーケージ防止
- 他の選択肢は無関係
問題 15
Workbench のコスト爆発の典型的原因と対策は？
A. インスタンスの放置 → Idle Shutdown を設定 B. 訓練ジョブ → SLA を上げる C. ストレージ → CMEK を無効化 D. ネットワーク → 公開 IP を付与
解答と解説
正解：A
- Workbench の代表的なコスト爆発要因は インスタンスの起動しっぱなし
- Idle Shutdown (例: 30 分) を設定するのが標準
問題 16
JSON Lines (.jsonl) フォーマットが標準なのは？
A. LLM の訓練・ファインチューニングデータ B. 画像分類のラベル C. BigQuery のクエリ結果 D. CSV 変換
解答と解説
正解：A
- LLM の SFT・ファインチューニングは JSONL が標準（input/output ペアを 1 行 1 サンプル）
問題 17
データチームが BigQuery に既にデータを集約しており、ML エンジニアが 既存パイプラインを壊さず モデルを訓練したい。最も干渉の少ない方法は？
A. 別の前処理パイプラインを Dataflow に組む B. BigQuery ML を使って同じデータセット上で訓練 C. すべてのデータを Cloud Storage に複製 D. AlloyDB を導入
解答と解説
正解：B
- 既存 BigQuery 上で 追加コスト・追加 ETL なし
- A/C は二重化で同期問題
- D は無関係
問題 18（複数選択 — 2 つ選べ）
機密データを LLM プロンプトに入れる前のチェックとして 適切な 組合せ：
A. Sensitive Data Protection で PII 検出 → マスキング B. Model Armor で入力チェック C. 何もしない、信頼している D. ローカルで暗号化してそのままプロンプトに含める
解答と解説
正解：A, B
- A：構造化 PII は DLP の主戦場
- B：プロンプトインジェクション・ジェイルブレイクは Model Armor
- C：明らかに不適切
- D：暗号化されていても LLM では復号できないので意味なし
問題 19
開発・実験用に Pipelines / Experiments / Kubeflow Pipelines からタスクに応じて選びたい。第一の判断軸は？
A. 開発フレームワークと運用負荷 B. 課金通貨 C. リージョン D. ユーザー数
解答と解説
正解：A
- 公式ガイド 2.3 「Choosing the appropriate Google Cloud environment for development and experimentation (e.g., Experiments on Agent Platform, Pipelines, Kubeflow Pipelines) given the framework」
- Experiments = 軽量、Pipelines = サーバーレス、Kubeflow on GKE = フル制御
問題 20
非構造化テキストの embeddings を BigQuery 内で生成して保存し、後で RAG に使いたい。SQL での関数は？
A. ML.GENERATE_EMBEDDING
B. ML.PREDICT
C. ML.TRANSLATE
D. ML.UNDERSTAND_TEXT
解答と解説
正解：A
ML.GENERATE_EMBEDDINGで BigQuery 内にベクトルを生成・保存- Vector Search や
ML.NEIGHBORSと組み合わせて RAG 構築可能
全 20 問。