Cloud Digital Leader 完全攻略① — 試験概要と「変革・データ・AI」前半3領域

Cloud Digital Leader は、Google Cloud が用意する唯一の Foundational 認定であり、技術者でなくてもクラウド活用の意思決定に参加するための「共通言語」を証明する資格だ。本記事は Cloud Digital Leader の試験全体像を押さえたうえで、出題 6 領域のうち前半 3 領域 — デジタル変革、データ、AI — を、公式試験ガイドの論点に沿って攻略する。配点にして約 49% を占める、得点の土台となる範囲だ。

GCP 認定全体のロードマップはGoogle Cloud 認定 入門 2026（2026-06-22 公開）で示した。本記事はそこから一歩進み、最初の 1 枚である Cloud Digital Leader の中身に踏み込む。

Cloud Digital Leader 試験の全体像 — 6 領域と配点

まず試験仕様を確認する。AWS の認定と異なり、合格スコアが非公表である点を前提に計画を立てたい。

出題は 6 つのセクションで構成され、公式試験ガイドが示す配点は次の通りだ。

• Section 1 デジタル変革（約 17%）
• Section 2 データ変革（約 16%）
• Section 3 AI による革新（約 16%）
• Section 4 インフラとアプリの近代化（約 17%）
• Section 5 信頼性とセキュリティ（約 17%）
• Section 6 運用によるスケーリング（約 17%）

6 領域がほぼ均等に配点されているのが特徴だ。AWS のように配点の大きいドメインへ重点投資する戦い方は通用しにくく、全領域を満遍なく仕上げる必要がある。本記事は前半の Section 1〜3（合計約 49%）を扱い、後半の Section 4〜6 は続編で攻略する。

時間配分の感覚も先に持っておきたい。90 分で 50〜60 問なので、1 問あたり 1.5〜1.8 分が目安になる。CDL の設問は技術試験のような長文シナリオが少なく、用語の定義や「このケースに最適なのはどれか」を問う短めの設問が中心だ。読解で時間を溶かす場面は少ないため、迷った問題に見直しフラグを立てて先に進めば、時間切れの心配はまず生じない。なお現行版の試験ガイドは 2026 年 7 月 28 日まで有効で、その後は新版へ切り替わる。受験を急ぐなら現行版の範囲で固めるのが安全だ。

補足すると、Cloud Digital Leader は技術職だけの資格ではない。むしろ Google が想定する主な受験者は、エンジニアと協働する企画・営業・管理職など、クラウド導入の意思決定に関わる非技術職だ。AWS 認定で技術的な土台を持つ読者にとっては、この「ビジネス側の語彙」を補強する 1 枚として機能する。技術とビジネスの両方の言葉を話せることが、マルチクラウド時代の橋渡し役としての価値を高める。

Section 1 — デジタル変革とクラウドの基礎（約 17%）

Section 1 は「なぜクラウドがビジネスを変えるのか」を問う領域だ。まず押さえるべきは用語の定義である。クラウド、クラウドネイティブ、オープンソース、オープンスタンダードといった言葉を、自分の言葉で説明できる状態にしておく。そのうえで、オンプレミスと比べたクラウドの利点 — スケーラビリティ、柔軟性、俊敏性、セキュリティ、コスト効率、戦略的価値 — を、具体的なビジネス事例に当てはめて語れるかが問われる。

Google Cloud が掲げるビジネス変革の便益も出題対象だ。公式ガイドは、インテリジェンス、自由、コラボレーション、信頼、サステナビリティの 5 つを Google Cloud の主要な変革価値として挙げている。さらに「トランスフォーメーションクラウド」という考え方 — アプリとインフラの近代化、データの民主化、人のつながり、信頼できる取引の 4 本柱で変革を加速する — も理解しておきたい。新しい技術を採用しない組織が直面するリスク、そして変革を促すドライバーと課題を説明できることが、この領域のゴールだ。AWS の Cloud Practitioner で学んだ内容とほぼ重なるため、AWS 有資格者には復習感覚で進められる領域でもある。

