MENU

Windowsでazd extension installがAccess is deniedになる原因と1.28.1以降の対処法

Azure

Windowsでazd extension installを実行した際に「Access is denied」と表示される場合、まず確認すべきなのはAzure Developer CLI本体のバージョンです。この問題は、拡張機能の実行ファイルを置き換える瞬間にWindowsの一時的なファイルロックが残り、削除や置換に失敗することで発生します。

既知の問題はAzure Developer CLI 1.28.1で修正されました。したがって、azdを1.28.1以上、できれば最新の安定版へ更新してから、拡張機能のインストールを再実行することが基本的な解決策です。2026年8月2日時点では1.29.0が最新安定版であり、1.28.1の修正も含まれています。(GitHub)

目次

azd extension installのAccess is deniedエラーは1.28.1で修正

Azure Developer CLI 1.28.1のリリースノートでは、Windows上でazd extension installが断続的に失敗し、次のようなエラーになる問題が修正されています。(GitHub)

failed to remove extension: ... Access is denied

この問題の要点は次のとおりです。

項目内容
発生するOSWindows
主な症状拡張機能の削除・再インストール・置換時にAccess is deniedになる
原因拡張機能の実行ファイルに一時的なファイルロックが残る
発生頻度毎回ではなく、断続的に発生する
修正バージョンAzure Developer CLI 1.28.1
推奨対応azd本体を1.28.1以上の最新安定版に更新する

ここで更新するのは拡張機能ではなく、Azure Developer CLI本体のazdです。Azure CLIのazや、azd extension upgradeだけを更新しても、古いazd本体を使い続けていれば根本的な修正にはなりません。

Access is deniedでも権限不足とは限らない

Windowsの「Access is denied」は、アクセス権限が不足しているときだけに発生するエラーではありません。

今回の既知問題では、拡張機能のプロセスが終了したあとも、Windowsが実行ファイルを短時間開いたままにすることがあります。また、ウイルス対策ソフトやEDRなど、別のプロセスがファイルを一時的に確認している場合もあります。

その状態でazdが古い拡張機能を削除し、新しい実行ファイルへ置き換えようとすると、Windowsからアクセス拒否または共有違反が返されます。(GitHub)

処理の流れを簡単にすると、次のようになります。

  1. azdが拡張機能の実行ファイルを起動する
  2. 拡張機能のプロセスが終了する
  3. Windows側では実行ファイルのロックが一時的に残る
  4. azdが既存の拡張機能を削除しようとする
  5. ロックが残っているため「Access is denied」になる

このため、同じコマンドをもう一度実行すると成功する場合があります。毎回確実に失敗するのではなく、成功したり失敗したりする点も、一時的なファイルロックであることを疑う材料です。

この既知問題に限れば、管理者権限の不足が直接の原因ではありません。最初からNTFSアクセス権を変更したり、ユーザープロファイル全体にフルコントロールを付与したりする対応は避けてください。

影響を受けるWindows環境

この問題は、特定のターミナルアプリではなく、Windowsのファイル操作に関係する問題です。そのため、PowerShellだけでなく、コマンドプロンプトやVisual Studio Codeの統合ターミナルから実行した場合にも発生する可能性があります。

環境・操作影響の可能性
Windows 10／11のローカル環境あり
Windows上のVisual Studio Code統合ターミナルあり
Windows Server上のビルド環境あり
WindowsのAzure Pipelinesエージェントあり
自己ホスト型のWindows CI/CDエージェントあり
azd extension install --forceによる再インストール特に影響を受けやすい
azd extension upgradeによる置換同じ削除処理を通るため影響する可能性がある
初めてインストールする拡張機能既存ファイルの置換がない場合は可能性が低い
WSL内にインストールしたLinux版azdこのWindows固有の問題の対象外
LinuxやmacOSこの既知問題の対象外

問題の発端となったテストでは、azd extension install --forceで既存の拡張機能を置き換える際に、拡張機能の実行ファイルがWindows上で開かれたままになっていました。(GitHub)

なお、公式リリースノートではazd extension installの問題として記載されていますが、実装上は拡張機能ディレクトリを削除する共通処理に修正が入っています。azd extension upgradeも一度既存の拡張機能をアンインストールしてから再インストールするため、同じ改善の対象になります。

1.28.1で追加されたファイルロック対策

Azure Developer CLI 1.28.1では、Windows上のファイル操作に再試行処理が追加されました。

対象となるのは、主に次のWindowsエラーです。

  • ERROR_SHARING_VIOLATION
  • ERROR_ACCESS_DENIED

