Deep Dive: AI / ML

📚公式ドキュメント参照

本ページは以下の公式ドキュメントを技術的根拠としています。リンクは別タブで開きます。

1AI/ML 全体像 — ML パイプラインの 6 ステップ

AI/ML プロジェクトは「モデルを訓練して終わり」ではなく、データから推論・監視・再学習までを連続したライフサイクルとして運用する必要があります。Google Cloud では Vertex AI を中核に、各ステップに対応するマネージドサービスを提供しています。

1.1 各ステップの責務と Google Cloud マッピング

1.2 試験での出題パターン

• パターン A: 「データサイエンティストが Notebook で手作業実行 → 再現性なし」 → Vertex AI Pipelines + Metadata で自動化
• パターン B: 「モデルを年 1 回しか更新していない、競合に劣後」 → Cloud Scheduler でトリガ + Pipelines で再学習
• パターン C: 「本番モデルが古いデータで学習されており、最近予測が外れる」 → Model Monitoring で Drift 検知 → 再学習

2GCP の AI/ML プロダクト分類 — 4 階層の使い分け

Google Cloud の AI/ML プロダクトは 「制御度（カスタマイズ性） × 開発工数」のトレードオフで 4 階層に整理できます。試験ではこの分類軸での選定問題が必ず出ます。

2.1 4 階層の比較表

2.2 プロダクト選定 決定ツリー（最重要）

2.3 試験での出題パターン

• パターン A: 「請求書から自動で金額・日付・取引先を抽出したい」 → Document AI Invoice Parser（Vision OCR ではない、Gemini でもない）
• パターン B: 「顧客の解約予測モデルを SQL アナリストが作りたい」 → BigQuery ML
• パターン C: 「社内ドキュメントを横断検索して回答する Chat 」 → Agent Builder + Vertex AI Search (Discovery AI)
• パターン D: 「自社独自の画像で品質検査モデル、コード書ける人がいない」 → AutoML Vision
• パターン E: 「数百億パラメータの LLM をゼロから事前学習」 → AI Hypercomputer + TPU v5p + Pathways

3Vertex AI 完全解剖 — 統合 ML プラットフォーム

Vertex AI は「データ準備からモデルデプロイ・監視までを 1 つの API/SDK で扱う統合プラットフォーム」です。公式は "unified, open platform for building, deploying, and scaling generative AI and machine learning" と定義しています。本章では主要 6 コンポーネントの内部構造と関係性を解剖します。

3.1 Workbench — Notebook 環境

Vertex AI Workbench は JupyterLab ベースの統合 Notebook 環境です。BigQuery と Cloud Storage に直接アクセスでき、conda 環境やカスタムコンテナをサポートします。idle shutdown でアイドル時間にインスタンスを自動停止し、コストを抑えられます。

• Instances: Google 管理、自動アップグレード、CMEK / VPC SC 対応 (推奨)
• User-managed Notebooks（レガシー）: ユーザー側で OS パッケージを管理可能だが、運用負荷が高い
• 制限: 3rd-party JupyterLab 拡張は非対応、VPC SC 環境では Executor 機能が一部制限

3.2 Feature Store — 特徴量の中央リポジトリ

機械学習特徴量を「Training と Serving の両方で同一定義」で使うための中央リポジトリです。Training-Serving Skew（学習時と推論時の特徴量分布差）の主要因を構造的に防ぐのが目的です。

3.3 Model Registry — モデルのバージョン管理

AutoML / Custom Training / BigQuery ML / 3rd-party モデルを一元管理する中央リポジトリです。バージョン、エイリアス（champion / candidate など）、ラベル、Model Card を保持し、Endpoint への直接デプロイをサポートします。

• バージョニング: 同一モデル ID 配下で複数バージョン管理、各バージョンに評価メトリクスを付与
• エイリアス: default、champion、candidate など可変ポインタ → コードを変えずに切替
• Lineage 追跡: どのデータ・どの Pipeline 実行から生成されたか Vertex ML Metadata に記録
• Endpoint 連携: モデル詳細ページから直接 Endpoint にデプロイ、Batch Prediction も設定可

