Azure Bicep

解決する課題

Azure のインフラを ARM テンプレート（JSON）で直接書くと、冗長な記法・式の読みにくさ・依存関係の手書きが負担になります。Bicep は、同じ宣言的デプロイをより簡潔で読みやすく型安全な専用言語で書けるようにし、JSON の生産性問題を解消します。

• ARM テンプレートの JSON が冗長で読みにくく、レビューや差分確認がしづらい
• リソース間の依存関係を手作業で書くのが煩雑で、書き漏れも起きる
• 共通構成を部品として再利用し、環境ごとに差し替えたい
• パラメータの型ミスや必須漏れをデプロイ前に検出したい
• 既存の JSON 資産を捨てずに、段階的に移行したい

主要概念と用語

• Bicep: Azure リソースを宣言的に記述するためのドメイン固有言語（DSL）。デプロイ時に ARM テンプレート（JSON）へ変換される。新しいランタイムではなく、あくまで ARM 用テンプレートを生成する言語
• トランスパイル（ビルド）: Bicep ファイルを ARM テンプレート（JSON）へ変換する処理。az bicep build や、デプロイ時に内部で自動実行される
• デコンパイル（decompile）: 既存の ARM テンプレート（JSON）を Bicep へ逆変換する処理。移行の起点に使う
• リソース宣言: resource キーワードで Azure リソースを定義する単位。タイプと API バージョン、プロパティを記述する
• モジュール（module）: 別の Bicep ファイルを部品として読み込む仕組み。ネットワーク・ストレージなどを分割し再利用する単位
• パラメータ／変数／出力: 入力値・中間値・他テンプレートへ渡す戻り値を表す要素。パラメータには型・既定値・制約を付けられる
• 暗黙の依存関係: あるリソースが別リソースのプロパティを参照すると、Bicep が依存を自動推論して展開順序を決める。明示指定も可能
• デコレーター: パラメータや変数に付ける注釈。許可値・最小最大・説明・シークレット指定などを宣言する（記法はアットマーク始まり）
• スコープ: デプロイの適用範囲。リソース グループ／サブスクリプション／管理グループ／テナントの4階層
• Bicep レジストリ / Template Specs: モジュールを社内で共有・配布する仕組み。バージョン付きで再利用できる

仕様・制限・クォータ

• 宣言的かつべき等: あるべき状態を記述し、ARM が現状との差分を適用します。同じファイルを再実行しても結果は変わりません
• ARM テンプレートと等価: Bicep で表現できる範囲は ARM テンプレートと一致し、相互変換が可能です。Bicep から JSON への変換（ビルド）も、JSON から Bicep への逆変換（デコンパイル）もできます
• ステートレス: Bicep / ARM は外部に独自の状態ファイルを持たず、実際の状態は Azure 側に保持されます。この点が状態ファイルを持つツールと異なります
• デプロイ モード: 増分（既存を保持し記載分を追加・更新）と完全（記載外を削除）があり、既定は増分です。完全モードは意図しない削除に注意します
• 依存関係の自動推論: リソース間のプロパティ参照から依存を自動で解決し、可能なものは並列に展開します
• テンプレート / デプロイの上限: 1 回のデプロイで扱えるリソース数やテンプレート サイズ、パラメータ数などに上限があり、大規模構成はモジュール分割で回避します
• 具体的な上限値は時期やリソース種別で変わり得るため、設計時は最新の公式ドキュメントで確認します

内部の仕組み

Bicep ファイルはデプロイ時にまず ARM テンプレート（JSON）へトランスパイルされ、テンプレートとパラメータがデプロイとして Azure Resource Manager（ARM）に投入されます。実行エンジンは従来どおり ARM であり、Bicep 自体がリソースを操作するわけではありません。

ARM はテンプレート内のリソース間参照から依存グラフを構築し、依存のないリソースは並列に、依存のあるものは順序を守って各リソース プロバイダーへ展開を指示します。各リソースの作成・更新はべき等で、すでに望ましい状態にあるものは再作成されません。モジュールは、参照先の Bicep を入れ子のデプロイ（ネスト デプロイ）として展開する形に変換されます。

