MENU

Azure Developer CLI（azd）May and June 2026更新まとめ：管理者が確認すべき影響と対応

Azure

Azure Developer CLI（azd）の「May and June 2026」更新は、単なる不具合修正のまとめではありません。開発端末のツール管理、CI/CDでの実行、複数サービスの並列デプロイ、TerraformやBicepを使ったプロビジョニング、GoによるAzure Functionsデプロイに影響する実務寄りの変更が含まれています。

最初に取るべき対応は、azd本体を最新版へ更新し、CIでazd upの出力文字列を監視していないか確認することです。あわせて、Container Appsの複数サービス構成、ACRリモートビルド、Terraform利用、複数テナント・複数サブスクリプション運用をしている環境では、検証環境でazd upとazd deployを再確認しておくべきです。

Microsoftは2026年6月26日に、2026年5月から6月にかけて公開されたAzure Developer CLIの9リリース分をまとめて発表しました。対象は1.24.3から1.26.0までで、新しいazd tool、azd exec、安全性を高めたマルチレイヤープロビジョニング、Ctrl+C時のキャンセル確認、Go Functions対応、拡張機能バンドルなどが主なポイントです。(Microsoft for Developers)

目次

Azure Developer CLI（azd）の今回の更新でまず確認すべきこと

今回のAzure Developer CLI（azd）更新で、管理者や開発リーダーが最初に見るべきポイントは次の4つです。

確認項目なぜ重要かすぐ行う対応
azd本体の更新セキュリティ改善と多数の修正が含まれるazd versionで現行版を確認し、検証環境から更新する
CI/CDのazd upログ判定出力形式が整理され、古いメッセージ監視が壊れる可能性がある旧メッセージ文字列に依存した条件分岐を探す
複数サービスの並列デプロイazd upが独立作業を並列化し、失敗時の見え方が変わるContainer Apps、ACR remote build、Aspire構成を再テストする
開発端末・CIエージェントのツール管理azd toolにより周辺ツールの検出・インストール・更新をCLIで扱える組織標準のセットアップ手順にazd tool checkを追加する

特に注意したいのは、azd upの出力変更です。従来の"Packaging services…"、"Provisioning Azure resources…"、"Deploying services…"などの文字列をCIの成功判定や通知条件に使っている場合、更新後に検出できなくなる可能性があります。Microsoftは、このような旧メッセージを監視しているCIはチェック内容を更新するよう案内しています。(Microsoft for Developers)

Azure Developer CLI（azd）とは何か

Azure Developer CLI（azd）は、Azure向けアプリケーションの初期化、インフラ作成、アプリ配置、監視、CI/CD構成をまとめて扱う開発者向けCLIです。Azure CLIやAzure PowerShellが個別リソースの細かな操作に強いのに対し、azdはアプリケーション単位のワークフローを短いコマンドで実行することに重点があります。Microsoft Learnでは、azd provisionが複数のAzureリソースをまとめてプロビジョニングする例が示されています。(Microsoft Learn)

典型的な使い方は、テンプレートを初期化してからazd upを実行し、インフラ作成とアプリのデプロイをまとめて進める流れです。

azd init
azd up

実務では、BicepやTerraformで定義したAzureリソース、azure.yamlで定義したサービス、GitHub ActionsやAzure PipelinesのCI/CD構成をつなぐ「開発からデプロイまでのオーケストレーター」として使われます。

主な新機能と変更点

azd toolで開発ツールの確認・インストール・更新をCLIから管理できる

今回の目立つ変更の一つが、新しいazd toolコマンド群です。azd toolは、Azure開発に必要な周辺ツールを検出、一覧表示、インストール、更新確認、アップグレードするための機能です。Microsoft Learnでは、azd toolがwinget、brew、apt、npm、VS Codeのcode CLIなど、各OSのパッケージマネージャーを背後で利用しながら、一貫したサブコマンドで操作できると説明されています。(Microsoft Learn)

よく使うコマンドは次の通りです。

azd tool list
azd tool check
azd tool install --all --dry-run
azd tool upgrade --all --dry-run

