Standard Logic Apps のデプロイ手順｜スロット運用・VNet統合・CI/CD

Standard Logic Apps は、Azure Functions の拡張として単一テナントで動くホスティング形態です。Consumption と違ってプランとストレージを自分で選ぶため、作成画面で決めた項目がそのまま運用時の制約になります。この記事で扱うのは、Azure ポータルでのリソース作成から、ステートフルとステートレスの選択、VNet 統合、デプロイメントスロット、Azure DevOps での CI/CD までです。いずれも公式ドキュメントの記載に沿って整理しました。サービスの仕組みや Consumption との料金比較、採用そのものの判断はAzure Logic Appsとは？仕組み・ConsumptionとStandardの違い・料金と採用判断を実装者目線で解説で扱っているため、本記事は Standard を選んだ後の構築・運用に絞ります。

まとめ：Standard Logic Apps のデプロイで先に決める4点

作成後に変更できない、または変更コストが高い決定が4つあります。

• ホスティング：Workflow Service Plan（WS1〜WS3）／App Service Environment V3／Hybrid の3択。予約容量に対する課金なので、実行がまばらなワークロードでは割高になります。
• ワークフローの種別：ステートフルかステートレスかは作成時に決め、後から変更すると実行時エラーになります。ステートレスは 64 KB を超えるデータで性能が落ち、メモリ不足でクラッシュすることがあります。実行時間は5分以内が想定で、Recurrence トリガーは使えません。
• ストレージプロバイダー：既定の Azure Storage か、SQL 認証しか使えない SQL ストレージか。SQL を選んでも Azure リージョンへ配置する限りストレージアカウントは必要です。
• ネットワーク：受信・送信の設定は「ネットワークの挿入」をオンにして仮想ネットワークを選んで初めて現れます。そのうえで受信のプライベートエンドポイントは、公開アクセスをオフにしたときだけ有効になります。

運用面では、ゼロダウンタイム更新のためのデプロイメントスロットが Standard で利用できます。以降で各項目の具体的な設定値と制約を見ていきます。

Standard Logic Apps の3つのホスティング選択

ポータルの「ロジック アプリの作成」画面で Standard を選ぶと、3つのホスティングオプションが提示されます。Functions Premium プラン、App Service Environment v1 および v2 は、単一テナント版の一般提供にともないサポート対象外になっています。

Workflow Service Plan と WS1・WS2・WS3 の割り当て

既定の選択肢です。価格レベルによって割り当てられる vCPU とメモリが決まります。

機能差はなく、違いは計算リソースの量だけです。課金は使用量ではなく予約容量に対して発生し、実行がなくてもプランを立てている間は課金されます。なお Standard では組み込みコネクタの操作が無制限に無料で、操作課金の対象はマネージドコネクタだけです（これとは別に、プランの予約容量と Azure Storage のトランザクションが課金されます）。Consumption が「実行単位」で計測するのに対し、Standard は「呼び出し単位」で計測するため、チャンクやページネーションで10回呼び出す操作は10回分として課金されます。

App Service Environment v3 を選ぶ条件

完全に分離された環境が必要なとき、または ASE v3 に紐づく仮想ネットワーク設定をそのまま継承したいときの選択肢です。Windows プランのみが対象で、価格レベルには Isolated V2 の App Service プランを別途選びます。この場合はプランのインスタンス分だけが課金され、ロジックアプリの数を増やしても追加費用は発生しません。ASE v3 では後述する Runtime Scale Monitoring が使えない一方、マネージド ID 認証の設定を済ませたうえでストレージアカウントのキーアクセスを無効化できるという違いがあります。App Service プラン側の考え方はAzure App Serviceとは？仕組み・料金プラン・デプロイスロットとStatic Web Apps／AKSとの違いを実装者目線で解説と共通です。

Hybrid デプロイの課金単位と適用範囲

オンプレミスやプライベートクラウドで動かす形態で、ランタイムは Azure Container Apps 拡張として Kubernetes 上で動きます。Arc 対応 Kubernetes インフラと SQL Server ライセンスは自前で用意し、Azure へは vCPU 使用量で支払います。使用量は「割り当て vCPU 数 × レプリカ数」で、割り当てられる範囲は 0.25 〜 2 コア、1レプリカあたり最大2 vCPU です。部分的にしか接続されていない環境でローカル処理が必要なケース向けで、単に安く上げたいという理由で選ぶ形態ではありません。