3.4 Vertex AI Training — AutoML と Custom の使い分け

3.5 Vertex AI Experiments と Vizier

• Experiments: 学習試行を「run」単位で記録、メトリクス・パラメータ・Artifact を比較可
• TensorBoard 統合: ロギングをそのまま可視化
• Vizier: ベイズ最適化ベースの HPO サービス、独立利用も可

from google.cloud import aiplatform

aiplatform.init(project="my-project", location="us-central1",
                staging_bucket="gs://my-staging")

job = aiplatform.CustomContainerTrainingJob(
    display_name="train-llm",
    container_uri="us-central1-docker.pkg.dev/my-project/train-images/llm:v1",
    command=["python", "train.py"],
    model_serving_container_image_uri="us-docker.pkg.dev/vertex-ai/prediction/pytorch-gpu.2-3:latest",
)

model = job.run(
    machine_type="a3-highgpu-8g",
    accelerator_type="NVIDIA_H100_80GB",
    accelerator_count=8,
    replica_count=4,           # multi-node training
    args=["--epochs", "10"],
    service_account="train-sa@my-project.iam.gserviceaccount.com",
    enable_web_access=True,
)

# Model Registry に自動登録される
print(model.resource_name)

3.6 試験での出題パターン

• パターン A: 「学習時と推論時で特徴量計算ロジックが食い違い精度劣化」 → Feature Store で特徴量定義を一元化
• パターン B: 「本番モデルがどのデータで学習されたか追えない」 → Model Registry + Vertex ML Metadata で Lineage 記録
• パターン C: 「データサイエンティストの個別 Notebook で実験、再現不能」 → Workbench + Pipelines + Experiments で標準化

4Vertex AI Pipelines 詳細＆事故ケース

Vertex AI Pipelines は "a portable and extensible description of an MLOps workflow as a series of steps" をサーバーレスで実行するオーケストレーション基盤です。Kubeflow Pipelines (KFP) と TensorFlow Extended (TFX) の 2 つのフレームワークをサポートし、DAG（有向非環グラフ）でタスクを並列実行します。

4.1 アーキテクチャと主要概念

Pipeline

DAG 全体の定義。Python DSL で書き、コンパイルすると YAML（IR）になる

Component

1 ステップの単位。Python 関数または独自コンテナ。入出力スキーマと実行ロジックを含む

Task

Component の実行インスタンス。1 つの Component が複数 Task になることもある（並列ファンアウト）

Artifact

Task が生成・消費するデータ。Dataset / Model / Metrics などの型を持つ

Metadata

Vertex ML Metadata に Pipeline 実行、パラメータ、Artifact が記録される

Lineage

ある Artifact がどの実行から生成され、何を入力としたかを遡れる。再現性・監査の要

Caching

同一入力なら過去の Artifact を再利用 (デフォルト ON)。コスト・時間を大幅削減

4.2 ライフサイクル

1. 定義: Python DSL で @dsl.component と @dsl.pipeline を書く
2. コンパイル: kfp.compiler.Compiler().compile(my_pipeline, "pipeline.yaml")
3. 実行 (Submit): aiplatform.PipelineJob(...).run(service_account=...)
4. 監視・可視化: Console で DAG・ログ・Artifact・Lineage グラフを確認
5. 停止 / 削除: 必要に応じて

from kfp import dsl
from kfp import compiler

@dsl.component(base_image="python:3.11", packages_to_install=["pandas","scikit-learn"])
def train_op(data_path: str, model_path: dsl.OutputPath("Model")):
    import pandas as pd, joblib
    from sklearn.linear_model import LogisticRegression
    df = pd.read_csv(data_path)
    X, y = df.drop(columns=["label"]), df["label"]
    clf = LogisticRegression().fit(X, y)
    joblib.dump(clf, model_path)

@dsl.pipeline(name="train-pipeline")
def my_pipeline(data_path: str):
    train_op(data_path=data_path)

compiler.Compiler().compile(my_pipeline, "pipeline.yaml")