実務上の価値は、開発環境のばらつきを減らせる点です。たとえば、新しく参加した開発者のPCでBicep拡張、Azure CLI、VS Code拡張が不足していてazd upが途中で失敗する、といった問題を事前に検出しやすくなります。

ただし、企業管理端末やロックダウンされたCIエージェントでは、winget、brew、apt、npm、VS Code拡張のインストールが制限されている場合があります。いきなりazd tool install --allを実行するのではなく、まず--dry-runで何が変更されるかを確認し、社内のソフトウェア配布ルールに合わせて導入するのが安全です。

azd execで環境変数を読み込んだスクリプト実行がしやすくなる

azd execは、azdの環境コンテキストを読み込んだ状態でコマンドやスクリプトを実行する新しい仕組みです。公式ブログでは、azd execがazdの環境変数やKey Vaultシークレット解決を含むコンテキストを継承すると説明されています。(Microsoft for Developers)

たとえば、デプロイ後に環境変数を読み込んで検証スクリプトを実行したい場合、従来は.envを読み込む処理を各OS向けに書き分けることがありました。azd execを使うと、azdが管理する環境値を子プロセスへ渡しやすくなります。

azd exec python scripts/check_endpoint.py
azd exec npm run smoke-test
azd exec --shell pwsh "Write-Host $env:AZURE_ENV_NAME"

Microsoft Learnのリファレンスでも、azd execはazd環境変数にアクセスできる状態でコマンドやスクリプトを実行し、複数引数では直接実行、単一のクォート付き引数ではシェル経由のインライン実行になると説明されています。(Microsoft Learn)

CI/CDで使う場合は、秘密情報を標準出力へ出さないように注意してください。azd execが便利になるほど、スクリプト側でenvやprintenvを不用意に出力したときの情報漏えいリスクも高まります。

マルチレイヤープロビジョニングでdependsOnを明示できる

複雑なAzure構成では、ネットワーク、ID、データベース、アプリ基盤、アプリサービスを段階的に作成したい場面があります。今回の更新では、マルチレイヤープロビジョニングの依存関係解析が強化され、azure.yamlのinfra.layersでdependsOnを明示できるようになりました。公式ブログでは、これによりマルチレイヤープロビジョニングがより安全になると説明されています。(Microsoft for Developers)

Microsoft Learnのazure.yamlスキーマでは、infra.layersはAzureインフラのプロビジョニング層を定義する配列で、各レイヤーにname、path、任意のmodule、dependsOn、hooksを指定できるとされています。dependsOnは、静的解析だけでは推測できない依存関係を宣言するために使います。(Microsoft Learn)

例として、coreレイヤーでネットワークやKey Vaultを作成し、servicesレイヤーがその出力値に依存する場合は、次のように依存関係を明示します。

infra:
  provider: bicep
  layers:
    - name: core
      path: ./infra/core
    - name: services
      path: ./infra/services
      dependsOn:
        - core

実務では、次のような構成で確認が必要です。

構成確認すべき点
Bicepを複数フォルダーに分けているinfra.pathとinfra.layersを併用していないか
postprovisionで環境変数を書き換えている後続レイヤーとの依存をdependsOnで明示すべきか
TerraformやBicep以外のプロバイダーを使っている更新後のazd provisionを検証環境で再実行する
グローバル環境でリージョン別に構成を分けているレイヤーの実行順が想定どおりか確認する

デプロイとCI/CDへの影響

azd upの出力が整理され、CIの文字列監視に影響する

今回の破壊的変更として、azd upの表示が整理されました。従来はパッケージング、プロビジョニング、デプロイのように複数のステージバナーが表示されていましたが、新しい出力では最初から最後まで1つの進行表示に統合されます。(Microsoft for Developers)

人間がターミナルで見る分には分かりやすくなりますが、CI/CDでは注意が必要です。次のような実装がある場合は修正対象です。

# 例：避けたい判定
grep "Provisioning Azure resources" azd.log
grep "Your up workflow" azd.log

代わりに、終了コード、JSON出力、成果物ファイル、Azure側のデプロイ状態など、より安定した判定方法へ寄せるのが安全です。今回の更新では、AZD_DEPLOYMENT_ID_FILE環境変数により、プロビジョニング中のARMデプロイIDをNDJSON形式で扱えるようになったため、CIツールや拡張機能からAzure側のデプロイ追跡をしやすくなっています。(Microsoft for Developers)

