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

このレッスンで学ぶこと

クラウドコンピューティングの定義を NIST の整理で理解する
オンプレミスとクラウドの違いを「所有」と「利用」の対比で説明できる
NIST が示す 5 つの本質的特徴を整理できる
なぜクラウドが 2010 年代以降に急速に普及したのかを把握する
本コースの守備範囲と扱わない範囲を理解する

「うちもそろそろクラウドにしないと」「うちはまだクラウドじゃないから遅れている」——会議室でいまも聞こえる言葉です。一方で、「で、クラウドって結局なんですか」と改めて問われると、ITに関わる人でもうまく説明できないことが少なくありません。クラウドはもはや業務システムの土台ですが、その実体は「自分の会社の建物にコンピューターを置かず、外の事業者の設備を必要なときに借りて使う」という、ごく単純な発想の集まりです。本コースの出発点として、まずクラウドが何を意味するのか、何が変わったのかを、技術用語を抜きに整理します。

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

クラウドコンピューティング（cloud computing）は、コンピューターの処理能力・保存場所・ソフトウェアなどを、ネットワーク越しに必要なときだけ利用する形態の総称です。

ポイントは、利用者が「自分でハードウェアを所有しない」「使いたいときに、使った分だけ料金を払う」「設備の調達・運用・廃棄を事業者に任せる」という 3 点にあります。電気・ガス・水道のように「インフラを使った量だけ支払う」発想に近く、英語圏では「ユーティリティコンピューティング（utility computing）」とも呼ばれてきました。

公式定義はどこにあるか

クラウドの代表的な公式定義は、米国国立標準技術研究所（NIST：National Institute of Standards and Technology）が 2011 年 9 月に発行した『The NIST Definition of Cloud Computing』（SP 800-145）にあります。短い文書ですが、業界・学術・政府の文脈で「クラウドとは何か」を語るときに、いまでも基準点として参照されます。

💡 ポイント NIST の定義は 2011 年に出されたものですが、2026 年の現在でも基本枠組みとして有効です。「クラウドとは何か」を社内で説明する場面では、NIST の整理を借りておくと議論がぶれにくくなります。

オンプレミスとクラウドの違い

クラウドを理解する近道は、その対比であるオンプレミスを並べてみることです。

オンプレミス（on-premises）とは、自社の建物（敷地内）にサーバーを設置し、自分たちでネットワーク・電源・空調・運用を持って業務システムを動かす形態です。「オンプレ」と略されます。

両者の違いを、表で見てみましょう。

観点	オンプレミス	クラウド
ハードウェアの所有	自社が購入・所有	事業者が所有
設置場所	自社の建物（または契約データセンター）	事業者のデータセンター
調達リードタイム	数週間〜数か月	数分〜数時間
料金体系	初期投資（CAPEX）が大	利用量に応じた経費（OPEX）が中心
拡張・縮小	物理的な追加調達が必要	ボタン操作で増減可能
故障対応	自社が部品交換・保守	事業者が対応
監視・運用	自社の運用チーム	一部は事業者が担う

「持つ」から「使う」への発想転換

オンプレミスは「コンピューターを所有して使う」、クラウドは「コンピューターを必要なときに借りて使う」。この 1 行が、クラウドの本質です。所有から利用への発想転換が、コスト構造・運用体制・調達スピード・組織のスキルセットすべてに影響します。

「料金を払い続けるなら、買ったほうが安いのでは」と感じる方もいるかもしれません。設備を 5 年使い続けて稼働率が常に高ければ、自社所有のほうが原価が安くなる場合もあります。一方で、需要が読めない事業や急成長中の事業では、必要なときだけ借りられるクラウドの柔軟性が、所有のコスト優位を上回ります。この判断は、コースの後半（特にレッスン 6）で改めて整理します。

📝 補足 「クラウド = インターネット越しのサーバー」と覚えるのは、入り口としては十分です。一方で、本講義では「単なる遠隔サーバー」と「クラウド」を区別します。違いは次に説明する 5 つの本質的特徴にあります。

NIST が示す 5 つの本質的特徴

NIST の定義は、クラウドを名乗るために満たすべき 5 つの本質的特徴（essential characteristics）を挙げています。1 つずつ見ていきましょう。

