模擬問題集一覧

GCP-PMLE 模擬問題集（練習問題）

Professional Machine Learning Engineer 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

GCP-PMLE（Professional Machine Learning Engineer）の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

GCP-PMLE の出題範囲（カバーしている分野）

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はGCP-PMLE の学習ガイドにまとめています。

GCP-PMLE の無料練習問題（15 問・解説つき）

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1プロトタイプから ML モデルへのスケーリングプロトタイプから ML モデルへのスケーリング
問題
あなたは、Gemini Enterprise Agent Platform で 1,750 億（175B）パラメータの大規模言語モデル（LLM）のトレーニングを最適化しています。このジョブ用に 32 チップの TPU v5p Pod スライスをプロビジョニングしました。最初は標準的なデータ並列でトレーニングを実行しましたが、ジョブはすぐにメモリ不足（OOM）エラーで失敗しました。メモリの問題を解決し、トレーニングのレイテンシ（所要時間）を最小限に抑えるトレーニング戦略を実装する必要があります。どうすればよいですか？

選択肢と解説

  • 1
    モデルの重みをホスト CPU メモリに保存するパラメータ サーバー アーキテクチャを使用するようにトレーニングを構成する。
  • 2
    勾配チェックポイントを有効にし、データ並列戦略を引き続き使用する。
  • ✓
    モデル パラメータとオプティマイザの状態をシャーディングするようにトレーニングを構成し、データ並列戦略を引き続き使用する。
  • 4
    TPU Pod スライスをスケールアップしてより多くのチップを含め、データ並列戦略を引き続き使用する。

解説

【正解】C

【0からの解説】
①前提知識
・標準的なデータ並列では、各アクセラレータ（TPU チップ）がモデル全体（パラメータ・勾配・オプティマイザの状態）の完全なコピーを持ち、異なるデータのミニバッチを処理して勾配を集約します。つまり「モデル全体が 1 チップのメモリに収まること」が前提です。
・175B パラメータのモデルは、bf16（2 バイト）で保存してもパラメータだけで約 350 GB、Adam オプティマイザの状態（fp32 のマスター重みやモーメント）や勾配を含めると 2 TB を超えます。TPU v5p は 1 チップあたり約 95 GB の HBM しか持たないため、1 チップにモデル全体を載せる標準データ並列では必ず OOM になります。
・パラメータとオプティマイザの状態（および勾配）を全チップに分割（シャーディング）して持たせる手法として、ZeRO / FSDP（Fully Sharded Data Parallel）や、JAX の GSPMD / pjit による自動シャーディングがあります。データ並列の枠組みを保ったまま、各チップのメモリ使用量をおよそ「全体 ÷ チップ数」に削減でき、32 チップ合計の HBM（約 3 TB）を有効活用できます。

②要件と制約語の整理
・原因: 標準データ並列で各チップにモデル全体の複製を置いているため OOM。
・「メモリの問題を解決」し、かつ「トレーニングのレイテンシを最小限に」。

③正解がどう満たすか
パラメータとオプティマイザの状態をシャーディングすれば、モデルの状態が 32 チップに分散されて各チップのメモリ消費が大きく下がり、OOM が解消します。計算中に必要な部分だけを TPU の高速なチップ間相互接続（ICI）で集めて使うため、通信オーバーヘッドを抑えつつデータ並列のスループットを維持でき、レイテンシも最小限にできます。

【誤りの選択肢】
A：パラメータ サーバーで重みをホスト CPU メモリに置くと、ステップごとに CPU と TPU の間で巨大な重みを転送する必要があり、HBM 内の処理やチップ間相互接続に比べて大幅に遅くなります。レイテンシ最小の要件に反し、大規模 LLM の TPU トレーニングで推奨される構成でもありません。
B：勾配チェックポイント（アクティベーションの再計算）は、順伝播の中間アクティベーションのメモリを削減する手法です。今回の問題はパラメータとオプティマイザの状態そのものが 1 チップに収まらないことなので、アクティベーションを減らしても OOM は解消しません。さらに再計算によって計算時間が増えます。
D：データ並列のままチップ数を増やしても、各チップが持つのはモデル全体の完全なコピーのままなので、1 チップあたりのメモリ使用量は減りません。コストだけが増えて OOM は解決しません。

【参考】
分散トレーニング
TPU v5p
TPU スライスで JAX コードを実行する
この問題のページを開く →
問題 2このモデルと必要なロジックをどのようにデプロイすべきですか？モデルのサービングとスケーリング
問題
あなたはメディア企業に勤務しています。ライブ音声ストリームの文字起こしと話者分離（ダイアライゼーション、話者識別）をほぼリアルタイムで行うソリューションを開発しています。PyTorch フレームワーク上に構築された最適化済みの WhisperX モデルを使用しており、このモデルは Hugging Face Hub から取得した複数のライブラリと重みを使用しています。デプロイには、モデル推論の直後に実行される、話者分離やアライメント補正を含む独自の Python 後処理ロジックを含める必要があります。ソリューションは効率的かつスケーラブルで、高スループットに対応し、サービングのレイテンシを最小限に抑える必要があります。このモデルと必要なロジックをどのようにデプロイすべきですか？

選択肢と解説

  • 1
    WhisperX モデルのアーティファクトを、GPU を構成したビルド済み PyTorch サービング コンテナを使用して Agent Platform エンドポイントにデプロイする。カスタムの後処理スクリプトは、エンドポイントの予測出力を受け取って最終的な話者分離を行う Cloud Run functions の関数でホストする。
  • 2
    セルフマネージドの Google Kubernetes Engine（GKE）クラスタを使用してデプロイする。モデルとロジックをコンテナにパッケージ化し、クラスタの Horizontal Pod Autoscaler（HPA）を構成してスループットを管理する。
  • ✓
    WhisperX モデルのアーティファクト、特定の Python 後処理スクリプト、必要な依存関係（Hugging Face ライブラリを含む）を単一のカスタム サービング コンテナ イメージにパッケージ化する。このカスタム イメージを GPU 対応の Agent Platform エンドポイントにデプロイする。
  • 4
    Model Garden で WhisperX モデルを探し、「ワンクリック デプロイ」機能を使用して Agent Platform エンドポイントにデプロイする。出力を Dataflow パイプラインにルーティングし、カスタムの DoFn 関数で後処理とロギングを行う。

解説

【正解】C

【0からの解説】
①前提知識
・Agent Platform Inference（旧 Vertex AI Prediction）では、モデルをエンドポイントにデプロイしてオンライン推論を提供します。デプロイ方法には、TensorFlow / PyTorch / scikit-learn / XGBoost などの標準的な形式向けの「ビルド済みコンテナ」と、任意のコード・ライブラリ・前処理 / 後処理を含められる「カスタム コンテナ」があります。
・カスタム コンテナは、HTTP サーバーとして推論リクエスト / ヘルスチェックに応答するという要件さえ満たせば、内部で任意の処理（推論 + 後処理）を実行できます。GPU の割り当てや、マネージドのオートスケーリング（最小 / 最大レプリカ数）もエンドポイント側で設定できます。
・WhisperX は Whisper による文字起こしに、単語レベルのアライメントや pyannote などによる話者分離を組み合わせたオープンソースのパイプラインで、多数の Python 依存関係を持ちます。

②要件と制約語の整理
・独自の Python 後処理（話者分離・アライメント補正）を「推論の直後に」実行する。
・Hugging Face のライブラリや重みなど特殊な依存関係がある。
・効率的、スケーラブル、高スループット、「サービングのレイテンシを最小限に」。

③正解がどう満たすか
モデル・後処理スクリプト・依存関係を 1 つのカスタム サービング コンテナにまとめれば、推論と後処理が同じコンテナ（同じ GPU マシン）内のメモリ上で連続して実行され、サービス間のネットワーク往復がなくなるためレイテンシが最小になります。デプロイ先は GPU 対応の Agent Platform エンドポイントなので、マネージドのオートスケーリングで高スループットにも対応でき、インフラ運用の負担もありません。

