Azure Developer CLI 1.23.15で最初に押さえるべき結論は2つです。1つは、azure.yaml のフックが Python / JavaScript / TypeScript を直接扱えるようになり、テンプレート駆動型アプリのプロビジョニングやデプロイ前後の自動処理を書きやすくなったこと。もう1つは、App Service のデプロイスロット運用が明示指定に変わり、これまでの「自動で選ばれる」前提の CI/CD や --no-prompt 実行が、そのままでは通らないケースが出ることです。GitHub Releases 上では 2026年4月11日に公開され、版表記は 1.23.15 (2026-04-10) です。 (GitHub)
今回の更新は、単なる小さなメンテナンス版ではありません。テンプレート作者にとってはシェルラッパーを減らせる更新であり、App Service スロットを使うチームにとっては運用ルールの見直しが必要な更新です。この記事では、何が変わったのかだけでなく、どのケースで影響を受け、何を直せばよいのかまで実務目線で整理します。 (GitHub)
Azure Developer CLI 1.23.15の要点
azure.yamlのフックで.pyを直接実行できるようになり、requirements.txtまたはpyproject.tomlがある場合は仮想環境の作成と依存関係の導入まで自動化されます。 (GitHub).jsと.tsのフックもサポートされ、package.jsonがあれば自動で依存関係を導入し、TypeScript はnpx tsxでビルドなし実行が可能になりました。 (GitHub)- App Service スロットへのデプロイは、従来の自動判定から明示指定へ変更されました。スロットが存在するのに
SLOT_NAMEを指定しない非対話実行は、今後はエラーになります。 (GitHub) hooks:ブロックで、単一フック形式と複数フック形式を混在させたときのパース失敗も修正されています。テンプレート作者には地味ですが効く修正です。 (GitHub)
azure.yaml フック強化で、テンプレート駆動型アプリの作り方が変わる
Azure Developer CLI のフックは、azd コマンドの前後やサービスのライフサイクルイベントでスクリプトを自動実行する仕組みです。コマンドレベルでは preprovision / postprovision / predeploy / postdeploy などが使え、サービスレベルでは prebuild / postbuild なども定義できます。つまり、今回の更新は「テンプレートの外側に置いた補助スクリプト」を扱いやすくするアップデートだと考えると理解しやすいです。 (Microsoft Learn)
これまで、Node 系や Python 系のテンプレートでも、フック実行のために Bash や PowerShell の薄いラッパーを挟む場面が少なくありませんでした。1.23.15 では .py、.js、.ts をそのままフックとして指定できるため、アプリ本体と同じ言語で補助処理を書きやすくなります。テンプレート配布時の学習コストが下がり、OS 差異に悩まされやすいシェル記法の依存も減らせます。これはリリースノート上の新機能から読み取れる、実務上の大きなメリットです。 (GitHub)
たとえば、次のような azure.yaml はかなり自然です。今回の更新以降は、こうした書き方をテンプレートの標準にしやすくなります。 (GitHub)
hooks:
preprovision:
run: ./hooks/check-subscription.py
postdeploy:
run: ./hooks/smoke-test.ts
services:
api:
project: ./src/api
language: ts
host: appservice
hooks:
prebuild:
run: ./hooks/generate-client.jsPython フックは「仮想環境まで自動」が実務で効く
Python フックでは、.py を指定すると azd が拡張子から自動判定し、必要に応じて仮想環境を作成し、requirements.txt や pyproject.toml から依存関係を導入して実行します。テンプレート利用者が事前に手作業で venv を切ったり、README 通りに依存関係を整えたりする負担が減るため、初回セットアップや再現性の面でかなり扱いやすくなります。特に postprovision で初期データ投入、predeploy で環境チェック、postdeploy で疎通確認を行うテンプレートでは恩恵が大きいです。 (GitHub)
JavaScript / TypeScript フックは Node 系テンプレートと相性がいい
JavaScript / TypeScript フックでは、.js と .ts が自動判定され、package.json があれば依存関係を導入します。TypeScript は npx tsx でそのまま実行されるため、別途コンパイル工程や tsconfig.json を前提にしない運用ができます。Node 系プロジェクトで、環境変数の整形、コード生成、スモークテスト、サンプルデータ登録まで TypeScript で統一したいチームにはかなり相性がよい更新です。 (GitHub)
ただし注意点もあります。依存関係の導入は現時点で npm ベースで、pnpm や yarn の自動検出は将来対応とされています。普段の開発では pnpm を使っていても、フックだけは npm install 前提で動く可能性があるため、lockfile や node_modules の前提が厳しいプロジェクトでは先に検証したほうが安全です。 (GitHub)
失敗しやすいポイントは「相対パス」と「実行位置」
フックの扱いで見落としやすいのが、実行時のカレントディレクトリです。ルートに定義したコマンドフックはプロジェクトルート基準、サービスフックはそのサービスの project ディレクトリ基準で動きます。シェルラッパーを廃止して .py や .ts に置き換えるときは、相対パスがずれていないかを最初に確認してください。ここを雑に移行すると、「依存関係は入ったのにファイルだけ見つからない」という中途半端な失敗が起きやすいです。 (Microsoft Learn)
階層型プロビジョニングやモノレポでは、今回の更新がより効く
Azure Developer CLI では、azure.yaml に複数のレイヤーを定義する階層型プロビジョニングが使えます。各レイヤーは独自の IaC テンプレートを持ち、上から順にプロビジョニングされます。さらに、標準の azd 機能は各レイヤーで機能し、コマンドレベルのフックはレイヤーごとに呼び出されます。 (Microsoft Learn)
この前提で見ると、1.23.15 のフック強化は単なる「スクリプト言語対応」ではありません。たとえば base レイヤーでネットワークや ID を作り、app レイヤーでアプリ用リソースを作る構成なら、確認ロジックや補助処理を Python や TypeScript で素直に書けます。モノレポで複数サービスを持つテンプレートや、Bicep と Terraform を混在させる構成でも、補助処理の言語をアプリ側に寄せやすくなります。 (Microsoft Learn)
一方で、ここには設計上の注意もあります。階層型プロビジョニングではコマンドフックが各レイヤーで実行されるため、重い postprovision をルートに置くと、レイヤー数ぶん実行される可能性があります。たとえば DB 初期化や検索インデックス投入のような「一度だけでよい処理」は、どのレイヤーで走るべきかを明確にしておかないと二重実行の原因になります。今回の更新でフックが書きやすくなったぶん、実行回数の設計はより重要になります。 (Microsoft Learn)
hooks: の混在書式修正は、テンプレート保守でじわじわ効く
1.23.15 には、hooks: ブロックで単一フック形式と複数フック形式を混在させるとパースに失敗する不具合修正も含まれています。従来は、あるイベントでは windows: / posix: を使った単一マップ形式、別のイベントでは複数フックの配列形式、という自然な書き方をすると崩れることがありました。今回の修正で両者を同じ hooks: ブロックに共存させられます。 (GitHub)
これはテンプレート作者にとってかなり実用的です。無理に全部を配列形式へ寄せる回避策や、OS ごとの処理を別ファイルに逃がす構成を続けなくてよくなるからです。フックが増えてきたテンプレートほど、今回の修正は可読性と保守性の改善につながります。 (GitHub)
内部ループで最も注意したいのは App Service スロットの breaking change
azd deploy は、標準的な開発の反復作業、つまり内部ループ向けのコマンドとして整理されています。今回の 1.23.15 では、その内部ループに直結する App Service スロットの挙動が変わりました。これまでのような自動ルーティングではなく、どこへデプロイするかを明示する方向へ寄せられています。 (Microsoft Learn)
何が変わったのか
AZD_DEPLOY_{SERVICE}_SLOT_NAME=productionを指定すると、メインアプリにデプロイされます。productionは Azure 側で予約済みのため、スロット名と衝突しない前提で使えます。 (GitHub)AZD_DEPLOY_{SERVICE}_SLOT_NAME=stagingのように指定すると、そのスロットにデプロイされます。存在しないスロット名を指定すると、利用可能な候補付きでエラーになります。 (GitHub)- スロットが存在するのに
SLOT_NAMEを指定せず、しかも--no-promptなどの非対話実行をすると、今後はエラーになります。対話実行ならproduction (main app)と各スロット名の選択肢が表示されます。 (GitHub) - これまでの「スロットが1つなら自動で選ぶ」挙動と、「初回デプロイ時に全スロットへ流す」挙動は削除されました。 (GitHub)
どのケースが影響を受けるか
影響が大きいのは、App Service でデプロイスロットを使っており、かつ CI/CD やスクリプトで azd deploy --no-prompt を回しているチームです。これまでたまたま自動判定で通っていたパイプラインは、1.23.15 以降は失敗に変わる可能性があります。逆に、App Service でもスロットを使っていない場合は、スロット未存在時は従来どおりメインアプリへデプロイされるため、影響は限定的です。 (GitHub)
すぐにやるべき対応
まずは、azure.yaml にある App Service ホストのサービスごとに、どのスロットへデプロイすべきかを明文化してください。特に複数サービスを持つテンプレートでは、「Web は production、API は staging」のようにサービス単位で変わることがあります。そこを曖昧にしたまま更新すると、内部ループでも本番寄り環境でも事故のもとです。 (GitHub)
設定の考え方はシンプルです。サービスごとに AZD_DEPLOY_{SERVICE}_SLOT_NAME を決め、.env や CI の変数に入れます。命名は azure.yaml のサービス単位で考えると整理しやすいです。 (GitHub)
AZD_DEPLOY_WEB_SLOT_NAME=production
AZD_DEPLOY_API_SLOT_NAME=stagingまた、スロットを使う運用では、更新直後に一度 azd deploy --no-prompt をステージング環境で実行し、明示指定が漏れていないか確認しておくと安全です。azd deploy 自体が内部ループ向けコマンドなので、日常の反復開発フローを止めないためにも、この確認は早めに済ませる価値があります。 (Microsoft Learn)
swap を使っているなら、表記も見直したい
スロット入れ替えを使う場合、swap 側でも production がメインアプリを指す扱いに寄せられています。@production も使えますが、従来の @main はまだ動く一方で非推奨警告が出ます。将来のメンテナンスまで考えるなら、今のうちに production 表記へ寄せておくほうが無難です。 (GitHub)
そのほかの修正も見逃せない
今回のリリースには、メインテーマ以外にも実務に効く修正があります。azd auth token は、拡張機能の資格情報プロバイダーからサブプロセスとして呼ばれたときに、バックグラウンドの更新チェックで終了させられる不具合が修正されました。さらに、古いリフレッシュトークン起因の認証エラーでは、正しいサブスクリプションテナント向けの再認証ガイダンスが返るようになっています。加えて、同梱される Bicep CLI は v0.42.1 に更新されました。 (GitHub)
ここまで含めて見ると、1.23.15 は「フック開発体験の改善」「App Service スロット運用の明確化」「周辺の安定性向上」がまとまって入ったリリースです。表面的には小さい更新に見えても、テンプレート作者と App Service 利用者には意外と影響が大きい版だといえます。 (GitHub)
まとめ：更新後にまず確認したい3点
azure.yamlのフックを見直し、Shell ラッパーで無理をしている処理を Python / JavaScript / TypeScript へ寄せられないか確認する。特にテンプレート配布用リポジトリでは効果が大きいです。 (GitHub)- App Service スロットを使うサービスでは、
AZD_DEPLOY_{SERVICE}_SLOT_NAMEを必ず明示し、--no-prompt実行を一度通しておく。ここを怠ると更新後の内部ループや CI が止まりやすくなります。 (Microsoft Learn) hooks:の古い回避策を整理し、混在書式やパス基準を含めてテンプレートの可読性を上げる。複雑なテンプレートほど、今回の修正を取り込む価値があります。 (GitHub)
1.23.15 は、新機能を試すだけのリリースではありません。テンプレート駆動型アプリのプロビジョニングをより自然な言語で書けるようにしつつ、App Service スロット運用には「曖昧さを残さない」ルールを持ち込んだ更新です。更新したらまず、フックの整理とスロット指定の明文化から始めるのが正解です。 (GitHub)
コメント