本文へスキップ
スキルアップカレッジ

クラウド入門

IT基礎知識 初級 全8レッスン 約200分

公開日:

コース概要

「うちもそろそろクラウドにしないと」「全部 AWS に乗せれば安く済むよ」——会議室でいまも聞こえる言葉です。一方で、クラウドに移行したのにコストが想定の 3 倍に膨らんだ、SaaS を入れすぎて誰がどのデータを管理しているか追えなくなった、という現場の悩みも増えています。クラウドは「特別な技術」ではなく、もはや業務システムの土台です。それでも「クラウドって結局なんですか」を腹落ちさせて説明できる人は、IT 職以外ではほとんど見かけません。本コースは、特別な技術知識のない方でも、IaaS/PaaS/SaaS の階層、主要プロバイダーの特徴、コストとセキュリティの考え方、移行の選択肢を、8 レッスンで体系的に学びます。特定クラウドの操作画面や設定手順には踏み込みません。代わりに、「クラウドという土台の上で意思決定する人」が現場で迷わない発想を、現場の事例と「2026 年 6 月時点の最新動向」を交えて整理します。経営者・事業責任者・情シス以外の管理職・SaaS を業務で使う社員にとって、業務判断の土台になる内容です。

学習の流れ

レッスン 1 でクラウドの定義(NIST の 5 つの本質的特徴)とオンプレミスとの違いを整理します。レッスン 2 は IaaS/PaaS/SaaS の 3 階層と責任分界を「ピザ屋の例え」で腹落ちさせます。レッスン 3 は主要クラウドプロバイダー(AWS・Azure・GCP)と日本の選択肢を 2026 年 6 月時点の市場感を踏まえて整理します。レッスン 4 はクラウドの中核サービス(コンピューティング・ストレージ・ネットワーク・データベース)を 3 社の代表サービス名で対比します。レッスン 5 はコンテナ・サーバーレス・マネージドサービスといった「モダンな実行環境」の位置づけを扱います。レッスン 6 は「クラウドは安い」神話への批判として、FinOps の発想で運用判断する考え方を学びます。レッスン 7 は「責任共有モデル」を中心に、クラウド時代のセキュリティ運用を整理します。最後のレッスン 8 で、クラウド移行の 7R、ハイブリッド・マルチクラウドの現実、2026 年 6 月時点の論点(AI エージェント実行環境、SBOM、PQC)、修了後の学習方向を案内します。前半(レッスン 1〜3)は「土台の発想」、中盤(レッスン 4〜6)は「サービスとコスト」、後半(レッスン 7〜8)は「セキュリティと未来」という三段構えです。

このコースで学べること

  • クラウドの定義(NIST 5 つの本質的特徴)を理解し、オンプレミスとの違いを説明できる
  • IaaS/PaaS/SaaS の階層と責任分界を整理し、業務で扱うサービスがどの階層に属するか判断できる
  • 主要クラウドプロバイダー(AWS/Azure/GCP)の特徴と日本の選択肢を整理できる
  • コンピューティング・ストレージ・ネットワーク・データベースの中核サービスを区別できる
  • コンテナ・サーバーレス・マネージドサービスの位置づけを把握する
  • クラウドのコスト構造を理解し、FinOps の発想で運用判断ができる
  • 責任共有モデルを踏まえ、利用者が守るべき範囲を判断できる
  • クラウド移行の選択肢(7R)、ハイブリッド・マルチクラウドの現実、2026 年時点の論点を整理できる

対象者

業種・職種を問わず、すべての社員にとって必要なクラウドの基礎を身につけたい方。IT 職でなくとも、SaaS を業務で使う方、経営者・事業責任者・情シス以外の管理職にも。情報セキュリティの基礎を学んだ方の次のステップとしても活用できる

講師紹介

山下 美月(やました みづき)

クラウドアーキテクト/元大手クラウド事業者ソリューションアーキテクト

新卒で大手通信キャリアの法人ネットワーク技術部に 3 年従事し、エンタープライズ向け回線・専用線・データセンター案件を担当。その後、外資系大手クラウド事業者の日本法人にソリューションアーキテクトとして転職して 7 年、エンタープライズ部門で製造業・金融・小売の大規模クラウド移行案件を主担当(最後の 3 年はチームリーダー)。2024 年に独立し、現在は中堅 SaaS 企業 4〜5 社のクラウド設計顧問を並行。AWS Certified Solutions Architect Professional・Google Cloud Professional Cloud Architect・Microsoft Certified: Azure Solutions Architect Expert の 3 社主要資格を保持。スタンス:「クラウドはあくまで道具、ビジネス要件から逆算しないと負債になる」「特定クラウドの宗教戦争に乗らず、要件で選ぶ」