# Submit
from google.cloud import aiplatform
aiplatform.init(project="my-project", location="us-central1")
job = aiplatform.PipelineJob(
    display_name="train-job",
    template_path="pipeline.yaml",
    parameter_values={"data_path": "gs://bkt/train.csv"},
)
job.submit(service_account="pipeline-sa@my-project.iam.gserviceaccount.com")

4.3 料金体系

• Pipeline 実行費用: 1 回あたり $0.03 / 実行（オーケストレーション料金）
• + Task の計算リソース: 各 Component が使う Vertex Training / VM / TPU の従量課金
• + Artifact ストレージ: GCS / Vertex ML Metadata の保存料金
• Caching を ON にすると同一入力の Task はスキップされ Task 料金がかからない

4.4 事故ケース集

4.5 CI/CD 統合パターン

Pipeline 自体を CI/CD で管理することで MLOps が成立します。代表的な構成：

1. Git push → Cloud Build トリガ
2. Build で kfp compile → pipeline.yaml を Artifact Registry にアップロード
3. Cloud Build で aiplatform.PipelineJob.submit() を実行（または Cloud Scheduler で定期）
4. Pipeline 完了後、Model Registry に新バージョンが登録される
5. Endpoint に Canary デプロイ（Traffic Split 5% → 50% → 100%）

4.6 試験での出題パターン

• パターン A: 「Pipeline 実行を毎晩自動化したい」 → Cloud Scheduler + Pub/Sub + Cloud Functions で PipelineJob.submit()
• パターン B: 「同じ Pipeline を何度も実行するがコストが高い」 → Caching を有効化、変化のない Component はスキップ
• パターン C: 「複数チームで Pipeline を共有して再利用したい」 → Component を再利用可能な単位で分割、Artifact Registry に登録

5Vertex AI Endpoints (オンライン推論)＆事故ケース

Endpoints は同期的な低レイテンシ推論を提供する API エンドポイントです。公式は "synchronous requests made to a model that is deployed to an Endpoint" と定義しています。1 つの Endpoint に複数モデルをデプロイし Traffic Split で振り分けられるのが特徴で、Canary / Blue-Green / Shadow デプロイの基盤になります。

5.1 主要構成要素

Endpoint

論理的な推論 URL。複数の Deployed Model を持てる

Deployed Model

Endpoint にデプロイされた個別モデルバージョン。マシンタイプ、min/max replicas、アクセラレータを持つ

Traffic Split

Endpoint 内の Deployed Model 間のトラフィック比率（合計 100%）

Public Endpoint

インターネット公開、IAM 認証で保護

Private Endpoint

Private Service Connect 経由（推奨）、または VPC Peering 経由

Dedicated Public

マルチテナント混在を避ける専用 public エンドポイント（推奨）

5.2 Auto-scaling の挙動

Endpoint の Deployed Model ごとに min_replica_count と max_replica_count を設定します。スケーリングは CPU 使用率 / GPU 使用率 / アクセラレータ使用率に基づき、min=0 は LLM 系の一部マネージドモデルのみ対応で、カスタムモデルは原則 min ≥ 1 です。

5.3 Traffic Split で実現するデプロイ戦略

5.4 事故ケース集

5.5 マシンタイプとアクセラレータ選定

from google.cloud import aiplatform

aiplatform.init(project="my-project", location="us-central1")

endpoint = aiplatform.Endpoint.create(display_name="prod-endpoint")

# Champion デプロイ
endpoint.deploy(
    model=aiplatform.Model("projects/.../models/123/versions/champion"),
    machine_type="n1-standard-4",
    min_replica_count=1,
    max_replica_count=10,
    traffic_split={"0": 100},  # 100% to first deployed model
)

# Challenger を 5% で投入
endpoint.deploy(
    model=aiplatform.Model("projects/.../models/123/versions/candidate"),
    machine_type="n1-standard-4",
    min_replica_count=1,
    max_replica_count=5,
    traffic_split={"existing-deployed-id": 95, "0": 5},
)

5.6 Online vs Batch Prediction の決定ツリー

5.7 試験での出題パターン

