Bicep モジュール

Bicep を使用すると、デプロイをモジュールにまとめることができます。モジュールは、別の Bicep ファイルがデプロイする Bicep ファイルです。モジュールには、JSON 用の Azure Resource Manager テンプレート (ARM テンプレート) を指定することもできます。モジュールを使用すると、デプロイの複雑な詳細をカプセル化することで、Bicep ファイルの読みやすさが向上します。また、モジュールを異なるデプロイに簡単に再利用することもできます。

組織内の他のユーザーとモジュールを共有するには、テンプレートスペックまたはプライベートレジストリを作成します。レジストリ内のテンプレートスペックとモジュールは、適切なアクセス許可を持つユーザーのみが使用できます。

Tip

モジュールレジストリとテンプレートスペックの選択は、ほとんど好みの問題です。 2 つのオプションのいずれかを選択するときは、次の点を考慮してください。

モジュールレジストリをサポートするのはBicepだけです。 Bicepを使用していない場合は、テンプレートスペックを使用します。
Bicep モジュールレジストリ内のコンテンツは、別の Bicep ファイルからのみデプロイできます。テンプレートスペックは、API、Azure PowerShell、Azure CLI、Azure portal から直接デプロイできます。 UiFormDefinition を使用して、ポータルのデプロイエクスペリエンスをカスタマイズすることさえできます。
Bicep には、 loadTextContent 関数と loadFileAsBase64 関数を使用して、他のプロジェクト成果物 (Bicep 以外のファイルや PowerShell スクリプト、CLI スクリプトなどの ARM 以外のテンプレートファイルなど) を埋め込むためのいくつかの制限付き機能があります。テンプレートスペックでは、これらのアーティファクトをパッケージ化することはできません。

Bicep モジュールは、入れ子になったテンプレートを持つ単一の ARM テンプレートに変換されます。 Bicep が構成ファイルを解決する方法と、Bicep がユーザー定義の構成ファイルを既定の構成ファイルとマージする方法の詳細については、「構成ファイル解決プロセスと構成ファイルのマージプロセス」を参照してください。

モジュールを定義する

モジュールを定義するための基本的な構文は次のとおりです。

@<decorator>(<argument>)
module <symbolic-name> '<path-to-file>' = {
  name: '<linked-deployment-name>'
  params: {
    <parameter-names-and-values>
  }
}

単純で実際の例は次のようになります。

module stgModule '../storageAccount.bicep' = {
  name: 'storageDeploy'
  params: {
    storagePrefix: 'examplestg1'
  }
}

JSON 用の ARM テンプレートをモジュールとして使用することもできます。

module stgModule '../storageAccount.json' = {
  name: 'storageDeploy'
  params: {
    storagePrefix: 'examplestg1'
  }
}

Bicep ファイルの別の部分にあるモジュールを参照するには、シンボリック名を使用します。たとえば、シンボリック名を使用して、モジュールからの出力を取得できます。シンボリック名には、a - z、A - Z、0 - 9、アンダースコア (_) を含めることができます。名前の先頭を数字にすることはできません。モジュールの名前を、パラメーター、変数、またはリソースと同じにすることはできません。

パスは、ローカルファイルでもレジストリ内のファイルでもかまいません。ローカルファイルには、Bicep ファイルまたは JSON 用の ARM テンプレートを指定できます。詳細については、「モジュールへのパス」を参照してください。

name プロパティは省略可能です。生成されるテンプレートでは、それは入れ子になったデプロイリソースの名前になります。名前が指定されていない場合は、入れ子になったデプロイリソースの名前として GUID が生成されます。

静的名を持つモジュールを同じスコープに同時にデプロイすると、1 つのデプロイがもう一方のデプロイからの出力に干渉する可能性があります。たとえば、2 つの Bicep ファイルが同じ静的名 (examplemodule) を持つ同じモジュールを使用し、同じリソースグループを対象としている場合、1 つのデプロイで間違った出力が表示される可能性があります。同じスコープへの同時デプロイが心配な場合は、モジュールに一意の名前を付けてください。一意のモジュール名を確保するもう 1 つの方法は、 name プロパティを除外することです。一意のモジュール名が自動的に生成されます。 no-module-nameリンター規則は、明示的なname プロパティを含むモジュールにフラグを設定することで、このよりクリーンなコーディング手法を適用するように設計されています。

