PCA 合格対策

セクション 2:
クラウドソリューションインフラの管理とプロビジョニング

試験全体の約 1/6 を占める実装寄りセクション。ネットワーク構築、ストレージ運用、コンピュート稼働、Vertex AI ワークフロー、プリビルト AI 統合を実務目線で問われます。VMware Engine(GCVE)、AI Hypercomputer、Gemini Enterprise は 2025 年改訂で追加された最新項目です。

📊 出題 17.5% 🔧 実装・運用 🤖 AI/ML プロビジョニング 🆕 GCVE / AI Hypercomputer / Gemini Enterprise
📘 基礎 🔧 応用 🎯 要点と暗記
🔑 TL;DR — このセクションの要約 ネットワークは VPC グローバル / Subnet リージョン、Cloud NAT・Private Google Access・PSC で外部 IP なしでも GCP API へ。LB は Global External Application LB が第一候補。ストレージは Autoclass + Lifecycle + Retention Policy + Bucket Lock でコストとコンプラを両立。コンピュートは GKE Autopilot + Workload Identity が現代の標準、Cloud Run + GPU も登場。VMware は GCVE + HCX でそのまま移行。AI 系は Vertex AI Pipelines / AI Hypercomputer(TPU + GPU + Pathways)/ Gemini Enterprise / Model Garden / Document AI を中心に出題。

🎯 学習目標

このセクションの達成度0 / 0








※ チェック状態はこのブラウザに保存されます。

🏗️ クラウドインフラ 5 レイヤー全体像

クラウドアーキテクトが扱うインフラを 5 レイヤー に分けて把握します。「プロビジョニング」は必要なリソースを必要な量・場所・タイミングで確保すること。GCP では宣言的に IaC(Terraform / Config Connector) で行うのが標準。

┌─────────────────────────────────────────────┐ │ 5. AI/ML レイヤー │ Vertex AI, Gemini, Model Garden, AI Hypercomputer ├─────────────────────────────────────────────┤ │ 4. アプリ / サーバーレス レイヤー │ Cloud Run, Cloud Run functions, App Engine ├─────────────────────────────────────────────┤ │ 3. コンピュート レイヤー │ Compute Engine, GKE, VMware Engine ├─────────────────────────────────────────────┤ │ 2. ストレージ レイヤー │ GCS, Persistent Disk, Cloud SQL, BigQuery ├─────────────────────────────────────────────┤ │ 1. ネットワーク レイヤー │ VPC, LB, Cloud Armor, Interconnect └─────────────────────────────────────────────┘

このセクションで問われる「判断軸」

判断軸試験で問われる例
ネットワーク到達性 vs セキュリティPrivate Google Access / Cloud NAT / VPC SC / PSC のどれを使うか
コンピュート選択GCE / GKE / Cloud Run / Cloud Run functions / VMware Engine のどれが最適か
コスト vs 可用性Spot vs Standard、Regional vs Multi-region
データ保持 vs 削除Lifecycle / Retention Policy / Bucket Lock / Object Versioning の使い分け
AI ワークロードのスケールVertex AI Endpoints vs Batch、TPU vs GPU、Custom vs Pre-trained API
既存資産の活用VMware Engine(VMware 維持) vs Migrate to VMs(仮想化解除)

2.1 ネットワークトポロジーの構成

VPC の基本

VPC ネットワークはグローバルリソース。AWS / Azure(リージョン単位)と違い、複数リージョンのサブネットを 1 つの VPC で扱えます。

VPC ネットワーク(グローバル) ├─ サブネット A(us-central1, 10.0.0.0/24) ├─ サブネット B(asia-northeast1, 10.0.1.0/24) ├─ Firewall Rules(VPC 全体に適用) ├─ Routes └─ Cloud Router(BGP 用)

サブネット設計

  • プライマリ範囲: VM IP の主範囲
  • セカンダリ範囲: GKE Pod / Service 用、Alias IP 用
  • 拡張可能: プライマリ範囲は後から拡張可(縮小不可)
⚠️ 試験頻出GKE で Pod 数が増える可能性 → セカンダリ範囲を広めに確保(後から縮小できない)。IP 枯渇時は GKE の Discontiguous Secondary Range で追加可能。

ファイアウォール 3 階層

優先順位(数値が小さいほど高優先): 0 ──── Hierarchical Firewall Policy(組織 / フォルダ) ↓ Network Firewall Policy(Global / Regional、新世代) ↓ 65535 ─ VPC Firewall Rules(implied deny ingress / allow egress)
ルール種別内容
VPC Firewall RulesVPC 単位、L4(IP/Port/Protocol)、Tag / SA 指定可
Hierarchical Firewall Policies組織 / フォルダ / プロジェクト階層で適用、上位で強制
Network Firewall Policiesグループ管理可能な次世代 FW、Geo-IP / Threat Intelligence 対応

外部接続パターン

サービス用途
Cloud NATプライベート VM がインターネットに egress(IP 共有)
Private Google Access外部 IP なしで googleapis.com にアクセス
Private Service Connect (PSC)プライベート IP で Google API / マネージドサービスへ
VPC Service Controls (VPC SC)API レベルでサービス境界(データ流出防止)

セキュリティ保護機能

Cloud Armor

L7 WAF、DDoS 防御、Geo-IP / Bot 対策、OWASP ルール。「SQL インジェクション / XSS 防御」→ Cloud Armor。

Cloud IDS

