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