変更要約: AZ-140 第2章を新規作成（ドメイン1後半: ホストプールアーキテクチャ(プール型/個人型・breadth/depth 負荷分散・Windows Enterprise multi-session・RDS CAL/Windows アクセス資格・リソース編成・VM 容量設計)、実装(Azure portal ウィザード・登録トークン・PowerShell/Azure CLI/ARM テンプレート/Bicep IaC・検証環境フラグ)、セッションホストイメージ(手動/Sysprep・Azure VM Image Builder・Azure Compute Gallery のバージョン管理/レプリケーション・更新ライフサイクル/再作成)）。
2.3セッションホストイメージ
セッションホストイメージの手動作成、Azure VM Image Builder による作成、イメージの変更とライフサイクル管理、OS/アプリ更新の適用、カスタムイメージからのセッションホスト作成、Azure Compute Gallery によるイメージ保管を理解します。
セッションホストを「アプリと設定が入った状態」で量産するには、カスタムイメージ を使います。全ホストが同一の黄金イメージから作られることで、一貫性と保守性が高まります。
2.3.1イメージの作成（手動 / VM Image Builder）
手動 では、VM を起動してアプリ導入・設定・一般化（Sysprep）し、イメージ化します。繰り返しや自動化には Azure VM Image Builder（テンプレートでビルドを宣言的に定義し、カスタマイズ手順を自動実行）を使います。VM Image Builder は「コードでイメージを再現可能にビルド」したい要件に向き、手作業の Sysprep より一貫性が高くなります。
2.3.2Azure Compute Gallery とライフサイクル
Azure Compute Gallery（旧 Shared Image Gallery）は、イメージを バージョン管理 し、複数リージョンへ レプリケーション、複数の VM/サブスクリプションへ大規模配布します。単一の管理対象イメージより、版管理とスケール配布に優れます。イメージの ライフサイクル管理 は「OS/アプリ更新を適用 → 新バージョンを発行 → 新バージョンでセッションホストを再作成（または追加） → 旧版を段階的に廃止」のサイクルで、セキュリティ更新を全ホストに行き渡らせます。
決め手：「コードで再現可能にイメージをビルド」＝Azure VM Image Builder。「イメージをバージョン管理し複数リージョン/大規模配布」＝Azure Compute Gallery。手動は Sysprep で一般化。更新は新バージョン発行→セッションホスト再作成のサイクル。
混同に注意：
①VM Image Builder(ビルドの自動化)と Compute Gallery(保管/版管理/配布)は役割が違い併用する。
②手動イメージは Sysprep での一般化が必須＝忘れると複製で SID 重複等の問題。
③更新は「稼働中ホストにパッチ」より「新イメージ版で再作成」が AVD の定石。
2.3.3この節のまとめ
- カスタムイメージ＝手動(Sysprep で一般化) か Azure VM Image Builder(コードで再現可能にビルド)
- Azure Compute Gallery＝イメージのバージョン管理/複数リージョンレプリケーション/大規模配布
- 更新は新バージョン発行→セッションホスト再作成のライフサイクルで全ホストに反映
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. アプリと設定を組み込んだセッションホストイメージを、テンプレートでコードから再現可能にビルドしたい。最適なのはどれですか？
Q2. カスタムイメージをバージョン管理し、複数リージョンへレプリケーションして大規模に配布したい。最適なのはどれですか？
Q3. カスタムイメージを手動で作成する際、複製時の SID 重複などを避けるために必須の手順はどれですか？
Q4. セッションホストに OS/アプリのセキュリティ更新を行き渡らせる AVD の定石はどれですか？
Q5. VM Image Builder と Azure Compute Gallery の関係として正しいのはどれですか？