【誤りの選択肢】
A：ビルド済み PyTorch コンテナは標準的なモデル提供を前提としており、WhisperX 固有の依存関係や独自ロジックをそのまま組み込むには向きません。さらに後処理を別サービスの Cloud Run functions に分けると、推論結果をネットワーク越しに受け渡す追加のホップが発生し、レイテンシが増え、構成要素も増えて管理が複雑になります。
B：GKE でも動作はしますが、「セルフマネージド」のクラスタではノード、GPU ドライバ、スケーリング、アップグレードなどの運用をすべて自分で担う必要があります。マネージドの Agent Platform エンドポイントで同等のスケーラビリティが得られるため、効率性の面で劣ります。
D：最適化済みの独自 WhisperX 構成が Model Garden のワンクリック デプロイでそのまま提供されている前提は成り立たず、独自の後処理も組み込めません。また、推論結果を Dataflow パイプラインに流して後処理する構成は、追加のデータ転送とパイプライン処理の遅延を生み、「推論の直後に実行」「レイテンシ最小」の要件に反します。

【参考】
推論にカスタム コンテナを使用する
推論用のカスタム コンテナの要件
この問題のページを開く →
問題 3ML パイプラインの自動化とオーケストレーションML パイプラインの自動化とオーケストレーション
問題
あなたは不正検出モデルの ML ワークフローを管理しています。データ処理とモデル トレーニングのソースコードはバージョン管理リポジトリに保存されています。リポジトリでコードが更新されたときに、ユニットテストを自動的に実行し、Agent Platform Pipelines で新しいトレーニング実行を開始する継続的トレーニング（CT）パイプラインを実装する必要があります。このプロセスのオーケストレーションには、フルマネージド サービスを使用したいと考えています。どうすればよいですか？

選択肢と解説

  • 1
    リポジトリへのコミットによってトリガーされる Cloud Run functions の関数を作成する。この関数でユニットテストを実行し、カスタム トレーニング ジョブを開始し、デプロイ前に Model Monitoring を使用して新しいモデルのパフォーマンスを検証する。
  • 2
    リポジトリの変更を監視する Cloud Workflow を定義する。Agent Platform Pipelines 上でそのワークフローを構成してユニットテストをオーケストレーションし、実行する。デプロイ前にモデル評価コンポーネントを使用して新しいモデルのパフォーマンスを検証する。
  • 3
    Agent Platform Pipelines がリポジトリの更新をポーリングするように構成する。パイプラインに条件付きステップを追加し、デプロイ前に Model Monitoring を使用して新しいモデルのパフォーマンスを検証する。
  • ✓
    リポジトリに関連付けた Cloud Build トリガーを作成する。ユニットテストを実行し、Agent Platform Pipelines のジョブをトリガーするビルド構成ファイルを定義する。デプロイ前にモデル評価コンポーネントを使用してモデルのパフォーマンスを検証する。

解説

【正解】D

【0からの解説】
①前提知識
・継続的トレーニング（CT）は、コードやデータの変化をきっかけにモデルの再トレーニングを自動実行する MLOps の仕組みです。Google の MLOps アーキテクチャ ガイドでは、コードの変更 → CI（ユニットテスト、パイプラインのビルド）→ パイプライン実行（CT）→ 評価・検証 → デプロイ、という流れを推奨しています。
・Cloud Build はフルマネージドの CI/CD サービスで、Cloud Build トリガーを使うと GitHub / Cloud Source Repositories / Bitbucket などのリポジトリへの push やプルリクエストを検知してビルド構成ファイル（cloudbuild.yaml）のステップを自動実行できます。
・Agent Platform Pipelines（旧 Vertex AI Pipelines）は ML ワークフローをサーバーレスで実行するサービスで、Google Cloud Pipeline Components のモデル評価コンポーネントを使うと、新モデルの評価指標を計算し、条件分岐でデプロイ可否を判定できます。

②要件と制約語の整理
・トリガー: リポジトリのコード更新。
・処理: ユニットテストの自動実行 → Agent Platform Pipelines でトレーニング実行。
・「フルマネージド サービスでオーケストレーション」。
・新モデルはデプロイ前に性能を検証する。

③正解がどう満たすか
Cloud Build トリガーをリポジトリに関連付ければ、コミットを契機にビルド構成ファイルの各ステップ（ユニットテスト → パイプラインのコンパイル → Agent Platform Pipelines のジョブ送信）がフルマネージドに実行されます。パイプライン内ではモデル評価コンポーネントで新モデルの指標を算出し、基準を満たした場合のみデプロイする、という Google 推奨の CI/CD/CT 構成そのものです。

【誤りの選択肢】
A：Cloud Run functions（旧 Cloud Functions）でユニットテストやトレーニング起動を自前実装するのは、CI 用途として設計された Cloud Build に比べてコードと運用が増えます（実行時間の制約もあります）。さらに Model Monitoring は本番エンドポイントの入力特徴量のスキューやドリフトを監視する機能であり、デプロイ前に新モデルの精度などのパフォーマンスを検証するものではありません。
B：Cloud Workflows には「リポジトリの変更を監視する」トリガー機能はありません。また、Cloud Workflows を Agent Platform Pipelines の上で構成する、という仕組みも存在せず、構成として成り立ちません。
C：Agent Platform Pipelines にはリポジトリをポーリングする機能はありません（パイプラインは API 呼び出しやスケジューラで起動します）。加えて、A と同様に Model Monitoring はデプロイ前のモデル性能検証には使いません。

【参考】
Cloud Build トリガー
TensorFlow Extended、Agent Platform Pipelines、Cloud Build を使用した MLOps のアーキテクチャ
MLOps: ML における継続的デリバリーと自動化のパイプライン
この問題のページを開く →
問題 4チーム内外で協働したデータとモデルの管理チーム内外で協働したデータとモデルの管理
問題
あなたは国際的な銀行に勤務しています。あなたのチームは、複雑な財務レポートを要約する生成 AI アプリケーションを開発しています。生成された要約の品質を、ソリューションの以前のバージョンと比較して評価・定量化するための、自動化されたスケーラブルなソリューションを実装する必要があります。どうすればよいですか？

選択肢と解説

  • 1
    Model Monitoring を使用して、出力トークン長の予測ドリフトを追跡する。
  • ✓
    Agent Platform で自動サイドバイサイド（AutoSxS）評価ジョブを実行し、ソリューションの新しいバージョンと以前のバージョンの出力を比較する。
  • 3
    両方のバージョンのソリューションをデプロイし、A/B テストを使用して本番トラフィックの一部を新しいバージョンに、残りのトラフィックを以前のバージョンにルーティングする。ユーザーのクリック率を比較する。
  • 4
    Agent Platform で評価ジョブを実行し、BLEU スコアを計算して新しいバージョンと以前のバージョンを比較する。

解説

【正解】B

【0からの解説】
①前提知識
・AutoSxS（Automatic Side-by-Side）は、Agent Platform（旧 Vertex AI）のパイプライン ベースのペアワイズ（2 つ比較）評価ツールです。同じプロンプトに対する 2 つのモデル（または事前生成済みの予測）の出力を、「オートレーター」と呼ばれる評価用 LLM（LLM-as-a-judge）が比較し、どちらが優れているかを判定します。
・要約タスクでは「指示への従い方」「根拠性（グラウンディング）」「網羅性」「簡潔さ」といった定義済みの基準で判定し、例ごとの判定・信頼度・説明と、全体の勝率（win rate）を出力します。人手の選好データを与えれば、オートレーターと人間の一致度も算出できます。
・現行名との対応: AutoSxS は「評価パイプライン サービス」上で動くペアワイズ評価ツールで、現在もドキュメントに「AutoSxS パイプラインを実行する」として残っています。ただし AutoSxS のページ自体に「最新のペアワイズ モデルベース評価機能は『評価指標を定義する』を参照」という案内があり、同じ「2 つの出力を判定用 LLM で比べ、どちらが良いかと勝率を出す」機能は、現在は Gen AI Evaluation Service（生成 AI 評価サービス）側に集約されつつあります。Gen AI Evaluation Service では、以前のバージョン（ベースライン）と新しいバージョン（候補）の応答を同じデータセットで生成してまとめて評価にかけると、横並び（サイドバイサイド）の比較レポートと勝率・引き分け率が得られます。SDK の評価モジュールにも、判定モデル（Gemini）が候補とベースラインのどちらが優れているかを選び、理由の説明と勝率を出す「ペアワイズ指標」があります。つまり「AutoSxS ＝ 評価パイプラインで実行する従来形のペアワイズ評価」「Gen AI Evaluation Service のペアワイズ評価（複数候補の比較）＝ その機能の現行の受け皿」と対応づけて覚えておけば、試験でどちらの名前で問われても正解を選べます。