• パターン A: 「夜間に 1 億件のレコードを推論したい」 → Batch Prediction（Online ではない）
• パターン B: 「新モデルを安全にデプロイしたい」 → Traffic Split で Canary、メトリクス監視ゲート
• パターン C: 「Endpoint をプライベート IP 経由でアクセスしたい」 → Private Service Connect Endpoint

6Model Monitoring 詳細

Vertex AI Model Monitoring は 本番モデルの特徴量分布変化を継続的に監視し、Skew / Drift / Feature Attribution の異常をアラートするサービスです。公式は "tracks tabular model quality by detecting data deviations" と定義しています。

6.1 検知する 3 種類の異常

6.2 仕組みとアラート閾値

• Categorical 特徴量: L-infinity 距離（最大カテゴリ確率差）で評価
• Numerical 特徴量: Jensen-Shannon 発散で評価
• デフォルト閾値: 0.3 (調整可能)
• サンプリングレート: 推論リクエストの一部のみ記録（コスト最適化）
• アラート通知: Cloud Logging に出力 → Cloud Monitoring Alert Policy で Pub/Sub / Email 通知

6.3 v1 と v2 の違い

6.4 事故ケース集

6.5 試験での出題パターン

• パターン A: 「本番モデルの精度が時間とともに低下、何を導入すべきか」 → Model Monitoring (Prediction Drift)
• パターン B: 「学習データと本番データの分布差を検知したい」 → Training-Serving Skew detection
• パターン C: 「コスト削減のためモニタリングデータをサンプリング」 → Sampling rate を 0.1 などに設定

7Gemini モデルファミリー

Gemini は Google の最新マルチモーダル基盤モデル群です。「Pro / Flash / Flash-Lite / Nano」を中心に、用途・コスト・コンテキスト長で使い分けます。Vertex AI 上では Gemini API（Managed）として提供され、Token 単位課金（input/output 別）です。

7.1 主要モデルの比較表

7.2 モデル選定 決定ツリー

7.3 Token 経済とコンテキスト戦略

• 1 トークン ≒ 4 文字（英語） / 1〜2 文字（日本語） の目安
• Input / Output で料金が違う。一般に Output が 3〜4 倍高い
• Context Caching: 長いシステムプロンプトを再利用する場合、Vertex AI のキャッシュ機能でコスト 75% 削減
• Batch API: 非リアルタイム処理は Batch エンドポイントで 50% 割引

7.4 事故ケース集

7.5 Provisioned Throughput と Token 経済の試算

Gemini API は標準で「従量課金」ですが、高負荷・SLO 要件では Provisioned Throughput (PT) で容量を予約できます。GSU（Generative AI Scale Unit）単位で購入し、月額固定でスロットリングを回避します。

• 従量課金: 使った分だけ、Token 単位。低トラフィック・予測不能ワークロード向き
• PT (Provisioned Throughput): GSU を月単位で予約。SLO 厳守・大量利用で総コストが安くなる損益分岐点あり

from google import genai
from google.genai import types

client = genai.Client(vertexai=True, project="my-project", location="us-central1")

# 長い system prompt をキャッシュ化
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        system_instruction="あなたは契約書レビューの専門家です...（長いプロンプト）",
        contents=[types.Content(role="user", parts=[types.Part(file_data=...)])],
        ttl="3600s",
    ),
)

# 以後のリクエストはキャッシュ参照（コスト 75% 削減）
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="この契約書の第 3 条の問題点は？",
    config=types.GenerateContentConfig(cached_content=cache.name),
)

7.6 試験での出題パターン

• パターン A: 「コールセンターの 1 日 100 万件の会話を要約、コスト最優先」 → Gemini Flash + Batch API
• パターン B: 「契約書 PDF を解析して条項抽出」 → Gemini Pro（マルチモーダル PDF）+ Function Calling
• パターン C: 「アプリ内で完全オフライン動作」 → Gemini Nano（オンデバイス）

8Model Garden — 1st-party + 3rd-party モデルカタログ