Azure ポータルでの作成手順とタブごとの決定事項

作成ウィザードは Basics、Storage、Networking、Monitoring、Authentication の順に進みます。ここで扱うのは Basics と Authentication、および作成直後の確認事項で、Storage と Networking は独立した論点として後の章に回しました。Monitoring タブで Application Insights を有効化しておくと、ワークフロー実行時のテレメトリから失敗や性能問題を追えます。監視基盤側の設計はAzure Monitorとは？監視の仕組み・Log AnalyticsとApplication Insightsの関係・料金モデルとDatadogとの違いを実装者目線で解説で扱っています。

Basics タブで指定する項目

サブスクリプション、リソースグループ、ロジックアプリ名、リージョン、Windows プラン、価格プランを指定します。ロジックアプリ名には、Functions と同じ命名規約により .azurewebsites.net のサフィックスが自動で付きます。プランは Windows ベースのみサポートで、Linux ベースの App Service プランは選べません。選んだリージョンが可用性ゾーンに対応していれば「ゾーン冗長」セクションが有効になります。

Authentication タブとマネージド ID でのホストストレージ認証

ホストストレージ（AzureWebJobsStorage）への認証方式を、接続文字列とマネージド ID から選びます。ユーザー割り当てマネージド ID を使う場合は、対象のストレージアカウントに次の4ロールを割り当てます。

• ストレージ アカウント共同作成者（Storage Account Contributor）
• ストレージ BLOB データ所有者（Storage Blob Data Owner）
• ストレージ キュー データ共同作成者（Storage Queue Data Contributor）
• ストレージ テーブル データ共同作成者（Storage Table Data Contributor）

そのうえで、次のアプリ設定を追加します。

AzureWebJobsStorage__managedIdentityResourceId = {ユーザー割り当てマネージドIDのリソースID}
AzureWebJobsStorage__blobServiceUri            = {ストレージアカウントのBlobサービスURI}
AzureWebJobsStorage__queueServiceUri           = {ストレージアカウントのQueueサービスURI}
AzureWebJobsStorage__tableServiceUri           = {ストレージアカウントのTableサービスURI}
AzureWebJobsStorage__credential                = managedIdentity

追加が終わったら、接続文字列を保持していた AzureWebJobsStorage を削除します。Workflow Service Plan では、あわせて「構成」の Runtime Scale Monitoring をオンにしてください。既存のマネージド ID を選ぶ場合、ロール割り当てをデプロイ前に済ませておかないとリソースを開いた時点でエラーになります。接続文字列を残す運用にするなら、値そのものはAzure Key Vaultとは？シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説で扱う方式に寄せて、アプリ設定へ平文で置かない構成にします。

作成直後に確認するアプリ設定

2つのアプリ設定が既定値どおりかを確認します。FUNCTIONS_WORKER_RUNTIME は以前 node が必須値でしたが、新規・既存を問わず現在の必須値は dotnet です。もう1つの APP_KIND は値が workflowApp である必要があり、ARM テンプレートによる自動化などでこの設定が欠落すると、JavaScript コードの実行アクションが動かない、あるいはワークフローが停止するといった症状が出ます。原因が分かりにくい不具合なので、テンプレートで作成した直後に見ておく価値があります。

ステートフルとステートレスの選択基準

ワークフロー追加時に「状態の種類」で選びます。作成後に種別を変更すると実行時エラーになるため、この判断は事実上やり直しがききません。

ステートフルは入出力と状態を外部ストレージに保存するため、障害後に中断した実行を再構成して完了まで流し直せます。ステートレスはすべてメモリ上で処理する分だけ応答が速くストレージ費用も抑えられますが、障害時の自動復旧はなく、呼び出し側が手動で再送する前提になります。

ステートレスで踏みやすい制約

ステートレスで使えるトリガーは push 型に限られます。スケジュール実行の Recurrence トリガーはステートフル専用なので、定期実行のワークフローをステートレスで作ることはできません。開始には Request、Event Hubs、Service Bus といったトリガーを使います。マネージドコネクタを有効にしても、ポーリング型トリガーはギャラリーに表示されません。加えて、ステートレスではトリガーの同時実行数を変更できません。なお種別を問わず、1つの Standard ワークフローに設定できるトリガーは1本だけです。

