Q1. あなたは投資銀行で ML 研究者として働いており、Gemini という大規模言語モデル（LLM）を試験的に利用しています。
社内ユースケース向けにこのモデルをデプロイする予定で、推論時間を最小化しつつ、モデルの基盤インフラを完全に制御する必要があります。
このタスクにはどのサービング構成を使うべきですか。
A. Model Garden のワンクリックデプロイを使って、Vertex AI エンドポイントにモデルをデプロイする。
B. カスタム YAML マニフェストを自分で作成し、Google Kubernetes Engine（GKE）クラスタにモデルを手動でデプロイする。
C. カスタム推論コンテナを自分で作成し、Vertex AI エンドポイントにモデルを手動でデプロイする。
D. Model Garden のデプロイオプションを使って、Google Kubernetes Engine（GKE）クラスタにモデルをデプロイする。
回答
- B
-
基盤インフラを完全に制御しつつ推論レイテンシを最小化する要件では、カスタム YAML マニフェストで GKE クラスタへ手動デプロイする方法が最適です。
GKE ではノードの種類やアクセラレータ配置、スケジューリングまで細かく調整でき、推論の遅延を抑え込めます。
Vertex AI のワンクリックデプロイ（選択肢 A）や Model Garden 経由のデプロイ（選択肢 D）は手軽ですが、インフラ制御の自由度が低くなります。
Vertex AI のカスタム推論コンテナ（選択肢 C）は一定のカスタマイズが可能なものの、GKE ほど基盤全体を掌握できません。
最大の制御と低レイテンシを両立できる B が正解です。
Google Kubernetes Engine（GKE）ドキュメント
Q2. あなたはストリーミング音楽サービスを運営する組織で働いています。
ユーザーの最近の再生履歴に基づいて「次の曲」を推薦する、本番稼働中のカスタムモデルがあります。
このモデルは Vertex AI エンドポイントにデプロイされています。
最近、同じモデルを新しいデータで再トレーニングし、オフラインのテスト結果は良好でした。
複雑さを最小限に抑えつつ、新しいモデルを本番環境でテストしたいと考えています。
どうすべきですか。
A. 新しいモデル用に新規の Vertex AI エンドポイントを作成してデプロイする。本番トラフィックの 5% をランダムに新エンドポイントへ送るサービスを構築する。再生時間などのエンドユーザー指標を監視し、モデル間で指標が改善すれば徐々に新エンドポイントへのトラフィック割合を増やす。
B. 受信した予測リクエストを BigQuery に取り込む。Vertex AI Experiments で実験を作成し、取得したデータで両モデルのバッチ予測を実行する。ユーザーが選択した曲を使って両モデルの性能を並べて比較し、新モデルの指標が優れていれば本番に投入する。
C. 既存の Vertex AI エンドポイントに新しいモデルをデプロイする。トラフィック分割（traffic splitting）を使って本番トラフィックの 5% を新モデルへ送る。再生時間などのエンドユーザー指標を監視し、モデル間で指標が改善すれば徐々に新モデルへのトラフィック割合を増やす。
D. 既存の Vertex AI エンドポイントにモデルモニタリングジョブを構成する。予測ドリフトを検知するよう設定してアラートのしきい値を定める。エンドポイント上のモデルを旧モデルから新モデルへ更新し、予測ドリフトのアラートが出たら旧モデルへ戻す。
回答
- C
-
トラフィック分割（traffic splitting）は、同一の Vertex AI エンドポイント内で複数のモデルやバージョンに予測リクエストを配分できる機能です。
既存エンドポイントに新モデルをデプロイし、トラフィックの 5% だけを新モデルに流せるため、新規エンドポイントや別サービスを作らずに本番でカナリアテストが行えます。
これにより複雑さを最小化しつつ、再生時間などの指標を見ながら段階的に移行できます。
選択肢 A は新規エンドポイントと振り分けサービスの構築が必要で複雑です。
B はオフライン評価にとどまり本番検証になりません。
D は一括切り替えでリスクが高く、段階的テストになりません。
Vertex AI: モデルのデプロイとトラフィック分割
Q3. 組織から、生成 AI ユースケース向けに広く利用可能なさまざまな ML モデルを比較するよう依頼されています。
比較対象のモデルは Google Cloud 上でも利用できます。
各チームから、それぞれのユースケースやタスクに合わせて厳選された社内ベンチマークデータセットを受け取っています。
推奨事項をまとめた包括的なレポートを提出する必要があります。
最も効率的な方法でモデルを評価したいと考えています。
どうすべきですか。
A. Model Garden を使って候補モデルを Vertex AI エンドポイントにデプロイする。生成 AI 評価サービス（Gen AI Evaluation Service）API を使って、各モデルの性能を社内ベンチマークデータセットで評価する。実験結果に基づいて最良のモデルを報告する。
B. オープンソースの LLM リーダーボードから生データを BigQuery データセットにストリーミングする。データを社内の Looker Studio ダッシュボードに送る。社内ベンチマークに似たオープンソースのデータセットで各モデルの性能を評価し、ダッシュボードの指標に基づいて最良のモデルを報告する。
C. Model Garden のモデルカードを確認し、社内ベンチマークに似たオープンソースデータセットでの各モデルの性能を評価する。分析結果に基づいて最良のモデルを報告する。
D. 各モデルの提供元サイトからモデルの重みをダウンロードする。候補モデルを Vertex AI エンドポイントにデプロイする推論スクリプトを書く。Vertex AI Experiments を使い、社内ベンチマークデータセットで全モデルを比較する評価スクリプトを書く。実験結果に基づいて最良のモデルを報告する。
回答
- A
-
Vertex AI の生成 AI 評価サービス（Gen AI Evaluation Service）は、独自データセットを用いて複数の基盤モデルや LLM を自動評価・並列比較するために設計された機能です。
Model Garden と統合された評価サービス API を使えば、評価スクリプトの自作や複雑な実験管理が不要になり、最も効率的に比較できます。
設問は「厳選された社内ベンチマークデータセット」の利用を重視しているため、オープンソースデータで代用する B と C は要件を満たしません。
D は重みのダウンロードやスクリプト作成が必要で手間が大きく、効率性の要件に反します。
Vertex AI: 生成 AI 評価サービスの概要
Q4. あなたは会社のリード ML エンジニアとして、スキャンした顧客フォームをデジタル化する ML モデルの構築を担当しています。
スキャン画像をテキストに変換して Cloud Storage に保存する TensorFlow モデルを開発済みです。
手作業をできるだけ介さずに、毎日終業時に集計されたデータへこの ML モデルを適用する必要があります。
どうすべきですか。
A. AI Platform（現 Vertex AI）のバッチ予測機能を使う。
B. Compute Engine 上に予測用のサービングパイプラインを作成する。
C. 新しいデータポイントが取り込まれるたびに Cloud Functions で予測を行う。
D. AI Platform（現 Vertex AI）にモデルをデプロイし、オンライン推論用のバージョンを作成する。
回答
- A
-
バッチ予測は、大量のデータに対してまとめて予測を実行する処理で、リアルタイム性が不要で定期的に処理できるケースに適しています。
毎日終業時にまとまったフォームをデジタル化する用途では、Cloud Storage 上の入力データに対してバッチ予測ジョブを投入する A が最適です。
結果も Cloud Storage に出力され、手作業を最小化できスケーリングも自動です。
B や C、D はリアルタイム／オンライン向けで、日次バッチ処理には過剰か不適切です。
なお AI Platform は現在 Vertex AI に統合されていますが、バッチ予測という考え方と正解は現行でも有効です。
Vertex AI: バッチ予測の取得
Q5. あなたのモデルの一つは、サードパーティのデータブローカーから提供されるデータでトレーニングされています。
このデータブローカーは、データのフォーマット変更を確実には通知してくれません。
こうした問題に対して、モデルのトレーニングパイプラインをより堅牢にしたいと考えています。
どうすべきですか。
A. TensorFlow Data Validation（TFDV）を使ってスキーマの異常を検出しフラグを立てる。
B. TensorFlow Transform を使い、データを期待される分布に正規化し、スキーマに合わない値を 0 に置き換える前処理コンポーネントを作成する。
C. tf.math を使ってデータを分析し、要約統計量を計算して統計的な異常にフラグを立てる。
D. モデルトレーニングの冒頭でカスタムの TensorFlow 関数を使い、既知のフォーマットエラーを検出しフラグを立てる。
回答
- A
-
TensorFlow Data Validation（TFDV）は、機械学習のデータを理解・検証・監視するためのライブラリです。
欠損特徴量・新規特徴量・データ型の相違といったスキーマの異常を自動で検出して報告できるため、フォーマット変更に対するパイプラインの堅牢化に最適です。
記述統計や可視化も生成でき、トレーニングパイプラインに組み込めばデータ品質を継続的に担保できます。
B は値を強制変換してしまい問題を隠蔽します。
C や D はカスタム実装が必要で網羅性に欠け、スキーマ検証としては TFDV に劣ります。
TensorFlow Data Validation（TFDV）ガイド
Q6. あなたは AI Platform（現 Vertex AI）を使って、CT スキャンの画像セグメンテーション向け ML モデルを開発しています。
最新の研究論文に基づいてモデルアーキテクチャを頻繁に更新し、同じデータセットで再トレーニングして性能をベンチマークする必要があります。
コードのバージョン管理を維持しながら、計算コストと手作業を最小化したいと考えています。
どうすべきですか。
A. Cloud Functions を使って Cloud Storage 上のコード変更を検知し、再トレーニングジョブをトリガーする。
B. コードを更新するたびに gcloud コマンドラインツールで AI Platform にトレーニングジョブを送信する。
C. Cloud Build を Cloud Source Repositories と連携させ、リポジトリへの新しいコードのプッシュで再トレーニングをトリガーする。
D. Cloud Composer で自動ワークフローを作成し、毎日実行してセンサーで Cloud Storage 上のコード変更を監視する。
回答
- C
-
コードのバージョン管理を保ちながら計算コストと手作業を最小化するには、ソースリポジトリと CI を連携させ、コードプッシュを契機に再トレーニングを自動起動する構成が適します。
Cloud Build をリポジトリと連携させ、プッシュをトリガーに再トレーニングを走らせる C が、バージョン管理と自動化を同時に満たす最適解です。
A は Storage 監視で変更検知が粗く、B は毎回の手動実行が必要です。
D の日次スケジュールはコード変更と無関係に走り無駄が生じます。
なお Cloud Source Repositories は新規利用の受付が終了していますが、Cloud Build をコードプッシュでトリガーする考え方自体は現行でも有効です。
Cloud Build: ビルドトリガーの作成と管理
Q7. あなたは売上予測を担当する本番システムを構築・運用しています。
本番モデルは市場の変化に追随し続ける必要があるため、モデルの精度が極めて重要です。
本番へのデプロイ以降モデル自体は変更していないにもかかわらず、モデルの精度が徐々に低下しています。
この精度の継続的な低下を引き起こしている最も可能性の高い問題は何ですか。
A. データ品質の低さ
B. モデルの再トレーニング不足
C. 情報を捉えるにはモデルの層が少なすぎる
D. トレーニング・評価・検証・テストにおけるデータ分割比率の誤り
回答
- B
-
モデルの再トレーニングは、新しいデータでモデルを更新し、性能と精度を維持するプロセスです。
モデルを変更していないのに精度が徐々に低下する場合、市場などデータの分布が時間とともに変化するモデルドリフトが原因であり、対策は定期的な再トレーニングです。
A のデータ品質や C の層の不足、D の分割比率の誤りは、デプロイ当初から一定の誤差を生む要因であり、時間経過に伴う「継続的な劣化」の説明にはなりません。
環境変化に追随するには再トレーニングが不可欠なので B が正解です。
Vertex AI Model Monitoring の概要
Q8. あなたは、複数の scikit-learn モデルを連鎖させて自社製品の最適価格を予測するアプリケーションを開発しました。
ワークフローのロジックは図のとおりです。
チームメンバーは各モデルを他のソリューションのワークフローでも個別に利用しています。
個々のモデルとワークフロー全体の双方でバージョン管理を確保しつつ、このワークフローをデプロイしたいと考えています。
アプリケーションはゼロまでスケールダウンできる必要があります。
計算リソースの利用量と、この構成の管理にかかる手作業を最小化したいと考えています。
どうすべきですか。
A. 各モデルを Vertex AI Endpoints のエンドポイントとして公開する。ワークフローを統合するためのカスタムコンテナのエンドポイントを作成する。
B. 各モデルの個別ファイルを読み込むワークフロー用のカスタムコンテナのエンドポイントを作成する。各モデルのバージョンは BigQuery で管理する。
C. 各モデルを Vertex AI Endpoints のエンドポイントとして公開する。ワークフローの統合には Cloud Run を使う。
D. 各モデルの個別ファイルを Cloud Run に読み込む。Cloud Run でワークフローを統合し、各モデルのバージョンは BigQuery で管理する。
回答
- C
-
複数モデルのワークフローを、バージョン管理と低コストを両立してデプロイするには、各モデルを Vertex AI Endpoints で公開しつつ、統合層を軽量なサーバーレスで実装するのが効率的です。
各モデルを Vertex AI Endpoints で個別に公開すればバージョン管理と再利用が容易になり、ゼロスケール可能な Cloud Run でワークフローを統合すれば未使用時のリソースを最小化できます。
A はカスタムコンテナで統合層を自作する必要があり運用負荷が高く、B と D はモデルファイルを直接読み込むためモデル単位のバージョン管理と再利用性が損なわれます。
Cloud Run の概要
Q9. あなたは、小売店舗のレジ周辺のライブ映像を撮影している会社で働いています。
このライブ映像を使い、サービスを待っている顧客の人数をほぼリアルタイムで検出するモデルを構築する必要があります。
できるだけ短時間かつ最小限の労力でソリューションを実装したいと考えています。
どのようにモデルを構築すべきですか。
A. Vertex AI Vision の Occupancy Analytics（占有分析）モデルを使う。
B. Vertex AI Vision の Person/vehicle detector（人／車両検出）モデルを使う。
C. Vertex AutoML を使い、アノテーション付きデータセットで AutoML の物体検出モデルをトレーニングする。
D. Vertex AutoML を使い、アノテーション付きデータセットで Seq2Seq+ 物体検出モデルをトレーニングする。
回答
- A
-
Vertex AI Vision の Occupancy Analytics（占有分析）モデルは、映像フレーム内の人や車両をカウントするために用意された学習済みモデルです。
アクティブゾーンでの計数やライン通過カウント、滞留検出などを標準機能で備えており、待機顧客数をほぼリアルタイムで検出する用途に最小の労力で対応できます。
C や D は自前でのアノテーションとトレーニングが必要で手間がかかり、B は人／車両の検出に特化した別モデルで占有分析ほど直接的ではありません。
なお Vertex AI Vision は現在 Agent Platform Vision に改称されていますが、当該モデルと正解は現行でも有効です。
Vertex AI Vision（現 Agent Platform Vision）
Q10. あなたは大規模なデータセットを使って、自社向けのカスタム言語モデルをトレーニングしています。
Vertex AI で Reduction Server 戦略を使う予定です。
分散トレーニングジョブのワーカープールを構成する必要があります。
どうすべきですか。
A. 最初の 2 つのワーカープールのマシンに GPU を持たせ、トレーニングコードを実行するコンテナイメージを使う。3 つ目のワーカープールにも GPU を持たせ、reductionserver のコンテナイメージを使う。
B. 最初の 2 つのワーカープールのマシンに GPU を持たせ、トレーニングコードを実行するコンテナイメージを使う。3 つ目のワーカープールはアクセラレータなしで reductionserver のコンテナイメージを使い、帯域幅を重視したマシンタイプを選ぶ。
C. 最初の 2 つのワーカープールのマシンに TPU を持たせ、トレーニングコードを実行するコンテナイメージを使う。3 つ目のワーカープールはアクセラレータなしで、reductionserver のコンテナイメージをアクセラレータなしで使い、帯域幅を重視したマシンタイプを選ぶ。
D. 最初の 2 つのプールのマシンに TPU を持たせ、トレーニングコードを実行するコンテナイメージを使う。3 つ目のプールにも TPU を持たせ、reductionserver のコンテナイメージを使う。
回答
- B
-
Reduction Server は、専用のリデューサー群でワーカーからの勾配を集約する、GPU 向けの高速な all-reduce の仕組みです。
リデューサーは GPU より安価な軽量 CPU VM で動かすのが前提のため、3 つ目のワーカープールはアクセラレータなしで帯域幅を重視したマシンタイプを選ぶのが正しい構成です。
Reduction Server は TPU をサポートしないため、C や D のように TPU を用いる構成は不適切です。
A はリデューサー用プールに不要な GPU を割り当ててコストが増えるため誤りです。
ワーカー 2 プールは GPU、リデューサープールは CPU＋高帯域という B が正解です。
Vertex AI: 分散トレーニング（Reduction Server）