これらのエラーが一時的なファイルロックによって発生した可能性がある場合、処理を即座に失敗させるのではなく、1秒間隔で最大10回再試行します。拡張機能ディレクトリの削除処理と、ファイル名の変更処理の両方で同じ再試行ロジックが使われています。

つまり、1.28.0以前では一瞬でもファイルがロックされていると失敗していた処理が、1.28.1以降ではロックが解除されるまで短時間待てるようになりました。

ユーザーが手動で待機処理を入れたり、何度もコマンドを実行し直したりする必要を減らす修正です。

azdを1.28.1以上へ更新する手順

現在のバージョンを確認する

PowerShellまたはコマンドプロンプトで、次のコマンドを実行します。

azd version

表示されたバージョンが1.28.0以前なら更新が必要です。

azd version 1.28.0 (...)

1.28.1以上であれば、今回のファイルロック対策は含まれています。

azd version 1.29.0 (...)

azd versionは、現在実際に呼び出されているAzure Developer CLI本体のバージョンを確認するコマンドです。(Microsoft Learn)

azd updateで最新安定版へ更新する

現在のAzure Developer CLIでは、インストール方法を判別して更新するazd updateコマンドが用意されています。

azd update

azd updateはベータ機能ですが、Winget、Chocolatey、MSI、インストールスクリプトなど、元のインストール方法に応じた更新処理を呼び出します。(Microsoft Learn)

古いバージョンでazd updateが利用できない場合や、組織の運用ルールでパッケージマネージャーを指定されている場合は、インストール時と同じ方法で更新します。

Wingetで更新する

Wingetからインストールした場合は、次のコマンドを実行します。

winget upgrade Microsoft.Azd

Chocolateyで更新する

Chocolateyからインストールした場合は、次のコマンドを実行します。

choco upgrade azd

PowerShellインストールスクリプトで更新する

Microsoftのインストールスクリプトを使って導入した場合は、同じスクリプトを再実行します。

powershell -ex AllSigned -c "Invoke-RestMethod 'https://aka.ms/install-azd.ps1' | Invoke-Expression"

Winget、Chocolatey、PowerShellスクリプトによる更新方法は、Microsoftの公式インストール手順でも案内されています。(Microsoft Learn)

更新後のバージョンを確認する

更新が終わったら、ターミナルを開き直して再確認します。

azd version

次の条件を満たしていれば、既知問題の修正が適用されています。

1.28.1以上

今から更新する場合は、1.28.1を個別に探して固定インストールする必要はありません。1.29.0など、1.28.1より新しい安定版にも修正は引き継がれているため、通常は最新安定版へ更新してください。(GitHub)

更新後に拡張機能を再インストールする

azd本体を更新したら、失敗していたコマンドを再実行します。

初回インストールの場合は、次の形式です。

azd extension install <extension-id>

既にインストール済みの拡張機能を更新する場合は、upgradeを使います。

azd extension upgrade <extension-id>

同じバージョンを強制的に再インストールする必要がある場合は、--forceを指定します。

azd extension install <extension-id> --force

--forceは、ダウングレードや同じ拡張機能の再インストールを含む強制インストールに使用できます。通常の更新であれば、まずazd extension upgradeを使い、必要な場合だけ--forceを選ぶのが安全です。(Microsoft Learn)

インストール結果は次のコマンドで確認できます。

azd extension list --installed

対象の拡張機能とバージョンが表示されれば、インストールは完了しています。(Microsoft Learn)

1.28.1以上でもAccess is deniedになる場合

azdを1.28.1以上へ更新してもエラーが続く場合は、既知問題とは別の原因が残っている可能性があります。

古いazdがPATHの先頭に残っていないか確認する

複数の方法でazdをインストールしていると、更新したものとは別の古い実行ファイルが呼び出されることがあります。

Windowsでは次のコマンドで、参照されるazdの場所を確認できます。

where.exe azd

複数のパスが表示された場合は、それぞれのインストール元を確認してください。

C:\Program Files\...
C:\Users\<ユーザー名>\AppData\Local\...

更新後もazd versionが古いままなら、PATH上で古い実行ファイルが優先されている可能性があります。使用していない旧バージョンをアンインストールするか、PATHの順序を整理します。

拡張機能のプロセスを終了する

対象の拡張機能を別のターミナル、Visual Studio Code、ビルドジョブなどで実行していないか確認します。

特に自己ホスト型CI/CDエージェントでは、前のジョブで起動したプロセスが残っていると、1.28.1の再試行時間を超えてロックが続く可能性があります。

次の順で確認すると切り分けやすくなります。

  1. 対象拡張機能を使用しているターミナルを閉じる
  2. Visual Studio CodeなどのIDEを終了する
  3. タスクマネージャーで関連プロセスを確認する
  4. 数秒待ってから再実行する
  5. 解消しない場合はWindowsを再起動する

