Cloud Digital Leader · Section 1

デジタルトランスフォーメーションと Google Cloud

クラウドの本質的概念・DX の意味・Google Cloud の強みを体系的に理解する

出題比率 約17%最重要セクションビジネス視点の理解
00

完全攻略ガイド（初学者向け・ステップバイステップ解説）

対象読者: クラウド初学者・非技術系ビジネスリーダー
試験配点: Section 1 は全体の約 17% を占める最重要セクション
学習目標: クラウドの本質的概念・DX の意味・Google Cloud の強みを理解する

01

Section 1 の出題範囲と学習ポイント

試験における Section 1 の位置づけ

1.1出題範囲

Google Cloud Digital Leader（CDL）試験の Section 1 は「デジタルトランスフォーメーションと Google Cloud」がテーマです。
この Section で問われるのは技術的な実装能力ではなく、以下のビジネス視点での理解です。
試験で問われること:
試験で問われること: ①クラウドの必要性 ②基本概念 ③最適戦略 ④Google Cloud の差別化 ⑤DX推進① クラウドがなぜ必要か（ビジネス的意義）② クラウドの基本概念を正確に理解しているか③ 自社の状況に最適なクラウド戦略を選べるか④ Google Cloud が他社と何が違うか / ⑤ DXをどう進めるか
1.2 Section 1 のサブトピック一覧
#サブトピック重要度
1デジタルトランスフォーメーション（DX）の定義と必要性★★★
2クラウドコンピューティングの 5 つの本質的特性★★★
3IaaS / PaaS / SaaS の違いと選択基準★★★
4パブリック / プライベート / ハイブリッド / マルチクラウド★★★
5CapEx と OpEx の違い★★★
6クラウド移行戦略（6R）★★★
7Google Cloud の独自の強み★★★
8Google Cloud のグローバルインフラ（リージョン・ゾーン）★★★
9Google Cloud のリソース階層★★☆
10DX 実現のための主要サービス概要★★☆
02

なぜ今クラウドなのか？デジタルトランスフォーメーションの本質

デジタルトランスフォーメーション（DX）とは / クラウドが必要な理由

2.1デジタルトランスフォーメーション（DX）とは？

デジタルトランスフォーメーション（DX）とは、デジタル技術を活用してビジネスモデル・プロセス・文化・顧客体験を根本的に変革し、競争優位を確立することです。
⚠️ よくある誤解: DX は「IT システムを刷新すること」ではありません。技術はあくまで手段であり、ビジネスそのものを変革することが本質です。
DX の 3 つのレベル
DXの3つのレベルレベル 3: ビジネスモデル変革（本当の DX）新しい収益モデル・市場の創出 (例: 製品販売 → サービス課金)レベル 2: プロセス変革既存業務フローの根本的な再設計 (例: 手動処理 → AI/IoT自動化)レベル 1: デジタル化（Digitization）アナログ → デジタルへの単純変換 (※これだけでは DX とは言えない)

2.2 なぜ今クラウドが必要なのか？

従来のオンプレミス環境が抱える 5 つの課題

課題説明ビジネスへの影響
スピードの遅さ新サーバー調達に数週間〜数ヶ月かかる市場機会を逃す
過剰投資リスク最大負荷を想定した設備投資が必要普段は遊休リソースが発生
スケールの限界急激な需要増に対応できないサービス停止・機会損失
高い維持費用ハードウェアの保守・更新が必要変動しない固定費
イノベーションの遅れ新技術の導入に時間とコストがかかる競合に後れを取る

クラウドが解決できること

オンプレミス対クラウド比較課題: 「新しいサービスを来週リリースしたい」オンプレミスクラウドサーバー発注 (2週間)設置・設定・テスト (2週間)リリース (4〜6週間後)コンソールでクリック (数分)テスト開始 (即日)リリース (数日後)

2.3 クラウドが DX を加速する 3 つのメカニズム

