Claude Desktopが0x80073CF9でインストールできない原因とpriconfig.xml

Claude Desktop Windows版のインストーラーが AddPackage failed with HRESULT 0x80073CF9 で止まるとき、配布されるMSIXパッケージの中身が引き金になっている可能性があります。GitHubのissue #92345では、パッケージのルートに紛れ込んだ priconfig.xml を取り除くだけでインストールが通ったと報告されています。

0x80073CF9自体は包括的なエラーで、これだけでは原因を絞れません。このページでは、イベントログで本当のエラーを確かめる方法と、priconfig.xml が原因かを見分ける手順、報告された回避策とその代償を順に示します。

0x80073CF9の下に隠れている0x80070490を確認する

インストーラーには2つのダイアログが出ます。報告者が示した文面は次のとおりです。

Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
Administrator access is required to install Claude with full features.
You can try again or install without Cowork.

2つ目の「管理者権限が必要」は、実態とずれています。報告者のインストーラーログでは Is elevated: true と出ており、昇格済みの状態で1秒かからずに同じ失敗をしていました。管理者として実行し直しても結果は変わりません。

報告者の説明では、0x80073CF9は ERROR_INSTALL_FAILED にあたる一般的なラッパーです。中身は Microsoft-Windows-AppXDeploymentServer/Operational というイベントログに残ります。

Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" `
  -MaxEvents 100 |
  Where-Object { $_.Id -in 401, 404, 605, 613 } |
  Format-List TimeCreated, Id, Message

上のコマンドは、報告者が確認したイベントIDを絞って見るための一例です。報告者の環境で並んでいたのは次の4件でした。

注目するのは 0x80070490 です。ERROR_NOT_FOUND、つまり「要素が見つからない」にあたります。Process Monitorで確認しても、このタイミングでファイルやレジストリの操作は失敗していませんでした。ディスク上のファイルが欠けているのではなく、デプロイ処理の内部で何かを探して見つけられなかった、という形です。

ログに605や613が並んでいれば、このページの話に該当します。そうでなければ、別の原因を疑うことになります。

priconfig.xmlがインストールを壊す仕組み

報告者がたどり着いた原因は、パッケージのルートにある priconfig.xml です。サイズは1,480バイトでした。

Microsoftの MakePri.exe のドキュメントでは、priconfig.xml はPRIファイル(アプリのリソースの索引)を作るときに渡す構成ファイルとして登場します。createconfig コマンドで生成し、new コマンドの /cf オプションで読ませる流れです。つまり、本来はビルド時の入力にあたります。

問題のファイルには、次の宣言が入っていました。

<packaging>
  <autoResourcePackage qualifier="Language"/>
  <autoResourcePackage qualifier="Scale"/>
  <autoResourcePackage qualifier="DXFeatureLevel"/>
</packaging>

報告者の読み解きでは、autoResourcePackage は「リソースが別のリソースパッケージに分かれている」とWindowsに伝える宣言です。デプロイのリソース索引の段階で、Windowsはそのパッケージを探しに行きます。Claude DesktopはバンドルではなくMSIX単体で配布されているため、探し先が存在せず、「要素が見つからない」が返る、という説明です。

これは報告者が差分の切り分けで突き止めた結果で、Microsoft側が確認した仕様ではない点に注意が必要です。ただし根拠は厚く、次の節で触れる制御実験が付いています。

ファイルが入っているかをMSIXの中で確かめる

MSIXの実体はZIPです。MSIXファイルを手元に取得できているなら、priconfig.xml が入っているかを展開せずに確かめられます。

Add-Type -AssemblyName System.IO.Compression.FileSystem
$zip = [IO.Compression.ZipFile]::OpenRead("C:\Temp\Claude.msix")
$zip.Entries |
  Where-Object { $_.FullName -eq "priconfig.xml" } |
  Select-Object FullName, Length
$zip.Dispose()

1行出力され、Length が1480なら、報告者が見たものと同じファイルです。ただし、ファイルが入っていることと、あなたの端末の失敗の原因であることは別の話です。判断の決め手はイベントログの0x80070490で、パッケージ内のファイルは補強材料と考えるのが妥当です。

報告者の環境では、確認した2つのビルド(1.46388.4.0と1.10628.2.0)のどちらにも同じファイルが入っていて、6月以降のどのバージョンでも失敗していました。その後のコメントでは、2.9939.2.0にも priconfig.xml が残っていると追記されています。

原因はこの1ファイルだと言える根拠

この報告が評価されているのは、一つずつ変数を変えた実験表が付いているからです。報告者は公式のMSIXを makeappx で組み直し、自己署名で署名してインストールを試しました。

マニフェストだけ、コンテンツだけでは再現しなかったため、報告者はファイル群を二分探索する自動スクリプトを書きました。3,058個の候補から、11ステップで priconfig.xml に行き着いています。

再署名したパッケージが失敗する点も重要です。Anthropicの署名証明書が原因ではないことを示しています。

原因だと誤認されやすい対処

この症状は過去にも2回報告され、どちらも invalid として閉じられています。報告者たちはどちらも、StateRepository-Machine.srd に残った Claude_pzs8sxrjxfjjc の孤立した PackageFamily 行を原因と見ていました。

