セクション4：分析のためのデータ準備と使用
整えたデータを「見える化（BI/可視化）」「予測（AI・ML）」「共有」へとつなげる工程。
Looker / BI Engine / マテリアライズドビュー・BigQuery ML・埋め込み/RAG・Analytics Hub が主役です。
どの要件をどのサービスで満たすか、その判断が本番の設計問題そのものになります。
出題 ~15%
📘 基礎
🔧 実践
🎯 発展
🔑 TL;DR（このセクションの核）
- 可視化は Looker（全社モデル）/ Looker Studio（手軽） ＋ BI Engine（インメモリ高速化）/ マテリアライズドビュー（事前計算）
- セキュリティは 列（ポリシータグ）・行（行レベル）・値（マスキング）・PII（DLP） の多層。もとデータを複製せず制御するのが正解の型
- ML準備は BigQuery ML（SQLで完結） vs Vertex AI（本格MLOps）。モデルはタスク種別で選ぶ
- 埋め込み・Vector Search・RAG は2024改訂の新トピック（
ML.GENERATE_EMBEDDING → VECTOR_SEARCH → ML.GENERATE_TEXT）
- 共有はコピーしない：社内委譲＝承認済みビュー、組織間＝Analytics Hub
🎯 学習目標チェックリスト
📖 学習コンテンツ
📘 基礎 BI/可視化・ML準備・データ共有の「概念」と「サービスの役割」を理解することがゴールです。設計判断やトレードオフは「応用」タブで扱います。
4.1 可視化のためのデータ準備
整えたデータをダッシュボードやレポートで「見える化」する工程です。速く・安く・安全に見せることが目的。「BIツールへの接続」「事前計算による高速化」「アクセス制御」が三本柱です。
① BIツール：Looker と Looker Studio
GCPの可視化ツールは大きく2つ。用途と規模で使い分けます（試験頻出の対比）。
| 観点 | Looker | Looker Studio（旧 Data Studio） |
|---|
| 位置づけ | エンタープライズBIプラットフォーム | 軽量なダッシュボード/レポートツール |
|---|
| 料金 | 有償（ライセンス） | 基本無料（Studio Pro は有償） |
|---|
| データモデル | LookML で一元的にモデル定義（セマンティックレイヤー） | レポート単位で個別に接続・定義 |
|---|
| 指標の一貫性 | 全社で共通定義（信頼できる単一の真実） | レポートごとにばらつきやすい |
|---|
| ガバナンス | 強い（バージョン管理・権限・監査） | 弱め（手軽さ優先） |
|---|
| 典型用途 | 全社共通のメトリクス・組込み分析・データアプリ | アドホックな可視化・小規模レポート・共有 |
|---|
全社で指標を統一・ガバナンス重視 ──► Looker（LookMLでモデル化）
手軽に無料でダッシュボードを作る ──► Looker Studio
💡 覚え方
Looker は「モデル化された信頼できる指標を全社で」。Looker Studio は「手軽に無料で可視化」。
② BI Engine：BigQuery のインメモリ高速化
BI Engine は BigQuery 専用のインメモリ分析アクセラレータ。よく使うデータをメモリにキャッシュし、ダッシュボードのクエリをサブ秒で返します。
- BIツール（Looker / Looker Studio / 対応サードパーティ）からの反復的なクエリを高速化
- 仕組みは透過的：クエリは普通に BigQuery に投げるだけで、対象データがメモリに乗っていれば自動的に高速化
- 課金は確保したメモリ容量（GB単位の予約）に対して発生
[BIツール] → クエリ → [BigQuery]
│
BI Engine が対象データを
インメモリにキャッシュ → サブ秒応答
③ マテリアライズドビュー（Materialized View）
集計・結合の結果を事前計算して保存しておくビュー。クエリのたびに再計算しないので速く・安くなります。
| 種類 | 実体 | 特徴 |
|---|
| 通常のビュー | 保存しない（クエリの別名） | 毎回もとのテーブルを全計算。最新だが遅い/高い |
|---|
| マテリアライズドビュー | 結果を保存（自動更新） | 事前計算済みで高速・低コスト。差分のみ自動更新 |
|---|
- ベーステーブルの変更を 増分（差分）で自動的に反映するため、手動更新は不要
- スマートチューニング：もとのテーブルへのクエリでも、最適なら自動的にマテリアライズドビューを使ってくれる
- 主に集計（SUM/COUNT/GROUP BY）を高速化する用途
④ フィールドの事前計算
レポート表示のたびに重い計算をすると遅くなります。あらかじめ計算して持っておくのが基本。
- 事前計算の手段：マテリアライズドビュー、スケジュールドクエリで集計テーブルを定期生成、Looker の LookML で計算項目（measure/dimension）を定義
- 「ダッシュボードが遅い」→ 表示のたびに巨大テーブルを集計している、が典型原因
⑤ 可視化のためのセキュリティ
「誰に・どのデータを見せるか」を制御します。BigQuery は段階的な粒度でアクセス制御できます。
| レベル | 仕組み | 例 |
|---|
| データセット/テーブル | IAM ロール | このデータセットを閲覧できるのは誰か |
| 列レベル | ポリシータグ（Dataplex のタクソノミー） | 機密列（給与・SSN）を特定の人にだけ見せる |
| 行レベル | 行レベルセキュリティ（Row-level security） | 営業担当者は自分の地域の行だけ見える |
| 値のマスキング | 動的データマスキング | 列は見えるが中身は *** やハッシュで隠す |
- Cloud DLP（Sensitive Data Protection）：PII（氏名・クレカ番号など）を検出・分類・マスキング/トークン化するサービス。可視化前にPIIを発見・保護する。
- これらはもとデータを複製せずにアクセスを制御できるのが利点（詳細は「応用」タブ）。
4.2 AI・ML のためのデータ準備
データを「分析」だけでなく「予測」にも使います。GCPではSQLだけでMLできる BigQuery ML と、本格的なMLOpsの Vertex AI の2つが軸です。
① 特徴量エンジニアリング・学習・サービング
MLは「特徴量を作る → 学習する → 予測を提供（サービング）する」の流れ。それぞれの準備を BigQuery で完結できます。
| 工程 | 内容 | BigQuery での手段 |
|---|
| 特徴量エンジニアリング | 生データを予測に効く形へ加工（正規化・エンコード・集約） | SQL変換、TRANSFORM 句、ML.FEATURE_* 関数 |
|---|
| 学習（Training） | モデルを作る | CREATE MODEL 文 |
|---|
| 評価（Evaluation） | 精度を測る | ML.EVALUATE |
|---|
| サービング（Serving / 推論） | 予測する | ML.PREDICT（バッチ）、Vertex AI でオンライン推論 |
|---|
TRANSFORM 句：学習時の前処理をモデル内に保存し、予測時に同じ変換を自動適用（学習/予測の前処理ズレ＝training-serving skew を防ぐ）
② BigQuery ML（BQML）：SQLだけで機械学習
SQLの CREATE MODEL 文だけでモデルを作成・予測できる仕組み。データをBigQueryの外に出さずに済みます。主要なモデル種別：
| モデル種別 | タスク | 典型用途 |
|---|
| 線形回帰（Linear regression） | 回帰（数値予測） | 売上・需要などの連続値予測 |
|---|
| ロジスティック回帰（Logistic regression） | 分類 | 解約予測・スパム判定（2値/多値分類） |
|---|
| k-means | クラスタリング（教師なし） | 顧客セグメンテーション |
|---|
| 行列分解（Matrix factorization） | レコメンド | 商品・コンテンツの推薦 |
|---|
| 時系列 ARIMA_PLUS | 時系列予測 | 売上・在庫の将来予測（季節性・休日対応） |
|---|
| Boosted tree（XGBoost） | 分類/回帰 | 表形式データで高精度が欲しいとき |
|---|
| Random forest | 分類/回帰 | 表形式データ・頑健な予測 |
|---|
| DNN（ディープニューラルネット） | 分類/回帰 | 非線形で複雑なパターン |
|---|
| AutoML Tables | 分類/回帰 | モデル選定を自動化したいとき |
|---|
| インポート/リモートモデル | 推論 | TensorFlow等の既存モデルや Vertex AI のモデルを呼ぶ |
|---|
数値を予測 ─────────────► 線形回帰
Yes/No・カテゴリを分類 ──► ロジスティック回帰 / Boosted tree
グループに分ける ────────► k-means
時系列の将来を予測 ──────► ARIMA_PLUS
おすすめを出す ──────────► 行列分解（Matrix factorization）
💡 覚え方
「連続値＝線形回帰」「分類＝ロジスティック回帰／表形式で高精度なら Boosted tree」「教師なしのグループ化＝k-means」「時系列＝ARIMA_PLUS」「推薦＝行列分解」。
③ BigQuery ML と Vertex AI の役割
| 観点 | BigQuery ML | Vertex AI |
|---|
| 操作 | SQL | Python/SDK・コンソール・パイプライン |
|---|
| 対象者 | データアナリスト/SQLユーザー | MLエンジニア/データサイエンティスト |
|---|
| データ移動 | 不要（BQ内で完結） | 必要に応じてエクスポート |
|---|
| 得意領域 | 表形式データの素早いモデル化 | 本格的なMLOps・カスタム学習・大規模サービング |
|---|
| MLOps | 限定的 | パイプライン・モデル管理・モニタリング・Feature Store |
|---|
SQLで手早く・BQ内で完結 ──────────► BigQuery ML
本格MLOps・カスタムモデル・運用 ──► Vertex AI
- Feature Store（Vertex AI）：特徴量を一元管理・再利用し、学習と推論で一貫した特徴量を提供
- BQML で作ったモデルを Vertex AI に登録して、オンライン推論やモニタリングに繋ぐこともできる（両者は連携可能）
④ 非構造化データの埋め込み（Embeddings）と RAG 準備
2024年の改訂で追加された新トピック。テキスト・画像などの非構造化データを「意味のベクトル」に変換（埋め込み＝embedding）し、類似検索やLLMの回答補強に使います。
- 埋め込み（Embeddings）：テキスト/画像を高次元の数値ベクトルに変換した表現。意味が近いものはベクトルも近い。
- Vector Search（ベクトル検索）：埋め込み同士の近傍検索。「意味が似ているものを探す」。
- RAG（Retrieval-Augmented Generation＝検索拡張生成）：質問に関連する社内ドキュメントを検索して取り出し、その内容をLLMに渡して回答させる手法。LLMの知識不足やハルシネーションを抑える。
RAG の準備フロー（BigQuery で完結できる）:
① 非構造化データ（ドキュメント等）を BigQuery / GCS に取り込む
② ML.GENERATE_EMBEDDING で埋め込みベクトルを生成
（Vertex AI の埋め込みモデルをリモートモデルとして呼ぶ）
③ ベクトルを保存し、必要ならベクトルインデックスを作成
④ 質問を埋め込み → VECTOR_SEARCH で近いドキュメントを検索
⑤ 取り出した文脈を LLM（ML.GENERATE_TEXT）に渡して回答生成
- BigQuery では
ML.GENERATE_EMBEDDING（埋め込み生成）、VECTOR_SEARCH（近傍検索）、CREATE VECTOR INDEX（高速化）でこの流れをSQLで実現できる
- 本格的な低レイテンシのベクトル検索が必要なら Vertex AI Vector Search（旧 Matching Engine）を使う
4.3 データの共有
作ったデータや分析結果を、社内の別チームや社外パートナーと安全に共有する工程です。「コピーして配る」のではなく「アクセスを許可する」のが現代的。
① 共有ルールの定義
何を・誰に・どこまで共有するかを最初に決めます。
- アクセス制御：IAMで「閲覧のみ」「特定データセットのみ」を付与
- 粒度の制御：行/列レベルセキュリティ、承認済みビューで見せる範囲を絞る
- PII保護：共有前に DLP でマスキング/トークン化
② 承認済みビュー（Authorized View）
もとのテーブルへのアクセス権を与えずに、ビューの結果だけを共有できる仕組み。
[元テーブル(機密)] ← 利用者は直接アクセス不可
│
承認済みビュー（必要な列・行・集計だけ）
│
[利用者] ← ビューだけ見える
- 「アナリストには集計結果だけ見せ、生の個人情報テーブルは触らせない」の定番解答
- 関連：承認済みデータセット、承認済みルーティン（UDF）でも同様の委譲ができる
③ Analytics Hub：BigQuery のデータ共有
組織の内外でデータをコピーせずに共有するための仕組み。データ提供者（Publisher）がリスティングを公開し、利用者（Subscriber）がリンクされたデータセットとして自分のプロジェクトから参照します。
[提供者] データ交換(Exchange)に
リスティングを公開（元データはコピーされない）
│ サブスクライブ
▼
[利用者] 自プロジェクトに「リンクされたデータセット」が出現
→ 自分のクエリから普通に参照（課金は利用者側のクエリに）
- データはコピーされない：提供者のデータをその場で参照する（重複・同期ズレ・転送コストを回避）
- 社内のドメイン間共有、社外パートナーへの提供、公開データセットの配布に使える
- アクセスは IAM で管理。提供時に承認済みビュー等で見せる範囲を絞れる
④ レポート・可視化の共有
- Looker Studio：レポートのURL共有・埋め込み・スケジュール配信
- Looker：ダッシュボードの共有、他アプリへの組込み分析（embedded analytics）、配信
- 共有時ももとのデータのアクセス制御（行/列レベル）が効くように設計する
📌 このセクションの基礎まとめ
- 可視化は Looker（全社モデル）/ Looker Studio（手軽） ＋ BI Engine（インメモリ高速化）/ マテリアライズドビュー（事前計算）
- セキュリティは列（ポリシータグ）・行（行レベル）・値（マスキング）・PII（DLP）の多層
- ML準備は BigQuery ML（SQLで完結）vs Vertex AI（本格MLOps）。モデル種別を用途で選ぶ
- 埋め込み・Vector Search・RAG は2024改訂の新トピック（
ML.GENERATE_EMBEDDING → VECTOR_SEARCH）
- 共有はコピーしない：承認済みビュー（社内委譲）と Analytics Hub（組織間）
🔧 実践（中堅） 🎯 発展（シニア）「どう設計判断するか」「トレードオフは何か」「試験のひっかけ」に焦点を当てます。基礎概念は「基礎」タブを参照。
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
⚠️ パーティション vs クラスタリング
パーティショニングはスキャン量（コスト）削減、クラスタリングはフィルタ/集計の高速化。「日付で絞る→パーティション、特定カラムで頻繁にフィルタ→クラスタ」。
🎯 可視化セキュリティの設計（行・列・マスキング）
「同じダッシュボードを役職で出し分けたい」「アナリストにPIIを見せたくない」が定番。もとデータを複製せずに制御するのが正解の型。
| 要件 | 解決策 |
|---|
| 部署/地域ごとに見える行を変える | 行レベルセキュリティ（フィルタを行に適用） |
| 機密列を一部の人にだけ見せる | ポリシータグ（列レベルセキュリティ） |
列は見せるが中身を隠す（***/ハッシュ） | 動的データマスキング（ポリシータグ＋マスキングルール） |
| PIIの発見・分類そのもの | Cloud DLP（スキャンして機密度を判定） |
| もとテーブルを触らせず結果だけ | 承認済みビュー |
列レベルセキュリティ vs 動的マスキング の違い：
- 列レベルセキュリティ → 権限がないと列ごとアクセス不可（エラー）
- 動的データマスキング → 列は見えるが値がマスクされる（クエリは成功し、集計はできるが生値は見えない）
⚠️ 使い分け
「列の存在は見せたいが値だけ隠したい/集計はさせたい」→ 動的データマスキング。「機密列はそもそも触らせない」→ 列レベルセキュリティ。
⚠️ DLP の役割を混同しない
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 を防ぐ。- リーク防止：未来情報や正解由来の特徴量を入れない。分割（train/eval）を時系列で正しく行う。
⚠️ 二重管理に注意
「予測時に前処理を書き直したらズレた」→ 原因は前処理の二重管理。TRANSFORM 句で一元化するのが正解。
🎯 埋め込み・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 に文脈として渡して回答生成
⚠️ RAG 周りのひっかけ
- 「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（組織間・コピー不要）
🎯 試験直前の総ざらい用。暗記すべき表と一問一答でセクション4を固めます。
🔑 暗記必須テーブル
Looker vs Looker Studio
| 観点 | Looker | Looker Studio |
|---|
| 位置づけ | エンタープライズBI | 軽量レポート/ダッシュボード |
|---|
| 料金 | 有償 | 基本無料 |
|---|
| モデル | LookML（全社共通の指標） | レポート単位 |
|---|
| キーワード | ガバナンス・一貫した指標・組込み分析 | 手軽・無料・アドホック |
|---|
BI高速化の打ち手
| 打ち手 | 役割 | 効くケース |
|---|
| BI Engine | インメモリ高速化 | BIダッシュボードの反復クエリ |
|---|
| マテリアライズドビュー | 集計の事前計算・増分自動更新 | 重い集計の繰り返し |
|---|
| パーティション | スキャン量（コスト）削減 | 日付等で絞れる |
|---|
| クラスタリング | フィルタ/集計の高速化 | 特定列で頻繁にフィルタ |
|---|
可視化/共有のセキュリティ
| 課題 | 解決策 |
|---|
| 見える行を制御 | 行レベルセキュリティ |
| 機密列を非表示（アクセス不可） | 列レベルセキュリティ（ポリシータグ） |
| 列は見せ値だけ隠す/集計可 | 動的データマスキング |
| PIIの検出・分類 | Cloud DLP |
| 元テーブル非公開で結果共有 | 承認済みビュー |
| 組織間でコピーせず共有 | Analytics Hub |
BigQuery ML モデル選択
| タスク | モデル |
|---|
| 数値予測（回帰） | 線形回帰 |
| 分類（Yes/No・カテゴリ） | ロジスティック回帰 |
| 表形式で高精度 | Boosted tree / Random forest |
| 非線形で複雑 | DNN |
| ラベルなしのグループ化 | k-means |
| 時系列の将来予測 | ARIMA_PLUS |
| レコメンド | 行列分解（Matrix factorization） |
| モデル選定を自動化 | AutoML Tables |
BQML vs Vertex AI
| 観点 | BigQuery ML | Vertex AI |
|---|
| 操作 | SQL | Python/SDK・パイプライン |
|---|
| データ移動 | 不要(BQ内完結) | 必要に応じて |
|---|
| 強み | 素早いモデル化 | 本格MLOps・カスタム・サービング |
|---|
| 特徴量管理 | TRANSFORM句 | Feature Store |
|---|
RAG関連のSQL関数（BigQuery）
| 関数 | 役割 |
|---|
ML.GENERATE_EMBEDDING | テキスト/画像を埋め込みベクトル化 |
CREATE VECTOR INDEX | ベクトル検索を高速化する索引 |
VECTOR_SEARCH | 近傍（意味的に類似）検索 |
ML.GENERATE_TEXT | LLMで生成（文脈を渡して回答） |
✅ 一問一答（確認テスト）
Q1. 全社で指標定義を統一し、ガバナンスを効かせたBIを構築したい。LookerとLooker Studioのどちら？
A. Looker（LookMLでセマンティックレイヤーを一元定義。Looker Studioはレポート単位で指標がばらつきやすい）
Q2. BigQueryのダッシュボードのレイテンシをサブ秒に下げたい。反復的なクエリが多い。使う機能は？
A. BI Engine（インメモリで反復クエリを高速化。透過的に効く）
Q3. 重い集計（GROUP BY）を何度も実行しており、毎回の再計算を避けたい。使う機能は？
A. マテリアライズドビュー（結果を事前計算・保存し、差分を自動更新）
Q4. クエリが遅くスキャンバイト数が膨大。日付で絞れるテーブル。まず何をする？
A. パーティショニング（日付列）＋パーティション列でのフィルタ。あわせて SELECT * をやめ列を絞る。頻繁にフィルタする列はクラスタリング。
Q5. 列は見せて集計はさせたいが、生のメールアドレスの値だけは隠したい。使うのは？
A. 動的データマスキング（列レベルセキュリティだと列ごとアクセス不可になり集計もできない。値だけ隠すならマスキング）
Q6. アナリストに集計結果だけ見せ、PIIを含む元テーブルには直接アクセスさせたくない。使うのは？
A. 承認済みビュー（Authorized View）。列はポリシータグ、行は行レベルセキュリティで併用。
Q7. 顧客を購買傾向でグループ分けしたい（正解ラベルなし）。BQMLのモデルは？
A. k-means（教師なしクラスタリング。ロジスティック回帰は教師ありの分類なので不適）
Q8. 季節性のある日次売上の将来3か月を予測したい。BQMLのモデルは？
A. ARIMA_PLUS（時系列予測。季節性・休日効果も自動考慮。線形回帰と迷わせるひっかけ）
Q9. データはBigQueryにあり、SQLだけで素早く解約予測モデルを作りたい。何を使う？
A. BigQuery ML（CREATE MODEL でロジスティック回帰。高精度ならBoosted tree。データ移動不要）
Q10. 学習時の前処理と予測時の前処理がずれてしまう（training-serving skew）。BQMLでの対策は？
A. TRANSFORM 句に前処理を記述。学習時の変換がモデルに保存され、ML.PREDICT 時に自動適用される。
Q11. LLMが社内固有の最新情報を知らず、誤った回答をする。再学習せずに精度を上げたい。手法は？
A. RAG（検索拡張生成）。関連文書を検索してLLMに文脈として渡す。BQなら ML.GENERATE_EMBEDDING → VECTOR_SEARCH → ML.GENERATE_TEXT。
Q12. キーワード一致ではなく「意味が似た」商品/文書を検索したい。何を使う？
A. 埋め込み（Embeddings）＋ベクトル検索（Vector Search）。意味の近さをベクトルの近さで測る。
Q13. 別組織（子会社）とBigQueryのデータを、コピーせず・同期ズレなしで共有したい。使うのは？
A. Analytics Hub（リスティングを公開 → 利用者はリンクされたデータセットで参照。クエリ課金は利用者側）
Q14. Cloud DLP の主な役割は？ アクセス制御も担う？
A. PIIの検出・分類・マスキング/トークン化が主役。アクセス制御そのものはIAM/ポリシータグ/行レベルセキュリティが担う（混同に注意）。
Q15. 低レイテンシで大量のベクトル検索をオンライン提供したい。BQのVECTOR_SEARCHかVertex AIか？
A. Vertex AI Vector Search（オンライン・大規模・低レイテンシに強い）。BQ内で分析的に行うなら BigQuery の VECTOR_SEARCH。
🎯 ひっかけ注意ポイント
❌ 混同しやすい論点
- Looker ⇔ Looker Studio：ガバナンス・全社指標なら Looker、手軽・無料なら Looker Studio
- BI Engine ⇔ マテリアライズドビュー：前者は「アクセス高速化」、後者は「計算の事前削減」。併用可
- 列レベルセキュリティ ⇔ 動的マスキング：前者は列ごとアクセス不可、後者は値だけ隠す（集計可）
- 時系列予測は ARIMA_PLUS（線形回帰と迷わせる）。ラベルなしグループ化は k-means（分類のロジスティック回帰ではない）
- Cloud DLP は検出・分類が主でアクセス制御ではない
- 共有はコピーしない：社内委譲＝承認済みビュー、組織間＝Analytics Hub。「エクスポートして配る」はアンチパターン
- パーティション＝コスト（スキャン）削減、クラスタリング＝速度。パーティション列を関数で加工するとプルーニングが効かない
- BQML ⇔ Vertex AI：SQLで完結・データ移動回避＝BQML、MLOps/カスタム/オンライン推論＝Vertex AI
📝 セルフチェック
- ☐ 暗記テーブル（Looker比較・BI高速化・セキュリティ・BQMLモデル・RAG関数）を白紙から再現できる
- ☐ 一問一答を全問即答できる
- ☐ BQMLのモデル選択の決定木を描ける
- ☐ 問題集セクション4 で80%以上取れた