きっかけ

以前、当ブログで以下の記事が投稿されました↓ tech.kentem.jp

ほうほう、Bicepでリソース管理すれば環境作成も容易になると・・。
自プロジェクトは他プロジェクトで作成しているアプリとの関連が強く、様々な環境でリソースが作成されています。
環境作成の手順について質問されることもしばしば。
こんな状況にBicep、うってつけでは？
ということでBicep導入してみました！

Bicepって何？

BicepはMicrosoftが開発したドメイン特化言語（DSL）で、Azure Resource Manager（ARM）テンプレートを簡潔に記述するためのものです。
詳しい内容は前述の記事で説明されておりますので、未履修の方はぜひそちらをご覧ください！

モジュール化してみる

一通りのリソースを定義したところで、同じような定義があることに気づきました。

param environment string = 'dev'
param location string = 'japaneast'

// フロントエンド用App Service Plan
resource frontendAppServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: '${environment}-frontend-plan'
  location: location
  sku: {
    name: environment == 'prod' ? 'P1V2' : 'B1'
    tier: environment == 'prod' ? 'PremiumV2' : 'Basic'
  }
  properties: {
    reserved: false
  }
}

// フロントエンド用App Service 1
resource frontendApp1 'Microsoft.Web/sites@2022-03-01' = {
  name: '${environment}-frontend-app1'
  location: location
  properties: {
    serverFarmId: frontendAppServicePlan.id
    httpsOnly: true
  }
}

// フロントエンド用App Service 2
resource frontendApp2 'Microsoft.Web/sites@2022-03-01' = {
  name: '${environment}-frontend-app2'
  location: location
  properties: {
    serverFarmId: frontendAppServicePlan.id
    httpsOnly: true
  }
}

// バックエンド用App Service Plan
resource backendAppServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: '${environment}-backend-plan'
  location: location
  sku: {
    name: environment == 'prod' ? 'P1V2' : 'B1'
    tier: environment == 'prod' ? 'PremiumV2' : 'Basic'
  }
  properties: {
    reserved: false
  }
}

// バックエンド用App Service 1
resource backendApi1 'Microsoft.Web/sites@2022-03-01' = {
  name: '${environment}-backend-api1'
  location: location
  properties: {
    serverFarmId: backendAppServicePlan.id
    httpsOnly: true
  }
}

// バックエンド用App Service 2
resource backendApi2 'Microsoft.Web/sites@2022-03-01' = {
  name: '${environment}-backend-api2'
  location: location
  properties: {
    serverFarmId: backendAppServicePlan.id
    httpsOnly: true
  }
}

// 出力
output frontendAppServiceUrls array = [
  'https://${frontendApp1.properties.defaultHostName}'
  'https://${frontendApp2.properties.defaultHostName}'
]

output backendAppServiceUrls array = [
  'https://${backendApi1.properties.defaultHostName}'
  'https://${backendApi2.properties.defaultHostName}'
]

App Service Plan と App Service のリソース定義、何回もやってます。
ここで便利なのがモジュールという機能です。
モジュールとは、複数の関連リソースを1つのファイルにまとめて再利用可能にする仕組みのことです。
個人的には冗長なpublicメソッドをprivateメソッドに分ける作業に近いなと感じています。

param location string = 'japaneast'
param appServicePlanName string
param appServiceNames array = []
param sku object = {
  name: 'B1'
  tier: 'Basic'
}

resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: appServicePlanName
  location: location
  sku: sku
  properties: {
    reserved: false // Windowsの場合はfalse、Linuxの場合はtrue
  }
}

resource appServices 'Microsoft.Web/sites@2022-03-01' = [for name in appServiceNames: {
  name: name
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}]

output appServicePlanId string = appServicePlan.id
output appServiceUrls array = [for (name, i) in appServiceNames: 'https://${appServices[i].properties.defaultHostName}']

このモジュールを使用するメインのBicepファイルは次のようになります。

param environment string = 'dev'
param location string = 'japaneast'

// フロントエンド用App Service
module frontendAppService 'appservice.bicep' = {
  name: 'frontend-appservice-deployment'
  params: {
    appServicePlanName: '${environment}-frontend-plan'
    location: location
    appServiceNames: [
      '${environment}-frontend-app1'
      '${environment}-frontend-app2'
    ]
    sku: {
      name: environment == 'prod' ? 'P1V2' : 'B1'
      tier: environment == 'prod' ? 'PremiumV2' : 'Basic'
    }
  }
}

// バックエンド用App Service
module backendAppService 'appservice.bicep' = {
  name: 'backend-appservice-deployment'
  params: {
    appServicePlanName: '${environment}-backend-plan'
    location: location
    appServiceNames: [
      '${environment}-backend-api1'
      '${environment}-backend-api2'
    ]
    sku: {
      name: environment == 'prod' ? 'P1V2' : 'B1'
      tier: environment == 'prod' ? 'PremiumV2' : 'Basic'
    }
  }
}

output frontendAppServiceUrls array = frontendAppService.outputs.appServiceUrls
output backendAppServiceUrls array = backendAppService.outputs.appServiceUrls

かなり読みやすくなりました！
「module」と書くことで、他のBicepファイルをモジュールとして呼び出すことが可能です。

パラメータファイルを使ってみる

パラメータファイルは、Bicepファイルで定義したパラメータに値を指定するためのJSONファイルです。
Bicepファイルの拡張子は.bicepで、関連するパラメータファイルは.bicepparamという拡張子で作成します。

using 'main.bicep'

param environment string = 'dev'
param location string = 'japaneast'

using で「どのBicepファイルのパラメータか？」という宣言をします。
Bicepファイルとパラメータファイルは1:Nの関係で、1つのBicepファイルに対して、複数のパラメータファイルを作成することが可能です。

モジュールにはパラメータファイルを紐づけられない？

Bicepファイルを分割しモジュールとして読み込むことができたので、モジュール化したBicepファイルに対してパラメータファイルを設定したいと思い、いろいろ試してみました。
しかし、執筆当時の2025年9月時点では以下のような制約がありました。

モジュール化したファイルに対してパラメータファイルを直接適用することはできない
パラメータファイルにパラメータファイルを紐づけることはできない

モジュールをインポートしているメインのBicepファイルのパラメータファイルからしか、モジュールのパラメータを設定できませんでした・・・。
そのため、ひとつのパラメータファイルに各モジュールで利用するパラメータ定義をまとめるという方法で乗り切りました。

やってみてどうだったか？

最初は少し理解に時間がかかりましたが、慣れてしまえばとても効率の良い管理方法だと感じました。
パラメータファイルも制約があってひとつにまとまってしまいましたが、「実行時に変更が必要になるのがそのファイルだけ」という扱いにできてかえってよかったのかもしれません。
これからいろんな方に環境構築していただいて、ブラッシュアップしていきたいです。