親子ワークフロー呼び出し時の挙動差

同じロジックアプリ内のワークフローを呼び出すとき、親子の種別の組み合わせで待ち方が変わります。親子ともステートフルなら非同期ポーリング、子がステートレスなら親は完了まで待つ「トリガーして待つ」、親がステートレスで子がステートフルなら同期パターンです。ここでいう同期パターンは公式表現で「fire and forget」とされ、子が 202 応答を即返し、親は結果を待たずに次のアクションへ進みます。つまり待たされる原因は親ではなく、子をステートレスにしたことにあると理解してください。ステートフル同士で fire and forget にしたい場合は、ワークフロー定義の operationOptions に DisableAsyncPattern を指定します。

ステートレスの実行履歴を一時的に見る方法

デバッグ時に限り、ワークフローの設定にある「デバッグ状態」をオンにすると部分的な実行履歴を確認できます。これはセッション単位の一時設定で、ワークフローを閉じる、ページを更新する、サインアウトすると自動的にオフへ戻ります。運用環境ではサポートされない設定です。またデバッグをオンにしたステートレスは、ステートフルより速くはなりません（メモリ処理による速度優位が失われます）。恒久的に履歴が必要なら、最初からステートフルで作ります。

VNet 統合とプライベートエンドポイントによる閉域化

ネットワークは作成ウィザードの Networking タブで設定しますが、デプロイ後にも変更できます。

公開アクセスとネットワーク挿入の組み合わせ

設定は2系統に分かれています。「パブリック アクセスを有効にする」はロジックアプリのエンドポイントを外部へ出すかどうかの設定で、オフにするとパブリックエンドポイントを持たず、仮想ネットワーク内のクライアントからのみ到達できるプライベートエンドポイント構成になります。もう一方の「ネットワークの挿入を有効にする」は、ワークフローから仮想ネットワーク内のエンドポイントへ通信できるかどうかの設定です。オンにして仮想ネットワークを選ぶと、受信側と送信側の設定が現れます。

• 受信アクセス：「プライベート エンドポイントを有効にする」は、パブリックアクセスをオフにしたときだけ選べます。
• 送信アクセス：「VNet 統合を有効にする」でサブネットを指定します。Premium 統合アカウントのプライベートエンドポイントと通信させる場合はここをオンにします。

プレミアム統合アカウントと連携するときは、ロジックアプリと統合アカウントを同一の仮想ネットワーク内に置き、かつロジックアプリ・仮想ネットワーク・統合アカウントが同一リージョンである必要があります。

ファイアウォール許可に必要な情報の取得

送信を絞っている環境では、ワークフローが使う接続ごとに FQDN を許可します。ロジックアプリのメニューから「ワークフロー」「接続」と辿り、API 接続タブで接続リソースを開いて JSON ビューに切り替え、connectionRuntimeUrl プロパティの値を控えます。この作業は接続の数だけ必要です。受信・送信の IP アドレスは「ネットワーク」ページの受信トラフィック・送信トラフィックの各セクションで確認できます。単一テナントでは共有 IP ではなく専用の静的 IP を持てるため、宛先システム側のファイアウォール開放を1つにまとめられます。

ストレージプロバイダーの選択と保存されるデータ

Storage タブの「ストレージの種類」で、Azure Storage か SQL and Azure Storage を選びます。

Azure Storage に保存されるもの

Standard は Functions と同等のストレージ要件を持ちます。ステートフルワークフローが使うのは、トリガーのスケジューリング用のキューと、ワークフローの状態や実行履歴の入出力を置くテーブル・BLOB です。これらはストレージトランザクションとして Azure Storage の料金で別建て課金され、請求書にも独立した項目として出ます。ストレージアカウント名は 3 〜 24 文字の英小文字と数字のみです。ファイル共有のセキュリティ設定は、既定の 最大互換性（Maximum Compatibility） から変えないでください。変更すると、ロジックアプリが起動できず「The user name or password is incorrect」というシークレット関連のエラーになります。

SQL ストレージを選ぶ条件と認証の制約

