IT支出を、大規模な先行ハードウェア購入から従量課金モデルに移行する。
クラウドサービスを利用して、設備投資（CapEx）を運用支出（OpEx）に変換する。
理由: クラウドは財務上の柔軟性を提供し、参入障壁を下げ、コストを使用量に直接合わせることで、過剰なプロビジョニングを回避する。
CertLabProGoogle Cloud Digital Leader
最終確認：2026年5月
CDL 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
IT支出を、大規模な先行ハードウェア購入から従量課金モデルに移行する。
クラウドサービスを利用して、設備投資（CapEx）を運用支出（OpEx）に変換する。
理由: クラウドは財務上の柔軟性を提供し、参入障壁を下げ、コストを使用量に直接合わせることで、過剰なプロビジョニングを回避する。
クラウドプロバイダと顧客間のセキュリティ所有権を明確にする。
Googleはクラウドインフラストラクチャ（ハードウェア、ネットワーク）を保護する。顧客はクラウドに置くもの（データ、IAM、アプリケーションコード）を保護する。
理由: 顧客は、サービスモデル（IaaS、PaaS、SaaS）に関わらず、常に自身のデータとアクセス制御に責任を負う。
他のプラットフォームやテクノロジーを使用する柔軟性を維持しつつ、クラウドを導入する。
Kubernetes (GKE)、TensorFlow、Apache Beam (Dataflow) のようなオープンソーステクノロジーを基盤とするサービスを優先する。
理由: オープンソース標準はワークロードのポータビリティを高め、プロプライエタリなAPIへのロックインを防ぎ、ハイブリッド/マルチクラウド戦略を可能にする。
企業の持続可能性目標を達成するために、IT運用の二酸化炭素排出量を削減する。
Google Cloudでワークロードをホストし、その100%再生可能エネルギーマッチングを活用する。Carbon Footprintツールを使用して、低炭素排出量のリージョンを監視・選択する。
理由: Google Cloudは最もクリーンなクラウドの一つを運営しており、企業はその持続可能性の恩恵を継承できる。
規制やデータ主権により、オンプレミスインフラストラクチャとクラウドサービスを統合する必要がある。
Anthosを使用して、オンプレミスとGoogle Cloud全体で一貫性のあるKubernetesベースのプラットフォームを提供する。
理由: Anthosは、アプリケーションがどこで実行されていても、統合された管理およびコントロールプレーンを提供し、ハイブリッド運用を簡素化する。
インフラストラクチャを管理することなく、ペタバイト規模の構造化データを複雑なSQLクエリで分析する。
BigQueryを使用する。
理由: BigQueryは、大規模な分析クエリに最適化された、フルマネージドのサーバーレスデータウェアハウスである。
強力な一貫性と水平スケーラビリティを備えた、グローバルに分散されたリレーショナルデータベースが必要。
Cloud Spannerを使用する。
理由: Spannerは、リレーショナルなセマンティクス（ACID、SQL）と非リレーショナルなスケールを組み合わせたもので、金融などのミッションクリティカルなグローバルアプリケーションに最適である。
シンプルなキーバリューデータ（例：IoT、ユーザープロファイル）を単一ミリ秒台のレイテンシで大量に保存および取得する。
Cloud Bigtableを使用する。
理由: Bigtableは、高スループット、低レイテンシの運用および分析ワークロード向けに最適化されたワイドカラムNoSQLデータベースである。
リアルタイムデータ同期とオフライン機能を必要とするモバイルまたはウェブアプリケーションを構築する。
Firestoreを使用する。
理由: Firestoreは、リアルタイム同期とオフライン持続性を内蔵したNoSQLドキュメントデータベースであり、最新のアプリケーション開発向けに設計されている。
従来のオンプレミスMySQL、PostgreSQL、またはSQL Serverデータベースを、最小限の変更でマネージドクラウドサービスに移行する。
Cloud SQLを使用する。
理由: Cloud SQLは、標準的なデータベースエンジンとの互換性を提供し、バックアップ、パッチ、レプリケーションを自動化するフルマネージドのリレーショナルデータベースサービスである。
リアルタイムの大量データストリーム（例：IoT、クリックストリーム）を取り込み、即座に分析するために処理する。
取り込みにはPub/Sub、ストリーム処理にはDataflow、分析にはBigQueryを使用する。
理由: これは、Google Cloud上でのスケーラブルなリアルタイム分析のための標準的なサーバーレスパターンである。
アクセスパターンが異なるデータ（頻繁、低頻度、アーカイブ）をコスト効率よく保存する。
Cloud Storageでライフサイクルポリシーを使用し、データがStandard、Nearline、Coldline、Archiveクラス間を自動的に移行するようにする。
理由: ライフサイクルポリシーは、手動介入なしにストレージコストをアクセス頻度に合わせるデータ階層化を自動化する。
将来の処理と分析のために、大量の生データ、非構造化データ、半構造化データを保存する。
Cloud Storageを中央リポジトリ（データレイク）として使用する。
理由: Cloud Storageは、耐久性があり低コストのオブジェクトストレージを提供し、すべてのGCPデータ処理サービス（BigQuery、Dataproc、Dataflow）と統合される。
Apache SparkやHadoopのようなオープンソースフレームワークを使用して、大規模なデータ処理ジョブを実行する。
Dataprocを使用する。
理由: Dataprocは、フルマネージドのSparkおよびHadoopクラスターを提供し、クラスターの作成と管理を自動化することで、チームがジョブに集中できるようにする。
機械学習の専門知識がなくても、画像認識、感情分析、音声書き起こしなどのAI機能をアプリに追加する。
事前学習済みAPIを使用する: Vision AI、Natural Language AI、Speech-to-Text API、Translation API。
理由: これらのAPIは、一般的なユースケース向けにGoogleの最先端モデルを提供し、シンプルなREST API呼び出しのみを必要とする。
自身のラベル付きデータ（例：製品画像、顧客テキスト）を使用してカスタムMLモデルをトレーニングするが、MLコーディング経験はない。
Vertex AI内でAutoMLを使用する。
理由: AutoMLはモデル構築プロセスを自動化し、チームがシンプルなグラフィカルインターフェースを通じて高品質なカスタムモデルを作成できるようにする。
データサイエンスチームが、カスタムMLモデルをライフサイクル全体（MLOps）にわたって構築、トレーニング、デプロイ、管理するための一元化されたプラットフォームを必要としている。
Vertex AIを使用する。
理由: Vertex AIは、機械学習ワークフローのあらゆるステップに対応するツールを単一環境で提供する包括的なMLOpsプラットフォームである。
スキャンされたドキュメントやPDFから構造化された情報（例：請求書番号、明細項目）を自動的に抽出する。
Document AIを使用する。
理由: Document AIは、ドキュメントのレイアウトを理解し、構造化データを抽出するために特別にトレーニングされており、手作業によるデータ入力を削減する。
顧客サービス問い合わせに対応するためのチャットボットまたは音声ベースの仮想エージェントを構築する。
Dialogflowを使用する。
理由: Dialogflowは、会話型インターフェースを構築し、インテント、エンティティ、会話フローを管理するために設計された自然言語理解プラットフォームである。
データウェアハウスに保存されたデータに対して、SQLのみを使用して予測モデルを直接構築・実行する。
BigQuery MLを使用する。
理由: BigQuery MLは、データアナリストが慣れ親しんだSQL構文を使用してモデルを作成できるため、データの移動を回避し、機械学習を民主化する。
テキストの要約、コード、画像などの新しいコンテンツを生成できるアプリケーションを構築する。
Generative AI向けにVertex AIプラットフォームを使用し、Geminiのような基盤モデルにアクセスする。
理由: Vertex AIは、強力な基盤モデルへのマネージドアクセスをAPI経由で提供し、生成AI機能の迅速な開発を可能にする。
VM上で動作するレガシーアプリケーションを、最小限の変更でクラウドに移行し、完全なOS制御を必要とする。
Compute Engineを使用する。
理由: Compute Engine (IaaS) は仮想マシンを提供し、最大限の制御とオンプレミスサーバーの直接的な移行パスを提供する。
トラフィックに基づいて自動的にスケーリング（ゼロへのスケーリングを含む）する必要がある、ステートレスなコンテナ化されたウェブアプリケーションをデプロイする。
Cloud Runを使用する。
理由: Cloud Runは、すべてのインフラストラクチャを抽象化し、アクティブなリクエスト処理時間に対してのみ課金される、コンテナ向けのフルマネージドサーバーレスプラットフォームである。
コンテナを使用して複雑なマイクロサービスアーキテクチャを実行し、きめ細やかなオーケストレーションと制御を必要とする。
Google Kubernetes Engine (GKE) を使用する。
理由: GKEは、マネージドでプロダクション対応のKubernetes環境を提供し、クラスター管理を自動化しながら、完全なオーケストレーション機能を提供する。
Cloud StorageへのファイルアップロードやPub/Subメッセージなどのイベントに応答して、小さなコードを実行する。
Cloud Functionsを使用する。
理由: Cloud Functions (FaaS) は、サーバーを管理することなく、短期間で単一目的の関数に最適なサーバーレスのイベント駆動型コンピューティングサービスである。
ウェブアプリケーションをデプロイし、コードの記述のみに集中し、プラットフォームにサーバー、スケーリング、パッチ適用を任せる。
App Engineを使用する。
理由: App Engine (PaaS) は、すべてのインフラストラクチャを抽象化するフルマネージドプラットフォームであり、アプリケーションを最速でデプロイしたい開発者に最適である。
大規模なフォールトトレラントなバッチ処理やハイパフォーマンスコンピューティングジョブを、可能な限り低コストで実行する。
Compute EngineのSpot VMを使用する。
理由: Spot VMは、中断可能なワークロードに対して大幅な割引（最大91%）を提供し、非クリティカルなバッチジョブにとって非常にコスト効率が高い。
オンプレミスのデータセンターとGoogle Cloudの間で、高帯域幅、低レイテンシのプライベート接続を確立する。
Cloud Interconnectを使用する。
理由: Cloud Interconnectは専用の物理接続を提供し、パブリックインターネット経由のVPNよりも信頼性が高く一貫したパフォーマンスを提供する。
世界中のユーザーベースに、低レイテンシでウェブコンテンツまたはビデオコンテンツを配信する。
Cloud CDNを使用する。
理由: Cloud CDNは、Googleのグローバルに分散されたエッジロケーションにコンテンツをキャッシュし、ユーザーの近くのPoPからコンテンツを提供する。
コンテナイメージ、OSパッケージ、言語パッケージを脆弱性スキャンで安全に保存および管理する。
Artifact Registryを使用する。
理由: Artifact Registryは、CI/CDおよびGKEと統合され、安全で一元化されたパッケージ管理を提供するユニバーサルなマネージドリポジトリである。
アプリケーションを再設計したり、運用ツールを変更したりすることなく、既存のVMwareワークロードをGoogle Cloudに移行する。
Google Cloud VMware Engineを使用する。
理由: これは、Google Cloud上で動作する専用のフルマネージドVMwareソフトウェア定義データセンター (SDDC) を提供し、VMwareのシームレスな「リフト＆シフト」を可能にする。
最小権限の原則に従い、職務に基づいてクラウドリソースへのユーザーアクセスを管理する。
個々のユーザーではなく、Googleグループに事前定義またはカスタムIAMロールを割り当てる。
理由: グループを介した権限管理は管理を簡素化し、新しいユーザーが正しい最小限の権限を自動的に継承することを保証する。
GCP組織全体で、セキュリティの脆弱性、脅威、設定ミスを一元的に把握する。
Security Command Centerを使用する。
理由: これは、セキュリティのシングルペインオブグラスとして機能し、複数のソースからの検出結果を集約し、実用的なインサイトを提供する。
公開ウェブアプリケーションをDDoS攻撃や一般的なWebエクスプロイト（例：SQLインジェクション）から保護する。
Cloud Armorを使用する。
理由: Cloud Armorは、GoogleのWebアプリケーションファイアウォール（WAF）であり、グローバルロードバランサと統合されたDDoS緩和サービスである。
暗号化キーを完全に制御しながら、クラウドサービス内のデータを暗号化する。
Cloud Key Management Service (Cloud KMS) を使用して、顧客管理の暗号化キー（CMEK）を作成する。
理由: CMEKを使用すると、コンプライアンスやポリシー上の理由からキーのライフサイクル（ローテーション、破棄）を制御でき、Googleはキーインフラストラクチャを管理する。
Cloud StorageまたはBigQueryに保存されている機密データ（例：クレジットカード番号、PII）を検出、分類、匿名化する。
Cloud Data Loss Prevention (DLP) を使用する。
理由: Cloud DLPは、偶発的な漏洩を防ぐために、機密データを自動的にスキャンして対応措置を講じるツールを提供する。
従来のVPNを使用せずに、従業員が内部ウェブアプリケーションに安全にアクセスできるようにする。
Identity-Aware Proxy (IAP) を使用する。
理由: IAPは、ユーザーIDとコンテキストに基づいてアクセスポリシーを適用し、アプリケーションに対するゼロトラストセキュリティモデルを作成する。
機密性の高いGoogle Cloudプロジェクトとサービスの周囲にセキュリティ境界を作成することで、データ流出を防ぐ。
VPC Service Controlsを使用する。
理由: VPC Service Controlsはサービスとデータを隔離し、有効なIAM権限を持つユーザーであっても、定義された境界外にデータが移動できないようにする。
APIキー、パスワード、証明書などのアプリケーションシークレットを安全に保存および管理する。
Secret Managerを使用する。
理由: Secret Managerは、きめ細やかなIAM権限を持つシークレットのための一元化され、バージョン管理され、監査されたストアを提供し、コードや設定ファイルに保存するよりも安全である。
メトリクス、ログ、トレースを通じて、アプリケーションとインフラストラクチャの健全性に関する包括的な可観測性を得る。
Google Cloud運用スイートを使用する: Cloud Monitoring（メトリクス/アラート）、Cloud Logging（ログ）、Cloud Trace（トレース）。
理由: この統合スイートは、プロアクティブな監視と迅速なトラブルシューティングのために、システムパフォーマンスの完全な全体像を提供する。
クラウド支出を積極的に管理し、コストが計画額を超える前に通知を受け取る。
Cloud Billingの予算アラートを設定する。
理由: 予算は、支出が特定のしきい値に達したときにプログラムによる通知を提供し、コスト超過を防ぐ。
チャージバックのために、クラウドコストを特定のチーム、プロジェクト、またはコストセンターに追跡および配分する。
すべてのリソースにラベルを適用し、Cloud Billingレポートを使用してラベルごとにコストをフィルタリングおよびグループ化する。
理由: ラベルは、リソースを整理し、財務ガバナンスのためのコストを帰属させる主要なメカニズムである。
継続的に実行される予測可能で定常的なワークロード（例：データベースサーバー）のコストを削減する。
Compute Engineまたは他のサービス向けに、1年または3年のコミットメント利用割引（CUD）を購入する。
理由: CUDは、一貫したリソース使用レベルへのコミットメントと引き換えに、オンデマンド料金よりも大幅な節約を提供する。
会社の組織構造（例：部門、環境）を反映するようにクラウドリソースを整理し、ポリシーを階層的に適用する。
組織 > フォルダ > プロジェクトのリソース階層を使用する。
理由: この構造により、IAMおよび組織のポリシーが階層を下って継承されるため、一元的な制御が可能になり、大規模なガバナンスが簡素化される。
クラウドインフラストラクチャを、反復可能で、バージョン管理され、自動化された方法で定義、デプロイ、管理する。
TerraformやCloud Deployment ManagerなどのInfrastructure as Code (IaC) ツールを使用する。
理由: IaCは手動エラーを削減し、デプロイ速度を向上させ、インフラストラクチャ変更の監査可能な記録を提供する。
サービスの信頼性の必要性と、革新して新機能をリリースする必要性のバランスを取る。
Site Reliability Engineering (SRE) の原則を実装する: サービスレベル目標 (SLO) を定義し、結果として得られるエラーバジェットを使用する。
理由: エラーバジェットは、ユーザーエクスペリエンスを保護するために、機能開発よりも信頼性作業をいつ優先すべきかを決定するためのデータに基づいたフレームワークを提供する。