パケットミラーリング + 侵入検知(IDS / IDPS)。「侵入検知」→ Cloud IDS。

Identity-Aware Proxy (IAP)

アプリ前段でユーザー認証、TCP 転送(SSH / RDP も)。VPN なしで Web 公開できる。

Cloud DNS

内部 / 外部 DNS、Private Zone、DNSSEC 対応。

ハイブリッド / マルチクラウド接続マトリクス

接続方式帯域SLA (HA)暗号化用途
Dedicated Interconnect10 / 100 Gbps99.99%なし大規模直結
Partner Interconnect50 Mbps – 50 Gbps99.99%なし中規模・パートナー経由
Cross-Cloud Interconnect10 / 100 Gbps99.99%なしGCP ↔ AWS / Azure 直結
HA VPN最大 3 Gbps/トンネル99.99%あり(IPsec)中小規模・暗号化
Classic VPN最大 3 Gbps99.9%ありレガシー(非推奨)
Network Connectivity Center (NCC)ハブ&スポークで複数経路を統合

LB 7 種類

3 軸(スコープ × 公開範囲 × 方式)で 7 種類。Global External Application LB が最も汎用的な第一候補です。

用途推奨 LB
グローバル Web/APIGlobal External Application LB
TCP/UDP 直接、IP 保持Regional External Passthrough NLB
内部マイクロサービスInternal Application LB
マルチリージョン内部 APICross-region Internal Application LB

🔧 VPC 設計パターン(4 種)

パターン内容採用判断
Single VPC1 VPC に全リソース小規模、シンプル運用
Shared VPCホスト + サービスプロジェクト中央でネットワーク統制、各部署が独自プロジェクト
VPC Peering複数 VPC を 1:1 接続部門 / 会社境界、独立した管理
Hub-and-spoke (NCC)ハブ VPC + スポーク VPC大規模、リージョン横断、推移ルーティング
💡 判断のコツShared VPC は組織内、Peering は組織を跨ぐ場合。AWS では Transit Gateway が NCC に相当。

🔧 Cloud Armor 主要機能

機能用途
Edge Security PolicyCDN / 外部 LB 手前で WAF
OWASP ルールSQLi/XSS/LFI/RCE/Scanner 等の Pre-configured ルール
Adaptive ProtectionML ベースの自動 DDoS 防御
reCAPTCHA Enterprise 統合Bot 対策
Geo / IP 制限国別アクセス制御
Rate Limitingレート制限(throttle / ban)
Internet → Cloud Armor (Edge) → Global LB → Backend ↓ ・OWASP ルール ・Adaptive Protection ・Geo / IP / Rate Limiting

🔧 Private Service Connect (PSC) — 3 パターン

パターン用途
PSC for Google APIsgoogleapis.com にプライベート IP(restricted.googleapis.com)
PSC for Published Services自社サービスをエンドポイント化(マルチテナント SaaS 風)
PSC for Managed ServicesCloud SQL / Memorystore / AlloyDB 等にプライベート接続

🔧 LB 詳細選定フロー

公開 or 内部? 公開 → L7 (HTTP/HTTPS)? グローバル → Global External Application LB(最も推奨) リージョン固定 → Regional External Application LB L4 TCP/UDP? Anycast IP・プロキシ → Global External Proxy NLB 直接通信・IP 保持 → Regional External Passthrough NLB 内部 → L7 → Internal Application LB L7 + マルチリージョン → Cross-region Internal Application LB L4 → Internal Passthrough NLB

🔧 LB バックエンド種別

バックエンド用途
Instance GroupVM ベース(MIG 推奨)
NEG (Network Endpoint Group)サーバーレス、ハイブリッド、K8s Service
Serverless NEGCloud Run / Cloud Run functions / App Engine
Internet NEG外部 FQDN / IP(オンプレ / 他クラウド)
Hybrid NEGオンプレに直接ルーティング
Private Service Connect NEGPSC 経由のサービス

🔧 マルチクラウド / ハイブリッド設計の判断軸

状況推奨
通信量 < 1 Gbps、コスト重視HA VPN
通信量 1-10 Gbps、本番要件Partner Interconnect
通信量 10+ Gbps、低レイテンシ必須Dedicated Interconnect
AWS / Azure へ直結(VPN なし)Cross-Cloud Interconnect
複数オンプレ + 複数クラウド統合Network Connectivity Center (NCC)
99.99% SLA 必須2 Interconnect or 2 HA VPN を冗長構成

🎯 ネットワーク即答

用途答え
プライベート VM の egressCloud NAT
外部 IP なしで googleapis.comPrivate Google Access
プライベート IP で Google APIPSC for Google APIs
プライベート IP で Cloud SQLPSC for Managed Services
API レベルでデータ流出防止VPC Service Controls
L7 WAF / DDoSCloud Armor
自動 DDoS 防御Cloud Armor Adaptive Protection
侵入検知 (IDS)Cloud IDS
アプリ前段ユーザー認証Identity-Aware Proxy (IAP)
組織レベル FW 強制Hierarchical Firewall Policy
グループ管理 FWNetwork Firewall Policy
BGP 動的ルート交換Cloud Router
ハブ&スポーク統合Network Connectivity Center (NCC)
GCP ↔ AWS/Azure 直結Cross-Cloud Interconnect

2.2 個別ストレージシステムの構成

Cloud Storage — バケット作成時の主要設定

