セクション 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 を中心に出題。
🎯 学習目標
🏗️ クラウドインフラ 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 Rules VPC 単位、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 Interconnect 10 / 100 Gbps 99.99% なし 大規模直結
Partner Interconnect 50 Mbps – 50 Gbps 99.99% なし 中規模・パートナー経由
Cross-Cloud Interconnect 10 / 100 Gbps 99.99% なし GCP ↔ AWS / Azure 直結
HA VPN 最大 3 Gbps/トンネル 99.99% あり(IPsec) 中小規模・暗号化
Classic VPN 最大 3 Gbps 99.9% あり レガシー(非推奨)
Network Connectivity Center (NCC) — — — ハブ&スポークで複数経路を統合
LB 7 種類
3 軸(スコープ × 公開範囲 × 方式)で 7 種類。Global External Application LB が最も汎用的な第一候補です。
用途 推奨 LB
グローバル Web/API Global External Application LB
TCP/UDP 直接、IP 保持 Regional External Passthrough NLB
内部マイクロサービス Internal Application LB
マルチリージョン内部 API Cross-region Internal Application LB
🔧 VPC 設計パターン(4 種)
パターン 内容 採用判断
Single VPC 1 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 Policy CDN / 外部 LB 手前で WAF
OWASP ルール SQLi/XSS/LFI/RCE/Scanner 等の Pre-configured ルール
Adaptive Protection ML ベースの自動 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 APIs googleapis.com にプライベート IP(restricted.googleapis.com)
PSC for Published Services 自社サービスをエンドポイント化(マルチテナント SaaS 風)
PSC for Managed Services Cloud 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 Group VM ベース(MIG 推奨)
NEG (Network Endpoint Group) サーバーレス、ハイブリッド、K8s Service
Serverless NEG Cloud Run / Cloud Run functions / App Engine
Internet NEG 外部 FQDN / IP(オンプレ / 他クラウド)
Hybrid NEG オンプレに直接ルーティング
Private Service Connect NEG PSC 経由のサービス
🔧 マルチクラウド / ハイブリッド設計の判断軸
状況 推奨
通信量 < 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 の egress Cloud NAT
外部 IP なしで googleapis.com Private Google Access
プライベート IP で Google API PSC for Google APIs
プライベート IP で Cloud SQL PSC for Managed Services
API レベルでデータ流出防止 VPC Service Controls
L7 WAF / DDoS Cloud Armor
自動 DDoS 防御 Cloud Armor Adaptive Protection
侵入検知 (IDS) Cloud IDS
アプリ前段ユーザー認証 Identity-Aware Proxy (IAP)
組織レベル FW 強制 Hierarchical Firewall Policy
グループ管理 FW Network 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 Lock Retention 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 高 IOPS 100,000 数 GB/s
PD Extreme 超高 IOPS 120,000 数 GB/s
Hyperdisk Balanced 次世代汎用、サイズと IOPS 独立 160,000 2,400 MB/s
Hyperdisk Throughput スループット重視(Hadoop など) — 数 GB/s
Hyperdisk Extreme 超高 IOPS(SAP HANA など) 350,000 5,000 MB/s
Hyperdisk ML AI 学習、複数 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 SQL HA 構成(同期スタンバイ) 自動バックアップ + Binlog PITR(任意時点、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)
期限付きアクセス URL Signed URL
公開を組織で完全禁止 Public Access Prevention
🎯 ブロックストレージ 即答
用途 答え
汎用 Hyperdisk Balanced or PD Balanced
超高 IOPS(SAP HANA) Hyperdisk Extreme
AI 学習で複数 VM 共有 Hyperdisk ML
スループット重視(Hadoop) Hyperdisk Throughput
一時データ・超低レイテンシ Local SSD
共有 NFS Filestore
🎯 データベース運用 即答
要件 答え
Cloud SQL の HA 同一リージョン同期スタンバイ
任意時点リストア PITR (Binlog 必須、7-35 日)
別リージョン DR Cross-region Read Replica → DR Replica
PostgreSQL 高性能 OLTP/HTAP AlloyDB
グローバル強整合性 Spanner Multi-region
BigQuery のスロット予約 Reservations (Editions)
BigQuery 過去 7 日参照 Time Travel
BigQuery 過去 7 日後復旧 Fail-safe
統合バックアップ + DR Backup and DR Service
2.3 コンピュートシステムの構成
📘 基礎
🔧 応用
🎯 要点
Compute Engine — マシンファミリー
ファミリー 用途
E2 汎用・低コスト
N2 / N2D 汎用・本番標準
N4 次世代汎用(最新世代)
C3 / C3D / H3 高性能 CPU・HPC
T2D / T2A スケールアウト型 Web、ARM
M3 / M4 メモリ最適化(SAP HANA)
G2 L4 GPU(推論)
A2 / A3 / A3 Ultra / A4 GPU(A100 / H100、AI 学習)
TPU v5e / v5p / Trillium TPU 専用(大規模 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 Login SSH 鍵を IAM で管理(ローカル鍵不要)
GKE の基本
観点 Autopilot Standard
ノード管理 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 Workflows YAML ステップ数 サーバーレスオーケストレーション
Eventarc イベント イベント数 イベントルーティング
🔧 Spot vs Standard の判断
観点 Spot VM Standard VM
価格 最大 91% 割引 通常
中断 24 時間以内に終了の可能性 なし
通知 ACPI G2 シグナル / Shutdown スクリプト —
再起動 自動再起動なし あり
用途 バッチ、ML 学習、レンダリング、CI/CD DB、本番 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 Autoscaler Node 数の増減(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 コールドスタート対策(常駐インスタンス)
Concurrency 1 インスタンスの同時処理数(1-1000)
CPU always allocated バックグラウンド処理可能
VPC connector / Direct VPC egress VPC 内リソースへアクセス
Cloud Run Jobs バッチ処理用、HTTP リクエスト不要
GPU 対応 (最新)Cloud Run でも GPU が使えるように
🎯 コンピュート 即答
要件 答え
標準ワークロード K8s GKE Autopilot
Pod 単位 IAM Workload Identity
クラスタ Node Pool 自動作成 Node Auto-Provisioning
ステートレス HTTP Cloud Run
サーバーレス GPU Cloud Run + GPU
バッチ処理サーバーレス Cloud Run Jobs
イベント駆動軽量 Cloud Run functions(旧 Cloud Functions Gen2)
イベントルーティング Eventarc
YAML ワークフロー Workflows
VM 状態保持 + MIG Stateful 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 / BigQuery VPC 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)
データ統合の準備
ソース 統合方法
BigQuery Vertex 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 Serving ms 単位で特徴量取得
Offline Storage BigQuery ベース、学習用
Feature Registry 特徴量メタデータ管理
Time-travel 学習時の状態を再現
Streaming Ingestion リアルタイム更新
🔧 学習リソースの選定
ワークロード 推奨
小規模、ハイパラ実験 Vertex AI Workbench + 単一 GPU
中規模、本番 Vertex AI Custom Training + Multi-GPU
大規模 LLM AI Hypercomputer (TPU v5p / Trillium)
ファインチューニング Vertex AI Tuning Pipelines
HPO(ハイパラ最適化) Vertex AI Hyperparameter Tuning
🔧 デプロイパターン
パターン 用途
Endpoints (Online) リアルタイム推論、< 100ms
Batch Prediction 大量データ、夜間バッチ
Private Endpoints VPC 内のみアクセス
Edge Deployment Vertex AI Edge Manager(IoT)
Co-hosting 複数モデルを 1 Endpoint に同居
🔧 Model Monitoring
監視項目 内容
Feature Drift 入力特徴量の分布が学習時と異なる
Prediction Drift 予測分布の変化
Feature Skew 学習データと本番データの差
Attribution Drift 特徴量寄与度の変化
Outlier Detection 異常値検知
🎯 Vertex AI 即答
機能 用途
Vertex AI Pipelines ML ワークフローオーケストレーション(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 Tuning HPO
🚀 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&A Vertex AI Conversation + BigQuery
営業エージェント Sales Agent(Gemini Enterprise 標準)
🔧 NotebookLM の活用
複数のソース(PDF / Google Docs / Web / GCS)を 同時に AI に読ませる
質問に 引用元付き で回答(ハルシネーション低減)
業務マニュアル / 法令 / 設計書 のサーベイに最適
🔑 NotebookLM キーワード 「社内ナレッジ Q&A」「引用必須」「設計書サーベイ」 → NotebookLM
🔧 Model Garden の選定軸
要件 推奨モデル
最高品質 LLM(汎用) Gemini 2 Pro
コスト効率 LLM Gemini Flash
オープンソース重視 Gemma / Llama
Anthropic Claude Model Garden 経由 Claude
画像生成 Imagen 3 / Stable Diffusion
音声合成 Chirp
埋め込み(Embeddings) text-embedding
🔧 Google AI API の使い分け
シナリオ 推奨
紙書類の電子化 Document AI
一般的 OCR Vision 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 即答
シナリオ 答え
帳票 / フォーム OCR Document AI
一般 OCR / 画像 Vision AI
動画分析 Video Intelligence
音声認識 Speech-to-Text
感情分析・エンティティ Natural Language
翻訳 135+ Translation
エンタープライズ検索 Discovery AI
対話 AI Conversational 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
暗記数値(コンピュート・ストレージ)
Spot 割引 : 最大 91%
継続使用割引 : 最大 30%
Committed Use : 1 年 30% / 3 年 55%
Cloud Storage 最低保持 : Standard 0 / Nearline 30 / Coldline 90 / Archive 365 日
Cloud SQL PITR 保持 : 7-35 日
BigQuery Time Travel : 7 日 + Fail-safe 7 日
Spanner 強整合性 SLA : Multi-region 99.999%
HA VPN SLA : 99.99%
Hyperdisk Extreme : 350,000 IOPS / 5,000 MB/s
Hyperdisk ML : 最大 2,500 VM 同時読込
Cloud Run 最大実行時間 : 60 分(HTTP)
🔑 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
🧭 次のステップ