Vertex AI

解決する課題

• 機械学習のデータ準備・学習・評価・デプロイ・監視が個別ツールに分散し、運用が煩雑になる
• 学習済みモデルを本番でスケーラブルに配信し、低レイテンシで予測を返したい
• コードを書かずに、または最小限の労力で高品質なモデルを素早く作りたい
• 生成 AI（Gemini などの基盤モデル）を安全に業務へ組み込み、検索拡張や微調整で自社データに適合させたい
• 実験・モデル・特徴量・パイプラインを一元管理してチームで再現性を保ちたい

主要概念と用語

• Vertex AI: 従来型 ML（予測モデルの学習・配信）と生成 AI（基盤モデルの呼び出し・チューニング）を統合したマネージド AI 基盤。AWS の SageMaker と Bedrock の役割を併せ持つ
• Model Garden: Google 製・サードパーティ製・オープンソースの基盤モデルを探して試せるカタログ。AWS Bedrock のモデル選択画面に近い
• Gemini API: Vertex AI 上でマルチモーダルの生成 AI モデルを呼び出すための API。テキスト・画像・音声などを扱える
• AutoML: 表・画像・テキストなどに対し、コードを書かずにモデルを自動学習する仕組み
• カスタム学習 (Custom Training): 自前のコンテナやスクリプトで任意のフレームワーク（TensorFlow・PyTorch など）を使って学習する方式
• エンドポイント (Endpoint): 学習済みモデルをデプロイしてオンライン予測（リアルタイム推論）を提供する宛先。常時稼働する配信先
• バッチ予測 (Batch Prediction): 大量データに対し、エンドポイント常駐なしでまとめて推論を実行する方式
• Feature Store: 特徴量を一元管理し、学習時と推論時で一貫した値を供給する仕組み
• Pipelines: 前処理・学習・評価・デプロイの各ステップを DAG として定義し、自動実行・再現する ML ワークフロー基盤
• Model Registry: モデルとそのバージョンを登録・管理する台帳
• Grounding（グラウンディング）: 生成結果を Google 検索や自社データに根拠付けしてハルシネーションを抑える仕組み

仕様・制限・クォータ

• リージョン単位で動作するサービスが多く、データの所在地やモデルの提供リージョンを設計時に確認する必要がある
• オンライン予測のエンドポイントはマシンタイプとレプリカ数を指定して配信する。最小・最大レプリカ数によるオートスケールを設定できる
• 生成 AI モデルには入力・出力のトークン上限や、プロジェクト単位のリクエスト/分・トークン/分といったレート制限がある。これらは定性的に「上限がある」と捉え、最新値はコンソールのクォータ画面で確認する
• カスタム学習では使用できる**アクセラレータ（GPU・TPU）**の種類と数にクォータがあり、増枠申請が必要になることがある
• バッチ予測・学習ジョブには同時実行数や入力サイズの制約がある
• 具体的な数値・上限・対応モデルは更新が頻繁なため、断定せず公式ドキュメントとクォータ画面で都度確認する

内部の仕組み

Vertex AI は、共通のメタデータ層（実験・モデル・特徴量・パイプラインの記録）の上に、学習・配信・生成 AI の各機能が乗る構成です。学習では、AutoML またはカスタムコンテナのジョブがマネージドな計算クラスタ上で実行され、生成物が Model Registry に登録されます。配信では、登録モデルをエンドポイントにデプロイすると、背後で割り当てられたマシン群がリクエストを受け、設定に応じてレプリカがオートスケールします。常時稼働が不要な大量推論はバッチ予測ジョブが入力ストレージを読み、結果を出力先へ書き戻します。

生成 AI では、Gemini などの基盤モデルが Google 側のマネージド基盤でホストされ、利用者は API 経由で呼び出します。自社データへの適合は、**プロンプト設計・グラウンディング・チューニング（微調整）**といった段階で行います。Pipelines はこれら一連のステップをコンテナ化したコンポーネントの DAG として実行し、各実行の入出力とアーティファクトをメタデータとして残すため、再現と監査が可能になります。

