| 認定試験 | 難易度 | おすすめの取得順序 |
|---|---|---|
| Professional Cloud Architect | ★★☆☆☆（2） | 1 |
| Professional Cloud Developer | ★★☆☆☆（2） | 2 |
| Professional Data Engineer | ★★★☆☆（3） | 3 |
| Professional Cloud Database Engineer | ★★★☆☆（3） | 4 |
| Professional Cloud DevOps Engineer | ★★★☆☆（3） | 5 |
| Professional Cloud Security Engineer | ★★★★☆（4） | 6 |
| Professional Cloud Network Engineer | ★★★★★（5） | 7 |
| Professional Machine Learning Engineer | ★★★★★（5） | 8 |
Professional Cloud Architect（PCA）
Google Cloud 上で様々なビジネス要件に基づくセキュアでスケーラブルなソリューションを設計、開発、管理する技術的なスキルと知識を証明する資格です。
ケーススタディが出題の中心になっており、ビジネス要件を満たす Google Cloud ソリューションを適切に選択する能力が問われます。
PCA では多くの Google Cloud ソリューションを幅広く取り上げており、他の Professional 認定試験を包括した内容が盛り込まれています。
Professional 認定試験の中では 難易度が低め なので、これから Google Cloud を学び始める人、Google Cloud 認定試験を受けようと思っている人にとっては最適な資格です。
問われる内容
Google Cloud 上でのエンタープライズアーキテクチャ設計と運用全般がテーマで、特に以下の領域が頻出です。
- 組織管理と IAM・ポリシ設計
- Organization Policy, IAM ロール設計, サービスアカウントと Workload Identity, 監査設計（Cloud Audit Logs）
- ネットワーク設計と接続性
- VPC, サブネット, Cloud NAT, Cloud DNS, 負荷分散（L4, L7, Global, Regional, Internal, External）, Cloud VPN, Cloud Interconnect, VPC Peering
- コンピュートとデプロイ戦略
- Compute Engine, GKE, Cloud Run, Cloud Functions, App Engine, デプロイ方式（Blue-Green, Canary）, アーティファクト管理（Artifact Registry）
- データ層の選定と移行
- Cloud Storage, Cloud SQL, Spanner, Bigtable, Firestore, BigQuery の使い分け, Backup と PITR, Database Migration Service
- 可観測性と運用設計
- Cloud Monitoring, Cloud Logging, アラーティング, インシデント運用, Log Routing と自動処理（Pub/Sub 連携）
- セキュリティと統制
- IAM ロール（最小権限の原則）, Cloud KMS と CMEK, Cloud Armor, Binary Authorization, Cloud DLP, VPC Service Controls, Secret 管理
- コスト最適化と可用性
- Autoscaling, Committed Use, リソース適正化（Recommender）, 高可用性構成, マルチリージョンや DR の設計
単にサービス名を知っているかではなく、ビジネス要件と制約を読み解き、最適な構成を根拠をもって選べるかが問われます。
求められる知識
アーキテクチャ判断を要件から読み取り、信頼性・セキュリティ・スケーラビリティ・コスト・運用性等のバランスで最適化できることが求められます。
特に以下のような知識が試験対策として重要になります。
- 可用性・一貫性・レイテンシ・コスト・運用負荷のトレードオフの理解
- Organization Policy の代表制約、最小権限の IAM 設計、サービスアカウント運用、監査ログの活用
- VPC とルーティング、L4 と L7 の使い分け、Global と Regional の選択、VPN と Interconnect の選択基準
- Cloud SQL と Spanner と Bigtable と Firestore と BigQuery の違い、DB バックアップと PITR、代表的な移行パターン
- GCE と GKE と Cloud Run と Functions と App Engine の選択軸、B/G デプロイメントやカナリアリリース、コンテナセキュリティ（Binary Authorization）
- メトリクスとログの設計、アラートとオンコール（Cloud Monitoring / Alert Policy）運用、ログエクスポートと自動処理、IaC と CI/CD（Cloud Build / Terraform 等）の基本
抑えておくべきポイント
要件ドリブンで設計を固定する
PCA はケーススタディが中心になります。
ビジネス要件を読み解いた上で、何を最優先にするか（可用性・レイテンシ・コスト）決定して最適なソリューションを選択します。
最小権限と境界で守る
GSA / IAM の利用は常に最小権限の原則（PoLP）に基づいて設計します。
階層型アクセス制御 について理解した上で、組織ポリシで一貫したポリシを適用し、IAM ロールを用いてリソース単位で細やかな権限を設定します。
マネージドサービスやネットワーク経路は Cloud Armor や Firewall で制御します。
暗号化や PII 等の要件が課せされているものには CMEK や Cloud DLP でのデータ保護を検討します。
正しい実行基盤を選ぶ
状態管理やスケール要件に合わせて GCE, GKE, Cloud Run, Functions, App Engine を選択する。運用負荷を下げたいならマネージドやサーバレスを優先する。
データベースのユースケース
トランザクションは Cloud SQL, グローバル強整合は Spanner, 高スループットなキーアクセスは Bigtable
DevOps と Observability
CI/CD と IaC 関連で、開発からデプロイまでのパイプラインに必要なソリューション（Cloud Build / Cloud Deploy）について理解しておく。
Observability では、Cloud Monitoring / Cloud Logging / Cloud Trance / Cloud Profiler の Alert Policy や Error Reporting について理解しておく。
選択肢の中に手動作業（Shell Script）ベースのものが登場しますが、「最小限の運用コストで」といった表現が含まれている場合等、基本的に Google Cloud のマネージドサービスを使う方がベターです。
Professional Cloud Developer（PCD）
Google Cloud 上でセキュアかつスケーラブルなアプリケーションを設計・開発する能力を証明する資格です。
Cloud Build 等を使用した CI/CD、GKE やその他コンピューティング系プロダクトにフォーカスが当たり、多くのエンジニアにとって馴染みのあるトピックが豊富に出題されます。
PCA ではビジネスの要件から最適なソリューションを選択する能力が問われますが、PCD ではより技術的な内容に踏み込んでいます。
PCA を取得した上で、より実践的な内容（アプリケーションを Google Cloud で運用する）を学びたい人におすすめな資格です。
PCA よりも具体的な技術を扱いますが、Professional 認定試験の中では 難易度が低め で取得しやすい資格になっているので、PCA と合わせて最初に受けてみるのが良いでしょう。
問われる内容
Google Cloud 上でのクラウドネイティブ開発と運用全般がテーマで、特に以下の領域が頻出です。
- 実行基盤の選定と設計
- Cloud Run, Cloud Functions, GKE, App Engine, Compute Engine, ステートレス化とスケーリングの使い分け
- API 設計と公開
- Cloud Endpoints, Apigee, 認証と認可, ルーティング, CORS, レート制限
- アイデンティティとシークレット管理
- IAM, サービスアカウント, Workload Identity, Secret Manager
- CI/CD
- Cloud Build, Artifact Registry, ビルド構成とプライベートプール, デプロイ戦略（Blue-Green, Canary, Rolling）
- 可観測性と運用
- Cloud Logging, Cloud Monitoring, Cloud Trace, Cloud Profiler, アラートとインシデント運用
- メッセージングとデータアクセス
- Pub/Sub, Cloud Storage, Cloud SQL, Firestore, Bigtable, Serverless VPC Access と接続設計
求められる知識
- サービス間認証の基本
- サービスアカウントの付与, ロールの最小化, キーファイルではなくアタッチ運用, GKE は Workload Identity を優先。
- API ベストプラクティス
- バージョニング, 契約の互換性, 429 と 5xx への指数バックオフ, 冪等リトライ, レート制限とクォータ。
- デプロイとリリース管理
- Blue-Green, Canary, Rolling の違いとロールバック方針, トラフィック分割, ヘルスチェックと段階解放。
- CI/CD とアーティファクト
- Cloud Build のステップ設計, Artifact Registry の脆弱性スキャン, 署名と Binary Authorization による未署名拒否。
- シークレットと構成管理
- Secret Manager で保管, バージョン管理とローテーション, ランタイム注入, 環境別設定の扱い。
- 可観測性の組み込み
- 構造化ログ出力, 指標とアラートの設計, 分散トレースでのボトルネック特定, プロファイルでの最適化。
- 非同期処理と疎結合
- Pub/Sub の Pull と Push, デッドレター, 順序と重複の前提, バックプレッシャと再試行ポリシー。
抑えておくべきポイント
マネージドサービスとステートレス設計を基本に考える
Google Cloud の開発では、Cloud Run や Cloud Functions を代表とするマネージドな実行環境を使い、自前でインフラを抱えず、スケーリングや障害対応を Google に任せる設計が推奨されます。アプリケーションはステートレスであるべきで、セッション情報や一時データは Cloud Storage や Firestore, Memorystore などの外部に逃がす設計が問われます。設問では「アプリの負荷に応じたスケーリング」「インフラ運用を最小化したい」といった文脈から、適切な基盤を選べるかがポイントです。
サービス間認証は「鍵」より「アイデンティティ」を使う
長期保存されるサービスアカウントキーは基本的に非推奨です。Workload Identity（GKE）や Cloud Run の組み込み認証を活用し、IAM 権限だけで認証を完結させることがベストプラクティスです。試験では「認証情報を安全に管理したい」「キーファイルを配布したくない」といった要件から、Secret Manager + サービスアカウントの IAM 組み合わせを正しく選べるかが問われます。
段階的なリリース戦略とロールバック経路を確保する
Cloud Run や GKE, App Engine などは複数のリビジョンを同時に持てる環境を活かして、Blue-Green や Canary デプロイが可能です。試験では「ユーザー影響を抑えて安全に切り替えるには？」「異常時にすぐ戻すには？」という設問に対し、トラフィック分割やタグ付きリビジョンを活用した設計を選べるかが求められます。
非同期処理と冪等性でシステムを壊れにくくする
Pub/Sub や Eventarc を使った非同期処理では、一時的な障害・遅延・重複を前提とした設計が重要です。指数バックオフ, 冪等性の担保（例：処理済み ID の記録, リトライ前提のトランザクション設計）を行い、一回だけ成功すればよい処理としてモデル化することが鍵です。問題文に「同じイベントが複数届く可能性がある」とあれば、これにどう備えるかが問われます。
可観測性とセキュリティは“後付け”ではなく“最初から”
開発者は、Cloud Logging や Monitoring だけでなく、Trace や Profiler を使ったパフォーマンス分析まで含めた“観測できるコード”を実装することが求められます。さらに、CI/CD パイプライン内で Artifact Registry の脆弱性スキャンや署名（attestation）を行い、Binary Authorization によって未署名のイメージはデプロイ拒否する仕組みを設けます。試験では「信頼できるアーティファクトだけを本番に流すには？」という設問が出題されます。
Professional Data Engineer（PDE）
Google Cloud で大規模データセットを収集、変換、公開するデータ処理システムを設計、構築、運用する能力を証明する資格です。
BigQuery を中心に、データの収集、変換、可視化、機械学習モデルの構築といったデータエンジニアリングの基本的な概念と Google Cloud のサービスに関する知識が問われます。
昨今では ML モデルに関する話題からデータの利活用を促進するデータエンジニアリング領域に重心がシフトしているみたいです。
この辺りから専門的な内容が多くなり、PCA や PCD と比較して難しくなってきますが、後述の認定資格と比べると 難易度は中程度 だと思います。
すぐに実践できるプラクティスもあるので、Google Cloud を使ってデータエンジニアリングに従事する人であれば、資格勉強することでナレッジの幅が広がるかと思います。
問われる内容
Google Cloud 上でのデータ基盤の設計・構築・運用がテーマになっていて、特に以下の領域にフォーカスされています。
- データ取り込み設計
- ソース特性（頻度, 順序, 重複, スキーマ変化）に応じた取り込み方式の選定
- Datastream（CDC, Replication）, BigQuery External Table, FastExport（Teradata → BigQuery）, Cloud Storage 経由取り込み
- ストレージ選定とレイアウト
- 目的・SLA・コストに適した保管先と物理設計（分割, 並び, 履歴）の判断
- BigQuery（Partitioning, Clustering, Time Travel, Materialized View）, BigLake, Omni, Bigtable（スキーマ, Garbage Collection）, Cloud Storage
- データ処理（バッチ, ストリーム）
- イベントの時刻と取り込みの時刻の区別, 集計枠（Tumbling Window, Sliding Window, Hopping Window, Session Window）と遅延到着の扱い, Watermark と Reshuffle の方針を設計
- Dataflow（PCollection, PTransform, ParDo・DoFn）, Dataproc（Spark, Hadoop, Serverless）, Dataprep, Data Fusion（GUI 変換・統合, Wrangler）
- データ品質・メタデータ・運用
- 品質基準の自動検証, 変更影響の追跡, 依存関係・再試行・スケジュール管理の設計
- Dataform（SQL ELT, Assertion）, Dataplex（Metadata, Data Lineage, Data Quality Rules）, Cloud Composer（Airflow, DAG）
- セキュリティ・ガバナンスと共有
- 最小権限, 鍵管理, 匿名化を前提に, 安全で追跡可能なデータ共有の設計
- CMEK, Cloud DLP（検出, マスキング）, Analytics Hub
単にサービス名を知っているかではなく、ユースケースに対してどの設計を選ぶべきかを判断できるかが問われます。
求められる知識
データ要件を設計に落とし込んで、信頼性・スケーラビリティ・コスト効率・セキュリティを満たす基盤を運用できることが求められます。
- 取り込みと一貫性の設計：ソース特性に基づく選択, CDC とバッチの使い分け, 冪等性, 重複排除, スキーマ進化への対応
- ストレージ設計と物理レイアウト：BigQuery の Partitioning, Clustering, Time Travel, Materialized Views, Bigtable の Row Key 設計と Garbage Collection, BigLake 連携の理解
- 時間セマンティクスと処理設計：発生時刻と取り込み時刻の区別, Windowing と Watermark の設計, 遅延到着と再計算の方針
- クエリ最適化とコスト管理：スキャン削減の設計, 事前集計と再利用の戦略, 同時実行とリソース管理, コスト見積もりと監視
- データ品質・運用信頼性の担保：Data Quality Rules と Assertions の自動検証, 隔離と是正の手順, Data Lineage による影響範囲追跡, DAG に基づく依存管理と再試行, 冪等再実行
- セキュリティとガバナンス：最小権限, CMEK による鍵管理, Cloud DLP による検出とマスキング, Analytics Hub を用いた最小開示と監査可能性
抑えておくべきポイント
鮮度・正確性・コストの 3 つの観点
どのくらい新しいデータを、どのくらい正確に、どのくらいの費用で扱うかを最初に決めて、以降の設計をその方針に揃える。
アクセスパターン起点のデータ設計
どの軸で絞込・結合するのか（時間・地域・顧客・イベント）を先に決めて、スキーマ・パーティション・クラスタ・集約単位をその利用実態に合わせる。
時間の扱いでバッチとストリームを切り分ける
イベントが発生したタイミングとそれを処理するタイミングを分けて考え、集計の枠と遅れて来るデータの扱いを決定してどの時点の数値を正とするかを定める。
データ品質とリネージを運用の中心に置く
一意性や欠損等のチェックを自動化し、問題が出たら止めて、原因と影響を追跡して直す流れを用意する。
Secure by Design という考え方
権限は最小限にし、暗号化や匿名化を前提にする。
共有はコピーではなく参照で行い、必要な人に必要な範囲だけ見せる。
Professional Cloud Database Engineer（PCDE）
Google Cloud のデータベースソリューションの設計、構成、デプロイメントに関するスキルを証明する資格です。
この試験では、Google Cloud の全てのデータベースソリューションが登場します。
最近では Spanner や AlloyDB に関する問題が増えているようです。
データベースの特徴（NoSQL, RDBMS, Columnar）を理解していることが前提となっており、ユースケースや要件に応じた構成・配置方法について問われます。
一部ではデータベースの移行に関する問題も登場するため、Google Cloud 以外のデータベースサービス（Oracle, SQL Server, Amazon Aurora）についても軽く押さえておいたほうが良いでしょう。
問題範囲は Google Cloud のデータベースソリューションに集中しており、抑えておくべきポイントも局所化しているので、英語の壁だけ突破できれば 難易度は中程度 だと思います。
問われる内容
Google Cloud でのデータベース設計、構築、運用がテーマで、特に以下の領域にフォーカスされています。
- 高可用性（HA）と災害復旧（DR）の設計
- 同一リージョン内のマルチゾーン HA
- フェイルオーバとフェイルバック
- クロスリージョン Read Replica による DR、バックアップと PITR（Point In Time Recovery）の運用間隔と保持期間
- 接続方式とセキュリティ
- Private IP 接続：Service Networking、VPC Peering
- Public IP と Authorized Networks
- Cloud SQL Auth Proxy
- SSL TLS による経路暗号化
- IAM とロールの設計
- CMEK（Customer Managed Encryption Keys）の適用
- マイグレーションとレプリケーション
- Database Migration Service（Homogeneous / Heterogeneous）
- 外部プライマリからの継続レプリケーション、Import / Export、レプリケーション遅延の理解とリード分離
- モニタリングとメンテナンス運用
- Cloud Monitoring 指標（CPU、メモリ、ストレージ、接続数、遅延）
- Query Insights によるクエリ分析
- メンテナンスウィンドウ
- キャパシティオートスケーリング
- マシンタイプ変更・ストレージ拡張周りとダウンタイム
- プロダクト選定
- Cloud SQL：MySQL / PostgreSQL / SQL Server
- Spanner：水平スケールと強整合性
- Bigtable：高スループット NoSQL
- Firestore：ドキュメント指向 / ネイティブアプリケーション / Datastore モード
- Bare Metal Solution for Oracle の位置づけ
単にサービス名を知っているかではなく、ユースケースに対してどの構成を選ぶべきかを判断できるかが問われます。
求められる知識
データベース要件を設計に落とし込み、可用性（HA）/ 復旧性（DR）/ ACID / パフォーマンス / コスト / セキュリティを満たす運用ができること。
特に以下のような知識が試験対策として重要になります。
- マルチゾーン HA, フェイルオーバー, フェイルバック, クロスリージョン Read Replica, バックアップと PITR, RPO と RTO
- Private IP と Public IP の選択, Authorized Networks, Cloud SQL Auth Proxy, SSL と TLS, IAM の最小権限, CMEK
- Database Migration Service（DMS）, 外部プライマリからの継続複製, インポートとエクスポート, レプリケーションラグ, 読み取り分離, 一貫性モデル（強整合, 結果整合）
- 主要メトリクス監視, Query Insights の活用, インデックスと実行計画, ストレージとマシンタイプの調整, コスト最適化
- Cloud SQL のエディション差と制約, Spanner のスキーマ設計とホットスポット回避, Bigtable の Row Key 設計と Garbage Collection, Firestore のモード選択
抑えておくべきポイント
RPO と RTO を決める
まず、どれだけ失ってよいか（RPO）や どれだけで復旧したいか（RTO） を考えます。
設問に「数分以内の復旧」や「ゼロダウンタイム」のようなキーワードがあれば、同一リージョン内のマルチゾーン HA やフェイルオーバ、クロスリージョンレプリカによる DR を優先します。
誤操作や時点復元のニーズが書かれていれば、バックアップと PITR を組み合わせる選択が妥当策です。
RPO/RTO をベースに考えることで、HA、DR、バックアップ、レプリカ戦略のどれが必要になるのかを判断しやすくなります。
接続面を最小にする
接続方式は 非公開を基本、公開は例外 とします。
Private IP 経由で接続し、認証や経路暗号化は Cloud SQL Auth Proxy に任せる構成が原則的によりセキュアな解答です。
さらに最小権限（IAM）と CMEK（顧客管理鍵）を適用できるかを確認します。
Public IP と Authorized Networks を使うのは要件に明記があるときだけ、という優先度で選択肢を比較します。
リード負荷の分散
読み取り系の負荷は Read Replica に逃がすという設計意図を読み取ります。
Read Replica は非同期複製でラグがあるため、最新性が厳密に必要な参照や書き込みを伴う処理には不向きです。
設問で「ダッシュボード」「分析集計」「レポート」のような読み取り中心の用途が示されていればレプリカ活用が有効で、逆に「強い整合性」「最新の残高が必須」ならプライマリ参照を検討します。
垂直スケールと水平スケール
スケーリングの方向を早めに決めます。
単一リージョンのトランザクション処理でスケールアップ中心なら Cloud SQL、グローバル分散や強整合と水平スケールが必要なら Spanner、高スループットなキーアクセスが主目的なら Bigtable を選ぶイメージです。
設問中の「グローバルスケール」「強整合」「TB-PB 規模のスループット」「既存の MySQL / PostgreSQL 互換」といったワードがヒントになります。
パフォーマンス最適化とメンテナンス
前提、クエリパフォーマンスの調査は Query Insights（スロークエリの特定や実行計画の確認）、メンテナンスウィンドウ（実施時間の制御）と延期設定について理解しておきます。
リソースの変更はマシンタイプやディスク等、何を変更するかによって変わるためダウンタイム（再起動の有無）や影響範囲がどこまであるのかを理解しておきます。
データベースのマイグレーションについて「ダウンタイム最小」「できるだけ少ない作業量で」が強調されていれば、Database Migration Service（DMS）がまず第一選択となり、停止許容が許容できて、かつ小規模なら Export / Import での移行を検討します。
Professional Cloud DevOps Engineer（PCDOE）
Google Cloud におけるアプリケーションの継続的な運用と改善、パフォーマンス監視やトラブルシューティングといった DevOps の能力を証明する資格です。
アプリケーションの開発と運用サイクルを効率化するための Google Cloud のサービスやツールのプラクティスに関する知識が問われます。
Kubernetes（GKE）を中心に、CI/CD やリリース戦略、IaC、監視、ロギングといった DevOps の基本的な概念と SRE（SLI/SLO）の知識が求められます。
SRE や Platform Engineering に従事している人にとっては比較的馴染みのある内容になっていますが、一から学ぶ人にとってはノウハウや概念の習得から必要になるため 難易度は中〜高程度 に位置すると思います。
PCDOE は PCD をより突き詰めた内容だと言えます。
問われる内容
Google Cloud 上での継続的デリバリと信頼性運用全般がテーマとなっており、特に以下の領域が試験範囲として頻出です。
- サービス信頼性設計（SRE 原則）
- SLI, SLO, Error Budget, トイル削減, ポストモーテム, インシデント対応, Root Cause Analysis（RCA）
- 可観測性とメトリクス設計
- Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, OpenTelemetry, Scoping Project, アラート・ダッシュボード設計
- 継続的デリバリと変更管理
- Cloud Build, Cloud Deploy, Artifact Registry, Blue-Green / Canary / Rolling デプロイ, リリース戦略とロールバック
- CI/CD パイプラインのセキュリティ
- Binary Authorization, Attestation, 脆弱性スキャン, Secret 管理, シフトレフト（Shift Left）
- コンテナ運用とスケーリング
- GKE の HPA / VPA / Cluster Autoscaler, Workload Identity, Network Policy, Spot VM 活用
- コストとリソース管理
- 確約利用割引（CUD）, スポット VM, Recommender, SLA 設計, Infrastructure as Code（IaC）
SLO を軸にして安定性・変更速度・運用負荷のバランスをどう設計するかが問われます。
求められる知識
Google Cloud 上で安定したシステム運用と信頼性の高いリリース体制を実現するために、以下のような知識が求められます。
- SRE 原則と信頼性指標の設計
- SLI / SLO / Error Budget の意味と役割、可用性目標に対する変更・障害・トイルのバランス
- インシデント対応とポストモーテム
- IC（Incident Commander）/ OL / CL の役割、Blameless Postmortem、MTTD / MTTR の定義
- 監視と可観測性の構築
- Cloud Monitoring / Logging, メトリクスの種類（GAUGE / DELTA / CUMULATIVE）、カスタムメトリクス、ログベースメトリクス、アラート設計
- CI/CD パイプライン設計とセキュリティ
- Cloud Build のステップ構成とトリガー、Artifact Registry の脆弱性スキャン、署名と Binary Authorization、シークレット管理のベストプラクティス
- デプロイ戦略とロールバック設計
- Blue-Green, Canary, Rolling デプロイの違い、Cloud Deploy による段階的リリースと自動ロールバック設計
- スケーリングとコスト最適化
- GKE のスケーリング技術（HPA, VPA, Cluster Autoscaler）、スポット VM、Cloud Recommender によるリソース調整、確約利用割引（CUD）の活用
抑えておくべきポイント
SLO を軸にした判断がすべての起点になる
試験の多くは「どれが SLO を守る構成か？」「SLO を侵害した場合どうすべきか？」といった出題です。SLO の定義を起点に、変更速度・安定性・自動化のバランスを取る設計が求められます。Error Budget の使い方（消費しすぎ vs しなさすぎ）も含めて、SRE 思考の判断基準を持っておくことが重要です。
監視は"見て終わり"ではなく、改善までつなげる仕組みとして設計する
単にメトリクスを可視化するのではなく、アラート、トレース、プロファイル、ログ、エラー集計を活用して"改善につながる観測"を行うことが求められます。SLI はユーザー視点で定義されているか、アラートはノイズになっていないか、など**「見るべき情報をどう絞るか」**が試験でも問われます。
デプロイは段階的、かつ即座に戻せる設計にする
Blue-Green, Canary デプロイを使って影響範囲を限定し、即座にロールバック可能な構成を選ぶのが基本方針です。Cloud Deploy や GKE, Cloud Run のリビジョン管理、トラフィック分割機能を活用する設問が出題され、「変更の安全性」をどう担保するかが問われます。
トイルは検知し、コードで排除する
"人手でやっている繰り返し作業"はトイルです。Cloud Scheduler による自動実行, Cloud Functions による通知処理, Terraform や Deployment Manager による構成管理など、トイルに該当する運用タスクは自動化すべきです。試験では「週に 1 回手動で対応している」といった記述から、どの手段で自動化できるかを選ばせる問題が出題されます。
インシデントは"人ではなく組織"で対応する文化を理解する
インシデント時は、役割分担（IC / OL / CL）と組織対応の原則に基づいた構成が問われます。Postmortem は「責任追及ではなく学びを残す」文化がベースであり、記録の共有まで含めた設計が求められます。試験では「誰が何をすべきか」「どんな手順で振り返るか」が問われるため、SRE 本の対応原則を言語化できるかどうかが鍵になります。
Professional Cloud Security Engineer（PCSE）
Google Cloud でのセキュアなインフラの設計、構築、保護する能力を証明する資格です。
サービス間認証、ネットワークセキュリティ、組織や IAM の管理、データ暗号化等、業務上様々なロールのあらゆるセキュリティ関連の話題を網羅的に扱います。
問題の傾向として、とにかく似たような回答が羅列されているため、何が課題で何を解決するプラクティスを講じるのかを適切に判断する必要があり、セキュリティプロダクトの深い理解が求められます。
普段からソリューションに触れていないとイメージすら持ちずらいものも登場するため、比較的難易度は高め で、Google Cloud のセキュリティに関する専門的な知識が要されます。
通常、Professional 認定試験は 50 問ですが、PCSE のみ 40 問と少なめです。
各セクションで一定割合 Pass しなければならないことを考えると 1 問あたりの重みが大きくなります。
問われる内容
最小権限・多層防御・監査可能性・鍵とデータのガバナンスを Google Cloud 上で実現するためのプラクティスが出題されます。
- ID 管理とアクセス管理
- IAM（ロール設計 / 条件付き IAM）, 組織ポリシ, Context-Aware Access, IAP, SSO, OIDC, Workforce Identity
- データ保護と鍵管理
- Cloud KMS, Cloud HSM, Cloud EKM, エンベロープ暗号（DEK / KEK）, Key Access Justifications（KAJ）
- ネットワーク境界の強化
- VPC Service Controls（Service Perimeter / Access Context Manager / Location Policy）, Private Google Access, Private Service Access
- ワークロード保護
- Cloud Armor, Cloud IDS, Binary Authorization, GKE（Workload Identity / Network Policy）
- 監査と可視化
- Cloud Audit Logs（Admin / Data Access / System / Policy Denied）, Security Command Center（SCC）, CSPM
- コンプライアンス / データ分類
- Cloud DLP, レイテンション, キー・データの位置制御, PII 保護
- 運用と自動化
- 階層型アクセス制御, 最小権限の原則（PoLP）, インシデント対応とエスカレーションプラクティス, ロギング, アラーティング
求められる知識
要件 → 制御へのマッピング → 運用可能性の担保を一貫して理解している必要があります。
暗号化で守るのか、アクセスで絞るのか、境界で塞ぐのか、監査で補強するのか、目的に対してどのようなプラクティスが最適解かを選べる力が求められる。
- ゼロトラストの分解思考
- ユーザ属性・端末状態・ネットワーク位置・アプリケーション・データ分類を条件として組み合わせて必要最小のアクセスを許可する
- 鍵とデータのライフサイクル
- 生成 → 使用 → ローテーション → 失効 → 破棄を運用可能性と可監査性込みで設計
- CMEK を基準に、要件次第で HSM / EKM
- 境界の多層化
- アイデンティティ境界（IAM / Context）、サービス境界（VPC Service Controls）、ネットワーク境界（Private Access）、アプリ境界（IAP / Cloud Armor）を重ねて漏洩経路を塞ぐ
- 監査可能性と是正のループ
- Audit Logs と SCC を中核に、検知 → 調査 → 是正を自動化
- 通知・チケット化・ポリシ補強
- 最小の解を選ぶ姿勢
- 要件が「暗号化」なのか「アクセス抑制」なのかを見極め、過剰設計を避けつつ実効性の高い最短構成を提案する
抑えておくべきポイント
「何を守るか」を分類して制御面に割り振る
データ、アイデンティティ、ワークロード、経路といった守る対象を切り分け、データなら暗号化と境界、アクセスなら IAM、経路なら Private Access や VPC Service Control、ワークロードなら Binary Authorization や Cloud Armor といったように、要件から必要なプラクティスを選定する。
鍵管理は CMEK を基準に要件次第で HSM / EKM を利用
とにかくたくさんの鍵管理オプションが出てくる。
デフォルトは GMEK、制御要件があれば CMEK というのが基準になる。
FIPS やハードウェア境界が必要なら Cloud HSM、鍵をクラウド外に置きたい（内部者リスクを含めて遮断したい）なら Cloud EKM + KAJ 等、より強い制御が必要になる。
エンベロープ暗号では DEK を KEK（CMEK / EKM）で保護し、KEK の可用・不可用がデータ可用性に直結する点まで理解しておく。
適切な Audit Logs の収集
Audit Logs による監査は次に分類されるので、どのような事象に対して何のログを調査すべきかを理解しておく。
| ログタイプ | 説明 | デフォルト有効 |
|---|---|---|
| Admin Activity Log | リソースの構成変更や、設定の変更等を行う API コールのログを記録 | 有効 |
| Data Access Log | リソースの読み取りや変更等、ユーザデータへのアクセスを記録 | 無効（明示的な設定が必要） |
| System Event Log | Google または Google Cloud インフラにより生成されたシステム関連イベントを記録 | 有効 |
| Policy Denied Log | ポリシ（IAM、組織ポリシ等）により拒否されたリクエストを記録 | 有効 |
これらを SCC に集約して脆弱性・脅威検出（ETD / KTD / VTD）と合わせて、検知 → 是正の運用設計に関する内容も問われる。
最小権限の原則
IAM ロールの付与は必ず最小権限の原則（PoLP）に基づいて行います。
基本ロールではなく、事前定義ロールやカスタムロールを中心に、条件付き IAM（IP アドレス、時間、リソース属性）ロールの使用をまず検討します。
階層型アクセス制御
Google Cloud では 階層型アクセス制御 によって、組織、フォルダ、プロジェクト、リソースの各レベルで IAM ポリシを設定できます。
許可ポリシが子リソースに対してどのように継承・伝搬されるのかを理解した上で、適切なレベルで IAM ポリシを設定します。
親レベルで一括制御すると管理負担は軽減されますが、特定の要件では柔軟性に欠けます。
子リソースで個別に設定すると柔軟性は増しますが、統一化されたポリシ運用が難しくなります。
Professional Cloud Network Engineer（PCNE）
Google Cloud のネットワークアーキテクチャの設計、実装、管理を行う能力を証明する資格です。
TCP/IP やネットワークの基本的な知識が必須で、インフラ・セキュリティ・VPC 構成にある程度精通している人向けの試験です。
試験自体が他の Professional 認定資格と比較して 難しい部類 に入ります。
覚えることも多いため、特にネットワークが得意でない場合は、他の試験の 1.5 ~ 2 倍程度の学習時間を見積もる必要があると思います。
ネットワークの構築（特に BGP や VPN といった広域ネットワークを経由する経路制御）について基本的な理解がある人は、Google Cloud 特有のプラクティスについて追加でキャッチアップしておけば十分対応できるでしょう。
問われる内容
Google Cloud 上でのネットワーク設計・構築・運用全般がテーマとなっており、特に以下のような領域が試験範囲として頻出です。
- VPC 設計とハブアンドスポーク構成
- 組織内プロジェクト間の通信構成における中心的な考え方
- オンプレミス接続構成
- Cloud Interconnect, Cloud VPN, Cloud Router, VPC Peering, Cloud DNS, Cloud NAT
- BGP Router, BGP Peering, DNS Resolver, DNS Forwarder, Netfilter
- Private アクセス構成の使い分け
- Private Google Access, Private Service Connect, Private Service Access
- ネットワークレベルのセキュリティ構成
- Firewall, Firewall Logs, VPC Service Controls, VPC Flow Logs, IAM
- ルーティング制御・経路構築
- Static Routing, Dynamic Routing, Policy-based Routing, Route-based Routing
- ロードバランサの構成選定と使い分け
- L4 / L7, Global / Regional, Internal / External
- 階層型制御に基づくリソース管理
- 組織レベル制御, フォルダレベル制御, プロジェクトレベル制御, ネットワークスコープ（サブネット単位）制御
単に「構成を知っているか」ではなく、「状況に応じた構成の選定ができるか」が問われます。
求められる知識
インフラ構成の選定やセキュリティ境界の設計といった観点から、Google Cloud におけるネットワーキングの設計原則を理解し、適切に応用できることが求められます。
特に以下のような知識が試験対策として重要になります。
- Cloud Router, BGP, MED, Route Priority の仕組みと制御方法
- トラフィックの流れ（入口・出口）に応じたルーティングの最適化
- VPC 間接続または VPC とオンプレミス DC 間接続における制約やスケーラビリティの理解
- IP アドレス設計や RFC1918 の理解
- ログベースのトラブルシューティング
- 各種ロードバランサの動作と用途の判断
抑えておくべきポイント
ハブアンドスポーク構成 👈 基本的に全部コレ
Google Cloud のネットワーク構成では、ハブアンドスポーク型アーキテクチャ というのが設計の礎となる考え方。
ネットワークリソースやセキュリティ制御を中央集権で管理しつつ、複数のプロジェクト（スポーク）を紐付ける形で構成する。
Shared VPC を使ったホスト・サービスプロジェクトの分離設計は頻出で、どの構成が適切かを問う内容が出題される。
トラフィックの方向ごとのルーティング制御の理解
例えば、トラフィックが VPC からオンプレミス DC に向かう場合（出口）と、オンプレミス DC から VPC に向かう場合（入口）で、制御方法が異なる。
Cloud Router の Route Priority や Google 側がアドバタイズする MED 値の設定方法を理解しておく。
設問では「どの方向に向かうトラフィックか」を読み取ったうえで適切な制御手段を選ぶ必要がある。
マネージドサービスへのプライベートアクセスパターンの区別
Private Google Access、Private Service Connect、Private Service Access は似ていますが、これらは用途や対象サービスが異なるので混同しなようにする。
例えば、Private Google Access は VM から Cloud Storage や BigQuery のような Public API にアクセスする用途、Private Service Connect は Internal LB を経由したプライベート通信等、試験では違いを問われるため明確に区別しておく。
IP アドレスレンジや ASN の理解
ここは知っているか否かの領域です。
特定の機能やサービスで使われる IP レンジや ASN（Autonomous System Number）を把握しておく。
特に覚えておくと良いもの。
-
199.36.153.4/30（restricted.googleapis.com）：特定の Google API にアクセスする際に使用される IP アドレスレンジ -
199.36.153.8/30（private.googleapis.com）：限定公開の Google アクセスに使用される IP アドレスレンジ -
35.199.192.0/19： Cloud DNS がフォワーディング（Private Forwarding Zone）のために使用する IP アドレスレンジ -
ASN 15169：Google のパブリック で、主に Google のサービスに直接接続するために使用される -
ASN 16550：Partner Interconnect を使用する場合
ロードバランサの種類と選定基準の把握
Google Cloud のロードバランサは多岐にわたります。
プロトコル（L4 / L7）、スコープ（Global / Regional）、用途（Internal / Global）によって使い分けが求められます。
設問ではクライアントからのコネクションをどの段階で終端するのか、どのレイヤでの負荷分散が必要なのかを見極める問題が多いです。
どのタイプの LB がどのユースケースに適しているかを判断する必要があります。
Professional Machine Learning Engineer（PMLE）
Google Cloud での機械学習モデルの設計、構築、運用、保守といった MLOps を含む一連の流れに関するスキルを証明する資格です。
前提として機械学習の基礎知識（モデルの構築・トレーニング・最適化）が必要となりますが、モデルをプロダクトに乗せる上での実装・評価・デプロイ・運用・チューニングセキュリティまで含めた内容が盛り込まれています。
機械学習の実務経験がある方であれば基礎部分の理解はしやすいですが、Vertex AI や MLOps、Leakage 等、Google Cloud 特有の運用観点もキャッチアップする必要があります。
最近では Gemma や Imagen に関する内容が追加されるなど、試験範囲の幅が広がっている印象です。
他の試験とは違った観点での難しさがあり、高レベルな英語の読解力も必要になります。
Google Cloud 認定資格の中では 最難関 と言われています。
問われる内容
モデル構築に加えて、実運用に耐える MLOps 視点での機械学習の実装スキルが広く問われます。
- 機械学習タスクの分類分類 / 回帰 / 教師あり・なし学習）
- 正則化、評価指標、前処理、特徴量エンジニアリング
- モデル学習・チューニング（XGBoost / TensorFlow / scikit-learn 等）
- Vertex AI 全般（Training, Prediction, Pipelines, Feature Store, Model Monitoring）
- モデル解釈と説明可能性（Explainable AI）
- データ分布変化（Drift / Skew / Leakage）
- AutoML の使いどころと制限
- 再現性（Reproducibility）と Lineage
- データ前処理パイプライン（TFX / Dataflow / Transform）
- Google Cloud の AI ソリューションと API（Vision / Translation / NLP / Speech）
モデルを構築してデプロイするだけではなく、継続的な運用・説明・再トレーニング・監視までエンドツーエンドで理解が求められます。
求められる知識
アルゴリズムの理論だけではなくモデルをプロダクトに乗せる力が問われます。
- 分類 / 回帰タスクの違い、使用する評価指標（Precision / Recall / F1 / RMSE）
- 学習パイプラインの構成（ExampleGen → Transform → Trainer → Evaluator → Pusher）
- モデル監視（Drift・Skew 検出、Vertex AI Model Monitoring の使い方）
- 説明可能性（Shapley, Integrated Gradients, Example-based Explanations）
- 分類・回帰・クラスタリング、表形式データへのモデル適用（AutoML Tabular）
- モデルデプロイ戦略（Traffic Split によるカナリアリリース等）
- データフォーマット（TFRecord, CSV）、ストレージ（BigQuery / GCS）
- 再現性の確保（パイプライン / Metadata / Model Registry / Feature Store）
抑えておくべきポイント
分類と回帰の問題定義と評価指標
評価指標として Precision、Recall、F1、RMSE）は頻出されるイメージ。
誤検知を避けたいのか（Precision 重視）、取り逃しを避けたいのか（Recall 重視）、両者のバランスを見たいのか（F1）、あるいは数値誤差の大きさを評価したいのか（RMSE）。
クラス不均衡なら Accuracy に頼らず、適切な指標を主指標・副指標としてセットで選定。
設問文から分類問題なのか回帰問題なのか、指標選択の妥当性を理解する。
TensorFlow / PyTorch / scikit-learn それぞれの特性と用途を整理
実験初期の表形式データや軽量なベースラインは scikit-learn、研究寄りで迅速な試作や独自モデルは PyTorch、Enterprise のパイプライン統合や大規模学習・推論、Vertex 連携の容易さは TensorFlow が優位というイメージ。
既存資産、推論形態、デプロイ先といった問題文の背景に合わせ、なぜその選択なのかを理解する。
Vertex AI の主要コンポーネント理解
Training（学習）→ Pipelines（再現可能な実行）→ Model Registry（バージョン管理）→ Prediction / Endpoints（提供）→ Model Monitoring（監視）→ Explainable AI（説明）の流れで、設計と運用が循環するイメージを持つ。
個々の機能名を暗記するより、「どのフェーズで何を担保しているか」を因果で理解する。
モデルの劣化要因を探索する方法
Drift / Skew / Leakage は運用時にモデル劣化の要因となる。
Drift は時間経過での分布変化、Skew は学習・本番の分布差、Leakage は本来使えない情報の混入。
検知は監視（分布比較・重要度変化）、緩和はデータガバナンス（特徴量管理・スキーマ検証）、再学習戦略（スケジュール or 閾値値発火）で戦略を立てる。
設問から「どこで起き、どう気づき、どう直すか」を理解する。
AutoML とカスタム学習のトレードオフ
AutoML は手軽さ優先、カスタムトレーニングは制御性優先で使い分ける。
迅速な PoC や標準タスクは AutoML、特殊前処理・独自損失・大規模分散や厳密な最適化が要るならカスタム（TensorFlow / Torch）といったイメージ。
短期価値か長期拡張性かを判断材料にすると良い。
MLOps 技術（TFX / Dataflow / RunInference）はエンタープライズ実装を意識
前処理・学習・評価・提供をコード化し直列化するのが TFX、スケーラブル処理は Dataflow、推論のデータパス近接化は RunInference。
MLOps では人の介入を極力避けて運用を自動化することを主な目的なので、人手を介さずに品質と速度を両立する方法、運用のボトルネックをどの技術で解消するかを考える。
Vertex AI コンソールに触れておく
PMLE で一番登場するマネージドサービスは Vertex AI Platform。
Vertex AI と一言で言っても機能が多岐に渡るため、小さなデータで良いので学習 → デプロイ → 監視 → 説明まで回して何のサービスで何が実現できるのかを実際にコンソールに触れて理解しておく。
特に、Pipelines、AutoML、Explainable AI あたりを動かして理解を深めておくのがおすすめ。