Model Garden は Google 製モデル（Gemini / Imagen / Veo / Gemma）と、Meta・Anthropic・Mistral・Hugging Face などのサードパーティモデルを Vertex AI 上で使えるカタログサービスです。「Managed API（Google 側で運用）」と「Self-deploy（自分の Endpoint にデプロイ）」の 2 形式があります。

8.1 主要モデルの分類

8.2 Managed API vs Self-deploy の決定ツリー

8.3 事故ケース集

8.4 試験での出題パターン

• パターン A: 「自社データで Fine-tuning + VPC 内完結したい」 → Model Garden Self-deploy（Llama / Gemma）
• パターン B: 「Claude のような外部 LLM を Google Cloud 上で使いたい」 → Model Garden の Anthropic Managed API
• パターン C: 「複数モデルを比較評価したい」 → Model Garden + Vertex AI Experiments で A/B 評価

9AI Hypercomputer 完全解剖

AI Hypercomputer は 「パフォーマンス最適化ハードウェア、オープンソフトウェア、主要 ML フレームワーク、柔軟な消費モデルを提供するスーパーコンピューティングシステム」です。TPU/GPU といったアクセラレータ、Jupiter NW（インターコネクト）、Pathways（分散学習ランタイム）、DWS（消費モデル）の 4 層から成ります。

9.1 TPU 世代比較

9.2 GPU 世代比較

9.3 Pathways — 分散学習ランタイム

Pathways は Google が開発した マルチホスト・マルチデバイスでの分散実行を抽象化する ML フレームワークです。1 つの JAX プログラムを数千チップに自動分散します。

• Data Parallelism: 同じモデルを複数チップに複製、バッチを分割
• Tensor Parallelism: 1 層内の行列演算をチップ間で分割
• Pipeline Parallelism: 層をチップに分割、マイクロバッチで流す
• Expert Parallelism (MoE): Mixture of Experts を異なるチップに配置

9.4 消費モデル（コスト戦略の核）

9.5 事故ケース集

9.6 Pathways と JAX による分散学習サンプル

# JAX / Flax + Pathways で TPU Pod スライスに分散
import jax
from jax import numpy as jnp
from jax.sharding import Mesh, NamedSharding, PartitionSpec as P

# Device mesh: 2D (data x model parallel)
devices = jax.devices()  # TPU v5p の chip 群
mesh = Mesh(devices.reshape(8, 32), axis_names=("data", "model"))

# Shard 戦略
sharding = NamedSharding(mesh, P("data", "model"))

# Parameter を 32-way model parallel + 8-way data parallel に
@jax.jit
def train_step(params, batch):
    loss, grads = jax.value_and_grad(loss_fn)(params, batch)
    new_params = jax.tree.map(lambda p, g: p - 1e-3 * g, params, grads)
    return new_params, loss

# Multi-host: Pathways が複数 VM 跨ぎで自動分散
# キーは「pjit + Mesh + sharding spec」で表現

9.7 試験での出題パターン

• パターン A: 「数十億パラメータ LLM をゼロから学習」 → TPU v5p Pod + Pathways + Reserved
• パターン B: 「中断許容のバッチ推論を最安で」 → Spot TPU v5e
• パターン C: 「来月の特定週にまとめて学習したい」 → DWS Calendar Mode で予約

10Vertex AI Agent Builder / Gemini Enterprise

Agent Builder は RAG・Function Calling・社内ドキュメント検索を含む AI エージェントアプリを組み立てるための統合サービスです。Gemini Enterprise は企業向けにブランディングされた製品名で、Agentspace（エージェントポータル）、NotebookLM Enterprise、Vertex AI Search（旧 Discovery AI）を統合します。

10.1 主要コンポーネント

Agents

LLM ベースの自律エージェント。Tool（API呼び出し）とプランニング機能で多段タスク実行

Vertex AI Search

旧 Discovery AI。エンタープライズ検索 + RAG 基盤。Data Store に PDF/HTML/構造化データを取り込み、Gemini が引用付きで回答

NotebookLM Enterprise

アップロードしたソースのみを根拠に質問応答する Notebook 型 RAG。VPC SC / CMEK 対応

Agentspace