並列化により、失敗時にもAzure側の処理が少し残る場合がある

azd upでは、独立した作業が並列に実行されるようになりました。これにより全体の所要時間短縮が期待できますが、あるステップが失敗したときに、別のAzureデプロイ処理がしばらく実行され続ける場合があります。公式ブログでも、失敗時に進行中の長時間デプロイが少し継続する可能性があると説明されています。(Microsoft for Developers)

管理者は、CIのタイムアウト設定とクリーンアップ手順を見直してください。特に検証用サブスクリプションでazd upが失敗した後、リソースグループ、ACRビルド、Container Apps、App Serviceなどが中途半端に残っていないかを確認する運用が必要です。

Ctrl+C時にAzure側のデプロイを残すかキャンセルするか選べる

azd provisionまたはazd up中にCtrl+Cを押した場合、対話モードではAzure側のデプロイをそのまま継続するか、ARM Cancel APIを通じてキャンセルするかを選べるようになりました。非対話モードでは、既定でAzure側のデプロイを残す動作になります。(Microsoft for Developers)

この変更は、手元の端末で誤って中断した場合には便利です。一方、CI/CDでは非対話モードが多いため、「ジョブが止まったからAzure側の処理も必ず止まった」と考えるのは危険です。パイプラインの中断、キャンセル、タイムアウト時には、Azure Portalやaz deployment系コマンドで実際のデプロイ状態を確認する設計にしておくと安全です。

Container Apps、ACR remote build、Aspire利用者は優先して検証したい

今回の修正では、並列実行に関連する不具合が多く解消されています。特に重要なのは、複数のContainer Appsを並列で発行し、docker.remoteBuild: trueを使ってACRリモートビルドを行うケースです。公式ブログでは、複数サービスのイメージが混ざる可能性のある問題が修正され、各並列アップロードが個別のBLOBへ送られるようになったと説明されています。(Microsoft for Developers)

該当する構成では、次の観点で検証してください。

対象確認内容
複数のContainer Appsサービスそれぞれ正しいコンテナイメージで起動しているか
docker.remoteBuild: truebuildArgsやbuildEnvがACRリモートビルドへ渡っているか
Aspire構成並列dotnet publishによる成果物競合が起きないか
Podman利用環境Dockerがない環境で想定どおりビルド・デプロイできるか
狭いターミナルやCIログ進捗表示が監視しやすい形で残るか

更新後に問題が解消されているかを見るだけでなく、既存のワークアラウンドが不要になっていないかも確認しましょう。たとえば、以前の競合を避けるために手動で直列実行していたスクリプトがある場合、更新後はシンプルなazd upへ戻せる可能性があります。

GoによるAzure Functions対応はPreviewとして扱う

今回の更新で、GoがAzure Functionsサービスのazd up対象としてサポートされました。Microsoft Learnでは、GoはAzure FunctionsのみPreviewとして記載され、Flex Consumptionプランへのデプロイに対応すると説明されています。(Microsoft Learn)

azure.yamlでは、サービスのlanguageにgo、hostにfunctionを指定します。

services:
  api:
    project: .
    host: function
    language: go

ただし、実運用で使う前に注意点があります。Microsoft Learnでは、Go 1.24以降が必要で、Go Function Appsではリモートビルドがサポートされず、ローカルで静的バイナリへコンパイルしてからパッケージ化されると説明されています。(Microsoft Learn)

つまり、CIエージェント側にGoのビルド環境が必要です。Node.jsやPythonのFunctionsと同じ感覚で、Azure側のリモートビルドに任せられるとは考えない方が安全です。

Terraform利用環境では認証方式を見直す

TerraformをIaCプロバイダーとして使っているazdプロジェクトでは、認証設定を確認してください。Microsoft Learnでは、Terraformのazurermプロバイダーはazdの資格情報キャッシュを読まず、Azure CLI経由で認証するため、azd auth loginだけではazd upのプロビジョニングで失敗すると説明されています。推奨手順は、azdをAzure CLI認証へ委任し、az loginを実行する方法です。(Microsoft Learn)