次の例では、デプロイ名をモジュール名に連結します。デプロイに一意の名前を指定すると、モジュール名も一意です。

module stgModule 'storageAccount.bicep' = {
  name: '${deployment().name}-storageDeploy'
  scope: resourceGroup('demoRG')
}

モジュール名を指定しないのも有効です。 GUID はモジュール名として生成されます。

module stgModule 'storageAccount.bicep' = {
  scope: resourceGroup('demoRG')
}

メインファイルのスコープとは異なる スコープを指定 する必要がある場合は、スコーププロパティを追加します。詳細については、「モジュールのスコープを設定する」を参照してください。

// deploy to different scope
module <symbolic-name> '<path-to-file>' = {
  name: '<linked-deployment-name>'
  scope: <scope-object>
  params: {
    <parameter-names-and-values>
  }
}

モジュールを条件付きでデプロイするには、if 式を追加します。これは、リソースを条件付きでデプロイするのと似ています。

// conditional deployment
module <symbolic-name> '<path-to-file>' = if (<condition-to-deploy>) {
  name: '<linked-deployment-name>'
  params: {
    <parameter-names-and-values>
  }
}

モジュールの複数のインスタンスをデプロイするには、for 式を追加します。 batchSizeデコレーターを使用して、インスタンスを順次デプロイするか並列にデプロイするかを指定します。詳細については、「Bicep の反復ループ」を参照してください。

// iterative deployment
@batchSize(int) // optional decorator for serial deployment
module <symbolic-name> '<path-to-file>' = [for <item> in <collection>: {
  name: '<linked-deployment-name>'
  params: {
    <parameter-names-and-values>
  }
}]

リソースと同様に、モジュールは、他のモジュールやリソースに依存しない限り、並列でデプロイされます。通常、依存関係は暗黙的に決定されるため、設定する必要はありません。明示的な依存関係を設定する必要がある場合は、モジュール定義に dependsOn を追加します。依存関係の詳細については、「 Bicep のリソースの依存関係」を参照してください。

module <symbolic-name> '<path-to-file>' = {
  name: '<linked-deployment-name>'
  params: {
    <parameter-names-and-values>
  }
  dependsOn: [
    <symbolic-names-to-deploy-before-this-item>
  ]
}

モジュールへのパス

モジュールには、ローカルファイルまたは外部ファイルを使用できます。外部ファイルは、テンプレートスペックまたは Bicep モジュールレジストリで見つけることができます。

ローカルファイル

モジュールがローカルファイルの場合は、そのファイルへの相対パスを指定します。 Bicepでは、プラットフォーム間で一貫したコンパイルを行うには、すべてのパスにスラッシュ (/) ディレクトリ区切り記号を使用する必要があります。 Windows の円記号 (\) 文字はサポートされていません。パスにはスペースを含めることができます。

メインファイルからディレクトリ内で 1 レベル上のファイルをデプロイするには、次の例を使用します。

module stgModule '../storageAccount.bicep' = {
  name: 'storageDeploy'
  params: {
    storagePrefix: 'examplestg1'
  }
}

レジストリ内のファイル

パブリックおよびプライベートモジュールレジストリがあります。

パブリックモジュールレジストリ

Note

Azure 以外の検証済みモジュールは、パブリックモジュールレジストリから廃止されます。

Azure 検証済みモジュールは、事前構築済み、事前テスト済み、および事前検証済みのモジュールであり、Azure にリソースをデプロイするために使用できます。 Microsoft の従業員は、これらのモジュールを作成して所有しています。一般的なAzureリソースと構成のデプロイプロセスを簡略化し、高速化します。モジュールは、Azure Well-Architected Framework などのベストプラクティスにも合わせて調整されます。

Bicep モジュールを参照して、利用可能なモジュールの一覧を確認できます。次のスクリーンショットで強調表示されている番号を選択して、フィルター処理されたビューに直接移動します。

Azure 検証済みモジュールを示すスクリーンショット。

モジュールの一覧に最新バージョンが表示されます。使用可能なバージョンの一覧を表示するには、バージョン番号を選択します。

Azure 検証済みモジュールのバージョンを示すスクリーンショット。

パブリックモジュールにリンクするには、次の構文でモジュールパスを指定します。

module <symbolic-name> 'br/public:<file-path>:<tag>' = {}