オンデマンド・セルフサービス（On-demand self-service）：利用者が、人間の担当者を介さずに、自分で必要なリソースを増減できる
広範なネットワークアクセス（Broad network access）：標準的なネットワーク経由で、PC・スマートフォン・タブレットなど多様な端末から使える
リソースプール（Resource pooling）：事業者が大量の計算資源をプール（共有池）として持ち、複数の利用者に動的に割り当てる
迅速な弾力性（Rapid elasticity）：必要に応じてリソースをすばやく増やしたり減らしたりでき、利用者からは「無限にあるように」見える
計測可能なサービス（Measured service）：使用量が自動的に計測・記録され、利用者は使った分だけ支払う

5 つの特徴を「水道」で例える

5 つの特徴を、日本語で身近に例えると次のようになります。

オンデマンド・セルフサービス：蛇口をひねれば水が出る（職員に申請する必要がない）
広範なネットワークアクセス：家・職場・公衆の水道、どこでも同じ規格の蛇口が使える
リソースプール：浄水場が大量の水を貯めて、各家庭に必要量だけ送る
迅速な弾力性：水を流しっぱなしにできる蛇口、止めれば消費が減る
計測可能なサービス：水道メーターで使った量だけ請求される

「水道」というメタファーに完全に置き換えられるわけではありません。しかし、5 つの特徴を 1 つの絵で覚えるには有効です。

5 つすべてが揃って「クラウド」

5 つの特徴のうち、どれか 1 つが欠けるだけで「単なる遠隔サーバー」になります。例えば、データセンター業者にサーバーを借りているだけでも、利用者が自分で増減できなければオンデマンド・セルフサービスを満たしません。これは伝統的なホスティング（hosting）と呼ばれ、クラウドとは区別されます。

⚠️ 注意 「うちは社内サーバーをデータセンターに移したからクラウドだ」と説明する組織もありますが、5 つの特徴を満たしているとは限りません。クラウド事業者の本来の意味では、NIST の 5 つの特徴を満たすサービスを指します。

なぜクラウドが普及したのか

クラウドという発想自体は古くからあります。一方で、業界全体に広がったのは 2010 年代以降です。普及の背景には、3 つの大きな流れがあります。

1. 大規模インフラの登場

2006 年に Amazon が S3（Simple Storage Service）と EC2（Elastic Compute Cloud）の提供を開始したことが、現代クラウドの実質的な出発点です。Amazon は自社の巨大な EC（電子商取引）サイトを支えるためのインフラを、外部にも貸し出す事業として立ち上げました。これに続いて、Microsoft が 2010 年に Azure を正式提供開始、Google が 2008 年に App Engine、2013 年に Compute Engine を提供開始し、3 強の構図ができていきました。日本でも、さくらインターネット・IDC フロンティア・NIFCLOUD・NTT 系のサービスが同じ時期に進化していきました。

2. スマートフォンと API エコノミー

スマートフォンの普及（2010 年代前半〜）により、業務もプライベートも「いつでもどこでも」つながる前提になりました。多様な端末を支えるには、自社サーバーよりもクラウドのほうが運用しやすい状況が生まれます。同時期に、SaaS のサービス同士が API（Application Programming Interface：ソフトウェア同士の連絡口）でつながる「API エコノミー」が広がり、業務システムの組み合わせ方が大きく変わりました。

3. テレワークと事業継続

2020 年代に入ると、テレワーク（在宅勤務）の急速な普及、災害・パンデミックといった非常事態への備え、事業継続計画（BCP：Business Continuity Plan）の見直しが進みました。自社建物に依存する仕組みからクラウドに移すことで、社員がどこからでも業務にアクセスでき、特定の事務所が使えなくなっても事業が継続できる利点が再認識されました。

2026 年 6 月時点では、上場企業のほぼ全社が何らかのクラウドサービス（特に SaaS）を業務で利用している状況にあります。

本コースの守備範囲

最後に、本コースで扱う範囲と扱わない範囲を整理しておきます。

扱う範囲

クラウドの定義と NIST の 5 つの本質的特徴（本レッスン）
IaaS／PaaS／SaaS の 3 階層と責任分界（レッスン 2）
AWS／Azure／GCP と日本の選択肢（レッスン 3）
コンピューティング・ストレージ・ネットワーク・データベースの中核サービス（レッスン 4）
コンテナ・サーバーレス・マネージドサービス（レッスン 5）
コストとガバナンス、FinOps の発想（レッスン 6）
責任共有モデル、IAM、鍵管理、ログと監査（レッスン 7）
クラウド移行の 7R、マルチクラウド・ハイブリッド、AI エージェント実行環境、SBOM・PQC（レッスン 8）