クラウドがDXを加速するメカニズムメカニズム 1: スピードと俊敏性・インフラを数分で調達 → 実験・検証サイクルを高速化・失敗しても損失が少ない → 積極的なイノベーションが可能メカニズム 2: データとインテリジェンスの活用・大量データを安価に保存・分析 / AI・MLを追加投資なしに利用・リアルタイムで顧客の行動を把握し意思決定メカニズム 3: コスト構造の最適化・固定費（CapEx）→ 変動費（OpEx）へ転換（使った分だけ支払う）・節約したコストをイノベーションに再投資

📎 参照: Google Cloud が考える DX
https://cloud.google.com/solutions/smart-analytics
https://cloud.google.com/transform

03

クラウドコンピューティングの基礎概念

NIST が定義するクラウドの 5 つの本質的特性

3.1クラウドコンピューティングの定義

クラウドコンピューティングとは、インターネット（クラウド）を通じて、コンピューティングリソース（サーバー・ストレージ・データベース・ネットワーク・ソフトウェア・分析・インテリジェンス）をオンデマンドで提供するサービスモデルです。
📌 ポイント：「クラウド」という名前の由来
昔のネットワーク図では、インターネットを
「雲（クラウド）☁️」の記号で表していました。
その「雲の向こう側」でコンピューティングを行うことから
「クラウドコンピューティング」と呼ばれます。
3.2 NIST が定義するクラウドの 5 つの本質的特性

NIST（米国国立標準技術研究所）が定めた、クラウドの必須要件です。試験では「これはクラウドの特性か？」を判断する問題が出ます。

特性 ① オンデマンド・セルフサービス（On-demand Self-service）
意味: 人間（ベンダー担当者）の介入なしに、
      必要な時に必要なリソースを自動的に調達できる。

具体例:
  - Google Cloud Console でボタンを押すだけで VM が起動
  - API 呼び出しで自動的にサーバーが増設される
  - クレジットカードがあれば今すぐ使い始められる

ビジネス価値: IT 部門への申請・承認待ち時間がゼロ
特性 ② 幅広いネットワークアクセス（Broad Network Access）
意味: 標準的なネットワーク（インターネット）を通じて、
      様々なデバイスからアクセス可能。

具体例:
  - スマートフォン・タブレット・PC・どこからでもアクセス
  - 自宅・オフィス・カフェ・世界中どこでも同じ環境
  - 特殊なソフトウェアやプロトコル不要

ビジネス価値: 場所・端末に縛られない働き方の実現（リモートワーク対応）
特性 ③ リソースのプーリング（Resource Pooling）
意味: 複数のユーザーが物理リソースを共有する
      マルチテナント型のモデル。ユーザーは
      物理的な場所を気にする必要がない。

具体例:
  - 世界中の顧客が Google のデータセンターを共有使用
  - 顧客ごとに仮想的に分離された環境を提供
  - 物理サーバーの場所はユーザーが指定できない
    （リージョンは選べる）

ビジネス価値: 規模の経済によるコスト削減
特性 ④ 迅速な弾力性（Rapid Elasticity）
意味: 需要に応じて自動的にリソースを増減（スケール）できる。
      ユーザーからは「無限にリソースがある」ように見える。

具体例:
  - EC サイトがセール時に自動でサーバーを 10 倍に増設
  - 深夜の閑散時間にはサーバーを自動縮小
  - 需要に応じて数分以内にスケールアップ/ダウン

ビジネス価値: 急なアクセス増でもサービス停止なし
             かつ普段は無駄なコストをかけない
特性 ⑤ 計測されたサービス（Measured Service）
意味: リソースの使用量を自動的に計測し、
      使った分だけ課金される従量制モデル。

具体例:
  - VM を 1 時間使えば 1 時間分だけ課金
  - ストレージを 100GB 使えば 100GB 分だけ課金
  - 使用量はリアルタイムで可視化・監視できる

ビジネス価値: 無駄なコストがなく、透明性の高い費用管理が可能
✅ ベストプラクティス: 5 つの特性の活用
俊敏性の最大化:
  - プロトタイプは「まず小さく始める」
  - 本番移行前に低コストで実験・検証する
  - 失敗しても損失を最小化できる

弾力性の活用:
  - 自動スケーリングポリシーを設定する
  - 負荷テストで最大容量を事前に確認する
  - スケールダウンルールも忘れずに設定する