財務面の論点も外せない。クラウドへの移行は、初期投資である資本的支出（CapEx）を、使った分だけ払う運用的支出（OpEx）へと転換する。この転換が総保有コスト（TCO）にどう影響するかは、頻出の出題ポイントだ。あわせて、リージョンとゾーン、ISP、DNS、帯域幅、レイテンシといった基本的なネットワーク用語も定義レベルで問われる。Google Cloud がグローバルなインフラと高速ネットワークでデジタル変革を支える、という文脈で理解しておきたい。

ネットワーク用語は丸暗記ではなく、「なぜグローバルなインフラが変革を支えるのか」という文脈で押さえると忘れにくい。たとえばレイテンシは、利用者の近くにデータセンターがあるほど小さくなり、それが顧客体験の良し悪しに直結する。リージョンとゾーンの違いも、可用性と災害対策という事業継続の文脈で理解すれば、後半で扱う運用領域の学習にもそのまま効いてくる。

IaaS / PaaS / SaaS と責任共有モデル — Section 1 の核心

Section 1 の中でも、クラウドの 3 つの提供モデルと責任共有モデルは確実に得点したい論点だ。

ポイントは、モデルが上（SaaS）に行くほど利用者の管理範囲が狭まり、運用負担が軽くなる一方、カスタマイズの自由度が下がるというトレードオフだ。試験では「この業務シナリオならどのモデルが最適か」を選ばせる形で問われる。たとえば、自社で OS レベルの細かな制御が必要なら IaaS、アプリ開発だけに集中したいなら PaaS、メールや会計のような完成サービスを使いたいだけなら SaaS、という対応を要件から逆引きできるようにしておく。

責任共有モデルも頻出だ。クラウドプロバイダーが負う責任と、利用者が負う責任の境界線が、IaaS・PaaS・SaaS のどのモデルかによって動く。AWS の責任共有モデルを理解していれば、Google Cloud でも考え方は同じだ。プロバイダーは「クラウドそのもののセキュリティ」を、利用者は「クラウドの中のセキュリティ」を担う、という基本構造を押さえておけばよい。SaaS に近づくほどプロバイダー側の責任範囲が広がり、IaaS に近づくほど利用者の責任が増える、という動き方も併せて覚えておくと、境界線を問う設問で迷わない。

Section 2 — データを価値に変える（約 16%）

Section 2 は、Google Cloud のデータ製品群を扱う、この会社らしさが最も濃い領域だ。出発点は「データの価値」の理解である。データの保管庫であるデータベース、分析向けに整えたデータウェアハウス、生データを大量に貯めるデータレイクの違いを区別し、構造化データだけでなく、これまで活用されてこなかった非構造化データからも価値を引き出せる、というクラウドの強みを説明できるようにする。

データそのものの扱い方も問われる。組織は、既存データの活用、新規データの収集、外部データの調達という 3 つの方法で価値を生み出せる。そして、データが価値に変わるまでの一連の流れ（データバリューチェーン）と、その全工程を支えるデータガバナンスの重要性も理解しておきたい。ガバナンスが欠けたデータ活用は、品質やコンプライアンスの面で破綻しやすい、という文脈が問われる。

中心となるのは、データ管理製品の使い分けだ。Google Cloud は用途別に複数の製品を持つ。リレーショナルかどうか、グローバル分散が必要か、分析用途かトランザクション用途かで選択肢が変わる。とりわけ BigQuery は、サーバーレスのマネージドデータウェアハウス兼分析エンジンとして位置づけられ、マルチクラウド環境でも使える点が強調される。AWS の Redshift に役割は近いが、クラスタの事前確保が要らず、スキャンしたデータ量に応じて課金される設計思想の違いを押さえておきたい。既存データベースをクラウドへ移行・近代化する方法が複数ある点も、出題範囲に含まれる。

ストレージのコスト最適化も出る。Cloud Storage には Standard、Nearline、Coldline、Archive の 4 つのストレージクラスがあり、アクセス頻度とコストのトレードオフで使い分ける。頻繁にアクセスするデータは Standard、めったに触らないアーカイブは Archive、という対応は AWS の S3 ストレージクラスと同じ発想だ。

