AI・クラウド / 第2章・全8章

共同利用から、計算をサービスとして使う時代へ

共同利用から管理作業の外部化をたどる。仮想化だけでは事業は成立しない。

約18分 / 内容確認日:2026-10-31

大きな設備を分けて使う発想

計算機が高価で、使う場所や人が限られていた時代には、一台の設備を複数の仕事で分けて使うことに大きな意味がありました。計算時間を配分する仕組みは、設備を所有することと、計算結果を得ることを分けて考える入口になります。現在のクラウドを、昔の共同利用と完全に同じものと考えることはできませんが、高価な設備の利用をまとめるという経済上の問いには連続性があります。

企業が各拠点でシステムを運営する場合には、機械を買うだけでなく、設置場所、電源、故障対応、バックアップ、更新の担当を用意します。設備を外部の施設に置くと、施設管理の仕事を移せますが、アプリケーションの管理まで自動的に移るわけではありません。歴史を読むときは、サービスの名称が変わったかだけでなく、それまで利用企業が抱えていたどの作業が、誰の仕事として外部化されたかを追います。

この変化は、費用の発生時期にも関わります。自社で一度に設備を買う形から、利用期間や利用量に応じて支払う形へ移れば、初期の資金負担は変わります。ただし、長期の支払総額が必ず小さくなるとは限りません。設備更新の不確実性を外部に移す一方、契約や料金体系の変更に対応する必要が生まれます。技術の歴史は、誰が将来の需要や設備陳腐化のリスクを負うかの変化としても読めます。

参照資料:The NIST Definition of Cloud Computing

仮想化とネットワークが供給の仕方を変える

仮想化は、一つの物理的な計算機の資源を、複数の実行環境として扱いやすくする技術です。利用者は物理機械の細部から離れた単位で資源を扱い、提供者は機械の配置や利用を調整できます。これだけでクラウドが完成するのではなく、資源を申し込む仕組み、課金、監視、障害対応などが揃って初めて継続的なサービスになります。発明と、事業として運用できる仕組みを区別することが重要です。

ネットワークの利用が広がると、離れた場所にある機能を呼び出すことが日常的になります。利用者がすべてのプログラムを自分の端末に置かなくても、共通の機能を提供者が更新する形が取りやすくなります。その一方、通信の途絶や応答時間がサービス品質の一部に入り、認証やデータの取り扱いが企業間の約束になります。利便性を支える条件が変わるため、設備の進歩だけを並べても産業の変化は説明しきれません。

NISTが2011年に公開したクラウド定義は、この提供方式を整理する共通の言葉として使われてきました。この年をクラウドの発明年と見なすのは誤りです。新しい事業の実務が先に広がり、その後で比較や調達に使う定義が整う場合があります。企業の沿革を調べる際も、試験提供、一般提供、地域展開、利用者の拡大を分けてください。異なる段階の出来事を一列に並べると、参入の早さだけが競争力であるように見えてしまいます。

参照資料:The NIST Definition of Cloud Computing

AIの普及が計算の供給に加えたもの

AIの利用が広がると、単に保存容量を増やすだけではなく、大量の計算を短い時間で行う部品、それらを結ぶ通信、発熱を処理する設備への要求が注目されます。これはクラウドがAIに置き換わったという意味ではありません。既存のサービス群に、異なる負荷や品質条件を持つ仕事が加わったと考える方が、基盤企業とアプリケーション企業の関係を整理しやすくなります。

IEAのEnergy and AIは、AIとデータセンターを電力供給や設備の条件と結び付けて分析しています。需要が伸びる見通しと、必要な場所で必要な時期に電力を確保できることは別です。歴史の新しい段階を見るときも、発表された投資額だけでなく、部品の調達、工事、受電、運用人材という一連の準備を確認します。サービス需要が先行しても、供給側の物理条件が短期間では変わらない場合があります。

企業の歴史を一枚にまとめる練習では、行を「利用企業が困っていたこと」「提供側が新たに引き受けた仕事」「残った制約」の三つにします。共同利用では設備費、クラウドでは供給の速さや運用、AIでは結果の品質や計算費用など、主な問いがどう変わったかを書きます。特定の年代がすべての企業に同時に到来したとは考えず、自社設備と外部サービスが併存する理由まで説明できれば、歴史を現在の選択につなげられます。

参照資料:Energy and AIAI Risk Management Framework

歴史を機能と責任の移動として描く

企業が昔から使っている顧客管理を、新しい外部サービスへ移す場面を想像します。移行前には自社が行っていた設備の調達、故障対応、OS更新、利用者管理、データの入力を別々に書きます。移行後にはどの作業が提供者へ移り、どの作業が残るかを線で結びます。新旧の製品名だけを比較するより、変化した仕事を具体的に説明できます。これは特定の技術世代が全社へ同時に広がらない理由を考える練習にもなります。

既存システムには、長年の業務条件が組み込まれている場合があります。新サービスへ移ることで設備運用の負担が減っても、帳票や権限、外部との接続を作り直す必要が生じるかもしれません。歴史的に便利な方式が登場したことと、個別企業が直ちに乗り換えることは別です。技術の進歩に対して企業の選択が遅く見える場合にも、費用、互換性、責任を調べれば、その選択の条件を理解できます。

沿革を読む際は、その企業が新しい方式を発明したのか、他の技術を組み合わせてサービス化したのか、特定の顧客へ広げたのかを分類します。競争力は最初の発表日だけでは決まりません。運用、契約、支援、既存顧客との接続のどこを改善したかを読むことで、歴史と現在の収益構造がつながります。

新旧の方式を比べるときには、便利になった点だけでなく、新しく必要になった作業も探します。外部との契約、権限の管理、費用の監視などが増える場合があります。歴史を一方向の進歩だけとして読むより、仕事の分担が移り変わった過程として説明すると現在の企業の違いが見えます。

参照資料:The NIST Definition of Cloud Computing責任共有モデルAI Risk Management Framework

この章の要点

  • 共同利用から管理作業の外部化をたどる
  • 仮想化だけでは事業は成立しない
  • 定義の公表年と発明年を区別する

自分の言葉で考える

2011年のNIST定義を、クラウドが初めて発明された年と説明してよいですか。

考え方の例を読む

適切ではありません。公表年は共通の定義が示された時点です。技術、サービス提供、利用拡大という異なる過程を区別します。

AI・クラウド・共同利用から、計算をサービスとして使う時代へについて質問する

出典と確認時点

統計や企業の説明は、資料の対象時点と確認日を分けて読んでください。

  1. The NIST Definition of Cloud Computing ↗NIST / 公表日の記載なし / 確認日:2026-10-31
  2. 責任共有モデル ↗AWS / 公表日の記載なし / 確認日:2026-10-31
  3. Security in Amazon EC2 ↗AWS / 公表日の記載なし / 確認日:2026-10-31
  4. Energy and AI ↗IEA / 公表日の記載なし / 確認日:2026-10-31
  5. AI Risk Management Framework ↗NIST / 公表日の記載なし / 確認日:2026-10-31