正解：B

解説： Looker Studio（旧 Data Studio）は基本無料で、レポート単位で素早くダッシュボードを作成・共有できる軽量ツールです。「無料」「手早く」「全社ガバナンスは不要」という条件にすべて合致します。

• ❌ A：Looker は有償のエンタープライズBIで、LookML による全社共通の指標定義・ガバナンスが強みです。今回は不要な上にコストもかかるため過剰です。
• ❌ C：BI Engine は可視化ツールではなく、BigQuery のクエリをインメモリで高速化するアクセラレータです。単体でダッシュボードは作れません。
• ❌ D：Vertex AI Workbench はML開発用のマネージドノートブック環境で、BIダッシュボードの用途ではありません。

📖 関連：01_基礎.md の「① BIツール：Looker と Looker Studio」

正解：B

解説： Looker は LookML というセマンティックレイヤーで指標（measure/dimension）を一元的にモデル定義します。どのダッシュボードでも同じ計算ロジックが使われるため、全社で一貫した「信頼できる単一の真実」を提供でき、指標の食い違いを解消できます。

• ❌ A：Looker Studio はレポート単位で個別に接続・定義するため、まさに今回問題になっている「指標がばらつく」リスクを持ちます。
• ❌ C：Cloud DLP は機密データ（PII）の検出・分類・マスキングを行うセキュリティサービスで、指標の統一とは無関係です。
• ❌ D：スケジュールドクエリは集計テーブルを定期生成する仕組みで、可視化レイヤーの指標定義を統一するものではありません。

📖 関連：03_要点と暗記.md の「Looker vs Looker Studio」

正解：A

解説： BI Engine は BigQuery 専用のインメモリ分析アクセラレータで、よく使うデータをメモリにキャッシュして反復的なBIクエリをサブ秒で返します。クエリやモデルを書き換える必要はなく透過的に効くため、「反復クエリのレイテンシ低減」という要件に最適です。

• ❌ B：CSVエクスポートは鮮度が失われ、ガバナンスも崩れるアンチパターンです。可視化の高速化策ではありません。
• ❌ C：ロジスティック回帰はML（分類）のモデルで、ダッシュボードの高速化とは無関係です。
• ❌ D：承認済みビューはアクセス制御（権限委譲）の仕組みで、高速化が目的ではありません。

📖 関連：01_基礎.md の「② BI Engine：BigQuery のインメモリ高速化」

正解：C

解説： マテリアライズドビューは集計・結合の結果を事前計算して保存し、ベーステーブルの変更を増分（差分）で自動反映します。「重い集計を繰り返す」「再計算を避けたい」「最新性も保ちたい」という条件にぴったりで、計算量とコストを大きく削減できます。

• ❌ A：BI Engine は「アクセスの高速化（インメモリキャッシュ）」が役割で、集計の事前計算（計算量の削減）とは目的が違います。重い集計そのものを減らす本問では、マテビューが主役です（両者は併用も可能）。
• ❌ B：通常のビューは結果を保存せず、クエリのたびに元テーブルを全計算します。最新ではあっても遅く高いままで、問題は解決しません。
• ❌ D：SELECT * は列指向の利点を捨てスキャン量を増やすアンチパターンで、集計の事前計算にもなりません。

📖 関連：02_応用.md の「BI高速化の選択：BI Engine vs マテリアライズドビュー vs 事前集計」

正解：A と B

解説： 低速クエリの診断はまず「どこが重いか」を実行グラフや INFORMATION_SCHEMA.JOBS（スキャンバイト数・スロット時間・実行時間）で特定するのが定石です（A）。スキャン過多が原因なら、日付パーティションを設定してパーティション列でフィルタすればスキャン範囲を絞れます（B）。

• ❌ C：パーティション列を関数で加工してフィルタすると、パーティションプルーニングが効かなくなり、かえってフルスキャンになる典型的アンチパターンです。
• ❌ D：SELECT * は列指向ストレージの利点を捨て、不要な列までスキャンしてコストと時間を増やします。必要な列だけに絞るのが原則です。

📖 関連：02_応用.md の「低速クエリのトラブルシューティング（頻出）」

