Claude Media
Claude Desktopの更新が0x80073D25で失敗する — RDS・Windows Serverの回避策
ClaudeTips

Claude Desktopの更新が0x80073D25で失敗する — RDS・Windows Serverの回避策

RDSホストでClaude Desktop(MSIX)を更新すると、他のユーザーがサインイン中のあいだ0x80073D25で失敗します。報告された再現条件と、自動更新を止めて管理者が更新する回避手順をまとめます。

読了目安 約11分

Windows ServerのRemote Desktop Session Host(RDS)にClaude Desktop(MSIX版)を入れ、複数ユーザーが使っている環境では、ユーザー単位の更新が0x80073D25で失敗する報告があります。他のユーザーがサインインしたままだと、更新した本人のセッションでも成功しません。

この件はGitHubのissue(claude-code#104564)に報告された状態で、コメントはまだなく、Anthropic側の見解も付いていません。原因の断定は避け、報告された再現条件と、報告者が使っている回避策、公式のサポート記事から言える範囲を分けて書きます。

0x80073D25が出るのはどんな条件か

issueの報告者の環境は、Windows Server 2025のRDSホストに複数ユーザーがいて、各ユーザーがそれぞれClaudeを登録している構成です。Claude Desktopのバージョンは3.6556.2.0(MSIX、x64)と書かれています。

失敗は次の手順で再現するとされています。

手順

報告されている再現手順

  1. 1

    2人のユーザーにClaudeを入れる

    RDSホストでユーザーAとBの両方にClaude Desktop(MSIX)を入れます。

  2. 2

    Bをサインインしたままにする

    Bのセッションは、Claudeを閉じた状態でも、切断(disconnected)状態でも構いません。

  3. 3

    Aとして更新する

    内蔵のアップデーターか、新しいMSIXを指定したAdd-AppxPackageで更新します。

  4. 4

    Bがサインアウトするまで失敗する

    HRESULT 0x80073D25で止まります。

注目点は、Bがサインアウトするまで直らないことです。報告者は、Claudeを全セッションで閉じても、パッケージサービスのCoworkVMServiceを止めても結果は変わらなかったと書いています。つまり「Claudeのプロセスが動いているから」という説明では片づきません。

もう一つ、起動への副作用があります。内蔵アップデーターは失敗しても各セッションで再試行を続けます。その試行中は、スタートメニューからClaudeを起動できないことが断続的に起きるそうです。

ユーザー単位の更新が他人に左右される理由

サポート記事は、ClaudeのMSIXを「ユーザー単位のアプリ」として配っていると説明しています。Add-AppxPackageは実行したユーザーにだけ登録し、Add-AppxProvisionedPackageはマシン全体にステージングして、管理者権限のない標準ユーザーを含む全ユーザーが使えるようにします。

RDSホストでは、同じパッケージが複数ユーザーに登録された状態になります。報告された症状は、この登録がユーザーをまたいで更新を妨げているように見えます。ただし、0x80073D25の意味やWindows側の具体的な仕組みは、issueにもClaudeの公式記事にも書かれていません。ここは推測の域を出ないため、Microsoft側のエラー定義を自環境で確認する必要があります。

issueの末尾には、関連する別の報告として#49655が挙がっています。こちらは単一ユーザーで、CoworkVMServiceのファイルロックによって0x80073CF6が出るものです。報告者は「今回の阻害要因は、同じホストの他のサインイン中ユーザーから来る」と区別しています。単一ユーザー端末の0x80073CF6は、サポート記事では前回のインストール・更新が中途半端に終わった状態を指すエラーとして扱われています。

エラー出る条件解説元
0x80073D25出る条件他ユーザーがサインイン中のRDSホストでの更新解説元issue #104564(報告のみ)
0x80073CF6出る条件前回のインストール・更新が未完了で一部登録が残る解説元サポート記事
0x80073D28出る条件ユーザー単位のMSIXを管理者権限なしで入れた解説元サポート記事

0x80073D28との違いも押さえておくと切り分けが速くなります。D28は「管理者権限なしでユーザー単位に入れた」ことが原因で、サポート記事はマシン全体へのプロビジョニングで直すとしています。D25は管理者権限の有無ではなく、他ユーザーの存在が条件です。D28の直し方はMSIX一括導入の手順にまとめています(詳細はClaude Desktop MSIXをWindowsへ一括導入する手順)。

報告者が使っている回避策

サインアウトを求める運用は、バックグラウンドで長い計算を回すユーザーがいるターミナルサーバーでは取れません。報告者は次の2段で更新しているそうです。

  1. レジストリのポリシーで内蔵の自動更新を止める
  2. ローカル管理者の別アカウントから、新しいMSIXをAdd-AppxPackageで入れる

2段目のアカウントは、自分用のClaudeを入れていないものを使います。報告者によると、パッケージサービスが新しい版に切り替わり、Windowsが他のユーザーを必要に応じて再登録します。Claudeを閉じているユーザーは直ちに、使用中のユーザーは次のサインイン時に切り替わります。

自動更新を止める

管理設定の記事では、disableAutoUpdatesがBoolean(既定はfalse)の項目です。MDMでバージョンを管理するときに設定し、レジストリではマシン全体のHKLM:\SOFTWARE\Policies\Claudeに置くのが推奨の場所です。HKLMとHKCUの両方に値があれば、マシン側が優先されます。

New-Item -Path "HKLM:\SOFTWARE\Policies\Claude" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" `
  -Name "disableAutoUpdates" -Value 1 -Type DWord

これで内蔵アップデーターの再試行が止まり、起動が不安定になる症状も収まる見込みです。ただし、報告者がこの設定の前後で起動の不具合を比較したとは書かれていません。

管理者アカウントから更新する

次に、新しいMSIXを別の管理者アカウントで入れます。報告者はこれをS4U(パスワード不要のサービス用ログオン)のスケジュールタスクとして実行しています。次はその形を例示したもので、パスやアカウント名は環境に合わせて置き換えます。サポート記事の手順ではなく、issueの記述から組み立てた例です。

$action = New-ScheduledTaskAction -Execute "powershell.exe" `
  -Argument '-NoProfile -Command "Add-AppxPackage -Path C:\deploy\Claude.msix"'
$principal = New-ScheduledTaskPrincipal -UserId "CORP\claude-updater" `
  -LogonType S4U -RunLevel Highest
Register-ScheduledTask -TaskName "UpdateClaude" `
  -Action $action -Principal $principal
Start-ScheduledTask -TaskName "UpdateClaude"

更新後は、各ユーザーのセッションでGet-AppxPackage -Name Claudeを実行し、バージョンが揃ったか確かめられます。同じ記事も、MDM側の検出スクリプトで同じコマンドを使う前提です。

Add-AppxProvisionedPackageで更新できるか

サポート記事が案内するマシン全体の入れ方はAdd-AppxProvisionedPackageです。

Add-AppxProvisionedPackage -Online -PackagePath "Claude.msix" `
  -SkipLicense -Regions "all"

これはもともと「これから初めて使うユーザーに配る」ためのコマンドです。すでにユーザー単位で登録済みのRDSホストで、このコマンドが0x80073D25を避けて更新に使えるかどうかは、issueには書かれていません。サポート記事にもRDSやマルチユーザーのホストに関する記述はありません。自社の検証環境で試し、結果を見てから本番に当てるのが安全です。

issueの報告者は、こう質問しています。マルチユーザーのWindows Server / RDSで更新するサポートされた方法はあるのか、自分たちの回避策は想定された使い方ではないのか。この質問に答えるコメントは、まだ付いていません。

更新方針を決める前に見ておく点

同じサポート記事は、更新の持ち主を1つに決めるよう求めています。アプリの自動更新(約4時間ごとに確認)とMDMの両方がパッケージを登録すると、"The parameter is incorrect"のような重複登録の症状が出るためです。RDSでも同じ考え方が当てはまります。

  • 自動更新を止めて管理者が更新する場合は、disableAutoUpdatesを1にします。バージョン固定を重視する運用向けです。
  • アプリの自己更新に任せる場合は、disableAutoUpdatesを未設定にします。ただし今回の報告では、この構成で他ユーザーがいると更新が失敗しています。

issueのラベルはinvalidで、状態はopenです。不具合として受理されたのか、別の扱いになるのかは、issueからは見えません。版が変われば挙動も変わるので、更新手順を固める前にissueの状態を見直してください。報告されたバージョンは3.6556.2.0なので、手元のバージョンが違えば同じ症状になるかどうかも試す価値があります。

起動できないときの切り分け

更新が失敗し続けている間にスタートメニューから起動できなくなったら、先に自動更新を止めるのが近道です。それでも直らないとき、MSIXの登録状態の問題なら、次の記事の切り分けが使えます。

まとめ

報告されている0x80073D25は、RDSホストで他のユーザーがサインインしているあいだ、ユーザー単位の更新が通らない問題です。Claudeを閉じても、CoworkVMServiceを止めても解消しないと報告されています。Anthropicからの対応方針は、issue上に示されていません。

当面の運用としては、自動更新をdisableAutoUpdatesで止め、管理者アカウントから更新する形が報告されています。サポート記事のAdd-AppxProvisionedPackageが更新にも使えるかは未確認のため、検証用のホストで先に試すのが妥当です。

この記事を共有:XはてブLinkedIn

関連する記事

Claude をもっと見る →