Webテクノロジーとクラウド

このページは、Web技術 と クラウドコンピューティング を整理するページです。HTTP/HTTPS から始まる Web の基礎、API と Web サービス の設計パターン、そして クラウドサービスモデル と デプロイメント形態 を一本の流れで押さえます。

HTTP は Web ブラウザとサーバ間でテキストやファイルをやり取りするプロトコルです。HTTPS は、その通信を TLS/SSL 暗号化で保護します。試験では ステートレス（各リクエストが独立）という特性が重要です。

HTTP はステートレスなため、ユーザーをどう識別し続けるかが課題です。Cookie はクライアント側に小さなデータを保存し、毎回のリクエストで自動送信する仕組みです。セッション はサーバ側でユーザーの状態を保持し、Session ID を Cookie で受け渡す仕組みです。試験では、認証後の状態保持がどう実装されるかを理解することが大切です。

Ajax は、ページ全体をリロードせず、JavaScript で部分的にサーバと通信する技術です。WebSocket は、HTTP をアップグレードして双方向通信を実現するプロトコルです。リアルタイム性が必要なチャットやライブ更新では WebSocket、ページ部分更新では Ajax という使い分けが基本です。

PWA は、ブラウザ上で App 同様の体験（オフライン動作、プッシュ通知、ホーム画面インストール）を提供する Web アプリケーションです。Service Worker というブラウザバックグラウンドプロセスがキャッシング戦略を管理します。試験では、Web アプリの進化形 として位置付けます。

REST（Representational State Transfer）は、Web 上のリソース（URI）に対して、HTTP メソッド（GET, POST, PUT, DELETE）で操作する設計原則です。ステートレス、リソース指向、キャッシュ可能 が特徴です。試験では、RPC 的な設計との違いを理解することが重要です。

SOAP は、XML ベースの複雑な交換プロトコルです。WSDL（Web Services Description Language）で仕様を定義し、UDDI で検索可能にするエンタープライズ向けの仕組みです。REST が単純な CRUD 中心なのに対し、SOAP はトランザクション性が求められるシステム間連携に使われます。

GraphQL は、クライアント側で必要なデータ構造を指定して取得する言語です。REST のような複数エンドポイント呼び出しや、不要なデータ取得の無駄を削減できます。試験では、REST との設計思想の違いを認識することが大切です。

JSON（JavaScript Object Notation）は、キーと値のペアをネストできる軽量な形式です。XML は、タグ構造で階層的なデータを表現できる拡張可能形式です。API 設計では、JSON がシンプルさで、XML が複雑なスキーマ定義で使い分けられます。

年度別の過去問では、HTTP、HTML/CSS、Web API、JSON、REST をひとまとまりに出して混乱させる問題が繰り返し出ています。ここは「何を決める言葉か」で切ると崩れにくくなります。

迷ったら、次の順で切ります。

たとえば、スマホアプリが商品データを取得する なら主役は Web API で、その通信に HTTP を使い、中身を JSON で返し、その API を REST で設計する という関係になります。Web API = HTML/CSS でもなければ、JSON = 通信プロトコル でもありません。

モノリス アーキテクチャは、全機能が 1 つの大きな成果物にまとまった設計です。マイクロサービス は、ビジネス機能ごとに小さなサービスに分割し、API で疎結合する設計です。スケーリング性、デプロイ独立性、障害隔離の観点でマイクロサービスが優位ですが、運用複雑性が増します。

クラウドコンピューティングは、インターネット経由で計算リソース（サーバ、ストレージ、ネットワーク、ソフトウェア）をオンデマンド提供する仕組みです。従来のオンプレミス（企業が自社でサーバを所有・運用）では、初期投資が大きく、スケーリングに時間がかかります。一方、クラウドは月額課金で開始でき、リソースを瞬時に増減できるため、成長企業やピーク対応が必要なビジネスに向いています。

