この記事では、Bicep CLI で使用できるコマンドについて説明します。 これらのコマンドは、Azure CLIを使用するか、Bicep CLI コマンドを直接呼び出すことによって実行できます。 それぞれの方法で、個別のインストール プロセスが必要です。 インストールの詳細については、Azure CLI および Azure PowerShell を参照してください。
このガイダンスでは、Azure CLIでコマンドを実行する方法を示します。 Azure CLIでコマンドを実行するときは、az で開始します。 Azure CLIを使用していない場合は、各コマンドの開始時に az なしでコマンドを実行します。 たとえば、 az bicep build は bicep build、az bicep version は bicep --version になります。
ビルド
build コマンドは、Bicep ファイルを JSON Azure Resource Manager テンプレート (ARM テンプレート) に変換します。 通常、このコマンドは、Bicep ファイルをデプロイするときに自動的に実行されるため、実行する必要はありません。 Bicep ファイルから作成された JSON ARM テンプレートを表示する場合は、手動で実行します。
次のいずれかのBicep機能を使用すると、言語バージョン 2.0 のコード生成が自動的に有効になります。
次の例では、main.bicep という名前のBicep ファイルを変換します。main.json という名前の ARM テンプレートに指定します。 新しいファイルは、Bicep ファイルと同じディレクトリに作成されます。
次の例では、 main.json を別のディレクトリに保存します。
次の例では、作成するファイルの名前と場所を指定します。
ファイルを stdout に出力するには、次のコマンドを使用します。
Bicep ファイルに外部レジストリを参照するモジュールが含まれている場合、build コマンドは自動的に restore を呼び出します。
restore コマンドは、レジストリからファイルを取得し、ローカル キャッシュに格納します。
Note
restore コマンドはキャッシュを更新しません。 詳細については、「restore」を参照してください。
自動復元を防ぐには、 --no-restore スイッチを使用します。
bicep build --no-restore <bicep-file>
--no-restore スイッチを使用するには、Bicep CLI バージョン 0.4.X 以降が必要です。
外部モジュールのいずれかがまだキャッシュされていない場合、--no-restore スイッチを使用したビルド プロセスは失敗します。
The module with reference "br:exampleregistry.azurecr.io/bicep/modules/storage:v1" hasn't been restored.
このエラーが発生した場合は、build スイッチを使用せずに --no-restore コマンドを実行するか、最初bicep restore実行します。
build-params
build-params コマンドは、
このコマンドは、 params.bicepparam パラメーター ファイルを params.json JSON パラメーター ファイルへ変換します。
逆コンパイル
decompile コマンドは、JSON ARM テンプレートをBicep ファイルに変換します。
このコマンドでは、main.json と同じディレクトリの中に main.bicep という名前のファイルが作成されます。
main の場合。同じディレクトリにbicepが存在する場合は、--force スイッチを使用して、既存のBicep ファイルを上書きします。
このコマンドの使用方法の詳細については、「decompile JSON ARM template to Bicep」を参照してください。
decompile-params
decompile-params コマンドは、JSON パラメーター ファイルを.bicepparam パラメーター ファイルに逆コンパイルします。
bicep decompile-params azuredeploy.parameters.json --bicep-file ./dir/main.bicep
このコマンドは、 azuredeploy.parameters.json パラメーター ファイルを azuredeploy.parameters.bicepparam ファイルに逆コンパイルします。
--bicep-file を使用して、using 宣言で参照されるBicep ファイル (.bicepparam ファイルを基準とする) へのパスを指定します。
format
format コマンドは、推奨されるスタイル規則に従うようにBicep ファイルを書式設定します。 これは、Bicep ファイルのコード フォーマッタまたは "より美しい" と考えてください。 Visual Studio Codeの SHIFT+ALT+F ショートカットと同じ関数があります。
generate-params
generate-params コマンドは、指定されたBicep ファイルからパラメーター ファイルをビルドし、既存のパラメーター ファイルがある場合は更新します。
bicep generate-params main.bicep --output-format bicepparam --include-params all
このコマンドは、main.bicepparam という名前のBicep パラメーター ファイルを作成します。 パラメーター ファイルには、既定値で構成されているかどうかに関係なく、Bicep ファイル内のすべてのパラメーターが含まれます。
このコマンドは、 main.parameters.jsonという名前のパラメーター ファイルを作成します。 パラメーター ファイルには、Bicep ファイルで既定値が構成されていないパラメーターのみが含まれています。
インストール
install コマンドは、Bicep CLI をローカル環境に追加し、Azure CLIでのみ使用できます。 詳細については、「install Bicep tools を参照してください。
最新バージョンをインストールするには、次のコマンドを実行します。
特定のバージョンをインストールするには、次のコマンドを使用します。
jsonrpc
jsonrpc コマンドは、JSON-RPC インターフェイスを使用してBicep CLI を実行します。 このインターフェイスを使用すると、構造化された出力をプログラムで操作できます。 また、複数のファイルをコンパイルするときにコールド スタートの遅延を回避することもできます。 このセットアップでは、.NET以外の言語でプログラムによってBicep ファイルを操作するためのライブラリの構築がサポートされています。
入力と出力を送受信するためのワイヤ形式は、ヘッダーで区切られます。 次の構造を使用します。ここで、 \r と \n は復帰文字と改行文字を表します。
Content-Length: <length>\r\n\r\n<message>\r\n\r\n
-
<length>は、末尾の<message>を含む、\r\n\r\n文字列の長さです。 -
<message>は生の JSON メッセージです。
次に例を示します。
Content-Length: 72\r\n\r\n{"jsonrpc": "2.0", "id": 0, "method": "bicep/version", "params": {}}\r\n\r\n
JSON-RPC インターフェイスでは、次のメソッドを使用できます。
bicep/format
Bicep ファイルを書式設定します。
要求:
{ "jsonrpc": "2.0", "id": 1, "method": "bicep/format", "params": { "path": "/path/to/file.bicep" } }応答:
{ "jsonrpc": "2.0", "id": 1, "result": { "success": true, "diagnostics": [], "contents": "param foo string\n\nresource storage 'Microsoft.Storage/storageAccounts@2025-01-01' = {\n name: 'mystorageaccount'\n location: 'East US'\n}\n" } }成功すると、
"success": trueが返され、コンテンツは書式設定されたBicepソースを保持します。 障害が発生した場合は、エラーを説明する"success": falseを使用してdiagnosticsします。
bicep/version
Bicep CLI のバージョンを返します。
要求:
{ "jsonrpc": "2.0", "id": 0, "method": "bicep/version", "params": {} }応答:
{ "jsonrpc": "2.0", "id": 0, "result": { "version": "0.24.211" } }
使用可能なメソッドと要求および応答本文については、「ICliJsonRpcProtocol.cs」を参照してください。
JSONRPC 接続を確立し、Node を使用してBicep ファイルをプログラムで操作する例については、「jsonrpc.test.ts」を参照してください。
名前付きパイプの使用法
JSONRPC クライアントとして既存の名前付きパイプに接続するには、次の構文を使用します。
bicep jsonrpc --pipe <named_pipe>`
<named_pipe> は、JSONRPC クライアントを接続するための既存の名前付きパイプです。
macOS または Linux 上の名前付きパイプに接続するには:
Windowsの名前付きパイプに接続するには:
bicep jsonrpc --pipe \\.\pipe\\bicep-81375a8084b474fa2eaedda1702a7aa40e2eaa24b3.sock`
その他の例については、C# および node.js を参照してください。
TCP ソケットの使用
JSONRPC クライアントとして既存の TCP ソケットに接続するには、次の構文を使用します。
TCP ソケットに接続するには:
stdin と stdout の使用法
JSONRPC インターフェイスを実行するには、次の構文を使用します。 メッセージに stdin と stdout を使用します。
lint
lint コマンドは、Bicep ファイルのエラーと linter rule 違反を返します。
Bicep ファイルに外部レジストリを参照するモジュールが含まれている場合、lint コマンドは自動的に restore を呼び出します。
restore コマンドは、レジストリからファイルを取得し、ローカル キャッシュに格納します。
Note
restore コマンドはキャッシュを更新しません。 詳細については、「restore」を参照してください。
自動復元を防ぐには、 --no-restore スイッチを使用します。
外部モジュールのいずれかがまだキャッシュされていない場合、--no-restore スイッチを使った lint プロセスは失敗します。
The module with reference "br:exampleregistry.azurecr.io/bicep/modules/storage:v1" has not been restored.
このエラーが発生した場合は、lint スイッチを指定せずに --no-restore コマンドを実行するか、最初に bicep restore を実行します。
list-versions
list-versions コマンドは、使用可能なすべてのバージョンの Bicep CLI を返します。 新しいバージョンにアップグレードするか新しいバージョンをインストールする場合は、このコマンドを使用します。 このコマンドは、Azure CLIでのみ使用できます。
パブリッシュ
publish コマンドは、レジストリにモジュールを追加します。 Azure コンテナー レジストリが存在し、レジストリに発行するアカウントに適切なアクセス許可が必要です。 モジュール レジストリの設定の詳細については、「 Bicep モジュールのプライベート レジストリを使用するを参照してください。 モジュールを発行するには、レジストリにアクセスするための適切なプロファイルとアクセス許可がアカウントに必要です。
Bicep構成ファイルで、レジストリに対する認証のプロファイルと資格情報の優先順位を構成できます。
ファイルをレジストリに発行すると、それをモジュール内で参照できます。
publish コマンドと --documentationUri/-d パラメーターを使用するには、Bicep CLI バージョン 0.14.X 以降が必要です。
モジュールをレジストリに発行するには、次のコマンドを使用します。
bicep publish <bicep-file> --target br:<registry-name>.azurecr.io/<module-path>:<tag> --documentationUri <documentation-uri>
次に例を示します。
bicep publish storage.bicep --target br:exampleregistry.azurecr.io/bicep/modules/storage:v1 --documentationUri https://www.contoso.com/exampleregistry.html
publish コマンドは、bicepconfig.json ファイルで指定されたエイリアスを認識しません。 モジュールの完全なパスを指定してください。
警告
同じターゲットに発行すると、古いモジュールが上書きされます。 更新時にバージョンをインクリメントします。
復元
Bicep ファイルで、レジストリに発行するモジュールが使用されている場合、restore コマンドはレジストリから必要なすべてのモジュールのコピーを取得します。 これらのコピーはローカル キャッシュに格納されます。 Bicep ファイルは、ローカル キャッシュで外部ファイルを使用できる場合にのみビルドできます。 通常、復元はビルド プロセスによって自動的にトリガーされるため、実行する必要はありません。
外部モジュールをローカル キャッシュに復元するには、レジストリにアクセスするための適切なプロファイルとアクセス許可がアカウントに必要です。 profile と資格情報の優先順位を構成して、Bicep構成ファイル内のレジストリに対する認証を行うことができます。
restore コマンドを使用するには、Bicep CLI バージョン 0.14.X 以降が必要です。
ファイルの外部モジュールを手動で復元するには、次のコマンドを使用します。
指定するBicep ファイルは、デプロイするファイルです。 これには、レジストリにリンクするモジュールが含まれている必要があります。 たとえば、次のファイルを復元できます。
module stgModule 'br:exampleregistry.azurecr.io/bicep/modules/storage:v1' = {
name: 'storageDeploy'
params: {
storagePrefix: 'examplestg1'
}
}
ローカル キャッシュは次の中に見つかります。
Windows時
%USERPROFILE%\.bicep\br\<registry-name>.azurecr.io\<module-path\<tag>Linux の場合
/home/<username>/.bicepMac の場合
~/.bicep
モジュールが既にキャッシュされている場合、restore コマンドはキャッシュを更新しません。 キャッシュを更新するには、キャッシュからモジュール パスを削除するか、--force コマンドで restore スイッチを使用します。
スナップショット
Bicep CLI v0.41.2 以降を使用すると、snapshot コマンドを使用して、.bicepparam ファイルからBicepデプロイの正規化された確定的表現を作成できます。 このスナップショットを後のスナップショットと比較して、Azureに何もデプロイせずに、リファクタリングによって引き起こされる変更を理解できます。 このコマンドは、次の場合に特に便利です。
- Visual Diffs: リファクタリング (モジュールへのコードの移動など) によって基になるリソース定義がどのように変更されるかを正確に確認します。
- 複合式: デプロイ前に複雑な文字列または変数が実際に評価される内容を理解します。
- CI/CD 検証: プル要求中にインフラストラクチャ ロジックの意図しない変更を自動的にキャッチします。
スナップショットの作成
このコマンドは、 .snapshot.json ファイルを生成します。 このファイルは "正規化" されています。つまり、モジュールの境界のようなノイズが除去されるため、リソース自体に集中できます。
次の JSON ファイルは、スナップショットの例を示しています。
{
"predictedResources": [
{
"id": "[format('/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/stmyappstorage001', subscription().subscriptionId, resourceGroup().name)]",
"type": "Microsoft.Storage/storageAccounts",
"name": "stmyappstorage001",
"apiVersion": "2025-01-01",
"location": "eastus",
"sku": {
"name": "Standard_LRS"
},
"kind": "StorageV2"
}
],
"diagnostics": []
}
変更を検証する
スナップショットを作成したら、検証モードでコマンドを実行します。 現在のBicep コードを保存されたスナップショットと比較し、what-if コマンドと同様に、視覚的な相違を示しますが、完全にローカルです。
サンプル出力は次のようになります。
PS C:\bicep> bicep snapshot --mode validate main.bicepparam
Snapshot validation failed. Expected no changes, but found the following:
Scope: <unknown>
~ [format('/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/stmyappstorage001', subscription().subscriptionId, resourceGroup().name)]
~ apiVersion: "2025-01-01" => "2025-06-01"
~ sku.name: "Standard_LRS" => "Standard_GRS"
"スナップショットの検証に失敗しました" は、2 つのスナップショットの違いを示します。
Bicep CLI スナップショットと What-if には、次の違いがあります。
| 機能 | bicep snapshot |
az deployment group what-if |
|---|---|---|
| 実行 | ローカルのみ (オフライン) | クラウドベース (オンライン) |
| 比較 | コードと保存されたファイルを比較します | コードとライブ Azure状態を比較します |
| 速度 | 非常に高速 | 低速 (API 呼び出しが必要) |
| ユースケース(事例) | リファクタリングとロジック テスト | デプロイ前の最終チェック |
コンテキストを提供する
スナップショットBicep実行すると、CLI によってコードのローカル評価が実行されます。 Azureとは通信しないため、サブスクリプション ID または現在のリソース グループ名をクラウドに "要求" することはできません。
コードで環境関数 ( subscription().id など) を使用している場合、CLI 引数を使用して特定のコンテキストを指定しない限り、スナップショットは失敗するかプレースホルダーを返します。
実際のデプロイ環境をシミュレートするには、次のフラグを渡します。
| 引数 | 目的 | 値の例 |
|---|---|---|
--subscription-id |
返される値を置き換えます。 subscription().subscriptionId |
00000000-1111-2222-3333-444444444444 |
--resource-group |
返される値を置き換えます。 resourceGroup().name |
my-production-rg |
--location |
の既定の場所を設定します。 deployment().location |
westeurope |
--tenant-id |
返される値を置き換えます。 tenant().tenantId |
72f988bf-86f1-41af-91ab-2d7cd011db47 |
--management-group |
返される値を置き換えます。 managementGroup().name |
my-corp-mg |
bicep snapshot main.bicepparam \
--subscription-id 00000000-0000-0000-0000-000000000000 \
--resource-group my-temp-rg \
--location eastus \
--mode overwrite
アップグレード
upgrade コマンドは、インストールされているバージョンを最新バージョンで更新します。 このコマンドは、Azure CLIでのみ使用できます。
バージョン
version コマンドは、インストールされているバージョンを返します。
bicep --version
Bicep CLI をインストールしなかった場合は、Bicep CLI が見つからなかったことを示すエラー メッセージが表示されます。
このコマンドには、バージョン番号が表示されます。
Bicep CLI version 0.29.45 (57a44c0230)
次のステップ
Bicep ファイルのデプロイの詳細については、以下を参照してください。