受講される方へのメッセージ

「クラウドの世界には、「乗せれば全部解決する」という幻想と、「危ないからオンプレが安全」という反動が、いまも同居しています。現場で見てきたのは、その極論のあいだで揺れて意思決定が止まる組織と、流行で判断した結果コストが想定の数倍に膨らむ案件、そして要件から丁寧に逆算してクラウドを使いこなしている組織でした。本コースは、IT 職でなくとも経営者・事業責任者・現場社員が、クラウドを「土台の道具」として理解し、自分の仕事に引き寄せて判断できる基礎を 8 レッスンで体系的にお伝えします。特定の操作画面や設定手順は登場しません。代わりに、IaaS/PaaS/SaaS という階層の意味、主要プロバイダーの特徴、コストとセキュリティの考え方、移行の選択肢を、現場の事例も交えて丁寧に整理していきましょう」

レッスン一覧

  1. 1

    クラウドとは何か——「コンピューターを借りる」発想の転換

    クラウドコンピューティングの定義、オンプレミスとの違い、NIST の 5 つの本質的特徴、なぜクラウドが普及したのか、本コースの守備範囲を学ぶ

  2. 2

    IaaS/PaaS/SaaS——3 つの提供形態の階層

    IaaS・PaaS・SaaS の違い、責任分界の仕組み、オンプレ・コロケーション・マネージドサービスの位置づけ、FaaS(サーバーレス)の予告を学ぶ

  3. 3

    主要クラウドプロバイダー——AWS・Azure・GCP と日本の選択肢

    AWS・Azure・GCP の特徴とシェア感、Alibaba Cloud・Oracle Cloud、日本のさくら・IDCF・Nifty・NTT 系、プライベートクラウド、業界別の選定傾向を学ぶ

  4. 4

    クラウドの中核サービス——コンピューティング・ストレージ・ネットワーク・データベース

    仮想マシン、オブジェクトストレージ、ブロックストレージ、VPC・サブネット・DNS・ロードバランサー、マネージド RDB・NoSQL・データウェアハウスの概観を学ぶ

  5. 5

    コンテナ・サーバーレス・マネージドサービス——モダンな実行環境

    Docker と Kubernetes の概念、マネージド Kubernetes、コンテナ実行サービス、FaaS(サーバーレス)の使いどころ、マネージドサービスの設計判断を学ぶ

  6. 6

    クラウドのコストとガバナンス——FinOps の発想

    従量課金の落とし穴、予約インスタンス・Savings Plans、タグ付けとコスト可視化、予算アラート、FinOps Foundation の発想、生成 AI 推論コストの不確実性を学ぶ

  7. 7

    クラウドのセキュリティ——責任共有モデルと設計の発想

    責任共有モデル、IAM とアクセス制御、鍵管理(KMS)、VPC とネットワーク分離、暗号化、ログと監査、クラウド時代のセキュリティ運用の考え方を学ぶ

  8. 8

    クラウド移行と次の選択——マルチクラウド・ハイブリッド・修了後

    クラウド移行の 7R、ハイブリッドクラウド、マルチクラウドの幻想と現実、ベンダーロックインの議論、AI エージェント実行環境、SBOM・PQC、修了後の学習方向を案内する

  9. 総復習テスト

    全レッスンの内容を振り返るテスト

このコースの用語集(75語)
暗号化
データを「鍵」を使って読めない形に変換する技術。クラウドでは保管時(at rest)と通信時(in transit)の両方で暗号化するのが現代のベストプラクティス。
インスタンス
仮想マシン 1 台を指す呼び名。「3 インスタンス起動した」と言えば、仮想マシンが 3 台動いている状態を指す。
オートスケーリング(おーとすけーりんぐ)
負荷に応じて仮想マシンやコンテナの数を自動で増減する仕組み。コスト最適化の代表的な手段だが、上限・下限・メトリクスの設計を誤ると暴走する。
オブジェクトストレージ(おぶじぇくとすとれーじ)
ファイルを「オブジェクト」として保存する仕組み。S3/Blob Storage/Google Cloud Storage が代表。容量無制限・コスト低・頻繁な編集には不向き。
オンプレミス
自社の建物(敷地内)にサーバーを設置し、自分たちでネットワーク・電源・空調・運用を持って業務システムを動かす形態。「オンプレ」と略される。
可用性ゾーン(かようせいぞーん、AZ)
1 つのリージョン内にある、物理的に独立した複数のデータセンター群。電源・空調・ネットワークが独立しているため、複数 AZ にサーバーを分散する「マルチ AZ 構成」が可用性設計の基本。