②要件と制約語の整理
・評価対象: 生成された「要約の品質」。
・比較対象: ソリューションの「以前のバージョン」。
・「自動化」「スケーラブル」「定量化」→ 人手評価ではなく、大量の例を自動で採点して数値化できる方法。

③正解がどう満たすか
AutoSxS で新旧バージョンの出力を同じ評価データセットに対して並べて比較すれば、オートレーターが要約の品質基準に沿って例ごとにどちらが優れているかを判定し、勝率として定量化します。パイプラインとして実行されるため自動化・スケールが容易で、判定理由の説明も得られます。現行の環境で同じことを行う場合は、Gen AI Evaluation Service のペアワイズ評価で新旧バージョンを比べても、考え方は同じです。

【誤りの選択肢】
A：Model Monitoring は本番の入力データ分布のスキューやドリフトを監視する機能です。出力トークン長の変化を追っても、要約が正確か・網羅的かといった「品質」は評価できず、新旧バージョンの比較にもなりません。
C：A/B テストは本番で実際のユーザー反応を測る手段ですが、クリック率は要約の品質を直接表す指標ではありません。また、本番デプロイとトラフィックの蓄積が必要で、品質の悪い要約を顧客に見せるリスクもあり、開発段階での自動評価として適切ではありません。
D：BLEU は生成文と参照文（正解テキスト）の n-gram の一致度を測る指標で、主に機械翻訳向けです。要約の意味的な品質（正確さ・網羅性など）をうまく捉えられず、参照要約の用意も必要です。また BLEU は各バージョンを参照文と比べるだけで、2 つの出力を直接比較して「どちらが良いか」を判定するものではありません。

【参考】
AutoSxS パイプラインを実行してペアワイズ モデルベースの評価を行う
Gen AI Evaluation Service の概要
評価結果を表示して解釈する
この問題のページを開く →
問題 5ローコードの AI ソリューションの設計ローコードの AI ソリューションの設計
問題
あなたは Gemini を使用する会話型アプリケーションをデプロイしました。最近、モデルのレスポンスの冗長さ（詳しさ）と正確さについて、数千行に及ぶユーザー フィードバックを収集しました。フィードバックによると、レスポンスは事実としては正しいものの、ユーザーは質問の種類に応じて異なるレベルの詳しさを求めていることがわかりました。ユーザーの期待により沿ったレスポンスを返すようにモデルを調整する必要があります。スケーラブルなソリューションを使用し、アプリケーションのメンテナンスを最小限に抑えたいと考えています。どうすればよいですか？

選択肢と解説

  • 1
    Model Garden の他のモデルを試す。各モデルをアプリケーションのデフォルト モデルとして設定して A/B テストを行い、その結果に基づいてモデルを選択する。
  • 2
    簡潔なレスポンスを期待するシナリオと詳細なレスポンスを期待するシナリオをすべて挙げるようユーザーに依頼する。それらのシナリオとそれぞれの詳しさのレベルを含むようにアプリケーションのプロンプトを変更する。更新したプロンプトでレスポンスの詳しさを再評価する。
  • 3
    キーワードベースのルーティング レイヤを実装する。ユーザーの入力に「detailed」や「description」という単語が含まれていれば詳細なレスポンスを返す。ユーザーの入力に「fact」という単語が含まれていれば、Gemini に再度プロンプトを送ってレスポンスを要約させ、簡潔なレスポンスを返す。
  • ✓
    適切な詳しさのレスポンスの例を、質問と回答のペアのリストとして提供するようユーザーに依頼する。このデータセットを使用して Agent Platform で教師ありファインチューニング（SFT）を行う。チューニングしたバージョンでレスポンスの詳しさを再評価する。

解説

【正解】D

【0からの解説】
①前提知識
・教師ありファインチューニング（SFT）は、「入力（プロンプト）と望ましい出力（回答）」のペアを例として与え、基盤モデルの振る舞いを特定のスタイル・形式・トーンに合わせて調整する手法です。Agent Platform（旧 Vertex AI）では Gemini モデルを JSONL 形式のデータセットでマネージドにチューニングでき、チューニング済みモデルはエンドポイントとしてそのまま利用できます。
・Google のドキュメントでは、SFT は「回答の長さや形式・スタイルなど、プロンプトだけでは一貫して制御しにくい出力の特徴」を学習させるのに適しているとされています。

②要件と制約語の整理
・回答は事実として正しい → 知識の追加ではなく「出力のスタイル（詳しさ）」の調整が課題。
・質問の種類によって望ましい詳しさが異なる → ルールで列挙しきれない微妙なパターンをモデルに学習させたい。
・数千行のフィードバックが既にある → 学習データの土台がある。
・「スケーラブル」「アプリケーションのメンテナンスを最小限に」→ アプリ側にルールや長いプロンプトを抱え込まない方法が望ましい。

③正解がどう満たすか
質問と適切な詳しさの回答のペアを集めて SFT を行えば、「どの種類の質問にどの程度の詳しさで答えるか」というパターン自体をモデルが学習します。アプリケーション側のロジックやプロンプトにシナリオを書き足し続ける必要がなく、新しい種類の質問にもある程度汎化するため、スケーラブルでメンテナンスも最小です。チューニング後に詳しさを再評価して効果を確認する点も、適切な開発サイクルです。

【誤りの選択肢】
A：回答は既に正確であり、問題はモデルの能力ではなく出力スタイルです。別モデルに切り替えても「質問の種類ごとの詳しさ」というユーザー固有の期待を学習するわけではなく、モデルごとの A/B テストは手間がかかるうえ、改善が保証されません。
B：プロンプトに全シナリオを列挙する方法は、シナリオが増えるたびにプロンプトを更新し続ける必要があり、プロンプトが肥大化してトークン コストやレイテンシも増えます。ユーザーに「すべてのシナリオ」を挙げてもらうこと自体も現実的ではなく、スケーラブルでもメンテナンス最小でもありません。
C：キーワードベースのルーティングは脆く、「detailed」「fact」などの単語を含まない多様な質問には対応できません。さらに要約のための再プロンプトで呼び出し回数とレイテンシ・コストが増え、ルールの追加・保守も継続的に必要になります。

【参考】
Gemini モデルの教師ありファインチューニングについて
Gemini モデルの教師ありファインチューニング データを準備する
チューニングの概要
この問題のページを開く →
問題 6AI ソリューションのモニタリングAI ソリューションのモニタリング
問題
あなたは、Gemini Enterprise Agent Platform を使用して、オンラインゲーム コミュニティ向けの生成 AI チャットボットをデプロイしています。ベータテスト中に、ユーザーが悪意のあるプロンプトを入力することで、モデルにヘイトスピーチや暴力的なコンテンツを生成させられることが判明しました。最小限の開発オーバーヘッドで、本番環境においてこのようなコンテンツをブロックするガードレールを実装する必要があります。どうすればよいですか？

選択肢と解説

  • 1
    モデルのシステム指示（システム プロンプト）を更新し、「あなたは役に立つアシスタントです。ヘイトスピーチや暴力的なコンテンツは生成しないでください。」と明示的に記述する。
  • ✓
    Model Armor を実装・構成し、ヘイトに該当するコンテンツが検出された場合にレスポンスをサニタイズする。
  • 3
    Agent Platform で教師ありファインチューニング（SFT）ジョブを作成し、安全でポリシーに準拠したゲーム関連の会話を厳選したデータセットを使ってモデルをチューニングする。
  • 4
    Cloud Natural Language API のモデレーション機能を統合し、有害なユーザー プロンプトがチャットボット モデルに届く前に分析してブロックする。

