この記事でわかること
- シラバス全6セクションの重要ポイントを網羅した解説
- 試験で問われやすい「サービスの使い分け」と「紛らわしい選択肢」の整理
- 各セクションの出題比率と優先度
- 試験直前30分の確認チェックリスト
この記事の使い方
この記事は、Cloud Digital Leader（以降 CDL）試験の全体像の把握や、試験直前の最終チェックにご利用いただくことを想定しております。本記事と併せて、公式ドキュメントや模擬試験での学習をしていただくことを強く推奨いたします。
試験の基本情報
試験形式
| 項目 | 内容 |
|---|---|
| 問題数 | 50〜60問（多肢選択式・複数選択式） |
| 試験時間 | 90分 |
| 受験料 | $99 USD（税別） |
| 受験方法 | オンライン（遠隔監視）または認定テストセンター |
| 合格ライン | 非公開（目安として70%前後とされている） |
| 有効期限 | 3年（更新試験あり） |
CDLの立ち位置
Google Cloud認定資格の中で唯一の「全員向け」基礎資格です。エンジニア以外のビジネス職・マネージャー・非IT職でも受験が想定されており、前提知識は不要。他の認定資格（Professional系）への足がかりとしても活用できます。
セクション別出題比率
| セクション | テーマ | 出題比率 |
|---|---|---|
| Section 1 | Google Cloud によるデジタルトランスフォーメーション | 約17% |
| Section 2 | Google Cloud によるデータ変革 | 約16% |
| Section 3 | Google Cloud AI によるイノベーション | 約16% |
| Section 4 | インフラとアプリのモダナイゼーション | 約17% |
| Section 5 | Google Cloud のセキュリティと信頼 | 約17% |
| Section 6 | Google Cloud オペレーションによるスケール | 約17% |
全セクションほぼ均等な出題比率が特徴です。苦手セクションを作らないことが合格への近道です。
推奨勉強時間の目安
| 対象 | 目安期間 |
|---|---|
| IT経験者（クラウド経験あり） | 2〜4週間 |
| エントリーレベルのITエンジニア | 1〜2ヶ月 |
| 非エンジニア | 2〜3ヶ月（約80時間が目安） |
Section 1：Google Cloud によるデジタルトランスフォーメーション（約17%）
Section 1はCDLの「哲学的な土台」です。クラウドとは何か、なぜ企業がクラウドに移行するのか——その「なぜ」を理解していることを問う問題が中心です。暗記より「考え方の理解」が問われます。
1-1. クラウドとデジタルトランスフォーメーション
重要用語の定義
CDL試験では用語の正確な理解が前提になります。以下を整理しておきましょう。
| 用語 | 定義 |
|---|---|
| クラウド | インターネット経由でオンデマンドにアクセスできるコンピューティングリソースの総称。物理ハードウェアを自社で持つ必要がなくなる |
| デジタルトランスフォーメーション（DX） | デジタル技術を活用してビジネスモデル・組織・プロセスを変革し、競争優位を築くこと。単なる「IT化」ではなく価値創出方法そのものを変えること |
| クラウドネイティブ | 最初からクラウドの特性（スケーラビリティ・分散・自動化）を前提として設計・構築されたアプリケーションや手法 |
| オープンソース | ソースコードが公開され、誰でも利用・変更・配布できるソフトウェア（例：Kubernetes、TensorFlow） |
| オープンスタンダード | 特定ベンダーに依存しない業界標準規格。ベンダーロックインを避けるために重要 |
クラウドの主要なメリット6つ
ここが出る
「なぜ企業はクラウドに移行するのか」を問う問題は頻出です。以下の6つを「なぜそうなるか」とセットで理解してください。
| メリット | 内容 |
|---|---|
| スケーラビリティ | 需要に合わせてリソースを瞬時に増減。トラフィック急増時もサービス停止しない |
| 柔軟性 | 必要なときに必要な分だけ使える。新サービス立ち上げのリードタイムが大幅短縮 |
| 俊敏性（アジリティ） | 新しいアイデアを素早く試せる。失敗コストが低く、イノベーションのサイクルが速くなる |
| セキュリティ | Google規模のセキュリティ投資の恩恵を受けられる。自社構築より高水準のセキュリティが実現しやすい |
| コスト効率 | 初期設備投資（CAPEX）が運用費（OPEX）に変わる。使った分だけ払うモデルでムダがない |
| 戦略的価値 | IT部門がインフラ管理ではなくビジネス価値創出に集中できる |
1-2. オンプレミス vs クラウドの比較
デプロイメントモデルの使い分け
| モデル | 概要 | 主な採用理由 |
|---|---|---|
| オンプレミス | 自社でサーバーを所有・管理 | データを完全に自社管理できる。規制が厳しい業界（金融・医療）向け |
| パブリッククラウド | CSPが提供するインフラをインターネット経由で利用 | 初期投資ゼロ、スケーラビリティが最高 |
| プライベートクラウド | 自社専用のクラウド環境 | セキュリティ要件が極めて高い組織向け |
| ハイブリッドクラウド | オンプレミスとパブリッククラウドの組み合わせ | 移行期間中や、一部データをオンプレミスに残す必要がある場合 |
| マルチクラウド | 複数のパブリッククラウドを組み合わせ | 特定ベンダーへの依存を避けたい場合や、各クラウドの強みを使い分けたい場合 |
ここが出る
- 「データ主権（データを自国内に置く義務）」が求められる場合 → プライベートクラウド or ハイブリッドクラウド
- 「コストを最小化しスケーラビリティを確保したい」 → パブリッククラウド
- 「既存のオンプレミス投資を活かしながらクラウドも使いたい」 → ハイブリッドクラウド
1-3. IaaS / PaaS / SaaS と責任共有モデル
サービスモデルの比較
これはCDLで必ず出る重要トピックです。「どのモデルを選ぶか」の判断基準をシナリオと一緒に覚えてください。
| モデル | 提供範囲 | ユーザーが管理するもの | Google Cloudの例 |
|---|---|---|---|
| IaaS | 仮想マシン・ネットワーク・ストレージ | OS・ミドルウェア・アプリ | Compute Engine |
| PaaS | OS・ミドルウェア・ランタイムまで | アプリケーションのコードのみ | App Engine、Cloud Run |
| SaaS | 完成したソフトウェア | 設定・利用のみ | Google Workspace |
責任共有モデル
ここが出る
- データの保護・分類は、どのモデルでも常にユーザーの責任
- 物理インフラのセキュリティは常にクラウドの責任
- IaaS → ユーザーの責任範囲が最大（OS・ミドルウェア・アプリすべて）
- SaaS → ユーザーの責任範囲が最小（データとアクセス管理のみ）
「自分のデータはクラウドに任せれば安全」は誤り。データの適切な分類・アクセス制御はユーザー責任です。
Section 2：Google Cloud によるデータ変革（約16%）
Section 2は「データをどう扱うか」を問うセクションです。BigQueryを中心に、データのライフサイクルと各サービスの役割分担を理解することが合格の鍵です。
2-1. データの種類とデータライフサイクル
データの3分類
| 種類 | 特徴 | 例 |
|---|---|---|
| 構造化データ | テーブル形式で整理。SQLで扱いやすく分析に向いている | 売上データ・顧客マスタ・在庫データ |
| 半構造化データ | 固定スキーマを持たないが一定の構造あり | APIのレスポンス（JSON）・ログファイル |
| 非構造化データ | テーブルや構造を持たない。全データの約80%を占める。AIが価値を引き出す対象 | 画像・動画・音声・テキスト文書・メール |
データライフサイクルの4段階
| フェーズ | 内容 |
|---|---|
| インジェスト（取り込み） | データソースからクラウドへデータを取り込む |
| 保存（ストレージ） | 適切な形式・場所にデータを保管する |
| 処理・分析 | データを変換・集計・分析する |
| 可視化・活用 | ダッシュボードやレポートで意思決定に活用する |
2-2. Google Cloudのデータサービス一覧と使い分け
ストレージ系
Cloud Storage
あらゆる形式のデータを保存できるオブジェクトストレージ。データレイクの中心的存在。
| クラス | アクセス頻度 | 主な用途 |
|---|---|---|
| Standard | 頻繁 | ウェブコンテンツ・ストリーミング |
| Nearline | 月1回程度 | バックアップ |
| Coldline | 四半期に1回程度 | 災害対策 |
| Archive | 年1回以下 | 長期アーカイブ |
データベース系
| サービス | 種別 | 特徴 | 主な用途 |
|---|---|---|---|
| Cloud SQL | リレーショナル（マネージド） | MySQL・PostgreSQL・SQL Serverに対応 | 既存DBのリフト&シフト移行 |
| Cloud Spanner | リレーショナル（グローバル分散） | 水平スケールしながらACIDトランザクションを保証 | 金融・グローバルECなど強整合性が必要な用途 |
| Firestore | NoSQL（ドキュメント型） | リアルタイム同期機能あり | モバイル・Webアプリのバックエンド |
| Bigtable | NoSQL（超大規模） | ペタバイト級データを低レイテンシで処理 | IoTデータ・時系列データ・広告分析 |
ここが出る：データベース選択基準
- SQLが使いたい（中小規模）→ Cloud SQL
- グローバルスケール＋ACID保証 → Cloud Spanner
- モバイルアプリのリアルタイムDB → Firestore
- 大量の時系列・IoTデータ → Bigtable
分析・データウェアハウス系
BigQuery
CDL試験で最も重要なサービスの1つ。サーバーレスのデータウェアハウスで、ペタバイト規模のデータをSQLで分析できます。
ここが出る：BigQueryの強みを問う問題
- サーバーレス → インフラ管理不要
- 列指向ストレージ → 分析クエリが高速
- BigQuery ML → SQLだけでMLモデルを作成・評価できる
- BigQuery Omni → 他クラウドのデータもその場で分析可能
Looker：BigQueryと統合してダッシュボード・レポートを作成するBIプラットフォーム。
データ処理・パイプライン系
| サービス | 役割 | 特徴 |
|---|---|---|
| Pub/Sub | 非同期メッセージング | データパイプラインの「バッファ」。データソースと処理の間を疎結合に保つ |
| Dataflow | ストリーム&バッチ処理 | Apache Beamベース。リアルタイムETLパイプラインに強い |
| Dataproc | SparkとHadoopのマネージドサービス | 既存オンプレミスのSparkジョブをそのまま移行したい場合に選択 |
ここが出る：データパイプラインの典型パターン
データソース → Pub/Sub（バッファ） → Dataflow（処理） → BigQuery（分析）
→ Looker（可視化）
Section 3：Google Cloud AI によるイノベーション（約16%）
Section 3はAI・機械学習のサービス体系を問うセクションです。「どの業務課題にどのAIサービスを使うか」の判断が問われます。
3-1. Google CloudのAIサービス3層構造
Google CloudのAIサービスは「開発の難しさ」と「カスタマイズ性」でトレードオフがある3層構造になっています。
| 層 | サービス | 難易度 | カスタマイズ性 | 主な用途 |
|---|---|---|---|---|
| 第1層 | 事前トレーニング済みAPI | 低（APIを呼ぶだけ） | 低 | 既存の汎用AIで十分な業務 |
| 第2層 | AutoML | 中（自社データを用意） | 中 | 汎用APIでは精度不足・自社固有の分類や検出 |
| 第3層 | Vertex AI | 高（コーディングが必要） | 高 | フルコントロールでカスタムモデルを開発 |
ここが出る：AIサービス選択基準
- コーディングなしで素早く使いたい → 事前トレーニング済みAPI
- 自社データでカスタマイズしたいがコードは書きたくない → AutoML
- フルコントロールでカスタムモデルを開発したい → Vertex AI
3-2. 生成AIとGoogle Cloud
| サービス | 概要 |
|---|---|
| Gemini | GoogleのマルチモーダルLLM。テキスト・画像・音声・コードを理解・生成できる |
| Vertex AI Gemini API | 自社アプリケーションにGeminiを組み込むためのAPI |
| BigQuery ML | BigQueryのSQL構文だけでMLモデルを作成・トレーニング・評価・予測できる機能 |
ここが出る
- 「SQLだけでMLを実行したい」→ BigQuery ML
- 「自社アプリに生成AIを組み込みたい」→ Vertex AI Gemini API
3-3. AI活用で注意すべき概念
説明可能なAI（Explainable AI）
AIの判断根拠を人間が理解できる形で提示すること。規制業界（金融・医療）では特に重要。Vertex AIに機能として組み込まれています。
責任あるAI（Responsible AI）
公平性・透明性・プライバシー保護を考慮したAI開発・運用の考え方。Google CloudではAIの責任ある利用のための原則が公表されています。
Section 4：インフラとアプリのモダナイゼーション（約17%）
Section 4はGoogle Cloudのコンピュート・ストレージ・ネットワークの基礎と、オンプレミスからクラウドへの移行パターンを問うセクションです。
4-1. コンピュートオプションの使い分け
| サービス | 種別 | 特徴 | 選ぶ状況 |
|---|---|---|---|
| Compute Engine | IaaS（VM） | OSから自由に構成できる。最大の制御性 | オンプレミスのサーバーをリフト&シフトする場合 |
| Google Kubernetes Engine（GKE） | コンテナオーケストレーション | KubernetesのマネージドサービS | マイクロサービスアーキテクチャを運用する場合 |
| Cloud Run | サーバーレスコンテナ | インフラ管理不要。リクエスト時のみ起動 | コンテナだがインフラを管理したくない場合 |
| App Engine | PaaS | コードをデプロイするだけで自動スケール | インフラをまったく意識したくないWebアプリ |
| Cloud Functions | FaaS | イベント駆動で小さなコードを実行 | イベントをトリガーにした処理（GCSアップロードなど） |
ここが出る：コンピュートの選択軸
- VMをそのまま移行したい → Compute Engine
- コンテナ化してKubernetesで管理したい → GKE
- コンテナだがインフラ管理したくない → Cloud Run
- コードだけデプロイしたいWebアプリ → App Engine
- イベントをトリガーに小さな処理を走らせたい → Cloud Functions
4-2. ネットワークの基礎
| サービス | 役割 |
|---|---|
| VPC（Virtual Private Cloud） | Google Cloud上のネットワーク。各種リソースを稼働 |
| Cloud Load Balancing | グローバル負荷分散。単一IPで世界中のリージョンにトラフィックを分散 |
| Cloud CDN | コンテンツをユーザーに近いエッジポイントにキャッシュして高速配信 |
| Cloud Interconnect / VPN | オンプレミスとGoogle Cloudを専用線またはVPN経由で接続。ハイブリッドクラウド構成に使用 |
4-3. モダナイゼーション戦略
| 戦略 | 内容 | メリット | デメリット |
|---|---|---|---|
| リフト&シフト（Rehost） | 既存システムをそのままクラウドに移行 | 最速・移行リスク低 | クラウドのメリットを最大限活かしにくい |
| コンテナ化（Replatform） | アプリをコンテナに載せ替えてGKEやCloud Runで動かす | 可搬性とスケーラビリティが向上 | ある程度の改修が必要 |
| クラウドネイティブ再設計（Refactor） | マイクロサービス化・サーバーレス化など抜本的な再設計 | 長期的なメリットが最大 | コストと時間が最もかかる |
Section 5：Google Cloud のセキュリティと信頼（約17%）
Section 5はクラウドセキュリティの基礎概念と、Google Cloudのセキュリティサービスを問うセクションです。
5-1. クラウドセキュリティの基礎概念
| 概念 | 内容 |
|---|---|
| ゼロトラストセキュリティ | 社内外のネットワークを問わず、すべてのアクセスを信頼せずに検証する次世代のセキュリティ概念 |
| 多層防御（Defense in Depth） | 単一のセキュリティ対策に頼らず、複数の防御レイヤーを重ねることでリスクを低減 |
| 最小権限の原則 | ユーザー・サービスには業務上必要な最小限のアクセス権限のみを付与するルール |
5-2. Google Cloudのセキュリティサービス
IAM（Identity and Access Management）
Google Cloud上のリソースに「誰が」「何を」「できるか」を管理するサービス。CDL試験で最も頻出のセキュリティサービスです。
ここが出る：IAMの3要素
| 要素 | 内容 | 例 |
|---|---|---|
| プリンシパル（誰が） | アクセスする主体 | ユーザー・グループ・サービスアカウント・ドメイン |
| ロール（何を） | 権限のまとまり | 基本ロール・事前定義ロール・カスタムロール |
| ポリシー（許可の設定） | プリンシパルにロールを紐づける設定 | 「このユーザーにStorageAdmin権限を付与」 |
最小権限の実践：基本ロール（Owner/Editor/Viewer）は広すぎるため、本番環境では事前定義ロールやカスタムロールを使うのがベストプラクティス。
その他のセキュリティサービス
| サービス | 役割 |
|---|---|
| Cloud Armor | DDoS攻撃・Webアプリ攻撃（SQLインジェクション・XSSなど）からアプリを守るWAF。Cloud Load Balancingと統合して動作 |
| Security Command Center | Google Cloudのリソース全体のセキュリティ状況を一元監視。脆弱性・設定ミス・脅威を検出・可視化 |
| Chrome Enterprise Premium | ゼロトラストアクセスソリューション。Google の世界水準の脅威インテリジェンス、セキュリティ機能、Google の安全なグローバル ネットワークを介したゼロトラスト アクセスの恩恵を得ることができる |
| Chronicle | セキュリティアナリティクス・SIEMプラットフォーム。大量のセキュリティログを高速に検索・分析 |
5-3. コンプライアンスとデータ保護
データ主権（Data Sovereignty）
データを特定の国・地域内に保存・処理しなければならない法的要件。Google Cloudはリージョン指定でデータの保存場所を制御できます。
ここが出る：コンプライアンス問題
- 「データをEU域内にのみ保存したい」→ リージョンを europe-west 系に限定
- 「データの暗号化を自社で管理したい」→ Cloud KMS（Key Management Service）または CMEK
Section 6：Google Cloud オペレーションによるスケール（約17%）
Section 6は「クラウドをどう運用・管理するか」と「コスト最適化」を問うセクションです。ビジネス寄りの問題が多いセクションです。
6-1. 財務ガバナンスとコスト管理
TCO（総保有コスト）の比較
ここが出る：オンプレミスの隠れたコストを見落とさないことが重要
オンプレミスの見えにくいコスト：ハードウェア購入費・電気代・冷却費・施設費・運用人件費・廃棄費用
クラウドに移行すると：上記がすべてOPEX（運用費）に変わり、使った分だけ支払うモデルになる
Google Cloudのコスト削減手段
| 割引種別 | 内容 | 最適なワークロード |
|---|---|---|
| 確約利用割引（Committed Use Discounts） | 1年または3年の使用量を事前コミットで最大70%割引 | 使用量が予測できる安定したワークロード |
| 継続利用割引（Sustained Use Discounts） | 月の一定時間以上VMを使い続けると自動適用 | 常時稼働のVM（手動設定不要） |
| スポット VM（旧プリエンプティブルVM） | 通常の60〜91%引き。中断される可能性あり | バッチ処理・HPC・CI/CDなど中断してもよいワークロード |
ここが出る：割引の使い分け
- 安定した予測可能なワークロード → 確約利用割引
- 中断可能なバッチ処理 → スポット VM
- 特に設定しなくても自動で節約 → 継続利用割引
6-2. 運用ツール（Google Cloud Observability）
| サービス | 役割 | 典型的なユースケース |
|---|---|---|
| Cloud Monitoring | メトリクス収集・可視化・アラート設定。SLO管理 | CPU使用率の監視・アラート通知 |
| Cloud Logging | アプリとインフラのログを一元収集・保存・検索 | 監査ログの保管・障害調査 |
| Cloud Trace | 分散サービス間のレイテンシを追跡 | マイクロサービスのボトルネック特定 |
| Cloud Profiler | 本番アプリのCPU・メモリ使用量をリアルタイム分析 | コードのパフォーマンス最適化 |
| Error Reporting | アプリのエラーを自動集計して優先順位とともに表示 | エラーの早期検知と対応 |
ここが出る：ツールの役割対応
- 「サービスの応答時間が遅い原因を調べたい」→ Cloud Trace
- 「エラーログをリアルタイムに監視したい」→ Cloud Logging + Cloud Monitoring
- 「コードのどの処理がCPUを食っているか調べたい」→ Cloud Profiler
6-3. SREとオペレーションの考え方
SRE（Site Reliability Engineering）
Googleが生み出した、ソフトウェアエンジニアリングの手法を運用（Ops）に適用するアプローチ。ヒューマンエラーを減らし、信頼性を高めることを目的とします。
| 用語 | 内容 | 例 |
|---|---|---|
| SLI（サービスレベル指標） | 信頼性を測る指標 | リクエスト成功率・レイテンシ |
| SLO（サービスレベル目標） | SLIの目標値 | 成功率99.9%以上 |
| SLA（サービスレベルアグリーメント） | サービスが守ることを約束した外部向けの契約。SLOより緩めに設定 | 成功率99.5%保証 |
エラーバジェット：SLOの「許容できる障害の余裕」のこと。エラーバジェットが残っている間は新機能リリースを優先し、使い果たしたら信頼性改善を優先するというルールで、開発とSREのバランスを取ります。
サービス横断 比較チートシート
試験直前30分チェックリスト
Section 1（約17%）確認項目
- クラウドの6つのメリットを理由とともに言える
- パブリック / プライベート / ハイブリッド / マルチクラウドの使い分け条件を言える
- IaaS / PaaS / SaaSそれぞれのユーザー責任範囲の違いを説明できる
- データの保護・分類はどのモデルでもユーザー責任と覚えている
Section 2（約16%）確認項目
- Cloud Storageの4クラス（Standard / Nearline / Coldline / Archive）と使い分けが言える
- BigQueryの強み（サーバーレス・列指向・BigQuery ML・BigQuery Omni）を言える
- データパイプラインの典型パターン（Pub/Sub → Dataflow → BigQuery）を言える
- Cloud SQL（中小規模）とCloud Spanner（グローバル・大規模）の使い分けを言える
Section 3（約16%）確認項目
- AIサービス3層（事前トレーニング済みAPI / AutoML / Vertex AI）の使い分け基準を言える
- BigQuery MLの特徴（SQLだけでML）を言える
- 説明可能なAIと責任あるAIの概念を説明できる
Section 4（約17%）確認項目
- コンピュートオプション5種の使い分け（CE / GKE / Cloud Run / App Engine / Cloud Functions）を言える
- リフト&シフト / コンテナ化 / クラウドネイティブ再設計の違いを説明できる
Section 5（約17%）確認項目
- IAMのプリンシパル・ロール・ポリシーの3要素を説明できる
- 最小権限の原則と基本ロールを本番で使わない理由を言える
- Cloud Armor・Security Command Center・BeyondCorpの役割を言える
- データ主権（Data Sovereignty）の意味を説明できる
Section 6（約17%）確認項目
- 確約利用割引 / 継続利用割引 / スポットVMの使い分けを言える
- SLI / SLO / SLAの違いを一言で説明できる
- Cloud Monitoring・Cloud Logging・Cloud Traceの役割の違いを言える
- エラーバジェットの概念を説明できる
まとめ
CDL試験は「クラウドとGoogle Cloudの価値を理解しているか」を問う資格です。暗記より「なぜそうなるか」の理解が合否を分けます。
この記事で最終確認を終えたら、あとは試験に集中するだけです。ぜひ合格してください。
関連記事