セクション4 応用：分析のためのデータ準備と使用 🔧🎯

このファイルは 🔧 実践（中堅） と 🎯 発展（シニア） レベル。「どう設計判断するか」「トレードオフは何か」「試験のひっかけ」に焦点を当てます。基礎概念は 01_基礎.md を参照。

4.1 可視化のためのデータ準備の設計判断

🔧 BI高速化の選択：BI Engine vs マテリアライズドビュー vs 事前集計

ダッシュボードが遅い/高い場合の打ち手は複数あり、原因に応じて使い分けます。

打ち手	効くケース	仕組み	コスト
BI Engine	同じデータへの反復クエリ（BIダッシュボード）	透過的なインメモリキャッシュ	確保メモリに課金
マテリアライズドビュー	重い集計/GROUP BYを繰り返す	結果を事前計算・増分自動更新	ストレージ＋更新分
スケジュールドクエリで集計テーブル	日次などの定期的な集計で十分	定期実行でサマリテーブル生成	実行クエリ分
パーティション/クラスタリング	スキャン量が多い	スキャン範囲を絞る	削減（後述）

ダッシュボードのレイテンシを下げたい ─► まず BI Engine
重い集計を毎回している ─────────────► マテリアライズドビュー
最新性は日次でよい定期集計 ─────────► スケジュールドクエリ

⚠️ BI Engine とマテリアライズドビューは併用可能。BI Engineは「アクセスの高速化」、マテビューは「計算の削減」と役割が違う。

🎯 低速クエリのトラブルシューティング（頻出）

「クエリが遅い・高い」原因の切り分けは試験でも実務でも重要。クエリプラン（実行詳細）/ INFORMATION_SCHEMA で原因を特定します。

まず確認するもの

クエリ実行グラフ（実行の詳細）：どのステージで時間/バイトを消費しているか
INFORMATION_SCHEMA.JOBS：スキャンバイト数・スロット時間・実行時間

主な原因と対策

症状	原因	対策
スキャン量が膨大	フルスキャン（パーティション未活用）	パーティション列でフィルタ、`SELECT *` をやめ列を絞る
特定の値に処理が偏る	データスキュー（偏り）	クラスタリング、結合キーの見直し、近似関数
シャッフルが多い	大きなテーブル同士のJOIN	非正規化（ネスト/STRUCT）、小テーブルを先にフィルタ
重複した重い計算	同じ集計を繰り返す	マテリアライズドビュー
`ORDER BY` が重い	全体ソート	不要なソートを削除、`LIMIT` と併用

避けるべきアンチパターン

SELECT *（必要な列だけにする＝列指向ストレージの利点を活かす）
パーティション列を関数で加工してフィルタ（パーティションプルーニングが効かなくなる）
巨大テーブルへの自己結合、CROSS JOIN の多用
WHERE の代わりに後段で絞る（早期フィルタが原則）

低速クエリ診断フロー:
  実行グラフで重いステージを特定
    → スキャン過多?     → パーティション/クラスタ + 列を絞る
    → JOINのシャッフル? → 非正規化(STRUCT/ARRAY) or 小テーブル先行フィルタ
    → 偏り(スキュー)?    → 結合キー見直し / 近似集計関数
    → 繰り返し集計?      → マテリアライズドビュー / BI Engine

⚠️ パーティショニングはスキャン量（コスト）削減、クラスタリングはフィルタ/集計の高速化。「日付で絞る→パーティション、特定カラムで頻繁にフィルタ→クラスタ」。

🎯 可視化セキュリティの設計（行・列・マスキング）

「同じダッシュボードを役職で出し分けたい」「アナリストにPIIを見せたくない」が定番。もとデータを複製せずに制御するのが正解の型。

要件	解決策
部署/地域ごとに見える行を変える	行レベルセキュリティ（フィルタを行に適用）
機密列を一部の人にだけ見せる	ポリシータグ（列レベルセキュリティ）
列は見せるが中身を隠す（`***`/ハッシュ）	動的データマスキング（ポリシータグ＋マスキングルール）
PIIの発見・分類そのもの	Cloud DLP（スキャンして機密度を判定）
もとテーブルを触らせず結果だけ	承認済みビュー