解説

【正解】B

【0からの解説】
①前提知識
・Gemini Enterprise Agent Platform（旧 Vertex AI）は、Gemini などの生成 AI モデルを利用・運用するための Google Cloud のプラットフォームです。
・Model Armor は、LLM へのプロンプト（入力）と LLM からのレスポンス（出力）を検査（スクリーニング）するフルマネージドのセキュリティ サービスです。テンプレートで「責任ある AI（Responsible AI）フィルタ（ヘイトスピーチ、ハラスメント、性的に露骨な表現、危険なコンテンツ）」「プロンプト インジェクション / ジェイルブレイク検出」「悪意のある URL 検出」「Sensitive Data Protection（旧 Cloud DLP）による機密データ検出」などを有効化し、検出時にブロックやサニタイズを行えます。
・Model Armor は Agent Platform と統合されており、テンプレートやフロア設定を構成するだけで generateContent などのモデル呼び出しに検査を適用できるため、独自のフィルタ処理を書く必要がほとんどありません。

②要件と制約語の整理
・悪意あるプロンプト（ジェイルブレイク的な入力）によってヘイトスピーチや暴力的コンテンツが生成されてしまう → 生成結果を確実に検査して止めるガードレールが必要。
・「本番環境で」「最小限の開発オーバーヘッドで」→ 自前実装やモデル再学習ではなく、構成ベースで適用できるマネージド機能が望ましい。

③正解がどう満たすか
Model Armor のテンプレートでヘイトスピーチや危険なコンテンツのフィルタ（信頼度のしきい値）を設定し、モデルのレスポンスを検査・サニタイズすれば、プロンプトがどれだけ巧妙でも「出力側」で有害なコンテンツを止められます。Agent Platform との統合機能を使えば構成だけで適用でき、開発オーバーヘッドは最小です。必要に応じてプロンプト側のプロンプト インジェクション / ジェイルブレイク検出も同じテンプレートで有効化できます。

【誤りの選択肢】
A：システム指示は有用ですが、あくまでモデルへの「お願い」であり強制力のあるガードレールではありません。今回まさに問題になっている悪意あるプロンプト（ジェイルブレイク）はシステム指示を回避するように作られているため、本番の防御としては不十分です。
C：SFT にはデータセットの収集・整備、チューニング ジョブの実行、評価、再デプロイが必要で、開発オーバーヘッドが大きくなります。また、チューニングしてもジェイルブレイクで有害出力を引き出される可能性は残り、検出・ブロックという決定的なガードレールにはなりません。
D：Cloud Natural Language API のテキスト モデレーション（moderateText）で有害性を判定すること自体は可能ですが、API 呼び出し・しきい値判定・ブロック処理をアプリ側に自前で組み込む必要があり、開発オーバーヘッドが Model Armor より大きくなります。さらにこの案は入力プロンプトのみを検査しており、一見無害に見えるプロンプトから生成された有害な「レスポンス」は防げません。LLM 向けに設計されたマネージドのガードレールである Model Armor のほうが要件に適合します。

【参考】
Model Armor の概要
Model Armor を Gemini Enterprise Agent Platform と統合する
プロンプトとレスポンスをサニタイズする | Model Armor
この問題のページを開く →
問題 7プロトタイプから ML モデルへのスケーリングプロトタイプから ML モデルへのスケーリング
問題
あなたは、カスタム PyTorch コンテナを使用して Gemini Enterprise Agent Platform 上で ResNet-50 のコンピュータ ビジョン モデルをトレーニングしています。トレーニング ジョブは、汎用マシンタイプと 1 基の NVIDIA A100 GPU で構成されています。トレーニング中にリソース使用率のグラフを監視したところ、GPU 使用率が不安定で、短い間隔で頻繁に 0% まで低下する一方、CPU 使用率は常に 90% を超えていることがわかりました。トレーニング時間を短縮するために GPU 使用率を最大化したいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    GPU メモリを使い切るまでトレーニングのバッチサイズを大きくする。
  • ✓
    DataLoader ユーティリティを更新して num_workers パラメータを増やし、pin_memory を有効にする。
  • 3
    GPU 数の多いマシンタイプに切り替え、トレーニング コードに torch.nn.parallel.DistributedDataParallel 戦略を実装する。
  • 4
    自動混合精度（AMP）を有効にして行列乗算を高速化する。

解説

【正解】B

【0からの解説】
①前提知識：深層学習のトレーニングでは、CPU が画像の読み込み・デコード・データ拡張などの前処理を行ってミニバッチを作り、それを GPU に転送して GPU が順伝播・逆伝播を計算します。CPU 側のデータ供給（入力パイプライン）が遅いと、GPU は次のバッチを待つ間アイドル状態になります。PyTorch の DataLoader では、num_workers を増やすと複数のワーカープロセスで並列にデータを読み込み・前処理でき、pin_memory=True にするとページロック（固定）メモリにバッチを置くことで CPU から GPU への転送が高速化され、非同期転送も可能になります。
②症状の整理：GPU 使用率が頻繁に 0% に落ちる一方、CPU 使用率は常に 90% 超。これは GPU の計算能力が不足しているのではなく、CPU 側のデータ供給が追いつかず GPU が待たされている「入力パイプラインのボトルネック」の典型的な兆候です。目標は GPU 使用率の最大化によるトレーニング時間短縮です。
③正解の理由：DataLoader の num_workers を増やしてデータの読み込み・前処理を並列化し（ワーカーの数は vCPU 数を目安に調整）、pin_memory を有効にしてホストからデバイスへの転送を高速化すれば、GPU に途切れなくバッチが供給され、GPU のアイドル時間が減ってトレーニング時間が短縮されます。ボトルネックそのものに直接対処する施策です。なお CPU がすでに飽和している場合は、vCPU 数の多いマシンタイプへの変更も併せて検討します。

【誤りの選択肢】
A：バッチサイズを大きくすると 1 ステップで CPU が準備すべきデータ量も増えるため、CPU 側のボトルネックは解消されません。GPU の待ち時間の割合はほとんど変わらず、根本原因に対処していません。
C：GPU を増やしても、データを供給する CPU 側が追いつかない状態は変わらず、むしろ待たされる GPU が増えるだけです。コストが増えるうえ、分散トレーニングのコード変更も必要で、GPU 使用率はさらに下がる可能性があります。
D：AMP は GPU 上の行列演算を高速化する手法ですが、ボトルネックは GPU の計算ではなく CPU のデータ供給です。GPU の計算が速くなるほど待ち時間の割合が増え、GPU 使用率はかえって低下します。

【参考】
Cloud Profiler を使用してモデルのトレーニング パフォーマンスをプロファイリングする: ノートブック
Gemini Enterprise Agent Platform サーバーレス トレーニングのコンピューティング リソースを構成する
この問題のページを開く →
問題 8低レイテンシでの取得を実現し、自動的にスケーリングし、かつ運用のオーバーヘッドを最小限に抑える特徴量サービング レイヤが…モデルのサービングとスケーリング
問題
あなたのチームは、リアルタイムでパーソナライズされた広告ランキング モデルをデプロイしようとしています。このモデルは、リクエスト時に取得するユーザー単位の特徴量数百個に低レイテンシでアクセスする必要があります。これらの特徴量は BigQuery に保存されており、ストリーミングの Dataflow パイプラインによって頻繁に更新されています。ユーザーベースが拡大し続けるにつれて、リクエスト時に BigQuery から特徴量を取得していることが原因で、推論全体のレイテンシが 100 ms のサービスレベル契約（SLA）を超えていることがわかりました。低レイテンシでの取得を実現し、自動的にスケーリングし、かつ運用のオーバーヘッドを最小限に抑える特徴量サービング レイヤが必要です。どうすればよいですか。