試験では、サービスモデル の 3 層（SaaS / PaaS / IaaS）と デプロイメント形態 の違いを中心に理解します。特に重要なのは、各層でユーザーが管理する部分が異なることです。「何を提供するのか」と「何をユーザーが管理するのか」をセットで押さえることが合格への鍵となります。

クラウドのサービスモデルは、「何をクラウド企業が提供し、何をユーザーが管理するのか」という責任分界で区分されます。

SaaS（Software as a Service） は、完成されたアプリケーションをインターネット経由で利用するモデルです。ユーザーはメールアカウントを作成し、ブラウザにログインすれば、すぐに使えます。Google Workspace（Gmailやドキュメント作成）、Salesforce（営業支援）、Microsoft 365 などが典型例です。ユーザーは「使う」だけで、インフラ、OS、ミドルウェアはすべてクラウド企業が管理します。

PaaS（Platform as a Service） は、アプリケーション開発・実行環境を提供するモデルです。開発者は、ミドルウェアや実行環境をすでに備えた環境にコードをアップロードすれば、すぐに動きます。Heroku、Google App Engine、Azure App Service などが例です。ユーザーは自分が書いたコードとデータだけを管理し、OS以下のインフラはクラウド企業が担当します。

IaaS（Infrastructure as a Service） は、計算リソース（サーバ、ストレージ、ネットワーク）そのものをレンタルするモデルです。ユーザーは、借りた仮想マシン上に OS をインストールし、ミドルウェアとアプリケーションを自分で構築します。AWS EC2、Azure VM、Google Compute Engine などが例です。クラウド企業は物理インフラだけを提供し、OS以上はユーザー責任です。

試験では、この「責任の線引き」が頻出です。問題で「この企業はクラウドを使いたい。アプリケーションはすでに完成しており、管理負荷を最小化したい」という状況なら、答えは SaaS です。逆に「新しい Web アプリを開発・実行したい」なら PaaS、「レガシーシステムを段階的にクラウド化したい」なら IaaS、というように、ビジネス要件と責任範囲を結びつけることが重要です。

DaaS（Desktop as a Service）は、クラウド上のデスクトップ環境を利用するモデルです。社内 PC を 1 台ずつ管理するのではなく、クラウド上の仮想デスクトップへ接続して使います。後で出てくる VDI を、外部サービスとして利用するイメージだと考えると分かりやすいです。

切り分けのコツは、何を使いたいか より先に どこまで自社で持ちたいか を見ることです。画面環境だけ借りたい なら DaaS、完成済みアプリを使いたい なら SaaS、アプリを作る基盤が欲しい なら PaaS、OS 以上を自社で握りたい なら IaaS です。

FaaS は、関数単位で実行できるサービスです（AWS Lambda など）。サーバレス と呼ばれることもあります。実行時間とメモリ使用量だけを課金する従量制が特徴です。スケーリングも自動です。

インターネットを使った取引は、単に「EC」とひとまとめにせず、誰と誰の取引か で整理すると理解しやすくなります。中小企業診断士試験では、B2B・B2C・C2C の違いと、企業間連携を支える EDI が定番です。

EDI（Electronic Data Interchange） は、受発注書、納品書、請求書などの商取引データを、企業間で標準化された形式で交換する仕組みです。紙やFAXをなくすこと自体が目的ではなく、受発注から在庫補充までをつなぎ、サプライチェーン全体を速く正確に動かすこと が本質です。

eビジネスでは、取引の類型ごとに使いやすい決済手段が異なります。

試験では、「企業間の定型反復取引を効率化したい」なら EDI、「消費者向けECで購入のしやすさを高めたい」なら B2C と決済 UX に着目すると整理しやすくなります。

Web 活用を問う問題では、単に「インターネットで情報発信できる」だけでなく、どの媒体がどんな伝わり方をするか が問われます。特に SNS と ブログ の違い、メディアミックス の考え方、そして情報の偏りが生じる現象は頻出です。