ランタイムのスループットやスケーリングをより細かく制御したい場合に、SQL Server、Azure SQL Database、Azure SQL Managed Instance をストレージプロバイダーにできます。公式が挙げる選択理由は、操作数で費用が動く Azure Storage と違い、SQL は CPU と IOPs が基準のため費用を読みやすいこと。ただし押さえるべき制約が1つあります。認証が接続文字列による SQL 認証のみで、Microsoft Entra ID とマネージド ID に対応していないことです（ローカル開発とテストに限り Windows 認証も選べます）。鍵や接続文字列の運用を厳格化している組織では、この時点で選択肢から外れるでしょう。加えて、Azure リージョンへ配置する限りは、プラットフォーム側のホスティング構成を保持するために Azure ストレージアカウントも引き続き必要です。SQL だけで完結するのは、Azure Arc クラスターのカスタムロケーションへ配置する場合に限られます。

デプロイメントスロットによるゼロダウンタイム更新

「Standard にはスロットがないので独自の切り替え手順が要る」という前提で書かれた情報が残っていますが、現在の Standard Logic Apps はデプロイメントスロットに対応しています。運用スロットと入れ替えることで、更新中も利用者に中断を出さずに切り替えられ、問題があれば前のバージョンへ戻せます。

スロットでできることとできないこと

Azure Functions の拡張性モデルを土台にしている都合で、App Service のスロットと同じ感覚では使えません。

• 非運用スロットは読み取り専用で作成されます。
• 非運用スロットのディスパッチャは停止しており、ワークフローは運用スロットにあるときだけ実行されます。
• トラフィック分散は無効です。したがってブルーグリーンデプロイ、スワップ前の製品検証テスト、A/B テストはいずれも対象外です。

対象外なのは実行を伴う検証です。スロット上のワークフロー定義を読み取り専用ビューで目視確認することはできますが、非運用スロットではディスパッチャが止まっているため、実際に流して確かめることはできません。スロットの価値は、配置済みの成果物を無停止で切り替える点と、切り戻し先を持てる点にあります。なお、スロット関連の操作全般に Azure Logic Apps Standard 共同作成者ロールが必要です。

作成・デプロイ・スワップの実行方法

スロットの作成はポータル（メニューの「デプロイ」の下にある「デプロイ スロット」）、Visual Studio Code、Azure CLI のいずれからでも行えます。名前は英小文字の英数字とハイフンのみで、作成後は「ロジックアプリ名-スロット名」という形式になります。

az functionapp deployment slot create --name {logic-app-name} --resource-group {resource-group-name} --slot {slot-name}

az functionapp deployment slot swap --name {logic-app-name} --resource-group {resource-group-name} --slot {slot-name} --target-slot production

Visual Studio Code では Azure Logic Apps: Create slot、Swap slot、Delete slot の各コマンドが使えます。注意すべきはスロットへのコード配置がポータルからはできない点です。Visual Studio Code のコマンド Azure Logic Apps: Deploy to slot か、次の Azure CLI を使います。

az logicapp deployment source config-zip --name {logic-app-name} --resource-group {resource-group-name} --slot {slot-name} --src {deployment-package-local-path}

スワップはポータルの「スワップ」から、ソースにデプロイスロット、ターゲットに運用スロットを指定して実行します。「プレビュー付きスワップ」はスロット設定を有効にしたロジックアプリでのみ動作します。

プライベートストレージ利用時の追加設定

ストレージアカウントをプライベート構成にしている場合、スロット作成後に手当てが要ります。スロットの環境変数からアプリ設定 WEBSITE_CONTENTSHARE の値を確認し、同じ名前のファイル共有をストレージアカウント側に手動で作成します。そのうえで各スロットに WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS を追加し、値は 0 です。BLOB・ファイル・テーブル・キューの各サービスをプライベートエンドポイント経由に限定したファイアウォール構成では Terraform ではなく Bicep か ARM テンプレートを使い、上記2つに加えて AzureFunctionsWebHost_hostid に一意の値を設定してください。ファイル共有フォルダーはデプロイ前に作成しておく必要があります。

Azure DevOps を使った CI/CD の自動化

