Google Cloud認定 Professional Machine Learning Engineer WEB問題集

正解：B

• BigQuery ML では CREATE MODEL ... OPTIONS(model_type='MATRIX_FACTORIZATION') が使える

• レコメンデーションに最も一般的

• コーディング最小（SQL のみ）

• 大規模データでもスケールする

• Cloud Storage → BigQuery Load も簡単

正解：D

今回の問題では、遅延の主な原因が「モデルの計算速度」ではなく「地理的な距離」にあるという点が最も重要です。モデルは3層の単純なパーセプトロンであり、計算量は決して大きくありません。そのため、より高性能な CPU（選択肢B）や GPU（選択肢A）を利用したところで、大きなレイテンシ削減にはつながりません。実際に現在のレイテンシは 40ms と比較的良好であり、推論速度そのものではなく、シンガポールから us-central1 へのネットワーク距離が大きいことが遅延の原因となっています。

したがって、シンガポールのユーザーに近いリージョンで推論を行うことが最も効果的です。そのためには、asia-southeast1（シンガポール）に新たな Vertex AI エンドポイントを作成し、ユーザーの地域に応じて適切なエンドポイントを利用させる構成が最適解となります。これにより、ネットワーク往復の距離が大幅に短縮され、推論レイテンシの改善が期待できます。

選択肢 C は private endpoints を使う点が余計であり、通常の Vertex AI エンドポイントで十分なユースケースに対して過剰な構成となります。今回求められているのは単純なリージョナル冗長性と近接性であるため、asia-southeast1 に Vertex AI エンドポイントを増設する D が最も直接的で効果的な解決策です。

以上の理由から、D が最も合理的かつ実用的な選択肢となります。

正解：A

この問題で重要なのは、二つの条件です。

1. トレーニングコードにカスタム依存関係が必要であること

2. トレーニングジョブの「起動時間」を最小化したいこと

起動時間を短くするためには、ジョブが開始される前に走る処理をいかに減らすかが最も重要です。Vertex AI のカスタムトレーニングジョブでは、コンテナイメージのダウンロードと、起動時のパッケージインストールが大きなオーバーヘッドになります。

選択肢 A は、トレーニングコードと必要な依存パッケージをあらかじめ カスタムコンテナに全て組み込んでおく構成です。この場合、ジョブ起動時に余計なインストール作業が発生せず、すぐにトレーニングスクリプトが実行されます。データは Cloud Storage に置いていますが、Vertex AI のトレーニングジョブは同一リージョン内で非常に高速に GCS にアクセスできるため、このデータ読み込みは起動時間にほとんど影響しません。むしろ、データをコンテナに含めてイメージサイズを肥大化させるより、コンテナをスリムに保つ方がダウンロードが短くなり、結果的に起動時間も短縮されます。

一方で B と D は、いずれも Python ソースディストリビューションによって実行時に依存関係をインストールする構成です。これはトレーニングジョブのたびに pip install のような処理が発生するため、起動時間が大きく伸びてしまいます。「起動時間を最小化する」という要件とは明確に矛盾します。

選択肢 C は、依存関係をカスタムコンテナに含められる点では悪くありませんが、データをコンテナに同梱する構成になっています。これはコンテナイメージが不要に大きくなるため、ジョブ起動時にイメージの取得に時間がかかります。また、データ更新のたびにコンテナを作り直す必要があり、実運用としても適切ではありません。

総合すると、カスタム依存関係を事前に含めつつ、イメージサイズを最小限に保つという観点で、選択肢 A が最も効率的であり、問題の要件に最も適合しています。そのため、正解は A となります。

正解：C

この問題では、二つの要件がはっきり示されています。ひとつは「Cloud Storage バケットに新しいファイルがあるときだけパイプラインを実行したい」というイベントドリブンな実行条件、もうひとつは「コンピュートノードのコストを最小限に抑えたい」というコスト制約です。この二つを同時に満たす設計を考える必要があります。

まず、Cloud Composer を使う B と D の案から考えてみると、Cloud Composer（Managed Airflow）は常に稼働するワーカーノードを持つため、Airflow 環境自体を立ち上げておくだけでそれなりのコンピュートコストが発生します。特にこの問題では、ファイル到着時にだけパイプラインを動かしたい、つまり「普段は何もしていない時間が多い」可能性が高いため、常時稼働型の Composer はコスト最適化の観点からあまり好ましくありません。D は GCSObjectUpdateSensor によって新ファイルを検知する仕組みを提案していますが、センサーが動作するためには Airflow 環境自体が常に動いている必要があるため、「コンピュートノードのコストを最小化する」という要件と矛盾します。B に至っては、Cloud Functions から DAG を「デプロイする」という少し不自然な構成であり、オーケストレーションの設計としても過剰かつ複雑です。