データを「使える」状態にする論点では、Looker が登場する。Looker は BI（ビジネスインテリジェンス）を民主化し、個人が自分でデータを探索してインサイトを得られるようにするツールだ。BigQuery のデータを Looker で可視化し、リアルタイムのレポートやダッシュボードを作る流れが問われる。さらに、リアルタイムのストリーミング分析を支えるデータパイプライン製品として、Pub/Sub と Dataflow が挙げられる。Pub/Sub がメッセージの受け渡しを担い、Dataflow がそのデータを変換・処理する、という役割分担をイメージできると理解が深まる。

これらのデータ製品群を貫くのは、「使った分だけ」「専門家がいなくても」という、データ活用の民主化という思想だ。かつては大規模なインフラ投資と専門チームが必要だった分析が、サーバーレスのサービスとセルフサービス BI によって、より多くの人の手に届くようになった。CDL のデータ領域は、個々の製品名よりも、この変化が事業にもたらす意味を問うていると理解しておきたい。

GCP データ管理製品の早見表

前半最大の暗記ポイントが、データ製品の使い分けだ。役割で対応づけて覚えると、選択肢を絞る問題で迷わなくなる。

この表を頭に入れたうえで、「グローバルに一貫性が必要ならば Spanner」「とにかく分析ならば BigQuery」「モバイルアプリの裏側ならば Firestore」というように、要件のキーワードから製品を逆引きできる状態を目指したい。実際の設問は製品名を直接問うより、業務シナリオを読ませて最適な製品を選ばせる形が多いため、種別と用途をワンセットで結びつけておくことが得点に直結する。

Section 3 — AI/ML は「3 つの選択肢」で覚える（約 16%）

Section 3 は、Google Cloud の AI/ML を扱う。技術的な実装ではなく、ビジネス価値の観点から「どの選択肢を選ぶか」が問われる。まず AI と ML の基礎として、両者の定義、データ分析や BI との違い、ML が解ける問題の種類を押さえる。ML が生むビジネス価値 — 大規模データの活用、意思決定のスケール、非構造化データの解放 — を説明できることも求められる。そして、高品質で正確なデータが ML 成功の前提であること、説明可能で責任ある AI が重要であることが、繰り返し問われる論点だ。AI を導入する以上、その判断根拠を説明できる透明性と、偏りや誤用を防ぐ責任ある運用が欠かせない、という姿勢が問われる。

責任ある AI が配点に含まれること自体が、Google の AI に対する立場を物語る。精度の高いモデルを作れるかどうかだけでなく、その判断を人間が説明でき、偏りや差別を生まないかを問う。実務でも、AI 導入の可否はしばしば技術的な精度ではなく、この説明責任とガバナンスの設計で決まる。CDL はその視点を基礎レベルで植え付ける試験だと捉えると、出題の意図が腑に落ちる。

核心は、AI/ML ソリューションの 3 つの選択肢だ。スピード、労力、差別化、必要な専門性というトレードオフで、次の 3 段階から選ぶ。

• 事前学習済み API（pre-trained API）: 最も速く、専門性も不要。Natural Language API、Vision API、Cloud Translation API、Speech-to-Text API、Text-to-Speech API といった、すぐ使える API 群。
• AutoML: 自社のデータでカスタムモデルを学習させたいが、機械学習の専門家がいない場合の選択肢。
• カスタムモデル: 最大の差別化を狙う場合。Gemini Enterprise Agent Platform（旧 Vertex AI）でゼロから構築する。

この 3 択は「速さ・手軽さ」と「差別化・自由度」のトレードオフそのものだ。標準的な画像認識や翻訳なら事前学習済み API で十分、自社データで独自性を出したいが専門家がいないなら AutoML、最大の差別化が競争力になるならカスタムモデル、という判断を問われる。要件文に出てくる「すぐに」「専門家がいない」「差別化したい」といったキーワードが、そのまま選択の手がかりになる。