従業員向けエージェントポータル。複数エージェントを統合表示、社内検索 + アプリ操作

Function Calling

LLM が API 呼び出しを構造化 JSON で発行、アプリ側が実行して結果を返す

Grounding

Google Search や Data Store を根拠にハルシネーション抑制

10.2 事故ケース集

10.3 試験での出題パターン

• パターン A: 「社内ドキュメントを引用付きで検索する Chat」 → Vertex AI Search + Gemini Grounding
• パターン B: 「研究者がアップロードした論文だけで Q&A」 → NotebookLM Enterprise
• パターン C: 「複数の社内 SaaS を統合した従業員向けポータル」 → Agentspace + Agent Builder

11Pre-trained AI APIs

事前学習済みモデルを API として提供するサービス群です。学習不要・コードを書くだけで即運用でき、「汎用タスクで自社モデルを作る必要がない」ケースの第一選択です。

11.1 主要 API 一覧

11.2 選定の決定ツリー

11.3 事故ケース集

11.4 Document AI の詳細（試験頻出）

Document AI は OCR ではなく「文書理解」プラットフォームです。プロセッサごとに特化しています。

from google.cloud.speech_v2 import SpeechClient
from google.cloud.speech_v2.types import cloud_speech

client = SpeechClient()
config = cloud_speech.RecognitionConfig(
    auto_decoding_config=cloud_speech.AutoDetectDecodingConfig(),
    language_codes=["ja-JP"],
    model="chirp_2",   # 多言語汎用
    features=cloud_speech.RecognitionFeatures(
        enable_automatic_punctuation=True,
        diarization_config=cloud_speech.SpeakerDiarizationConfig(
            min_speaker_count=2, max_speaker_count=4,
        ),
    ),
)
request = cloud_speech.RecognizeRequest(
    recognizer=f"projects/my-project/locations/global/recognizers/_",
    config=config,
    uri="gs://my-bucket/call.wav",
)
response = client.recognize(request=request)
for result in response.results:
    print(result.alternatives[0].transcript)

11.5 試験での出題パターン

• パターン A: 「請求書の自動データ化」 → Document AI（Vision OCR ではない）
• パターン B: 「コールセンター録音の文字起こし」 → Speech-to-Text + Speaker Diarization
• パターン C: 「ユーザ生成コンテンツの不適切画像検出」 → Vision API SafeSearch

12Responsible AI / Model Armor / Sensitive Data Protection

LLM・生成 AI を業務に組み込む際は プロンプトインジェクション / ジェイルブレイク / データ漏洩 / 有害コンテンツ生成のリスクに対するガードレールが必須です。Google Cloud は以下のレイヤーで防御します。

12.1 防御スタック

12.2 Model Armor の主要機能

• Prompt Injection 検知: 「過去の指示を無視」のようなパターンを検出
• Jailbreak 検知: モデルの安全性を回避するプロンプトを検出
• 有害コンテンツ検知: Hate / Sexually Explicit / Violence / Harassment 等
• PII 検出: 氏名・電話・クレカ番号等の検出と Redact
• Malicious URL 検知: フィッシング URL のフィルタ
• 対応モデル: Gemini, Model Garden の主要 LLM, Self-deploy モデル

12.3 事故ケース集

12.4 Gemini Safety Filter の設定

12.5 試験での出題パターン

• パターン A: 「LLM 入力からプロンプトインジェクションを防ぐ」 → Model Armor
• パターン B: 「Vertex AI を VPC 内で完結させたい」 → VPC Service Controls + Private Service Connect
• パターン C: 「PII を含むデータを LLM に渡す前に除去」 → Sensitive Data Protection (DLP) で de-identify

13コスト管理＆運用

AI/ML はインフラ・データ・推論コール全てが課金対象となり、油断すると即座に予算超過します。本章では サービス別の料金構造と落とし穴、防御策を整理します。

13.1 サービス別の主要コスト要因

13.2 コスト最適化チェックリスト