次に Vertex AI Pipelines を使う A と C を比較します。A の場合、スケジューラーで一定間隔ごとにパイプラインを起動し、その中の最初のステップで「前回実行時から新しいファイルがあるかどうか」をチェックする構成になっています。一見すると悪くないように見えますが、この方法では新しいファイルがなくてもパイプライン自体は定期的に起動されてしまいます。パイプラインの起動ごとに基盤側でオーケストレーション環境が立ち上がるため、無駄な実行が増え、コストやオーバーヘッドも積み上がります。「新しいファイルがあるときだけ動かしたい」という要件を素直に満たしているとは言えません。

それに対して C は、Vertex AI Pipelines で機械学習パイプラインを構成し、そのパイプラインの実行トリガーとして Cloud Functions を用いる構成です。Cloud Functions は Cloud Storage のイベントトリガー（たとえば OBJECT_FINALIZE）を利用することで、新しいファイルがバケットにアップロードされたタイミングでのみ発火させることができます。この Cloud Functions から Vertex AI Pipelines のパイプライン実行を API 経由で開始すれば、「新しいファイルが来たときだけパイプラインを走らせる」という要件を自然に満たせます。さらに、Vertex AI Pipelines はマネージドなサーバレス型のオーケストレーションに近い動きをするため、パイプライン実行時のみリソースを使い、常時稼働のワーカーノードを自前で維持する必要はありません。Cloud Functions もイベントベースで短時間だけ動作するため、アイドル時のコンピュートコストはほぼゼロにできます。この点で C は、イベントドリブン実行とコスト最適化という二つの要件を最もバランスよく満たす構成です。

以上から、Cloud Composer のような常時稼働が必要なオーケストレーション基盤ではなく、Cloud Storage トリガーでイベントを受け、必要なときだけ Vertex AI Pipelines を起動するという構成を取れる C が、問題文の要件に最も適した正解となります。

正解：B

この問題のポイントは、「開発サイクルを早く回したい」というニーズと、「追加の費用はかけたくない」というコスト制約が同時に存在している点です。Kubeflow/Vertex AI Pipelines を使っている状況で、何度もパイプラインを回しながら feature engineering や学習ロジックを改善している、まさに実務の MLOps 開発フェーズを想定したシナリオになっています。

まず、パイプライン全体に 1 時間以上かかっているということは、多くのステップが毎回最初から実行されているということです。しかし、実際にコードを頻繁に変更しているのは特徴量エンジニアリングやモデル学習の一部であり、データの読み込みや前処理など、毎回同じ処理結果になるステップも多く含まれているはずです。ここで有効なのが Kubeflow Pipelines の「キャッシュ機能」です。キャッシュを有効化しておくと、入力パラメータやコードに変更がないステップについては、前回実行時の出力をそのまま再利用することができます。その結果、そのステップを再実行せずに済むため、パイプライン全体の実行時間を大きく短縮できます。

特にこの問題のように、「何度もパイプラインを回してコードを微調整している」場合、毎回 BigQuery からの読み込みや前処理、変わっていない評価ステップなどを一から再実行するのは明らかに無駄です。キャッシュを有効にしておけば、「変更したステップ以降」だけが再実行され、手を加えていない前段の処理はキャッシュ結果が使われるため、開発効率が飛躍的に向上します。そして、キャッシュは追加の GPU や強力なマシンタイプを購入するわけではなく、仕組みとしての再利用を行うだけなので、「追加コストをかけずに高速化する」という要件にも合致します。したがって、最も合理的な選択肢は B：すべてのステップでキャッシングを有効化する です。

一方、A の「コメントアウトする」という方法は、手作業でパイプラインを部分的に無効化するアイデアですが、これではオーケストレーションとしての一貫性が崩れますし、毎回定義を書き換える必要があり、管理もミスも増えます。また、コメントアウトしても、前段のステップ（データ読み込みや前処理など）が毎回フル実行されるので、時間短縮効果は限定的です。

C は一見「BigQuery に寄せた方が速そうだ」と感じるかもしれませんが、問題が問うているのは「構成を大きく作り替えること」ではなく、「開発中のパイプライン実行をどう効率化するか」です。特徴量エンジニアリングを BigQuery に出してしまうのは設計変更に近く、PyTorch ベースのパイプライン全体との整合性や、既に書いているコードとの再利用性も落ちます。また、BigQuery に処理を移してもクエリコストが余計にかかる可能性があり、「追加コストを避けたい」という要件ともややずれます。

D の GPU 追加は、モデル学習時間を短縮できる可能性はありますが、GPU は明確に追加コストを増やす方向の解決策です。問題文にはっきりと「追加の費用は発生させたくない」とあるため、ここで GPU を選ぶのは要件違反になります。

以上を踏まえると、既存の構成を大きく変えず、追加コストもかけずに、かつ開発ループを高速化できるのは ステップキャッシュを有効にすること（B） であり、これが Professional Machine Learning Engineer 試験としての模範的な解答となります。