項目選択肢
場所タイプRegion(単一)/ Dual-region(2 リージョン同期)/ Multi-region(複数リージョン)
ストレージクラスStandard / Nearline / Coldline / Archive、または Autoclass
アクセス制御Uniform(IAM のみ・推奨)/ Fine-grained(IAM + ACL)
暗号化Google-managed(デフォルト)/ CMEK / CSEK

ライフサイクル管理

オブジェクトの 自動移行・削除 を定義。新規バケットは Uniform access + Autoclass が推奨。

{
  "lifecycle": {
    "rule": [
      { "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
        "condition": {"age": 30} },
      { "action": {"type": "Delete"},
        "condition": {"age": 365} }
    ]
  }
}

保持ポリシーとオブジェクトロック

機能内容
Retention Policyバケット全体に保持期間を設定(期間中は削除不可)
Bucket LockRetention Policy を永続化(解除不可、コンプラ用)
Object Versioning上書き / 削除時に旧版を保持
Object Hold個別オブジェクトをロック(Event-based / Temporary)
⚠️ 試験頻出「7 年の監査保持」→ Retention Policy + Bucket Lock + Archive クラス。

ブロックストレージ(Persistent Disk / Hyperdisk)

タイプ用途最大 IOPS最大スループット
PD Standard (pd-standard)コスト重視、HDD数千数百 MB/s
PD Balanced汎用、SSD数万数 GB/s
PD SSD高 IOPS100,000数 GB/s
PD Extreme超高 IOPS120,000数 GB/s
Hyperdisk Balanced次世代汎用、サイズと IOPS 独立160,0002,400 MB/s
Hyperdisk Throughputスループット重視(Hadoop など)数 GB/s
Hyperdisk Extreme超高 IOPS(SAP HANA など)350,0005,000 MB/s
Hyperdisk MLAI 学習、複数 VM 同時アタッチ1.2 TB/s(読込)
💡 Hyperdisk の特徴サイズと IOPS / スループットを独立して調整可能。PD は連動するので無駄が出やすい。AI ワークロードでは Hyperdisk ML(最大 2,500 VM 同時読込)。

ファイルストレージ(Filestore)

NFS v3 互換のマネージドファイルシステム。複数 VM から共有マウントする場合に使用。

  • Basic HDD: 低コスト、汎用
  • Basic SSD: 高性能、汎用
  • Zonal: ゾーン冗長、ホームディレクトリ
  • Regional: リージョン冗長、HA 用
  • Enterprise: リージョン冗長 + 高可用、本番ファイル共有

データベース運用設定

サービス高可用構成バックアップリストア
Cloud SQLHA 構成(同期スタンバイ)自動バックアップ + BinlogPITR(任意時点、7-35 日)
AlloyDBプライマリ + 4 リードプール連続バックアップPITR
Spannerデフォルトで複数ゾーンバックアップ + Backup Schedules別インスタンスへ復元
Bigtable同期 / 非同期レプリケーション増分バックアップテーブル単位リストア
Firestoreデフォルトで複数ゾーンスケジュールエクスポート同モードへインポート

Backup and DR Service(旧 Actifio)

VM・DB・GKE・ファイルシステムを統合的にバックアップ。

  • アプリケーション整合性のあるスナップショット
  • クロスリージョンレプリケーション
  • インスタントマウントで素早く復旧
  • VMware Engine、Compute Engine、Cloud SQL、GKE PV をサポート

🔧 Cloud Storage クラス選定(コスト最適化)

クラス月額 ストレージアクセス料早期削除料適用例
Standard無料なしアクセス頻繁
Nearlineあり30 日以内削除でペナルティ月次レポート
Coldlineあり90 日以内四半期バックアップ
Archive最低365 日以内法的保管
💡 Autoclassアクセスパターンに応じ 自動でクラス変更。手動ライフサイクル不要。新規バケットで有効化推奨。

🔧 オブジェクトロックの使い分け

機能撤回可能性用途
Object Versioning旧版は手動削除可誤削除リカバリー
Retention Policyポリシー削除可(解除に条件)監査要件
Bucket Lock永続化規制要件(HIPAA、SEC 17a-4 等)
Object Hold (Temporary)解除可訴訟対応
Object Hold (Event-based)イベントで解除契約終了後 N 年保管

🔧 データ転送方式の選定

データ量で選ぶ: < 10 TB → gcloud storage / API 10 TB - 1 PB → Storage Transfer Service(オンライン) > 1 PB or 帯域不足 → Transfer Appliance(物理デバイス) 継続レプリケーション → Storage Transfer Service スケジュール / Object Replication BigQuery 移行 → BigQuery Data Transfer Service

🔧 Cloud SQL の HA 設計

機能内容
High Availability同一リージョン内、同期スタンバイ(フェイルオーバー 1-2 分)
Read Replica同一 / 別リージョン、非同期、読み込み負荷分散
Cross-region DR Replica別リージョンへの DR(フェイルオーバー手動)
PITR過去 7-35 日の任意時点へ復元(Binlog 必須)
Backup自動 + オンデマンド、最大 365 日保持

🔧 BigQuery の運用

  • Reservations (Editions): Standard / Enterprise / Enterprise Plus
  • Autoscaler: スロット数の自動増減
  • Partition / Cluster: コスト・性能最適化
  • Time Travel: 過去 7 日間のスナップショット
  • Fail-safe: Time Travel 終了後さらに 7 日リカバリ可能

🎯 ストレージ運用 即答