選択肢と解説

  • 1
    BigQueryReadClient を使用して、データをモデルの推論コンテナに直接ストリーミングする。
  • ✓
    Agent Platform Feature Store を有効にし、FetchFeatureValues API を使用してモデル用の特徴量を取得する。
  • 3
    Memorystore 上に Redis キャッシュを実装し、Dataflow パイプラインに特徴量を Redis キャッシュへ書き込むコンポーネントを追加する。
  • 4
    BigQuery BI Engine を使用して、特徴量の取得に使用している SQL クエリを高速化する。

解説

【正解】B

【0からの解説】
①前提知識：BigQuery は大量データを集計・分析するためのデータウェアハウスで、1 件ずつのキー検索をミリ秒単位で大量にさばく「オンライン サービング」用途には向きません。そこで Google Cloud には、ML 用の特徴量を管理・提供するマネージドサービスとして Vertex AI Feature Store（現 Agent Platform Feature Store）があります。現行の Feature Store は BigQuery のテーブル（またはビュー）をそのままデータソースとして登録し、「特徴ビュー（feature view）」を介してオンライン ストアへ同期します。オンライン ストアは Bigtable オンライン サービングを基盤とし、エンティティ ID（ここではユーザー ID）をキーにした低レイテンシの読み取りを提供し、ノード数の自動スケーリングにも対応しています。モデルはリクエスト時に FetchFeatureValues API を呼び出して、そのユーザーの特徴量をまとめて取得します。
②要件の整理：(1) 数百の特徴量をリクエスト時に低レイテンシで取得、(2) 特徴量の元データは BigQuery にあり、ストリーミング Dataflow で頻繁に更新、(3) 100 ms の SLA を守る、(4) 自動スケーリング、(5) 運用のオーバーヘッドを最小限に。
③正解の理由：Feature Store は BigQuery をデータソースとして直接使えるため、既存の BigQuery 上の特徴量テーブル（Dataflow が更新しているもの）をそのまま登録し、オンライン ストアへ同期（Bigtable オンライン サービングではスケジュール同期に加え継続的な同期も可能）できます。サービング基盤は Google が管理し、自動スケーリングも構成でき、取得は FetchFeatureValues API の 1 回の呼び出しで済みます。キャッシュの整合性管理やインフラのサイジングを自前で行う必要がないため、「低レイテンシ」「自動スケーリング」「運用オーバーヘッド最小」のすべてを満たします。なお、旧来の Optimized オンライン サービングは非推奨となっており、Google は Bigtable オンライン サービングへの移行を推奨しています。

【誤りの選択肢】
A：BigQueryReadClient（BigQuery Storage Read API）は、テーブルの大量データを高スループットで一括読み出しするための API です。ユーザー ID を指定した 1 件単位の高速なポイント ルックアップを行う仕組みではなく、セッション作成のオーバーヘッドもあるため、リクエストごとに呼び出すと 100 ms の SLA を満たせません。根本原因である「BigQuery をオンライン サービングに使っている」点が解消されません。
C：Memorystore for Redis は低レイテンシの読み取りは実現できますが、Dataflow パイプラインへの書き込みコンポーネントの追加・保守、キー設計、TTL や整合性の管理、インスタンスのサイジングやスケーリングなどを自前で設計・運用する必要があります。マネージドの Feature Store と比べて運用のオーバーヘッドが大きく、「運用のオーバーヘッドを最小限に」という条件に反します。
D：BI Engine は BI ツールやダッシュボードからの分析 SQL を高速化するためのインメモリ分析エンジンです。リクエストごとに大量の同時ポイント ルックアップを処理する用途向けではなく、クエリの起動やジョブ処理のオーバーヘッドも残るため、オンライン推論用の特徴量サービング レイヤとしては不適切です。

【参考】
Gemini Enterprise Agent Platform の Feature Store について
オンライン サービングのタイプ
オンライン ストアから特徴をサービングする
この問題のページを開く →
問題 9前処理コンポーネントは、その入力またはパラメータが変更された場合にのみ再実行されるようにする必要があります。ML パイプラインの自動化とオーケストレーション
問題
あなたは Kubeflow Pipelines（KFP）SDK を使用して、Agent Platform Pipelines で実行される機械学習パイプラインを開発しています。このパイプラインには、大規模なデータセットの変換に 2 時間かかる前処理コンポーネントが含まれています。現在、後続の model_training コンポーネントのコードを繰り返し修正しており、テストのためにパイプラインを頻繁に再送信する必要があります。前処理コンポーネントは、その入力またはパラメータが変更された場合にのみ再実行されるようにする必要があります。労力、コスト、および合計実行時間を最小限に抑えたいと考えています。どうすればよいですか。

選択肢と解説

  • ✓
    set_caching_options(enable_caching=True) メソッドを含めて、前処理コンポーネントで実行キャッシュが有効になっていることを確認する。
  • 2
    Agent Platform Experiments を使用して実行のリネージを追跡し、前回の実行の出力アーティファクト URI をトレーニング コンポーネントに渡す。
  • 3
    前処理済みデータを、パイプライン実行間で共有される永続ボリューム クレーム（PVC）に書き込むようにパイプラインを構成する。
  • 4
    前処理ステップが直近 1 時間以内に実行されたかどうかを確認する dsl.Condition ステップをパイプラインに追加する。

解説

【正解】A

【0からの解説】
①前提知識：Vertex AI Pipelines（現 Gemini Enterprise Agent Platform Pipelines、以下 Agent Platform Pipelines）は、KFP SDK で定義したパイプラインをサーバーレスで実行するマネージドサービスです。この Pipelines には「実行キャッシュ」機能があり、各ステップの「インターフェース」（入力パラメータの値と入力アーティファクト ID、出力の定義、コンポーネント仕様＝コンテナ イメージ・コマンド・引数・環境変数）をキャッシュキーとして、ML Metadata に同じキーの成功済み実行が記録されていれば、そのステップを再実行せずに前回の出力を再利用します。キャッシュは同じパイプライン名の実行間で共有され、有効期限はありません。タスク単位では task.set_caching_options(...) で、ジョブ単位では PipelineJob の enable_caching で制御できます。
②要件の整理：(1) 2 時間かかる前処理を、入力やパラメータが変わったときだけ再実行、(2) 後続の学習コンポーネントは頻繁に修正して再送信、(3) 労力・コスト・合計実行時間を最小化。
③正解の理由：前処理コンポーネントで実行キャッシュを有効にしておけば、入力・パラメータ・コンポーネント仕様が同じ限りキャッシュヒットとなり 2 時間の処理がスキップされ、前回の出力アーティファクトがそのまま後続の model_training に渡されます。逆に入力やパラメータ、コードが変わればキャッシュキーが変わるので自動的に再実行されます。これは「変更時のみ再実行」という要件そのものであり、1 行の設定で済むため労力もコストも最小です。なお、学習コンポーネントはコードを変更しているのでコンポーネント仕様が変わり、キャッシュされずに毎回実行されます。

【誤りの選択肢】
B：Experiments は実験のパラメータや指標、リネージの記録・比較のための機能で、ステップの実行をスキップする仕組みではありません。前回の URI を手作業でトレーニング コンポーネントに渡す運用は手間がかかり、前処理の入力が変わったかどうかを自動判定できないため、「入力が変わったときだけ再実行」を満たしません。
C：PVC は Kubernetes 上で動く KFP の概念で、サーバーレスの Agent Platform Pipelines ではパイプライン実行間で共有する PVC を前提にした構成は一般的ではありません。仮にデータを共有できても、前処理を再実行すべきかどうか（入力の変更有無）を判定する仕組みは提供されず、自前のロジックが必要になります。
D：dsl.Condition はパイプライン内の上流タスクの出力値に基づいて分岐する機能で、「過去の別の実行がいつ行われたか」を判定する仕組みではありません。また「直近 1 時間以内に実行されたか」という時間基準は「入力やパラメータが変わったか」という要件と一致せず、1 時間を過ぎれば入力が同じでも再実行され、逆に入力が変わっても 1 時間以内ならスキップされてしまいます。