コスト透明性の確保:
  - ラベル（タグ）でリソースをチーム・プロジェクト別に分類
  - 予算アラートを必ず設定する
  - Cloud Billing レポートで定期的に使用量を確認する

📎 参照: NIST クラウドコンピューティングの定義
https://csrc.nist.gov/publications/detail/sp/800-145/final
https://cloud.google.com/learn/what-is-cloud-computing

04

クラウドサービスモデル

IaaS / PaaS / SaaS の責任分界点

4.1サービスモデルの全体像

クラウドサービスは「どこまで Google が管理してくれるか」によって 3 つに分類されます。
責任の分担
サービスモデルごとの責任分界点オンプレミスIaaSPaaSSaaSアプリ自社自社自社Googleデータ自社自社自社Googleランタイム自社自社GoogleGoogleミドルウェア自社自社GoogleGoogleOS自社自社GoogleGoogle仮想化自社GoogleGoogleGoogleインフラ自社GoogleGoogleGoogleユーザー管理負荷最大中小最小

4.2 IaaS（Infrastructure as a Service）

定義: 仮想マシン・ストレージ・ネットワークなどのインフラ基盤をサービスとして提供するモデル。ユーザーは OS・ミドルウェア・アプリを自分で管理します。

特徴とメリット・デメリット

項目内容
柔軟性OS・ミドルウェア・アプリを自由に選択・設定できる
制御性インフラを細かく制御できる
移植性オンプレの環境をほぼそのままクラウドへ移行できる
デメリットOS パッチ・セキュリティ設定・スケーリング設定を自分で行う必要がある

Google Cloud でのサービス例

サービス説明
Compute Engine仮想マシン（VM）。OS を選んでサーバーを起動
Cloud Storageオブジェクトストレージ。ファイルを保存・配信
Virtual Private Cloud（VPC）仮想ネットワーク環境
Persistent DiskVM にアタッチできるブロックストレージ

4.3 PaaS（Platform as a Service）

定義: アプリケーションの開発・実行・管理に必要なプラットフォーム（実行環境）をサービスとして提供するモデル。ユーザーはアプリとデータだけに集中できます。

特徴とメリット・デメリット

項目内容
開発生産性インフラを意識せずにコードを書くだけでいい
自動スケールトラフィックに応じて自動でスケール
運用負荷OS パッチ・インフラ設定は Google が担当
デメリット特定の言語・フレームワーク・設定に制約がある場合がある

Google Cloud でのサービス例

サービス説明
App EngineWeb アプリを「コードをアップロードするだけ」で実行
Cloud Runコンテナ化されたアプリをサーバーレスで実行
Cloud Functionsイベントで実行される小さな関数
BigQueryサーバーレスのデータウェアハウス
Cloud SQLフルマネージドのリレーショナルデータベース

4.4 SaaS（Software as a Service）

定義: 完全に構築されたソフトウェアをサービスとして提供するモデル。インターネット接続とブラウザがあれば、インストールなしに即座に使えます。

特徴とメリット・デメリット

項目内容
導入の速さサインアップすれば即日使い始められる
管理不要更新・バックアップ・セキュリティパッチはベンダーが担当
アクセス性デバイス・場所を問わずアクセス可能
デメリットカスタマイズの自由度が低い・データがベンダー側にある

Google Cloud でのサービス例

サービス説明
Google WorkspaceGmail・Docs・Sheets・Slides・Meet・Drive のスイート
Google Maps Platform地図・ルート検索・場所情報 API
LookerBI（ビジネスインテリジェンス）プラットフォーム
Chronicleセキュリティ情報・イベント管理（SIEM）

📎 参照: Google Cloud のサービスモデル解説
https://cloud.google.com/learn/what-is-iaas
https://cloud.google.com/learn/what-is-paas
https://cloud.google.com/learn/what-is-saas

05

クラウドデプロイメントモデル

パブリック / プライベート / ハイブリッド / マルチクラウドの選択基準

5.1デプロイメントモデルの概要