正解：C

解説： 列レベルセキュリティは Dataplex のタクソノミーで定義したポリシータグを列に付与し、権限のないユーザーはその列にアクセスできなくします（クエリに含めるとエラー）。「機密列をそもそも触らせない」という要件に合致します。

• ❌ A：動的データマスキングは列自体は見え、値だけが *** などに置き換わります。クエリは成功し集計もできるため、「アクセス不可・エラーにする」という今回の要件とは異なります。
• ❌ B：行レベルセキュリティは「どの行を見せるか」を制御するもので、特定の列を隠す用途ではありません。
• ❌ D：Cloud DLP は機密データの検出・分類が主な役割で、アクセス制御そのものは担いません。

📖 関連：02_応用.md の「列レベルセキュリティ vs 動的マスキング の違い」

正解：B

解説： 動的データマスキングは、列は見せたまま値だけを *** やハッシュに置き換えます。クエリは成功し列も存在として見えるため、「値は隠すが集計はさせたい」という要件にぴったりです。

• ❌ A：列レベルセキュリティは権限がないと列ごとアクセス不可（エラー）になります。「列は見せて集計はさせたい」本問では強すぎます。これが列レベルセキュリティとマスキングの頻出ひっかけです。
• ❌ C：承認済みビューで列を除外すると、その列の存在自体が見えなくなり、ドメイン別集計もできません。
• ❌ D：行レベルセキュリティは行の出し分けを制御するもので、列の値をマスクする用途ではありません。

📖 関連：03_要点と暗記.md の「可視化/共有のセキュリティ」

正解：B

解説： 「解約する/しない」は二値分類なのでロジスティック回帰が適切です。さらに「データはBQにある」「SQLだけで素早く」「データを外に出したくない」という条件は BigQuery ML の得意領域そのものです。CREATE MODEL でSQLだけで学習・予測が完結します。

• ❌ A：PyTorch のカスタム学習は Vertex AI の領域で、データのエクスポートが必要になり「SQLだけ・データを外に出さない」という要件に反します。SQLで済むのに Vertex AI を持ち出すのは頻出のひっかけです。
• ❌ C：k-means は教師なしクラスタリングで、正解ラベル（解約有無）がある分類問題には不適です。
• ❌ D：ARIMA_PLUS は時系列予測用で、二値分類のタスクには使いません。

📖 関連：02_応用.md の「BigQuery ML を選ぶか Vertex AI を選ぶか」

正解：A と B

解説： 時系列の将来予測（季節性・休日効果を自動考慮）には ARIMA_PLUS が最適です（A）。正解ラベルのないグループ化は教師なしの k-means が適切です（B）。

• ❌ C：時系列の将来予測を線形回帰でやるのは典型的なひっかけです。季節性のある時系列は ARIMA_PLUS を選びます。
• ❌ D：ロジスティック回帰は教師あり（正解ラベルが必要）の分類モデルです。ラベルのないグループ化には使えず、k-means が正解です。

📖 関連：02_応用.md の「BigQuery ML モデル選択の決定木（頻出）」

正解：B

解説： TRANSFORM 句に前処理を書くと、学習時の変換ロジックがモデル内に保存され、ML.PREDICT 時に同じ変換が自動適用されます。前処理を一元化できるため、学習と推論のズレ（training-serving skew）を構造的に防げます。

• ❌ A：手作業でのコピー運用はまさに二重管理であり、ズレの原因そのものです。恒久対策になりません。
• ❌ C：Feature Store は特徴量の一貫管理・再利用に有効ですが、「生データをそのまま保存する」だけでは前処理のズレは解決しません。また本問はBQML内で完結でき、TRANSFORM 句が最も直接的です。
• ❌ D：予測のたびの再学習はコストが高く、前処理ズレの原因に対する対策にもなっていません。

📖 関連：02_応用.md の「特徴量エンジニアリングと training-serving skew」

正解：A