【参考】
実行キャッシュを構成する
Gemini Enterprise Agent Platform Pipelines の概要
この問題のページを開く →
問題 10チーム内外で協働したデータとモデルの管理チーム内外で協働したデータとモデルの管理
問題
あなたは需要予測モデルの開発の探索フェーズにいます。数 TB の過去の売上データと在庫記録が BigQuery テーブルに保存されています。追加のデータ移動を行わずに、売上高の移動平均や週次の集計などの指標に関する予備分析を行うための、クリーンな新しいテーブルを作成する必要があります。最もシンプルな方法を使用し、オーバーヘッドを最小限に抑えたいと考えています。どうすればよいですか？

選択肢と解説

  • 1
    Agent Platform Pipelines のワークフローに PreprocessingOp コンポーネントを作成し、移動平均を計算して時間ベースの特徴量を抽出し、処理済みデータを BigQuery の新しい宛先テーブルに書き込む。
  • 2
    Agent Platform Workbench を使用して BigQuery からデータを Dask DataFrame に読み込む。探索的データ分析（EDA）と特徴量エンジニアリングの変換を行い、処理済みデータを BigQuery の新しい宛先テーブルに書き戻す。
  • 3
    BigQuery コンソールで SQL クエリを作成する。BigQuery ML の ML.TRANSFORM 関数を使用して移動平均を計算し、時間ベースの特徴量を抽出する。処理済みデータを BigQuery の新しい宛先テーブルに書き込む。
  • ✓
    BigQuery コンソールで SQL クエリを作成する。CAST、EXTRACT などの標準 SQL 関数と、OVER() 句を使ったウィンドウ関数を使用して変換と計算を行う。結果を BigQuery の新しい宛先テーブルとして実体化（マテリアライズ）する。

解説

【正解】D

【0からの解説】
①前提知識
・BigQuery は、SQL で TB〜PB 規模のデータを分析できるサーバーレスのデータウェアハウスです。データを BigQuery の外に出さずに、その場で集計・変換できます。
・ウィンドウ関数（分析関数）は、AVG(sales) OVER (PARTITION BY store ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) のように、行ごとに一定範囲の行を参照して移動平均などを計算する SQL の機能です。EXTRACT(WEEK FROM date) や DATE_TRUNC で週単位の値を取り出し GROUP BY すれば週次集計もできます。CAST は型変換、つまりデータのクリーニングに使います。
・結果は CREATE TABLE ... AS SELECT（CTAS）や宛先テーブルの指定で新しいテーブルとして保存（マテリアライズ）できます。
・BigQuery ML の ML.TRANSFORM 関数は、CREATE MODEL の TRANSFORM 句で定義した前処理を、学習済みモデルを使って新しいデータに適用する関数です。モデルを作成していなければ使えません。

②要件と制約語の整理
・数 TB のデータがすでに BigQuery にある。
・「追加のデータ移動なし」で、移動平均・週次集計などを含むクリーンな新テーブルを作る。
・探索フェーズの予備分析用で、「最もシンプル」「オーバーヘッド最小」。

③正解がどう満たすか
BigQuery コンソールで標準 SQL（CAST・EXTRACT・ウィンドウ関数）を書いて結果を新しいテーブルにマテリアライズすれば、データは BigQuery 内から一切動かず、BigQuery の分散処理で数 TB でも高速に処理されます。追加のサービスやインフラ、コードは不要で、最もシンプルかつ低オーバーヘッドです。

【誤りの選択肢】
A：Agent Platform Pipelines（旧 Vertex AI Pipelines）のコンポーネントを作るには、コンポーネントの実装・パイプライン定義・実行環境の管理が必要です。本番の再現可能なワークフローには有用ですが、探索フェーズの一回限りの分析としてはオーバーヘッドが大きすぎます。
B：数 TB のデータを Agent Platform Workbench（旧 Vertex AI Workbench）の Dask DataFrame に読み込むと、BigQuery の外へ大量のデータ移動が発生し、「追加のデータ移動なし」に反します。メモリや計算リソースのサイジングも必要になり、BigQuery 内の SQL より手間とコストがかかります。
C：ML.TRANSFORM は、TRANSFORM 句付きで作成した BigQuery ML モデルの前処理を再適用する関数で、モデルなしで汎用的な移動平均計算に使うものではありません。モデルを作るという余計な手順が必要になり、ウィンドウ関数による移動平均の計算もこの関数の役割ではありません。

【参考】
TRANSFORM 句を使用して特徴量エンジニアリングを実行する
データ準備の概要
この問題のページを開く →
問題 11ローコードの AI ソリューションの設計ローコードの AI ソリューションの設計
問題
あなたは医療機関に勤務しており、患者のトリアージ（緊急度判定）プロセスを自動化する必要があります。Gemini Live API を使用して、患者と人間のような会話を行い、必要な患者情報を収集する電話エージェント型ソリューションを構築したいと考えています。このソリューションは日本語でパイロット運用する予定です。レイテンシと開発時間を最小限に抑え、モデルのレスポンスがネイティブ並みに流暢であるようにする必要があります。どうすればよいですか？

選択肢と解説

  • 1
    Gemini Live API の Speech-to-Text 機能でユーザーの入力を取得し、その後 Chirp による Text-to-Speech のストリーミング処理で患者の言語で患者とやり取りする。
  • ✓
    Gemini Live API を使用し、language_code フィールドを ja-JP に構成する。患者の言語で応答するよう明確なシステム指示を含める。
  • 3
    日本語の医療会話の文字起こしデータセットで Gemini Flash モデルをファインチューニングし、ネイティブ並みの流暢さを確保する。このカスタムモデルを Gemini Live API の背後にデプロイする。
  • 4
    Gemini Pro モデルを使用して、適切な言語を自動的に選択させる。

解説

【正解】B

【0からの解説】
①前提知識
・Gemini Live API は、音声・テキスト・映像を双方向にストリーミングして、低レイテンシでリアルタイムの音声会話を実現する API です。音声を直接入力として受け取り、音声で直接応答できる（ネイティブ音声モデルの場合は音声のまま理解・生成する）ため、「音声認識 → テキスト生成 → 音声合成」と別々のサービスをつなぐ構成より遅延が小さくなります。
・Live API では、音声出力の言語を speech_config の language_code（BCP-47 形式、例: ja-JP）で指定できます。日本語（ja-JP）はサポート言語に含まれています。また公式ドキュメントでは、英語以外で応答させる場合、システム指示に「（その言語）で応答すること。必ず明確に（その言語）で応答すること」といった指示を入れることが推奨されており、ネイティブ音声モデルではシステム指示で応答言語を制御します。

②要件と制約語の整理
・Gemini Live API を使った電話での人間らしい会話。
・日本語でパイロット運用。
・「レイテンシを最小」「開発時間を最小」「ネイティブ並みの流暢さ」。

③正解がどう満たすか
Live API をそのまま使い、language_code を ja-JP に設定し、システム指示で日本語（患者の言語）で応答するよう明示すれば、追加のサービス連携やモデル学習なしに、Live API の低レイテンシなネイティブ音声会話を日本語で利用できます。構成変更だけなので開発時間も最小です。

【誤りの選択肢】
A：音声認識（Speech-to-Text）と音声合成（Chirp による Text-to-Speech）を別々につなぐ「カスケード」構成は、処理段が増える分レイテンシが大きくなり、連携の実装で開発時間もかかります。Live API はそれ自体が音声の入出力を扱えるため、わざわざ分割する必要はありません。
C：ファインチューニングにはデータセットの収集（医療データなので個人情報の扱いも必要）、チューニング、評価が必要で、開発時間が大幅に増えます。また Gemini は日本語を十分に扱えるため流暢さのためのチューニングは不要であり、任意のチューニング済みモデルを Live API の背後に置くという構成も前提にできません。
D：言語の自動選択に任せるだけでは、患者の発話や雑音によって意図しない言語で応答するリスクがあり、日本語での一貫した応答が保証されません。また Gemini Live API を使うという前提から外れ、リアルタイム音声会話のための低レイテンシ要件にも合いません。