メディアミックス は、1つの媒体だけで完結させず、複数媒体を役割分担させる考え方です。たとえば、SNS で関心を集め、ブログや自社サイトで詳しく説明し、EC サイトで購買につなげる流れです。試験では、単一媒体で全部やる とする選択肢が誤りになりやすいです。

インターネット上では、情報が多いだけでなく、偏って届く ことがあります。似た言葉が多いので、どこに偏りの原因があるかで切り分けます。

フィルターバブル はシステム側、エコーチェンバー はコミュニティ側、集団極性化 は心理過程側の概念です。ここを区別できると、SNS の設問でかなり強くなります。

クラウドのデプロイメント形態は、「誰とリソースを共有するのか」という観点で分けられます。

パブリッククラウド は、複数の企業や個人がリソースを共有する形態です。Amazon Web Services（AWS）、Microsoft Azure、Google Cloud Platform などが該当します。ユーザーは低コストで瞬時に利用開始でき、スケーラビリティに優れています。ただし、リソースが他の企業と共有されるため、セキュリティやデータ保護は自社では直接管理できません。Web サービス、開発・テスト環境、一般的な業務システムに向いています。

プライベートクラウド は、1 企業専用のクラウド環境です。物理インフラと管理体制を自社が所有するか、ベンダーに全て委託します。セキュリティ対策やコンプライアンス要件をカスタマイズできるため、機密データを扱う金融機関や医療機関に向いています。ただし、初期投資とメンテナンスコストが高くなります。

ハイブリッドクラウド は、オンプレミス環境とパブリッククラウドを組み合わせる形態です。例えば、基幹システムは自社データセンター（オンプレミス）で運用し、新規プロジェクトはクラウドで実施する、といった使い分けです。既存資産を活かしながら段階的にクラウド化したい企業や、ピーク時だけクラウドに負荷を逃がしたい企業に適しています。

コミュニティクラウド は、特定の業界や団体の共通ニーズに対応したクラウド環境です。例えば、金融業界専用のコミュニティクラウドなら、業界標準のセキュリティやコンプライアンスが組み込まれています。

試験では「セキュリティや規制要件が厳しい場合は？」と聞かれたら、プライベートまたはハイブリッド（機密部分はオンプレミス）を選びます。一方、「コストを最小化して新規サービスを素早く立ち上げたい」なら、パブリッククラウドが正解です。

クラウドの効率性を支える実装技術を層で理解します。

仮想化 は、物理的な 1 台のサーバ上に、複数の独立した仮想マシン（VM）を走らせる技術です。クラウドの根本を支える技術で、なぜ複数企業が同じ物理サーバを共有できるのかの鍵となります。

具体的には、CPU、メモリ、ディスクを論理的に分割し、各 VM に割り当てます。例えば、128GB のメモリと 32 コア CPU を持つ物理サーバを 4 台の仮想マシン（各 32GB、8 コア）に分割するイメージです。各 VM は独立した OS を持ち、完全に分離された環境で動作するため、1 台の VM がクラッシュしても他の VM には影響しません。

この分割・隔離を実現するのが ハイパーバイザー（仮想化ソフト）です。ハイパーバイザーは、各 VM からのリソース要求を物理レベルで管理し、公平に配分します。VMware vSphere、Microsoft Hyper-V、KVM（Linux 組込み）などが主要な実装です。

仮想化がなければ、サーバの稼働率は低いままです。従来は、1 台のサーバを 1 つのアプリケーション（例：Web サーバ）専用に使っていたため、その サーバの CPU が 10% しか使われていなくても、他のアプリケーションは別のサーバが必要でした。仮想化によって、複数の低負荷アプリケーションを 1 台の物理サーバ上で動かせるため、ハードウェア利用効率が大幅に向上します。

両者とも「複数のアプリケーションを 1 台の物理サーバ上で独立して動かす」という目的は同じですが、実装とコスト効率が大きく異なります。

