はじめに
私は現在、Google Cloud のプロフェッショナル認定資格である Professional Cloud Architect (PCA) の取得を目指しています。
実は1ヶ月後に試験本番を控えているのですが、「そろそろ本気で準備しないとまずい」と思い、試しに公式の模擬試験を受けてみました。
その結果は、なんと 9/19点。得点率は半分にも届かず、かなり焦っています。なんとかしなければ....
しかし、焦って闇雲に手を広げるよりも、まずは「試験日までに何をやるべきか」を整理することが最優先です。この記事では、現在の自分の課題を言語化し、残り1か月で PCA 試験に合格するための具体的な学習方針をまとめます。
現在地
まずは、スタート地点における自分の実力を整理します。
- Google Cloud の経験: 個人開発や遊びで主要サービス（Cloud Run や Cloud Storage など）を少し触った程度。実務での設計・運用経験はなし。
- 模擬試験のスコア: 9/19点（約 47%）。
- 試験対策の進捗: 体系的なインプット・アウトプットはほぼ手付かず。これから本腰を入れる状態。
この記事でやること
残り1か月という限られた時間で合格ラインに到達するため、この記事では以下のステップで合格ロードマップを描きます。
- 公式ガイドの出題範囲を読み解き、PCAで求められる「設計・運用視点」を整理する
- 各セクションごとの重要サービスと、試験で問われそうなポイントを整理する
- 1ヶ月で合格するための学習計画を立てる
「PCAの範囲が広すぎて、何から手をつければいいか分からない」という方の参考になれば幸いです。
公式ガイドから見る求められる能力と出題範囲
まずは、公式ガイドからProfessional Cloud Architect（以下PCA）試験で求められている能力や出題範囲を整理していきます。
求められる能力
公式ガイドには、求められる能力として以下のように書かれています。
Professional Cloud Architect には、Google Cloud テクノロジーを活用して、 ビジネス目標を推進する堅牢、安全、かつスケーラブルで効率、費用対効果、可用性、 柔軟性の高いソリューションを設計、開発、管理する能力があります。 Professional Cloud Architect は、エンタープライズ クラウド戦略、ソリューション設計、 ワークロード移行アプローチ、デプロイとオーケストレーション、最適化、 アーキテクチャのベスト プラクティスに精通しています。 また、レガシー、マルチクラウド、ハイブリッド環境にまたがる多層分散アプリケーションを 設計するための一般的なオープンソース テクノロジーとソフトウェア開発方法論も熟知しています。
この引用文から読み取れるのは、PCA では少なくとも次のようなことが求められている、ということです。
- Google Cloud を使ってソリューションを設計・開発・管理すること
- そのソリューションが、堅牢・安全・スケーラブル・効率的・費用対効果が高い・可用性が高い・柔軟であること
- エンタープライズ クラウド戦略、ソリューション設計、ワークロード移行、デプロイ、オーケストレーション、最適化、ベスト プラクティスに関わること
- レガシー、マルチクラウド、ハイブリッド環境にまたがるアプリケーション設計を含むこと
- オープンソース テクノロジーやソフトウェア開発方法論も対象に含まれること
つまり、少なくともこの章からは「単一のサービス名を知っているか」ではなく、広い前提の中で設計や運用をどう扱うか が問われる試験だとわかります。
出題範囲
公式ガイドのセクション1から各項目を大雑把にみていきます。各項目ごとに出題されそうなサービスをAIに推測させ、表としてまとめています。あくまで推測なので、参考程度に見ていただければと思います。
セクション 1: クラウド ソリューション アーキテクチャの設計と計画（試験内容の約 25%）
1.1 ビジネス要件を満たすクラウド ソリューション インフラストラクチャを設計する
以下のような点を考察します。(公式ガイドより引用)
- ビジネス ユースケースとプロダクト戦略
- 機能要件と非機能要件の特定
- 事業継続計画
- 費用の最適化
- アプリケーション設計の支援
- 外部システムとの統合パターン
- データの移動
- 設計を決定する際のトレードオフ
- ワークロード配置戦略（構築、購入、変更、サポートの終了など）
- 成果の測定方法（重要業績評価指標（KPI）、投資収益率（ROI）、指標など）
- セキュリティとコンプライアンス
- オブザーバビリティ
応用情報など、IPAの試験で問われそうな要件定義や非機能要件といったキーワードが並んでいます。必須知識ではありますが、暗記するというよりは、システム開発における一般的なベストプラクティスとして理解しておけば問題なさそうです。
1.2 技術要件を満たすクラウド ソリューション インフラストラクチャを設計する
以下のような点を考察します。(公式ガイドより引用)
- Google Cloud Well-Architected Framework に関する知識
- 高可用性とフェイルオーバーの設計
- クラウド リソースの柔軟性
- 成長要件を満たすスケーラビリティ
- パフォーマンスとレイテンシ
- Gemini Cloud Assist
- バックアップとリカバリ
このセクションも1.1と同様に、クラウドアーキテクチャの一般的なベストプラクティス（高可用性、スケーラビリティなど）を問う内容が中心です。
ただ、公式ガイドの中に「Gemini Cloud Assist」という比較的新しいキーワードが含まれていたので、概要をメモしておきます。
1.3 ネットワーク、ストレージ、コンピューティング リソースを設計する
以下のような点を考察します。(公式ガイドより引用)
- オンプレミス環境 / マルチクラウド環境とのインテグレーション
- Google Cloud AI / ML ソリューション（Gemini LLM、Agent Builder、Model Garden、Gemini モデル、AI Hypercomputer など）
- クラウドネイティブなネットワーキング（Virtual Private Cloud（VPC）、ピアリング、ファイアウォール、ロードバランサ、ルーティング、コンテナ ネットワーキング、共有 VPC、Private Service Connect など）
- データ処理ソリューションの選択
- 適切なストレージ タイプ（オブジェクト、ファイル、データベースなど）の選択
- プラットフォーム プロダクトへのコンピューティング ニーズのマッピング（Google Kubernetes Engine（GKE）、Cloud Run、Cloud Run functions など）
- コンピューティング リソースの選択（Spot VM、カスタム マシンタイプ、特殊なワークロードなど）
ここからようやく、具体的なリソース名が増えてきます。 ネットワーク、ストレージ、コンピューティングといった基本要素に加えて、AI/ML 関連のサービスも含まれているので、名前と用途をセットで押さえていく必要がありそうです。
また、明示されていない部分も含めると、オンプレ環境との接続や Cloud Storage の種類なども合わせて確認しておきたいところです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| ハイブリッド接続 | Cloud VPN | ★★★ | IPsecを利用した安全なサイト間接続。帯域幅要件（最大3Gbps/トンネル）とHA VPN（可用性99.99%）の構成。 |
| Cloud Interconnect | ★★★ | Dedicated（専用線）およびPartner（プロバイダ経由）の選択。帯域幅が高く低遅延が求められる場合の最適解。 | |
| Cross-Cloud Interconnect | ★★☆ | AWSやAzureなどの他のクラウドプロバイダとの専用・高可用性接続。 | |
| Private Service Connect | ★★★ | VPCからGoogle APIや公開サービスへ、インターネットを経由せずプライベートIPでアクセスする手法。 | |
| Migration Center | ★★☆ | オンプレミスや他クラウドのインフラストラクチャを検出し、移行の評価・計画を行う統合プラットフォーム。 | |
| AI / ML | Gemini Enterprise Agent Platform | ★★★ | 生成AIを含むAI/MLモデルの学習や推論基盤の選定。要件に応じたマネージドサービスの活用。 |
| Gemini Models | ★★★ | テキスト、画像、コードなどを生成・理解するGeminiモデルの活用方法。 | |
| Model Garden | ★★☆ | Googleの基盤モデルやオープンソースのモデルを探索・デプロイする機能。 | |
| Agent Studio | ★★☆ | AIエージェントの構築、テスト、デプロイを行う環境。 | |
| Agent Development Kit (ADK) | ★★☆ | AIエージェント開発用のツールキットの利用。 | |
| Agent Runtime | ★☆☆ | エージェントを実行する基盤。 | |
| AI Hypercomputer | ★☆☆ | 大規模なAIワークロード向けのインフラストラクチャ。 | |
| Gemini Cloud Assist | ★★☆ | インフラ構成、トラブルシューティング、コスト最適化を支援するAIアシスタント。 | |
| ネットワーク | Virtual Private Cloud (VPC) | ★★★ | プロジェクト間のネットワーク分離。ファイアウォールルールやサブネットの基本設計。 |
| Shared VPC | ★★★ | 組織・プロジェクト間でのネットワーク共有。ホストプロジェクトとサービスプロジェクトの概念。 | |
| VPC Network Peering | ★★★ | 異なるVPC間をプライベートIPで接続。推移的ルーティングがサポートされない点に注意。 | |
| Cloud Load Balancing | ★★★ | グローバル/リージョン、L4/L7、内部/外部の使い分け。要件に基づく適切なLBの選定。 | |
| Cloud DNS | ★★★ | ゾーン管理、VPC向けのプライベートDNSやルーティングポリシーの設定。 | |
| Cloud NAT | ★★★ | プライベート環境からのインターネットアクセスを安全に提供する構成。 | |
| Cloud Router | ★★★ | オンプレミスとの動的ルーティング（BGP）の設計。 | |
| Cloud Firewall | ★★★ | ネットワークタグやサービスアカウントベースのアクセス制御。 | |
| Firewall Policies | ★★☆ | 階層型ファイアウォールポリシーによる組織レベルの統制。 | |
| Private Service Connect | ★★★ | VPCからGoogle APIや公開サービスへ、プライベートIPでアクセスする手法（再掲）。 | |
| GKE Networking | ★★☆ | GKEでのVPCネイティブクラスタ、Service、Ingressのルーティング設計。 | |
| ストレージ | Cloud Storage | ★★★ | 標準、Nearline、Coldline、Archiveのストレージクラスと、ライフサイクル管理。 |
| Filestore | ★★☆ | アプリケーションやGKE向けのマネージドNFS（ファイルストレージ）。 | |
| Persistent Disk | ★★★ | Compute Engineのブロックストレージ。可用性（リージョンPD）やバックアップの設計。 | |
| Hyperdisk | ★★☆ | 次世代の高性能ブロックストレージ。パフォーマンス要件での使い分け。 | |
| Local SSD | ★★☆ | 揮発性だが超高速なローカルストレージ。スクラッチデータの処理などでの利用。 | |
| データベース | Cloud SQL | ★★★ | リレーショナルDB。リージョン内の要件に適したマネージドRDBMS。 |
| Cloud Spanner | ★★★ | グローバルな水平スケール・強整合性が求められるリレーショナルDB。 | |
| Firestore | ★★★ | モバイル/ウェブアプリに最適なドキュメント指向のNoSQL。 | |
| Bigtable | ★★☆ | 大量データの高速な読み書き（時系列、IoTなど）に適したワイドカラム型NoSQL。 | |
| Memorystore | ★★☆ | Redis/Memcachedのフルマネージドサービス。レイテンシ低減やキャッシング戦略に利用。 | |
| データ処理 | BigQuery | ★★★ | ペタバイト級のデータウェアハウス。分析要件やストリーミングインサートの活用。 |
| Dataflow | ★★★ | Apache Beamベースのストリーミング/バッチ処理。 | |
| Pub/Sub | ★★★ | 非同期メッセージング。システム間の疎結合化や、ストリーミングの入り口として頻出。 | |
| Dataproc | ★★☆ | Hadoop/Sparkエコシステムの移行や大規模データ処理。 | |
| Cloud Composer | ★★☆ | Apache Airflowベースのワークフロー・オーケストレーション。 | |
| Datastream | ★★☆ | サーバーレスの変更データキャプチャ（CDC）およびレプリケーションサービス。 | |
| コンピューティング | Compute Engine | ★★★ | IaaSとしての仮想マシン。ワークロードに応じたマシンの選定。 |
| Google Kubernetes Engine (GKE) | ★★★ | コンテナオーケストレーション。GKE Autopilotの運用負荷軽減の利点。 | |
| Cloud Run | ★★★ | HTTPリクエスト等に応答するステートレスコンテナの実行環境。ゼロスケールのメリット。 | |
| Cloud Run functions | ★★★ | イベント駆動の単一処理を実行するサーバーレス機能（旧Cloud Functions）。 | |
| Batch | ★★☆ | バッチ処理ジョブのスケジューリングと実行。 | |
| コンピューティング リソース | Spot VM | ★★★ | プリエンプティブルなリソースを利用した、バッチ処理等のコスト削減。 |
| Custom Machine Types | ★★★ | 必要なvCPUとメモリを柔軟に指定し、リソースを最適化する構成。 | |
| GPU VM | ★★☆ | 機械学習や画像処理などで必要なハードウェアアクセラレータ。 | |
| TPU | ★☆☆ | Google独自の機械学習に特化したハードウェアアクセラレータ。 | |
| Sole-tenant Nodes | ★☆☆ | 物理サーバーを専有する構成。コンプライアンスやライセンス要件で利用。 | |
| Confidential VM | ★★☆ | メモリ使用中もデータを暗号化し、高度な機密性を維持するVM構成。 |
1.4 移行計画を作成する
以下のような点を考察します。(公式ガイドより引用)
- 既存システムとソリューションのインテグレーション
- ソリューションをサポートするためのシステムおよびデータの評価と移行（Google Cloud Migration Center など）
- 移行方法論、ワークロード テスト、ネットワーク計画、依存関係計画の使用
- ソフトウェア ライセンスの影響と財務的影響の判断
模擬試験でもいくつか出題されていた領域です。既存環境からGoogle Cloudへ移行する際のアプローチ（いわゆる「6R」などの移行戦略）や、Migration Centerのような専用ツールの使い所を問われるため、しっかりと各フェーズのセオリーを押さえておく必要がありそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| 移行支援 | Migration Center | ★★★ | オンプレミスや他クラウドのインフラストラクチャを検出し、移行の評価・計画を行う統合プラットフォーム。 |
| VM移行 | Migrate to Virtual Machines | ★★★ | オンプレミスや他クラウドのVMをCompute Engineに直接移行。ダウンタイムを最小限に抑える機能。 |
| データベース移行 | Database Migration Service | ★★★ | オンプレ/他クラウドDBをCloud SQLやAlloyDBへ、継続的データレプリケーション（CDC）で移行。 |
| データ転送 | Storage Transfer Service | ★★★ | オンプレミス、AWS S3等からCloud Storageへの大規模なデータ転送の自動化。 |
| BigQuery Data Transfer Service | ★★☆ | SaaS（Google広告など）や他社DWHからBigQueryへの自動データ取り込み。 | |
| ハイブリッド接続 | Cloud VPN | ★★★ | IPsecを利用した安全なサイト間接続。移行時の安全なデータ転送経路として利用。 |
| Cloud Interconnect | ★★★ | Dedicated/Partnerを利用した専用線接続。移行時の大容量かつ安定した転送経路。 | |
| Cross-Cloud Interconnect | ★★☆ | AWSやAzureなどの他のクラウドプロバイダとの専用・高可用性接続。 | |
| Private Service Connect | ★★☆ | VPCからGoogle API等へプライベートIPでアクセスする手法。 |
1.5 将来のソリューションの向上を想定する
以下のような点を考察します。(公式ガイドより引用)
- クラウドおよび技術の向上
- ビジネスニーズの進化
- クラウド ファーストの設計アプローチ
非常に抽象度が高く、1.1や1.2の要件定義と重なる部分も多いセクションです。「クラウドネイティブな設計アプローチ」など、長期的な視点でシステムをどう発展させていくかというアーキテクトとしての総合力が問われていると感じます。
セクション 2: クラウド ソリューション インフラストラクチャの管理とプロビジョニング（試験内容の約 17.5%）
2.1 ネットワーク トポロジを構成する
以下のような点を考察します。(公式ガイドより引用)
- オンプレミス環境への拡張（ハイブリッド ネットワーキング）
- マルチクラウド環境への拡張（Google Cloud 間の通信を含む）
- セキュリティ保護（侵入防止、アクセス制御、ファイアウォールなど）
- VPC の設計とロード バランシング（クラウド、インターネット、クラウドに隣接するサービスへのアクセスなど）
1.3と内容が被る部分もありますが、こちらはより具体的に「ハイブリッド環境」や「マルチクラウド環境」をどう繋ぐかといった実践的なネットワーク設計が問われます。VPCやCloud Interconnectといったリソースを深く理解しておく必要がありそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| VPC | Virtual Private Cloud (VPC) | ★★★ | プロジェクトのネットワーク基盤。サブネット設計とネットワーク分離の構成。 |
| Shared VPC | ★★★ | 組織やプロジェクト間でのネットワークリソースの共有と一元管理。 | |
| VPC Network Peering | ★★★ | 別組織や別プロジェクトのVPCを接続する構成。推移的ルーティングの制限に注意。 | |
| Cloud WAN | ★★☆ | Googleのグローバルネットワークを利用した、サイト間の最適化されたルーティング。 | |
| ハイブリッド接続 | Cloud VPN | ★★★ | インターネット経由でのIPsecを利用した安全なサイト間接続。 |
| Cloud Interconnect | ★★★ | 安定した高帯域幅と低遅延を提供する専用線接続（Dedicated / Partner）。 | |
| Cross-Cloud Interconnect | ★★☆ | 他のクラウド環境（AWS, Azureなど）との直接的な専用接続。 | |
| Network Connectivity Center | ★★☆ | グローバルなネットワーク接続を一元的に管理・監視するプラットフォーム。 | |
| Private Service Connect | ★★★ | Google APIや公開サービスへ、インターネットを経由せずプライベートIPでアクセスする機能。 | |
| セキュリティ | Cloud Firewall | ★★★ | ネットワークタグやサービスアカウントベースのインスタンスレベルのアクセス制御。 |
| Firewall Policies | ★★☆ | 組織やフォルダレベルで一元的に適用される階層型ファイアウォール。 | |
| Cloud Armor | ★★★ | 外部ロードバランサと統合されたWAFおよびDDoS保護機能。 | |
| Identity and Access Management (IAM) | ★★★ | ネットワークリソースに対するアクセス権限の適切な付与（最小権限）。 | |
| ロードバランシング | Cloud Load Balancing | ★★★ | グローバル/リージョン、L4/L7の要件に基づく適切な負荷分散の構成。 |
| Cloud DNS | ★★★ | VPC向けのプライベートDNSや、外部向けの権威DNSの管理。 | |
| Cloud NAT | ★★★ | プライベートVMやGKEノードからインターネットへの安全なアウトバウンド通信。 | |
| Cloud Router | ★★★ | Cloud VPNやInterconnectと連携したBGPによる動的ルーティング。 |
2.2 ストレージシステムを個別に構成する
以下のような点を考察します。(公式ガイドより引用)
- データ ストレージの割り当て
- データ処理とコンピューティングのプロビジョニング
- セキュリティとアクセスの管理
- データ転送とレイテンシを考慮した構成
- データ保持とデータ ライフサイクルの管理
- データ増大の計画
- データ保護（バックアップと復元など）
可用性やコスト、データ転送の要件に合わせて、Cloud StorageやPersistent Diskなどをどう使い分けるのか、ユースケースベースで叩き込む必要がありそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| オブジェクトストレージ | Cloud Storage | ★★★ | データアクセス頻度や可用性に基づくストレージクラス（Standard, Nearline等）の構成。 |
| ファイルストレージ | Filestore | ★★★ | 複数VMやGKEからの同時マウントが可能な共有ファイルシステムの構成。 |
| ブロックストレージ | Persistent Disk | ★★★ | Compute Engine向けの標準的なブロックストレージと可用性（リージョンPD）の設計。 |
| Hyperdisk | ★★☆ | 高性能データベースやミッションクリティカルな要件向けの次世代ブロックストレージ。 | |
| Local SSD | ★★☆ | 揮発性だが超高速なI/Oを提供するローカルアタッチドストレージ。 | |
| バックアップ | Backup and DR Service | ★★★ | VM、データベース等の一元的なバックアップとディザスタリカバリ（DR）戦略。 |
| Persistent Disk Snapshots | ★★★ | ディスクのバックアップ作成と、別ゾーン/リージョンへの復元の仕組み。 | |
| Cloud Storage Bucket Lock | ★★☆ | コンプライアンス対応のためのデータ改ざん防止機能。指定期間の削除・上書き禁止。 | |
| データライフサイクル | Cloud Storage Lifecycle Management | ★★★ | 一定期間経過後の低コストなストレージクラスへの自動移行や自動削除のルール。 |
| データ転送 | Storage Transfer Service | ★★☆ | 大容量データをCloud Storageへオンラインで自動転送・スケジュールする機能。 |
| Transfer Appliance | ★☆☆ | ネットワーク帯域が限られる環境で、物理デバイス経由でオフライン転送する手段。 | |
| セキュリティ | Cloud Key Management Service (Cloud KMS) | ★★★ | ストレージデータの暗号化鍵（CMEK, CSEK）の管理と要件に応じた使い分け。 |
| Identity and Access Management (IAM) | ★★★ | ストレージバケットへのプロジェクト/組織レベルでのアクセス制御。 | |
| Cloud Storage IAM / ACL | ★★☆ | バケットレベルのIAMと、オブジェクトごとの細かなACL制御の使い分け。 |
2.3 コンピューティング システムを構成する
以下のような点を考察します。(公式ガイドより引用)
- コンピューティング リソースのプロビジョニング
- コンピューティングの変動性の構成（スポットと標準の比較）
- コンピューティング リソース（Compute Engine、GKE、サーバーレス ネットワーキング、Google Cloud VMware Engine など）のクラウドネイティブなネットワーク構成
- インフラストラクチャ オーケストレーション、リソース構成、パッチ管理
- コンテナ オーケストレーション
- サーバーレス コンピューティング
Compute Engineの細かなマシンタイプの違いから、GKEのようなコンテナオーケストレーション、Cloud Runといったサーバーレスまで、選択肢が非常に多そうな領域です。「この要件ならどのコンピューティングリソースを選ぶのがベストか（コスト・運用面含む）」を的確に判断できるレベルまで理解を深める必要があるように感じます。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| 仮想マシン | Compute Engine | ★★★ | ワークロードに応じたマシンタイプの選定（汎用、メモリ最適化、コンピューティング最適化など）。 |
| Spot VM | ★★★ | 中断可能なバッチ処理などで利用し、コンピューティングコストを大幅に削減。 | |
| Custom Machine Types | ★★★ | 必要なvCPUとメモリを柔軟に指定し、リソースの無駄を省く構成。 | |
| Instance Templates | ★★★ | VMの構成をテンプレート化し、MIG等での一貫したプロビジョニングに利用。 | |
| Managed Instance Groups (MIG) | ★★★ | オートスケーリングとオートヒーリング（自動復旧）を備えた高可用性設計。 | |
| Sole-tenant Nodes | ★☆☆ | コンプライアンスやライセンス要件で物理サーバーを専有する構成。 | |
| Confidential VM | ★★☆ | メモリ処理中のデータも暗号化し、高度なセキュリティ要件を満たすVM。 | |
| コンテナ | Google Kubernetes Engine (GKE) | ★★★ | コンテナ化されたアプリケーションのオーケストレーションとクラスタの管理。 |
| GKE Autopilot | ★★★ | ノード管理をGoogleに任せ、Podの運用に集中できるフルマネージドな構成。 | |
| GKE Standard | ★★☆ | ノードのOSやハードウェア構成を詳細に制御したい場合に選択する構成。 | |
| サーバーレス | Cloud Run | ★★★ | HTTPリクエスト等に応答するステートレスコンテナの実行環境。ゼロスケールのメリット。 |
| Cloud Run functions | ★★★ | イベント駆動の単一処理を実行するサーバーレス機能（旧Cloud Functions）。 | |
| VMware | Google Cloud VMware Engine | ★★☆ | オンプレミスのVMwareワークロードを、Google Cloud上にリフト＆シフトで移行。 |
| Infrastructure as Code | Infrastructure Manager | ★★☆ | Terraform設定を基にしたインフラストラクチャの自動プロビジョニングと管理。 |
| Terraform | ★★★ | 宣言的なコードによるインフラの構築と変更管理。リソースの再現性と一貫性の担保。 | |
| 構成管理・自動化 | OS Config | ★★☆ | Compute Engineのパッチ適用、OSの構成管理を自動化。 |
| Cloud Build | ★★☆ | CI/CDパイプラインを構築し、ビルドやデプロイを自動化。 |
2.4 エンドツーエンドの ML ワークフローに Gemini Enterprise Agent Platform を活用する
以下のような点を考察します。(公式ガイドより引用)
- Agent Platform Pipelines を使用した ML ライフサイクルの自動化とオーケストレーション
- Agent Platform データ統合の準備
- AI Hypercomputer の使用（ML / AI ワークロードでの AI Hypercomputer、Cloud Run functions、Agent Platform の使用、ML モデルのトレーニングとサービングにおける GPU と TPU の統合、さまざまな使用量モデルの最適化、大規模な AI モデル トレーニングの実施など）
ここ最近のトレンドが色濃く反映された、AI・ML関連のインフラ設計領域です。GPU・TPUやAI Hypercomputerの特徴を理解し、モデルの学習や推論の規模に応じた適切な実行環境・コスト最適化の手法を選定できるようになる必要がありそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| AIプラットフォーム | Gemini Enterprise Agent Platform | ★★★ | エンタープライズ向けのAIモデル開発、デプロイ、管理を行う統合プラットフォーム。 |
| Gemini Models | ★★★ | テキスト、画像、コードなどを生成・理解するマルチモーダルな基盤モデル。 | |
| Model Garden | ★★☆ | Googleの基盤モデルやオープンソースのモデルを探索・デプロイするハブ。 | |
| Agent Studio | ★★☆ | AIエージェントの構築、テスト、デプロイを行う環境。 | |
| Agent Development Kit (ADK) | ★★☆ | エージェント開発用のツールキットの利用。 | |
| MLパイプライン | Agent Platform Pipelines | ★★☆ | 機械学習のワークフロー（データ前処理からトレーニング、デプロイまで）の自動化。 |
| データ準備 | Agent Platform Data Integration | ★★☆ | AIモデル向けのデータ収集、前処理、品質管理の統合。 |
| AIインフラ | AI Hypercomputer | ★★☆ | 大規模なAIワークロード向けの最適化されたインフラストラクチャ。 |
| GPU | ★★☆ | 機械学習や画像処理などで必要な一般的なハードウェアアクセラレータ。 | |
| TPU | ★★☆ | Google独自の機械学習に特化したハードウェアアクセラレータ。 | |
| AI運用 | Gemini Cloud Assist | ★★☆ | インフラ構成、トラブルシューティング、コスト最適化を支援するAI機能。 |
| サーバーレス | Cloud Run functions | ★★☆ | イベント駆動でAIパイプラインをトリガーする際などに利用。 |
2.5 Agent Platform を使用して事前構築済みソリューションまたは API を構成する
以下のような点を考察します。(公式ガイドより引用)
- Google AI API（Search、Conversation、Vision、Image、Video、Audio など）の区別
- Gemini Enterprise の機能（AI エージェントと NotebookLM）の統合によるワークフローの強化
- Model Garden に登録されている AI モデルのソリューションへの統合
VisionやConversationなど、Google Cloudが提供する学習済みの「Google AI API」群をどう組み合わせてビジネス要件を満たすかが問われます。それぞれのAPIが「何に使えるのか」という機能の区別がつきやすいため、比較的点数を取りやすそうな（勉強しやすい）領域だと感じています。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| AIプラットフォーム | Gemini Enterprise Agent Platform | ★★★ | AIエージェントやソリューションを構築・管理する基盤（再掲）。 |
| AI API | Google AI API | ★★★ | 自前でモデルを学習せずに機械学習機能を利用する事前構築済みAPIの総称。 |
| Search API | ★★☆ | 企業データやウェブコンテンツからの高度な検索機能の実装。 | |
| Conversation API | ★★☆ | チャットボットや対話型AIアシスタントの構築。 | |
| Vision API | ★★☆ | 画像内のオブジェクト検出、顔認識、テキスト抽出（OCR）。 | |
| Image API | ★★☆ | 画像の生成、編集などの操作。 | |
| Video API | ★★☆ | 動画コンテンツの分析、シーン検出、オブジェクト追跡。 | |
| Audio API | ★★☆ | Speech-to-Text等の音声認識やテキスト読み上げ（TTS）。 | |
| AIサービス | Gemini Enterprise | ★★☆ | 組織向けのセキュアな生成AIサービス。 |
| NotebookLM Enterprise | ★★☆ | エンタープライズ向けのAI支援ノートブック環境。 | |
| AIモデル | Model Garden | ★★★ | ニーズに合った事前構築済みモデルの選定とデプロイ。 |
| Gemini Models | ★★★ | マルチモーダルな基盤モデルをAPI経由で直接利用。 |
セクション 3: セキュリティとコンプライアンスを考慮した設計（試験内容の約 17.5%）
3.1 セキュリティを考慮して設計する
以下のような点を考察します。(公式ガイドより引用)
- Identity and Access Management（IAM）
- リソース階層（組織、フォルダ、プロジェクト）
- データ セキュリティ（鍵管理、暗号化、シークレット管理）
- 職掌分散
- セキュリティ管理（監査、VPC Service Controls、コンテキストアウェア アクセス、組織のポリシー、階層型ファイアウォール ポリシーなど）
- Cloud Key Management Service（Cloud KMS）を使用した顧客管理の暗号鍵の管理
- 安全なリモート アクセス（Identity-Aware Proxy、サービス アカウントの権限借用、Chrome Enterprise Premium、Workload Identity 連携など）
- ソフトウェア サプライ チェーンの保護
- AI のセキュリティ確保（Model Armor、Sensitive Data Protection、安全なモデルのデプロイなど）
IAMによる権限管理から、VPC Service Controlsを用いた境界防御、データの暗号化（Cloud KMS）まで、セキュリティの多層防御がテーマです。各セキュリティ機能が防げる脅威の範囲をしっかり整理しておく必要がありそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| IAM | Identity and Access Management (IAM) | ★★★ | 最小権限の原則。基本ロールではなく、事前定義ロールやカスタムロールの適切な適用。 |
| IAM Conditions | ★★☆ | 時間や環境（IPアドレスなど）に基づく、属性ベースのアクセス制御。 | |
| Service Accounts | ★★★ | アプリケーションやリソース間の認証。キー管理のリスクを避ける運用。 | |
| Service Account Impersonation | ★★☆ | キーを発行せずに、一時的にサービスアカウントの権限を借用するセキュアな手法。 | |
| リソース管理 | Resource Manager（Organization / Folder / Project） | ★★★ | 階層構造によるポリシー継承の仕組みと、管理・請求の境界線。 |
| データ保護 | Cloud Key Management Service (Cloud KMS) | ★★★ | 暗号鍵の管理（CMEK, CSEK）と要件に応じた使い分け。 |
| Cloud HSM | ★★☆ | FIPS要件を満たす、クラウド上のハードウェアセキュリティモジュールによる鍵管理。 | |
| Secret Manager | ★★★ | APIキーやDBパスワードなど機密情報の安全な保管、バージョン管理、アクセス制御。 | |
| セキュリティ境界 | VPC Service Controls | ★★★ | プロジェクト境界でのデータの引き出し（データ漏洩）防止。外部からのAPIアクセス遮断。 |
| Organization Policy Service | ★★★ | リソースの作成場所（特定リージョンのみ）や公開アクセスの禁止など、組織全体の制約。 | |
| Hierarchical Firewall Policies | ★★☆ | 組織やフォルダ単位で一元的に適用されるファイアウォールルール。 | |
| Context-Aware Access | ★★☆ | ユーザーのアイデンティティとコンテキスト（デバイスの状態など）に基づくアクセス制御。 | |
| 安全なリモートアクセス | Identity-Aware Proxy (IAP) | ★★★ | VPNを使わずに、ゼロトラストモデルで社内ウェブアプリやSSH/RDPへ安全にアクセス。 |
| Workload Identity Federation | ★★☆ | オンプレミスや他クラウドのIDプロバイダと連携し、サービスアカウントキーを発行せずに認証。 | |
| Chrome Enterprise Premium | ★☆☆ | 企業向けブラウザを利用したエンドポイントセキュリティの強化。 | |
| 監査・ログ | Cloud Audit Logs | ★★★ | 「誰が、いつ、どこで、何をしたか」を記録する監査ログの保存と分析。 |
| ソフトウェア サプライチェーン | Artifact Registry | ★★★ | コンテナイメージや各種パッケージの安全な保管とアクセス制御。 |
| Binary Authorization | ★★☆ | 署名（Attestation）を検証し、承認されたイメージのみをGKE等へデプロイさせる強制機能。 | |
| Software Delivery Shield | ★★☆ | 開発からデプロイまでのサプライチェーン全体を保護するソリューション。 | |
| AIセキュリティ | Model Armor | ★★☆ | AIモデルに対するプロンプトインジェクションなどの脅威から保護する機能。 |
| Sensitive Data Protection | ★★☆ | ログやストレージ内の機密データ（PIIなど）の自動検出とマスキング。 |
3.2 コンプライアンスを考慮して設計する
以下のような点を考察します。(公式ガイドより引用)
- 法規制（医療記録のプライバシー、児童のプライバシー、データのプライバシー、所有権、データ主権など）
- 商用（クレジット カードの情報処理などの機密データ、個人を特定できる情報（PII）など）
- 業界の認定資格（SOC 2 など）
- 監査（ログなど）
個人情報保護（PII）や業界のコンプライアンス要件（SOC 2など）を遵守するための設計が問われます。ここはIPAの情報処理試験（高度試験など）に近いマネジメント寄りの知識が求められるため、クラウド特有の監査ログ（Cloud Audit Logs）の仕組みなどと結びつけて理解しておけば問題なさそうです。
セクション 4: 技術プロセスやビジネス プロセスの分析と改善（試験内容の約 15%）
4.1 技術プロセスを分析、定義する
以下のような点を考察します。(公式ガイドより引用)
- ソフトウェア開発ライフサイクル（SDLC）
- 継続的インテグレーション / 継続的デプロイ
- トラブルシューティングと根本原因の分析のベスト プラクティス
- ソフトウェアとインフラストラクチャのテストと検証
- サービス カタログとプロビジョニング
- 障害復旧
CI/CDによる継続的デプロイメントや、障害復旧（DR）といった、システム運用の根幹に関わるベストプラクティスが問われます。単なるツールの使い方ではなく、ソフトウェア開発のライフサイクル全体を俯瞰し、ダウンタイムを最小限に抑えるプロセスの設計力が求められそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| CI/CD | Cloud Build | ★★★ | コンテナのビルドからテストの自動化を担うマネージドCI/CDプラットフォーム。 |
| Cloud Deploy | ★★★ | GKEやCloud Runへの継続的デリバリー。承認プロセスやカナリアリリースの組み込み。 | |
| Artifact Registry | ★★★ | ビルドされたコンテナイメージやアーティファクトを一元管理し、脆弱性スキャンと連携。 | |
| Infrastructure as Code | Terraform | ★★★ | 再現性の高いインフラストラクチャ構築と、宣言的な構成変更の管理。 |
| Infrastructure Manager | ★★☆ | Google CloudネイティブなIaCのデプロイおよび管理サービス。 | |
| サービスカタログ | Cloud Marketplace | ★★☆ | 認定済みのサードパーティ製ソフトウェアやソリューションの迅速なデプロイ。 |
| 構成管理 | OS Config | ★★☆ | Compute Engineでのパッチ管理とOS構成の自動化。 |
| モニタリング | Cloud Monitoring | ★★★ | メトリクスの収集、ダッシュボード化、SLOに基づくアラートの設定。 |
| Cloud Logging | ★★★ | ログの集中管理、ログベースの指標の作成、長期保管のためのBigQuery等へのルーティング。 | |
| Error Reporting | ★★☆ | アプリケーションのエラーやクラッシュを集約し、発生頻度を可視化。 | |
| Cloud Trace | ★★☆ | 分散システムにおけるリクエストのレイテンシをトレースし、ボトルネックを特定。 | |
| Cloud Profiler | ★☆☆ | 本番環境でアプリケーションのCPU・メモリプロファイリングを行い、パフォーマンスを分析。 | |
| 監査 | Cloud Audit Logs | ★★★ | 管理アクティビティやデータアクセスログの監査対応。 |
| 障害復旧 | Backup and DR Service | ★★★ | VMやDBなどのバックアップ計画の策定と、障害発生時のディザスタリカバリ手順の確立。 |
4.2 ビジネス プロセスを分析、定義する
以下のような点を考察します。(公式ガイドより引用)
- ステークホルダー管理（影響度の管理や円滑化など）
- チェンジ マネジメント
- チームの評価、スキルの準備
- 意思決定プロセス
- カスタマー サクセス マネジメント
- コストの最適化、リソースの最適化（CapEx / OpEx）
- ビジネスの継続性
ステークホルダー管理やチェンジマネジメント、コスト最適化（CapEx/OpExの考え方）など、ビジネス側に寄り添ったマネジメント知識が中心です。これもIPA試験で問われるような知識がベースになりますが、「それをクラウドの文脈でどう実現するか」という視点でのキャッチアップが必要になりそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| コスト管理 | FinOps Hub | ★★★ | 組織全体のクラウド費用対効果を監視し、最適化のインサイトを得るダッシュボード。 |
| Cloud Billing | ★★★ | プロジェクトと請求先アカウントの関連付け、リソース階層に基づくコスト管理。 | |
| Billing Reports | ★★☆ | ラベルを活用した部門ごとやサービスごとのコストの可視化と分析。 | |
| Billing Budgets & Alerts | ★★☆ | 予算の超過を検知して通知を送信し、Pub/Subと連携した自動制御を行う設計。 | |
| Recommender | ★★★ | アイドル状態のVMの特定や、確約利用割引（CUD）の提案など、コスト最適化を自動提案。 | |
| Active Assist | ★★☆ | Recommender等を含む、AIによるインフラストラクチャの継続的な最適化支援ツールの総称。 | |
| ビジネス継続性 | Google Cloud Well-Architected Framework | ★★★ | 信頼性、セキュリティ、コスト最適化、運用、パフォーマンス効率の5本柱に基づくアーキテクチャ評価。 |
| Backup and DR Service | ★★☆ | RTO/RPO要件に基づいたバックアップ運用とディザスタリカバリの継続性確保（再掲）。 |
セクション 5: 実装の管理（試験内容の約 12.5%）
5.1 開発・運用チームへのアドバイスと導入の成功
以下のような点を考察します。(公式ガイドより引用)
- アプリケーションとインフラストラクチャのデプロイ
- API 管理のベスト プラクティス（Apigee など）
- フレームワークのテスト（負荷、単体、インテグレーション）
- データとシステムの移行および管理ツール
- Gemini Cloud Assist
設計したアーキテクチャを実際に導入するにあたり、開発・運用チームをどう支援していくかがテーマです。API管理（Apigee）や移行ツールの活用など、チームがスムーズに開発・運用を回せるようにするための周辺ツールのベストプラクティスを押さえておく必要がありそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| デプロイ (アプリ & インフラ) | Cloud Build | ★★★ | マネージドなCI/CDプラットフォーム。Buildトリガーの設定、Artifact Registryへのイメージ保管、セキュリティ（SLSAレベルなど）の担保。 |
| Cloud Deploy | ★★★ | GKE、Cloud Runなどへの継続的デプロイ（CD）を管理。カナリアデプロイやブルー/グリーンデプロイ、迅速なロールバックのベストプラクティス。 | |
| Terraform / Infrastructure Manager | ★★★ | IaC（Infrastructure as Code）によるインフラの宣言的デプロイ。ステートファイルの管理や、冪等性の確保。 | |
| API 管理 | Apigee | ★★★ | エンタープライズ向けのAPI管理。レートリミット（流量制御）、OAuth認証、APIの収益化（マネタイズ）、分析。GKEやCloud Runのフロントとしての配置。 |
| API Gateway | ★★☆ | より軽量なAPI管理。Cloud FunctionsやCloud Runの前段に配置し、認証（Firebase AuthやAuth0など）を共通化するケース。 | |
| テストフレームワーク | Cloud Load Testing / Locustなど | ★★☆ | マネージドな負荷テストの設計（または分散環境の構築）。スケール時のボトルネック特定。 |
| CI環境での自動テスト | ★★☆ | Cloud Build内での単体テスト（Unit）やインテグレーションテスト（統合）の自動化プロセスと、エラー時の通知。 | |
| データ & システムの移行 | Database Migration Service (DMS) | ★★★ | MySQL、PostgreSQLなどのリレーショナルデータベースを、最小限のダウンタイムでCloud SQLやAlloyDBへ移行する（CDC: 変更データキャプチャ）。 |
| Storage Transfer Service | ★★★ | オンプレミスのストレージ、他社クラウド（S3など）からCloud Storageへ大量データを高速・安全に転送する。 | |
| BigQuery Data Transfer Service | ★★☆ | SaaS（Google広告など）や他社データウェアハウスからBigQueryへの自動データ取り込み。 | |
| Migrate to Containers | ★★☆ | VM（Compute Engineなど）をGKEやCloud Runのコンテナへ自動変換・移行するプロセス。 | |
| AIによる開発運用支援 | Gemini Cloud Assist | ★★★ | Google Cloud環境の設計、デプロイ、トラブルシューティング、コスト最適化を支援するAIアシスタント。ログの要約や、インフラ構成の推奨、IAM権限の最適化提案など。 |
5.2 Google Cloud をプログラマティックに操作する
以下のような点を考察します。(公式ガイドより引用)
- Cloud Shell エディタ、Cloud Code、Cloud Shell ターミナル
- Google Cloud SDK（gcloud、gsutil、bq など）
- クラウド エミュレータ（Bigtable、Spanner、Pub/Sub、Firestore など）
- Infrastructure as Code（IaC、Terraform など）
- Google API へのアクセスに関するベスト プラクティス
- Google API クライアント ライブラリ
コンソール画面からの操作ではなく、gcloudコマンドやTerraform（IaC）、Cloud Client Libraryを使った「コードによるインフラ管理」が問われます。実務での運用経験がない分、手元で実際にコマンドを叩いたり、エミュレータを使ってみたりして、体感として理解度を深める必要性を感じています。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| 開発・操作環境 | Cloud Shell / ターミナル | ★★☆ | ブラウザから直接アクセスできる管理マシンの役割。Google Cloud CLI（gcloudなど）や各種言語ツールがプリインストールされており、安全かつ迅速に作業を開始できる環境。 |
| Cloud Shell エディタ / Cloud Code | ★★☆ | Cloud CodeはVS CodeやIntelliJ向けの拡張機能。IDEから直接GKEやCloud Runへのデプロイ、デバッグ、ログ確認を行い、開発者のフィードバックループ（生産性）を向上させる手法。 | |
| コマンドライン ツール | gcloud CLI | ★★★ | Google Cloudリソースの作成・管理を行う主要ツール。APIのラッパーとして機能し、自動化スクリプトでの使用や初期設定（gcloud init, gcloud auth）が基本となる。 |
| gsutil / bq コマンド | ★★★ | gsutil（最新ではgcloud storageへの移行が推奨）はCloud Storageのバッチ処理や同期（rsync）。bqはBigQueryのテーブル操作やクエリ実行、データのロードに特化したCLI。 | |
| ローカル開発・テスト | クラウド エミュレータ | ★★☆ | Bigtable、Spanner、Pub/Sub、Firestoreなどのサービスをローカル環境で模倣するツール。クラウドの課金やネットワーク遅延を避けつつ、CI/CDパイプライン上で高速に統合テストを行うベストプラクティス。 |
| インフラのコード化 | Infrastructure as Code (IaC) / Terraform | ★★★ | インフラを宣言的なコードで管理する。試験では特にTerraformのベストプラクティス（状態ファイル tfstate をCloud Storageで一元管理してロックをかけるなど、チーム開発時の運用）が頻出。 |
| API アクセス・統合 | Google API クライアント ライブラリ | ★★☆ | REST APIを直接叩くのではなく、各言語（Python、Java、Goなど）向けに最適化された公式ライブラリを使う利点。認証の簡素化や自動ページネーションがサポートされる。 |
| API操作のベストプラクティス | ★★★ | **「エクスポネンシャル バックオフ（指数的バックオフ）」**による再試行ロジックの実装（一時的なエラーやレート制限への対処）。また、コード内にクレデンシャルをハードコードせず、**ADC（アプリケーションのデフォルト認証情報）**を使用するセキュリティの基本。 |
セクション 6: ソリューションとオペレーション エクセレンスの確保（試験内容の約 12.5%）
6.1 Google Cloud Well-Architected Framework のオペレーション エクセレンスの柱となる原則と推奨事項
システムの運用性を高め、継続的な改善を行っていくための「オペレーションエクセレンス」に関する基本的な考え方が問われるんでしょうか？Google Cloudが提唱するWell-Architected Frameworkのガイドラインを一度しっかりと読み込み、設計の拠り所となる原則を頭に入れておく必要がありそうです。
6.2 Google Cloud Observability ソリューションに関する知識
以下のような点を考察します。(公式ガイドより引用)
- モニタリングとロギング
- プロファイリングとベンチマーク
- アラート戦略
システムの健康状態を把握するための、モニタリング、ロギング、アラート設計の領域です。単にCloud LoggingやCloud Monitoringを知っているだけでなく、「SLI/SLOをどう定義し、どのような条件でアラートを発報するのが最適か」といったSRE（サイト信頼性エンジニアリング）的な思考が問われそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| ロギング (ログの収集と管理) | Cloud Logging | ★★★ | Google Cloudリソースやアプリケーションのログを一元管理。特定のエラーログをカウントしてメトリクス化する「ログベースの指標（Log-based metrics）」の活用。 |
| Log Router (ログシンク) | ★★★ | ログの保存要件に応じたルーティング設計が頻出。 ・長期保管/コンプライアンス要件 → Cloud Storage ・ログの分析/クエリ実行 → BigQuery ・リアルタイム通知/外部連携 → Pub/Sub | |
| モニタリング (メトリクスの監視) | Cloud Monitoring | ★★★ | CPU、メモリ、ネットワークなどのインフラ指標や、カスタム指標の収集・ダッシュボード化。「稼働時間チェック（Uptime Checks）」による外部からの死活監視。 |
| アラート戦略 (通知と自動化) | アラート ポリシーと通知チャネル | ★★★ | 異常を検知した際の通知設計。メール、Slack、PagerDuty連携のほか、Pub/Sub を通知チャネルに指定して Cloud Functions や Cloud Run を起動し、インシデント対応を「自動化」するアーキテクチャ。 |
| SREの原則 (SLO / エラーバジェット) | ★★★ | 原因（CPU使用率が高いなど）ではなく、症状（ユーザーへのレスポンスが遅い、エラーになるなど）に基づいてアラートを鳴らす「シンプトム・ベース・アラート」の考え方。 | |
| プロファイリングと ベンチマーク | Cloud Profiler | ★★☆ | 本番環境のアプリケーション（CPU、メモリ使用量）をオーバーヘッドを最小限に抑えて継続的に分析するツール。「どの関数のコードがリソースを消費しているか」を特定する際に使用。 |
| Cloud Trace | ★★☆ | マイクロサービスや分散システムにおけるレイテンシ（遅延）のボトルネックを特定する分散トレーシングツール。「システム全体のうち、どのAPI呼び出しに時間がかかっているか」の特定。 | |
| Error Reporting | ★★☆ | 発生したクラッシュやエラーを自動的に集約・グループ化し、発生頻度や影響範囲をダッシュボードで分かりやすく可視化する機能。 |
6.3 デプロイとリリース管理
システムを安全に本番環境へ反映するためのリリース戦略（カナリアリリースやブルーグリーンデプロイメントなど）が問われます。要件に応じて、ダウンタイムゼロでのリリースや、問題発生時の迅速なロールバックをどう実現するかを整理しておきたいと思います。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| リリース戦略 | デプロイメント戦略の比較 | ★★★ | ビジネス要件に応じた使い分け。 ・ブルー/グリーン: ゼロダウンタイム、瞬時の切り戻しが可能だがリソースが2倍必要。 ・カナリア: 一部のユーザー（例: 5%）にのみ新バージョンを公開し、リスクを最小化。 ・ローリング: インスタンスを徐々に入れ替える。 |
| トラフィック分割 (Traffic Splitting) | ★★★ | Cloud Run、App Engine、GKE (Ingress / Gateway API / サービスメッシュ) を使用して、リビジョン間でトラフィックを段階的に移行する機能。 | |
| アーティファクト管理 | Artifact Registry | ★★★ | コンテナイメージ、OSパッケージ（Debian, RPM）、言語パッケージ（Maven, npm）を一元管理。IAMによるアクセス制御とリージョン間の複製。 |
| 自動化と継続的提供 | Cloud Deploy / Cloud Build | ★★★ | テストからステージング、本番への昇格（プロモーション）プロセス。承認ゲート（手動承認）をパイプラインに組み込む設計。 |
6.4 デプロイされたソリューションをサポートし支援する
リリース後の運用フェーズにおいて、ユーザーサポートやシステムの維持管理をどのように行うかという観点です。運用の自動化やトラブルシューティングの仕組みなど、システムを「作って終わり」にしないための継続的なサポート体制の設計が求められそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| サポート体制 | Google Cloud Customer Care | ★★☆ | サポートプラン（Standard, Enhanced, Premium）の違い。特にPremiumの機能（15分以内のレスポンス要件、テクニカル アカウント マネージャー(TAM)の存在）をビジネス要件と照らし合わせる。 |
| インシデント管理 | 運用ドキュメント (Runbooks / Playbooks) | ★★☆ | 障害発生時に運用チームが迅速に対応するための手順書の整備。SREのベストプラクティスに基づく対応手順の標準化。 |
| ブレームレス・ポストモーテム | ★★★ | SREの重要な概念。障害発生後、特定の個人を非難（Blame）するのではなく、プロセスの欠陥やシステムの改善点に焦点を当てる事後検証の文化。 | |
| トラブルシューティング | Cloud Support API | ★☆ | サポートケース（問い合わせ）の作成・管理を、自社の社内システムやITSMツール（ServiceNowなど）とAPI経由で統合するアプローチ。 |
6.5 品質管理方法を評価する
本番環境で稼働するシステムの「品質」をどのように担保し、測定し続けるかがテーマです。テスト手法だけでなく、継続的なコード品質のチェックや、エラー予算（Error Budget）の考え方など、品質とスピードのバランスを取る運用手法を理解しておく必要がありそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| セキュリティと脆弱性 | Container Analysis (脆弱性スキャン) | ★★★ | Artifact RegistryにプッシュされたイメージのOSや言語パッケージの既知の脆弱性（CVE）を自動スキャンし、デプロイ前にリスクを評価する。 |
| Binary Authorization | ★★★ | GKEやCloud Runへのデプロイ時に、署名（Attestation）を検証し、「スキャンを通過し、承認された安全なイメージ」のみが本番環境で実行されることを保証する強制機能。 | |
| コードとアーティファクト | SLSA (Supply-chain Levels for Software Artifacts) | ★★☆ | ソフトウェア サプライチェーンの完全性を保護するためのセキュリティフレームワーク。ビルドの出所（Provenance）を保証する。 |
| テスト戦略 | シフトレフト (Shift-Left) テスト | ★★★ | セキュリティテストやコード解析を、開発サイクルの「右側（リリース直前）」ではなく「左側（開発・ビルドの初期段階）」に移動させ、早期にバグや脆弱性を発見する概念。 |
6.6 本番環境でソリューションの信頼性を確保する
システムが本番稼働した後に、意図的な障害注入（カオスエンジニアリング）や負荷テストを通じて、信頼性をどう証明し高めていくかが問われます。ここは単なる知識だけでなく、実際にどうシステムを検証して弱点を洗い出すかという、より高度な運用設計の知識が必要になりそうです。
⬇︎AIによる具体的なリソースの整理
| 分野 | 学習するリソース / 概念 | 優先度 | 概要・試験で問われそうなポイント |
|---|---|---|---|
| カオス エンジニアリング | 障害インジェクション (Fault Injection) | ★★★ | 本番環境（または本番同等環境）に意図的に障害（遅延やエラー）を注入し、システムの回復力をテストする。 ・Istio / Cloud Service Mesh: マイクロサービス間の通信にHTTP遅延やアボートを注入。 |
| ゾーン/リージョン障害のシミュレーション | ★★☆ | 特定のゾーンのVMを強制シャットダウンさせ、MIG（マネージドインスタンスグループ）のオートヒーリングやマルチリージョン構成のロードバランサが正常に機能するかをテストする。 | |
| ペネトレーション テスト | Google Cloud のペネトレーションテスト規約 | ★★★ | ユーザーが自身のプロジェクトに対してペネトレーションテストを実施する際、Googleへの事前承認は不要である（ただし、規約を遵守し、他テナントに影響を与えないこと）という運用ルール。 |
| Web Security Scanner | ★★☆ | App Engine、GKE、Compute Engine上で稼働するウェブアプリケーションの脆弱性（クロスサイトスクリプティング（XSS）、平文パスワードなど）を自動でクロールして検出する。 | |
| 負荷テスト | 分散負荷テストのアーキテクチャ | ★★★ | 大規模なトラフィックをシミュレートするために、GKE上でJMeterやLocustのワーカーノードを分散実行し、オートスケールの設定値やスロットル（上限）が正しく機能するかを評価する。 |
【まとめ】出題範囲の主要Google Cloudサービス一覧
ここまでの各セクションで登場した主なサービスを、機能カテゴリごとに整理しました。全体像の把握や、復習時のチェックリストとしてご活用ください。
| カテゴリ | 主なサービス・リソース・概念 |
|---|---|
| コンピューティング・コンテナ | Compute Engine, Google Kubernetes Engine (GKE), GKE Standard / Autopilot, Cloud Run, Cloud Run functions, Batch, Google Cloud VMware Engine, MIG, Spot/Confidential VM, Custom Machine Types, Sole-tenant Nodes, GPU / TPU |
| ネットワーキング | Virtual Private Cloud (VPC), Shared VPC, VPC Network Peering, Cloud Load Balancing, Cloud DNS, Cloud NAT, Cloud Router, Cloud Firewall / Firewall Policies, Cloud VPN, Cloud Interconnect, Cross-Cloud Interconnect, Cloud WAN, Private Service Connect, Network Connectivity Center, API Gateway, Apigee, Cloud Armor, GKE Networking |
| ストレージ | Cloud Storage, Persistent Disk, Hyperdisk, Local SSD, Filestore, Backup and DR Service, Storage Transfer Service, Transfer Appliance |
| データベース | Cloud SQL, Cloud Spanner, Firestore, Bigtable, Memorystore, Database Migration Service (DMS), Datastream |
| データ処理・分析 | BigQuery, Dataflow, Dataproc, Pub/Sub, Cloud Composer, BigQuery Data Transfer Service |
| セキュリティ・ID管理 | Identity and Access Management (IAM), Service Accounts, Workload Identity Federation, Identity-Aware Proxy (IAP), Context-Aware Access, Chrome Enterprise Premium, Secret Manager, Cloud KMS / Cloud HSM, Organization Policy Service, Sensitive Data Protection, Container Analysis, Binary Authorization, Web Security Scanner, Cloud Audit Logs, Model Armor, VPC Service Controls |
| 運用・監視 | Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, Error Reporting, Active Assist, Recommender |
| CI/CD・デプロイ | Cloud Build, Cloud Deploy, Artifact Registry, Software Delivery Shield, OS Config, Infrastructure Manager, Terraform / IaC, SLSA |
| 移行・モダナイゼーション | Migrate to Virtual Machines, Migrate to Containers, Migration Center |
| AI・機械学習 | Gemini Enterprise Agent Platform, Gemini Enterprise, Gemini Models, Gemini Cloud Assist, NotebookLM Enterprise, Model Garden, Agent Studio, Agent Runtime, ADK, Agent Platform Pipelines / Data Integration, AI Hypercomputer, Google AI API |
| 管理・組織・コスト | Resource Manager, Cloud Billing, Billing Budgets & Alerts, Billing Reports, FinOps Hub, Google Cloud Customer Care |
| アーキテクチャ概念・その他 | SREの原則, 障害インジェクション, ゾーン/リージョン障害のシミュレーション, 分散負荷テスト, シフトレフトテスト, トラフィック分割, デプロイメント戦略の比較, ブレームレス・ポストモーテム, クラウドエミュレータ, Cloud Shell / エディタ |
1ヶ月で合格するための学習計画を立てる
ここまで、公式ガイドに基づく出題範囲と、試験で問われそうなポイント、そして各セクションで必要になる具体的なリソースについて整理してきました。記事の冒頭で掲げた「この記事でやること」の1と2が完了したことになります。
範囲の広さに改めて圧倒されていますが、残り1ヶ月（約4週間）で合格ラインに到達するため、以下のようなスケジュールで学習を進めていく計画を立てました。
第1週〜第2週：出題範囲のサービス・リソースの理解
最初の2週間は、この記事で整理した表をベースにインプットに集中します。
- 各セクション、各項目で求められる具体的なGoogle Cloudのサービスやリソース（例えば、Compute EngineとGKEの使い分け、Cloud VPNとInterconnectの違いなど）を確実に理解する。
- サービス単体の知識だけでなく、「どのような要件のときに、どのサービスを組み合わせるべきか」というアーキテクチャの視点を意識して知識を吸収する。
第3週：体系的な知識の定着とハンズオン
次の1週間は、インプットした知識を実践的なものに昇華させます。
- Google Cloud Skills Boost（Professional Cloud Architect 向けの学習パス）を活用し、体系的な知識を身につける。
- 単なる座学で終わらせず、実際にハンズオンで手を動かしながら、コンソール画面やコマンドラインでの操作感を体感として定着させる。
第4週：模擬問題での総仕上げと弱点補強
最後の1週間は、ひたすらアウトプットと復習に充てます。
- UdemyにあるPCAの模擬問題集や、Google Cloud公式の模擬試験を解きまくる。
- そこで間違えた問題や、まだ知識が不足しているセクションに戻り、ピンポイントで復習・補強を行う。
- 実際の試験を想定し、問題文から要件を素早く読み解く訓練をする。
おわりに
「9/19点」という絶望的なスコアからのスタートですが、こうして出題範囲とやるべきことを整理できたことで、少しだけ道筋が見えてきました。 これから1ヶ月間、この学習計画に沿って本気で対策を進めていきます。無事に合格できたら、またその体験記を書きたいと思います！