【参考】
Gemini 3.8 Live のデベロッパー ガイド
システム指示を使用する
この問題のページを開く →
問題 12AI ソリューションのモニタリングAI ソリューションのモニタリング
問題
あなたは生成 AI を使用して、銀行の顧客から寄せられる、保有商品や取引履歴に関する問い合わせに対応する会話型エージェントを構築しています。エージェントのレスポンスに個人を特定できる情報（PII）が含まれないようにする必要があります。この要件を最小限の労力で実装したいと考えています。どうすればよいですか？

選択肢と解説

  • 1
    Agent Platform のモデル パラメータで safety_settings のしきい値を Block_Most に構成する。
  • 2
    Python の re モジュールでパターン r'\b(?:\d{4}[- ]?){3}\d{4}\b' を使用してクレジットカード番号を識別し秘匿化（編集）する後処理ラッパーを開発する。
  • ✓
    Sensitive Data Protection を組み込んだ Model Armor を実装し、エージェントのレスポンスから PII を検出して秘匿化する。
  • 4
    サンプリングされた Shapley（SHAP）値を使用してモデルの予測を理解し、モデルが PII を明かす方向に偏っていないことを確認する。

解説

【正解】C

【0からの解説】
①前提知識
・個人を特定できる情報（PII）とは、氏名、住所、電話番号、メールアドレス、口座番号、クレジットカード番号、マイナンバーなど、個人を特定し得る情報のことです。
・Sensitive Data Protection（旧 Cloud DLP）は、多数の組み込み infoType（クレジットカード番号、電話番号、メールアドレス、各国の ID 番号など）を使って機密データを検出し、マスキングや置換などの匿名化（de-identification）を行うサービスです。
・Model Armor は LLM のプロンプトとレスポンスを検査するマネージド サービスで、Sensitive Data Protection と統合されています。基本構成では主要な機密 infoType を検出し、詳細構成では検査テンプレート / 匿名化テンプレートを指定して検出した PII を秘匿化したレスポンスを返せます。

②要件と制約語の整理
・エージェントの「レスポンス」に PII を含めない（検出して取り除く）。
・PII の種類は多岐にわたる（口座情報、取引履歴に含まれる氏名など）。
・「最小限の労力で」→ 自前のルール実装より、マネージドの検出・秘匿化機能を使う。

③正解がどう満たすか
Model Armor のテンプレートで Sensitive Data Protection を有効化すれば、エージェントのレスポンスを検査し、PII を検出・秘匿化できます。Google が管理する多数の infoType 検出器を構成だけで利用でき、正規表現などを自作・保守する必要がないため、最小限の労力で要件を満たせます。

【誤りの選択肢】
A：safety_settings（安全フィルタ）は、ヘイトスピーチ、ハラスメント、性的に露骨な表現、危険なコンテンツといった有害カテゴリを対象とするもので、PII の検出・秘匿化機能ではありません。しきい値を厳しくしても PII を含む回答は防げません。
B：正規表現での後処理は動作はしますが、対象がクレジットカード番号の形式に限られ、氏名・住所・口座番号など他の PII は検出できません。PII の種類ごとにパターンを作り込み保守する必要があり、誤検出や見逃しも多く、「最小限の労力」に反します。
D：Shapley 値（SHAP）は特徴量が予測にどれだけ寄与したかを説明する Explainable AI の手法であり、生成されたレスポンスから PII を検出・除去する機能はありません。

【参考】
プロンプトとレスポンスをサニタイズする | Model Armor
Model Armor の概要
Model Armor を Gemini Enterprise Agent Platform と統合する
この問題のページを開く →
問題 13また、システムは 1 日あたり数百万件の取引を処理できるようにスケーリングする必要があります。プロトタイプから ML モデルへのスケーリング
問題
あなたはフィンテック企業で ML チームを率いています。チームは、不正の可能性があるクレジットカード取引をリアルタイムで検出するシステムを構築しています。取引の承認・拒否を行うため、モデルは非常に低いレイテンシ（200 ms 未満）で予測を返す必要があります。また、システムは 1 日あたり数百万件の取引を処理できるようにスケーリングする必要があります。データセットは BigQuery に保存された構造化された表形式の取引データです。チームはデータ サイエンスに精通していますが、リアルタイムのモデル サービング インフラストラクチャの管理と最適化の複雑さは避けたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    Agent Platform Workbench のノートブックで、PyTorch を使用してディープ ニューラル ネットワーク（DNN）を構築する。GPU 対応の Compute Engine インスタンスのクラスタをプロビジョニングし、リアルタイム予測用にモデルを提供する API を作成する。
  • 2
    BigQuery ML を使用してブーストツリー分類モデルをトレーニングする。1 分ごとに実行され、直近の取引をスコアリングする ML.PREDICT 関数を使用したバッチ予測ジョブをスケジュールする。
  • 3
    Agent Platform AutoML の予測（Forecasting）を使用して、取引のシーケンスで時系列モデルをトレーニングする。モデルを表形式ワークフローとしてデプロイし、不正行為が含まれる可能性が高い将来の時間枠を予測する。
  • ✓
    BigQuery の表形式データセットを使用して Agent Platform AutoML でトレーニングする。トレーニング済みモデルを Agent Platform エンドポイントにデプロイし、エンドポイントの API を取引処理アプリケーションに統合する。

解説

【正解】D

【0からの解説】
①前提知識：Vertex AI AutoML（現 Agent Platform AutoML）の表形式（分類・回帰）は、BigQuery テーブルなどの表形式データから、特徴量エンジニアリングやモデル選択、ハイパーパラメータ調整を自動化して高品質なモデルを作成する機能です。作成したモデルは Vertex AI Prediction（現 Agent Platform Inference）のエンドポイントにデプロイでき、Google が管理するサービング基盤が自動スケーリングしながら REST/gRPC API で同期的なオンライン予測を返します。
②要件の整理：(1) 取引ごとにリアルタイムで不正を判定（分類問題）、(2) 200 ms 未満の低レイテンシ、(3) 1 日数百万件にスケール、(4) BigQuery の表形式データ、(5) リアルタイム サービング基盤の管理・最適化の複雑さを避けたい。
③正解の理由：AutoML の表形式分類で BigQuery のデータから直接モデルを作成し、マネージドなエンドポイントにデプロイすれば、取引処理アプリケーションは API を呼ぶだけで取引ごとの同期予測を得られます。サービング インフラのプロビジョニング、スケーリング、パッチ適用は Google が管理し、レプリカの自動スケーリングで大量の取引にも対応できるため、低レイテンシ・スケーラビリティ・運用負荷の回避をすべて満たします。

【誤りの選択肢】
A：Compute Engine の GPU クラスタと独自の API を自前で構築・運用することになり、スケーリング、可用性、パッチ適用、レイテンシ最適化をすべてチームが担います。「サービング インフラストラクチャの管理と最適化の複雑さを避けたい」という条件に真っ向から反します。
B：BigQuery ML のブーストツリー分類自体は表形式データに適していますが、1 分ごとのバッチ予測では、取引の発生から判定までに最大 1 分以上の遅れが生じます。取引の承認・拒否の時点で 200 ms 未満に予測を返すというリアルタイム要件を満たせません。
C：予測（Forecasting）は将来の数値（売上など）を時系列で予測するためのモデルで、個々の取引が不正かどうかを判定する分類問題には適していません。「不正が起きやすい将来の時間枠」を予測しても、目の前の取引をリアルタイムに承認・拒否する要件には応えられません。

【参考】
分類と回帰の概要
AutoML モデルのオンライン推論を取得する
この問題のページを開く →
問題 14エンドポイントをどのように構成すべきですか。モデルのサービングとスケーリング
問題
あなたは、Agent Platform エンドポイントにデプロイされたレコメンデーション モデルを使用する、トラフィックの多い e コマース アプリケーションを運用しています。フラッシュセールの際には、トラフィックが 1 秒あたりのクエリ数（QPS）1,000 から 50,000 へと急激に増加します。このような急増時、オートスケーラーが急な需要に対応できるだけの速さで新しいリソースをプロビジョニングできないため、アプリケーションが 503: Service Unavailable エラーを返します。セール開始時のサービス中断をなくす必要があります。エンドポイントをどのように構成すべきですか。

