Azure Developer CLI（azd）のApril 2026更新で最も重要なのは、azd hooksをPython、JavaScript、TypeScript、.NETで書けるようになったことです。これまでBashやPowerShell中心だった自動化処理を、開発チームが普段使っている言語で実装しやすくなりました。
今回の更新は、単なる機能追加ではありません。CI/CDでの非対話実行、AIモデルのクォータ事前確認、azd updateの扱いやすさ向上、App Serviceスロット指定の変更など、Azureを使った開発・運用の失敗を減らすための改善が多く含まれています。Microsoftの公式ブログでは、2026年4月にazdの5つのリリースが提供され、対象バージョンは1.23.14、1.23.15、1.24.0、1.24.1、1.24.2とされています。(Microsoft for Developers)
Azure Developer CLI (azd) – April 2026で何が変わったか
Azure Developer CLI（azd）は、Azureアプリケーションの初期化、プロビジョニング、デプロイ、パイプライン構成をまとめて扱うためのCLIです。azd up、azd provision、azd deployといったコマンドを使い、ローカル開発からAzureへの展開までを短い手順で進められます。
April 2026更新の要点は、次の5つです。
| 変更点 | 影響を受ける人 | 実務上の意味 |
|---|---|---|
| マルチ言語hooks対応 | 開発者、DevOps担当者 | PythonやTypeScriptなどでデプロイ前後の処理を書ける |
azd updateのPublic Preview化 | 全ユーザー | パッケージマネージャーに依存せずazdを更新しやすい |
| AIモデルのクォータ事前確認 | AIアプリ開発者 | プロビジョニング後にクォータ不足で失敗するリスクを減らせる |
--no-promptの挙動標準化 | CI/CD運用者 | 自動実行時の失敗原因を把握しやすい |
| App Serviceスロット指定の明確化 | App Service運用者 | 意図しないスロットへのデプロイを防ぎやすい |
とくに注目すべきは、azd hooksの使い勝手が大きく変わった点です。azure.yamlに定義したhookで、Python、JavaScript、TypeScript、.NETのスクリプトを直接指定できるようになりました。Microsoft Learnでも、azdはファイル拡張子から言語を推定し、依存関係の管理とスクリプト実行を行うと説明されています。(Microsoft Learn)
最大の注目点はマルチ言語hooks対応
azd hooksは、Azureへのプロビジョニングやデプロイの前後に任意の処理を実行する仕組みです。たとえば、次のような作業を自動化できます。
- デプロイ前に設定ファイルを生成する
- プロビジョニング後にデータベースマイグレーションを実行する
- デプロイ後に初期データを投入する
- 環境変数やシークレット参照を検証する
- テストやヘルスチェックを実行する
従来はBashやPowerShellで書く場面が多く、チームによっては「アプリ本体はTypeScriptなのに、デプロイ周辺だけシェルスクリプトを読む必要がある」という分断が起きがちでした。April 2026更新では、Python、JavaScript、TypeScript、.NETのhookがサポートされ、プロジェクトの主要言語に近い形で自動化処理を書けるようになっています。(Microsoft for Developers)
Python hookはデータ処理や検証に使いやすい
Python hookでは、.pyファイルをazure.yamlから参照できます。requirements.txtまたはpyproject.tomlがある場合、azdが仮想環境を作成し、依存関係をインストールしてからスクリプトを実行します。(Microsoft Learn)
たとえば、プロビジョニング前に設定値の妥当性を検証する場合は、次のように書けます。
hooks:
preprovision:
run: ./hooks/validate.pyPythonは、JSONやYAMLの読み込み、外部APIとの連携、設定値の検証に向いています。インフラ構成の入力値を事前チェックしたい場合や、AIアプリでモデル名・リージョン・SKUの組み合わせを検証したい場合に使いやすい選択肢です。
注意点は、hook用の依存関係をアプリ本体の依存関係と混ぜすぎないことです。hook専用のrequirements.txtをhooks/配下に置くなど、責務を分けておくと、後から保守しやすくなります。
JavaScript・TypeScript hookはフロントエンド系チームに向いている
JavaScriptとTypeScriptのhookでは、.jsまたは.tsファイルを指定できます。package.jsonがある場合、azdはnpm installを実行します。TypeScriptはnpx tsx経由で実行され、コンパイル手順なしで使えると説明されています。(Microsoft Learn)
hooks:
postdeploy:
run: ./hooks/seed.tsたとえば、Static Web AppsやApp Serviceにフロントエンドをデプロイした後、APIの疎通確認や初期データ投入をTypeScriptで行う、といった使い方が考えられます。
また、configブロックを使うと、JavaScript・TypeScript hookで使うパッケージマネージャーを指定できます。
hooks:
postdeploy:
run: ./hooks/seed.ts
config:
packageManager: pnpmNode.jsベースのチームでは、既存のテストコードやユーティリティ関数をhookにも流用しやすくなります。ただし、本番デプロイのhookで大量の依存関係をインストールすると、CI/CD時間が長くなる可能性があります。hook用のpackage.jsonは軽量に保つのが現実的です。
.NET hookはC#中心のAzure開発と相性がよい
.NET hookでは、.csファイルを指定できます。プロジェクトファイルがある場合はプロジェクトモードで実行され、.NET 10以降では単一ファイルのC#スクリプト実行もサポートされます。(Microsoft for Developers)
hooks:
postprovision:
run: ./hooks/migrate.cs.NETチームにとっては、Azure Functions、App Service、ASP.NET Coreアプリのデプロイ後処理をC#で書けるのが大きな利点です。たとえば、Entity Framework Coreのマイグレーション、管理者ユーザーの初期作成、アプリ設定の検証などを、既存の.NET資産に近い形で実装できます。
一方で、デプロイhookに業務ロジックを詰め込みすぎると、デプロイ失敗時の切り分けが難しくなります。hookは「デプロイに必要な補助処理」に絞り、アプリケーション本体の責務と分離するのが安全です。
azd hooksを使うべき場面・使わないほうがよい場面
マルチ言語hooks対応により、azdは便利になりました。ただし、すべての処理をhookに寄せればよいわけではありません。
| 判断ポイント | hookに向いている | hookに向いていない |
|---|---|---|
| 実行タイミング | デプロイ前後に必ず実行したい処理 | 任意のタイミングで手動実行したい処理 |
| 処理時間 | 数秒から数分で終わる処理 | 長時間のバッチ処理 |
| 失敗時の影響 | デプロイを止めるべき検証 | 失敗しても本番稼働に影響しない補助処理 |
| 保守性 | チームが読める言語で書ける処理 | 特定メンバーしか理解できない複雑な処理 |
| 再実行性 | 何度実行しても安全な処理 | 二重登録や重複投入の危険がある処理 |
実務では、hookに入れる処理は冪等性を意識する必要があります。つまり、同じhookが複数回実行されても、同じ結果になるように設計することです。
たとえば、初期データ投入hookで「毎回INSERTする」だけの実装にすると、再デプロイ時にデータが重複します。実運用では、既存データを確認してから登録する、またはマイグレーションツールを使って変更履歴を管理する、といった対策が必要です。
AIアプリ開発ではクォータ事前確認が重要
April 2026更新では、AIモデルのクォータ事前確認も追加されています。azd provision実行時に、Bicepスナップショット内のAzure Cognitive Servicesモデルデプロイを検出し、プロビジョニング前にクォータの可用性を検証します。クォータ超過や認識できないモデル名がある場合は警告されます。(Microsoft for Developers)
これは、Azure OpenAIやAzure AI Servicesを使う開発チームにとって実用的な改善です。AIアプリでは、リージョン、モデル、SKU、クォータの組み合わせによってデプロイ可否が変わります。構成ファイル上は正しく見えても、実際のAzureサブスクリプションではクォータ不足で失敗することがあります。
今回の改善により、少なくとも一部のクォータ問題をプロビジョニング前に発見しやすくなります。ただし、すべての運用リスクがなくなるわけではありません。チームで確認すべきポイントは次の通りです。
- 利用予定リージョンで対象モデルが使えるか
- 必要なモデル容量がサブスクリプションに割り当てられているか
- 検証環境と本番環境でクォータ条件が違わないか
- Bicepや
azure.yamlのモデル名が最新の提供状況とずれていないか - 失敗時に別リージョンや別モデルへ切り替える運用手順があるか
AI関連のAzureリソースは提供状況が変わる可能性があります。azdの事前確認を過信せず、Azure Portalや公式ドキュメントでクォータとリージョンの状態を確認する運用も残しておくと安全です。
azd updateがPublic Previewになり更新しやすくなった
今回の更新では、azd updateがPublic Previewになりました。これにより、alpha機能フラグなしでazd updateを使えるようになり、初回利用時にはPreview通知が表示されます。(Microsoft for Developers)
従来、CLIツールの更新は、OSやインストール方法によって手順が分かれがちでした。WindowsならMSIやwinget、macOSならHomebrew、Linuxならパッケージやスクリプトなど、チーム内でも更新方法がばらつくことがあります。
azd updateが使いやすくなると、次のような運用がしやすくなります。
azd version
azd update
azd versionただし、Public Previewである点には注意が必要です。本番CI/CD環境では、常に最新へ自動更新するよりも、検証済みバージョンを固定するほうが安全な場合があります。
おすすめの運用は次の通りです。
| 環境 | azd更新方針 |
|---|---|
| 個人開発環境 | 比較的早めに更新して新機能を試す |
| チーム開発環境 | チームで検証後に推奨バージョンをそろえる |
| CI/CD環境 | バージョン固定を基本にし、更新前に検証ジョブを通す |
| 本番リリース直前 | 大きな更新は避け、既知の安定版を使う |
今回の更新にはセキュリティ関連の修正も含まれているため、放置はおすすめできません。特にWindows環境では、azd update時のMSIコード署名検証が改善され、想定外のMSIがインストールされるリスクを抑える修正が入っています。(Microsoft for Developers)
CI/CDでは--no-promptと--non-interactiveの挙動を確認する
CI/CDでazdを使っている場合、April 2026更新で見逃せないのが非対話実行まわりの変更です。
--non-interactiveが--no-promptのグローバルエイリアスとして使えるようになり、AZD_NON_INTERACTIVE環境変数でも非対話モードを有効にできます。また、--no-prompt実行時にサブスクリプション、場所、リソースグループなどの必須入力を解決できない場合、構造化されたエラーで一貫して失敗するようになりました。(Microsoft for Developers)
これは、CI/CDでは良い変更です。対話入力待ちでジョブが止まるより、必要な値が不足していることを明確にエラーにしてくれるほうが、運用しやすいからです。
CI/CDで確認すべき設定は次の通りです。
azd provision --no-prompt
azd deploy --no-promptまたは、環境変数で指定します。
export AZD_NON_INTERACTIVE=true
azd upGitHub ActionsやAzure Pipelinesでazdを使っている場合は、次の値が自動解決できるか確認してください。
- Azureサブスクリプション
- デプロイ先リージョン
- リソースグループ
- Azure環境名
- App Serviceのデプロイスロット
- 認証に使うIDまたはサービスプリンシパル
- 必要な環境変数やシークレット
更新後にCI/CDが急に失敗した場合、azdの不具合と決めつける前に、「これまで暗黙に補完されていた入力が、非対話モードで明示的なエラーになった」可能性を確認するとよいでしょう。
破壊的変更：azd init -t <template>は新しいディレクトリを作る
April 2026更新では、注意すべき破壊的変更もあります。
azd init -t <template>を実行した場合、従来のように現在のディレクトリへ初期化するのではなく、テンプレート名に基づく新しいプロジェクトディレクトリが作成されるようになりました。従来と同じように現在のディレクトリへ初期化したい場合は、.を明示します。(Microsoft for Developers)
azd init -t <template> .この変更は、git cloneに近い自然な挙動とも言えます。一方で、既存の手順書や社内ドキュメントで次のような流れを書いている場合は、修正が必要です。
mkdir my-app
cd my-app
azd init -t <template>更新後は、意図せずmy-app/<template-name>/のような二重ディレクトリ構成になる可能性があります。研修資料、ハンズオン、社内テンプレート利用手順では、azd initの挙動を確認してから案内を更新しましょう。
破壊的変更：App Serviceスロットは明示指定が必要
App Serviceを使っているチームでは、スロット指定の変更にも注意が必要です。
今回の更新で、App Serviceデプロイ時の自動的なスロット選択ロジックが、明示的なスロット指定に置き換えられました。メインアプリにデプロイする場合はAZD_DEPLOY_{SERVICE}_SLOT_NAME=production、特定スロットにデプロイする場合はAZD_DEPLOY_{SERVICE}_SLOT_NAME=<name>を設定します。スロットが存在し、スロット名が未設定の場合、対話モードではプロンプトが表示され、非対話モードではエラーになります。(Microsoft for Developers)
たとえば、サービス名がwebの場合は次のような指定になります。
export AZD_DEPLOY_WEB_SLOT_NAME=production
azd deployステージングスロットへデプロイする場合は、次のように指定します。
export AZD_DEPLOY_WEB_SLOT_NAME=staging
azd deployこの変更は、運用上は歓迎すべき内容です。自動推定による意図しないスロットへのデプロイを避けやすくなるためです。ただし、既存のCI/CDでは環境変数の追加が必要になる可能性があります。
特に確認すべきケースは次の通りです。
- App Serviceに本番スロットとステージングスロットがある
- 以前は
--no-promptでスロットが自動選択されていた - 初回デプロイ時に複数スロットへ一括反映する前提の運用がある
- ブルーグリーンデプロイやスロットスワップを使っている
- GitHub ActionsやAzure Pipelinesでスロット名を明示していない
更新後は、スロット名を環境変数として明示し、パイプラインのログで想定スロットへデプロイされているか確認してください。
Extension FrameworkとKey Vault連携の改善
April 2026更新では、Extension Frameworkにも変更があります。Extension FrameworkはBeta扱いですが、azd本体はGAです。今回の更新では、拡張機能の作者向けにカスタムプロビジョニングプロバイダーを登録できるようになり、ユーザーはazure.yamlでインフラプロバイダーを指定できるようになります。(Microsoft for Developers)
また、Key Vaultのシークレット参照を環境変数内で解決し、拡張機能へ渡す仕組みも追加されています。これにより、拡張機能を使ったワークフローでも、シークレット管理をAzure Key Vault中心に寄せやすくなります。
ただし、Extension FrameworkはBetaであるため、本番運用で独自拡張に大きく依存する場合は慎重に検証すべきです。特に、次の観点を確認してください。
| 確認項目 | 理由 |
|---|---|
| 拡張機能のバージョン固定 | 更新で挙動が変わる可能性を抑えるため |
| Key Vault参照の権限 | 実行IDに必要な読み取り権限があるか確認するため |
| CI/CDでの非対話実行 | 拡張機能更新や入力待ちで止まらないようにするため |
| ロールバック手順 | 拡張機能由来の障害時に戻せるようにするため |
拡張機能を使う場合でも、まずは標準のBicepやTerraform構成で実現できないかを検討し、必要な部分だけ拡張するのが現実的です。
.azdignoreと.azdxignoreでテンプレートとwatch modeが扱いやすくなる
プロジェクト初期化やテンプレート作成に関わる改善もあります。
テンプレート作者は、テンプレートルートに.azdignoreを作成することで、.github/やSECURITY.mdなど、利用者のプロジェクトへコピーしたくないファイルを除外できます。(Microsoft for Developers)
これは、社内テンプレートを作っているチームにとって便利です。テンプレートの保守に必要なファイルと、利用者に配布すべきファイルを分離しやすくなります。
また、watch mode向けには.azdxignoreが追加されています。プロジェクトルートに作成し、node_modules/やdist/などを除外することで、azd x watch時の不要な再ビルドを抑えられます。(Microsoft for Developers)
たとえば、フロントエンドを含むプロジェクトでは次のような設定が考えられます。
node_modules/
dist/
build/
coverage/
.tmp/watch modeで「なぜか頻繁に再ビルドが走る」「変更していないのに監視が反応する」という場合は、.azdxignoreを整備する価値があります。
Docker利用者はdocker.networkを確認する
コンテナベースのサービスでは、azure.yamlのDocker設定にdocker.networkが追加されました。この値はdocker buildの--networkに渡されます。企業ネットワークやプロキシ配下で、ビルド時にホストネットワークが必要な場合などに役立ちます。(Microsoft for Developers)
例として、Container Apps向けサービスでホストネットワークを使う場合は、次のような構成が考えられます。
services:
api:
project: ./src/api
host: containerapp
language: docker
docker:
network: hostただし、hostネットワークの利用は環境依存になりやすい設定です。ローカル開発環境では動くが、CI/CDランナーでは動かないというケースもあります。ネットワーク設定を追加する場合は、開発環境、CI/CD、本番相当環境で同じようにビルドできるか確認しましょう。
セキュリティ修正は早めに適用したい
今回のリリースには、複数のセキュリティ関連修正が含まれています。代表的なものは、Windows MSIインストール時のコード署名検証、拡張機能コマンドにおける環境変数の取り扱い修正、Aspireサーバー初期化時の安全でないグローバルな作業ディレクトリ変更の削除です。(Microsoft for Developers)
特に、拡張機能コマンドで誤ったazd環境のシークレットや設定が渡される可能性があった問題は、複数環境を扱うチームにとって重要です。開発、検証、本番の環境名を分けている場合、環境変数やシークレットの取り違えは重大な事故につながります。
更新後は、次の点を確認してください。
azd versionで利用バージョンを把握する- チーム内で利用バージョンをそろえる
- 拡張機能を使っている場合は、環境名指定の挙動を確認する
- Windows環境では
azd updateの実行可否を確認する - 管理者が配布している環境では、勝手に更新できない前提で運用手順を作る
セキュリティ修正を含むCLI更新は、機能追加より優先度を高く扱うべきです。一方で、本番パイプラインへ即時反映する前に、検証環境でazd provisionとazd deployを通しておくと安全です。
開発者・管理者・ウォッチャー別の確認ポイント
今回の更新は、読む人の立場によって見るべきポイントが異なります。
| 読者 | まず確認すべきこと | 次に取るべき行動 |
|---|---|---|
| アプリ開発者 | hooksを自分の主要言語で書けるか | 既存のBash/PowerShell処理を置き換える価値を判断する |
| DevOps担当者 | --no-promptとApp Serviceスロット指定 | CI/CDの環境変数と失敗条件を見直す |
| Azure管理者 | セキュリティ修正と更新方法 | 組織内のazd配布・更新ルールを確認する |
| AIアプリ開発者 | クォータ事前確認 | モデル、リージョン、容量の設計を見直す |
| テンプレート作者 | .azdignoreとマルチ言語hooks | 利用者に不要なファイルを配布しない構成にする |
| 製品ウォッチャー | Extension FrameworkとCopilot連携 | azdがAI支援と拡張性を強めている流れを把握する |
今回のリリースは、派手な新サービス発表というより、Azure開発の現場で起きやすい失敗を減らす更新です。特に、hook、非対話実行、スロット指定、クォータ確認は、実際のデプロイ品質に直結します。
既存プロジェクトでの確認手順
既存のazdプロジェクトを持っている場合は、次の順番で確認すると効率的です。
現在のバージョンを確認する
まず、現在使っているazdのバージョンを確認します。
azd version複数メンバーで開発している場合は、個人端末とCI/CD環境の両方を確認してください。ローカルだけ更新され、CI/CD側が古いままだと、同じazure.yamlでも挙動が変わる可能性があります。
検証環境で更新する
更新は、まず検証環境で行います。
azd updateazd updateはPublic Previewになっていますが、環境によっては管理者権限やインストール方式の制約を受ける場合があります。組織管理端末では、管理者が配布するバージョンを使う運用になっていることもあります。
azure.yamlを確認する
次に、azure.yamlを確認します。Microsoft Learnでは、azure.yamlはazdプロジェクトの構成ファイルであり、サービス、Azureリソース、インフラ、hooks、CI/CDパイプラインなどを定義すると説明されています。(Microsoft Learn)
特に見るべき項目は次の通りです。
hooksinfra.layersservicesdockerpipeline- App Serviceを使うサービス名
- AIモデル関連の設定
- 拡張機能やカスタムプロバイダーの有無
CI/CDで非対話実行をテストする
検証用ブランチや一時環境で、非対話実行を確認します。
azd provision --no-prompt
azd deploy --no-promptまたは、環境変数で非対話モードを有効にします。
AZD_NON_INTERACTIVE=true azd upここで失敗した場合は、必須値が不足している可能性があります。サブスクリプション、リージョン、リソースグループ、スロット名などを明示してください。
App Serviceスロットを明示する
App Serviceのデプロイスロットを使っている場合は、環境変数を追加します。
AZD_DEPLOY_WEB_SLOT_NAME=stagingWEBの部分はサービス名に応じて変わります。サービス名にスペースや特殊な命名がある場合は、環境変数名としてどう解釈されるかも確認しましょう。
hookの移行候補を洗い出す
最後に、既存のBashやPowerShell hookを確認します。すべてを移行する必要はありませんが、次のような処理は移行候補になります。
- アプリ本体と同じ言語で書いたほうが読みやすい処理
- 依存関係管理が必要な処理
- OS差分でBash/PowerShellを分けている処理
- テストコードやユーティリティを再利用したい処理
- 複雑化して保守しづらくなったシェルスクリプト
逆に、数行で終わる単純なファイルコピーや環境変数確認であれば、既存のBashやPowerShellのままでも問題ありません。移行の目的は「新機能を使うこと」ではなく、「保守性と再現性を上げること」です。
April 2026更新をどう評価すべきか
Azure Developer CLI (azd) – April 2026は、Azure開発の自動化をより実務向けにする更新です。最大の価値は、マルチ言語hooks対応によって、デプロイ周辺の処理をチームの得意な言語で書けるようになった点にあります。
一方で、破壊的変更も含まれています。azd init -t <template>のディレクトリ作成挙動、App Serviceスロットの明示指定、非対話実行時のエラー挙動は、既存プロジェクトやCI/CDに影響する可能性があります。
まずは、azd versionで現状を確認し、検証環境で更新後のazd provisionとazd deployを実行してください。そのうえで、CI/CDの環境変数、App Serviceスロット指定、既存hookの移行候補を順に見直すのが安全です。
今回の更新は、「azdを便利にする」だけでなく、「Azureへのデプロイを失敗しにくくする」ための改善が多いリリースです。Azureを使う開発チームは、早めに内容を把握し、自分たちのテンプレート、パイプライン、運用手順に反映しておくとよいでしょう。
コメント