要件答え
30 日後 Nearline へLifecycle Rule
自動クラス変更(手間なし)Autoclass
期間中削除不可Retention Policy
永続的に解除不可(規制対応)Bucket Lock
上書き保護・誤削除復旧Object Versioning
訴訟対応の凍結Object Hold (Temporary)
期限付きアクセス URLSigned URL
公開を組織で完全禁止Public Access Prevention

🎯 ブロックストレージ 即答

用途答え
汎用Hyperdisk Balanced or PD Balanced
超高 IOPS(SAP HANA)Hyperdisk Extreme
AI 学習で複数 VM 共有Hyperdisk ML
スループット重視(Hadoop)Hyperdisk Throughput
一時データ・超低レイテンシLocal SSD
共有 NFSFilestore

🎯 データベース運用 即答

要件答え
Cloud SQL の HA同一リージョン同期スタンバイ
任意時点リストアPITR(Binlog 必須、7-35 日)
別リージョン DRCross-region Read Replica → DR Replica
PostgreSQL 高性能 OLTP/HTAPAlloyDB
グローバル強整合性Spanner Multi-region
BigQuery のスロット予約Reservations (Editions)
BigQuery 過去 7 日参照Time Travel
BigQuery 過去 7 日後復旧Fail-safe
統合バックアップ + DRBackup and DR Service

2.3 コンピュートシステムの構成

Compute Engine — マシンファミリー

ファミリー用途
E2汎用・低コスト
N2 / N2D汎用・本番標準
N4次世代汎用(最新世代)
C3 / C3D / H3高性能 CPU・HPC
T2D / T2Aスケールアウト型 Web、ARM
M3 / M4メモリ最適化(SAP HANA)
G2L4 GPU(推論)
A2 / A3 / A3 Ultra / A4GPU(A100 / H100、AI 学習)
TPU v5e / v5p / TrilliumTPU 専用(大規模 ML 学習)

課金単位と割引

  • 秒単位課金(最低 1 分)
  • 継続使用割引: 1 ヶ月の使用率に応じ最大 30% 自動割引
  • Committed Use Discounts (CUD): 1 / 3 年契約で 30-55% 割引
  • Spot VM: 最大 91% 割引(24 時間以内に終了の可能性)

Managed Instance Group (MIG)

VM を テンプレートから複数起動・自動修復・自動スケール するグループ。

Instance Template ─┬─ MIG (us-central1-a) ─ VM × N ├─ MIG (us-central1-b) ─ VM × N └─ MIG (us-central1-c) ─ VM × N ↑ Regional MIG = ゾーン跨ぎ
  • Autohealing: ヘルスチェック失敗で VM 再作成
  • Autoscaling: CPU / LB / カスタム指標 / スケジュール
  • Rolling Update: 段階的更新(Canary / Phased rollout)
  • Stateful MIG: 個別 VM の状態(ディスク / メタデータ)を保持

OS 管理(VM Manager / OS Config)

機能内容
OS Patch Managementパッチデプロイ、スケジュール、コンプライアンス
OS Inventoryインストール済みパッケージ・脆弱性
OS Config Agentエージェント経由で設定変更
OS LoginSSH 鍵を IAM で管理(ローカル鍵不要)

GKE の基本

観点AutopilotStandard
ノード管理Google 管理自己管理
課金Pod のリソース要求単位Node 単位
カスタマイズ制限あり完全自由
用途新規・標準ワークロードGPU/TPU、特殊要件
  • VPC-native cluster: デフォルト。Pod IP に Alias IP を使用
  • Private cluster: コントロールプレーン / ノードがプライベート IP
  • Workload Identity: Pod 単位で IAM 権限を付与(推奨)

サーバーレスコンピューティング

サービス単位課金用途
Cloud Runコンテナリクエスト時間ステートレス HTTP / Worker
Cloud Run functions関数呼出回数 + 実行時間イベント駆動
App Engine Standardアプリインスタンス時間Web アプリ(標準ランタイム)
App Engine Flexコンテナインスタンス時間カスタムランタイム
Cloud WorkflowsYAMLステップ数サーバーレスオーケストレーション
Eventarcイベントイベント数イベントルーティング

🔧 Spot vs Standard の判断

観点Spot VMStandard VM
価格最大 91% 割引通常
中断24 時間以内に終了の可能性なし
通知ACPI G2 シグナル / Shutdown スクリプト
再起動自動再起動なしあり
用途バッチ、ML 学習、レンダリング、CI/CDDB、本番 API、ステートフル

Spot VM 設計のコツ:複数ゾーン / リージョンで分散、中断シグナルでチェックポイント保存、MIG が中断後に自動再作成、Standard でベースライン + Spot でピーク吸収。

🔧 MIG の運用パターン

パターン用途
Rolling Update (Phased)段階デプロイ(5% → 50% → 100%)
Canaryバージョン別ターゲットサイズ
Stateful MIGディスク・メタデータを VM ごとに保持
Multi-zone MIG自動ゾーン分散
Multi-region MIGグローバル LB と組み合わせ

🔧 OS Config / VM Manager 運用

パッチ管理ライフサイクル: 1. OS Inventory … インストール済みパッケージ把握 2. Vulnerability Reports … 既知脆弱性レポート 3. OS Policy Assignments … 構成管理(パッケージ・ファイル) 4. OS Patch Jobs … パッチ適用ジョブ 5. Patch Compliance … パッチ適用状況の可視化

🔧 GKE Workload Identity(推奨パターン)