扱わない範囲

特定クラウドの操作画面・API・コマンド例・IaC（Infrastructure as Code）のコード
特定 SaaS 製品の操作手順や設定（公式ドキュメントを参照）
ネットワーク・OS の専門知識（別の専門書・コースを参照）
暗号アルゴリズムや認証プロトコルの数学的詳細
「AWS 認定資格」「Azure 認定資格」「Google Cloud 認定資格」など個別試験対策の網羅性
フィッシング・マルウェアといった攻撃手法の詳細（情報セキュリティの守備範囲）

スタンス

本コースは、クラウドを「特別な技術の話」ではなく「業務システムの土台として理解し、判断できる基本リテラシー」として扱います。同時に、「クラウドに乗せれば全部解決」という発想とも、「クラウドは危ないからオンプレが安全」という発想とも距離を置きます。要件から逆算してクラウドという道具を選び、コスト・セキュリティ・運用のバランスを取る判断軸を、現場の感覚も交えて持ち帰っていただくのが目的です。

特定のクラウド事業者（AWS／Azure／GCP）を推す立場は取りません。レッスン 3 で 3 社の特徴を整理しますが、優劣の判定ではなく「要件で選ぶための観点」を伝えるのが本コースの姿勢です。

講師の現場メモ：「通信キャリア時代の『クラウド移行への抵抗』」

私（山下）が新卒で入社した大手通信キャリアの法人ネットワーク技術部での話です。配属 2 年目、ある中堅製造業のお客様のシステム更改提案を担当しました。

当時はちょうど AWS が日本でも知られ始めた時期で、私はクラウドへの移行案を提案資料に組み込みました。社内会議で資料を見せると、課長と部長が顔を見合わせました。

「山下さん、お客様の基幹システムを、他社の建物に置くんですか？セキュリティは大丈夫ですか？」「故障したら、我々が現場に行けないですよね？」「コストはオンプレのほうが安いと言われています。データは『そこにある』ことが大事です」

私は反論を準備していました。NIST の定義、AWS の物理セキュリティ証明書、リードタイム短縮の効果——。けれど課長の言葉でハッとしました。「山下さんが言うクラウドの利点は理屈ではわかる。ただ、お客様の経営層には『よくわからない場所に置く』という不安が必ず残る。理屈の説明ではなく、その不安にどう答えるかが、提案の本質だ」。

結局、その案件はオンプレ更改で進みました。3 年後、同じお客様が再びシステム更改の時期を迎えたとき、今度は経営層自らが「クラウドにしたい」と打診してきました。3 年のあいだに、テレワーク導入・大規模災害の影響・競合他社のクラウド移行成功事例が積み重なり、不安よりも遅れることへの不安のほうが大きくなったからです。

このとき私が学んだのは 2 つです。1 つ目は、技術の優位性だけでは組織は動かない、ということ。2 つ目は、クラウドの普及には「3 年」という時間が必ず要る、ということです。本コースで「特定クラウドの宗教戦争に乗らず、要件で選ぶ」と繰り返し言うのは、当時の課長の言葉が私の中に残っているからです。

まとめ

このレッスンでは、以下のことを学びました。

クラウドコンピューティングは、コンピューターの処理能力・保存場所・ソフトウェアをネットワーク越しに必要なときだけ使う形態
NIST の『The NIST Definition of Cloud Computing』（SP 800-145、2011 年）が公式定義の基準
オンプレミスは「所有して使う」、クラウドは「借りて使う」発想
NIST が示す 5 つの本質的特徴：オンデマンド・セルフサービス、広範なネットワークアクセス、リソースプール、迅速な弾力性、計測可能なサービス
5 つすべてが揃って「クラウド」と呼べる。1 つでも欠けると単なる遠隔サーバー
普及の背景には大規模インフラの登場、スマートフォンと API エコノミー、テレワークと事業継続の 3 つの流れがある
本コースは「特別な技術」ではなく「業務の土台を理解する基本リテラシー」として扱う

次のレッスンでは、IaaS／PaaS／SaaS の 3 階層と責任分界の発想を、ピザ屋の例えで腹落ちするように整理します。

確認クイズ

このレッスンの理解度をチェックしましょう。