クラウドを「どこに・どのように展開するか」を定義したモデルです。
4 つのデプロイメントモデル
5.2 デプロイメントモデルの比較
比較項目パブリックプライベートハイブリッドマルチ
初期コスト低高中〜高中
運用コスト変動（従量）固定（高）中変動
スケーラビリティ非常に高物理的限界あり中〜高高
セキュリティ制御Google 依存完全自社分散分散
データ主権低〜中高高中
管理の複雑さ低高高非常に高

📎 参照:
https://cloud.google.com/learn/what-is-hybrid-cloud
https://cloud.google.com/learn/what-is-multicloud

06

CapEx vs OpEx ─ コスト構造の根本的変化

オンプレミスの資本支出からクラウドの運用経費への転換

6.1CapEx と OpEx

比較詳細
比較項目CapEx（オンプレ）OpEx（クラウド）
支払い方法先払い（一括または分割）後払い（月次・従量課金）
財務上の分類資産（バランスシート）費用（損益計算書）
費用計上方法減価償却（数年かけて）発生した月に全額計上
初期コスト非常に高いほぼゼロ
スケール対応困難（事前に大量購入必要）容易（必要な分だけ増減）
技術の陳腐化数年で陳腐化・買い替え必要常に最新技術を利用可能
リスク需要予測が外れると過剰・不足実需に合わせて調整可能
財務計画立てやすい（固定費）変動するが予測ツールあり
財務上の変化
07

クラウドへの移行戦略（6 つの R）

Rehost / Replatform / Repurchase / Refactor / Retire / Retain

7.1戦略の比較

戦略変更規模スピードコストリスククラウド活用度
Rehost最小最速低低低
Replatform小〜中速い低〜中低〜中中
Repurchase中中中中高（SaaS）
Refactor最大最も遅い高高最高
Retire—即座なしなし—
Retainなし—なしなしなし
08

Google Cloud の独自の強みと差別化

グローバルネットワーク・AI/ML・サステナビリティ

8.1強みまとめ

強みキーワード
グローバルネットワーク専用ネットワーク・海底ケーブル・低レイテンシ
AI/ML の優位性TPU・Vertex AI・Gemini・10年以上の実績
セキュリティゼロトラスト・BeyondCorp・Titan チップ
データ分析BigQuery・サーバーレス・ペタバイト規模
オープン性Kubernetes・TensorFlow・ベンダーロックイン回避
サステナビリティカーボンニュートラル・再生可能エネルギー
信頼性99.999% SLA・大規模サービスの運用実績
09

Google Cloud のグローバルインフラ

リージョン / ゾーン / エッジネットワーク

9.1インフラ構造

10

Google Cloud のサービス階層とリソース管理

組織 / フォルダ / プロジェクト / リソース

10.1リソース階層

Google Cloud リソース階層（組織 → フォルダ → プロジェクト → リソース）組織 (Organization)フォルダ (Folder)プロジェクト (Project)
11

DX 実現のための Google Cloud ソリューション

インフラ / データ / AI / 生産性向上

11.1ソリューション一覧

課題ソリューション効果
業務効率化Google Workspace + Geminiメール・文書作成を AI が支援
顧客サービス向上Dialogflow・Contact Center AI24h AI チャットボット対応
データ活用BigQuery + Lookerデータドリブン意思決定の実現
EC 売上向上Recommendations AI個別化されたレコメンデーション
製造業の品質改善Vision AI + AutoML製品不良の自動検出
人材・採用Cloud Talent Solution求人検索・採用マッチングの AI 最適化
コスト削減Cloud Run + BigQueryサーバーレスで ITコスト最小化
12

Section 1 総まとめ・頻出問題パターン

まとめとチェックリスト

12.1学習チェックリスト