Kubernetes Service Account (KSA) ↓ Workload Identity Binding Google Service Account (GSA) ↓ GCP リソースへのアクセス → ノードに広く GSA を付ける旧来パターンは非推奨 → Pod 単位で最小権限を実現

🔧 GKE のスケーリング

スケーリング内容
HPA (Horizontal Pod Autoscaler)CPU / メモリ / カスタム指標で Pod 数増減
VPA (Vertical Pod Autoscaler)Pod のリソース要求を自動調整
Cluster AutoscalerNode 数の増減(Standard)
Node Auto-Provisioning必要に応じ Node Pool 自動作成(Standard)
Autopilot上記すべて自動

🔧 GKE Enterprise(旧 Anthos)

  • Fleet 管理: 複数クラスタを統合管理
  • Multi-cluster Ingress / Services: クラスタ跨ぎサービス公開
  • Config Sync: GitOps でクラスタ設定同期
  • Policy Controller: OPA Gatekeeper による Policy
  • Service Mesh: マネージド Istio
  • Connect Gateway: オンプレ / 他クラウド K8s を統合操作

🔧 Cloud Run の主要機能

機能用途
Min instancesコールドスタート対策(常駐インスタンス)
Concurrency1 インスタンスの同時処理数(1-1000)
CPU always allocatedバックグラウンド処理可能
VPC connector / Direct VPC egressVPC 内リソースへアクセス
Cloud Run Jobsバッチ処理用、HTTP リクエスト不要
GPU 対応(最新)Cloud Run でも GPU が使えるように

🎯 コンピュート 即答

要件答え
標準ワークロード K8sGKE Autopilot
Pod 単位 IAMWorkload Identity
クラスタ Node Pool 自動作成Node Auto-Provisioning
ステートレス HTTPCloud Run
サーバーレス GPUCloud Run + GPU
バッチ処理サーバーレスCloud Run Jobs
イベント駆動軽量Cloud Run functions(旧 Cloud Functions Gen2)
イベントルーティングEventarc
YAML ワークフローWorkflows
VM 状態保持 + MIGStateful MIG
MIG 段階更新Rolling Update (Phased / Canary)
VM パッチ管理VM Manager (OS Patch Management)
パッケージ・脆弱性把握OS Inventory / Vulnerability Reports
SSH 鍵を IAM 管理OS Login
物理ノード占有Sole Tenant Node
メモリ暗号化Confidential VM

🖥️ Google Cloud VMware Engine (GCVE) — 2025 改訂で追加

VMware vSphere / NSX-T / vSAN をフルマネージドで GCP 上に提供 するサービス。2025 改訂で試験対象に追加されました。

主要特徴

  • 既存 VMware ライセンス利用可(BYO License もしくは GCP 契約)
  • HCX 経由でリフト&シフト: オンプレ VMware → GCVE をダウンタイム最小で移行
  • NSX-T ネットワーク: 既存ネットワークポリシーをそのまま使える
  • GCP サービスと連携: VPC Peering で BigQuery / Cloud SQL 等にアクセス

GCVE が選ばれる典型ケース

  • Oracle DB on VMware の移行(OS / ハイパーバイザーそのまま、ライセンス継続)
  • 短期間(< 6 ヶ月)で移行必要 → HCX で無停止
  • 既存 VMware 運用ノウハウ活用(vCenter / NSX-T / vSAN そのまま)
  • Refactor の予算がない → クラウドネイティブ化を遅延
  • データセンター退去期限 → ハードウェア廃棄を加速

GCVE 構成図

オンプレ vSphere ──── HCX ────→ GCVE(GCP 上) ├── vCenter Server ├── ESXi(ベアメタル、3-32 ノード) ├── NSX-T Manager / Edge ├── HCX Manager └── vSAN ↕ VPC Peering Cloud SQL / BigQuery / GCS

GCVE と GCP サービスの統合

連携先方法
GCS / BigQueryVPC Peering 経由でアクセス
Cloud SQLプライベート IP 接続
Backup and DR統合バックアップ対象
Cloud Monitoringエージェントでメトリクス送信
IAMプライベートクラウド単位で権限管理
🔑 GCVE 選定キーワード「VMware そのまま」「6 ヶ月で移行」「DC 退去期限」「Oracle on VMware」 → GCVE + HCX

2.4 Vertex AI で ML ワークフローをエンドツーエンド

Vertex AI の構成要素

データ準備 ├── Cloud Storage / BigQuery(生データ) └── Vertex AI Feature Store(特徴量管理) モデル開発 ├── Vertex AI Workbench(マネージド Jupyter) ├── AutoML(コード不要) ├── Custom Training(独自モデル) └── Model Garden(事前学習モデルカタログ) オーケストレーション └── Vertex AI Pipelines(Kubeflow Pipelines ベース) デプロイ・推論 ├── Vertex AI Endpoints(オンライン推論、リアルタイム) ├── Vertex AI Batch Prediction(バッチ推論) └── Model Registry(バージョン管理) 監視 ├── Vertex AI Model Monitoring(ドリフト検知) └── Vertex AI Explainable AI(説明可能性)

Vertex AI Pipelines(基本)

ML ライフサイクルを DAG(有向非巡回グラフ) として宣言し、自動実行する仕組み。

  • Kubeflow Pipelines (KFP) または TFX (TensorFlow Extended) で記述
  • 各ステップはコンテナとして実行
  • パラメータ・成果物・実行履歴を Vertex ML Metadata に保存
  • スケジュール実行 / イベント駆動が可能
from kfp import dsl