issue #92345の報告者は、この診断を実験で否定しています。次のコマンドで登録を消すと、イベント400で削除は成功しましたが、直後のインストールは同じ 0x80070490 で失敗しました。孤立した行は、失敗したインストールの副産物であって原因ではない、という結論です。

Remove-AppxPackage -Package Claude_1.46388.4.0_x64__pzs8sxrjxfjjc -AllUsers

報告者が個別の実験で除外した要因は、ほかにも次のとおりです。

• 欠けた依存関係(VCLibs、WindowsAppRuntime、UI.Xamlはすべて存在)
• 権限と昇格
• Anthropicのコード署名証明書(チェーンは有効)
• 残留した CoworkVMService
• AppXボリュームの状態、SisPath、KnownFolderの記述子、カタログデータベース
• 新規作成したWindowsユーザーアカウント(失敗は端末単位で、プロファイル単位ではない)

つまり、アプリの再インストール、Windowsの修復、ユーザーの作り直しで直らなかった端末が、この件の典型的な姿です。起動後に出る別の症状との見分けは、後の表にまとめます。

報告された回避策と、その代償

報告者が実際に通した回避策は、MSIXから priconfig.xml を除いて組み直す方法です。issue本文の手順を、フォルダー名だけ置き換えて示します。

1. ダウンロードしたMSIXをZIPとして展開する
2. priconfig.xml を削除する
3. 同時に AppxSignature.p7x、AppxBlockMap.xml、[Content_Types].xml も削除する(makeappx が再生成する)
4. AppxManifest.xml とそのほかのファイルには触れない
5. makeappx で組み直し、署名してから Add-AppxPackage で入れる

makeappx pack /d C:\Temp\claude_unpacked /p claude_fixed.msix /o /nv
Add-AppxPackage -Path claude_fixed.msix

署名は「信頼される証明書なら何でもよい」とされています。2台目で再現したコメントでは、マニフェストの Publisher と完全に一致するサブジェクトを持つ自己署名証明書を使っていました。この方法で、627MBのパッケージ全体が入り、CoworkVMService も自動起動の状態で動いたと報告されています。

同じコメントに、見落としやすい注意が1つあります。SDKによっては makeappx.exe が先にarm64版に解決されることがあり、x64のフォルダーを明示して呼ぶ必要がある、という点です。

この方法には、無視できない代償があります。

• 組み直したパッケージは自分の署名になるため、Anthropicの署名ではなくなる
• 自動更新は失敗し、更新が通ったとしても同じファイルが戻ってくる
• 配布元が直さない限り、バージョンが上がるたびに作業が繰り返しになる

個人の端末で試す回避策としては成り立ちます。ただし、組織で配布しているMSIXを書き換えて運用に載せるのは別の話で、署名や更新の経路が変わることを前提に、管理者側で判断する事項です。企業向けの配布方法そのものはClaude DesktopをWindowsで一括導入する手順で扱っています。

英語環境なら起きない、という仮説は否定された

最初の報告者のWindowsはスペイン語(es-ES)でした。パッケージの既定の修飾子が Language=en-US であることから、「英語環境なら既定値で探索が満たされ、影響が出ないのではないか」という仮説が書かれていました。報告者自身が「未検証の推測」と断っています。

この仮説は、2台目の報告で否定されています。表示言語が英語(en-US)の端末でも同じ1,480バイトのファイル、同じ3つの autoResourcePackage で、失敗は同一でした。リソースパッケージの探索はシステム言語に関係なく行われる、というのが2台目の結論です。

その端末はAtlasOSの派生環境でしたが、標準のWindowsでも同じ症状が出て、同じファイルを除くと両方で直っています。過去の2件が閉じられた根拠である「AtlasOS固有の問題」という見立ても、これで弱まりました。

では、なぜ一部の端末だけで起きるのか。この点は、issueの時点で解明されていません。言語でも、カスタム環境でもないとすれば、条件は未特定のままです。報告が少ないのは、同じ症状でも「Windowsの修復で直らない不具合」として個別に処理され、原因の特定まで進まなかった可能性もあります。これは筆者の推測にすぎません。

似たエラーコードとの見分け方

Claude Desktop Windows版には、16進のエラーコードが付く不具合がほかにもあります。症状が出る段階で見分けられます。

インストールそのものが通らないなら、このページの話です。入ったあとで起動に失敗するなら、0x80070020で起動しない場合やCoworkVMServiceで起動しない場合を参照してください。

修正の見通し

報告者の提案は、パッケージング工程から priconfig.xml を除外することです。makepri の入力ファイルであり、実行時の資産ではないからです。ほかにも不要なビルド成果物がルートに残っていないか、同時に点検する価値があると添えています。

issueのラベルには bug、has repro、platform:windows、area:installation などが付いています。9月25日の追記時点で2.9939.2.0にも同じファイルが入っていたため、新しいバージョンが出ても、このファイルが取り除かれたかはパッケージの中身で確かめるまで分かりません。先ほどの確認コマンドが、そのまま判定に使えます。

標準の入手経路でいつ直るかは、公式の発表待ちです。それまでは、イベントログで0x80070490を確かめ、回避策の代償を理解した上で組み直すか、修正版を待つかを選ぶことになります。

インストール後の初期設定やVM機能の準備は、Claude Desktop Windows版のインストールと初期設定にまとめています。