Microsoft Azure documentation update: [microsoft.azd.extensions] Registry update for 0.11.0 は、Azure Developer CLI（azd）の拡張機能開発用エクステンションである microsoft.azd.extensions 0.11.0 を、公式の拡張機能レジストリから扱えるようにする更新です。Azure App Service、Storage、VM などの Azure リソース仕様が直接変わる更新ではなく、影響の中心は azd x init、azd x build、azd x pack、azd x publish、azd x watch を使う拡張機能開発者、CI/CD、Dev Container 環境です。公式PRでは、0.11.0のアーティファクトURLと sha256 チェックサムを拡張機能レジストリへ追加し、azd x コマンドの補完仕様テストデータも更新したと説明されています。(GitHub)
結論から言うと、すぐに本番Azure環境の設定変更が必要になる更新ではありません。ただし、azd拡張機能を作成・公開しているチームは、0.11.0で変わった検証ルール、依存関係のみの拡張パック、Goスキャフォールド、secretプロンプト、.azdxignore対応を確認してから展開するべきです。リリースページでは azd-ext-microsoft-azd-extensions_0.11.0 が Pre-release と表示されており、リリースノート上のバージョン表記は 0.11.0（2026-05-19）です。(GitHub)
Microsoft Azure documentation updateとして押さえるべき要点
今回の「Registry update」は、名前だけ見るとAzureのコンテナレジストリやサービスレジストリの変更に見えるかもしれません。しかし実際には、Azure Developer CLI の拡張機能を配布・検出するための azd 拡張機能レジストリに関する更新です。
Azure Developer CLI の拡張機能は、azd の機能を追加・自動化・統合するためのモジュールで、拡張機能ソースというファイルまたはURLベースのマニフェストを通じて配布されます。公式の拡張機能ソースは azd に事前構成され、https://aka.ms/azd/extensions/registry でホストされると Microsoft Learn で説明されています。(Microsoft Learn)
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| 対象 | microsoft.azd.extensions 0.11.0 | azd拡張機能を作る・ビルドする・公開する開発者向け |
| 更新の中心 | 拡張機能レジストリへのアーティファクトURLとsha256チェックサムの追加 | azd extension install や azd extension upgrade で0.11.0を解決しやすくなる |
| 併せて変わるもの | azd x ... の補完仕様テストデータ | --capabilities、--tags、--output などのヘルプ・補完表示に影響する可能性 |
| 直接影響しにくいもの | Azure上の既存リソース、通常の azd up 利用者 | 拡張機能開発をしていない利用者は影響が限定的 |
| 注意点 | Pre-release扱い | 本番の拡張機能公開フローへ入れる前に検証環境で確認する |
microsoft.azd.extensions 0.11.0で何が変わるのか
レジストリに0.11.0の配布情報が追加される
公式PR #8275 の主な変更は、cli/azd/extensions/registry.json に microsoft.azd.extensions 0.11.0 のアーティファクトURLと sha256 チェックサムを登録することです。これは、azd が拡張機能を見つけ、指定バージョンを取得し、配布物の整合性を確認するための基礎情報にあたります。(GitHub)
管理者目線では、これは「Azureポータル上のリソース設定変更」ではなく、「開発者が使うCLI拡張機能の配布メタデータ更新」と捉えるのが正確です。社内でazd拡張機能の利用を制限している場合は、許可リスト、ミラーリング、プロキシ、社内検証済みバージョンの管理対象に microsoft.azd.extensions 0.11.0 を入れるかどうかを判断します。
azd x buildのメタデータ警告が非致命扱いになる
0.11.0では、azd x build における拡張機能メタデータの警告が、必ずしもビルド失敗として扱われなくなります。一方で、必須フィールドの欠落や利用不能なメタデータは引き続き検証エラーとして扱われます。リリースノートでは、metadata warnings を non-fatal にする一方で、required fields と unusable metadata は validation errors のままにすると説明されています。(GitHub)
この変更は便利ですが、CI/CDでは注意が必要です。以前は警告で止まっていたパイプラインが、0.11.0では成功する可能性があります。公開品質を厳しく管理したい場合は、azd x build の終了コードだけでなく、ログ内の warning もレビュー対象にしてください。
実務では、次のように分けて考えると安全です。
| 状態 | 0.11.0での扱い | 管理上の判断 |
|---|---|---|
| 推奨項目の不足などの警告 | 非致命扱いになり得る | CIは通っても、公開前レビューで確認する |
| 必須項目の不足 | エラー | 修正しない限り公開フローへ進めない |
| 実行不能なメタデータ | エラー | 拡張機能の設計または設定を修正する |
| 警告ゼロを品質基準にしたい場合 | 終了コードだけでは不十分な可能性 | ログ検査や独自のメタデータチェックを併用する |
azd x initの検証順序、タグ、名前空間、エラー表示が改善される
0.11.0では、azd x init の入力検証と初期化体験も改善されています。リリースノートでは、validation ordering、warning output、namespace/tag handling、--no-prompt時の --tags、子プロセスエラー表示の改善が挙げられています。(GitHub)
特に確認したいのは、スクリプトで azd x init --no-prompt を使っているケースです。対話式では問題なく動いても、CIやテンプレート生成ジョブでは引数の不足や名前空間の指定ミスが見落とされることがあります。0.11.0ではタグや名前空間の扱いが整理されているため、既存スクリプトの引数を再確認しておくと、生成物の差分を予測しやすくなります。
例として、次のような観点で確認します。
# インストール済み拡張機能を確認
azd extension list --installed
# 対象拡張機能をバージョン指定で検証環境に導入
azd extension install microsoft.azd.extensions -v 0.11.0
# 既存スクリプトで使っている初期化コマンドを検証
azd x init --no-prompt依存関係のみの拡張パックを扱いやすくなる
0.11.0では、dependency-only extension packs が azd x build、azd x pack、azd x publish でサポートされます。リリースノートでは、依存関係のみのレジストリメタデータ公開や、アーティファクトがない場合の明確なメッセージにも触れられています。(GitHub)
これは、実行ファイルを持たず、複数の拡張機能や依存関係を束ねる目的のパックを作る場合に重要です。従来のように「形だけの実行ファイルメタデータ」を用意して回避するのではなく、依存関係のみのパックとして正しく定義できる方向に進んでいます。
一方で、実行可能な拡張機能なのに対応するアーティファクトがない場合、azd x publish は空のアーティファクトマップを公開するのではなく失敗するようになります。これは公開事故を防ぐ改善ですが、既存の公開ジョブでは失敗条件が変わる可能性があります。アーキテクチャ別の成果物、ファイル名、レジストリメタデータの対応関係を確認してください。
Goスキャフォールドがazdextランタイムに沿う
0.11.0には、拡張機能開発キットを azdext ランタイムへ移行し、生成されるGo拡張機能スキャフォールドを更新する変更も含まれます。関連PRでは、azdext.Run と NewExtensionRootCommand を使うSDK寄りの構成へ移行し、Goテンプレートや capability ドキュメント、スキーマを更新したと説明されています。(GitHub)
新規に azd x init でGo拡張機能を作るチームは、生成される go.mod、コマンド定義、グローバルフラグの扱いが以前のテンプレートと異なる可能性があります。既存拡張機能をすぐに書き換える必要があるとは限りませんが、新旧テンプレートの差分を確認し、将来的な移行計画を立てておくと保守しやすくなります。
secretプロンプトに対応する
0.11.0では、スキャフォールドされた拡張機能の gRPC prompt contract に secret prompt option のサポートが追加されています。関連PRでは、入力値をパスワードのようにマスクするための Secret フラグを core prompt と gRPC extension prompt API に追加したと説明されています。(GitHub)
これは、APIキー、接続文字列、トークンのような機密情報を拡張機能から入力させる場合に役立ちます。ただし、入力欄がマスクされるだけで安全対策が完了するわけではありません。拡張機能側でログに出力しない、標準出力に混ぜない、平文で設定ファイルへ保存しない、必要に応じてAzure Key Vaultや環境変数を使う、といった実装上の配慮が必要です。
azd x watchが.azdxignoreと.gitignoreを考慮する
0.11.0では、azd x watch が .azdxignore と .gitignore をサポートします。関連PRでは、.azdxignore が gitignore 構文で扱われ、.gitignore とあわせてファイルやディレクトリをリビルドトリガーから除外できると説明されています。(GitHub)
これは開発体験に直結します。生成ファイル、ログ、キャッシュ、ビルド成果物まで監視対象に入ると、無駄な再ビルドやwatchのループが起きやすくなります。0.11.0を使う場合は、拡張機能リポジトリに次のような .azdxignore を用意すると、watchのノイズを減らせます。
bin/
dist/
tmp/
*.log
coverage/
node_modules/ただし、.gitignore で除外しているファイルが azd x watch でも無視される可能性があります。開発中に「変更したのにwatchが反応しない」と感じた場合は、まず .gitignore と .azdxignore の両方を確認してください。
影響範囲：誰が確認すべきか
今回の更新で最も影響を受けるのは、Azure Developer CLIの通常利用者ではなく、azd拡張機能の開発・検証・公開を担当しているチームです。
| 対象者 | 影響度 | 確認ポイント |
|---|---|---|
| azd拡張機能の開発者 | 高 | azd x init/build/pack/publish/watch の挙動、生成コード、警告表示 |
| CI/CD管理者 | 高 | buildが警告で止まらなくなる可能性、publish失敗条件、バージョン固定 |
| 社内ツール管理者 | 中 | 公式拡張機能レジストリへのアクセス、許可済みバージョン、sha256確認 |
| Dev Container利用チーム | 中 | devcontainer.json の extensions 指定、コンテナ再ビルド |
| 通常のAzureアプリ開発者 | 低 | 拡張機能を使っていなければ影響は限定的 |
| Azureリソース運用担当者 | 低 | Azure上の既存リソース設定が直接変更される更新ではない |
Microsoft Learnでは、Dev Container Feature の extensions オプションに azd拡張機能名のカンマ区切りリストを指定でき、拡張機能はコンテナビルド時にインストールされると説明されています。拡張機能の一覧を変えた後は、VS Codeの「Rebuild and Reopen in Dev Container」でコンテナを再構築する必要があります。(Microsoft Learn)
管理者・開発者が行うべき確認手順
現在のazd環境を確認する
まず、開発端末、CIランナー、Dev Containerで使っているazdと拡張機能の状態を確認します。azdのリファレンスでは、azd version はAzure Developer CLIのバージョン番号を表示するコマンドとして説明されています。(Microsoft Learn)
azd version
azd extension source list
azd extension list --installedazd extension source list で、公式レジストリ以外に社内レジストリや開発用レジストリを追加していないか確認します。チーム内で異なるソースを使っていると、同じ microsoft.azd.extensions でも取得できるバージョンやタイミングがずれることがあります。
検証環境で0.11.0を導入する
いきなり本番の拡張機能公開フローに組み込まず、まず検証用の端末またはCIジョブでバージョン指定して導入します。Microsoft Learnでは、azd extension install に -v, --version を指定でき、azd extension upgrade にもバージョン制約を指定できると説明されています。(Microsoft Learn)
# 新規インストールの例
azd extension install microsoft.azd.extensions -v 0.11.0
# 既存インストールを検証用に更新する例
azd extension upgrade microsoft.azd.extensions -v 0.11.0社内で拡張機能のバージョンを固定している場合は、ローカルだけで更新せず、CI定義、Dev Container、オンボーディング手順書も同じバージョンに揃えます。
既存の拡張機能プロジェクトで一通りテストする
0.11.0で確認すべきコマンドは、単なるインストール確認だけでは足りません。特に、公開まで自動化している場合は、次の流れで検証します。
# 既存プロジェクトでビルド
azd x build
# パッケージング
azd x pack
# 公開前のメタデータ確認
azd x publish実行時は、成功・失敗だけでなく、warningの内容も記録します。0.11.0では警告が非致命になるため、「CIが成功したから問題なし」と判断すると、推奨メタデータ不足のまま公開に進む可能性があります。
azd x publishの成果物判定を確認する
実行可能な拡張機能では、対象OS・アーキテクチャごとのアーティファクトがメタデータと一致しているかを確認してください。0.11.0では、実行可能な拡張機能に対応アーティファクトがない場合、空のアーティファクトマップを公開するのではなく失敗します。(GitHub)
確認すべきポイントは次のとおりです。
- ビルド成果物のファイル名がpublish側の想定と一致しているか
- 対象プラットフォームを増減したときに古いメタデータが残っていないか
- dependency-only extension pack なのに、不要な実行ファイル設定を残していないか
- CIの作業ディレクトリや成果物パスが0.11.0でも同じか
watch対象から除外すべきファイルを整理する
azd x watch を日常的に使う場合は、.azdxignore を用意しておくと効率的です。特に、コード生成やビルドでファイルが大量に更新されるプロジェクトでは、watch対象を絞るだけで開発体験が大きく改善します。
一方で、.gitignore の影響も受けるため、watchしてほしいファイルを誤って除外していないか確認してください。たとえば、生成コードをGit管理していないがwatch対象にはしたい場合、.gitignore 側のルールと開発フローを見直す必要があります。
移行・展開時に失敗しやすいポイント
Pre-releaseを本番フローにそのまま入れてしまう
GitHubのリリースページでは、azd-ext-microsoft-azd-extensions_0.11.0 が Pre-release と表示されています。さらに、Microsoft Learnでは azd extensions 自体が beta と説明されています。(GitHub)
そのため、社内標準ツールとして配布する場合は、少なくとも次の確認を済ませてから採用してください。
| 確認項目 | 推奨対応 |
|---|---|
| 既存拡張機能のビルド | warningを含めてログをレビューする |
| 公開ジョブ | 成果物なしの失敗条件を確認する |
| Dev Container | 再ビルド後に同じコマンドが使えるか確認する |
| 社内プロキシ | GitHubリリースアセットへのアクセス可否を確認する |
| ロールバック | 以前の拡張機能バージョンへ戻す手順を残す |
warningを品質ゲートとして見ていない
0.11.0では、警告が非致命扱いになることで開発中の摩擦は減ります。しかし、組織の品質基準によっては「警告ありで公開できる」状態は望ましくありません。特に、capability、provider、tag、namespace のようなメタデータは、将来の検索性や運用性に影響します。
CIでは、終了コードだけでなくログを保存し、公開前レビューでwarningを確認できるようにしておくと安全です。
補完やヘルプ文言をスクリプトで解析している
公式PRでは、azd x ... の Fig completion spec testdata も更新され、--capabilities、--tags、--output などのフラグ説明や表示対象が変わることが示されています。(GitHub)
ヘルプテキストや補完出力をgrepして判定しているスクリプトは、軽微な文言変更で壊れやすくなります。可能であれば、安定した出力形式、明示的な設定ファイル、テスト用の固定メタデータを使って判定する構成に切り替えてください。
secret入力を安全な保存と混同する
secretプロンプトは入力表示をマスクするための改善です。保存先、ログ、テレメトリ、標準出力まで自動的に安全になるわけではありません。拡張機能側で機密情報を扱う場合は、入力後の取り扱いまで設計してください。
避けるべき例は次のとおりです。
- 入力されたAPIキーをログに出す
- extension.yaml に平文で保存する
- CIの標準出力に接続文字列を表示する
- デバッグ用のJSONにsecretを含めたまま成果物として保存するよくある疑問
今回のRegistry updateはAzure Container Registryの変更ですか？
違います。今回のRegistry updateは、Azure Developer CLIの拡張機能ソースレジストリに関する更新です。Azure Container Registry（ACR）のリポジトリ、イメージ、認証設定を変更するものではありません。
既存のAzureリソースに影響しますか？
通常は影響しません。今回の更新は microsoft.azd.extensions というazd拡張機能開発用のエクステンションに関するものです。Azure上のApp Service、Container Apps、Storage、Key Vaultなどの既存リソース設定が、この更新だけで変更されるわけではありません。
全員が0.11.0へ更新すべきですか？
azd拡張機能を作成・公開している人は検証する価値があります。一方、通常のアプリ開発で azd up や azd deploy だけを使っており、azd x コマンドを使っていない場合、優先度は高くありません。チーム標準として導入する場合は、Pre-releaseである点を踏まえて段階的に展開してください。
Dev Containerでは何を確認すべきですか？
devcontainer.json で azd拡張機能を自動インストールしている場合、extensions の指定、コンテナビルド時の取得元、再ビルド後のコマンド動作を確認します。Microsoft Learnでは、拡張機能の一覧を変更した後はコンテナを再構築する必要があると説明されています。(Microsoft Learn)
まず取るべきアクション
今回の Microsoft Azure documentation update: [microsoft.azd.extensions] Registry update for 0.11.0 は、Azure本体の運用設定変更ではなく、Azure Developer CLIの拡張機能開発フローに関わる更新です。対応の優先順位は、azd x を使っているかどうかで判断してください。
azd x を使っている場合は、まず検証環境で microsoft.azd.extensions 0.11.0 を導入し、azd x build のwarning、azd x publish の成果物判定、azd x init --no-prompt の引数、.azdxignore と .gitignore のwatch挙動を確認します。そのうえで、CI/CD、Dev Container、社内手順書、バージョン固定ルールを更新すると、展開時のトラブルを減らせます。
特に管理者は、「インストールできるか」だけでなく、「どのバージョンを誰が使い、どのレジストリから取得し、どのログを品質判定に使うか」まで決めておくことが重要です。0.11.0は拡張機能開発を進めやすくする更新ですが、Pre-release扱いであるため、まずは小さな検証環境から始めるのが現実的です。
コメント