仮想マシン（VM） は、完全な OS をゲストとして含むため、重量級です。各 VM は独立した OS カーネル、デバイスドライバ、ライブラリをすべて持つため、隔離レベルは極めて高く、安全性に優れています。例えば、Linux VM と Windows VM を同じサーバ上で動かすことも可能です。ただし、各 VM が GB 単位のメモリを消費し、起動に数十秒～分かかるため、スケーラビリティと迅速性に欠けます。企業のサーバ統合（複数の古いオンプレミスサーバをデータセンター上の VM に統合する）やマルチテナント環境（顧客ごとに専用 VM を提供する SaaS）に適しています。

コンテナ は、OS カーネルを共有し、アプリケーションと必要なライブラリだけをパッケージ化するため、軽量です。各コンテナは数百 MB～数 GB であり、秒単位で起動できます。隔離レベルはソフト（同じ OS カーネル上での名前空間・リソース制限で分離）なため、VM ほど完全ではありませんが、同じ OS（例：全て Linux）を前提に、複数アプリケーションの軽量隔離が必要なユースケースに最適です。

Docker はコンテナ化の標準技術で、アプリケーション実行環境を「イメージ」として定義します。このイメージは、開発環境・テスト環境・本番環境で全く同じ動作をするため、「開発環境では動いたのに本番環境で動かない」という問題が起きにくくなります。マイクロサービスアーキテクチャで複数の小さなサービスを頻繁にデプロイ・スケールする場合、コンテナの軽さと迅速性が大きな優位性になります。

試験では、「この企業は古いアプリケーションを複数の OS で動かしている。物理サーバを統合したい」という場合は VM、「新しい Web アプリを複数サービスに分割して、頻繁に更新したい」という場合はコンテナ、という使い分けが重要です。

Docker はコンテナ化の実装技術で、アプリケーション環境をイメージとして定義・配布します。ただし、Docker は単一マシン上でのコンテナ管理に向いています。

Kubernetes（K8s）は、複数のコンテナを複数のサーバ（ノード）にまたがって実行・管理する オーケストレーション プラットフォームです。Kubernetes がなければ、10 台のサーバ上で 100 個のコンテナを管理するのは手作業で極めて複雑です。Kubernetes は以下の操作を自動化します：

マイクロサービスアーキテクチャでは、数十～数百のコンテナが動作するため、Kubernetes のような自動管理ツールがなければ運用は破綻します。

CDN は、地理的に分散したサーバで静的コンテンツ（画像、動画、JavaScript、CSS）をキャッシュ配信する仕組みです。

例えば、日本と米国にそれぞれユーザーがいるとします。CDN がなければ、全ユーザーが米国のオリジンサーバからコンテンツを取得するため、日本のユーザーは長い遅延（100ms～数秒）を経験します。CDN を使えば、コンテンツを日本と米国の複数拠点に事前キャッシュしておき、各ユーザーが地理的に最も近いサーバから取得できるため、遅延が大幅に減少（10ms～100ms に短縮）します。

また、オリジンサーバへのアクセス集中も軽減されます。100 万人のユーザーが同じ画像を要求しても、CDN が各地で配信するため、オリジンサーバには数十～数百のリクエストしか届きません。結果、オリジンサーバの帯域幅コストが削減されます。

CDN は YouTube、Netflix、Amazon CloudFront など、大規模な静的コンテンツ配信に必須の技術です。

エッジコンピューティング は、クラウドの中央データセンターではなく、ネットワークの末端（エッジ）でデータ処理を行う考え方です。

例えば、工場に 1000 個の IoT センサが設置されているとします。従来のクラウドモデルなら、1000 個のセンサからすべてのデータをクラウドに送信し、クラウド上で分析・フィルタリングします。ただし、これは以下の課題を招きます：