@dsl.component(base_image="python:3.10")
def preprocess(data_uri: str) -> str:
    return f"preprocessed: {data_uri}"

@dsl.component(base_image="python:3.10")
def train(preprocessed: str) -> str:
    return f"model from {preprocessed}"

@dsl.pipeline(name="simple-pipeline")
def pipeline(data_uri: str):
    p = preprocess(data_uri=data_uri)
    train(preprocessed=p.output)

データ統合の準備

ソース統合方法
BigQueryVertex AI Datasets / Feature Store 直接統合
Cloud Storageファイルパス指定(CSV / JSON / TFRecord 等)
ストリーミングPub/Sub → Dataflow → BigQuery / GCS
データレイクハウスDataplex でカタログ化 → Vertex AI から参照

🔧 Pipelines の設計パターン

標準的なパイプライン構成: Ingestion → Preprocessing → Training → Evaluation → Validation → Deployment → Monitoring ↓ ↓ ↓ ↓ ↓ ↓ ↓ BigQuery Dataflow Custom/AutoML Eval Metrics Model Card Endpoints Model Monitoring GCS Beam TPU/GPU Drift Detection

再利用性のテクニック

  • コンポーネント: 再利用可能な小単位(Container Component / Python Component)
  • パラメータ: パイプライン入力(データセットパス、ハイパーパラメータ)
  • キャッシュ: 同一入力なら再実行不要
  • Conditional / ParallelFor: 条件分岐・並列実行

🔧 Vertex AI Feature Store

オンライン推論用の 低レイテンシ特徴量ストア。学習と推論で同じ特徴量定義を使うのが利点。

機能内容
Online Servingms 単位で特徴量取得
Offline StorageBigQuery ベース、学習用
Feature Registry特徴量メタデータ管理
Time-travel学習時の状態を再現
Streaming Ingestionリアルタイム更新

🔧 学習リソースの選定

ワークロード推奨
小規模、ハイパラ実験Vertex AI Workbench + 単一 GPU
中規模、本番Vertex AI Custom Training + Multi-GPU
大規模 LLMAI Hypercomputer (TPU v5p / Trillium)
ファインチューニングVertex AI Tuning Pipelines
HPO(ハイパラ最適化)Vertex AI Hyperparameter Tuning

🔧 デプロイパターン

パターン用途
Endpoints (Online)リアルタイム推論、< 100ms
Batch Prediction大量データ、夜間バッチ
Private EndpointsVPC 内のみアクセス
Edge DeploymentVertex AI Edge Manager(IoT)
Co-hosting複数モデルを 1 Endpoint に同居

🔧 Model Monitoring

監視項目内容
Feature Drift入力特徴量の分布が学習時と異なる
Prediction Drift予測分布の変化
Feature Skew学習データと本番データの差
Attribution Drift特徴量寄与度の変化
Outlier Detection異常値検知

🎯 Vertex AI 即答

機能用途
Vertex AI PipelinesML ワークフローオーケストレーション(Kubeflow)
Vertex AI Workbenchマネージド Jupyter
Vertex AI Feature Storeオンライン特徴量低レイテンシ
Vertex AI Model Registryモデルバージョン管理
Vertex AI Endpointsオンライン推論
Vertex AI Batch Predictionバッチ推論
Vertex AI Model Monitoringドリフト検知
Vertex AI Explainable AI説明可能性
Vertex AI Hyperparameter TuningHPO

🚀 AI Hypercomputer — 大規模 AI 学習の統合製品

大規模 AI ワークロード(数百 B パラメータの LLM 学習など)のための 統合インフラ製品。4 レイヤー構成を必ず暗記。

レイヤー 1

コンピュート層

  • TPU v5e / v5p / Trillium(学習に最適)
  • A3 / A3 Ultra(H100 GPU)
  • A4(最新 GPU)
レイヤー 2

ネットワーク層

  • Jupiter(光回線スイッチング)
  • ノード間 3.2 Tbps
レイヤー 3

ストレージ層

  • Hyperdisk ML(複数 VM 同時アタッチ可)
  • Anywhere Cache(オブジェクトキャッシュ)
  • Parallel Filesystem (Lustre)
レイヤー 4

ソフトウェア層

  • JAX / PyTorch / TensorFlow
  • Pathways(マルチホスト分散を抽象化)
  • XLA コンパイラ

構成判断

要件推奨
LLM 学習(数百 B パラメータ)TPU v5p / Trillium pod
マルチモーダル学習A3 Ultra (H100) / A4
推論レイテンシ重視A3 + Hyperdisk ML
高スループットファインチューニングTPU v5e
既存 PyTorch コードA3 / A4 + JAX / PyTorch + Pathways

コスト最適化

手法効果
Dynamic Workload Scheduler (DWS)GPU / TPU を必要なときだけ確保(在庫優先)
Calendar / Flex Start モード開始時刻を柔軟にしコスト削減
Reservations確実な確保(本番用)
Committed Use (TPU / GPU)1-3 年契約で割引
Spot for ML 学習チェックポイント前提で大幅割引
🔑 AI Hypercomputer キーワード「大規模 LLM 学習」「TPU + GPU 混在」「Pathways」「DWS」「Trillium」 → AI Hypercomputer

2.5 プリビルトソリューションや API の Vertex AI 統合

Google AI API(事前学習済み)

コードなしで即利用できる API。