br/public: これはパブリックモジュールのエイリアスです。このエイリアスは、Bicep 構成ファイルでカスタマイズできます。
ファイルパス: / 文字で区切ったセグメントを含めることができます。
tag: モジュールのバージョンを指定します。

例えば次が挙げられます。

module storage 'br/public:avm/res/storage/storage-account:0.18.0' = {
  name: 'myStorage'
  params: {
    name: 'store${resourceGroup().name}'
  }
}

Note

パブリックモジュールのエイリアスは br/public。次のように記述することもできます。

module <symbolic-name> 'br:mcr.microsoft.com/bicep/<file-path>:<tag>' = {}

プライベートモジュールレジストリ

モジュールをレジストリに発行した場合は、そのモジュールにリンクできます。 Azure コンテナーレジストリの名前とモジュールへのパスを指定します。モジュールのパスは次の構文で指定します。

module <symbolic-name> 'br:<registry-name>.azurecr.io/<file-path>:<tag>' = {

br: これは、Bicep レジストリのスキーム名です。
ファイルパス: これは Azure Container Registry の repository と呼ばれます。ファイルパスには、 / 文字で区切られたセグメントを含めることができます。
tag: モジュールのバージョンを指定します。

例えば次が挙げられます。

module stgModule 'br:exampleregistry.azurecr.io/bicep/modules/storage:v1' = {
  name: 'storageDeploy'
  params: {
    storagePrefix: 'examplestg1'
  }
}

レジストリ内のモジュールを参照すると、Visual Studio Code の Bicep 拡張機能は自動的に bicep restore を呼び出して、外部モジュールをローカルキャッシュにコピーします。外部モジュールが復元されるまで、しばらく時間がかかります。モジュールの IntelliSense がすぐに機能しない場合は、復元が完了するまで待ちます。

レジストリ内のモジュールの完全なパスは長くなる場合があります。モジュールを使用するたびに完全なパスを指定する代わりに、 bicepconfig.json ファイルでエイリアスを構成します。エイリアスを使用すると、モジュールの参照が簡単になります。たとえば、エイリアスを使用すると、パスを次のように短縮できます。

module stgModule 'br/ContosoModules:storage:v1' = {
  name: 'storageDeploy'
  params: {
    storagePrefix: 'examplestg1'
  }
}

パブリックモジュールレジストリには、定義済みのエイリアスがあります。

module storage 'br/public:avm/res/storage/storage-account:0.18.0' = {
  name: 'myStorage'
  params: {
    name: 'store${resourceGroup().name}'
  }
}

bicepconfig.json ファイル内のパブリックエイリアスをオーバーライドできます。

Bicep CLI v0.43.1 以降では、Bicepは、Azure Container Registry (ACR) からモジュールを参照または復元するときに、カスタムドメインの使用を明示的にブロックします。このセーフガードにより、サポートされていない構成が使用されなくなり、それ以外の場合はコンプライアンスの問題が発生します。

moduleStore.myCompany.comなどのカスタムドメインを参照しようとすると、Bicep CLI は診断エラー BCP446 を返します。例えば次が挙げられます。

module foo 'br:moduleStore.myCompany.com/networking/hub:1.0.0' = { ... }

Bicepは、組み込みの許可リストに対してすべてのレジストリホスト名を検証します。現時点では、次のドメインのみが許可されています。

*.azurecr.io
*.azurecr.cn
*.azurecr.us
mcr.microsoft.com
mcr.azure.cn
ghcr.io

組織でカスタムドメインを使用している場合は、次の制限に従ってBicep ファイルを更新します。

ネイティブホスト名に戻す:ネイティブ .azurecr.io (または関連するクラウド固有) ドメインを使用するように、すべてのBicepモジュール参照を更新します。
ローカルキャッシュをクリアします。 参照を更新した後、ローカルモジュールキャッシュをクリアすることが必要になる場合があります。修正されたネイティブホスト名を使用してモジュールをプルするには、 bicep restore をもう一度実行します。

テンプレートスペックのファイル

テンプレートスペックを作成したら、モジュールでそのテンプレートスペックにリンクします。テンプレートスペックを次の形式で指定します。

module <symbolic-name> 'ts:<sub-id>/<rg-name>/<template-spec-name>:<version>' = {

Bicep ファイルを簡略化するには、テンプレートスペックを含むリソースグループのエイリアスを作成します。エイリアスを使用すると、構文は次のようになります。

module <symbolic-name> 'ts/<alias>:<template-spec-name>:<version>' = {

次のモジュールでは、ストレージアカウントを作成するテンプレートスペックをデプロイします。テンプレートスペックのサブスクリプションとリソースグループは、 ContosoSpecsという名前のエイリアスで定義されます。

module stgModule 'ts/ContosoSpecs:storageSpec:2.0' = {
  name: 'storageDeploy'
  params: {
    storagePrefix: 'examplestg1'
  }
}

デコレーターを使用する

@expression形式でデコレーターを記述し、モジュール宣言の上に配置します。次の表に、モジュールで使用できるデコレーターを示します。

Decorator	Argument	Description
batchSize	none	順番にデプロイするようにインスタンスを設定します。
description	文字列	モジュールの説明を指定します。

デコレーターは、sys 名前空間にあります。デコレーターと同じ名前の別のアイテムを区別する必要がある場合は、デコレーターの前に sys を付けます。たとえば、Bicep ファイルに description という名前のパラメーターが含まれている場合は、sys デコレーターを使用するときに、description名前空間を追加する必要があります。

BatchSize

@batchSize()は、for式を使用するリソースまたはモジュール定義にのみ適用できます。

既定では、デプロイエンジンはモジュールを並列にデプロイします。 @batchSize(int) デコレーターを追加する場合、インスタンスを順次にデプロイします。

@batchSize(3)
module storage 'br/public:avm/res/storage/storage-account:0.11.1' = [for storageName in storageAccounts: {
  name: 'myStorage'
  params: {
    name: 'store${resourceGroup().name}'
  }
}]

詳細については、「バッチでのデプロイ」を参照してください。

Description

説明を追加するには、モジュールの宣言に description を追加します。例えば次が挙げられます。

@description('Create storage accounts referencing an AVM.')
module storage 'br/public:avm/res/storage/storage-account:0.18.0' = {
  name: 'myStorage'
  params: {
    name: 'store${resourceGroup().name}'
  }
}

説明のテキストとして Markdown 形式のテキストを使用できます。

Parameters

モジュールの定義で指定するパラメーターは、Bicep ファイル内のパラメーターと一致します。

次の Bicep の例には、 storagePrefix、 storageSKU、 locationの 3 つのパラメーターがあります。 storageSKU パラメーターには既定値があるため、デプロイ時にそのパラメーターの値を指定する必要はありません。

@minLength(3)
@maxLength(11)
param storagePrefix string

@allowed([
  'Standard_LRS'
  'Standard_GRS'
  'Standard_RAGRS'
  'Standard_ZRS'
  'Premium_LRS'
  'Premium_ZRS'
  'Standard_GZRS'
  'Standard_RAGZRS'
])
param storageSKU string = 'Standard_LRS'

param location string

var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'

resource stg 'Microsoft.Storage/storageAccounts@2025-06-01' = {
  name: uniqueStorageName
  location: location
  sku: {
    name: storageSKU
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

output storageEndpoint object = stg.properties.primaryEndpoints

前の例をモジュールとして使用するには、それらのパラメーターの値を指定します。

targetScope = 'subscription'

@minLength(3)
@maxLength(11)
param namePrefix string

resource demoRG 'Microsoft.Resources/resourceGroups@2025-04-01' existing = {
  name: 'demogroup1'
}

module stgModule '../create-storage-account/main.bicep' = {
  name: 'storageDeploy'
  scope: demoRG
  params: {
    storagePrefix: namePrefix
    location: demoRG.location
  }
}

output storageEndpoint object = stgModule.outputs.storageEndpoint

モジュールのスコープを設定する

モジュールを宣言するときは、モジュールを含むBicep ファイルのスコープとは異なるスコープをモジュールに設定します。モジュールのスコープを設定するには、scope プロパティを使用します。 scope プロパティを指定しない場合、モジュールは親のターゲットスコープにデプロイされます。

次の Bicep ファイルでは、リソースグループと、そのリソースグループ内のストレージアカウントが作成されます。ファイルはサブスクリプションにデプロイされますが、モジュールのスコープは新しいリソースグループになります。

// set the target scope for this file
targetScope = 'subscription'

@minLength(3)
@maxLength(11)
param namePrefix string

param location string = deployment().location

var resourceGroupName = '${namePrefix}rg'

resource newRG 'Microsoft.Resources/resourceGroups@2025-04-01' = {
  name: resourceGroupName
  location: location
}

module stgModule '../create-storage-account/main.bicep' = {
  name: 'storageDeploy'
  scope: newRG
  params: {
    storagePrefix: namePrefix
    location: location
  }
}

output storageEndpoint object = stgModule.outputs.storageEndpoint

次の例では、2 つの異なるリソースグループにストレージアカウントがデプロイされます。どちらのリソースグループも既に存在している必要があります。

targetScope = 'subscription'

resource firstRG 'Microsoft.Resources/resourceGroups@2025-04-01' existing = {
  name: 'demogroup1'
}

resource secondRG 'Microsoft.Resources/resourceGroups@2025-04-01' existing = {
  name: 'demogroup2'
}

module storage1 '../create-storage-account/main.bicep' = {
  name: 'westusdeploy'
  scope: firstRG
  params: {
    storagePrefix: 'stg1'
    location: 'westus'
  }
}

module storage2 '../create-storage-account/main.bicep' = {
  name: 'eastusdeploy'
  scope: secondRG
  params: {
    storagePrefix: 'stg2'
    location: 'eastus'
  }
}

scope プロパティを有効なスコープオブジェクトに設定します。 Bicep ファイルがリソースグループ、サブスクリプション、または管理グループをデプロイする場合は、モジュールのスコープをそのリソースのシンボリック名に設定します。または、スコープ関数を使用して有効なスコープを取得します。

以下がその関数です。

次の例では、managementGroup 関数を使用してスコープを設定します。

param managementGroupName string

module mgDeploy 'main.bicep' = {
  name: 'deployToMG'
  scope: managementGroup(managementGroupName)
}

Output

モジュールから値を取得し、メインの Bicep ファイルでそれを使用できます。モジュールから出力値を取得するには、モジュールオブジェクトで outputs プロパティを使用します。

最初の例では、ストレージアカウントを作成し、プライマリエンドポイントを返します。

@minLength(3)
@maxLength(11)
param storagePrefix string

@allowed([
  'Standard_LRS'
  'Standard_GRS'
  'Standard_RAGRS'
  'Standard_ZRS'
  'Premium_LRS'
  'Premium_ZRS'
  'Standard_GZRS'
  'Standard_RAGZRS'
])
param storageSKU string = 'Standard_LRS'

param location string

var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'

resource stg 'Microsoft.Storage/storageAccounts@2025-06-01' = {
  name: uniqueStorageName
  location: location
  sku: {
    name: storageSKU
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

output storageEndpoint object = stg.properties.primaryEndpoints

このプロパティをモジュールとして使用すると、その出力値を取得できます。

targetScope = 'subscription'

@minLength(3)
@maxLength(11)
param namePrefix string

resource demoRG 'Microsoft.Resources/resourceGroups@2025-04-01' existing = {
  name: 'demogroup1'
}

module stgModule '../create-storage-account/main.bicep' = {
  name: 'storageDeploy'
  scope: demoRG
  params: {
    storagePrefix: namePrefix
    location: demoRG.location
  }
}

output storageEndpoint object = stgModule.outputs.storageEndpoint

Bicep バージョン 0.35.1 以降を使用すると、モジュール出力に @secure() デコレーターを適用して機密としてマークし、それらの値がログやデプロイ履歴で公開されないようにすることができます。この方法は、モジュールが、生成されたキーや接続文字列などの機密データを、公開を危険にさらさずに親Bicep ファイルに返す必要がある場合に便利です。詳細については、「セキュリティで保護された出力」を参照してください。

モジュール ID

Bicep バージョン 0.36.1 以降では、ユーザー割り当てマネージド ID をモジュールに割り当てることができます。この ID はモジュール内で使用できます。たとえば、Key Vaultにアクセスできます。ただし、バックエンドサービスでは、この機能はまだサポートされていません。

param identityId string

module mod './module.bicep' = {
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${identityId}': {}
    }
  }
  name: 'mod'
  params: {
    keyVaultUri: 'keyVaultUri'
    identityId: identityId
  }
}

機密性の高い値をモジュールに渡すには、 getSecret 関数を使用します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-06-26