Azure Verified Modulesで進めるインフラ標準化：連載案内
別のチームから同じ検証用の仮想マシン（以下、VM）が欲しいと言われたとき、前回と同じ構成をどこで確かめ、誰が作成と返却を担当するのでしょうか。この連載は、その問いから始めます。
導入編では、Azure Portalでの構築からBicepによるコード管理に進み、複数チームで共通部品を保守する場面を考えます。本編では、Azure Verified Modules（以下、AVM）でその部品を利用し、実際に構成を比べ、払い出しと返却まで確かめた順に読み進めます。
読む順番
| 順番 | 記事 | 読みどころ |
|---|---|---|
| 導入編 | AzureでCIを始めると、なぜBicepを書き、Azure Verified Modulesを使うのか | 同じ検証用VMを複数チームへ渡す例で、インフラのコード化、共通部品の保守、自社の責任を整理します。 |
| 第1回 | Azure Verified Modulesで進めるインフラ標準化①：VMとVPNのどこを共通部品に任せるか（公開予定） | 検証用VMとVPNの構成を例に、部品に任せる実装と自社で判断する設定を整理します。 |
| 第2回 | Azure Verified Modulesで進めるインフラ標準化②：同じVMとVPNを2方式で作って比べる（公開予定） | 直接定義とモジュールを使う方式を、記述量、実際の構成、接続結果で比べます。 |
| 第3回 | Azure Verified Modulesで進めるインフラ標準化③：比較した構成を、申請した人へ渡す（公開予定） | 比較で使った構成を再利用し、申請、承認、構築、接続情報の引き渡しを確かめます。 |
| 第4回 | Azure Verified Modulesで進めるインフラ標準化④：作成の権限を絞り、返却まで確かめる（公開予定） | 専用の固定枠へ操作範囲を絞り、作成と返却を検証します。継続利用の運営案も扱います。 |
| 第5回（番外編） | Azure Verified Modulesで進めるインフラ標準化⑤：次の検証にも使える確認の進め方（公開予定） | 比較条件、結果の残し方、バージョン、権限と返却の確認を整理します。 |
検証の範囲
2026年11月6日〜8日に、Bicepの直接定義版とAVM版でVMとVPNを構築し、展開予測、実リソース、接続を比較しました。次に、GitHub Issueの入力検査、承認、払い出し、プロファイル取得、接続、返却を確認しました。その後の固定枠方式では、権限を限定した状態で予約、展開、プロファイルの受け渡し、削除と枠の解放までを確認しています。固定枠での接続再試験は記録されていません。
各回では、実行結果が残る範囲を示します。期限切れの定期削除は実装と判定テストまでです。複数チームでの継続運営、モジュールの更新手順、効果の測り方は、検証を踏まえた提案として扱います。Bicepを初めて読む場合は、公式入門でparam、resource、moduleの役割を押さえるとコードを追いやすくなります。[1]