azd config set auth.useAzCliAuth true
az login

複数テナントを扱う場合は、テナントを明示してログインする運用も検討します。

az login --tenant <tenant-id>

Terraform構成を使うチームでは、ローカル端末だけでなくCI/CDのサービス接続、OIDC、フェデレーション資格情報の設定もあわせて確認してください。今回の修正では、GitHub OIDCのカスタムsubject claimに関連する不一致問題も修正されています。(Microsoft for Developers)

複数テナント・複数サブスクリプション環境で使いやすくなる

グローバル企業や複数事業部でAzureを利用している組織では、テナントとサブスクリプションの選択ミスが問題になりがちです。今回の更新では、複数テナントユーザー向けにサブスクリプション選択前のテナントピッカーが追加され、選択したテナントに応じてサブスクリプション一覧を絞り込めるようになりました。また、azd config sub-filter setとazd config sub-filter removeにより、テナントごとのサブスクリプションフィルターを保存できるようになっています。(Microsoft for Developers)

これは、開発者が誤って本番用サブスクリプションや別地域のサブスクリプションを選ぶ事故を減らすうえで有効です。管理者は、チームごとに利用してよいサブスクリプションの範囲を決め、azdの初期セットアップ手順にサブスクリプションフィルター設定を含めるとよいでしょう。

拡張機能の配布・更新も管理しやすくなる

azd拡張機能まわりでは、azd extension upgrade --allの改善、拡張レジストリのschemaVersion対応、依存関係解決、自己完結型の拡張バンドルなどが追加されています。自己完結型バンドルは、azd x pack --bundleで作成し、azd extension install <bundle.zip>でインストールできる仕組みです。(Microsoft for Developers)

企業環境では、外部レジストリに直接アクセスできないCI環境や、承認済み拡張機能だけを配布したいケースがあります。その場合、自己完結型バンドルは有用です。ただし、拡張機能はCLIの実行フローに深く関わるため、配布前に次の点を確認してください。

確認項目理由
拡張機能の入手元不正な拡張や改ざん済みZIPを避けるため
依存関係のバージョン範囲予期しない更新で挙動が変わるのを防ぐため
CIでの--output json利用更新結果を機械的に判定しやすくするため
レジストリスキーマの互換性古いレジストリ定義で更新が止まる可能性があるため

設定変更・移行期限・管理者が確認すべきポイント

今回の公式情報では、特定日までに必ず移行しなければならない移行期限は示されていません。ただし、セキュリティ改善が含まれ、Microsoftも最新版への更新を推奨しているため、次回の開発環境・CIイメージ更新に含めるのが現実的です。(Microsoft for Developers)

項目必須度推奨対応
azd本体の更新高検証環境で更新後、CIイメージと開発端末へ展開する
CIのログ判定変更高azd upの旧ステージ文字列に依存していないか検索する
azd tool導入中標準開発環境チェックにazd tool listとazd tool checkを追加する
azd exec活用中OSごとの環境変数読み込みスクリプトを置き換えられるか確認する
infra.layers.dependsOn中〜高複数レイヤー構成やhook経由の依存がある場合に明示する
Go Functions対象者のみ高Go 1.24以降、Flex Consumption、ローカルビルド前提を確認する
Terraform認証高auth.useAzCliAuthとaz loginの運用を標準化する
拡張機能バンドル対象者のみ中オフラインCIや制限環境での配布方式を決める
Ctrl+C時の扱い中中断時にAzure側のデプロイが残る可能性を運用手順に書く

更新前後の実務チェック手順

現在のバージョンと周辺ツールを確認する

まず、開発端末とCIエージェントでazd本体のバージョンを確認します。

azd version

次に、周辺ツールの状態を確認します。

azd tool list
azd tool check

組織でJSONを収集している場合は、スクリプトで扱いやすい形式にしておくと棚卸しに使えます。

azd tool list --output json

azd本体を更新する

Microsoft Learnのコマンドリファレンスでは、azd updateはazd本体を最新バージョンへ更新するコマンドとして掲載されています。インストール方法によっては、従来どおりwinget、Homebrew、インストールスクリプトなどで更新する運用も選べます。(Microsoft Learn)