混同パターン正しい理解
DX = デジタル化DX はビジネス変革が本質。単なるデジタル化（紙→PDF）は DX ではない
クラウド = 安いクラウドは必ずしも安くない。設計次第でオンプレより高くなることも
SaaS = カスタマイズ自由SaaS はカスタマイズ自由度が低い。柔軟性が必要なら PaaS や IaaS
ハイブリッド = マルチクラウドハイブリッド=オンプレ+クラウド / マルチ=複数クラウドベンダー
リージョン = ゾーンリージョン（地域）の中に複数のゾーン（DC）がある
弾力性 = スケールアップのみ弾力性はスケールアップ（増加）もスケールダウン（縮小）も含む
Rehost = 最良の移行Rehost は最速だが、クラウドの恩恵は最小。Refactor がベスト
CapEx = 悪いCapEx/OpEx はどちらが良い/悪いではない。財務戦略次第
13

完全網羅レポート

詳細解説

13.1比較レポート

比較項目オンプレミスクラウド
インフラの所在と運用自社の施設（データセンター）内に物理ハードウェアとソフトウェアを配置し、自社の人員で運用・保守を行う。プロバイダのデータセンターに配置された仮想化リソースをインターネット経由で利用する。
拡張のスピードと柔軟性新しいサーバーの調達、ネットワークの設定、ソフトウェアのインストールに数週間から数ヶ月を要する。数クリックまたはAPI経由で、数秒から数分で世界中にリソースを展開・縮小できる。
メンテナンスとパッチ管理自社のIT部門がハードウェアの故障対応からOSのセキュリティパッチ適用まで全責任を負う。物理ハードウェアの保守はプロバイダが行い、サービスモデルによってはOS以上のパッチ管理も自動化される。
初期投資と財務モデル膨大な事前の設備投資（CapEx）が必要であり、ハードウェアの減価償却に数年縛られる。初期投資は不要であり、使用したリソース分のみを支払う運用経費（OpEx）モデルとなる。
14

公式参照リソース一覧

リンク集

14.1参照リソース

タイトルURL
Cloud Digital Leader - Certification exam guidehttps://cloud.google.com/learn/certification/guides/cloud-digital-leader
15分で合格する Cloud Digital Leaderhttps://qiita.com/kyo2bay/items/33a74d36b7abf841a2e2
クラウド費用の最適化: 成功し続けるための諸原則https://cloud.google.com/blog/ja/products/gcp/cost-managementprinciples-of-cloud-cost-optimization
Google Cloud Digital Leader Training Professional Certificatehttps://www.coursera.org/professional-certificates/google-cloud-digital-leader-training
クラウド コンピューティングに関する運命共有モデルhttps://cloud.google.com/security/shared-fate?hl=ja
Startup Whitepaperhttps://cloud.google.com/resources/startup-guide?hl=ja
Google CloudのCAFをまとめてみたhttps://zenn.dev/yellowman/articles/fe79e2e58449eb
Google Cloud Digital Leader Learning Pathhttps://medium.com/@aserdargun/google-cloud-digital-leader-learning-path-0b45fb756a04
グローバル ロケーション - リージョンとゾーンhttps://cloud.google.com/about/locations?hl=ja
「リージョン」「ゾーン」とは何？https://cloud-ace.jp/column/detail208/
地域とリージョンhttps://docs.cloud.google.com/docs/geography-and-regions?hl=ja
Shared responsibility in Assured Workloadshttps://docs.cloud.google.com/assured-workloads/docs/shared-responsibility
Simplifying the shared responsibility modelhttps://www.datadoghq.com/blog/shared-responsibility-model/
Shared responsibilities and shared fate on Google Cloudhttps://docs.cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate
9つのGoogle Cloudセキュリティベストプラクティスhttps://www.sentinelone.com/ja/cybersecurity-101/cloud-security/google-cloud-security-best-practices/
24の Google Cloud Platform（GCP）セキュリティベストプラクティスhttps://www.sysdig.com/jp/learn-cloud-native/24-google-cloud-platform-gcp-security-best-practices
Google Cloud ランディング ゾーンのリソース階層を決定するhttps://docs.cloud.google.com/architecture/landing-zones/decide-resource-hierarchy?hl=ja
リソース階層を使用したアクセス制御https://docs.cloud.google.com/iam/docs/resource-hierarchy-access-control?hl=ja
Google Cloud Digital Leader Exam Guide (2026)https://cloudfluently.com/blog/google-cloud-digital-leader-exam-guide-2026