Microsoft、Windows Updateをすべてのサードパーティ製アプリに開放し始める

 (theverge.com)
3 ポイント 投稿者 GN⁺ 2025-05-29 | 1件のコメント | WhatsAppで共有
  • Microsoftが、サードパーティ製アプリもWindows Updateで更新できるように開放する新プラットフォームをプレビュー公開
  • 新しいWindows Updateオーケストレーション・プラットフォームは、ドライバーや業務アプリを含むあらゆる更新を統合管理できるよう設計されている
  • ユーザーの活動状況、バッテリー状態、環境配慮型エネルギーのタイミングなどに応じて、更新スケジュールを最適化できる
  • Win32、MSIX、APPXアプリまで対応し、Windows Updateの履歴にもアプリ更新履歴が含まれる
  • 従来のMicrosoft StoreやWinget方式の限界を超え、業務向けのカスタムアプリも含められる可能性がある

Windows Update、すべてのアプリ更新のハブを目指す動き

  • Microsoftは最近、Windows UpdateをOSとドライバーの更新だけでなく、すべてのアプリの統合更新プラットフォームへ拡張する計画を発表した
  • この変化は特に、企業環境で社内アプリまで更新を統合管理したいという需要を反映したものとみられる

新しいオーケストレーション・プラットフォームの概要

  • Windows Update Orchestration Platformという名称で、現在プライベートプレビュー提供中
  • 既存のWindows Updateの機能を拡張し、アプリ更新もあわせてスケジュール調整とユーザー体験最適化の対象に含める

> 「私たちは、アプリやドライバーなど、どのような更新でもWindows Updateとともにオーケストレーションできる統合インテリジェント・プラットフォームを構築しています。」 — Microsoftプロダクトマネージャー Angie Chen

既存のアプリ更新方式の問題

  • 多くのWindowsアプリは、各開発元ごとに個別の更新システムを運用している
  • その結果、更新タイミングや品質に一貫性がない
  • Microsoft Store経由で一部アプリは統合更新できるが、多くのアプリはStoreに登録されていないか、企業向けの独自アプリである

主な機能と利点

  • ユーザーの活動状況、バッテリー状態、持続可能なエネルギー利用の時間帯に基づくスケジューリング機能
  • Windows Updateの標準通知および履歴UIに統合
  • MSIX / APPXアプリはもちろん、一部のWin32アプリまで対応
  • プラットフォームの今後の更新を自動的に継承
  • 既存インストーラーを置き換える可能性を提示（例: Adobeのように独自のバックグラウンドインストーラーを運用する大規模アプリも対象になり得る）

既存ソリューションとの比較

方式 説明 主な欠点
Microsoft Store アプリのインストールと更新をStoreで管理 登録アプリが限定的で、企業向けアプリへの適用が難しい
Windows Package Manager (winget) コマンドラインベースのパッケージインストール/更新ツール 主にパワーユーザーや開発者向けで、一般ユーザーには主流でない
Windows Updateオーケストレーション OS/ドライバー以外に一般アプリまで更新を統合可能 現在はプライベートプレビュー段階

今後の展望

  • まずは企業向けアプリ更新の統合需要が大きいと予想される
  • その後、Adobe、Zoom、その他の商用ソフトウェアへ拡大する可能性がある
  • 長期的には、macOSのようにシステム全体の更新を一元化する方向性を目指す

Microsoftは、分散したアプリ更新体験の統合をあらためて強化しようとしており、開発者と企業が協力して参加するかどうかが、このエコシステム転換の鍵になるとみられる。

関連記事