azd update

注意したいのは、azd tool upgradeはazd本体ではなく、Azure開発に使う周辺ツールを更新するためのコマンドだという点です。azd本体の更新と、周辺ツールの更新は分けて管理してください。

代表的なプロジェクトでazd upを再実行する

更新後は、いきなり全プロジェクトへ展開するのではなく、代表的な構成を選んで検証します。

検証対象実行すること
App Service構成azd up、azd deploy、スロット運用の確認
Container Apps複数サービス各サービスのイメージ、環境変数、ログを確認
ACR remote builddocker.remoteBuild: trueのビルド引数と成果物を確認
Terraform構成azd config set auth.useAzCliAuth true後にazd upを確認
Go FunctionsCIエージェントでGo 1.24以降が利用できるか確認
拡張機能利用プロジェクトazd extension upgrade --all後の互換性を確認

CI/CDの非対話設定を明示する

CI/CDでは、対話プロンプトが出るとジョブが停止する可能性があります。azd toolの初回確認やazd upのプロンプトを避けるため、非対話設定を明示しておくと安全です。

export AZD_NON_INTERACTIVE=true
export AZD_SKIP_FIRST_RUN=true
azd up --no-prompt

Microsoft Learnでは、--no-prompt、AZD_NON_INTERACTIVE=true、AZD_SKIP_FIRST_RUN=true、CI環境の自動検出によって初回ツール確認やプロンプトを抑制できると説明されています。(Microsoft Learn)

ただし、非対話モードではCtrl+C時のキャンセル確認も表示されません。Azure側のデプロイが残る可能性を前提に、失敗時の後片付けや監視を設計してください。

よくある失敗パターンと回避策

azd tool install --allを管理端末でそのまま実行して失敗する

企業管理PCでは、パッケージマネージャーの実行、VS Code拡張の追加、npm経由のインストールが制限されていることがあります。まずは--dry-runで変更内容を確認し、社内の配布方式に合わせてツールを導入しましょう。

azd tool install --all --dry-run

CIが古いazd upの表示文字列を待ち続ける

今回の出力整理により、旧ステージ名に依存したCIは壊れる可能性があります。grepでログ文字列を探すより、終了コード、JSON、デプロイID、Azure側の状態確認へ移行するのが安全です。

Terraformでazd auth loginだけ実行して失敗する

Terraformのazurermプロバイダーはazdの認証キャッシュを読まないため、Azure CLI認証が必要です。Terraformプロジェクトでは、次の設定を標準手順に入れてください。

azd config set auth.useAzCliAuth true
az login

Go Functionsでリモートビルド前提のCIを組んでしまう

GoのAzure Functions対応は、ローカルで静的バイナリをビルドしてパッケージ化する前提です。CIイメージにGo 1.24以降を入れ、remoteBuild: trueに依存しない構成にしてください。

マルチレイヤー構成で暗黙の順序に頼る

postprovisionで作成した値を後続レイヤーが参照するような構成では、静的解析だけでは依存関係を推測できない場合があります。dependsOnでレイヤー間の関係を明示しておくと、将来のメンテナンスでも意図が伝わりやすくなります。

今回の更新をどう活用すべきか

Azure Developer CLI（azd）のMay and June 2026更新は、開発者の利便性向上と、チーム運用・CI/CD運用の安定化に寄った内容です。特にazd toolとazd execは、個人の手元だけでなく、チーム標準の開発環境やパイプラインの再現性を高めるために使えます。

一方で、azd upの出力変更、並列化、非対話モードでのキャンセル挙動など、既存の自動化に影響する変更もあります。更新そのものは急いで本番展開するより、まず検証環境で代表的な構成を試し、CIの判定ロジック、認証方式、サブスクリプション選択、拡張機能の管理手順を見直すのが安全です。

最初の一歩として、開発端末または検証用CIエージェントで次のコマンドを実行し、現状把握から始めてください。

azd version
azd tool list
azd tool check

そのうえで、azd updateによる本体更新、azd upの再検証、CIログ判定の修正を進めれば、今回の更新を安全に取り込めます。

Azure
CI/CD Azure azd Bicep Azure Developer CLI

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次