解説： これは RAG（検索拡張生成）の典型シナリオです。BigQuery では ML.GENERATE_EMBEDDING で文書を埋め込みベクトル化し、質問を埋め込んで VECTOR_SEARCH で意味的に近い文書を取得、その文脈を ML.GENERATE_TEXT に渡して回答を生成します。再学習せずに社内知識を反映でき、根拠も提示できます。

• ❌ B：ロジスティック回帰は分類モデルで、文書検索＋生成による回答案作成には使えません。
• ❌ C：全文をプロンプトに貼り付けるのはコンテキスト長の制約・コスト・ノイズの面で非現実的です。関連文書だけを検索して渡す RAG が適切です。
• ❌ D：k-means のクラスタリングはグループ化であり、LLM による回答案生成の手段ではありません。

📖 関連：01_基礎.md の「④ 非構造化データの埋め込み（Embeddings）と RAG 準備」

正解：B

解説： 「意味的に似たものを探す」には埋め込み＋ベクトル（近傍）検索が必要です。さらに「低レイテンシのオンライン検索を本番サービング」という要件があるため、大規模・低レイテンシに強い Vertex AI Vector Search が最適です。BQ内で分析的に行うなら VECTOR_SEARCH ですが、オンライン本番サービングでは Vertex AI が有利です。

• ❌ A：LIKE はキーワードの文字列一致であり、意味的な類似は捉えられません。
• ❌ C：マテリアライズドビューは集計の事前計算であり、意味的類似検索とは無関係です。
• ❌ D：Cloud DLP は機密データの検出・分類が役割で、類似検索の手段ではありません。

📖 関連：02_応用.md の「埋め込み・Vector Search・RAG の設計」

正解：C

解説： Analytics Hub は組織の内外でデータをコピーせずに共有する仕組みです。提供者がリスティングを公開し、利用者（子会社）は自プロジェクトに「リンクされたデータセット」として参照できます。コピー不要で同期ズレがなく、クエリ課金は利用者側になります。組織間共有の定番解答です。

• ❌ A：CSVエクスポートはコピーであり、同期ズレ・コスト・ガバナンス劣化を招くアンチパターンです。
• ❌ B：承認済みビューは主に同一組織内での権限委譲（元テーブルを触らせず結果だけ見せる）の手段です。別組織とのコピーレス共有には Analytics Hub が適切です。
• ❌ D：スケジュールドクエリでのコピーは、まさに避けたい「複製」そのもので、同期ズレとコストが発生します。

📖 関連：02_応用.md の「共有方法の選択：コピーしないのが原則」

正解：A と B

解説： Cloud DLP はPII（氏名・クレカ番号など）の検出・分類・マスキング/トークン化を担い、保護すべき対象を可視化前・共有前に把握できます（A）。承認済みビューは元テーブルへのアクセス権を与えずに、必要な列・行・集計結果だけを共有できる定番手段です（B）。

• ❌ C：Cloud DLP は検出・分類が主役で、アクセス制御そのものは担いません。アクセス制御は IAM・ポリシータグ（列レベル）・行レベルセキュリティが担当します。この混同は頻出のひっかけです。
• ❌ D：PIIテーブルの丸ごとコピー配布は、同期ズレ・コスト・ガバナンス劣化に加え情報漏洩リスクを高める重大なアンチパターンです。コピーせずアクセスを制御するのが原則です。

📖 関連：02_応用.md の「可視化セキュリティの設計（行・列・マスキング）」「Cloud DLP は検出・分類が主」

正解：B

解説： 行レベルセキュリティは、ユーザーの属性に応じて「どの行を見せるか」を行単位のフィルタで制御します。1つの共通テーブル／レポートのまま、各セールスマネージャーに自地域の行だけを表示でき、レポートの複製も不要です。

• ❌ A：動的データマスキングは列の値を隠す仕組みで、行の出し分けはできません。
• ❌ C：列レベルセキュリティは特定の列へのアクセスを制御するもので、地域別に行を絞る用途には使えません。
• ❌ D：地域ごとにレポートを手動で複製するのは、まさに避けたい運用であり、保守コストと指標のばらつきを招きます。行レベルセキュリティで1つに統合するのが正解です。

📖 関連：02_応用.md の「可視化セキュリティの設計（行・列・マスキング）」