設計パターン / ベストプラクティス

• 用途で学習方式を選ぶ: 素早く標準的なモデルが欲しいなら AutoML、独自フレームワークや細かな制御が要るならカスタム学習
• 学習と推論で特徴量を一致させる: オンライン/オフラインの差異（トレーニング・サービングスキュー）を避けるため Feature Store で特徴量を共有する
• 常時 vs まとめて: 低レイテンシのリアルタイム応答はエンドポイント、夜間の大量処理はバッチ予測でコストを抑える
• 生成 AI は根拠付けを前提に: 業務利用では Grounding や検索拡張（自社データ参照）でハルシネーションを抑え、出力を検証可能にする
• ワークフローを Pipelines で固める: 手作業を排し、前処理から評価・デプロイまでを再現可能なパイプラインにする
• 段階的にデプロイ: 新バージョンはトラフィック分割で一部に流し、品質を見てから全面切り替えする

運用・監視

• Cloud Monitoring / Cloud Logging で推論リクエスト数・レイテンシ・エラー率を監視し、エンドポイントの健全性を把握する
• Model Monitoring で入力データの分布のずれ（データドリフト）や予測ドリフトを検知し、再学習の判断材料にする
• エンドポイントのレプリカ数とマシンタイプを負荷に合わせて調整し、レイテンシとコストのバランスを取る
• 学習・パイプラインの実行履歴とアーティファクトをメタデータとして残し、障害時の原因追跡と再現を容易にする
• 生成 AI ではトークン消費量とレート制限の到達状況を監視し、必要に応じてクォータ増枠やリトライ設計を行う

コスト

セキュリティ

• IAM でデータ・モデル・エンドポイント・パイプラインへのアクセスを最小権限に分離する（AWS の IAM ロール相当）
• 学習・推論のワークロードにはサービスアカウントを割り当て、認証情報のハードコードを避ける
• 保存データは Google 管理鍵で既定暗号化され、要件に応じて CMEK（顧客管理鍵、Cloud KMS） を適用できる
• VPC Service Controls でデータ境界を作り、エンドポイントや学習ジョブからの外部流出を防ぐ。Private Service Connect / 限定公開アクセスで内部からのみ到達させる構成も取れる
• 生成 AI ではプロンプトインジェクションや機微情報の流出に備え、入力検証・出力フィルタ・データの取り扱いポリシーを設計に組み込む

Well-Architected の観点

• パフォーマンス効率: 用途に応じて AutoML とカスタム学習、オンラインとバッチを使い分け、GPU/TPU やレプリカ数を適正化する。エンドポイントのオートスケールで負荷変動に追従する
• 運用上の優秀性: Pipelines と Model Registry、メタデータで ML ワークフローを自動化・再現可能にし、Model Monitoring でドリフトを検知して継続的に改善する（MLOps）
• これらは Google Cloud の Well-Architected Framework が重視する性能効率と運用の柱に直結する。データやモデルの一元管理は再現性と監査性を高め、運用負荷を下げる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) 利用可能なリージョンを指定（例: 東京）して設定
gcloud config set ai/region asia-northeast1

# 2) モデルを Model Registry にアップロード（事前学習済みコンテナの例）
gcloud ai models upload \
  --display-name=my-model \
  --container-image-uri=asia-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-3:latest \
  --artifact-uri=gs://MY_BUCKET/model/

# 3) オンライン予測用のエンドポイントを作成
gcloud ai endpoints create --display-name=my-endpoint

# 4) モデルをエンドポイントにデプロイ（オートスケール設定つき）
gcloud ai endpoints deploy-model ENDPOINT_ID \
  --model=MODEL_ID \
  --display-name=my-deploy \
  --machine-type=n1-standard-2 \
  --min-replica-count=1 \
  --max-replica-count=3

# 5) エンドポイント一覧で確認
gcloud ai endpoints list --region=asia-northeast1