列レベルセキュリティ vs 動的マスキングの違い：
- 列レベルセキュリティ → 権限がないと列ごとアクセス不可（エラー）
- 動的データマスキング → 列は見えるが値がマスクされる（クエリは成功し、集計はできるが生値は見えない）
⚠️ 「列の存在は見せたいが値だけ隠したい/集計はさせたい」→ 動的データマスキング。「機密列はそもそも触らせない」→ 列レベルセキュリティ。
⚠️ Cloud DLP は検出・分類が主役。アクセス制御そのものは IAM/ポリシータグ/行レベルセキュリティが担う（混同に注意）。

🔧 ツール接続の勘所

Looker は LookML のセマンティックレイヤーで指標を一元定義 → どのダッシュボードでも同じ数字。Looker Studio はレポート単位なので指標がばらつくリスク。
BIからの接続でサービスアカウントの権限が広すぎると情報漏洩リスク。最小権限＋承認済みビュー経由が安全。

4.2 AI・ML のためのデータ準備の設計判断

🔧 BigQuery ML モデル選択の決定木（頻出）

問題文のタスク種別とデータ形状からモデルを選びます。

予測したいものは何?
  連続的な数値（売上額・気温） ─────────► 線形回帰 (Linear regression)
  カテゴリ/Yes-No（解約する?） ─────────► ロジスティック回帰
        └ 表形式で高精度が欲しい ───────► Boosted tree (XGBoost) / Random forest
        └ 非線形で複雑 ────────────────► DNN
  ラベルなしでグループ分け ─────────────► k-means（教師なし）
  時間とともに変化する値の将来 ─────────► ARIMA_PLUS（季節性・休日も自動考慮）
  ユーザーへのおすすめ ─────────────────► 行列分解 (Matrix factorization)
  どのモデルが良いか自動で選びたい ─────► AutoML Tables

⚠️ 「需要予測/売上予測で時系列」と来たら ARIMA_PLUS（線形回帰と迷わせる。時系列なら ARIMA_PLUS）。
⚠️ 「顧客をセグメント化（ラベルなし）」→ k-means（ロジスティック回帰は教師ありの分類なので不可）。
⚠️ 「表形式データでとにかく高精度」→ Boosted tree。

🔧 BigQuery ML を選ぶか Vertex AI を選ぶか

状況	選択
データがBigQueryにあり、SQLで素早く試したい	BigQuery ML
アナリスト中心・前処理〜学習〜予測をSQLで	BigQuery ML
カスタムモデル（PyTorch/TF）・大規模分散学習	Vertex AI（カスタム学習）
本番MLOps（パイプライン・監視・再学習・低レイテンシ推論）	Vertex AI
特徴量を学習/推論で一貫管理・再利用したい	Vertex AI Feature Store

⚠️ 「データ移動を避けたい＆SQLだけ」→ BQML。「MLOps/モデルレジストリ/オンライン推論」→ Vertex AI。
BQMLで学習 → Vertex AIに登録してサービング、という橋渡しも出題されうる。

🎯 特徴量エンジニアリングと training-serving skew

TRANSFORM 句に前処理を書くと、学習時の変換がモデルに保存され、ML.PREDICT 時に自動で同じ変換が適用される → 学習と推論で前処理がずれる training-serving skew を防ぐ。
⚠️ 「予測時に前処理を書き直したらズレた」→ 原因は前処理の二重管理。TRANSFORM 句で一元化するのが正解。
リーク防止：未来情報や正解由来の特徴量を入れない。分割（train/eval）を時系列で正しく行う。

🎯 埋め込み・Vector Search・RAG の設計

RAGの準備は「取り込み → 埋め込み生成 → ベクトル保存/索引 → 検索 → 生成」。どこをどのサービスで実現するかの判断がポイント。

判断軸	BigQuery で完結	Vertex AI Vector Search
データの所在	データがBQにある	どこでも
操作	SQL（`ML.GENERATE_EMBEDDING` / `VECTOR_SEARCH`）	SDK・エンドポイント
レイテンシ	分析・バッチ寄り	低レイテンシのオンライン検索に強い
規模/運用	手軽に開始	大規模・本番サービング

RAG構築の流れ（BigQueryネイティブ）:
  ドキュメント取込(GCS/BQ)
    → ML.GENERATE_EMBEDDING（Vertexの埋め込みモデルをリモート呼び出し）
    → ベクトルを列に保存 → CREATE VECTOR INDEX（高速化）
    → 質問を埋め込み → VECTOR_SEARCH で近傍ドキュメント取得
    → ML.GENERATE_TEXT に文脈として渡して回答生成