選択肢と解説

  • 1
    マシンタイプを NVIDIA A100 GPU 搭載の a2-highgpu-1g インスタンスに変更する。
  • ✓
    min_replica_count を、予想される急増のかなりの部分をカバーするベースラインまで引き上げ、max_replica_count を 100 に設定する。
  • 3
    デプロイされたモデルの自動スケーリング構成で、min_replica_count を 1 に、max_replica_count を 100 に設定する。
  • 4
    モデルをプライベートな Agent Platform エンドポイントにデプロイし、GPU 使用率に基づいて自動スケーリングする。

解説

【正解】B

【0からの解説】
①前提知識：Vertex AI Prediction（現 Agent Platform Inference）のエンドポイントにデプロイしたモデルは、min_replica_count（最小レプリカ数）と max_replica_count（最大レプリカ数）の範囲で、CPU 使用率や GPU デューティ サイクル（既定の目標は 60%）などの指標に基づいて自動スケーリングします。ただしスケールアップを決めてから新しいレプリカがリクエストを処理できるようになるまでには、VM のプロビジョニング、コンテナのダウンロード、モデルの読み込みといった時間がかかります。公式ドキュメントでも、スケールアップが想定トラフィックに対して遅すぎる場合は、最小レプリカ数を十分に高く設定することが推奨されています。
②要件の整理：(1) フラッシュセールで 1,000 QPS → 50,000 QPS へと急増、(2) オートスケーラーのリソース準備が間に合わず 503 エラーが発生、(3) セール開始時のサービス中断をなくす。
③正解の理由：min_replica_count を予想される急増の大部分に耐えられる水準まで引き上げておけば、セール開始の瞬間からすでに十分なレプリカが稼働しているため、新規プロビジョニングを待たずにトラフィックを処理できます。残りの増加分や想定外の増加は max_replica_count（100）までの自動スケーリングで吸収できます。リアクティブなスケーリングのタイムラグという根本原因に対する直接的な対策です（コスト面では、セール期間に合わせて事前に最小レプリカ数を引き上げ、終了後に戻すといった運用も考えられます）。

【誤りの選択肢】
A：マシンタイプを高性能な GPU インスタンスに変えても、各レプリカの処理能力が変わるだけで、オートスケーラーが新しいリソースを準備するまでの遅延は解消されません。GPU 付きノードはプロビジョニングにかえって時間がかかることもあり、コストも大きく増えます。
C：min_replica_count を 1 にすると、平常時はさらに少ないレプリカで待機することになり、急増時にはより多くのレプリカを新規にプロビジョニングしなければなりません。max_replica_count を増やしても上限が上がるだけでスケールアップの速度は変わらないため、503 エラーは解消されず、むしろ悪化します。
D：プライベート エンドポイントはネットワーク経路（VPC 内からの低レイテンシ・セキュアなアクセス）に関する選択であり、スケーリングの速さには影響しません。GPU 使用率に基づく自動スケーリングも、負荷が上がってから反応するリアクティブな方式である点は変わらず、プロビジョニングの遅延という根本原因を解決しません。

【参考】
自動スケーリングを使用して推論ノードをスケーリングする
推論用のコンピューティング リソースを構成する
この問題のページを開く →
問題 15ホールドアウトしたテスト データセットでモデルのパフォーマンスを検証する必要があります。ML パイプラインの自動化とオーケストレーション
問題
あなたは Agent Platform Pipelines を使用して自動トレーニング ワークフローを開発しています。このパイプラインは新しいカスタムモデルをトレーニングし、Model Registry に登録します。ホールドアウトしたテスト データセットでモデルのパフォーマンスを検証する必要があります。モデルの評価指標が特定のしきい値を満たした場合にのみ、モデルが本番環境の Agent Platform エンドポイントにデプロイされるようにしたいと考えています。コストと管理のオーバーヘッドを最小限に抑えたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    トレーニング ジョブ中にトレーニング データセットで評価指標を計算するようにトレーニング コンポーネントを構成する。指標を次のステップに出力し、評価指標が指定したしきい値を超えた場合にモデルをデプロイする条件付きタスクを使用する。
  • 2
    Model Registry から最新のモデル バージョンを取得する Python コンポーネントを挿入する。そのトレーニング指標を現在の本番モデルと比較し、新しいモデルのほうが優れている場合に新しいモデルをデプロイする条件付きタスクを使用する。
  • 3
    モデルを一時的な Agent Platform エンドポイントにデプロイする。カスタム コンポーネントを使用してテスト データセットをオンライン予測に送信し、指標を計算して、評価指標が指定したしきい値を超えた場合に本番環境のエンドポイントにデプロイする。
  • ✓
    テスト データセットで予測を生成するバッチ予測コンポーネントを追加する。結果をモデル評価コンポーネントに渡す。評価指標が指定したしきい値を超えた場合にモデルをデプロイする条件付きタスクを使用する。

解説

【正解】D

【0からの解説】
①前提知識：Vertex AI Pipelines（現 Gemini Enterprise Agent Platform Pipelines）では、Google Cloud パイプライン コンポーネント（GCPC）として、バッチ予測ジョブを実行するコンポーネント（ModelBatchPredictOp）や、予測結果と正解ラベルから分類・回帰などの評価指標を計算するモデル評価コンポーネント、エンドポイント作成・デプロイのコンポーネントなどが用意されています。また KFP の条件分岐（dsl.Condition／dsl.If）を使うと、上流タスクの出力（評価指標など）に応じて後続タスク（デプロイ）を実行するかどうかを決められます。バッチ予測はエンドポイントを常時起動する必要がなく、ジョブ実行中だけリソースが課金されます。
②要件の整理：(1) ホールドアウトしたテスト データセットで性能を検証、(2) 指標が特定のしきい値を満たした場合のみ本番エンドポイントにデプロイ、(3) コストと管理のオーバーヘッドを最小化。
③正解の理由：バッチ予測コンポーネントでテスト データセットの予測を生成し、モデル評価コンポーネントで指標を算出、条件付きタスクでしきい値判定してデプロイする構成は、Google が提供する既製コンポーネントの組み合わせだけで実現できる標準的なパターンです。評価は未知データ（ホールドアウト）で行われるため信頼でき、一時エンドポイントのような常時課金リソースも不要なので、コストと管理負荷の両方を最小化できます。

【誤りの選択肢】
A：トレーニング データセットで計算した指標は、モデルが学習に使ったデータに対する成績なので過学習していても高く出ます。要件の「ホールドアウトしたテスト データセットでの検証」を満たさず、汎化性能を正しく判定できません。
B：比較に使っているのはトレーニング指標であり、ホールドアウトのテスト データセットで評価していません。また、要件は「特定のしきい値を満たすこと」であって「本番モデルより優れていること」ではないため、判定基準も要件と一致しません。さらに Model Registry からの取得や比較ロジックを自前の Python コンポーネントで実装・保守する必要があります。
C：テスト データの評価のためだけに一時エンドポイントへデプロイすると、デプロイ中はノードが常時起動して課金され、デプロイ・アンデプロイの待ち時間や後片付けの管理も発生します。さらにオンライン予測用のリクエスト送信と指標計算をカスタム コンポーネントで実装する必要があり、オフラインでまとめて推論できるバッチ予測＋既製の評価コンポーネントに比べてコストも管理のオーバーヘッドも大きくなります。

【参考】
Agent Platform を使用してモデルを評価する
Google Cloud パイプライン コンポーネントのリスト
パイプラインのビルド
この問題のページを開く →

GCP-PMLE 模擬問題集についてよくある質問

GCP-PMLE の練習問題は無料で試せますか？

はい。GCP-PMLE は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

GCP-PMLE は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。