変更要約: 初版
4.1配備モデルと種類
アプリを「どこで動かすか」を、プライベート/パブリック/ハイブリッド/エッジの各クラウドモデルと、エッジコンピューティング（データ発生源の近くで処理）、そして仮想マシン（VM）・ベアメタル・コンテナという実行基盤の選択として、「この要件（遅延・分離・性能・移植性）にはどれが適切か」という判断で学びます。
アプリを配備するとき最初に決めるのは「どこで、何の上で動かすか」です。同じアプリでも、機密データを社内に閉じたいのか、負荷変動に即応したいのか、工場のセンサに近い場所で低遅延に処理したいのかで、選ぶべきクラウドモデルと実行基盤はまったく変わります。この節では、private/public/hybrid/edge という配備モデルと、VM・ベアメタル・コンテナという実行の形を、用語の暗記ではなく「この要件ならどれを選ぶか」という設計判断として整理します。
4.1.1クラウド配備モデル
- プライベートクラウド＝単一組織専用のインフラ（自社DCや専有環境）。統制・コンプライアンス・データ主権を最優先する要件に向くが、容量は自前で確保するため急な拡張には弱い。パブリッククラウドは事業者の共有インフラを従量課金で使い、即応的なスケールと運用負荷の低減が利点。
- ハイブリッドクラウド＝プライベートとパブリックを組み合わせ、要件ごとに配置を分ける。例えば機密データはプライベートに置き、季節的な負荷急増（バースト）だけをパブリックへ逃がす（クラウドバースティング）。「どちらか」ではなく特性ごとに使い分けるのが実務の主流。
- エッジ（エッジクラウド）＝処理をユーザやデバイスの物理的に近い場所に分散配置するモデル。中央のデータセンタまで往復する遅延を避け、広域回線に依存せず現地で即応できる。判断軸は遅延・帯域コスト・統制・拡張速度であり、「新しいからパブリック」ではない。
4.1.2エッジコンピューティング
- エッジコンピューティング＝データを生成する場所（センサ・カメラ・店舗・工場）の近くで処理し、必要な結果だけを中央へ送る考え方。全生データをクラウドへ送らないため、遅延の削減・帯域の節約・オフライン耐性が得られる。IoTや産業制御、リアルタイム映像解析で価値が高い。
- 中央集約型（すべてをクラウドで処理）と対比すると、エッジは「発生源で一次処理」が本質。例えば工場の振動センサが毎秒数千サンプルを出すとき、全部をクラウドへ送るのは帯域の無駄で遅い。エッジで異常判定だけ行い、アラートと要約だけを送るのが妥当な設計になる。
4.1.3VM・ベアメタル・コンテナ
- 仮想マシン（VM）＝ハイパーバイザ上で独自のゲストOSごと動く。OSレベルで強く分離され、異なるOSを1台に同居できるが、OSを丸ごと抱えるため起動が遅く重い。「強い分離」「異種OS混在」が要件のときに選ぶ。
- コンテナ＝ホストのカーネルを共有し、アプリと依存関係だけを packaging して動かす。OSを抱えないため軽量・高速起動・高い移植性（どこでも同じように動く）が持ち味。マイクロサービスやCI/CDでの高頻度デプロイに向く。分離はVMより弱い（同一カーネル）点は理解しておく。
- ベアメタル＝仮想化層を挟まずハードウェアに直接OS/アプリを載せる形。仮想化オーバーヘッドが無く最高性能を引き出せるが、1台=1用途になりがちで柔軟性・集約率は低い。高性能計算やレイテンシに極端に敏感な用途で選ぶ。
「private＝統制/コンプラ・public＝弾力スケール・hybrid＝特性ごとに配置・edge＝発生源近くで低遅延」「エッジコンピューティングは生データを送らず現地で一次処理」「VM＝独自OSで強分離だが重い・コンテナ＝カーネル共有で軽量高移植だが分離は弱い・ベアメタル＝直載せで最高性能」が頻出です。要件（遅延・分離・性能・移植性・統制）から逆算して選べるように練習しましょう。
あなたは全国50店舗の小売チェーンで、店内カメラの映像から「レジ待ち行列の長さ」をリアルタイムに推定し、混雑時にスタッフへ通知するシステムの配備を設計しています。開発者は当初「全店舗のカメラ映像を中央のパブリッククラウドへ常時アップロードし、そこでまとめて解析しよう」と提案しましたが、これは要件を取り違えた判断です。50店舗×複数カメラの生映像を常時アップロードすると広域回線の帯域コストが膨大になり、往復の遅延で「今の混雑」を通知するリアルタイム性も損なわれ、回線断で店舗が丸ごと止まります。ここはエッジコンピューティングが妥当で、各店舗に小型の実行基盤を置き、映像解析は現地で一次処理して「行列長」という軽い結果だけを中央へ送る設計にします。次に実行基盤を選びます。店舗端末は限られたハードで複数のアプリ（映像解析・POS連携・監視エージェント）を高頻度に更新しながら同居させたいので、OSを丸ごと抱えるVMより、カーネル共有で軽量・高速起動・移植性の高いコンテナが合理的です（全店に同じイメージを配れば「どこでも同じ」が効く）。一方、中央側で機械学習モデルを大規模に再学習するバッチは、GPUの生性能を絞り出したいのでベアメタルや高性能VMが向きます。そして機密性の高い会員購買データはコンプライアンス上プライベート側に置き、季節セールで解析負荷が跳ねる部分だけパブリックへ逃がす——結果として全体はハイブリッド構成になります。重要なのは、「新しいから全部クラウド」でも「安いから全部エッジ」でもなく、要件（遅延・帯域・分離・性能・統制）の一つひとつが、どのモデル・どの基盤を選ぶ判断根拠になっていることです。
| 実行基盤 | 分離と重さ | 性能/起動 | 向く用途 |
|---|---|---|---|
| ベアメタル | 仮想化なし・直載せ | 最高性能・オーバーヘッド無 | HPC・極端に低遅延な用途 |
| 仮想マシン（VM） | 独自OSで強い分離・重い | 起動が遅い・集約は柔軟 | 異種OS混在・強い分離が必要 |
| コンテナ | カーネル共有・分離は弱め・軽量 | 高速起動・高い移植性 | マイクロサービス・高頻度デプロイ |
ひっかけ： 「コンテナはVMと同じく独自OSを持ち、VMと同等に強く分離される」は誤りです——コンテナはホストのカーネルを共有し、独自OSを持たないため軽量な代わりに分離はVMより弱いです。また「リアルタイム性が要る処理でも、全データを中央クラウドへ送って集中処理するのが常に最適」も誤り＝発生源近くで一次処理するエッジコンピューティングのほうが遅延と帯域の面で有利なことが多いです。
4.1.4この節のまとめ
- 配備モデルは要件で選ぶ：private＝統制/コンプラ、public＝弾力スケール、hybrid＝特性ごとに配置、edge＝発生源近くで低遅延
- エッジコンピューティングは生データを送らず現地で一次処理し、遅延・帯域・オフライン耐性を改善する
- 実行基盤はVM（独自OS・強分離・重い）／コンテナ（カーネル共有・軽量高移植・分離は弱い）／ベアメタル（直載せ・最高性能）を要件で使い分ける
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 全国50店舗の店内カメラ映像から混雑度をリアルタイムに推定して現場スタッフへ即時通知したい。広域回線の帯域は限られ、回線断でも各店舗は動作を続ける必要がある。配備の考え方として最も適切なものはどれか。
Q2. 店舗端末は限られたハードウェア上で、映像解析・POS連携・監視エージェントの複数アプリを高頻度に更新しながら同居させたい。「どこでも同じように動く」移植性と高速起動も重視する。実行基盤の選択として最も適切なものはどれか。
Q3. 機密性の高い会員購買データはコンプライアンス上、自社統制下に置く必要がある。一方で季節セール時にだけ解析負荷が数倍に跳ね上がる。コストと統制の両立を図る配備モデルとして最も適切なものはどれか。