1. Spot TPU / GPU 活用: 中断許容可能なバッチ学習・推論は Spot で最大 91% 削減
2. DWS で予約待ち化: 即時開始不要なら DWS で確保性とコストを両立
3. Batch Prediction を活用: オンライン不要なら Batch へ（コスト 1/5〜1/10）
4. モデル量子化 / 蒸留: INT8 量子化で推論メモリと速度を改善
5. Pre-trained API のリージョン選定: クライアントに近いリージョンでレイテンシ・転送料金削減
6. Custom Quota で暴走防止: プロジェクト単位で API 上限を固定
7. Budget Alert と Pub/Sub 通知: 50% / 80% / 100% で自動通知＋Cloud Function で停止
8. Context Caching（Gemini）: 共通プロンプトはキャッシュで 75% 削減
9. Gemini Flash へフォールバック: 簡易タスクは Flash で十分
10. Endpoint の min=0 適用（可能なモデルのみ）: 低頻度推論
11. Pipelines Caching ON: 同一入力 Task の再実行を回避
12. Workbench idle shutdown: 30 分非アクティブで自動停止

13.3 運用モニタリング指標

13.4 試験での出題パターン

• パターン A: 「Vertex AI のコスト超過、最初に確認すべきは？」 → Endpoint の min_replica と未使用 Endpoint
• パターン B: 「学習コストを削減したい、中断許容可能」 → Spot TPU / Preemptible
• パターン C: 「Gemini API のコスト最適化」 → Context Caching + Batch API + Flash へフォールバック

14MLOps 全体ベストプラクティス

本章は AI/ML を本番運用する上での横断的ベストプラクティスを整理します。試験では「サイレント精度劣化を防ぐには」「再現性のある学習を行うには」のような問題で問われます。

14.1 モデルライフサイクル管理

14.2 データ・モデル Lineage

• Vertex ML Metadata: Pipeline 実行・Artifact・Lineage を自動記録
• Artifact Registry: 学習用カスタムコンテナ、Pipeline YAML をバージョン管理
• GCS Object Versioning: 学習データの世代管理
• BigQuery Snapshot: 学習に使った時点のデータをスナップショット保存
• Dataform / Dataplex: データ系統と品質管理

14.3 再学習トリガの設計

14.4 セキュリティ ベストプラクティス

• VPC Service Controls: Vertex AI を含む API 境界を作成、データ exfiltration 防止
• CMEK: 学習データ・モデル・推論ログを顧客管理キーで暗号化
• Workload Identity: SA Key を排除、メタデータサーバ経由で短命トークン
• Model Armor: LLM の入出力フィルタリング（プロンプトインジェクション・PII）
• IAM Recommender: 過剰権限を定期検出、Least Privilege 維持
• Audit Logs: モデル操作・推論コールを全記録
• Org Policy: 許可リージョン制限、CMEK 必須、Public IP 禁止

14.5 試験での出題パターン

• パターン A: 「サイレント精度劣化を防ぐ」 → Model Monitoring + KPI 監視 + 再学習 Pipeline
• パターン B: 「学習の再現性を担保」 → Pipelines + Metadata Lineage + GCS Versioning
• パターン C: 「データ漏洩を防ぐ」 → VPC SC + CMEK + Model Armor + DLP

15試験頻出パターン（ケーススタディ別）

PCA 試験のケーススタディ（Altostrat Media / EHR Healthcare / TerramEarth / Cymbal Retail 等）でよく出る AI/ML 関連の典型構成を整理します。

15.1 メディア / コンテンツ系（Altostrat Media）

15.2 ヘルスケア / 規制業界（EHR Healthcare）

15.3 製造 / IoT（TerramEarth）

15.4 小売 / EC（Cymbal Retail）

15.5 金融

16アンチパターン総集編

本章は「公式ドキュメント / ベストプラクティスに反する典型ミス」を集約します。試験では「何が間違っているか」を問う形式で頻出します。

17クォータと制限の一覧

主要サービスのデフォルトクォータと注意点を一覧化します。実数は変動するため、本番設計時は 公式 Quotas ページで最新を確認してください。

17.1 Vertex AI 系

17.2 Gemini API

17.3 TPU / GPU

17.4 Pre-trained API