# Windowsアプリの更新が失敗したとき、再試行の前に段階を見る

アプリに更新があるのに、「更新」を押しても終わらないように見えます。ダウンロード中か、管理者の承認待ちか、インストール中か、インストール済みバージョンの確認中かを見ます。判断を待っているインストーラーは、何度クリックしても進みません。

## 遅いダウンロードと、失敗したインストールを分ける

Moleの更新の行は段階を示します。ダウンロードは、合計サイズがあるときは割合を、ないときはダウンロード済みの量を示します。数字が変わるなら進んでいます。ダウンロード中は取り消せます。管理者の確認を含むインストール段階に入ると、もう取り消せないので、インストーラーが途中で強制終了されることはありません。

| 止まる場所 | 最初の確認 |
| --- | --- |
| ダウンロードが進まない、またはサーバーエラー | ダウンロード先、接続、ベンダーのサービス。エラー全文を残す |
| 管理者アクセスを求めている | タスクバーとWindowsの承認の確認 |
| 別のウィンドウを開いたままインストール中 | インストーラーがアプリの終了、確認、再起動を待っているか |
| 終わったのにバージョンが変わらない | アプリのバージョン情報、インストールの範囲、開き直しが必要か |

拒否されたダウンロードは、インストーラーが一度も動かなかったことを意味し得ます。インストーラーが壊れたことや、動いている版を先にアンインストールする必要を示すものではありません。

## エラーはインストーラー自身の文脈で読む

Windows Installerの結果は、失敗の種類によって対処が違う理由を示します。

| MSIコード | 意味 | 次の手順 |
| --- | --- | --- |
| 1603 | 一般的なインストール失敗 | `%TEMP%`のMSIログ(`MSI*.log`)を読むか、`msiexec /l*v`で再実行する。コードだけでは原因は特定できない |
| 1618 | 別のインストールが実行中 | そのインストールが終わってから、次を始める |
| 3010 | 成功。完了には再起動が必要 | 作業を保存し、再起動の要求に従い、バージョンを確認する |

これらの意味はMicrosoftの[Windows Installerのコード表](https://learn.microsoft.com/en-us/windows/win32/msi/error-codes)からのものです。MSIの結果に当てはまり、すべてのベンダーのEXEインストーラーに当てはまるわけではありません。特に3010は、失敗したダウンロードを再インストールする必要があるという意味ではありません。

## インストールを繰り返さずにログを探す

次のPowerShellの問い合わせは、アプリの更新を始めずに、WinGetのバージョン、環境、ログディレクトリを示します。

```powershell
winget --info
```

失敗した時刻のログを見つけ、アプリ名、パッケージID、タイムスタンプを照合します。ダウンロードの応答、インストーラーの終了、そのあとのバージョン確認を分けます。ログにはユーザー名とローカルパスが入り得ます。アーカイブ全体を公開せず、サポートへ共有する前に出したくない詳細を外します。

試した時刻、元のアプリのバージョン、完全なコード、承認や再起動の要求を一緒に残します。そうしないと、昨日の無関係なインストールの失敗が、今日の問題の原因に見え得ます。[WinGetのトラブルシューティングのドキュメント](https://learn.microsoft.com/en-us/windows/package-manager/winget/troubleshooting)は、強制的な再インストールを要求せずに、このログの探し方を説明しています。

<figure class="blog-diagram">
  <picture>
    <source media="(max-width: 900px)" srcset="/img/blog/windows-windows-app-update-failures-en-mobile.webp" type="image/webp" width="768" height="1500">
    <img src="/img/blog/windows-windows-app-update-failures-en.webp" width="1360" height="454" loading="lazy" alt="更新には別々の段階がある">
  </picture>
  <figcaption>影響を受けた段階を特定します。承認は条件付きで、バージョンの確認はインストールと、必要な再起動のあとに続きます。</figcaption>
</figure>

## 一部の更新は、先に古い版を外す

Java 8などのインストーラーは、古い版の削除を要求することがあります。マシン全体へのインストールは管理者アクセスが必要なことがあり、通常ユーザーの更新は完了しないことがあります。Moleはサポートされた更新の場合を扱い、必要なときは承認を求めます。すべての失敗が権限の問題とは限りません。

インストーラーの終了コードと挙動は違います。Microsoftの[WinGetのトラブルシューティング案内](https://learn.microsoft.com/en-us/windows/package-manager/winget/troubleshooting)は、ログとエラーの調査を説明しています。サポートには、「失敗」という語だけより、コードと段階の方が役立ちます。

## 新しいバージョンが実際に使われているか確認する

アプリにはユーザー単位とマシン全体のインストールがあり得て、表示されるバージョンがパッケージ登録と違うこともあります。このインストールのバージョン情報を開き、インストーラーが終わったことを確認し、求められた再起動を完了します。更新一覧を空にするためだけにインストールを繰り返すのは、信頼できる修正ではありません。

Moleは、バージョンが変わらなかった結果を確認できるように残します。自分で更新するアプリは自分の経路を残します。[更新のガイド](/ja/windows/blog/update-windows-apps)がその項目を説明しています。開いたまま更新するブラウザーは、次の再起動のあと新しい版を使うのが普通です。

## フィードバックにはバージョンと正確なエラーを入れる

Windows、Mole、影響を受けたアプリのバージョンを記録します。ダウンロード、承認、インストールがどこまで進んだかを書き、エラーとスクリーンショットを[Windowsヘルプ](/ja/windows/help)のサポート経路で送ります。ログは、共有したくないものを先に外します。

Mole自身の更新、ほかのアプリの更新、Windows Updateは別の待ち行列です。システムの更新エラーは、アプリの失敗1件をシステム全体のリセットの理由にせず、Windowsの記録から調べます。更新の経路そのものは[Windowsでどの更新の入り口を使うか](/ja/windows/blog/update-windows-apps)、更新ファイルとそれが失うロールバックは[Windows Updateのファイルを削除する](/ja/windows/blog/delete-windows-update-files)を見てください。


Canonical: https://mole.fit/ja/windows/blog/windows-app-update-failures