設計パターン / ベストプラクティス

• モジュール化: ネットワーク・ストレージ・アプリ層などをモジュールに分割し、環境ごとにパラメータで差し替える
• 環境分離: 同一テンプレートと環境別パラメータ ファイル（dev／staging／prod）で、構成差異をパラメータに閉じ込める
• what-if で事前確認: 本番適用前に必ず what-if を実行し、想定外の削除・変更を検出する
• デコレーターで入力を検証: 許可値・最小最大・必須を宣言し、誤ったパラメータをデプロイ前に弾く
• モジュールをレジストリで共有: 共通モジュールを Bicep レジストリや Template Specs にバージョン付きで公開し、組織で再利用する
• CI/CD 連携: ファイルを Git で管理し、GitHub Actions や Azure Pipelines から自動デプロイ（PR レビュー、what-if、適用）
• 段階的移行: 既存 JSON はデコンパイルで Bicep 化し、リント結果を見ながら手直しして移行する

運用・監視

• デプロイ履歴: スコープ単位でデプロイ履歴と各操作の成否・エラー詳細が記録され、失敗時の原因追跡に使える
• アクティビティ ログ: ARM 経由のすべてのコントロール プレーン操作が証跡として残る（AWS の CloudTrail 相当）
• リント（Bicep linter）: 記法や非推奨パターンを静的に検査し、ビルド時に警告を出す。CI に組み込んで品質を保つ
• 失敗の切り分け: プロバイダー未登録、クォータ超過、RBAC 権限不足、API バージョン不一致が典型的な失敗要因
• ドリフト対策: ポータルでの手動変更がテンプレートと乖離する「ドリフト」を、what-if や定期的な再デプロイで検出・是正する

コスト

Bicep と ARM によるデプロイ操作そのものは無償です。課金が発生するのは、テンプレートが作成した個々のリソース（仮想マシン・ストレージなど）であり、IaC レイヤーには直接の利用料金はありません。コスト最適化の観点では、SKU・サイズ・冗長性をパラメータ化し、環境ごとに過剰なリソースを作らないことが重要です。

セキュリティ

• 認可は RBAC: デプロイは Microsoft Entra ID と Azure RBAC で認可されます。実行者やパイプラインのサービス プリンシパルには最小権限を割り当てます
• シークレットを直書きしない: 接続文字列やパスワードはファイルにハードコードせず、Azure Key Vault 参照でデプロイ時に注入します
• secure パラメータを使う: パスワードやキーのパラメータにはシークレット指定のデコレーターを付け、ログや出力に値が残らないようにします
• マネージド ID をパイプラインに使い、長期資格情報の保存を避けます
• Azure Policy で許可リージョン・SKU・命名規約などを強制し、テンプレートの逸脱や手動変更を防ぎます

関連サービス・比較

Bicep は ARM テンプレート（JSON）を生成する言語で、ランタイムである ARM とは役割が分かれています。記述言語としての立ち位置は AWS の CloudFormation テンプレートに対応し、簡潔な専用言語という性格は CDK に近い側面もあります。

ハンズオン / CLI例

# Bicep CLI を準備（Azure CLI に同梱、初回は自動取得）
az bicep version

# Bicep ファイルを ARM テンプレート（JSON）へビルド
az bicep build --file main.bicep

# リソース グループを作成
az group create --name demo-rg --location japaneast

# 適用前に変更内容を事前確認（what-if）
az deployment group what-if \
  --resource-group demo-rg \
  --template-file main.bicep \
  --parameters env=dev

# Bicep ファイルをリソース グループ スコープにデプロイ（既定は増分モード）
az deployment group create \
  --resource-group demo-rg \
  --name infra-deploy \
  --template-file main.bicep \
  --parameters @dev.parameters.json

# 既存 ARM テンプレート（JSON）を Bicep へ逆変換
az bicep decompile --file azuredeploy.json