注意

本記事は特定環境（Windows 11 + Docker Desktop EXE版）での対応記録です。 Docker Desktopのバージョンやインストール形態により挙動が異なる場合があります。

はじめに

Docker Desktopの自動アップデートが、適用のたびに失敗して同じ状態を繰り返す症状が発生しました。

この記事では、ログから原因を特定し、手動でアップデートを完了させ、再発防止を検討するまでの流れを記録します。

原因

原因は「自動アップデートの適用に管理者昇格が必要なのに、昇格を担う特権ヘルパーサービスが停止していた」ことでした。

環境

項目内容
OSWindows 11 Pro（26200）
対象Docker Desktop
更新前4.73.0（build 226246）
更新先4.73.1（build 226574）
インストール種別EXE版（ユーザー単位）
エンジン29.4.3（Linux containers）

更新先の4.73.1（build 226574）は2026-05-12にリリースされたバージョンです。

症状

Docker Desktop自体は起動して動作しているものの、自動アップデートが完了しません。

13分おきのバックグラウンド更新チェックで、更新版が「ダウンロード済み・インストール準備完了」になります。

しかし、その後のインストールが毎回失敗し、同じ状態に戻るループが続いていました。

原因調査

ログとオペレーティングシステムの状態を順に確認しました。

バージョンとプロセス・サービスの確認

まず現行バージョンと、関連プロセス・サービスの状態を確認します。

docker version
Get-Process | Where-Object { $_.ProcessName -like "*docker*" }
Get-Service | Where-Object { $_.Name -like "*docker*" }

ここで、特権ヘルパーサービスcom.docker.serviceが停止（StartType: Manual）であることがわかりました。

設定ファイルの確認

Docker Desktopの設定ファイルを確認します。

%APPDATA%\Docker\settings-store.json

UpdatePreviousVersionが更新前と同じ4.73.0のまま残っており、アップデートが先へ進んでいない状態が読み取れました。

AutoDownloadUpdatesはtrueで、バックグラウンドダウンロードは有効でした。

ログの解析

ログは次のディレクトリにあります。

%LOCALAPPDATA%\Docker\log\host\

electronログには、アップデート適用時のエラーが記録されていました。

Update installing - storing dashboard open state: true
POST /update/apply: Internal Server Error (HTTP 500: Internal Server Error)

バックエンドログ（com.docker.backend.exe.log）には、更新版が繰り返しダウンロードされ「ready to install」になる記録が、13分間隔で大量に並んでいました。

そして、決定的なエラーが見つかりました。

[updater][W] using fallback URL .../Docker Desktop Installer.exe
after getting an error: fork/exec
...\Docker Desktop Updater-226246 (226574).exe:
The requested operation requires elevation.
POST /update/apply: fork/exec
...\Docker Desktop Installer (226574).exe:
The requested operation requires elevation.

差分アップデーターも、フォールバックのフルインストーラーも、ともに管理者昇格が必要で起動できず、最終的にeventUpdateFailureで失敗していました。

判明した原因

原因は、次の組み合わせでした。

  • 自動アップデートの適用には管理者昇格（UAC）が必要
  • 昇格を肩代わりする特権ヘルパーサービスcom.docker.serviceが停止していた
  • 設定上AlwaysRunServiceが無効で、サービスを常駐させていなかった

EXE版（ユーザー単位インストール）のDocker Desktopは、特権サービスをオンデマンドで扱います。

そのため、バックグラウンドの自動適用ではUAC昇格ができず、毎回失敗してループしていました。

対応（手動アップデート）

フォールバック用のフルインストーラーは、すでにダウンロード済みでした。

%LOCALAPPDATA%\Temp\DockerDesktopUpdates\Docker Desktop Installer (226574).exe

破損していないかを、Docker公式のappcastに記載されたチェックサムと照合して検証します。

$f = "$env:LOCALAPPDATA\Temp\DockerDesktopUpdates\Docker Desktop Installer (226574).exe"
(Get-FileHash -Path $f -Algorithm SHA256).Hash

SHA256は公式の値と完全に一致し、サイズも647,738,800バイトで一致しました。

ダウンロード済みインストーラーは正常だったため、これを管理者権限で起動して手動でアップデートを適用します。

