【正解】C
【0からの解説】
① 前提知識・
モノリス: すべての機能が 1 つのアプリケーションにまとまった構成です。一部を変更しても全体をビルド・テスト・デプロイし直す必要があり、チームが大きくなるほどデプロイが遅くなります。
・
マイクロサービス: 機能ごとに小さな独立したサービスへ分割し、それぞれを個別に開発・デプロイ・スケールできるようにする構成です。モノリスから一度に作り直すのではなく、機能を少しずつ切り出して移行する段階的なやり方（ストラングラー フィグ パターン）が推奨されます。
・
イベント駆動型アーキテクチャと
Pub/Sub: Pub/Sub はフルマネージドな非同期メッセージング サービスです。「取引が発生した」などのイベントを Pub/Sub に発行し、関心のあるサービス（不正検出、通知、分析など）がそれぞれ購読することで、サービス同士を疎結合に保てます。新しい機能はイベントを購読するサービスを追加するだけで組み込めます。
・
Vertex AI（現 Gemini Enterprise Agent Platform）エンドポイント: トレーニング済みモデルをデプロイし、オンライン予測（リアルタイム推論）を API として提供するマネージドな仕組みです。
② 要件と制約語の整理・課題: デプロイ サイクルが遅い／モノリシックな設計が ML 不正検出モデルの統合を妨げている。
・求められているのは「
長期的な戦略」であり、「
開発者の俊敏性の向上」と「
将来のイノベーションに向けて Google Cloud の高度なデータ・AI 機能を活用できる体制」の両方を満たす必要があります。目先の機能追加ではなく、アーキテクチャの根本的な改善が問われています。
③ 正解 C が要件をどう満たすか・
段階的なマイクロサービス化により、サービスごとに独立してデプロイできるようになり、デプロイ サイクルの遅さという根本原因を解消します。段階的に進めるため、買収直後の本番システムを止めるリスクも抑えられます。
・
Pub/Sub によるイベント駆動の疎結合な構成にすることで、不正検出モデルを含む新しい ML 機能を、既存サービスを改修せずにイベントの購読者として追加できます。同じイベントを BigQuery などの分析基盤へ流すことも容易で、将来のデータ・AI 活用の土台になります。
・不正検出モデルは
Vertex AI エンドポイントにデプロイし、マネージドなスケーリング、モデルのバージョン管理、モニタリングを活用できます。
【誤りの選択肢】
A：モデルを Vertex AI エンドポイントで提供すること自体は有効ですが、モノリスはそのまま残るため、デプロイ サイクルの遅さという根本課題は解決しません。将来新しい AI 機能を追加するたびにモノリスを改修する必要があり、「長期的な戦略」「開発者の俊敏性の向上」の要件を満たさない短期的な対処にとどまります。
B：コンテナ化して GKE で動かし、データベースをマネージドな Cloud SQL に移すことで運用面は改善しますが、アプリケーションはモノリスのままです（いわゆるリフト＆シフトに近い移行）。1 つの大きなコンテナを丸ごとデプロイし直す構造は変わらず、デプロイの遅さや ML モデル統合の難しさは解消されません。
D：Datastream で BigQuery にデータを複製し、BigQuery ML でモデルを作るのはデータ分析基盤としては有効ですが、アプリケーションのモノリシックな構造や開発者の俊敏性には一切手を付けていません。また、BigQuery ML の予測は BigQuery 上の SQL で実行する形が基本で、取引処理の流れの中でのリアルタイム不正検出をアプリケーションに組み込む課題も解決しません。
【参考】
学習プログラム: モノリスを GKE アプリに変換する - 概要 | Google Kubernetes Engine (GKE)Pub/Sub とはAgent Platform の概要