API用途
Vision AI画像分類、ラベル検出、OCR、顔検出
Video Intelligence動画ラベル、シーン検出、不適切コンテンツ検知
Speech-to-Text音声認識
Text-to-Speech音声合成
Natural Language APIエンティティ抽出、感情分析、構文解析
Translation API翻訳(135+ 言語)
Document AI文書 OCR、フォーム抽出、構造化抽出
Discovery AI(旧 Vertex AI Search)エンタープライズ検索
Conversational Agents(旧 Dialogflow CX)対話 AI
⚠️ Vision AI vs Document AI「帳票・請求書 OCR」→ Document AI(Vision より高機能で構造化抽出)。「一般 OCR / 画像」→ Vision AI。

Model Garden(最新・必須)

Google + サードパーティ + OSS の 200+ モデル を統一インターフェースで利用できるカタログ。

含まれるモデル

  • Google: Gemini (Pro/Flash/Nano)、PaLM 2、Imagen、Chirp、Codey、Embeddings
  • サードパーティ: Anthropic Claude、AI21 Jurassic、Mistral Large
  • OSS: Llama、Stable Diffusion、Falcon、Gemma

利用パターン

  • API として利用(Vertex AI Endpoints 経由)
  • ファインチューニング(自社データで再学習)
  • デプロイ(GKE / Vertex AI Endpoints に配置)
🔑 Model Garden キーワード「Claude / Llama を GCP で」「Gemma」「Imagen 3」「マルチモデル」 → Model Garden

🔧 Gemini Enterprise の構成判断

要件推奨機能
ナレッジ Q&A(社内文書)NotebookLM + Discovery AI
業務エージェント(カスタマーサポート)Conversational Agents (Dialogflow CX)
Coding 支援Gemini Code Assist
全社 AI アシスタントAgentspace
構造化データ Q&AVertex AI Conversation + BigQuery
営業エージェントSales Agent(Gemini Enterprise 標準)

🔧 NotebookLM の活用

  • 複数のソース(PDF / Google Docs / Web / GCS)を 同時に AI に読ませる
  • 質問に 引用元付き で回答(ハルシネーション低減)
  • 業務マニュアル / 法令 / 設計書 のサーベイに最適
🔑 NotebookLM キーワード「社内ナレッジ Q&A」「引用必須」「設計書サーベイ」 → NotebookLM

🔧 Model Garden の選定軸

要件推奨モデル
最高品質 LLM(汎用)Gemini 2 Pro
コスト効率 LLMGemini Flash
オープンソース重視Gemma / Llama
Anthropic ClaudeModel Garden 経由 Claude
画像生成Imagen 3 / Stable Diffusion
音声合成Chirp
埋め込み(Embeddings)text-embedding

🔧 Google AI API の使い分け

シナリオ推奨
紙書類の電子化Document AI
一般的 OCRVision AI
動画コンテンツ分類Video Intelligence
大量ファイルの翻訳Translation API(バッチ)
多言語顧客対応Translation + Conversational Agents
音声議事録Speech-to-Text + Natural Language API

🎯 Gemini Enterprise 即答

機能用途
Agentsカスタマーサポート / Sales / IT エージェント
NotebookLM引用付き AI ノートブック
Conversational Agents旧 Dialogflow CX、対話型
Agentspace全社 AI アシスタント
Discovery AIエンタープライズ検索(旧 Vertex AI Search)

🎯 Google AI API 即答

シナリオ答え
帳票 / フォーム OCRDocument AI
一般 OCR / 画像Vision AI
動画分析Video Intelligence
音声認識Speech-to-Text
感情分析・エンティティNatural Language
翻訳 135+Translation
エンタープライズ検索Discovery AI
対話 AIConversational Agents (旧 Dialogflow CX)

🤖 Gemini Enterprise — 構成要素

Gemini を企業向けに統合した AI エージェント基盤。旧 Vertex AI Agent Builder を含む統合製品。

Gemini Enterprise ├── Agents(業務特化 AI) │ ├── Customer Service Agent │ ├── Sales Agent │ └── Coding Agent ├── NotebookLM(ナレッジ統合 AI、引用付き) ├── Conversational Agents(旧 Dialogflow CX、対話制御) ├── Discovery AI(旧 Vertex AI Search、エンタープライズ検索) └── Agentspace(全社向け AI アシスタント)

統合アーキテクチャ例(Gemini Enterprise + Vertex AI + AI API)

┌─────────────────────────────────────────────┐ │ User Channel: Web / Slack / Teams / 電話 │ └──────────────┬──────────────────────────────┘ ↓ ┌─────────────────────────────────────────────┐ │ Gemini Enterprise Agentspace │ │ ├─ Conversational Agents (対話制御) │ │ ├─ NotebookLM (ナレッジ参照) │ │ └─ Custom Agent (業務ロジック) │ └──────────────┬──────────────────────────────┘ ↓ ┌─────────────────────────────────────────────┐ │ Vertex AI │ │ ├─ Model Garden (Gemini / Claude / Llama) │ │ ├─ Custom Models (自社ファインチューン) │ │ ├─ Feature Store │ │ └─ Endpoints (オンライン推論) │ └──────────────┬──────────────────────────────┘ ↓ ┌─────────────────────────────────────────────┐ │ Data & API Layer │ │ ├─ BigQuery / Cloud SQL / Spanner │ │ ├─ Document AI (帳票OCR) │ │ ├─ Translation / Speech / Vision API │ │ └─ Apigee (バックエンド API 集約) │ └─────────────────────────────────────────────┘

