セクション 1：
クラウドソリューションアーキテクチャの設計と計画
試験全体の 1/4 を占める最重要セクション。ビジネス要件 → 技術要件 → サービス選定の「翻訳力」、Well-Architected の 6 柱、移行戦略 6R、AI/ML 最新項目（Vertex AI / Gemini / Model Garden / AI Hypercomputer / Gemini Cloud Assist）を体系的に押さえます。
★ 最重要セクション
📊 出題 25%
🎯 設計判断の翻訳力
📘🔧🎯 全レベル対応
📘 基礎
🔧 応用
🎯 要点と暗記
🔑 TL;DR — このセクションの要約
アーキテクトの仕事は「ビジネス要件 → 技術要件 → サービス選定」の翻訳。判断軸は常に Well-Architected の 6 柱（運用/セキュリティ/信頼性/性能/コスト/持続可能性）。ネットワークは VPC・Interconnect・LB、ストレージは GCS・Cloud SQL・Spanner・BigQuery・Bigtable、コンピュートは GCE・GKE・Cloud Run・Cloud Run functions の選定マトリクスを暗記。移行は 6R（Rehost / Replatform / Refactor / Repurchase / Retain / Retire）と Migration Center。AI/ML は Vertex AI / Gemini / Model Garden / AI Hypercomputer / Gemini Cloud Assist が最新の必出項目。
🎯 学習目標
このセクションの達成度0 / 0
※ チェック状態はこのブラウザに保存されます。
🏛️ Well-Architected Framework — 6 本の柱
GCP の設計判断の根底にある 6 柱。「どの柱を優先するか」を即答できることが合格に直結します。試験では選択肢を「該当する柱」で評価し、最もビジネス要件に合致するものを選びます。
柱 1
Operational Excellence
Operational Excellence
運用上の卓越性
自動化・観測可能性・継続改善・IaC・SLO 設計
代表サービス: Cloud Monitoring, Cloud Logging, Cloud Trace, Terraform
柱 2
Security
Security
セキュリティ
IAM 最小権限・CMEK・VPC SC・コンプライアンス
代表サービス: IAM, Cloud KMS, VPC Service Controls, Sensitive Data Protection
柱 3
Reliability
Reliability
信頼性
SLO・冗長化・マルチリージョン・HA VPN・PITR・DR
代表サービス: Cloud Load Balancing, Spanner Multi-region, Backup and DR
柱 4
Performance Optimization
Performance Optimization
性能最適化
レイテンシ・スループット・キャパシティ計画
代表サービス: Premium Tier, Cloud CDN, Memorystore, Hyperdisk
柱 5
Cost Optimization
Cost Optimization
コスト最適化
TCO・CapEx/OpEx・コミットメント・Right-sizing
代表サービス: Committed Use, Spot VM, GCS Autoclass, Active Assist
柱 6
Sustainability
Sustainability
持続可能性
カーボン削減・低炭素リージョン選定・効率化
代表サービス: Carbon Footprint, Region Picker, Active Assist
🔄 6 柱のトレードオフ
6 柱は互いに競合することがあります。試験では 「最もビジネス要件に合致する」選択肢が正解で、特定柱の最大化ではない点に注意。
| トレードオフ | 具体例 | 判断軸 |
|---|---|---|
| 信頼性 vs コスト | マルチリージョン（コスト 2-3 倍）⇔ シングルリージョン | SLO 要件と予算上限 |
| 性能 vs セキュリティ | 全リクエスト DLP 検査（遅延増）⇔ サンプリング検査 | 規制要件の強度 |
| 運用容易性 vs 柔軟性 | Cloud Run（簡単）⇔ GKE（柔軟だが運用負担） | チームスキルと拡張計画 |
| セキュリティ vs 開発速度 | Binary Authorization 強制 ⇔ 自由デプロイ | 本番/開発の段階分け |
1.1 ビジネス要件を満たすクラウドソリューションインフラの設計
ビジネス要件 vs 技術要件
アーキテクトの本質は「ビジネス課題を技術ソリューションに翻訳する」こと。試験では必ず「ビジネス要件」が問題文に埋め込まれており、それを技術選定に変換する力が問われます。
📊 ビジネス要件（何を達成したいか）
- 売上を 20% 増やしたい
- カスタマーサポートコストを 30% 削減
- 規制対応（HIPAA / GDPR）を必達
- 99.9% の可用性を維持
- 3 ヶ月以内にグローバル展開
⚙️ 技術要件（どう実現するか）
- 1,000 RPS のスループット
- 平均応答時間 200ms 以下
- データはアジア圏内に保存（データ主権）
- 既存のオンプレ AD と統合
- RPO 5 分、RTO 30 分
機能要件 vs 非機能要件（NFR）
| 種類 | 内容 | 例 |
|---|---|---|
| 機能要件 | システムが「何を」するか | ユーザー登録、注文処理、決済 |
| 非機能要件 (NFR) | システムが「どのように」するか | 性能、可用性、セキュリティ、保守性 |
💡 試験のコツ必ずNFR を特定してから、それに応じたサービス選定をします。「99.9% 可用性」「100ms 以下」など数値が出てきたら NFR の手がかり。
設計プロセスの 5 ステップ
1. 要件定義 → 2. 設計 → 3. 検証 → 4. 移行/構築 → 5. 運用・改善
↓ ↓ ↓ ↓ ↓
ヒアリング アーキ図 PoC 段階移行 継続改善
KPI/ROI サービス選定 テスト 本番リリース コスト最適化
🔧 ビジネス要件 → サービス選定の翻訳マトリクス（最頻出）
典型的なビジネス要件キーワードを技術要件 → 推奨サービスへ翻訳する「定番パターン」を暗記しておくと、本番で即答できます。
| ビジネス要件キーワード | 技術要件 | 推奨サービス（即答） |
|---|---|---|
| 「グローバル展開」 | 多リージョン・低レイテンシ | Global LB + Cloud CDN + Spanner |
| 「99.9% 以上の可用性」 | 冗長化・自動フェイルオーバー | Multi-region LB / Cloud SQL HA / GKE Multi-cluster |
| 「規制対応（HIPAA/GDPR）」 | データ主権・暗号化・監査 | リージョン制限 + CMEK + VPC SC + Audit Logs |
| 「コスト削減」 | コミットメント・自動停止 | Committed Use / Spot VM / Autoclass / Autoscaling |
| 「機械学習を活用」 | ML プラットフォーム | Vertex AI / Gemini / Model Garden |
| 「リアルタイム分析」 | ストリーミング処理 | Pub/Sub + Dataflow + BigQuery |
| 「マイクロサービス化」 | コンテナ + オーケストレーション | GKE / Cloud Run |
| 「レガシー DB 移行」 | 最小ダウンタイム | Database Migration Service |
| 「ハイブリッド」 | オンプレ ↔ GCP 接続 | Dedicated Interconnect + HA VPN |
| 「マルチクラウド」 | GCP ↔ AWS/Azure 接続 | Cross-Cloud Interconnect / NCC |
🔧 KPI / ROI / TCO の設計
設計判断を支える経営指標。試験では「ROI を最大化」「TCO を低減」というフレーズが頻出。
| 指標 | 内容 | 例 |
|---|---|---|
| KPI | 業務目標達成度 | 月次注文数、顧客満足度 |
| ROI | 投資対効果（コスト削減額 / 投資額） | 移行投資 $100k で年間 $200k 削減 |
| TCO | 総所有コスト | クラウド利用料 + 運用人件費 + 機会損失 |
| CapEx vs OpEx | 資本支出 vs 運用支出 | オンプレ機器（CapEx）vs クラウド月額（OpEx） |
| SLI / SLO / SLA | 測定値 / 目標 / 契約 | SLI=可用率 / SLO=99.9% / SLA=契約上の補償 |
🔧 Workload Disposition 戦略（4 判断）
| 戦略 | 内容 | 採用判断 |
|---|---|---|
| Build | 自社で新規開発 | コア競争力、差別化要素 |
| Buy | SaaS / マネージドサービス利用 | 汎用機能、運用負担削減 |
| Modify | 既存を改良 | 中長期的に価値あり、コスト許容 |
| Deprecate | 廃止 | 価値低下、コストが利益を上回る |
⚠️ 試験頻出「メール送信サービスを自前運用」→ Buy（SendGrid 等 SaaS に切り替え）。「既存オンプレ ERP を 1 年で運用予定」→ Retain / Modify（急がない）。
🎯 ビジネス要件 即答パターン
| キーワード | 即答サービス |
|---|---|
| グローバル + 強整合性 | Spanner Multi-region |
| グローバル + 高速読込 | Global LB + Cloud CDN + Spanner Read Replica |
| 99.9% 以上の可用性 | HA / Multi-region 構成 |
| 最小ダウンタイム DB 移行 | Database Migration Service |
| API 管理（フルライフサイクル） | Apigee |
| 軽量 API ゲートウェイ | API Gateway / Cloud Endpoints |
| LLM ベース対話システム | Gemini + Agent Builder |
| 大規模 LLM 学習 | AI Hypercomputer + Vertex AI |
| 移行アセスメント | Migration Center |
| AI 支援設計 | Gemini Cloud Assist |
1.2 技術要件を満たすクラウドソリューションインフラの設計
可用性とスケーラビリティ
技術要件の中心は NFR（非機能要件）。可用性・スケーラビリティ・性能・セキュリティの各要件を満たすサービス選定が問われます。
可用性のレイヤー
| 構成 | 典型例 | 可用率の目安 |
|---|---|---|
| 単一 VM・1 ゾーン | 個別 GCE インスタンス | 99.5% |
| Multi-zone | Regional MIG + Cloud SQL HA | 99.99% |
| Multi-region | Spanner Multi-region + Global LB | 99.999% |
| Global Active-Active | Spanner + Global LB + Cloud CDN | 99.999%+ |
サービス別の冗長化方式
| サービス | 冗長化レベル | 詳細 |
|---|---|---|
| Compute Engine | ゾーン | MIG でゾーン跨ぎ、自動ヘルスチェック |
| GKE | ゾーン / リージョナル | Regional クラスタはコントロールプレーンも冗長 |
| Cloud SQL | ゾーン HA | 同期スタンバイ、Cross-region read replica |
| Spanner | リージョン / マルチリージョン | Multi-region は強整合性で 99.999% SLA |
| Cloud Storage | リージョン / デュアル / マルチ | クラスと地理範囲を組合せ |
| Cloud Load Balancing | グローバル / リージョナル | Global は自動でリージョン跨ぎ振り分け |
DR 戦略（RTO/RPO で構成を変える）
RTO（復旧目標時間）と RPO（許容データ損失量）を整理して、4 つの戦略から選択します。
| 戦略 | RTO | RPO | コスト | 用途 |
|---|---|---|---|---|
| Backup & Restore | 数時間 | 数時間 | 低 | 非クリティカル |
| Pilot Light | 数十分 | 数分〜時間 | 中低 | 中重要度 |
| Warm Standby | 数分 | 数分 | 中 | 重要 |
| Hot Standby (Active-Active) | 数秒 | 0 | 高 | ミッションクリティカル |
🔧 設計判断のトレードオフ — 3 ケース
ケース 1：コスト vs 信頼性（要件: 月 99.95% + 月 $5,000 以内）
マルチリージョン構成だと月 $15,000 ↑。
- A: シングルリージョン Cloud SQL HA + GKE Regional（コスト低、99.95% 達成可能）✅
- B: マルチリージョン Spanner + GKE Multi-cluster（コスト高、過剰）
正解は A。要件を満たす最小コスト構成を選ぶ。
ケース 2：開発速度 vs 柔軟性（要件: 3 ヶ月で MVP リリース）
自前 K8s だと 1 ヶ月インフラ構築で消える。
- A: Cloud Run（開発速度最優先）✅
- B: GKE（柔軟性最優先・MVP には過剰）
正解は A。MVP は速度優先、拡張時に GKE 移行も可能。
ケース 3：グローバル展開 vs シンプルさ（要件: 全世界 200ms 以内）
シングルリージョンだと太平洋越え 300ms+。
- A: Spanner Multi-region + Global LB + Cloud CDN ✅
- B: 各リージョンに独立した Cloud SQL + アプリ（強整合性なし）
正解は A。強整合性が必要なら Spanner 一択。
🔧 SLI / SLO / SLA の関係
[SLI: Service Level Indicator] ← 測定値（例: 5xx エラー率）
↓
[SLO: Service Level Objective] ← 内部目標（例: 99.9%）
↓
[SLA: Service Level Agreement] ← 顧客契約（例: SLO を下回ったら返金）
→ SLO を厳しめに設定（SLA より厳しく）して
エラーバジェット内で改善を回すのが SRE の標準
🎯 可用性 即答
| 要件 | 即答 |
|---|---|
| 単一 VM | 99.5% |
| Multi-zone (MIG) | 99.99% |
| Multi-region | 99.999% |
| Spanner Multi-region SLA | 99.999% |
| HA VPN SLA | 99.99% |
| Classic VPN SLA | 99.9% |
| Dedicated Interconnect SLA（単独 / HA） | 99.9% / 99.99% |
1.3 ネットワーク・ストレージ・コンピュートリソースの設計
1.3.1 ネットワーク設計の基礎
GCP の VPC は プロジェクト横断のグローバルリソース。AWS/Azure と違い 1 VPC で複数リージョンのサブネットを扱えます。
プロジェクト
└─ VPC ネットワーク（グローバル）
├─ サブネット（リージョン A: 10.0.1.0/24）
├─ サブネット（リージョン B: 10.0.2.0/24）
├─ ファイアウォール ルール
├─ ルート
└─ Cloud Router（BGP 用）
ネットワーク接続方式マトリクス
| 方式 | 用途 | 帯域 | SLA (HA) | 暗号化 |
|---|---|---|---|---|
| Dedicated Interconnect | 大規模・低レイテンシ専用線 | 10 Gbps / 100 Gbps | 99.99% | なし（必要なら MACsec） |
| Partner Interconnect | 中規模・パートナー経由 | 50 Mbps – 50 Gbps | 99.99% | なし |
| Cross-Cloud Interconnect | GCP ↔ AWS/Azure 直結 | 10/100 Gbps | 99.99% | なし |
| HA VPN | 中小規模・暗号化トンネル | 最大 3 Gbps/トンネル | 99.99% | あり（IPsec） |
| Classic VPN | レガシー（非推奨） | 最大 3 Gbps | 99.9% | あり |
VPC 共有方式
| 方式 | 用途 | 特徴 |
|---|---|---|
| Shared VPC | 組織内の複数プロジェクトでネットワーク共有 | ホスト + サービスプロジェクトの集中管理 |
| VPC Peering | 異なる VPC 間の接続 | 1:1 接続、推移性なし |
| Private Service Connect (PSC) | サービスエンドポイント公開 | プライベート IP でマネージドサービスへ |
| Network Connectivity Center (NCC) | ハブ&スポーク統合 | 複数 VPN / Interconnect / SD-WAN を一元管理 |
1.3.2 ストレージ選定マトリクス（最重要）
あなたのデータは？
├── オブジェクト（ファイル、画像、動画、バックアップ）
│ └── Cloud Storage
│ ├── Standard（頻繁アクセス）
│ ├── Nearline（30日以上、月1回）
│ ├── Coldline（90日以上、四半期1回）
│ └── Archive（365日以上、年1回）
│
├── 共有ファイルシステム（NFS/SMB）
│ └── Filestore
│
├── ブロック（VM ディスク）
│ └── Persistent Disk / Hyperdisk
│
├── リレーショナル
│ ├── 単一リージョン → Cloud SQL (MySQL/PostgreSQL/SQL Server)
│ ├── PostgreSQL 高性能 → AlloyDB
│ └── グローバル強整合性 → Spanner
│
├── ドキュメント / モバイル同期
│ └── Firestore
│
├── ワイドカラム / 時系列・IoT
│ └── Bigtable
│
├── キャッシュ
│ └── Memorystore (Redis / Memcached / Valkey)
│
└── 分析 / DWH
└── BigQuery
Cloud Storage のストレージクラス
| クラス | アクセス頻度 | 最低保持期間 | 取り出し料金 |
|---|---|---|---|
| Standard | 頻繁 | なし | 無料 |
| Nearline | 月 1 回 | 30 日 | あり |
| Coldline | 四半期 1 回 | 90 日 | あり |
| Archive | 年 1 回 | 365 日 | 高い |
💡 Autoclass有効化するとアクセスパターンに応じて自動でクラス変更（手動ライフサイクル不要）。新規バケットでの推奨設定。
1.3.3 コンピュート選定フローチャート
ステートフル（VM 状態を保持） or 自由な OS が必要？
YES → Compute Engine（IaaS）
NO ↓
Kubernetes が必要？
YES → GKE（コンテナオーケストレーション）
├── Autopilot: 完全マネージド、Pod 単位課金
└── Standard: ノード管理あり、柔軟
NO ↓
ステートレス HTTP / イベント駆動？
YES → Cloud Run / Cloud Run functions
├── Cloud Run: コンテナベース、HTTP / イベント駆動
└── Cloud Run functions: 関数ベース、軽量（旧 Cloud Functions Gen2）
NO ↓
Web/モバイルアプリで標準ランタイムでOK？
YES → App Engine（PaaS）
コンピュート選定マトリクス
| サービス | 抽象度 | スケーリング | 課金 | 用途 |
|---|---|---|---|---|
| Compute Engine | IaaS | 手動 / Auto | VM 単位（秒課金） | レガシー移行、特殊 OS、GPU/TPU |
| GKE Standard | K8s | Node / Pod | Node 単位 | マイクロサービス、複雑な K8s |
| GKE Autopilot | K8s マネージド | Pod 単位 | Pod リソース要求 | 標準ワークロード、運用最小化 |
| Cloud Run | サーバーレス | 0〜1000+ | リクエスト課金 | ステートレス HTTP、API |
| Cloud Run functions | サーバーレス | 0〜N | 呼出回数 + 実行時間 | イベント駆動（旧 Cloud Functions Gen2） |
| App Engine | PaaS | 0〜N | インスタンス時間 | レガシー Python / Java Web |
Spot VM vs Standard VM
| 項目 | Spot VM | Standard VM |
|---|---|---|
| 価格 | 最大 91% 割引 | 通常 |
| 中断 | 24 時間以内に終了の可能性 | なし |
| 用途 | バッチ、CI/CD、Spark、ML 学習 | 本番アプリ、DB |
| 再起動 | 自動再起動なし | あり |
🔧 LB 選定マトリクス（7 種類）
GCP の Cloud Load Balancing は 3 軸（スコープ × 公開範囲 × 方式）で 7 種類。「Global External Application LB」が最も汎用的な第一候補。
| LB タイプ | プロトコル | スコープ | 用途 |
|---|---|---|---|
| Global External Application LB | HTTP(S) | グローバル | 一般的な Web/API、Anycast IP |
| Regional External Application LB | HTTP(S) | リージョン | リージョン固定の Web |
| Global External Proxy NLB | TCP/SSL | グローバル | TCP プロキシ（Anycast） |
| Regional External Passthrough NLB | TCP/UDP | リージョン | 直接通信、IP 保持 |
| Cross-region Internal Application LB | HTTP(S) | リージョン跨ぎ内部 | マルチリージョン内部 API |
| Internal Application LB | HTTP(S) | リージョン内部 | マイクロサービス間 |
| Internal Passthrough NLB | TCP/UDP | リージョン内部 | DB / 特殊プロトコル |
🔧 Private Service Connect (PSC) — 3 パターン
PSC for Google APIs ─► googleapis.com にプライベート IP でアクセス
PSC for Published Services ─► 自社サービスをエンドポイント化（マルチテナント SaaS）
PSC for Managed Services ─► Cloud SQL / Memorystore / AlloyDB へプライベート接続
🔧 Cloud SQL vs AlloyDB vs Spanner
| 観点 | Cloud SQL | AlloyDB | Spanner |
|---|---|---|---|
| 用途 | 一般 OLTP | PostgreSQL 高性能 OLTP/HTAP | グローバル強整合性 OLTP |
| 互換性 | MySQL/PostgreSQL/SQL Server | PostgreSQL 互換 | 独自（PostgreSQL 互換あり） |
| スケール | リードレプリカ | リードプール（自動 4 倍） | 自動水平スケール |
| グローバル | リージョナル | リージョナル | マルチリージョン強整合性 |
| 価格帯 | 中 | 中高 | 高 |
🔧 BigQuery vs Bigtable
| 観点 | BigQuery | Bigtable |
|---|---|---|
| 用途 | 分析 (OLAP) | 時系列・IoT・大量書込 (Wide-column) |
| クエリ言語 | SQL | HBase API / SQL (Bigtable Studio) |
| レイテンシ | 秒〜分 | ミリ秒 |
| スケール | サーバーレス | ノード型（手動 or Autoscaling） |
| 課金 | クエリ量 or Reservation | ノード時間 + ストレージ |
🔧 GKE Autopilot vs Standard
| 観点 | Autopilot | Standard |
|---|---|---|
| ノード管理 | Google 管理 | 自己管理 |
| 課金 | Pod 単位（リソース要求） | Node 単位 |
| カスタマイズ | 制限あり | 完全自由 |
| 推奨用途 | 新規・標準ワークロード | 特殊要件、GPU/TPU、規定 OS |
🔧 Cloud Run vs Cloud Run functions
| 観点 | Cloud Run | Cloud Run functions |
|---|---|---|
| 単位 | コンテナイメージ | 関数 |
| 用途 | ステートレス HTTP、API、Web、Worker | イベント駆動（GCS、Pub/Sub 等） |
| 言語 | 任意（コンテナ可能なら） | Node.js, Python, Go, Java, Ruby, PHP, .NET |
| 最大実行時間 | 60 分 | 60 分 (HTTP) / 9 分 (イベント) |
🎯 ストレージ即答
| 要件 | 答え |
|---|---|
| オブジェクト | Cloud Storage（Standard / Nearline / Coldline / Archive） |
| 共有ファイル（NFS / SMB） | Filestore |
| VM ブロック | Persistent Disk / Hyperdisk |
| OLTP 単一リージョン | Cloud SQL |
| OLTP PostgreSQL 高性能 | AlloyDB |
| OLTP グローバル強整合性 | Spanner Multi-region |
| 分析 / DWH | BigQuery |
| 時系列・IoT 大量書込 | Bigtable |
| ドキュメント / モバイル同期 | Firestore (Native) |
| キャッシュ | Memorystore |
🎯 コンピュート即答
| 要件 | 答え |
|---|---|
| ステートフル / 特殊 OS / レガシー | Compute Engine |
| Kubernetes 必須 | GKE |
| 標準ワークロード K8s | GKE Autopilot |
| ステートレス HTTP・API | Cloud Run |
| イベント駆動軽量 | Cloud Run functions |
| バッチ・CI/CD・中断許容 | Spot VM |
| 物理ノード占有・BYOL | Sole Tenant Node |
| メモリ暗号化（規制） | Confidential VM |
🎯 ネットワーク即答
| 用途 | 答え | SLA |
|---|---|---|
| 大規模・低レイテンシ | Dedicated Interconnect | 99.99% (HA) |
| 中規模・パートナー経由 | Partner Interconnect | 99.99% (HA) |
| GCP ↔ AWS/Azure 直結 | Cross-Cloud Interconnect | 99.99% (HA) |
| 暗号化必要・中小規模 | HA VPN | 99.99% |
| グローバル Web/API | Global External Application LB | — |
| TCP/UDP 直接・IP 保持 | Regional External Passthrough NLB | — |
| 組織内複数プロジェクト集中管理 | Shared VPC | — |
| ハブ&スポーク統合 | Network Connectivity Center (NCC) | — |
1.4 移行計画の作成（6R / Migration Center）
移行方法（データ量別）
| データ量 | 方法 | 期間 |
|---|---|---|
| < 1 TB | gcloud / gsutil で直接アップロード | 数時間 |
| 1-10 TB | Storage Transfer Service（オンライン） | 数日 |
| 10-100 TB | Storage Transfer Service + 専用線 | 1-2 週 |
| > 100 TB | Transfer Appliance（物理デバイス郵送） | 数週間 |
Database Migration Service (DMS)
オンプレ・他クラウドの DB を Cloud SQL / Spanner に 最小ダウンタイムで移行するサービス。
- MySQL → Cloud SQL for MySQL
- PostgreSQL → Cloud SQL for PostgreSQL / AlloyDB
- SQL Server → Cloud SQL for SQL Server
- Oracle → AlloyDB / PostgreSQL（最近追加）
🔧 移行戦略 6R（最頻出）
| 戦略 | 別名 | 内容 | 期間 | コスト/工数 |
|---|---|---|---|---|
| Rehost | Lift & Shift | VM をそのまま移行 | 短 | 低 |
| Replatform | Lift & Reshape | 一部マネージド化（DB を Cloud SQL に） | 中 | 中 |
| Refactor | Re-architect | クラウドネイティブ化（マイクロサービス） | 長 | 高 |
| Repurchase | Drop & Shop | SaaS に置き換え（Salesforce 等） | 中 | 中 |
| Retain | Keep | クラウドに移行せず維持 | — | — |
| Retire | Decommission | システム廃止 | 短 | 低 |
🔧 6R 判断フローチャート
このシステムは将来も必要？
NO → Retire（廃止）
既存の SaaS で代替可能？
YES → Repurchase（置換）
クラウド化のメリットがある？
NO → Retain（維持）
YES ↓
クラウドネイティブに作り直す価値ある？
YES → Refactor（再構築）
NO ↓
マネージドサービスを一部使う？
YES → Replatform（部分マネージド化）
NO → Rehost（そのまま移行）
🔧 Migration Center（2024 年以降）
旧 Stratozone を統合した 移行アセスメント・計画・実行プラットフォーム。
主要機能
- Discovery: オンプレ環境を自動スキャン（mCollector / vSphere / Hyper-V）
- Assessment: ワークロード評価（適合度、推奨サービス、コスト試算）
- Recommendation: 6R 戦略の推奨
- Migration Plan: 移行ウェーブと依存関係の可視化
- Migration Execution: M4CE / DMS と連携
試験キーワード対応
- 「オンプレ環境のアセスメント」→ Migration Center
- 「移行コスト試算」→ Migration Center
- 「6R 推奨」→ Migration Center
- 「Stratozone」→ 旧名（新名は Migration Center）
🎯 6R 即答
- Rehost: そのまま移行（Lift & Shift）
- Replatform: 一部マネージド化（DB を Cloud SQL）
- Refactor: クラウドネイティブ化
- Repurchase: SaaS 置換
- Retain: 維持
- Retire: 廃止
🎯 移行サービス即答
| 要件 | 答え |
|---|---|
| 移行アセスメント | Migration Center（旧 Stratozone） |
| VM 移行 | Migrate to Virtual Machines (M4CE) |
| DB 移行（最小ダウンタイム） | Database Migration Service |
| 大量データ移行（>100 TB） | Transfer Appliance |
| 中量データ移行（10-100 TB） | Storage Transfer Service |
| BigQuery 移行 | BigQuery Data Transfer Service |
1.5 将来のソリューション改善の構想（AI/ML 最新項目）
クラウドファースト設計の原則
マネージドサービス優先
自前運用より GCP マネージドを使う
サーバーレス優先
必要なときだけリソース消費
API ファースト
機能を API で公開、疎結合化
Infrastructure as Code
Terraform 等で宣言的に管理
GitOps
Git を Source of Truth に
観測可能性
監視・ロギング・トレースを最初から組み込む
Vertex AI — ML プラットフォームの全体像
GCP の ML プラットフォーム。データ準備 → 学習 → デプロイ → 監視 を統合管理。
Vertex AI の主要機能
├── AutoML（コードなしで学習）
├── Custom Training（独自モデル学習）
├── Pipelines（ML ワークフローオーケストレーション）
├── Feature Store（特徴量管理）
├── Workbench（Jupyter 環境）
├── Model Registry（モデル管理）
└── Model Garden（事前学習モデルカタログ）
Gemini と Model Garden
- Gemini: Google の最新 LLM（Pro / Flash / Nano）
- Model Garden: Gemini に加え、PaLM、Llama、Claude、Mistral など 200+ モデルを統一インターフェース
AI Hypercomputer（最新追加）
大規模 AI 学習・推論のためのスーパーコンピュータ製品。
ハードウェア層
- TPU v5e / v5p / Trillium
- GPU H100 / A100 / L4 (A3 / A3 Ultra / A4)
- Jupiter NW（光回線、3.2 Tbps/ノード）
ストレージ層
- Cloud Storage + Anywhere Cache
- Hyperdisk ML（複数 VM 同時アタッチ）
- Parallel File System (Lustre)
ソフトウェア層
- JAX / PyTorch / TensorFlow
- Pathways（マルチホスト分散）
- XLA コンパイラ
統合ツール
- Kubernetes / Slurm
- Vertex AI Pipelines
- Dynamic Workload Scheduler (DWS)
Gemini Cloud Assist（最新追加）
GCP コンソール内に組み込まれた AI アシスタント。
- アーキテクチャ設計の支援（「100 RPS のチャットボットを設計したい」など）
- 障害時のログ解析支援
- gcloud CLI コマンド生成
- Terraform / IaC コードのレビュー
- ドキュメント検索（自然言語）
🔧 「自前 ML vs マネージド AI API」の選定
| 状況 | 推奨 |
|---|---|
| 既製機能でOK（OCR、翻訳、感情分析） | Pre-trained API（Vision API、NL API 等） |
| 自社データで分類モデル | AutoML |
| 既存 ML コードを GCP に移行 | Vertex AI Custom Training |
| LLM ベースのチャット / Q&A | Gemini + Agent Builder |
| 大規模 LLM 学習 | AI Hypercomputer + Vertex AI |
🔧 Gemini Enterprise Agent Platform（旧 Vertex AI Agent Builder）
LLM 駆動のエージェントを構築するプラットフォーム。
- Agents: 業務特化 AI エージェント（カスタマーサポート、検索 等）
- Data Stores: ナレッジソース（Web / 構造化データ / 非構造化データ）
- NotebookLM: AI ノートブック（複数ソースから引用付き回答）
- Discovery AI（旧 Vertex AI Search）: エンタープライズ検索
🔧 コスト最適化の 5 観点
1. Right-sizing → Recommender 活用
2. Committed Use → 1-3 年契約で 30-55% 割引
3. Spot VM → バッチ向け、最大 91% 割引
4. Autoscaling → MIG / Cloud Run / GKE
5. Storage 階層化 → GCS Autoclass / BigQuery パーティション
- Cloud Billing: 課金状況確認
- Billing Budgets: 予算アラート
- Recommender: コスト最適化提案（VM Right-sizing 等）
- Active Assist: AI ベースの最適化提案
🔧 進化を見越したアーキ
- 疎結合: Pub/Sub でサービス間を非同期化
- マルチリージョン対応: 単一リージョンでもデータ設計はマルチを見越す
- マイクロサービス志向: モノリスでもサービス境界を明確に
- 拡張ポイント: API ゲートウェイ（Apigee）で将来の機能追加を容易に
🎯 AI/ML 最新サービス（必須暗記）
| サービス | 用途 |
|---|---|
| Vertex AI | ML プラットフォーム（学習 / 推論統合） |
| Vertex AI Pipelines | ML ワークフローオーケストレーション |
| Vertex AI Workbench | マネージド Jupyter |
| Vertex AI Feature Store | 特徴量管理 |
| Model Garden | 事前学習モデルカタログ（Gemini / Claude / Llama / Mistral） |
| Gemini | Google の最新 LLM（Pro / Flash / Nano） |
| Gemini Enterprise Agent Platform | LLM エージェント構築（旧 Vertex AI Agent Builder） |
| Discovery AI | エンタープライズ検索（旧 Vertex AI Search） |
| NotebookLM | AI ノートブック（引用付き） |
| AI Hypercomputer | TPU/GPU + Jupiter NW + ストレージ統合 |
| Gemini Cloud Assist | GCP コンソール内 AI 支援 |
⚖️ 設計判断のトレードオフ — まとめ
試験では「最も適した設計は？」が問われます。要件のキーワードから 6 柱の優先順位を立て、最終的に「ビジネス要件を満たす最小コストで合理的な構成」を選びます。
設計判断のチェックポイント
- ビジネス要件キーワード抽出（コスト / 性能 / 可用性 / 規制）
- 非機能要件 (NFR) を特定
- Well-Architected 6 柱で優先順位付け
- 選択肢を「該当する柱」で評価
- 最も「ビジネス要件に合致」する選択肢を選ぶ
よくあるひっかけ
- 過剰スペック（マルチリージョン Spanner を要件以上に勧める）
- SLA の混同（Classic VPN 99.9% / HA VPN 99.99%）
- リネームの旧名（Cloud Functions Gen2 → Cloud Run functions など）
- 「VPC SC は IAM の代替ではない」（補完）
- 「Spanner ≠ Cloud SQL」（強整合性 + グローバル要件で Spanner 一択）
🔄 サービスリネーム最新一覧
2024-2025 年の改訂で多数のリネームがありました。旧名で出題されるひっかけにも注意。
| 旧名 | 新名 |
|---|---|
| Cloud Functions Gen2 | Cloud Run functions |
| Vertex AI Agent Builder | Gemini Enterprise Agent Platform |
| Vertex AI Search | Discovery AI |
| BeyondCorp Enterprise | Chrome Enterprise Premium |
| Cloud DLP | Sensitive Data Protection |
| Anthos（一部） | GKE Enterprise |
| Stratozone | Migration Center |
| Dialogflow CX | Conversational Agents |
| Actifio | Backup and DR Service |
🎯 要点と暗記 — 一問一答
試験直前の最終チェック。詳細は折りたたみで表示します。
Q1. グローバルで強整合性のトランザクションが必要な OLTP は？
A. Spanner Multi-region。99.999% SLA、無停止スケール、強整合性のすべてを満たすのは Spanner のみ。
Q2. オンプレ 800 TB を GCP に移行したい。最適な方法は？
A. Transfer Appliance（物理デバイス郵送でオフライン転送）。100 TB を超える場合はネットワーク転送が非現実的。
Q3. オンプレ MySQL を Cloud SQL へ最小ダウンタイムで移行したい。
A. Database Migration Service (DMS)。継続レプリケーション付き移行で切替直前まで同期。
Q4. 「VMware 環境を 6 ヶ月で GCP に移したい、ハイパーバイザは VMware 維持」は？
A. Google Cloud VMware Engine (GCVE) + HCX。BYOL でライセンス継続、HCX で無停止ライブマイグレーション。
Q5. Spot VM の最大割引率は？中断通知は？
A. 最大 91% 割引、24 時間以内に終了の可能性。ACPI G2 シグナル / Shutdown スクリプトで通知。MIG と組み合わせて自動再作成するのが定番。
Q6. Committed Use Discount の割引率は？（1 年 / 3 年）
A. 1 年 30% / 3 年 55%。継続使用割引（Sustained Use Discount）は最大 30%（こちらは自動）。
Q7. ステートレス HTTP API でサーバーレス、コンテナベース、最大 60 分実行のサービスは？
A. Cloud Run。イベント駆動の関数なら Cloud Run functions（旧 Cloud Functions Gen2）。
Q8. 大規模 LLM 学習で TPU と GPU を混在させたい。
A. AI Hypercomputer + Pathways。JAX / PyTorch で透過的にマルチホスト分散を扱える。
Q9. Claude や Llama を GCP で使いたい。
A. Model Garden。Gemini と一緒に Claude / Llama / Mistral / Imagen / Gemma など 200+ モデルを統一インターフェースで利用可能。
Q10. オンプレ環境を自動スキャンして移行プランを作りたい。
A. Migration Center（旧 Stratozone）。Discovery / Assessment / 6R Recommendation / Migration Plan を統合。
💡 必殺フレーズ集（試験当日用）
| 状況 | 即答 |
|---|---|
| 「グローバル + 強整合性」 | Spanner Multi-region |
| 「99.9% 以上の可用性」 | Multi-region / HA 構成 |
| 「最小ダウンタイム DB 移行」 | Database Migration Service |
| 「オンプレ → GCP 高速接続」 | Dedicated Interconnect + HA VPN バックアップ |
| 「マルチクラウド接続」 | Cross-Cloud Interconnect / NCC |
| 「API 管理（フルライフサイクル）」 | Apigee |
| 「軽量 API ゲートウェイ」 | API Gateway / Cloud Endpoints |
| 「大量データ移行（>100TB）」 | Transfer Appliance |
| 「中量データ移行（10-100TB）」 | Storage Transfer Service |
| 「LLM ベース対話システム」 | Gemini + Agent Builder |
| 「大規模 LLM 学習」 | AI Hypercomputer + Vertex AI |
| 「移行アセスメント」 | Migration Center |
| 「AI 支援設計・トラブルシュート」 | Gemini Cloud Assist |
| 「VMware そのまま」 | VMware Engine (GCVE) + HCX |
📌 試験中の判断フローチャート（暗記推奨）
質問を読む
↓
ビジネス要件キーワード抽出（コスト / 性能 / 可用性 / 規制）
↓
非機能要件 (NFR) 特定
↓
Well-Architected 6 柱で優先順位付け
↓
選択肢を「該当する柱」で評価
↓
最も「ビジネス要件に合致」する選択肢を選ぶ
🔑 5 分で復習する箇条書きまとめ
- Well-Architected = 運用 / セキュリティ / 信頼性 / 性能 / コスト / 持続可能性 の 6 柱
- コンピュート: GCE / GKE / Cloud Run / Cloud Run functions / App Engine
- ストレージ: GCS / Cloud SQL / Spanner / BigQuery / Bigtable / Firestore / Memorystore / Filestore
- ネットワーク: VPC / Shared VPC / Peering / PSC / NCC、Interconnect 3 種 + VPN 2 種、LB 7 種
- 移行: 6R + Migration Center
- AI/ML: Vertex AI + Gemini + Model Garden + AI Hypercomputer + Gemini Cloud Assist
- 可用性: 単一 99.5% / Multi-zone 99.99% / Multi-region 99.999%
- コスト: Right-sizing + Committed Use + Spot + Autoscaling
- リネーム: Cloud Functions → Cloud Run functions、Cloud DLP → Sensitive Data Protection 等