変更要約: 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.2ホストプールとセッションホストの実装
Azure portal でのホストプール/セッションホストの作成、PowerShell・Azure CLI・ARM テンプレート・Bicep による自動作成、ホストプール/セッションホスト設定とライセンス構成を理解します。
計画ができたら実装します。少数の検証は Azure portal、本番の繰り返し可能な展開は コードによる自動化 を使い分けます。
2.2.1作成と登録
Azure portal ではウィザードでホストプール・ワークスペース・アプリケーショングループ・セッションホストをまとめて作成できます。セッションホスト（VM）は 登録トークン でホストプールに参加します（AVD エージェントがトークンで登録）。設定では最大セッション数、負荷分散、検証環境フラグ、RDP プロパティ（次章）などを構成し、ライセンス（マルチセッションの Windows アクセス資格）を確認します。
2.2.2IaC による自動化
反復可能・大規模な展開は PowerShell（Az.DesktopVirtualization 等）・Azure CLI・ARM テンプレート・Bicep で自動化します。ARM テンプレート（JSON）と Bicep（その簡潔な DSL）は宣言的にホストプール/セッションホストを定義し、CI/CD で再現性のある展開を可能にします。「ポータルの手作業を避け、コードで再現可能に」が要件なら IaC を選びます。手作業（portal）とコード（IaC）を規模で使い分けます。
決め手：「少数・対話的に作成」＝Azure portal ウィザード。「反復可能・大規模・CI/CD で再現」＝IaC（PowerShell/CLI/ARM/Bicep）。セッションホストは登録トークンでホストプールに参加。Bicep は ARM テンプレートの簡潔な DSL。
混同に注意：
①登録トークンは期限付き＝期限切れだとセッションホストが参加できない。
②ARM テンプレート(JSON)と Bicep(DSL)は同じデプロイ基盤＝Bicep は ARM にコンパイルされる。
③検証環境フラグはサービス更新を先行受信する設定で本番には付けない。
2.2.3この節のまとめ
- portal ウィザード＝少数・対話的、IaC(PowerShell/CLI/ARM/Bicep)＝反復可能・大規模・CI/CD で再現
- セッションホストは登録トークン(期限付き)でホストプールに参加
- Bicep は ARM テンプレートの簡潔な DSL（同じデプロイ基盤）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 本番の AVD 環境を、CI/CD で再現可能・宣言的に繰り返し展開したい。最適なのはどれですか？
Q2. セッションホスト（VM）がホストプールに参加するために必要なものはどれですか？
Q3. セッションホストが登録できない。登録トークン関連で最も疑うべき原因はどれですか？
Q4. ARM テンプレートと Bicep の関係として正しいのはどれですか？
Q5. 少数のセッションホストを対話的に素早く作成したい。最適なのはどれですか？