Visual Studio Code の Azure Logic Apps (Standard) 拡張機能には、ビルドとデプロイのパイプラインを生成する機能があります。手書きで YAML を組む前に、まずこれを試すのが早道です。前提として、Azure DevOps Marketplace の Azure Logic Apps (Standard) Build and Release tasks、サービスプリンシパルを持つ Azure Resource Manager サービス接続、配置先のリソースグループ、およびプロジェクトを置く Azure DevOps の Git リポジトリを用意します。DevOpsとは？開発と運用を統合する実践・ツール・導入判断を実装視点で解説で扱う一般的な CI/CD の考え方をそのまま持ち込めますが、ロジックアプリ固有の事情として「Azure 側でホストされる接続」をどう扱うかが焦点になります。

拡張機能が生成するデプロイスクリプト

プロジェクトのショートカットメニューから「Generate deployment scripts」を実行すると、ワークスペース直下に deployment/{ロジックアプリ名} フォルダーが作られ、その配下に3種類の成果物が入ります。

要点は、デザイン時に接続参照をパラメーター化しておくことです。ワークフローを開いた際の「接続のパラメーター化を許可しますか」に「はい」と答えると、ローカル開発を壊さずに環境ごとの値を差し替えられる形になります。生成後、CD-pipeline.yml の source 属性にある CI パイプライン名を、実際に使う名前へ書き換えてからコミットします。

デプロイスクリプト生成の対象範囲と ARM 限定の制約

デプロイスクリプト自体は、同じワークスペースにある Standard ロジックアプリプロジェクトと Functions のカスタムコードプロジェクトの両方に対して生成されます。ただしカスタムコードプロジェクトは現時点で無視され、ビルドパイプラインも作られません（対応はロードマップ入りとされています）。パイプラインを Azure DevOps へ接続し、トリガーを設定するのは利用者側の作業です。インフラのデプロイスクリプトは ARMテンプレートとBicep DSLの関係性と設計思想の違いで扱う ARM テンプレートのみが対象で、それ以外は計画段階です。Terraform でインフラを管理したい場合は AzAPI プロバイダーが ARM とパリティを持つとされ、モジュール単位では Azure Verified Modules が案内されています。

Kudu（Advanced Tools）を使う調査と復旧

Standard は Functions と同じ App Service のインフラ上で動くため、Kudu にアクセスできます。用途としてまとまった実例が公式に載っているのが、拡張バンドルの更新です。

拡張バンドルが古く組み込みアクションが出ない症状

ポータルで作成した既存のロジックアプリで、XML 検証や Liquid 変換といった組み込みアクションがデザイナーの一覧に出てこないことがあります。原因は拡張バンドル Microsoft.Azure.Functions.ExtensionBundle.Workflows のバージョンが古いままになっていることで、次の手順で解消します。

1. ロジックアプリの「概要」から停止します。
2. 「開発ツール」の「高度なツール」から Kudu を開きます。
3. デバッグコンソールで CMD を選び、...\home\data\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows へ移動します。
4. 既存バージョンのフォルダーを削除します（例：rm -rf 1.1.3）。
5. ポータルへ戻り、「概要」から再起動します。最新バンドルが自動取得されます。

削除に失敗するときの回避

「permission denied」や「file in use」で削除に失敗する場合は、ブラウザーでページを再読み込みしてから手順を繰り返します。この手順が有効なのはポータルで作成したロジックアプリで、Visual Studio Code の拡張機能で作成・デプロイしたものは別の対処になります。

Standard を選ぶべきでない場面と設計上の失敗パターン

ここまでの制約を踏まえると、Standard が向かない構成と、作った後に効いてくる失敗が見えてきます。

予約容量課金が見合わない構成

公式が示す例示リージョンの試算では、WS1（1 vCPU・3.5 GB）は730時間換算で月額およそ 175.16 米ドルです。1日に数回しか動かない連携を Standard に載せると、この費用に対して実行が伴いません。実行がまばらで、VNet 内リソースへの直接アクセスも不要なら、Consumption のほうが素直です。Standard の効きどころは、マネージドコネクタを避けて組み込みコネクタで組める大量実行のワークロードです。判断材料はAzure Logic Appsとは？仕組み・ConsumptionとStandardの違い・料金と採用判断を実装者目線で解説に整理しています。

ステートレスを安易に選んだときの手戻り

