対象読者
- Google Cloud Professional Cloud Architect（PCA）の取得を目指している方
- Google Cloudのサービスはある程度知っているものの、PCAの問題になると迷ってしまう方
- 「結局、PCAって何を勉強すればいいの？」となっている方
- Google Cloudのアーキテクチャ設計を体系的に整理したい方
TL;DR
- PCAは、Google Cloudサービスの暗記試験というより「要件に対して適切な設計を選べるか」の試験。
- 問題を解くときは、まず 目的 → 制約 → 非機能要件 → サービス候補 → Well-Architected の順番で考えると整理しやすい。
- Compute Engine / GKE / Cloud Run、Cloud SQL / Spanner / Bigtable / BigQueryなど、似たサービス同士の使い分けは特に重要。
- ケーススタディは事前公開されているので、試験直前ではなく、早めに「要求・制約・ありそうな設計」を整理しておく。
- 最後は問題演習。ただし「正解を覚える」のではなく、なぜ他の選択肢が不正解なのかまで説明できる状態を目指す。
はじめに
2025年、Google Cloud Japanから新しく
Google Cloud Partner All Certification Holders
というプログラムが発表されました。(2026年は未実施ですが...)
これは、Google Cloudのパートナー企業に所属するエンジニアのうち、対象となるGoogle Cloud認定資格をすべて保持している人を公式に発表するプログラムです。
2025年版では、2025年6月1日時点で一般公開されていた以下の13資格が対象でした。
- Cloud Digital Leader
- Generative AI Leader
- Associate Cloud Engineer
- Associate Data Practitioner
- Associate Google Workspace Administrator
- Professional Cloud Architect
- Professional Cloud Developer
- Professional Data Engineer
- Professional Cloud Security Engineer
- Professional Cloud Network Engineer
- Professional Cloud DevOps Engineer
- Professional Cloud Database Engineer
- Professional Machine Learning Engineer
Google Cloud公式ブログによると、2025年8月から募集が開始され、11月に受賞者が発表されています。
その中でも、個人的に
「Google Cloudを広く理解する」
という意味で、かなり重要だと思っている資格が Professional Cloud Architect（PCA） です。
PCAを勉強すると、
「Cloud Runって何？」
だけではなく、
「この要件ならCloud RunとGKEのどちらを選ぶ？」
「Cloud SQLではなくSpannerにする理由は？」
「可用性を上げたいけれど、そこまでの構成が本当に必要？」
といった、アーキテクトとしての判断そのものを考えることになります。
ということで今回は、PCAをこれから取得する方向けに、
何を覚えるのかではなく、どう考えればよいのか
という観点を中心に整理してみます。
1. まずPCAはどんな試験なのか
現在のProfessional Cloud Architect標準試験は、以下の形式です。
| 項目 | 内容 |
|---|---|
| 試験時間 | 2時間 |
| 問題数 | 50〜60問 |
| 形式 | 選択式・複数選択式 |
| 言語 | 日本語 / 英語 |
| 有効期間 | 2年間 |
| 前提資格 | なし |
| 推奨経験 | IT業界3年以上、うちGoogle Cloudでの設計・管理経験1年以上 |
| ケーススタディ | 2件 |
| ケース問題の割合 | 全体の20〜30% |
Google Cloud公式でも、PCAは
- クラウドソリューションの設計・計画
- インフラストラクチャの管理・プロビジョニング
- セキュリティとコンプライアンス
- 技術・ビジネスプロセスの分析と最適化
- アーキテクチャ実装の管理
- ソリューションと運用の信頼性
などを評価する試験として定義されています。
ここで大事なのは、
「Google Cloudのサービスを知っていますか？」だけを聞いている試験ではない
というところです。
2. PCAで一番大事なのは「要件を読む」こと
例えば、次のような問題があったとします。
Webアプリケーションを新しく構築します。
アクセス量は大きく変動します。
Kubernetesの運用経験者はいません。
運用負荷を可能な限り下げたいです。
候補が、
- Compute Engine
- GKE
- Cloud Run
だった場合、
「GKEは高機能だからGKE！」
とはなりません。
要件を見ると、
- アクセス量が変動する
- Kubernetesの経験者がいない
- 運用負荷を下げたい
という制約があります。
そのため、特別な要件がなければ、
Cloud Runのようなマネージド性の高いサービス
が有力になります。
逆に、
特殊なDaemonSetを動かしたい
Kubernetes APIを直接利用する必要がある
といった要件が追加されれば、GKEが候補になります。
つまりPCAでは、
サービス
↓
要件に当てはめる
ではなく、
要件
↓
制約
↓
必要な特性
↓
サービス
の順番で考えることが重要です。
3. 個人的に使いやすい「設計判断の9原則」
問題を解く際、私は次のような観点で選択肢を見ます。
① マネージドサービスを優先する
Google Cloudが管理してくれる範囲が広いほど、
- OS管理
- パッチ
- スケール
- 障害対応
- バックアップ
などの運用負荷を減らせます。
もちろん、
とにかくCloud Runを選べばOK
という意味ではありません。
要件を満たせるなら、より運用負荷の少ないものを選ぶ
くらいに考えるのがちょうど良いと思います。
② 「誰が運用するの？」を考える
PCAの問題では、
- Kubernetes経験者がいない
- DBAが少ない
- 運用チームを増員できない
といった組織的な条件も、立派なアーキテクチャ要件です。
技術的に構築可能かだけではなく、
その構成を誰が3年後まで面倒を見るのか
くらいまで考えると選択肢を削りやすくなります。
③ 最小権限を基本にする
IAM関連ではかなり重要です。
基本は、
必要な人に
必要なリソースだけ
必要な権限だけ
です。
例えばSecret Managerなら、
プロジェクト全体に広く secretAccessor
ではなく、
必要なSecretにだけアクセス権を付ける
方が適切です。
権限管理と合わせて、
- 職務分離
- Organization Policy
- VPC Service Controls
- 監査ログ
なども押さえておきたいところです。
④ 単一障害点をなくす。ただし過剰設計しない
これは結構重要です。
PCAでは高可用性が大事ですが、
とにかくマルチリージョン！
にすると、今度はコストや複雑性が上がります。
例えば、
RTO = 数分
RPO = ほぼゼロ
と
RTO = 24時間
RPO = 12時間
では、必要なDR構成は全く異なります。
要求された可用性を満たす最小構成
を考えるのがポイントです。
⑤ RTO・RPOからDRを決める
DR問題では、
- RTO：どのくらいで復旧したいのか
- RPO：どのくらいのデータ損失まで許容できるのか
を最初に見ます。
例えば、
RTO 数分
RPO 数秒
なら常時同期に近い構成が必要になります。
一方、
RTO 1日
RPO 1日
なら、バックアップから復元する構成でも要件を満たせる可能性があります。
⑥ 需要変動には自動スケーリングを考える
アクセスが読めない、
イベント時だけ急増する、
という要件が出たら、
スケールアウトできるサービス
が候補になります。
Cloud RunやGKE、Managed Instance Groupなど、
どのレイヤーまで管理したいかと合わせて判断します。
⑦ 既存資産を無視しない
クラウド試験なので、
全部クラウドネイティブに作り直せばよい
と思いがちですが、PCAではそうとも限りません。
例えば、
- 移行期限が3か月
- 数百台のVMが存在する
- アプリケーション改修の時間がない
のであれば、
まずRehostやReplatformを実施し、
その後段階的にRefactorする方が合理的なケースもあります。
⑧ 「最高の技術」より「要件に最適な技術」
これが一番PCAらしいところかもしれません。
Spannerは非常に強力ですが、
単一リージョンの小規模な業務システムに、
必ずしもSpannerが必要なわけではありません。
逆に、
- 世界中から書き込み
- 強整合性
- 水平スケール
が必要なら、Spannerが非常に有力になります。
⑨ 問題文にない要件を勝手に追加しない
例えば、
「将来的に世界展開するかもしれない」
と問題文に書かれていないのに、
勝手に世界展開を想定してSpannerを選ぶ、
みたいなことは避けます。
試験問題では、
書いてある要件を満たすこと
が最優先です。
4. まず押さえたいGoogle Cloudサービスの全体像
150以上あるサービスを全部同じ粒度で覚えるのはなかなか大変です。
そこで私は、大きく次のような領域に分けて整理するのがおすすめです。
Google Cloud
├─ Organization / IAM / Security
├─ Networking
├─ Compute
├─ Database / Storage
├─ Data Analytics
├─ AI / ML
├─ Development / CI/CD
└─ Operations / Monitoring
特にPCAでは、
似ているサービスの違い
を説明できることが重要です。
5. Compute：Compute Engine, GKE, Cloud Run
まず頻出なのがComputeです。
ざっくり整理すると、
| サービス | 特徴 |
|---|---|
| Compute Engine | VMを自由に管理 |
| GKE | Kubernetesによるコンテナ管理 |
| Cloud Run | サーバーレスコンテナ |
考える軸は、
制御性 ←────────────→ 運用負荷の低さ
Compute Engine GKE Cloud Run
です。
Compute Engine
向いているケース：
- OSレベルの制御が必要
- 既存VMをそのまま移行したい
- 特殊なミドルウェアが必要
GKE
向いているケース：
- Kubernetes前提
- 複雑なコンテナ構成
- Kubernetes APIやエコシステムを活用したい
Cloud Run
向いているケース：
- HTTP/APIアプリケーション
- ステートレス
- 自動スケールしたい
- Kubernetesの管理をしたくない
6. Database：RDB, NoSQL...etc
PCAで迷いやすいところです。
ざっくり整理すると、
| サービス | 主な用途 |
|---|---|
| Cloud SQL | 一般的なRDB |
| AlloyDB | 高性能PostgreSQL互換 |
| Spanner | グローバル・水平スケールRDB |
| Firestore | ドキュメント型NoSQL |
| Bigtable | 大規模・低レイテンシKey-Value |
| BigQuery | 分析 |
特に、
Cloud SQL
vs
Spanner
vs
Bigtable
vs
BigQuery
を切り分けられるとかなり楽になります。
Cloud SQL
例えば、
- MySQL/PostgreSQL互換
- 一般的な業務システム
- SQLを利用
- 世界規模の水平スケールまでは不要
であれば有力です。
Spanner
例えば、
- グローバル展開
- 大量トランザクション
- 水平スケール
- 強整合性
が必要なら候補です。
Bigtable
例えば、
- IoT
- 時系列データ
- 超大量データ
- Key-Valueアクセス
- 低レイテンシ
など。
BigQuery
こちらはOLTP用DBではなく、基本的には
分析用データウェアハウス
です。
「大量のログを分析したい」
「集計クエリを実行したい」
という文脈ではかなり有力です。
7. Pub/Subは「疎結合」が見えたら思い出す
Pub/SubもPCAでは非常によく登場します。
例えば、
大量のデバイス
↓
イベント発生
↓
Pub/Sub
↓
Dataflow
↓
BigQuery
という構成です。
Pub/Subのポイントは、
ProducerとConsumerを直接つながなくてよい
ことです。
そのため、
- 一時的な接続断
- 突発的なアクセス
- システム間連携
- 非同期処理
などに強くなります。
8. ネットワークは「接続」と「境界」を分けて考える
ネットワーク系は、まず用途別に整理すると分かりやすいです。
オンプレと接続
Cloud VPN
Cloud Interconnect
複数プロジェクトのネットワークを統合管理
Shared VPC
Google APIへのプライベートアクセス
Private Google Access
Private Service Connect
DDoS / WAF
Cloud Armor
Google Cloudサービスからのデータ持ち出し対策
VPC Service Controls
同じ「セキュリティ」でも、目的がかなり違います。
9. Well-Architected Frameworkを最後のチェックに使う
現在のGoogle Cloud Well-Architected Frameworkには、6つの柱があります。
- Operational excellence
- Security, privacy, and compliance
- Reliability
- Cost optimization
- Performance optimization
- Sustainability
Google CloudのPCA公式ページでも、Well-Architected Frameworkの理解はProfessional Cloud Architectにとって重要であり、これらの柱が試験目標全体に組み込まれているとされています。
また2026年1月には、Sustainabilityが本格的な柱として拡充されています。
問題を解いたあと、
この構成は…
運用できる？
安全？
壊れても大丈夫？
高すぎない？
性能は足りる？
無駄なリソースを使っていない？
と確認すると、かなりPCAっぽい考え方になります。
10. PCAの問題はこの5ステップで考える
ここまでをまとめると、個人的にはこの順番が一番整理しやすいです。
Step 1：何を実現したいのか
まず技術を見る前に、
ビジネス上の目的
を確認します。
例えば、
世界中のユーザーに低遅延で提供したい
なのか、
運用コストを下げたい
なのか。
ここが違えば答えも変わります。
Step 2：制約を拾う
例えば、
- 移行期限
- 予算
- 既存スキル
- オンプレ資産
- 法規制
- データ所在地
など。
PCAでは、むしろこの制約が正解を決めることがあります。
Step 3：非機能要件を見る
代表的なのは、
可用性
RTO
RPO
性能
セキュリティ
コスト
運用性
スケーラビリティ
です。
Step 4：サービス候補を絞る
ここで初めてサービスを選びます。
例えば、
RDBが必要
↓
グローバル強整合性が必要
↓
水平スケールが必要
↓
Spanner
という感じです。
Step 5：Well-Architectedで確認
最後に、
もっと単純にできないか？
を考えます。
PCA問題では、
必要以上に複雑な構成
が不正解選択肢として出てくることも多いです。
11. ケーススタディは絶対に事前に読む
PCA標準試験では現在、以下の4つのケーススタディが公開されています。
- EHR Healthcare
- Helicopter Racing League
- Mountkirk Games
- TerramEarth
実際の試験では、このうち2つのケースが出題され、ケーススタディ関連問題は全体の20〜30%を占めます。
そのため、
試験中に初めて全部読む
のは少しもったいないです。
私は事前に、ケースごとに1枚程度で、
Business requirements
Technical requirements
Existing environment
Constraints
考えられるGoogle Cloud構成
を整理しておくことをおすすめします。
例えば、
Mountkirk Games
├─ 世界中のゲームユーザー
├─ 低レイテンシ
├─ GKE
├─ Spanner
└─ グローバルなスケーリング
くらいの粒度で構いません。
重要なのは文章を暗記することではなく、
この会社の設計上のクセを理解しておくこと
です。
12. 問題演習では「不正解の理由」を考える
最終的には、やはり問題演習が重要です。
ただし、
Aが正解だった
↓
Aを覚える
だけだと、本番で少し条件を変えられたときに対応できません。
おすすめは、
なぜAなのか
なぜBではないのか
なぜCではないのか
条件がどう変わったらBになるのか
まで考えることです。
例えば、
Kubernetes経験者がいないのでCloud Run
という問題なら、
では、Kubernetes APIが必要という条件が追加されたら？
と考えます。
すると、
Cloud Run
↓
GKE
に答えが変わる可能性があります。
この「条件を1個変えて考える」のはかなりおすすめです。
13. 人と問題を議論するのも意外と効く
PCAは、
Aも動くしBも動くけど、どちらがより適切か
という問題が多いので、一人で正解だけ確認していると判断基準が曖昧になりがちです。
そんなときは、
「自分は運用負荷を理由にAだと思う」
「でも、この要件ならRPOを優先してBでは？」
くらいの軽いブレインストーミングをすると、設計判断の理由がかなり整理されます。
勉強会のように大掛かりにしなくても、
迷った問題を2〜3問だけ誰かと話す
くらいでも十分効果があります。
14. 個人的なPCA学習ロードマップ
これから始めるなら、次の順番をおすすめします。
① 公式試験ガイド
まず、
そもそも何が出るのか
を確認します。
PCAの試験範囲はかなり広いため、公式ガイドをチェックリストにするのがおすすめです。
② Google Cloudサービスを分類する
全部を個別に暗記するのではなく、
Compute
Database
Storage
Network
Security
Data
AI
Operations
くらいに整理します。
③ 類似サービスを比較する
特に、
Compute Engine / GKE / Cloud Run
Cloud SQL / AlloyDB / Spanner
Firestore / Bigtable
Cloud Storage / Persistent Disk / Filestore
Pub/Sub / Cloud Tasks
VPN / Interconnect
など。
④ ケーススタディ
4ケースを1枚ずつ整理。
⑤ 問題演習
ここからひたすら、
要件 → 判断 → サービス
の型を身につけます。
⑥ 間違えたところだけ公式Docs
全部のDocumentationを最初から読む必要はないと思います。
間違えたところを、
問題
↓
理解不足発見
↓
公式Docs
↓
再度問題
で埋める方が効率的です。
15. 最低限これだけ覚えておくチートシート
最後に超ざっくりまとめます。
| 要件 | まず思い出すもの |
|---|---|
| VMを自由に管理 | Compute Engine |
| Kubernetes | GKE |
| サーバーレスコンテナ | Cloud Run |
| 一般的なRDB | Cloud SQL / AlloyDB |
| グローバル強整合性RDB | Spanner |
| 大規模Key-Value | Bigtable |
| 分析 | BigQuery |
| オブジェクト保存 | Cloud Storage |
| イベント疎結合 | Pub/Sub |
| ストリーム処理 | Dataflow |
| AI/ML | Vertex AI |
| Secret管理 | Secret Manager |
| DDoS/WAF | Cloud Armor |
| サービス境界 | VPC Service Controls |
| オンプレ接続 | VPN / Interconnect |
| 集中VPC管理 | Shared VPC |
| 権限 | IAM |
| 組織ガードレール | Organization Policy |
| 監視 | Cloud Monitoring |
| ログ | Cloud Logging |
ただし、
この表だけ覚えて試験に行くのはおすすめしません。
重要なのは、
なぜそれを選ぶのか
を説明できることです。
まとめ
Professional Cloud Architectという名前から、
Google Cloudのサービスをたくさん覚える資格
という印象を持つかもしれません。
実際には、サービス知識以上に、
要件を読み、トレードオフを考え、適切な設計を選択する力
を問われる試験だと思います。
個人的には、PCA問題を見るときは常に、
1. 何を実現したい？
2. 制約は？
3. 非機能要件は？
4. 一番シンプルに満たせるサービスは？
5. 運用・セキュリティ・信頼性・コスト的に問題ない？
の順番で考えています。
Google Cloudのサービスは今後も増えますし、既存サービスも変わっていきます。
それでも、
要件を整理して、最適なアーキテクチャを選ぶ
という考え方自体は変わりません。
PCAの勉強を、
単なる資格対策ではなく、
Google Cloudで設計するときの「判断の型」を身につける機会
として使うと、かなり面白い資格だと思います。
参考
-
Google Cloud Partner All Certification Holders 2025
Google Cloud公式ブログ：Partner All Certification Holders 2025 応募開始 -
Professional Cloud Architect
Google Cloud Professional Cloud Architect 認定ページ -
Professional Cloud Architect Exam Guide
Professional Cloud Architect 認定試験ガイド -
Google Cloud Well-Architected Framework
Google Cloud Well-Architected Framework