⚖️ 設計判断のトレードオフ

ケース 1:既存 VMware 環境 1000 VM の移行

要件: 6 ヶ月で完了、ハイパーバイザーは VMware 維持、最小ダウンタイム

  • A: Migrate to VMs で Compute Engine へ(Refactor の知識習得が必要、運用変更大)
  • B: GCVE + HCX(VMware 運用そのまま、HCX で無停止移行)✅
  • C: 各 VM 個別に gcloud で移行(1000 VM の手作業は非現実)

正解は B

ケース 2:AI 学習で TPU と GPU を混在

要件: 大規模 LLM 学習、ハードウェアを柔軟に切り替え

  • A: TPU 単独で構成(GPU ジョブが回せない)
  • B: GKE で TPU / GPU 別 NodePool(運用負担、ハードウェア最適化が難しい)
  • C: AI Hypercomputer + Pathways(TPU / GPU を統合、JAX で透過利用)✅

正解は C

ケース 3:社内ドキュメント 10 万件を AI で検索したい

要件: 引用元必須、ハルシネーション最小化、IT 部門で短期構築

  • A: Gemini API + 自作 RAG(構築期間長、保守負担)
  • B: NotebookLM Enterprise + Discovery AI(プリビルト、引用機能標準)✅
  • C: BigQuery + Vector Search(検索のみで Q&A 機能弱)

正解は B

ケース 4:マルチリージョン GKE の Pod 増加で IP 枯渇

要件: 既存サブネットを変更せず Pod を増やしたい

  • A: 新サブネットを追加(クラスタ作り直し)
  • B: GKE セカンダリ範囲を Discontiguous で追加(既存クラスタで Pod 増加可能)✅
  • C: Cluster Autoscaler 制限(本質解決にならない)

正解は B。GKE は Discontiguous な複数セカンダリ範囲をサポート。

📋 Organization Policy 頻出制約

ポリシー効果
compute.vmExternalIpAccessVM 外部 IP 制限
compute.disableSerialPortAccessシリアルポート無効
storage.uniformBucketLevelAccessGCS Uniform 強制
iam.disableServiceAccountKeyCreationSA キー作成禁止
iam.allowedPolicyMemberDomains許可ドメイン制限
sql.restrictPublicIpCloud SQL Public IP 禁止
compute.restrictSharedVpcSubnetworksShared VPC 利用制限

💡 設計判断の必殺フレーズ

状況即答
「VMware そのまま GCP に」VMware Engine (GCVE) + HCX
「サーバーレスで GPU」Cloud Run + GPU
「Pod 単位課金 K8s」GKE Autopilot
「Pod 単位 IAM」Workload Identity
「ML ワークフロー自動化」Vertex AI Pipelines
「学習と推論で同じ特徴量」Vertex AI Feature Store
「ドリフト検知」Vertex AI Model Monitoring
「大規模 LLM 学習」AI Hypercomputer (TPU/GPU + Pathways)
「TPU/GPU 在庫優先で確保」Dynamic Workload Scheduler (DWS)
「Claude / Llama を GCP で」Model Garden
「社内ナレッジ Q&A + 引用」NotebookLM
「エンタープライズ検索」Discovery AI
「全社 AI アシスタント」Agentspace
「カスタマーサポート AI」Conversational Agents
「帳票 / フォーム OCR」Document AI
「7 年永続保管(規制)」GCS Retention Policy + Bucket Lock + Archive
「統合バックアップ + DR」Backup and DR Service
「VM パッチ統合」VM Manager
「組織レベル FW 強制」Hierarchical Firewall Policy
「次世代 FW(Geo / Threat)」Network Firewall Policy
「ハブ&スポーク統合」Network Connectivity Center (NCC)
「L7 WAF」Cloud Armor
「侵入検知」Cloud IDS
「IP 枯渇でも追加サブネット」GKE Discontiguous Secondary Range

暗記数値(コンピュート・ストレージ)

🔑 5 分で復習する箇条書きまとめ
  • ネットワーク: VPC グローバル / Subnet リージョン / Hierarchical FW で組織統制 / Cloud Armor = WAF / Cloud IDS = 侵入検知 / PSC でプライベート接続
  • LB: Global External Application LB を第一候補、L4 直接通信は Regional External Passthrough NLB
  • ストレージ: Autoclass + Bucket Lock + Retention Policy / Hyperdisk は IOPS とサイズ独立 / Hyperdisk ML は AI 共有
  • DB: Cloud SQL HA + PITR、AlloyDB は PostgreSQL 高性能、Spanner Multi-region 強整合性
  • コンピュート: GKE Autopilot + Workload Identity、Cloud Run + GPU、VM Manager でパッチ統合
  • VMware: GCVE + HCX で VMware ライセンス維持のままリフト&シフト
  • Vertex AI: Pipelines(Kubeflow)/ Feature Store / Model Registry / Endpoints / Batch / Monitoring
  • AI Hypercomputer: TPU v5/Trillium + A3/A4 GPU + Jupiter NW + Hyperdisk ML + Pathways
  • Gemini Enterprise: Agents + NotebookLM + Conversational Agents + Discovery AI + Agentspace
  • Model Garden: Gemini / Claude / Llama / Mistral / Imagen / Gemma を統一インターフェース
  • AI API: Document AI(帳票)、Vision、Video、Speech、Natural Language、Translation
← セクション 1 に戻る セクション 3:セキュリティとコンプライアンス → 📝 問題演習を解く 📖 用語集