「速くて安いから」という理由でステートレスを選ぶと、後から要件が増えたときに詰みます。添付ファイルが 64 KB を超える、処理が5分を超える、定期実行が必要になる、チャンク送信が必要になる、といった変更はいずれもステートフルでしか吸収できません。そして種別は変更できず、新しいワークフローを作り直すことになります。実行履歴が要らないと断言できる短時間の同期処理以外は、ステートフルで始めるほうが安全です。

課金が跳ねるトリガー設定ミス

サービスプロバイダー系の組み込みトリガーは、設定を誤ったまま放置すると危険です。よくあるのは、Service Bus キューや BLOB コンテナーといった宛先に対するアクセス許可をロジックアプリへ与えないまま、トリガーだけ設定してしまうケースです。失敗したトリガーが不要なスケーリングを引き起こし、請求額が大きく膨らむことがあると公式ドキュメントも明記しています。トリガーは設定後に必ず疎通を確認し、稼働後も監視対象に含めてください。

1つのロジックアプリに詰め込みすぎる設計

推奨は1ワークフローあたり50アクション以下で、これを超えるとデザイナーの応答が落ちます。ビジネスロジックは複数ワークフローへ分割するのが基本方針です。ただしロジックアプリにワークフローを増やすほどコールドスタートの時間とロード時間が延びるため、分割すれば無条件に良いわけでもありません。停止時間を許容できない構成では、分割とあわせてデプロイメントスロットを用意するのが公式の推奨です。

よくある質問

Standard Logic Apps でデプロイメントスロットは使えますか？

使えます。ポータル、Visual Studio Code、Azure CLI のいずれからでもスロットを作成し、運用スロットとスワップできます。ただし非運用スロットは読み取り専用で、ディスパッチャが停止しているためワークフローが動くのは運用スロットだけです。ブルーグリーンデプロイや A/B テストには使えません。

ステートレスで作ったワークフローを後からステートフルに変更できますか？

できません。種別は作成時に決める項目で、作成後に変更すると実行時エラーになります。変更が必要になった場合は、目的の種別で新しいワークフローを作り直します。

SQL ストレージを選べばストレージアカウントは不要になりますか？

Azure リージョンへ配置する場合は不要になりません。ワークフローの状態や実行履歴は SQL データベースに入りますが、ロジックアプリの構成をプラットフォーム側で保持するために Azure ストレージアカウントが引き続き必要です。SQL だけで完結できるのは、Azure Arc クラスター上のカスタムロケーションへ配置する場合です。

デプロイメントスロットへポータルからコードを配置できますか？

できません。スロットの作成・スワップ・削除はポータルから操作できますが、コードの配置は Visual Studio Code の「Azure Logic Apps: Deploy to slot」か、Azure CLI の az logicapp deployment source config-zip に --slot を付けて実行します。

ワークフローが起動せず、シークレット関連のエラーが出るのはなぜですか？

ストレージアカウントのファイル共有のセキュリティ設定が、既定の「最大互換性」から変更されている場合に起きます。この設定を戻せば解消するはずです。なお、これとは別の症状（JavaScript コードの実行アクションが動かない、ワークフローが停止する）が出ているときは、APP_KIND が workflowApp か、FUNCTIONS_WORKER_RUNTIME が現在の必須値である dotnet かを確認します。

Standard Logic Apps の運用に必要な最低限のロールは何ですか？

公式ドキュメントが明示しているのは2種類です。デプロイメントスロットの作成・デプロイ・スワップには Azure Logic Apps Standard 共同作成者ロール、ホストストレージをマネージド ID で認証する場合はストレージアカウントに対する「ストレージ アカウント共同作成者」「ストレージ BLOB データ所有者」「ストレージ キュー データ共同作成者」「ストレージ テーブル データ共同作成者」の4ロールです。

関連記事

• Azure Logic Appsとは？仕組み・ConsumptionとStandardの違い・料金と採用判断を実装者目線で解説
• Azure App Serviceとは？仕組み・料金プラン・デプロイスロットとStatic Web Apps／AKSとの違いを実装者目線で解説
• Azure Key Vaultとは？シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説
• DevOpsとは？開発と運用を統合する実践・ツール・導入判断を実装視点で解説
• ARMテンプレートとBicep DSLの関係性と設計思想の違い