$installer = "$env:LOCALAPPDATA\Temp\DockerDesktopUpdates\Docker Desktop Installer (226574).exe"
Start-Process -FilePath $installer -Verb RunAs

UACダイアログを承認し、インストーラーの指示にしたがって更新を進めます。

更新中にDocker Desktopが自動で終了し、4.73.1をインストールして再起動しました。

確認

アップデート完了後、バージョンとコンテナーの状態を確認します。

docker version --format '{{.Server.Platform.Name}} {{.Server.Version}}'
docker ps --format "{{.Names}} | {{.Status}}"

Docker Desktop 4.73.1 (226574)へ更新されていました。

エンジン再起動でいったん停止していたコンテナー（GitHub Actionsのセルフホストランナー14個）も、再起動ポリシーにより25秒ほどで自動復帰しました。

自動起動設定の確認

Windowsサインイン時の自動起動が有効かどうかを、3つの観点で確認しました。

確認項目状態
settings-store.jsonのAutoStarttrue
レジストリHKCU\...\RunのDocker Desktopエントリ存在
スタートアップ有効状態（StartupApproved\Run）02＝有効

3つとも有効で、自動起動はオンのままでした。

StartupApproved\Runの値は先頭バイトで有効・無効を表します。

02は有効を意味し、無効化された履歴を示すタイムスタンプも記録されていませんでした。

再発防止の検討

同じ失敗を繰り返さないために、特権サービスを常駐させる方法を検討しました。

うまくいかなかった方法

OSレベルでサービスを自動起動に変更し、起動させました。

Set-Service -Name 'com.docker.service' -StartupType Automatic
Start-Service -Name 'com.docker.service'

一時的にはRunning・Automaticになりましたが、Docker Desktopを起動すると、サービスはManual・停止へ戻されました。

settings-store.jsonへAlwaysRunServiceを直接追記する方法も試しましたが、Docker Desktop側でキーが削除されました。

EXE版のDocker Desktopは特権サービスをオンデマンドで管理するため、OS設定や設定ファイルの直接編集は上書きされてしまいます。

公式の方法

Docker公式の方法は、管理者向けの設定ファイルadmin-settings.jsonを使うものです。

Windowsでは次のパスに配置します。

C:\ProgramData\DockerDesktop\admin-settings.json

内容は次のとおりです。

{
  "configurationFileVersion": 2,
  "alwaysRunService": {
    "locked": true,
    "value": true
  }
}

管理者権限のPowerShellで作成します。

$dir = 'C:\ProgramData\DockerDesktop'
if (-not (Test-Path $dir)) {
  New-Item -ItemType Directory -Path $dir -Force | Out-Null
}
@'
{
  "configurationFileVersion": 2,
  "alwaysRunService": {
    "locked": true,
    "value": true
  }
}
'@ | Set-Content -LiteralPath "$dir\admin-settings.json" -Encoding UTF8

ただし、この設定管理（Settings Management）はDocker Businessサブスクリプション向けの機能です。

無償ライセンスやPersonalライセンスでは無視される場合があるため、環境によって効果は変わります。

ファイル作成後はDocker Desktopを再起動し、com.docker.serviceがRunning・Automaticのまま維持されるかどうかで効果を判定できます。

実務上の運用

設定管理が効かない環境では、無理に常駐化を狙うより、更新通知から手動で適用する運用が確実です。

更新通知から「Install」を選ぶと、対話的なUACダイアログが表示され、承認すれば問題なく更新できます。

今回のループは「適用できない更新が滞留していた」ことが引き金でした。

最新版へ更新できた時点でループ自体は解消しているため、当面の実害は限定的です。

おわりに

Docker Desktopの自動アップデートが失敗するという症状から、ログを起点に「管理者昇格の不足」という原因へたどり着き、検証済みインストーラーーの手動実行で解消しました。

再発防止については、EXE版インストールとライセンス種別に依存する部分が大きく、環境によっては「更新通知からの手動適用」が現実的な運用になります。

エラーメッセージそのものよりも、ログのどこに記録されているかを把握しておくと、同種のトラブルを素早く切り分けられます。

参考サイト