再起動は有効な切り分け方法ですが、恒久対策ではありません。まずazd本体のバージョンを確認することが重要です。

セキュリティ製品やEDRを確認する

Microsoft Defenderや組織のEDR製品が、ダウンロードされた実行ファイルを検査している間、ロックが長く残る場合があります。

ただし、セキュリティ機能を無効化するのではなく、次の点を管理者へ確認してください。

  • 拡張機能の実行ファイルが隔離されていないか
  • アプリケーション制御ポリシーで実行や置換を拒否されていないか
  • ユーザープロファイル内への実行ファイル配置が禁止されていないか
  • EDRのログにブロック記録がないか

毎回同じ場所で確実に失敗する場合は、一時的なロックではなく、組織のセキュリティポリシーやアクセス権限が原因である可能性が高くなります。

debugログを取得する

詳細な原因を確認する場合は、--debugを追加します。

azd extension install <extension-id> --debug

ログをファイルへ保存する場合は、PowerShellで次のように実行できます。

azd extension install <extension-id> --debug *> azd-extension-debug.log

ログ内で次の文字列を確認します。

failed to remove extension
Access is denied
sharing violation

Microsoftも、予期しないazdの問題を調査する場合は--debugを使用するよう案内しています。ログを外部へ提出するときは、サブスクリプション情報、パス、トークンなどの機密情報を削除してください。(Microsoft Learn)

エラーの状況から原因を判断する方法

状況考えられる原因優先する対応
azdが1.28.0以前既知の一時ファイルロック問題1.28.1以上へ更新
同じコマンドが成功したり失敗したりする一時的なファイルロックazd更新後に再実行
--forceのときだけ失敗する既存実行ファイルの置換失敗1.28.1以上へ更新
更新したのにazd versionが古いPATH上に別のazdが存在where.exe azdで確認
1.28.1以上でも毎回失敗する実プロセス、EDR、アクセス権限プロセスとセキュリティログを確認
ダウンロード段階で失敗するネットワーク、プロキシ、証明書ファイルロックとは別問題として調査
LinuxやWSL内のLinux版でも失敗する今回とは別の原因エラー全文を--debugで確認

「Access is denied」という文字だけで管理者権限不足と判断せず、azdのバージョン、失敗した処理、再現性の3点を確認することが重要です。

CI/CDではazd 1.28.1以上を事前確認する

WindowsのCI/CD環境で拡張機能を自動インストールする場合は、ジョブの先頭でazdのバージョンを記録しておくと、同じ問題の再発を防ぎやすくなります。

PowerShellでは、次のように1.28.1未満をエラーにできます。

$versionOutput = azd version

if ($versionOutput -notmatch 'azd version\s+([0-9]+\.[0-9]+\.[0-9]+)') {
    throw "azdのバージョンを取得できませんでした: $versionOutput"
}

$currentVersion = [version]$Matches[1]
$minimumVersion = [version]'1.28.1'

if ($currentVersion -lt $minimumVersion) {
    throw "azd 1.28.1以上が必要です。現在のバージョン: $currentVersion"
}

Write-Host "使用するazd: $versionOutput"

自己ホスト型エージェントでは、前回のジョブでインストールされた拡張機能やプロセスが残る可能性があります。毎回無条件に--forceで再インストールするのではなく、必要に応じてazd extension list --installedで状態を確認し、更新が必要な場合はazd extension upgradeを使う運用が適しています。

Azure Developer CLI extensionsは現在ベータ段階の機能です。CI/CDで使用する場合は、azdの最低バージョンを明示し、実行ログにazd versionを残しておくと、将来の仕様変更や不具合も切り分けやすくなります。(Microsoft Learn)

まずazd本体を最新安定版へ更新する

Windowsでazd extension installが「Access is denied」になる既知問題は、アクセス権限そのものではなく、拡張機能の実行ファイルに残る一時的なファイルロックが原因でした。

対応の順序は次のとおりです。

  1. azd versionで現在のバージョンを確認する
  2. 1.28.0以前ならazd updateなどで最新安定版へ更新する
  3. 更新後に再度azd versionを確認する
  4. azd extension installまたはazd extension upgradeを再実行する
  5. 解消しない場合は、古いazdのPATH、残存プロセス、EDR、実際のアクセス権限を確認する

修正が入った最低バージョンは1.28.1ですが、更新先を1.28.1に固定する必要はありません。現在利用できる1.28.1以上の最新安定版へ更新するのが、最も確実で保守しやすい対応です。

Azure
Windows Azure Developer CLI azd extension Access is denied

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次