1件のコメント

 
GN⁺ 2025-05-29
Hacker Newsの意見
  • Windowsでは依然として、Chromeが権限昇格の問題を回避するために特別なサービスを使って更新を処理している状況があり、Spotifyなど多くのアプリも同じ理由でAppDataにインストールされる状態が続いていることが共有された。多くのプログラムのアンインストーラーは今でもきちんと動作せず、ファイルやその他の痕跡を残すことがある。MSIは「チェーン署名」という古い鍵で新しい鍵を署名し続けることを永続的に要求するが、10年以上という長期間にわたって更新を管理しなければならない場合、非常に難しく感じられる問題だ。いつかこの状況がすべてすっきり整理されてほしいという願い
    • Chromeが使っているインストール／更新プログラムはオープンソースの Omaha で、他の言及されたアプリは Squirrel を使っている。どちらも AppData に配置できるが、特に Squirrel はユーザーディレクトリにしかインストールされない。Squirrel の思想は、管理者権限なしでもユーザーインストールを可能にすること
    • AppData にインストールする理由は、権限昇格の回避を目的に隠そうとしているからではない。Microsoft がほぼ10年以上にわたり AppData へのインストール方式を推奨してきた結果であり、最近では権限昇格なしで動作可能なプログラムなら、AppData インストールが「正しい」方式だと考えている
    • コンテナ化されておらず、root/管理者アクセス権を持つアプリの場合、インストーラーの立場から残存ファイルを完全に処理するのはほぼ不可能な問題だと思う。こうしたアプリは任意のディレクトリにファイルを作成・書き込みでき、Microsoft やアプリ提供者が提供するアンインストーラーでさえすべてのファイルを見つけ出せない。プログラム全体の動作フローをそのまま再現しない限り、完全削除は難しいと考える
    • GNU/Linux 環境のパッケージでも、残存ファイルを残すことは多い
  • UniGetUI を知ることができた。WinGet や Scoop などさまざまなパッケージマネージャーをうまく呼び出してくれ、無視リストなどのカスタマイズ機能も提供している。Windows ではそのレベルのカスタマイズ機能はあまり期待できないと思う
  • なぜ Windows に macOS のような統合されたインストール・更新・削除フレームワークが最初から存在しなかったのか、ずっと疑問に思っている。明らかに未解決の大きな欠落だと思う。現在でも企業顧客はアプリケーションを管理するために個別に自前でパッケージ化しなければならない。初期から Microsoft が DLL 共有を奨励し、後方互換性を提供する必要があったため、.MSI や高度なソフトウェア管理フレームワークの導入を強制しなかったのが原因ではないかと推測している
    • macOS も最初からそのような統合フレームワークを提供していたわけではない。多くのアプリはドラッグ＆ドロップで Applications フォルダに入れるだけという簡便さがある一方、かなりの数のアプリはインストーラーを実行する必要があり、システム全体にサポートファイルをインストールするため管理者認証を求めることも多い。アプリごとに独自のアップデーターが起動時に自動実行されることもあり、昔は拡張機能やコントロールパネル要素が System Folder にインストールされ、再起動が必要だった記憶がある。そしてこうしたアプリの多くには独自のアンインストール機能もなく、設定ファイルやキャッシュファイルなどもユーザーが自分で探して削除しないと問題なく再インストールできなかった
    • Microsoft の最初の有名な OS だった MS-DOS の影響で、初期の Windows はサードパーティーソフトウェアのインストールという観点では実質的に DOS のように動作していた。別個のインストール概念はなく、ベンダー提供の INSTALL.COM / INSTALL.EXE を実行する方式で、主にルートディレクトリに新しいフォルダを作ってファイルをコピーしていた。場合によってはユーザーが自分でフォルダを作って手動コピーしていた。すべてのアプリデータ処理が特定のディレクトリ（例: C:\Program Files）に集中する構造で、UNIX のように /bin、/etc、/var に分離されていなかった。MS-DOS は IO.SYS、MS-DOS.SYS、CONFIG.SYS、AUTOEXEC.BAT 以外の各種ファイルの配置場所にまったく頓着しない構造だった。Windows 3.x が大衆的に普及した時期にもこの DOS スタイルの作業方式がそのまま続き、「統合インストールシステム」の導入はかなり遅れた。.MSI もかなり後期に導入されたため、既存プログラムに適用されなかったという歴史的背景の説明
    • macOS に移行したとき、典型的なインストール体験が Windows よりはるかに良いことに本当に驚いた。ダウンロードしたファイルをただフォルダにコピーするだけでインストール完了という手軽さが印象的だった。別途インストーラーが必要な場合でも、ほとんど常にシステム提供の見慣れたフローなので気軽に感じられる
    • ドライバー、システム拡張、ライブラリのバージョン管理などの複雑な問題が、統合されたインストール／アンインストールシステムを作ることを難しくしている。インターネット接続すら保証できないなら、さらに厄介だ。こうした機能を作ったとしても、ソフトウェアベンダーに利用を促さなければならず、経営陣がそれを新たな利益手段と見なしてしまわないかという懸念もある
    • 主要なソフトウェアベンダーは、GPO 展開向けの msi パッケージを一般に提供していることが多い。ここ10年で自分でパッケージ化しなければならなかったことはほとんど記憶にない。インストールパラメータの調整程度の簡単な作業だけで済む場合が大半だ。ただし、改善の余地は今でも十分に残っていると感じる
  • Windows 10 で、すべての更新を無効化したまま1年以上まったく問題なく使っている。Microsoft は「アップデート」という言葉そのものをネガティブなものにしてしまった気がするし、Nadella がなぜここまで Windows に愛着を見せないのか理解できない
    • セキュリティ面を心配して更新しないと大変なことになるユーザーもいるだろうが、ほとんどの家庭用 PC は NAT 環境にあるため、リモート脆弱性（例: EternalBlue）の悪用も難しく、トロイの木馬に感染しない限り大きな問題はない。ブラウザーさえ最新なら実質的に安全だと思う。例外的にトロイの木馬に感染した場合でも、管理者権限なしで文書の暗号化やボットネット参加が可能なので、Windows Update だけであらゆる脅威を防げるわけではないという意見
  • Windows Update の方式は、すべての Linux パッケージマネージャーが使う方法と非常によく似ていると思う。ただし Chocolatey、Scoop、WinGet など他の代替手段と比べると、Windows Update はあまりにも単純すぎて機能不足に感じられる
    • WinGet の存在を知るのがあまりにも遅かったことが恥ずかしく感じられる。Ubuntu など Linux 環境で過ごした後、Windows 用パッケージマネージャーを検索していてようやく知った
    • Windows Update は速度が非常に遅く感じられる。更新コンポーネント数やデータ量が10倍に増えたら、本当に想像もしたくないと思う
  • 開発者／上級ユーザーではなく、Winget / コマンドラインでアプリ更新するのが難しい一般ユーザーなら、オープンソースアプリの UniGetUI を強く勧める。UI は直感的で、よく管理されており、とても快適に動作する
    • UniGetUI プロジェクトを初めて知ったが、本当に洗練された印象だ。良い情報共有に感謝
  • このスレッドのおかげで UniGetUI というとても素晴らしいツールを知ることができた。今後、自分のすべての Windows デバイスに必ずインストールする予定だ。このアプリの主な目標は、WinGet、Scoop、Chocolatey、Pip、Npm、.NET Tool、PowerShell Gallery など、さまざまな Windows パッケージマネージャー向けの直感的な GUI を提供すること。対応するパッケージマネージャーで、必要なソフトウェアを簡単にインストール／更新／削除できる魅力的なアプリだ。リンク 参照（16.2k stars を記録）
  • この変更は、7zip の更新にも20分かかり、再起動まで要求されるような事態を招きそうだという疑念
    • 必ずしもそうなるとは思わない。Windows Update には強制再起動を要求しない更新も多く、7zip もそれと変わらない形で設定できると思う
  • 他の投稿者たちと同じく、今回の変化はすでにかなり手遅れだと感じる。理由は単に誰が先にやったかではなく、個人的には Win32 API とデスクトップアプリの時代は少なくとも10年前に終わっていたと見ているからだ。今やデスクトップにインストールされたアプリは少数派で、大多数のユーザーはモバイルアプリとウェブブラウザーにより依存している。個人的にインストールするものもほとんどがユーティリティで、これは Microsoft のビジネスモデルにも合っていない。結局のところ、対象ユーザーはいったい誰なのかという疑問
  • この方針は、Windows Update サービスに問題が起きた場合に巨大な単一障害点を生むのではないかという懸念。関連検索トレンド からも分かるように、Windows Update は長年にわたり不安定さの実績がある
    • 単一の更新手段になるならその懸念は現実的だが、実際には Windows Update を唯一の経路として動かす計画ではないため、「シングルポイント」の懸念はそれほど大きくないと思う