加えて、BigQuery ML を覚えておきたい。これは標準 SQL を書くだけで BigQuery 内に ML モデルを作成・実行できる機能で、データアナリストが SQL の延長で機械学習を扱える点が価値だ。基盤技術として、オープンソースの ML ツール群である TensorFlow と、ML 性能に最適化された Google 独自ハードウェアの Cloud TPU も押さえておく。これらは「どう作るか」の細部ではなく、「何のための技術か」を識別できれば十分だ。

AWS の知識で前半 3 領域を最短攻略する

AWS 有資格者であれば、前半 3 領域の多くは「名前の置き換え」で攻略できる。役割で対応づけると学習時間を圧縮できる。

ただし、前述の通り CDL は技術実装ではなくビジネス価値を問う試験だ。「どう構築するか」ではなく「なぜそれを選ぶと事業が前進するか」を語れるかが分かれ目になる。AWS で得たサービス知識を、ビジネス文脈に翻訳し直す作業が、この試験特有の準備になる。たとえば「BigQuery はサーバーレスだ」という事実を覚えるだけでなく、「だから初期投資なしに分析を始められ、データ量の増減に追従できる」という事業上の意味まで言語化できると、設問の意図に的確に応えられる。

前半 3 領域のつまずきポイント

最後に、前半で典型的につまずく 3 点を挙げる。

第一に、用語の定義の軽視だ。CDL はビジネス寄りの試験のため、「cloud-native とは」「データレイクとデータウェアハウスの違いは」といった定義問題が地味に効く。サービス名を覚える前に、概念の定義を自分の言葉で言えるようにしておきたい。定義があいまいなまま製品名の暗記に走ると、ひねった選択肢で足をすくわれる。

第二に、データ製品の取り違えだ。Cloud SQL、Spanner、Bigtable、Firestore、BigQuery は役割が重なって見えるため、混同しやすい。早見表の「種別 × 用途」をセットで覚え、要件のキーワードから逆引きする訓練が有効だ。とくに「グローバルな一貫性」という語が出たら Spanner、という反射を作っておくと強い。

第三に、AI 3 択のトレードオフの読み違えだ。「専門家がいない」「すぐ使いたい」「差別化したい」といった要件語から、pre-trained API・AutoML・カスタムモデルのどれを選ぶかを判断する問題は頻出だ。3 択を「速さ ⇄ 差別化」の軸で整理しておけば、迷わず選べる。

まとめ — 前半 3 領域で得点の土台を固める

Cloud Digital Leader は 6 領域がほぼ均等に配点される試験で、前半の Section 1〜3（デジタル変革・データ・AI）だけで約 49% を占める。Section 1 はクラウドの基礎概念と IaaS/PaaS/SaaS・責任共有モデル、Section 2 は BigQuery を中心としたデータ製品の使い分け、Section 3 は pre-trained API・AutoML・カスタムモデルの 3 択 — この骨格を押さえれば、得点の土台は固まる。

AWS で築いた知識の多くはそのまま流用できるが、CDL が問うのは「ビジネス価値の判断」だ。サービス名の暗記を、事業文脈の言葉に翻訳し直す準備を意識してほしい。続編では、後半の Section 4〜6（インフラとアプリの近代化・信頼性とセキュリティ・運用によるスケーリング）を攻略し、Cloud Digital Leader の全体像を完成させる。

学習の進め方としては、まず公式試験ガイドで 6 領域の骨格を把握し、Google Cloud Skills Boost の無償学習パスで肉付けするのが王道だ。前半 3 領域を本記事で押さえたら、模擬問題で定義問題と製品の使い分けを重点的に確認し、8 割の正答率を安定させてから後半へ進むとよい。公式と正規教材だけで合格圏には十分に届くため、実試験問題の転載をうたう dumps サイトには手を出さないこと。

参照

• Cloud Digital Leader（公式試験ページ）
• Cloud Digital Leader 試験ガイド（公式 PDF）
• BigQuery（公式）
• Cloud Storage ストレージクラス（公式）
• Google Cloud 認定 入門 2026（2026-06-22 公開）

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.