Bicep

Bicepとは

Bicep は、Azure のリソースを宣言的に定義する言語です。[[IaC]] のうち Azure 専用の選択肢にあたります。

Azure には元々 ARM テンプレートという JSON 形式の定義がありましたが、JSON は人が書くには冗長でした。Bicep はそれを読み書きしやすい構文に置き換えたもので、ビルドすると ARM テンプレートの JSON になります。

param location string = resourceGroup().location

resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'stg${uniqueString(resourceGroup().id)}'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

output storageId string = storage.id

同じ内容を ARM テンプレートで書くと、入れ子の JSON と文字列連結で数倍の長さになります。Bicep は新しい仕組みではなく、既存の仕組みへの入口を書きやすくしたものと捉えると位置づけが掴めます。

Terraformとの違い

同じ IaC でも、性格がはっきり違います。

	Bicep	Terraform
対象	Azure 専用	複数のクラウド・SaaS
状態の管理	Azure 側が持つ(state ファイル不要)	自分で state を管理する
差分の確認	`what-if` で事前確認	`plan` で事前確認
新機能への追随	Azure の API 定義から自動生成され速い	プロバイダの実装を待つ

最大の実務的な差は state ファイルを持たないことです。Terraform では state の保管場所・ロック・破損時の復旧が運用の課題になりますが、Bicep はデプロイの履歴を Azure 側が保持します。その代わり Azure から出られません。

選択の基準はAzure だけで完結するかです。マルチクラウドや SaaS の設定まで含めるなら Terraform、Azure 専用でチームも Azure 中心なら Bicep のほうが摩擦が少なくなります。

モジュールで再利用する

繰り返す構成は別ファイルへ切り出し、モジュールとして呼び出します。

module network './modules/vnet.bicep' = {
  name: 'network'
  params: { location: location, addressPrefix: '10.0.0.0/16' }
}

依存関係は自動で解決されます。 あるリソースが別のリソースの出力を参照していれば、Bicep がその順序でデプロイします。順序を手で書く必要はなく、書いてしまうと実態とずれたときに壊れます。

実務での注意点

what-if を必ず通す — 適用前に差分を出します。既存リソースの再作成(=一度消える)が含まれていないかを、ここで確認します
デプロイの単位を決める — サブスクリプション単位・リソースグループ単位でスコープが変わります。スコープを間違えると「作られない」ではなく「別の場所に作られる」ことがあります
[[CI/CD]] に載せる — 手元からの適用は誰が何をしたか残りません。PR とパイプライン経由に寄せます
命名の一意性 — ストレージアカウント名などは世界全体で一意です。uniqueString() で衝突を避ける書き方が定番です

関連技術とのつながり

[[IaC]] — 宣言的にインフラを定義する考え方。Bicep はその Azure 実装
[[クラウドコンピューティング]] — 定義の対象となる基盤
[[CI/CD]] — 適用を自動化し、変更を追跡可能にする
[[YAML]] — パイプライン定義側で組み合わせる書式
[[Azure SDK for Python]] — 構築後のリソースをプログラムから操作する側

Q: BicepとARMテンプレートの関係として正しいのはどれ?
- [ ] Bicepは全く別のデプロイ基盤を使う
- [x] BicepはビルドするとARMテンプレートのJSONになる
- [ ] ARMテンプレートがBicepへ変換されてから実行される
解説: 仕組み自体は同じで、Bicepは読み書きしやすい構文を与えたものです。

Q: BicepがTerraformと違ってstateファイルを持たない理由はどれ?
- [ ] 差分を計算しないから
- [x] デプロイの履歴をAzure側が保持しているから
- [ ] 毎回すべてを作り直しているから
解説: state の保管・ロック・復旧という運用課題が無い代わりに、Azure から出られません。

Q: Bicepでリソースのデプロイ順序を明示的に書く必要が無いのはなぜ?
- [x] 出力を参照している関係から依存を自動で解決するため
- [ ] すべて同時にデプロイされるため
- [ ] 順序はファイルの記述順で決まるため
解説: 手で順序を書くと実態とずれたときに壊れます。参照関係に任せるのが正しい書き方です。