エッジコンピューティングなら、工場の入口に小型エッジサーバを置き、そこで 1000 個のセンサデータを集約・フィルタリングします。例えば、「温度が 80°C を超えた」という要約情報と「異常箇所」だけをクラウドに送信します。結果、遅延が削減され、ネットワーク帯域幅も節約でき、プライバシーも保護されます。

エッジコンピューティングは、自動運転車（カメラ画像をリアルタイムで処理）、スマートシティ（交通量データをエッジで集約）、IoT 製造業（機器の異常検知をエッジで即座に判定）などで急速に普及しています。

サーバレス は、開発者がサーバ管理を気にせず、関数やイベントハンドラを書くだけで動く環境です。「サーバがない」という意味ではなく、サーバ管理を クラウド企業に完全委託するモデルです。AWS Lambda、Google Cloud Functions、Azure Functions が該当します。

例えば、画像アップロードをトリガーに、自動的にサムネイルを生成するシステムを作りたいとします。従来の PaaS なら、Web サーバは常に起動させておき、アクセスがなくても電力を消費します。サーバレスなら、「画像がアップロードされたときだけ、サムネイル生成関数が 1 秒間実行される」という課金になります。月 1000 回実行されるなら、課金対象は 1000 秒分だけで、その他の時間帯は完全に無料です。

スケーリングも自動です。突然アクセスが 100 倍に増えても、関数は自動的に数百個の並行インスタンスで実行され、処理しきれないことはありません。一方、低ボリュームなら数個のインスタンスだけで対応し、コストは無駄になりません。

ただし限界もあります：

したがって、「リアルタイムデータ処理」「定期バッチ処理」「IoT イベントハンドリング」といった、短時間で独立した処理に最適です。長時間の複雑なワークフローや常に状態を保持する必要があるシステムには向きません。

VDI は、ユーザーが使うデスクトップ環境そのものをサーバ上で仮想化し、ネットワーク経由でシンクライアント（キーボード・マウス・ディスプレイだけの簡易端末）へ配信する仕組みです。

従来のテレワークでは、ユーザーが自宅のパソコンで作業するため、データが端末に残るリスク（紛失、盗難、不正コピー）があります。VDI を使えば、実際の処理や データはサーバ上で行われ、端末には画面映像だけが送信されます。ユーザーはタッチペンでタブレットを操作しているのと同じイメージで、実際のセキュアな環境で作業しています。

VDI の利点：

VDI の課題：

金融機関、政府機関、医療機関など、セキュリティ要件が厳しい業界や、テレワーク推進企業で導入が進んでいます。

オンプレミスとクラウドは、大きく異なるトレードオフを持ちます。単に「クラウドが新しい・良い」ではなく、ビジネス特性に応じた選択が重要です。

オンプレミス（自社データセンター） は、物理サーバを購入し、自社施設で運用するモデルです。初期投資（サーバ購入、ラック設置、冷却システム構築）が数千万円～数億円と巨大です。完全な自社管理により、セキュリティポリシーを細かくカスタマイズでき、機密データに最適です。一方、スケーリングには 3～6 ヶ月かかり（サーバ購入→設置→テスト→本運用）、ピーク時の一時的な負荷対応に向きません。毎年の保守費、電力費、人員費（システム管理者）で年間数百万円～数千万円の運用コストが発生します。

クラウド は、月額課金で瞬時に始められます。初期投資がゼロ（またはごく小さい）で、スケーリングは秒～分で完了し、ピーク時の負荷急増に即対応できます。ただし、インフラの細かいカスタマイズは難しく、クラウド企業のサービス仕様に依存します。セキュリティは「共有責任モデル」で、企業も設定と監視の責任を持たねばなりません。

選択基準：

ハイブリッドクラウドは、この両世界のバランスを取る実務的な選択です。

API 設計と責任分界に関する誤解

クラウドサービスモデルの混同（頻出の誤り）

仮想化技術の混同

コスト・スケーラビリティの誤解

デプロイメント形態の誤解

試験で得点を落とさないために