⚠️ 「LLMが社内固有の最新情報を知らない/ハルシネーションする」→ RAG（再学習やファインチューニングより手軽で、根拠を提示できる）。
⚠️ 「意味が似た文書/商品を探す」→ 埋め込み＋Vector Search（キーワード一致ではなく意味的類似）。
⚠️ 「低レイテンシで大量のオンラインベクトル検索」→ Vertex AI Vector Search。「BQ内でSQLで分析的に」→ BigQuery の VECTOR_SEARCH。

4.3 データの共有の設計判断

🔧 共有方法の選択：コピーしないのが原則

要件	解決策	理由
もとテーブルを触らせず結果だけ社内共有	承認済みビュー	権限委譲、列/行を絞れる
組織内のドメイン間/社外でデータセット共有	Analytics Hub	コピー不要・同期ズレなし
一般公開データの配布	Analytics Hub の公開リスティング	スケーラブルに配布
単発で一部だけ閲覧許可	IAMで該当データセット/ビューに付与	シンプル

⚠️ 「データをコピーして各部署に配る」は同期ズレ・コスト・ガバナンス劣化を招く。**Analytics Hub（参照型共有）**が正解。
⚠️ 「社外パートナーとBQデータを共有」→ Analytics Hub（リスティングをサブスクライブ）。エクスポートして渡す、ではない。

🎯 Analytics Hub の運用ポイント

提供者はリスティングを公開、利用者はリンクされたデータセットとして参照。クエリ課金は利用者側。
提供前に承認済みビューや列/行レベルセキュリティで見せる範囲を絞る → 機密を守りつつ共有。
VPC Service Controls の境界をまたぐ共有は境界設定に注意（情報持ち出しと整合させる）。

🎯 統合シナリオ演習（考え方の練習）

シナリオ：あるEC企業。 ① 経営層に全社共通の指標でリアルタイム性の高いダッシュボードを提供したい。ダッシュボードが現在遅い。 ② 注文テーブルには顧客のメール/電話（PII）が含まれ、アナリストには集計だけ見せたい。地域マネージャーには自地域の行だけ見せたい。 ③ 解約しそうな顧客を予測してマーケに渡したい。SQLで素早く回したい。 ④ サポート用に過去の問い合わせ文書を検索し、LLMで回答案を作りたい。 ⑤ 分析結果を**子会社（別組織）**ともコピーせず共有したい。

設計の骨子（解答例）

指標の一貫性＋ガバナンス → Looker（LookMLで全社モデル）。遅さ対策は BI Engine でダッシュボードを高速化し、重い集計は マテリアライズドビュー で事前計算。スキャン削減に注文テーブルを日付パーティション＋顧客IDクラスタリング。
アナリストには 承認済みビュー（PII列を除外/マスク）。PIIは Cloud DLP で検出・分類し、必要列に 動的データマスキング または 列レベルセキュリティ（ポリシータグ）。地域出し分けは 行レベルセキュリティ。
解約予測は二値分類 → BigQuery ML のロジスティック回帰（高精度が欲しければ Boosted tree）。前処理は TRANSFORM 句でモデルに内包し skew を防止。ML.PREDICT で対象顧客を抽出。
RAG：問い合わせ文書を取り込み、ML.GENERATE_EMBEDDING で埋め込み → CREATE VECTOR INDEX → VECTOR_SEARCH で類似文書を取得 → ML.GENERATE_TEXT で回答案生成。低レイテンシ要件が強ければ Vertex AI Vector Search。
子会社との共有は Analytics Hub（リスティング公開 → リンクされたデータセット）。コピー不要で同期ズレなし。提供範囲は承認済みビューで限定。

この「各要件を最適サービスに割り当てる」思考が本番の設計問題そのものです。

まとめ：このセクションの設計判断の型

可視化高速化は原因で選ぶ：反復クエリ→BI Engine、重い集計→マテビュー、スキャン過多→パーティション/クラスタ
セキュリティはコピーせず制御：行レベル／列レベル（ポリシータグ）／動的マスキング／DLP（検出）の役割分担
BQMLはタスクでモデル選択、本格運用は Vertex AI。前処理は TRANSFORM で skew 回避
埋め込み→Vector Search→RAG の流れ。BQ内SQL vs Vertex AI Vector Search を要件で選ぶ
共有は承認済みビュー（社内委譲）と Analytics Hub（組織間・コピー不要）

→ 03_要点と暗記.md で記憶を固めましょう。