winget upgrade で23件の更新待ちを棚卸しした話
winget upgrade --include-unknown は2026-07-19の手元で23件の更新待ちを出した。
数の多さよりも、バージョンの飛び方のほうが目についた。Azure Developer CLI は 1.23.1400 から 1.29.100 へ、GitHub CLI は 2.83.2 から 2.97.0 へ上がる状態になっている。実際に数字を並べると、更新を後回しにしていた期間がそのまま見える（アプリ一覧というより、放置の履歴に近い）。
これは ARM64 Windows だから特別に起きた話ではない。ただ、Surface Pro 11th Edition のような ARM64 機では、ネイティブ版、x64 版、Store 配布、MSIX が同じ一覧に混ざる。そこを winget の表だけで眺めると、更新管理というより棚卸しに近くなる。
短い確認のつもりだったが、出てきた一覧は思ったより運用メモ向きだった（ただの更新表というより、放置していた場所の棚卸しになった）。
棚卸しに使ったコマンド
実行したのは winget upgrade --include-unknown と winget list、それから winget source list である。マシンは Surface Pro 11th Edition、Snapdragon X 12-core X1E80100 @ 3.40GHz、メモリ 32GB、Windows 11 Pro 10.0.26200 ARM64 版。電源は AC 接続のまま、電源プランは既定の「バランス」にしていた。
winget upgrade --include-unknown
winget list
winget source list
upgrade の実行時間は 4.98秒、list は 10.72秒、sources は 0.49秒だった。ここでは速度を比べたいわけではなく、更新待ちの内訳とソースの状態を残す目的で取っている。実際に見た sources には msstore、winget、winget-font の3件が登録されていた。更新待ちの表で使われていたソースは winget と msstore の2種類だった。
この環境では winget-font も残っている。明示的フラグは true。このソースが直接今回の23件を増やしたわけではないが、source list まで残しておくと後で見返しやすい（あとからソース差分を疑うときの足場になる）。
更新待ちとして出てきた一覧
upgrade.stdout に出ていた更新待ちは23件だった。パッケージ名、ID、現在のバージョン、利用可能なバージョンはこの表のとおり。
| 名前 | ID | 現在 | 利用可能 | ソース |
|---|---|---|---|---|
| Azure Developer CLI | Microsoft.Azd | 1.23.1400 | 1.29.100 | winget |
| Azure Functions Core Tools | Microsoft.Azure.FunctionsCoreTools | 4.6.0 | 4.12.1 | winget |
| Bonjour | Apple.Bonjour | 3.0.0.10 | 3.1.0.1 | winget |
| Claude | Anthropic.Claude | 1.5354.0.0 | 1.24012.9 | winget |
| CMake | Kitware.CMake | 4.3.3 | 4.4.1 | winget |
| Copilot CLI | GitHub.Copilot | v1.0.47 | v1.0.77 | winget |
| Eclipse Temurin JDK with Hotspot 8u492-b09 (x64) | EclipseAdoptium.Temurin.8.JDK | 8.0.492.9 | 8.0.502.7 | winget |
| GitHub CLI | GitHub.cli | 2.83.2 | 2.97.0 | winget |
| Linux 用 Windows サブシステム | Microsoft.WSL | 2.7.3.0 | 2.7.11 | winget |
| Microsoft Azure CLI (64-bit) | Microsoft.AzureCLI | 2.80.0 | 2.88.0 | winget |
| Microsoft Azure Quick Review | Microsoft.Azure.QuickReview | 3.1.2 | 4.0.0 | winget |
| Microsoft Build of OpenJDK 21.0.11+10 (arm64) | Microsoft.OpenJDK.21 | 21.0.11.10 | 21.0.12.8 | winget |
| Microsoft GameInput | Microsoft.GameInput | 3.3.221.0 | 3.4.218 | winget |
| Microsoft Scout 0.23.331 | Microsoft.ScoutAgent | 0.23.331 | 0.23.578 | winget |
| Microsoft Visual C++ 2022 Redistributable (Arm64) - 14.51.36231 | Microsoft.VCRedist.2015+.arm64 | 14.51.36231.0 | 14.51.36247.0 | winget |
| Microsoft Visual C++ v14 Redistributable (x64) - 14.50.35719 | Microsoft.VCRedist.2015+.x64 | 14.50.35719.0 | 14.51.36247.0 | winget |
| Microsoft Visual C++ v14 Redistributable (x86) - 14.50.35719 | Microsoft.VCRedist.2015+.x86 | 14.50.35719.0 | 14.51.36247.0 | winget |
| Node.js | OpenJS.NodeJS.LTS | 24.13.0 | 24.18.1 | winget |
| Pandoc 3.9 | JohnMacFarlane.Pandoc | 3.9 | 3.10 | winget |
| PowerToys (Preview) ARM64 | XP89DCGQ3K6VLD | 0.96.1 | 0.100.2 | msstore |
| Python Launcher | Python.Launcher | 3.12.10 | 3.13.5 | winget |
| Roblox Player for akirasakai | Roblox.Roblox | Unknown | 0.726 | winget |
| spacedesk Windows DRIVER | Datronicsoft.SpacedeskDriver.Server | 2.2.14.0 | 2.2.28.0 | winget |
Azure Developer CLI の 1.23.1400 から 1.29.100 は、見た瞬間に引っかかった。Microsoft Azure CLI も 2.80.0 から 2.88.0、Azure Functions Core Tools も 4.6.0 から 4.12.1 まで開いている。Azure まわりの道具を同じ時期に入れて、その後まとめて放置していた感じが数字に残っていた（この固まり方は、普段使う道具ほど後回しにしがちな自分の癖にも見える）。
Roblox Player の Unknown も気になる。--include-unknown を付けたから表に出た項目で、現在バージョンが読めないまま 0.726 が提示されている。これは更新対象として扱えるかもしれないが、差分の大きさは比較できない。こういう行を同じ表に入れると、23件という数だけでは状態を読み切れない（Unknown は件数には入るが、古さの比較には向かない）。
小さく見える差も、並べると意味が出てくる。
Microsoft Visual C++ 2022 Redistributable (Arm64) は 14.51.36231.0 から 14.51.36247.0 なので、飛び幅だけなら大きくない。けれど x64 と x86 の Redistributable は 14.50.35719.0 から 14.51.36247.0 へ上がる。ARM64 機の上でも Arm64、x64、x86 のランタイムが一緒に残っているのが、この表だけで分かる。
MSIX の一覧は ARM64 と neutral が混ざる
list.stdout には MSIX 形式のパッケージが多く並んでいた。名前の中に _arm64__8wekyb3d8bbwe が付くものがあり、たとえば WindowsWorkload.PSOnnxRuntime.1_0.3.245.0_arm64__8wekyb3d8bbwe や Microsoft.RawImageExtension_2.5.24.0_arm64__8wekyb3d8bbwe が見える。ARM64 ネイティブのアプリやランタイムがこの形で表に出ることを確認できた。
同じ一覧には _neutral__8wekyb3d8bbwe もあった。Microsoft.PowerToys.SparseApp_0.96.1.0_neutral__8wekyb3d8bbwe、Microsoft.Winget.Source_2026.803.1208.47_neutral__8wekyb3d8bbwe、Microsoft.LanguageExperiencePackja-JP_26100.174.273.0_neutral__8wekyb3d8bbwe がその例だ。ARM64 機の中でも、アーキテクチャ固定のパッケージと neutral のパッケージが同居している。
このあたりは、更新表だけを見ていたら気づきにくいところ。
winget upgrade の更新表だけを見ると、PowerToys (Preview) ARM64 のように分かりやすい名前だけが目に入る。winget list まで見ると、WindowsWorkload、WinML、PSTokenizer、Speech Pack のような MSIX 側の細かい部品が大量に現れる。ARM64 版 Windows は、アプリ本体だけでなく、こうした補助パッケージも含めて成り立っているのだと実感した。
先頭を切ってしまった
失敗したのは winget list の保存方法だった。なぜここで詰まったのか、後から見るとかなり単純な話になる。
JSON の list.stdout は rRenameContextMenu_0.96.1.0_neutral__8wekyb3d8bbwe から始まっている。これは表の先頭ではない。PowerToys の PowerRenameContextMenu の途中から切り出されたような文字列で、ヘッダー行も前半のパッケージも失われていた。
原因は分かっている。標準出力を末尾 20000文字で切って保存する実装にしていたため、長い winget list の前半を自分で捨てた。パイプで受けた出力を安易に切り詰めると、後から全件集計ができなくなる。エラーとして落ちないので、気づくまで少し詰まった。
これは設計ミスだったので、次からは標準出力を変数に抱えて削るのではなく、いったんファイルへリダイレクトしてから読む。winget list > winget-list.txt のように生の出力を残しておけば、後で必要な範囲だけを切り出せる。JSON に埋める場合も、全文ファイルへのパスを持たせたほうが安全だ。
今回の upgrade.stdout は短かったので、23件の表は作れた。list.stdout は途中からなので、全インストール済みアプリの件数や ARM64 と x64 の比率は出さない。そこまで書くと数字の根拠が崩れてしまうので、今回は更新待ちの棚卸しに絞った。
更新を溜めない運用にする
個人的には、winget upgrade は「今すぐ全部上げるためのコマンド」よりも、まず棚卸しとして使うほうがいい。Azure Developer CLI、Azure CLI、Functions Core Tools、OpenJDK、Node.js、Python Launcher が同じ日に更新待ちになると、どれを先に上げるか考えざるを得ない。全部まとめて更新して壊れたら、原因の切り分けが面倒だ。
実際に表へ起こしてみると、放置の長さが見えた。Azure Developer CLI の 1.23.1400 から 1.29.100、GitHub CLI の 2.83.2 から 2.97.0、Copilot CLI の v1.0.47 から v1.0.77 は、日常的に使う道具ほど後で効きそうだった。バージョンの飛び幅が大きいほど、設定ファイル、認証、拡張機能、PATH のどこで変化が出たのか追いにくくなる。
次回からは winget upgrade --include-unknown の結果を日付つきで残し、開発系ツールとランタイム系を分けて更新する。Microsoft Visual C++ Redistributable や GameInput はアプリ側の依存で入っていることもあるので、CLI 類と同じ勢いで触らないほうがよさそうだ。
2026年7月19日に見直しても、いちばん大きな反省はコマンドではなくログの取り方にあった。更新を溜めると壊れたときの原因切り分けが難しくなる。ログを切ると、さらに調査の足場まで失ってしまう、という反省まで残った。