タグ: update

Windows 11 25H2 の新機能と改善点 ― 管理者向け強化とレガシー機能削除に注目

2025年8月29日、Microsoft は Windows Insider Program の Release Preview チャネルにて、Windows 11 バージョン 25H2（ビルド 26200.5074） を公開しました。このリリースは、年次機能アップデートに相当するものであり、最終的には年内に一般提供（GA: General Availability）が予定されています。

今回の 25H2 は従来の大型アップデートと異なり、有効化パッケージ（enablement package / eKB） を通じて提供される点が特徴です。これにより、すでに稼働中の 24H2 と同じサービスブランチを基盤として、システムを大きく入れ替えることなく新機能や変更点を追加することが可能となります。そのため、適用時間の短縮や安定性の確保が期待され、企業利用における導入のハードルを下げる狙いも含まれています。

さらに、今回のプレビュー版は新しい機能を体験する機会であると同時に、管理者や開発者が既存の環境との互換性を確認するための重要な段階でもあります。特に IT 管理者にとっては、プリインストールアプリの削除制御といった管理性向上が注目点となり、今後の本番環境への展開計画に大きく関わることになります。

Release Preview チャネルに展開されたことで、25H2 は「正式リリース直前の完成度を持つバージョン」と位置づけられ、これを通じてユーザーや企業は早期に導入テストを行い、フィードバックを提供することが可能になります。Microsoft の年次アップデート戦略の一環として、25H2 がどのように Windows 11 の進化を加速させるのかが注目されます。

更新形式の概要

Windows 11 バージョン 25H2 の提供形式は、従来の「大型アップデート」方式ではなく、有効化パッケージ（enablement package / eKB） を採用しています。これは、すでに提供されている Windows 11 バージョン 24H2 と同じサービスブランチを共有し、その基盤上で新機能や改良を「有効化」する仕組みです。言い換えれば、25H2 自体は 24H2 と大きく異なる OS ビルドではなく、既存の機能を土台としつつ軽量に機能追加を行う「差分的アップデート」となります。

この方式の最大のメリットは、更新の適用時間が短く済むことです。従来のようにシステム全体を再インストールするのではなく、既存のバージョンに対して特定の機能をオンにすることでアップデートが完了します。そのため、個人ユーザーにとっては短時間で最新バージョンへ移行でき、企業にとっても業務影響を最小限に抑えつつアップデート展開を進められる利点があります。

さらに、eKB の仕組みにより 24H2 と 25H2 は共通のサービス更新を受け取れる という特徴もあります。これにより、セキュリティ修正や安定性改善が 24H2 と同様に配信され続けるため、バージョンを切り替えても更新サイクルが途切れることはありません。管理者にとっては、複数のバージョンを並行管理する必要性が薄れるため、運用負担の軽減にもつながります。

また、この形式は Microsoft が Windows 10 時代から導入してきた「年次アップデートの軽量化戦略」の延長線上にあり、Windows 11 においても OS の進化と安定性を両立させる手段として定着しつつあります。大規模な機能刷新よりも、小規模で安定した進化を優先することで、エンタープライズ環境や教育機関での導入をより容易にする狙いが明確です。

主な新機能・変更点・バグフィックス

1. レガシー機能の削除と管理者向け機能強化

  • PowerShell 2.0 と WMIC（Windows Management Instrumentation コマンドライン）の削除。モダンな管理ツールへの移行が強制されます。
  • Enterprise / Education エディションでは、グループポリシーまたは MDM（CSP）を利用して、プリインストール済みの Microsoft Store アプリを選択的に削除可能となりました。

2. バグ修正と安定性向上

最新の Insider Preview Build では、以下のような具体的な修正が含まれています：

  • 複数モニター環境で、日付や時刻をクリックした際に、誤って主モニター上にフライアウトが表示される問題を修正。
  • アプリを最小化し、仮想デスクトップ間を移動した際に、タスクバーでプレビューサムネイルが重複して表示される問題を修正。
  • Alt + Tab 使用時の explorer.exe のクラッシュを一部 Insider で修正。
  • 「設定 > システム > ディスプレイ」内の HDR 有効化設定がオフになる問題を修正。
  • TV にキャストしたあと、数秒後にオーディオが再生されなくなる問題を修正。
  • 特定のスマートカードドライバーで表示される「エラー 31」を修正。
  • diskusage /? コマンドのヘルプ表示のタイプミスを修正。
  • Quick Settings 経由で PIN を求める際に Enter キーが機能しない問題を修正。
  • タスクマネージャーの「メモリ不足時に中断」設定のツールチップ表示内容を修正。

3. 新機能・ユーザーエクスペリエンスの改善（Insider Preview 経由）

25H2 そのものには大きな新機能が少ないものの、Insider Preview を通じて導入された以下の改善が含まれている可能性があります：

  • タスクバーアイコンのスケーリング機能（見やすさ向上）。
  • クイック・マシン・リカバリー（Quick Machine Recovery：QMR）機能。トラブル時に診断ログをもとに自動復旧を行う。
  • Voice Access にカスタム辞書の単語登録機能を追加。
  • Narrator に「スクリーンカーテン」機能を追加。
  • プライバシー関連のダイアログのデザイン刷新。
  • Quick Settings 内におけるアクセシビリティのテキスト説明表示。
  • エネルギーセーバーの適応型モード（Adaptive Energy Saver）。
  • 共有ウィンドウ（Windows share window）にビジュアルプレビュー機能追加。
  • ダークモードの改善。ファイル操作ダイアログがシステムのダークテーマに正しく追従するようになりました。  
  • パフォーマンス関連改善に向けて、フィードバック Hub 経由で自動パフォーマンスログ収集機能の導入。

配布と導入手順

Windows 11 バージョン 25H2 は、まず Windows Insider Program の Release Preview チャネルを対象に配布が開始されています。Insider Program に参加しているユーザーは、「設定 > Windows Update」から “更新プログラムのチェック” を手動で実行することで、25H2 の更新案内を受け取ることができます。いわゆる “seeker” モードであり、利用者が自ら適用を選択しない限り、自動的に配布されることはありません。そのため、正式公開前に試験的に導入したいユーザーや企業の検証環境での利用に適した配布形態となっています。

適用後は、これまでのバージョンと同様に 月例の累積更新プログラム（セキュリティアップデートや品質改善） が継続的に提供されます。これは 24H2 と 25H2 が同じサービスブランチを共有しているためであり、バージョンをまたいでも統一的な更新サイクルが維持される仕組みです。特に企業環境においては、バージョンごとに異なる更新を管理する負担が軽減される点が利点といえます。

さらに、Microsoft は Azure Marketplace を通じた配布も予定しており、クラウド上の仮想マシンやテスト環境に容易に展開できるようになります。これにより、大規模環境でのテストや教育機関における一括導入がより柔軟になります。

また、Microsoft は公式に ISO イメージの提供を来週に予定していると発表しており、クリーンインストールや大規模展開を検討している管理者にとって重要な選択肢となります。これにより、従来の Windows インストールメディアを用いたセットアップや、評価用仮想環境の構築も容易に行えるようになります。

このように、25H2 は Insider 向けの段階的な提供から始まり、クラウド配布や ISO 形式による展開まで複数の導入方法が整備されており、個人ユーザーから企業・教育機関まで幅広い利用者が環境に応じた方法で試験・導入できるよう設計されています。

今後の展望

Windows 11 バージョン 25H2 は現在 Release Preview チャネルに到達しており、次のステップとして年内の一般提供（GA: General Availability）が予定されています。具体的な公開日程はまだ公式に発表されていませんが、例年の傾向から秋から冬にかけて段階的に配信が始まる可能性が高いと見られます。年次アップデートという性格上、家庭用 PC ユーザーにとってはもちろん、企業や教育機関にとっても導入のタイミングを見極める重要な節目となります。

一方で、今回のリリースでは新機能そのものよりも 既存の不具合がどこまで修正されるか に注目が集まっています。特に話題となっているのが、一部環境で報告されている SSD が認識されなくなる「SSD消失問題」 です。更新適用後にシステムが SSD を検出できなくなるケースがあり、ストレージそのものが消えたように見える重大な事象として注目されています。また、NDI（Network Device Interface）を利用する環境での不安定性も報告されており、映像制作や配信分野での影響が懸念されています。これらの問題が一般提供開始までに解決されるかどうかは、多くのユーザーや管理者にとって重要な判断材料となります。

さらに、正式リリース後に 新たな不具合が発生していないか も大きな関心事です。25H2 は有効化パッケージ方式により比較的軽量なアップデートであるものの、内部的には数多くのコード変更や統合が行われているため、予期せぬ副作用が発生する可能性があります。過去の大型アップデート直後にも、一部周辺機器のドライバー不具合やアプリケーションとの互換性問題が発覚した例があり、今回も初期段階のフィードバックが安定性確認の鍵となるでしょう。

総じて、25H2 の一般提供は Windows 11 の進化を一段階押し上げるものと位置づけられますが、利用者の最大の関心は「新機能の追加」以上に「SSD消失問題やNDI不具合といった既知の問題が修正されているか」「新たなトラブルが発生していないか」にあります。Microsoft が正式リリースまでにこれら懸念点をどこまで解消できるかが、25H2 の評価を左右する大きな分岐点になるといえるでしょう。

おわりに

Windows 11 バージョン 25H2 は、年内に予定されている一般提供に先立ち、Release Preview チャネルを通じて幅広いユーザーが体験できる段階に入りました。今回のアップデートは、有効化パッケージ方式による効率的な配布や、レガシー機能の整理、管理者向けの柔軟なアプリ削除制御といった改良が特徴的です。大規模な機能刷新こそ控えめですが、日常的な操作の安定性や企業利用の利便性を高める取り組みが着実に進んでいます。

同時に、SSD消失問題やNDI環境での不具合といった懸念点が、正式公開までに解決されるかどうかは依然として注目を集めています。一般提供後に新たな不具合が発生しないかどうかも含め、今後数か月は慎重な観察が必要です。

総じて、25H2 は「大きな変化」よりも「着実な進化」を重視したアップデートといえます。利用者や管理者は新機能の活用に加え、安定性や互換性の検証にも注力しながら、正式リリースに備えることが求められるでしょう。Windows 11 が成熟したプラットフォームとして次の段階へ進むうえで、この 25H2 が重要な節目になることは間違いありません。

参考文献

「KB5064081」プレビュー版の内容まとめ ― Windows 11 24H2向け最新累積更新（2025年8月29日公開）

2025年8月29日、Microsoftは Windows 11 バージョン 24H2 向けに「KB5064081（OSビルド 26100.5074）」を公開しました。本更新は、いわゆる「プレビュー累積更新」と呼ばれるもので、セキュリティ修正を含まない任意インストール型の更新プログラムです。毎月定例の「Bリリース」（セキュリティ更新を含む公式累積更新）に先立ち、次回以降に反映される改善点や新機能を先行して利用できるのが特徴です。

今回の KB5064081 には、ユーザー体験や利便性を高める数多くの変更が含まれており、タスクマネージャーのCPU使用率表示方式の統一、ロック画面やウィジェットボードの改善、ファイルエクスプローラーや検索機能の刷新、Windows Hello の認証体験向上、さらには Copilot+ PC に関する設定強化など、幅広い領域での進化が見られます。また、システム管理の観点からは、企業向け Windows バックアップの一般提供や PowerShell 2.0 の削除といった、将来の運用を見据えた大きな変化も含まれています。

この記事では、Microsoft の公式サポートページおよび技術系メディアの情報を基に、KB5064081 の変更内容を網羅的に整理します。

主な新機能と改善点

1. タスクマネージャーのCPU使用率表示の統一

  • Processes タブのCPU使用率が他のタブと一致する計算方式に変更。
  • 計算式は「(Δ CPU Time) ÷ (Δ Elapsed Time × ロジカルプロセッサ数)」に統一。
  • 従来の Processor Utility を確認したい場合は、Details タブに「CPU Utility」列を追加可能。

2. Recall 機能の拡張

  • 個人化されたホームページが導入され、Recent Snapshots や Top Apps and Websites を表示。
  • 左側ナビゲーションバーでホーム・タイムライン・フィードバックなどにアクセス可能。

3. Click to Do のチュートリアル追加

  • 初回起動時に対話的チュートリアルを提供。
  • テキスト要約や背景除去などの利用例を提示し、操作を学習可能。

4. プライバシー許可ダイアログの再設計

  • カメラやマイクのアクセス要求時に画面が暗転するなど、より目立つ表示へ変更。

5. 通知センターの大きな時計（秒表示対応）

  • タスクバー通知センターに秒まで表示できる大型時計を追加。
  • 「設定 > 時刻と言語 > 日付と時刻」で有効化可能。

6. タスクバー検索の改善

  • 検索結果がグリッド形式に対応。
  • 画像検索の利便性が向上。

7. ロック画面のウィジェット強化

  • ウィジェットの追加・削除・並べ替えが可能に。
  • 天気、スポーツ、交通情報などを柔軟にカスタマイズ。

8. ファイルエクスプローラーの改善

  • コンテキストメニューに仕切り線を追加。
  • Entra ID（旧Azure AD）でサインイン時、Activity 列や Recommended セクションに人物アイコンが表示。
  • Microsoft 365 Live Persona Card に対応し、組織内の人物情報を確認可能。

9. Windows Hello の刷新

  • パスキーやサインイン手順のUIを刷新。
  • 顔認証が失敗した場合に改善オプションを提示。
  • スタンバイ復帰後の指紋認証が安定。

10. 設定アプリの改善

  • アクティベーションや有効期限通知が Windows 11 デザインに統一。
  • 「プライバシーとセキュリティ > テキストと画像生成」でAI利用アプリのアクセス制御が可能に。
  • Copilot+ PC向けエージェントが AMD/Intel デバイスの英語環境でも利用可能に。

11. ウィジェットボードの拡張

  • 複数ダッシュボードをサポート。
  • 左ナビゲーションバーが追加され、Discover フィードも刷新。
  • Copilot によるストーリーやメディアプレビュー表示。

12. 組織向け Windows バックアップの一般提供開始

  • デバイス移行や AI PC 展開に対応したバックアップと復元の仕組みを企業向けに提供。

13. PowerShell 2.0 の削除

  • Windows 11 24H2 から PowerShell 2.0 は完全削除。
  • 今後は PowerShell 5.1 および PowerShell 7 系列を利用する必要あり。

インストール方法と注意点

KB5064081 は プレビュー累積更新 であり、通常のセキュリティ更新とは異なり、自動的にすべての端末に配信されるものではありません。適用方法にはいくつかの選択肢があり、利用環境に応じて導入可否を判断することが推奨されます。

まず、最も一般的なのは Windows Update を通じた適用です。更新プログラムは「オプションの更新」として表示され、「ダウンロードとインストール」を選択した場合にのみ導入されます。既定では自動的にインストールされないため、安定性を重視するユーザーはスキップすることも可能です。ただし、システム設定で「最新の更新プログラムをすぐに入手する」を有効化している場合、プレビュー更新が自動的に適用されることがあります。

次に、管理者や検証目的で利用する場合は、Microsoft Update カタログ から直接ダウンロードして適用する方法も用意されています。x64 および ARM64 向けのパッケージが提供されており、企業環境では WSUS や Intune を通じて配布することも可能です。

一方で、プレビュー更新にはセキュリティ修正が含まれていないため、導入にあたってはいくつかの注意が必要です。まず、未検証の環境で業務システムに直接適用することは推奨されず、テスト環境での事前検証が望ましいとされています。また、プレビュー更新を避けたい場合は「更新の一時停止」設定を利用することで、自動的な適用を防ぐことができます。なお、今回の改善内容は翌月の定例更新に統合されるため、プレビューを導入しなくても最終的にはすべてのユーザーに反映されます。

このように、KB5064081 の適用はあくまで任意であり、新機能をいち早く試したいユーザーや検証担当者には有益ですが、安定稼働を優先する環境では導入を見送る判断も合理的です。

おわりに

KB5064081 は、2025年8月29日に公開された Windows 11 バージョン 24H2 向けのプレビュー累積更新であり、セキュリティ修正を含まない任意インストール型の更新プログラムです。本更新は、通常の月例更新の前に改善内容を先行適用する位置づけであり、安定版への反映を待たずに新機能を試せる点に大きな特徴があります。

内容を整理すると、ユーザー体験の向上に直結する変更（タスクマネージャーのCPU使用率計算の統一やロック画面・ウィジェットの刷新）、生産性を高める改善（検索機能の強化やファイルエクスプローラーでの組織連携機能）、そしてセキュリティや認証体験の強化（Windows Hello の改良、プライバシー許可ダイアログの見直し）が幅広く含まれています。また、企業利用を見据えた「組織向け Windows バックアップ」の一般提供や、古い PowerShell 2.0 の削除といった管理者向けの重要な変更も注目に値します。

一方で、プレビュー版はあくまで正式リリース前の段階であり、環境によっては互換性や安定性に影響が出る可能性も否定できません。そのため、個人ユーザーが新機能を体験するには魅力的ですが、業務環境では慎重に判断し、検証環境でのテストを経てから導入することが推奨されます。最終的には次回の定例累積更新で同内容が広く配布されるため、必ずしも今すぐ適用する必要はありません。

総じて KB5064081 は、Windows 11 の今後の方向性を垣間見ることができる更新であり、日常的な使い勝手の改善から企業システムの運用に関わる基盤強化まで、多岐にわたる進化を確認できる内容となっています。今後の正式リリースに向けて、利用者は自身のニーズに応じて導入可否を判断することが重要です。

参考文献

「SSD障害は存在しない」― Windows 11 24H2「KB5063878」を巡る障害報告について、MicrosoftとPhisonが因果関係を否定

はじめに

2025年8月に配信された Windows 11 24H2 の累積更新プログラム「KB5063878」は、セキュリティ強化を目的とした通常の更新のひとつに過ぎないはずでした。しかし、配信直後から一部ユーザーの間で「アップデートを適用したらSSDが突然認識されなくなった」「大容量データをコピーした瞬間にドライブが消えた」といった深刻な声が相次ぎ、SNSや技術系フォーラムを通じて急速に広まりました。

特に注目されたのは、報告の条件がある程度一致していた点です。数十GBを超えるファイル転送や50GB以上のデータコピーといった負荷の大きい処理を実行した際、さらにSSDの使用率が6割を超える状況で現象が発生したとされ、単なる偶発的なトラブルではなく「特定の条件下で再現する不具合ではないか」という見方が強まりました。実際、Reddit上では特定のSSDブランドやモデルに言及する投稿も散見され、ユーザーの間で「アップデートによってSSDが物理的に破壊されているのではないか」という強い懸念が共有されました。

このような経緯から、問題は単なる「小規模な互換性不具合」の域を超え、世界中で数百万人が利用するWindows 11の信頼性そのものに疑問を投げかける騒動に発展しました。バックアップを取らずにアップデートを適用していたユーザーにとっては、データ消失リスクへの恐怖が現実味を帯び、コミュニティ全体で「更新をすぐに止めるべきか」「今後のパッチを待つべきか」という議論が巻き起こりました。

しかし、この問題は時間の経過とともに大きく様相を変えていきます。MicrosoftやSSDコントローラメーカーのPhisonが本格的な調査を進めた結果、ユーザーの間で広まった「アップデートがSSDを破壊している」という説は公式には否定され、問題は再現されないものとして処理されました。つまり、当初ユーザーが抱いた強い不安と、ベンダー側が示した結論との間に大きな溝が生まれたのです。

本記事では、この騒動の発端から公式調査の結果までを整理し、最終的に「この問題が解消されることは期待できない」という結論に至った経緯を明らかにします。

Microsoftの見解

ユーザーの間で「KB5063878 適用後にSSDが認識されなくなる」との声が急速に拡散すると、Microsoftはただちに社内調査を開始しました。同社はこれまでも更新プログラムに関しては配信直後からユーザーフィードバックをモニタリングしており、今回も同様のプロセスを経て影響を精査したとしています。その結果を受けて、Microsoftは公式に次のように発表しました。

“After thorough investigation, Microsoft has found no connection between the August 2025 Windows security update and the types of hard drive failures reported on social media.”

（「入念な調査の結果、2025年8月のWindowsセキュリティ更新と、ソーシャルメディアで報告されているようなハードドライブ障害との間に関連性は認められなかった」）

つまり、SNSやフォーラムで語られた「アップデートによってSSDが破壊される」という懸念は、Microsoftの公式調査においては裏付けが得られなかったということです。同社は、社内で実施されたテスト環境においても、ユーザーが報告するような「ドライブ消失」や「認識不能」現象を再現することができなかったと明言しています。

さらにMicrosoftは、調査結果の結論として以下のように補足しています。

“As always, we continue to monitor feedback after the release of every Windows update, and will investigate any future reports.”

（「常にそうしているように、各Windows更新リリース後はユーザーのフィードバックを監視し、今後の報告についても引き続き調査を行う」）

このコメントからは、Microsoftが「今回のSSD障害は既知の不具合としては扱わない」という立場を明確にしつつも、ユーザーからの新たな報告に対しては門戸を閉ざさない姿勢を示していることがわかります。すなわち、現段階で修正パッチや既知の問題リスト入りはなく、「再現不能＝公式には不具合とは認められない」という結論に至ったのです。

このような立場表明は、多くのユーザーが体験したとする現象とは大きく食い違っています。ユーザー側から見れば「確かにアップデート後にSSDが消えた」という実体験があるにもかかわらず、Microsoftは「証拠も再現性もないため、原因はWindows更新とは無関係」と結論づけた形です。結果として、ユーザーの声と公式の見解の間に大きな乖離が生まれ、今回の騒動は「問題は存在しないものとして扱われる」方向で収束してしまいました。

Phisonの見解

Windows 11 24H2 更新プログラム「KB5063878」適用後にSSDが認識されなくなるというユーザー報告が拡大したのを受けて、SSDコントローラ大手のPhisonも迅速に調査を実施しました。以下に、同社の公式発表から再現性に関する声明と結論部分を引用しつつ、詳しく整理します。

調査内容および再現性

Phisonは、報道やユーザー報告で指摘された「影響を受けた可能性のあるドライブ」に対し、徹底した社内テストを展開しました。

“Phison dedicated over 4,500 cumulative testing hours to the drives reported as potentially impacted and conducted more than 2,200 test cycles. We were unable to reproduce the reported issue, and no partners or customers have reported that the issue affected their drives at this time.” 

（「Phisonは影響を受けた可能性があると報告されたドライブに対し、累計4,500時間以上、2,200回を超えるテストを行った。しかし報告された問題を再現することはできず、現時点でパートナーや顧客から当該現象が発生したとの報告も受けていない」）

この声明は、以下の点を明確に示しています：

  • 4,500時間以上に及ぶテストと2,200回以上のテストサイクルを実施したが、問題は再現されなかった
  • パートナーや顧客からも正式な障害報告は上がっていない

虚偽情報の拡散への対応

一部では「Phisonコントローラが影響を受けている」とする偽文書が出回っていたことも明らかにされました。Phisonはこれを否定し、正確な情報提供に努めています：

“Phison remains committed to the highest standards of reliability and continues to closely monitor the situation in collaboration with our industry partners.” 

（「Phisonは最高水準の信頼性を維持することに引き続き注力し、業界パートナーと協力しながらこの状況を注意深く監視している」）

結論および追加アドバイス

Phisonは「自社のコントローラが原因ではない」という調査結果を正式に表明しつつ、重いデータ処理が行われる際の「安全策」として次のような助言も提供しています：

“While our validation testing has not identified any concerns related to these Windows 11 updates, we have shared industry best practices to support high‑performance storage devices. We continue to advise users that for extended workloads, such as transferring large files or decompressing large archives, make sure a proper heatsink or thermal pad is used with the storage device. This helps maintain optimal operating temperatures, reduces the likelihood of thermal throttling, and ensures sustained performance.” 

（「我々の検証テストでは今回のWindows 11更新に関連する懸念は確認されなかったが、高性能ストレージを適切に運用するための業界ベストプラクティスを共有している。大容量ファイルの転送や巨大アーカイブの解凍など長時間の負荷がかかる作業では、適切なヒートシンクやサーマルパッドを用いてストレージデバイスを冷却することを推奨する。これにより適正な温度を維持し、サーマルスロットリングの可能性を減らし、持続的な性能を確保できる」）

この助言はSSDの性能維持と障害回避のための「予防的措置」であり、今回のSSD消失問題への直接的な修正策ではありません。しかし、ハードウェア管理上は有益である点も明示しています。

利用者との認識の乖離

今回の騒動で最も顕著になったのは、ユーザーが体験として語る現象と、MicrosoftやPhisonが公式に示した調査結果との間に存在する大きなギャップです。

RedditやMicrosoft Q&Aフォーラムには「WD Black NVMeが突然死んだ」「更新直後に500GBのSATA SSDが認識されなくなった」といった報告が相次ぎました。これらは単なる「動作が遅くなった」程度の軽微な不具合ではなく、利用者の目には「ストレージの致命的な障害」と映る内容でした。特に、更新直後に異常が発生した場合、利用者は自然に「アップデートこそが直接の原因だ」と考えやすく、コミュニティ全体で疑念と不安が増幅されていきました。

一方で、MicrosoftとPhisonは何千時間もの検証を行った上で「再現できなかった」「アップデートやコントローラに原因はない」と結論づけました。公式の立場から見れば、「証拠も再現性もない事象は不具合とは認められない」というのは一貫した姿勢です。製品やサービスをグローバル規模で提供する企業にとって、再現できない現象を「既知の不具合」として扱うことは難しく、サポートポリシー上も合理的な判断だと言えます。

しかし、この合理性こそがユーザーの実感と衝突します。

「確かに自分のSSDはアップデート後に消えた」という個別体験は、たとえ統計的に稀少であっても本人にとっては絶対的な事実です。にもかかわらず、ベンダー側から「問題は存在しない」と宣告されることは、利用者にとっては自らの経験が切り捨てられたように感じられます。結果として「現象はあるのに、公式は認めない」という構図が生まれ、認識の乖離はますます拡大しました。

この乖離の背景には、テクノロジー利用における「体感」と「統計的証明」の違いがあります。ユーザーは自らの端末で発生した一度きりの障害を「明確な証拠」と捉えますが、ベンダーは再現性・統計的有意性・検証可能性がなければ「存在しない」と判断します。そのギャップが今回のSSD騒動で如実に表れ、結果として「解消されることのない疑念」だけが残された形です。

まとめ

今回の「Windows 11 24H2 KB5063878とSSD障害報告」を巡る騒動は、アップデート適用直後に一部ユーザーから「SSDが認識されなくなった」「大容量コピーでドライブが消失した」といった深刻な声が広がったことから始まりました。ソーシャルメディアやフォーラムを中心に体験談が共有され、「アップデートがSSDを物理的に破壊しているのではないか」という疑念が強まったのです。

一方で、Microsoftは「社内テストやテレメトリで再現できない」と明言し、**「アップデートと障害の因果関係は確認されなかった」と結論づけました。Phisonも4,500時間以上の検証と2,200回を超えるテストサイクルを行った上で、「報告された現象を再現できなかった」「顧客やパートナーからの障害報告も存在しない」**と公式に発表しています。両者の見解は一致しており、SNSや一部ユーザーの報告は「公式には不具合とは認められない」と位置づけられました。

ここに生じたのが「利用者の体感」と「公式見解」の大きな乖離です。利用者は「自分のSSDが消えた」という経験を事実として語り、恐怖や不信を強めました。しかしベンダー側は「再現できない現象はサポートできない」と合理的な判断を示しました。その結果、公式対応として修正パッチが提供されることもなく、既知の問題として記録されることもありませんでした。

つまり、今回の騒動は 「アップデートがSSDを破壊する」という不安が利用者の間で残り続ける一方、ベンダー公式には存在しない不具合として処理される という形で終結しました。

この構図は、IT業界における典型的な「再現性の壁」を浮き彫りにしています。どれほど多くのユーザーが同じような症状を訴えても、メーカーが検証環境で現象を再現できない限り、正式に「バグ」と認定されることはありません。そして今回のケースでは、MicrosoftとPhisonの双方が明確に「因果関係なし」と結論づけたことで、今後この事象が修正や改善によって「解消される」可能性はほぼ絶望的となりました。

ユーザーの不安や不信は残るものの、公式見解としては「問題は存在しない」とされたまま収束していく──それが、このアップデートとSSD障害報告を巡る一連の騒動の帰結です。

参考文献

Windows 11 セキュリティ更新「KB5063878」「KB5062660」で報告された SSD 不具合 ― Microsoft と Phison は再現できず

2025年8月に配信された Windows 11 の月例セキュリティ更新プログラム（KB5063878、KB5062660）を適用した一部のユーザーから、SSD が突然認識されなくなる、あるいはドライブが消失するという深刻な不具合が報告されました。特に大容量ファイルを扱う作業や高負荷のワークロードで発生しやすいとされ、ユーザーの間で大きな不安を呼んでいます。

今回の問題が注目を集めたのは、単なる一部環境の不具合報告にとどまらず、テスト結果や動画を含む具体的な検証報告がインターネット上に拡散されたためです。中には、SSD が再起不能になりデータが失われたケースも報告されており、利用者にとっては単なる「一時的な不具合」では済まない深刻さを帯びています。

この件に関しては、SSD コントローラを手掛ける Phison 社の製品で発生しやすいという指摘もありましたが、Microsoft および Phison 双方が大規模な検証を行った結果、現時点では不具合を再現できていないと発表しています。それでもユーザー報告が散発的に続いているため、事象の発生条件や影響範囲は依然として不透明なままです。

本記事では、これまでの経緯と公式発表を整理するとともに、現時点で取り得る対応策、さらに今後の大型アップデート（25H2）適用時に懸念される二次的なリスクについても解説します。

不具合の報告

今回の不具合は、Windows 11 の 2025 年 8 月配信セキュリティ更新（KB5063878、KB5062660）を適用した後、一部のユーザー環境で SSD が突然認識されなくなったり、ドライブ自体が OS から消えてしまうという現象として報告されました。特に 大容量ファイル（50GB 以上）を転送する際や、ドライブ容量の 6 割以上を使用している状況で発生する可能性が高いとされ、利用環境によっては再起動後もドライブが戻らず、データが失われたというケースもありました。

海外のフォーラムやテストユーザーからは、詳細な検証報告が相次ぎました。あるテストでは 21 台の SSD を対象に負荷テストを実施したところ、そのうち 12 台で一時的にドライブが認識されなくなる現象が確認され、さらに Western Digital SA510 2TB モデルでは再起不能となる深刻な障害が発生したと報告されています。こうした事例は、単発的なハードウェア故障ではなく、更新プログラムとの関連性が疑われる根拠となりました。

特に注目されたのは、Phison 製 NAND コントローラを搭載した SSD で不具合が発生しやすいとされた点です。これにより、Phison のコントローラに依存する幅広い SSD 製品に潜在的な影響が及ぶ可能性が指摘され、利用者や業界関係者の間で警戒が高まりました。

一方で、報告事例の中には SSD や HDD の消失が「一時的」であり、再起動後に正常に認識されたケースも含まれていました。このため、事象がすべてハードウェアの物理的故障につながるわけではなく、ソフトウェア的な要因や特定条件下での挙動が関与している可能性も排除できません。

こうした状況から、当初は「セキュリティ更新による SSD の文鎮化」というセンセーショナルな見出しが拡散しましたが、その後の調査で再現性が確認できないことが判明しつつあり、依然として 発生条件や影響範囲が明確でない状態が続いています。

Microsoft と Phison の対応

不具合報告が広がった後、Microsoft は状況を把握し、調査を開始したことを公表しました。ただし同社の社内検証では、ユーザーが報告したような SSD の消失や破損は確認できていないと説明しています。これは、問題が非常に特定の条件下でのみ発生するか、あるいは別要因が絡んでいる可能性を示しています。Microsoft は引き続きユーザーからの情報収集を続けており、現時点では「既知の問題」として公式ドキュメントに掲載する段階には至っていません。

一方、SSD コントローラ大手の Phison も即座に独自の調査を行い、徹底的な再現テストを実施しました。その規模は累計 4,500 時間以上、2,200 回を超えるテストサイクルに及び、負荷の大きいワークロードや大容量ファイル転送など、ユーザーから報告のあった条件を中心に重点的に検証が行われました。しかし、最終的に いずれのテストでも不具合を再現できなかったと結論づけられています。

Phison は加えて、インターネット上で拡散した「内部文書」が偽造である可能性を指摘し、風評被害を避けるために法的措置を検討していると発表しました。この文書は「Phison が不具合を認識しつつ隠蔽している」と受け取られる内容を含んでいましたが、同社はこれを強く否定し、公式に調査結果を公開することで透明性を確保しようとしています。

さらに Phison はユーザー向けの推奨事項として、高負荷時にはヒートシンクやサーマルパッドを用いた冷却対策を行うことを挙げました。これにより SSD の安定性を高め、今回の問題が仮に環境依存の熱要因と関係していた場合の予防策になる可能性があります。

総じて、Microsoft と Phison の両社は「現時点では再現できない」という立場を共有しており、ユーザー報告とのギャップが存在する状態です。両社とも引き続き調査を継続するとしているものの、再現不能である以上、原因特定や恒久的な修正には時間を要する見通しです。

現時点での対処方法

現状、Microsoft と Phison の双方が数千時間規模のテストを行ったにもかかわらず再現に至っていないため、根本的な原因は特定されていません。そのため、ユーザー側が取れる確実な対応は非常に限られています。

まず考えられるのは、問題が発生した場合に該当する更新プログラム（KB5063878、KB5062660）をアンインストールすることです。これは Windows Update の「更新履歴」から削除操作を行うことで対応可能です。ただし、この方法はシステムを既知の脆弱性にさらすことになり、セキュリティリスクが増大するという副作用があります。そのため、無条件にアンインストールするのではなく、実際に不具合が発生している環境に限定して適用するのが現実的です。

また、アンインストール後は Windows Update が自動的に再適用を試みる可能性があるため、更新プログラムの一時停止やグループポリシーによる制御を併用することが推奨されます。特に企業環境や検証中のシステムでは、問題が未解決のまま再適用されることで業務に支障が出るリスクがあるため、運用レベルでの制御が重要となります。

不具合が発生していない環境については、むやみにパッチを削除するのではなく、データバックアップを確実に取ることが最も有効な予防策となります。システムイメージや重要データのバックアップを定期的に取得しておけば、万一の障害発生時でも復旧の可能性を高めることができます。特に SSD が完全に認識されなくなるケースが報告されているため、データ保護の観点では通常以上にバックアップの重要性が増しています。

さらに、Phison が推奨しているように、SSD の冷却対策を強化することもリスク低減につながります。ヒートシンクやサーマルパッドを導入し、長時間の大容量処理時に温度が過度に上昇しないようにしておくことは、環境依存的な発生要因を排除する助けとなります。

まとめると、現時点での有効な対処は以下の通りです。

  1. 不具合が実際に発生した場合のみ当該パッチをアンインストールする。
  2. アンインストール後は自動再適用を防ぐために更新を一時停止する。
  3. 定期的なデータバックアップを徹底し、万一の障害に備える。
  4. SSD の温度管理を強化し、冷却対策を講じる。

今後の懸念 ― 二次災害リスク

今回の不具合については、Microsoft と Phison がともに「再現できない」と結論づけているため、公式に修正プログラムが提供される見通しは現時点では立っていません。しかし、Windows Update の仕組みを考慮すると、問題が完全に解消されないまま将来の累積更新や機能更新に統合される可能性が高く、ユーザーはその影響を受けざるを得ない状況に直面する恐れがあります。特に 2025 年秋に提供が予定されている Windows 11 25H2 では、今回の KB5063878 および KB5062660 が含まれることが想定されるため、以下のような「二次災害」的リスクが懸念されます。

1. 個別アンインストールが不可能になるリスク

累積型アップデートや機能更新に統合された場合、特定の更新プログラムだけを切り離して削除することはできません。つまり、25H2 に含まれる形で提供された場合には、ユーザーが選択的に当該パッチを外すことはできず、問題が残存したままシステムを利用せざるを得ない可能性があります。

2. 機能更新インストール中の障害

もし SSD 消失問題が環境依存的に存在する場合、25H2 のインストール作業そのものがリスクとなります。大容量のファイル書き込みを伴う更新処理中に SSD が認識不能になれば、インストールが失敗しロールバックされる、あるいはシステムが起動不能に陥る危険性があります。この場合、通常の「更新失敗」よりも影響が大きく、システム復旧が困難になる二次被害につながる恐れがあります。

3. 利用継続リスクと業務影響

企業や組織環境では、セキュリティ要件から最新の更新を適用せざるを得ないケースが多く存在します。そのため、仮に問題が未解決でも 25H2 を導入することが半ば強制され、結果として 安定性よりもセキュリティを優先せざるを得ない状況が発生する可能性があります。このジレンマは、業務システムや重要データを扱う環境で深刻なリスクとなり得ます。

4. アップデート拒否による脆弱性曝露

逆に、不具合を恐れて 25H2 の導入を見送る選択をした場合、セキュリティ更新を長期間適用できないことになります。これにより既知の脆弱性に対してシステムが無防備となり、攻撃リスクが増大します。つまり、「適用して壊れるリスク」と「適用しないで攻撃されるリスク」の板挟みになることが予想されます。

まとめ

今回の Windows 11 セキュリティ更新プログラムに関する SSD 不具合は、ユーザーから複数の報告が上がった一方で、Microsoft と Phison のいずれも大規模なテストで再現できなかったという点が特徴的です。つまり、確かに現象は一部環境で確認されているものの、その発生条件が極めて限定的である可能性が高く、広範なユーザーに共通して影響するタイプの不具合とは断定できない状況にあります。

現時点でユーザーが取れる対策は、不具合が発生した場合に該当パッチをアンインストールすることに限定されます。ただし、これはセキュリティリスクを増大させる副作用を伴うため、問題が実際に発生している環境に絞って適用すべき手段です。それ以外の環境では、定期的なバックアップや SSD の冷却対策といった予防策を優先することが現実的です。

一方で、将来的にリリースされる Windows 11 25H2 への統合が見込まれることから、今回の問題は「解決されないまま累積更新に取り込まれる」可能性を否定できません。その場合、ユーザーはパッチを個別に外すことができず、環境によってはインストール中に障害が発生する、あるいはシステムを安定的に利用できなくなるといった二次災害的リスクを負うことになります。逆に更新を避ければ、脆弱性に曝されるリスクが高まるため、利用者は難しい判断を迫られることになります。

総じて、今回の不具合は「再現できない＝安全」という単純な構図では片付けられません。むしろ、再現性の低さゆえに原因特定が難しく、発生した場合の影響が非常に大きいという点に注意すべきです。25H2 の適用を控える前後では、システム全体のバックアップを確実に取得し、既知の問題リストや公式の追加情報を確認した上で導入を判断する姿勢が求められます。

参考文献

2025年8月26日公開 ― Windows 10 向けプレビュー更新「KB5063842」の内容と注意点

2025年8月26日、Microsoftは Windows 10 バージョン22H2 向けにプレビュー更新「KB5063842（OS ビルド19045.6282）」を公開しました。本更新はセキュリティ修正を含まない「非セキュリティ更新（プレビュー）」であり、主に表示や入力まわりの不具合修正、企業利用を想定した機能改善などが含まれています。

ただし、プレビュー更新は正式な月例更新に先行して提供される「早期公開版」にあたり、動作検証を兼ねている性格が強いため、安定性を最優先する環境では導入に注意が必要です。どうしても解消したい不具合が含まれている場合や、十分な検証環境を持っている場合を除き、一般利用者や企業の運用環境にすぐ適用することは推奨されません。翌月の定例更新に統合されるのを待つ方が安全です。

加えて、NDIを利用するアプリケーションやAutodesk製品など、一部の環境では既存の互換性問題が解消されていない可能性があります。これらは今後の非セキュリティ更新に含まれないまま残される恐れもあり、2025年10月14日に迫る Windows 10 サポート終了 を見据えると、バグ修正が提供されないまま利用を続けるリスクも想定しなければなりません。ESU（拡張セキュリティ更新プログラム）が対象とするのはセキュリティ更新のみであり、互換性の問題や機能不具合が修正される保証はないのです。

したがって本記事では、KB5063842の内容を整理するとともに、適用判断のポイントや、Windows 10 終了期を迎える利用者・企業が取るべき今後の対応についても考察します。

更新の概要

今回の KB5063842（OS ビルド19045.6282） は、Windows 10 バージョン 22H2 を対象とした 非セキュリティプレビュー更新 です。セキュリティ修正は含まれず、主に不具合修正や機能改善を目的としています。公開形態は「プレビュー（オプション）」であり、自動適用はされず、Windows Update の「オプションの更新プログラム」に手動で表示される形式です。

この更新を適用すると、次回の月例必須更新に先立って改善内容を利用できますが、その反面、テスト段階に近い位置付けで提供されているため、安定性よりも早期の不具合解消を優先したい場合や、検証環境での確認を行いたい場合に限って適用することが推奨されます。通常の利用者や企業環境では、無理に導入せず、翌月の定例更新に統合されてから適用する方が安全です。

対象となるのは以下のエディションです。

  • Windows 10 Home
  • Windows 10 Pro
  • Windows 10 Enterprise
  • Windows 10 Education
  • Windows 10 Enterprise Multi-Session
  • Windows 10 IoT Enterprise

なお、Windows 10 のサポートは 2025年10月14日で終了予定 であり、今回のKB5063842はサポート終了前に提供される数少ない更新のひとつにあたります。そのため、プレビュー更新といえども内容を把握しておくことは、サポート切れまでの残り期間を考慮した移行計画やシステム運用の判断において意味を持ちます。

修正点と改善内容

今回のKB5063842（OS ビルド19045.6282）では、Windows 10 バージョン22H2に対して多岐にわたる不具合修正と機能改善が行われています。セキュリティ修正は含まれませんが、ユーザー体験や企業利用環境に影響する重要な修正が含まれているため、内容を整理します。

表示・入力関連の修正

  • 共通コントロールの不具合 一部の補助文字がテキストボックスに正しく表示されない問題を修正。特に国際化環境で入力時の表示欠落が改善されます。
  • 簡体字中国語IMEの修正 拡張文字が空白で表示されてしまう不具合を修正。中国語環境での入力精度が向上します。

認証・アクセシビリティ

  • Windows Helloの改善 ナレーターが「顔認識強化保護を有効にする」チェックボックスのラベルを誤って読み上げてしまう問題を修正。視覚障害ユーザーにとっての操作性が改善されます。

検索・UI表示

  • 検索ペインの不具合 検索ペインでプレビューが正しく表示されない場合がある問題を修正。検索結果の視認性が向上します。

ファミリーセーフティ

  • アプリ利用制限の改善 ブロックされたアプリを起動しようとした際に「許可を求める」フローが起動しない問題を修正。保護者が子供のアプリ利用を管理する仕組みが正常に機能します。

周辺機器・マルチメディア

  • RDS環境でのWebカメラ修正 Remote Desktop Services (RDS) 環境下で mf.dll によってリダイレクトされたウェブカメラが正しく列挙されない問題を修正。リモート利用時の映像デバイス接続性が改善されます。
  • リムーバブルストレージアクセスの修正 グループポリシーで設定された「リムーバブル記憶域へのアクセスを制御する」機能が正しく機能しない不具合を修正。USBメディアの管理ポリシーが期待通りに動作するようになります。

ネットワーク・通信

  • COSAプロファイルの更新 モバイル通信プロファイル（国や通信事業者に応じた設定ファイル）が更新され、最新の通信環境に対応。

エンタープライズ向け改善

  • Windows 10 キーレス Commercial ESU + Windows 365 環境対応 両者を組み合わせた利用環境で、アウトバウンド通信をブロックできる新しい機能を追加。ゼロトラスト環境でのセキュリティ管理を強化。
  • Windows Backup for Organizations 一般提供開始 組織利用向けバックアップ機能がGA（General Availability）となり、デバイスリプレースやWindows 11移行、AI対応PC導入時の事業継続性を支援。企業の移行計画において重要な機能となります。

セキュリティ関連の注意点

  • Secure Boot証明書の有効期限設定 多くのWindowsデバイスで利用されるSecure Boot証明書に有効期限が設定され、2026年6月で期限切れとなる予定。証明書更新を怠るとOSが起動不能になる恐れがあるため、事前対応が強く推奨されています。

解消されていない既知の問題

今回のKB5063842は多くの不具合修正や改善を含むものの、すべての問題が解消されたわけではありません。特にユーザーコミュニティや外部の技術情報で指摘されている事例として、NDI（Network Device Interface）関連とAutodesk製品関連の不具合が依然として残されている点が注目されます。

NDI関連の問題

NDIを利用するアプリケーションにおいて、更新後も依然として不具合が発生する可能性があります。具体的には、映像配信やキャプチャ処理の安定性に影響を与えるケースが報告されており、ライブ配信や映像制作を行うユーザーにとっては業務や制作フローに直接支障をきたす恐れがあります。Windows 10の環境をこのような用途で利用している場合、プレビュー更新を適用することで問題が悪化する可能性も排除できず、慎重な検討が必要です。

Autodesk製品との互換性問題

同様に、Autodesk社が提供する一部のアプリケーションでは、更新を適用した環境で起動時のエラーや動作不良が発生することが指摘されています。これらは建築設計や3Dモデリングなど、専門的な業務で広く利用されている製品であり、特に業務環境において深刻な影響を及ぼすリスクがあります。Autodesk側からの正式な修正や回避策が提示されていない状況であるため、利用者は現行の安定した環境を維持するか、検証環境を用意した上で慎重に導入判断を下す必要があります。

今後の修正見通しについて

これらの問題はKB5063842（OS ビルド19045.6282）には含まれておらず、今後のプレビュー更新や定例更新でも修正が取り込まれるかどうかは不透明です。加えて、2025年10月14日に予定されているWindows 10のサポート終了後は、ESU（拡張セキュリティ更新プログラム）の対象となりますが、ESUが提供するのはあくまで「セキュリティ更新」に限定されます。つまり、今回のようなアプリケーション互換性や機能面での不具合修正が含まれる保証はなく、NDIやAutodesk製品との互換性問題が未解決のまま残される可能性も否定できません。

このため、NDIやAutodeskといった特定の環境依存度が高いソフトウェアを利用している場合は、今後の更新を追跡しつつ、最悪の場合は 不具合が残存したままサポート終了を迎える可能性がある ことを前提に、業務フローの見直しやOS移行計画を検討しておく必要があります。

Windows 10 サポート終了と今後の対応

Microsoftはすでに発表しているとおり、Windows 10 の延長サポートは2025年10月14日で終了します。この日を境に、一般ユーザー向けのセキュリティ更新や不具合修正は一切提供されなくなり、脆弱性への対応やシステムの安定性は利用者自身に委ねられることになります。今回の KB5063842 も、終了に向けた「最後期の更新群」の一部にあたります。

サポート終了後に Windows 10 を使い続ける場合、法人ユーザーであれば ESU（拡張セキュリティ更新プログラム） を契約することで最長3年間のセキュリティ更新を受け取ることが可能です。ただし、この ESU が提供するのはあくまで「セキュリティ更新」のみであり、アプリケーション互換性や機能改善、NDIやAutodeskに代表される不具合修正などが対象になる保証はありません。そのため、業務アプリや周辺機器に依存した環境では、未解消の問題がそのまま残り続けるリスクを理解しておく必要があります。

個人ユーザーの場合は ESU の対象外であり、サポート終了後に Windows 10 を使い続けることは、セキュリティ上のリスクを抱えながら利用を続けることを意味します。特にオンラインバンキングや重要な業務データのやり取りを行う環境では、継続利用は推奨できません。

したがって、利用者が今後取るべき対応は大きく分けて以下の3つです。

  1. Windows 11 への移行 ハードウェア要件を満たしている場合は、Windows 11 へのアップグレードを検討するのが最も安全かつ確実な選択肢です。特に企業環境では、Windows 11 専用の管理機能やセキュリティ機能を活用できるメリットも大きいといえます。
  2. ハードウェア刷新を伴う移行 Windows 11 の要件を満たさないPCを利用している場合は、ハードウェア更新を含めた移行計画を立てる必要があります。近年では「AI PC」として新しい利用形態が想定されており、今後のソフトウェアやサービス連携を見据えると新世代デバイスへの移行は合理的です。
  3. 業務継続のための回避策 一部の業務システムでどうしても Windows 10 環境を残さざるを得ない場合、ESUの活用や仮想環境での隔離運用など、リスクを限定した形での利用が現実的な対策となります。ただし、これも暫定的な措置にすぎず、長期的には移行を避けられません。

総じて、Windows 10 のサポート終了は単なるOSの節目ではなく、ユーザーや企業に対して「移行計画を先送りしないこと」が求められる大きな転換点です。特に今回の KB5063842 のような非セキュリティ更新においても、解消されない不具合が残存する可能性がある以上、サポート終了を待つのではなく、早期にWindows 11や次世代環境へ移行する準備を始めることが現実的な対応策といえるでしょう。

おわりに

今回の KB5063842（OS ビルド19045.6282） は、Windows 10 バージョン22H2向けに公開された非セキュリティのプレビュー更新です。テキスト表示やIME、Windows Hello、検索ペイン、ファミリーセーフティなど、日常利用に直結する機能の不具合修正が含まれており、さらに企業向けには Windows Backup for Organizations の一般提供や、ゼロトラスト環境を意識したライセンス・通信制御の改善なども導入されています。サポート終了を控えたタイミングで、Microsoftが安定性と移行支援を両立させようとしている姿勢が見て取れます。

ただし、本更新はあくまで「プレビュー」であり、適用には慎重さが求められます。どうしても修正したい不具合がある場合や検証環境を持っている場合を除き、一般利用者や業務環境では翌月の月例更新に統合されるのを待つ方が安全です。特に、NDIやAutodesk製品との互換性問題のように今回の更新では解消されない既知の問題も残されており、これらは今後の非セキュリティ更新に含まれないままサポート終了を迎える可能性もあります。ESU（拡張セキュリティ更新プログラム）が提供するのはあくまでセキュリティ修正に限られるため、こうした互換性の不具合が修正対象となる保証はなく、利用者は「修正されないまま残るリスク」を前提に対策を講じる必要があります。

さらに大きな視点では、Windows 10 のサポート終了が 2025年10月14日 に迫っていることを忘れてはなりません。今後の更新は限られており、不具合修正の機会も少なくなっています。今回のKB5063842を含む一連の更新は「終盤戦」の位置づけであり、利用者や企業にとってはWindows 11や新しいデバイスへの移行計画を前倒しで検討する契機と捉えるべきでしょう。

総じて、本更新は日常的な不具合解消と企業利用支援の両面で価値を持ちますが、導入の判断は慎重であるべきです。そして、このアップデートを単なる「不具合修正のひとつ」として消費するのではなく、Windows 10 のサポート終了後を見据えた移行戦略を本格的に始めるためのシグナルと位置付けることが重要です。

参考文献

Docker DesktopにCritical脆弱性、CVE-2025-9074 ─ macOS・Linuxも含め更新推奨

コンテナ技術は、開発から運用まで幅広い現場で欠かせない存在となっています。その中でも Docker Desktop は、Windows・macOS・Linux などの環境で簡単に Docker を利用できるツールとして、多くの開発者やエンジニアに利用されています。日常的にローカル開発環境を立ち上げたり、テスト用に複数のコンテナを起動したりする用途で広く普及しており、影響範囲は非常に大きいと言えます。

今回報告された脆弱性 CVE-2025-9074 は、そうした日常的に利用される開発環境に潜む重大なリスクです。影響は特定の設定や条件に限定されず、Enhanced Container Isolation（ECI）や「Expose daemon」設定の有無にかかわらず影響を受けることが判明しています。これにより、普段はセキュアだと考えていた環境でも、不正アクセスやコンテナ制御の乗っ取りといった深刻な被害に発展する可能性があります。

特に Windows 環境では、WSL を介したホストドライブへのアクセスが可能になるなど追加的なリスクが確認されていますが、macOS や Linux でも同様にコンテナ間の不正制御が可能になるため、「Windows ユーザーだけが対象」ではなく、すべての Docker Desktop ユーザーが直ちにアップデートすべき事案です。

Docker 側は迅速に修正版をリリースしており、2025年8月20日に公開された Docker Desktop 4.44.3 で本脆弱性が修正されています。本記事では、脆弱性の詳細とリスク、そしてユーザーが取るべき対策について整理します。

脆弱性の概要

今回報告された CVE-2025-9074 は、Docker Desktop 上で稼働する Linux コンテナが、本来アクセスできないはずの Docker Engine API に直接アクセスできてしまうという脆弱性です。Docker Engine API はコンテナのライフサイクル管理やイメージ操作などを行うための強力なインターフェースであり、ここに不正アクセスされると、ユーザーの意図しない操作が可能になってしまいます。

この問題の本質は、Docker Desktop が内部で利用している サブネット経由の通信経路にあります。通常であれば、セキュリティ設定やネットワークの分離によってコンテナからホスト側の管理 API へ直接到達できないように設計されています。しかし、今回の脆弱性では、その設計をすり抜ける形でアクセスが可能となり、結果として以下のようなリスクが生じます。

  • 不正なコンテナ制御: 攻撃者が任意に新しいコンテナを生成したり、既存コンテナを停止・削除したりできる。
  • イメージの操作: ローカルに保存された Docker イメージを削除、改ざん、あるいは外部に流出させる可能性。
  • 設定の改変: 環境構築や開発に利用する設定を不正に変更される危険性。

さらに問題を深刻化させているのは、この挙動が ECI（Enhanced Container Isolation）や「Expose daemon」の設定有無に依存しない という点です。つまり、セキュリティオプションを強化していたとしても、今回の脆弱性を防ぐことはできません。

また、Windows 環境においては、WSL バックエンドを利用している場合、通常は制御できない ホストドライブがユーザー権限でマウントされる リスクが確認されています。これはシステム内のファイルが意図せず外部から参照・改変されることにつながり、開発用 PC の安全性を直接脅かす可能性があります。

一方で macOS や Linux 環境においても、Docker Engine API の権限を奪取されれば同様にコンテナ制御やイメージ操作が行われるため、プラットフォームに依存しない深刻な脅威となっています。

今回の脆弱性は CVSS v4.0 ベーススコア 9.3（Critical） として評価されており、最も高い深刻度レベルに分類されています。この評価は、単なる理論的リスクではなく、現実に悪用された場合の影響が極めて広範囲かつ深刻であることを意味しています。

影響範囲

今回の脆弱性 CVE-2025-9074 は、Docker Desktop を利用しているすべてのユーザーに影響を与える可能性があります。特定の環境や利用方法に限定された問題ではなく、Windows・macOS・Linux のいずれにおいても共通してリスクが存在する点が重要です。

まず Windows 環境については、特に WSL（Windows Subsystem for Linux）をバックエンドとして利用している場合に深刻な追加リスクが指摘されています。WSL 上の Linux コンテナからホストマシンのドライブをユーザー権限でマウントされる可能性があり、これによって開発者が扱うソースコードや機密データが不正に参照・改変される危険性が生じます。これは通常のコンテナ分離モデルでは想定されない挙動であり、ローカル開発環境全体が攻撃者に乗っ取られる可能性を意味します。

一方で macOS や Linux 環境でも安心はできません。Docker Engine API へのアクセスが可能になる点は共通しており、攻撃者がこの API を操作することで、以下のようなリスクが発生します。

  • 不正なコンテナの生成・削除・停止などによる環境の破壊
  • ローカルに保存された Docker イメージの不正利用や流出
  • 開発環境に必要な設定やデータの改変によるサービス停止や混乱

つまり、「Windows 以外の環境では被害が軽い」とは言えず、開発環境に依存するすべてのユーザーが影響を受ける可能性があるのです。Docker Desktop は開発者にとって日常的に利用するツールであり、ローカル環境のコンテナ基盤そのものが脆弱化するという点で、被害の範囲は単一コンテナにとどまらず、開発プロジェクト全体、さらには組織内のリポジトリや CI/CD パイプラインに波及するリスクを孕んでいます。

加えて、今回の脆弱性は ECI（Enhanced Container Isolation）や「Expose daemon」設定の有無に依存せず影響するため、「セキュリティ機能を有効化しているから安全」と考えていたユーザーも例外ではありません。むしろ、多くの利用環境で普段通りにコンテナを実行しているだけで影響を受けるため、利用者全体を巻き込む普遍的な問題と言えます。

結論として、この脆弱性は 「Docker Desktop を利用するすべてのユーザーが対象」であり、特定のプラットフォームや構成に限定されたリスクではありません。そのため、Windows だけでなく macOS や Linux を利用している開発者やエンジニアも例外なく、迅速なアップデート対応が求められます。

対策

今回の脆弱性 CVE-2025-9074 に対しては、Docker 社がすでに修正版を公開しており、Docker Desktop 4.44.3 以降にアップデートすることで解消されます。現地時間 2025 年 8 月 20 日にリリースされたこのバージョンには、脆弱性を突いた不正アクセス経路を封じる修正が含まれており、ユーザー側で追加の設定変更を行う必要はありません。

重要な点は、設定や回避策では問題を防げないということです。ECI（Enhanced Container Isolation）の有効化や「Expose daemon」の無効化など、従来のセキュリティオプションを組み合わせてもこの脆弱性を防ぐことはできません。根本的な対策は Docker Desktop 自体を更新することに尽きます。

アップデート手順

１．現在のバージョンを確認

ターミナルで以下を実行し、Docker Desktop 4.44.3 以上であるかを確認します。

docker version

または、Docker Desktop Dashboardの右下に表示されているバージョンが4.44.3以上になっていることを確認します。

２．最新版の入手

Docker の公式サイト（https://www.docker.com/products/docker-desktop）から最新版をダウンロードします。Docker Desktop Dashboardの通知からでもダウンロード可能です。

３．Docker Desktopのアップデート

  • Windows / macOS: インストーラを実行し、既存の Docker Desktop に上書きインストール。
  • Linux: パッケージマネージャ（例: apt や dnf）を利用して更新、もしくは公式のインストーラを再適用。

４．アップデートの実行

右下がUpdateという表示になっている場合、これをクリックしてアップデートを行ってください。Software Updateページが表示されるので、更新を実施してください。

５．アップデート後の確認

  • 再度 docker version を実行し、クライアント・サーバともに 4.44.3 以上であることを確認。
  • 念のため、既存のコンテナが正常に動作するかテスト。

運用上の留意点

  • 全環境での更新を徹底: 個人開発環境だけでなく、チームメンバーや CI/CD 用のビルド環境など、Docker Desktop を利用しているすべての端末で更新が必要です。
  • 旧バージョンの利用を避ける: 脆弱性が公開されているため、旧バージョンを使い続けると攻撃者に狙われやすくなります。
  • 定期的なバージョンチェック: Docker Desktop は短いリリースサイクルで更新されるため、今回の件を機に定期的にバージョン確認を行い、常に最新を維持する運用を推奨します。
  • CI/CD パイプラインの確認: ビルド環境やテスト環境で Docker Desktop を利用している場合、更新漏れがあるとチーム全体のリスクにつながるため、パイプラインの実行ホストも忘れずに更新してください。

結論として、唯一の有効な対策は速やかなアップデートです。Windows 環境だけでなく macOS・Linux を含むすべての開発環境で Docker Desktop を利用しているユーザーは、今すぐバージョン確認を行い、必要に応じて更新を実施することが強く推奨されます。

おわりに

今回明らかになった CVE-2025-9074 は、Docker Desktop の根幹である Docker Engine API へのアクセス制御に関わる重大な脆弱性であり、影響範囲は Windows・macOS・Linux を含むすべての利用者に及びます。特定の環境に限定された問題ではなく、普段の開発作業やテスト環境、さらには CI/CD パイプラインにまで影響する可能性がある点が非常に危険です。

特に Windows 環境では WSL を介したホストドライブへのアクセスが可能になるなど追加的なリスクがありますが、これはあくまで一部の強調事例であり、macOS や Linux 環境でも Docker Engine API を乗っ取られることで同等の深刻な被害が生じ得ます。したがって、「Windows 以外は安全」と考えるのは誤りです。開発者がどの OS を利用していようと、この脆弱性を軽視すべきではありません。

Docker 社は迅速に修正版を提供しており、2025 年 8 月 20 日公開の Docker Desktop 4.44.3 で問題は解消されています。今回の事例から学べる重要な教訓は、脆弱性対策は「設定や部分的な防御策では不十分」であり、ソフトウェアを常に最新の状態に保つことこそが最も確実な防御策であるという点です。

また、個人開発者だけでなく、組織として Docker Desktop を利用している場合は、全メンバーの環境を一斉に更新する体制が不可欠です。ひとりでも古いバージョンを使い続ければ、その環境が攻撃者に狙われ、結果的にプロジェクト全体のセキュリティを損なう恐れがあります。特にクラウド連携やソースコード管理リポジトリと接続している開発環境では、被害が企業全体に波及する可能性すらあります。

さらに、今回の脆弱性に限らず、日常的なセキュリティ対策として 安全性が確認されていない不明なコンテナイメージを軽率に起動しない ことも重要です。公式リポジトリや信頼できる配布元以外から入手したコンテナには、脆弱性を悪用するコードやマルウェアが含まれる可能性があります。OS やツールを最新化することと同様に、利用するコンテナの信頼性を確認することも忘れてはなりません。

結論として、今すぐ Docker Desktop のバージョンを確認し、4.44.3 以上に更新することが最優先の対応です。加えて、怪しいコンテナを不用意に起動せず、信頼できるソースのみを利用することが、Docker 環境全体の安全を守るうえで不可欠な行動となります。

参考文献

Microsoftが発表したWindowsおよび周辺アプリの変更について利用者が注意すべきポイント

以下では、Microsoftの公式情報にもとづき、Windows 11 24H2の強制アップデートに関する発表と既知の不具合、BitLocker（ストレージ暗号化）の自動有効化によるデータ喪失リスク、そしてMicrosoft Authenticatorのパスワード管理機能廃止について解説します。いずれも利用者に影響し得る重要トピックです。それぞれ明確な見出しのもとに詳細をまとめます。

Windows 11 24H2の強制アップデート

learn.microsoft.com
Windows 11, version 24H2 known issues and notifications | Microsoft Learn
View announcements and review known issues and fixes for Windows 11, version 24H2

Windows 11 24H2への大型アップデートは順次すべての適格デバイスに提供され、自動適用が進められています。利用者にとっては、不安定な更新が強制されるリスクに注意が必要です。

MicrosoftはWindows 11 バージョン24H2（通称「Windows 11 2024 Update」）の一般提供を開始し、段階的ロールアウトの最終フェーズに入ったと述べています。特に、Windows Update経由での自動更新について「Windows 11 バージョン23H2/22H2/21H2を実行しているHomeおよびProエディションのデバイス（かつIT部門に管理されていないもの）は、バージョン24H2への更新プログラムが自動的に配信される」ことが公式にアナウンスされています。ユーザーは再起動のタイミングを選択したり、短期間（通常1週間程度）であれば延期も可能ですが、基本的には管理されていない一般ユーザーPCには強制的に24H2へのアップデートが適用される流れです。企業の管理下にない端末（例えば自宅利用のPCや小規模事業のPC）が対象となるため、企業ユーザーであってもこうした端末を業務利用している場合は注意が必要です。一方、社内でWindows Update for BusinessやIntune、グループポリシーなどにより更新管理されているデバイスはこの自動適用の対象外ですが、遅かれ早かれ24H2へのアップグレード計画を立てる必要があります。

こうした強制アップデートに対し、利用者からは「十分に検証されていない不安定なアップデートが強制されるのではないか」という懸念が出ています。アップデート中はPCの再起動が繰り返され長時間かかる可能性があり、業務に支障をきたすおそれがあります。また、アップデート適用後にシステム不具合（最悪の場合Blue Screen of Death、いわゆるSTOPエラー）が発生すると業務停止につながりかねません。実際、Windows 11 24H2にはいくつかの既知の不具合が公式に報告されています。企業環境ではWSUSや更新ポリシーでアップデートのタイミングを制御できますが、最新バージョンへの追随そのものは避けられないため、以下のような問題点を把握した上で慎重に展開することが重要です。

未だ不具合が報告されている状況にある24H2ですが、強制アップデートによる影響を軽減させるためにバックアップなどの対策を行いつつ、アップデートに伴う業務停止時間を最小限にするように計画を立てておく必要が

Windows 11 24H2のストレージ暗号化自動化（BitLocker）とデータ喪失リスク

blogs.windows.com
Windows security and resiliency: Protecting your business | Windows Experience Blog
At Microsoft, security is our top priority, and with every release, Windows becomes even m…

Windows 11 24H2ではデバイスのストレージ暗号化（BitLocker）が初期設定で有効になるケースが増えています。暗号化自体はセキュリティ強化策ですが、万一に備えて回復キーの管理に注意しないと、ユーザーが自分のデータにアクセスできなくなるリスクがあります。

MicrosoftはWindows 11のセキュリティ強化の一環として、「モダンなシステムのほとんどでBitLockerをデフォルト有効化した」と述べています。従来、BitLockerによるドライブ暗号化は主にPro以上のエディションや企業向けに重視されていましたが、Windows 11 24H2では要件緩和によりHomeエディションを含む幅広いシステムで自動的にデバイス暗号化（BitLocker相当）が有効となるよう変更されています。例えばモダンスタンバイ対応のPCだけでなく、TPMを備えた一般的なPCでも条件を満たせばセットアップ時に暗号化がオンになります。これは盗難・紛失時のデータ保護には有効であり、Microsoftも「チップからクラウドまでWindows 11は既定でより安全になった」とアピールしています。

BitLocker自動化の仕組み

初期セットアップや24H2へのアップグレード時に、ユーザーが明示的に操作しなくてもバックグラウンドでドライブ暗号化が開始される場合があります。この際、回復キー（Recovery Key）のバックアップが自動で行われるのが通常です。具体的には、個人のMicrosoftアカウントでWindowsにサインインしている場合、BitLockerの48桁の回復キーはそのアカウントにひも付けられオンラインで取得可能な状態で保存されます。一方、職場や学校の管理下にあるデバイスでは、回復キーはAzure ADやActive Directoryに自動バックアップされ、組織のIT部門が管理します。このように、ユーザー自身が意識しなくとも「回復キーの保管」自体は行われる設計です。ただしMicrosoftも強調しているように、「このバックアップが確実に存在しアクセス可能かを検証すること、必要に応じて自前の追加バックアップを作成すること」が極めて重要です。万一クラウドへのキー保存がされていなかったり、ユーザーが誤ってキー情報を削除してしまっていると、暗号化ドライブにアクセスできなくなった際に復旧手段がなくなるためです。

データ喪失のリスクと注意点

BitLocker暗号化が自動有効になることで懸念されているのが、ユーザーが回復キーを把握していない場合のデータ喪失リスクです。実際、「Windowsのアップデートや設定変更後に突如BitLockerによってロックがかかり、自分のデータにアクセスできなくなった」という報告が増えていると指摘する声もあります。例えばあるユーザーは、「MicrosoftはMicrosoftアカウントでサインインすると自動的にBitLockerを有効化するようになった。もしそのMSアカウントへのアクセス権を失えばデータも永遠に失う。【警告も再チャンスもなく、BitLockerに初めてロックアウトされたときにその存在を知る人が多い】」と述べ、一般ユーザーにとってはデータ機密性よりも可用性（アクセスできること）の方が重要であるケースが多いのに、バックアップの周知不足により「悲劇的な失敗（致命的なデータ損失）」が起きかねないと批判しています。これは決して大げさな懸念ではありません。企業から貸与されたPCや共有端末の場合、利用者自身が回復キーを知らされていなかったり、管理者もキーを紛失してしまうと、そのPC上のローカルデータには誰もアクセスできなくなります。特にリモートワークで従業員が各自セットアップしたPCを使っているような場合、本人が暗号化の存在を認識しておらずキーのバックアップを怠っていると、ちょっとしたハードウェア変更やファームウェア更新が引き金でBitLockerリカバリを求められ、業務データが人質に取られるような事態も起こりえます。

このようなリスクへの対策として、Microsoftは公式ガイドでBitLocker回復キーの確認・バックアップ方法を公開しています。企業環境では、可能であればAzure ADやMBAM（Microsoft BitLocker Administration and Monitoring）等で全端末の回復キーを一元管理する運用が望まれます。また、24H2への更新ポリシー適用時に自動暗号化を無効化するレジストリ設定（[DisableDeviceEncryptionキーの利用など】）も技術的には可能です。しかしセキュリティ強化とのトレードオフになるため、基本方針としては暗号化は有効にした上で、キー管理を徹底することが推奨されます。具体的には以下の点に注意してください:

  • キーの所在確認: Microsoftアカウント利用時は「デバイスの一覧」ページから回復キーを確認できます。同僚や部下のPCについても、組織管理下であればAzure ADポータル等からキーを取得可能です。万一に備え、全デバイスのキー情報が揃っているか今一度チェックしましょう。
  • ユーザー周知: IT部門からエンドユーザーへ、「BitLocker暗号化が有効になっている」ことと「回復キーの重要性」について周知徹底してください。鍵を紛失するとデータ復旧不能になる旨を伝え、可能ならユーザー自身にもキーのバックアップ（印刷保管や安全なクラウド保管）を促します。
  • シナリオテスト: ハードディスク交換やBIOSパスワード変更など、BitLockerがリカバリキー入力を要求する典型的なシナリオをテストしてみましょう。キーを正しく入力できるか、手順に不備がないかを事前に確認しておくことで、実際のトラブル時に落ち着いて対応できます。

以上を踏まえ、Windows 11 24H2環境では「暗号化されていることを前提に運用を組み立てる」ことが不可欠です。セキュリティは強化されますが、その裏で鍵管理がおろそかになると本末転倒です。企業としてはデータ漏えいとデータ消失の双方のリスクを考慮し、ポリシーと教育を整備する必要があります。

Microsoft Authenticatorのパスワード管理機能廃止

support.microsoft.com
Changes to Microsoft Authenticator autofill – Microsoft Support

Microsoft Authenticatorアプリのパスワード保存・自動入力機能が2025年中に段階的終了します。モバイルでAuthenticatorをパスワード管理に使っていたユーザーは、Edgeブラウザーへの移行やエクスポートを求められており、通知を見逃すとパスワードを失う可能性があるため注意が必要です。

Microsoftは「Authenticatorアプリ内のオートフィル（パスワード管理）機能を廃止し、今後はMicrosoft Edgeに統合する」ことを発表しました。これは2025年に入ってから公開されたサポート文書で明らかにされたもので、ユーザーにとって有用だったAuthenticatorのパスワード保存機能を停止する代わりに、より多くのユーザーをEdgeブラウザへ誘導する意図があるとされています。公式には「複数デバイス間でパスワードを容易に使えるようオートフィル体験を整理統合するため」と説明されており、実質的にモバイルにおけるパスワードのオートフィル管理はEdgeに一本化される流れです。

段階的廃止のスケジュール

廃止は一夜にして行われるわけではなく、以下の段階を追って実施されます。

  • 2025年6月 – Authenticatorアプリ上で新しいパスワードを保存する機能が無効化されます。これ以降、Authenticator内には新規のログイン情報を追加登録できなくなります。
  • 2025年7月 – Authenticatorによるパスワード自動入力（オートフィル）機能が停止します。同時に、Authenticatorに保存されていたクレジットカードなどの支払い情報はデバイス上から削除されます（これら支払い情報は他デバイスと同期されない設計のため、このタイミングで消去されると公式に説明されています）。
  • 2025年8月 – Authenticatorアプリに保存されていたパスワードが全て利用不能になります。8月1日をもってサーバー上からも関連データが消去され、以降Authenticatorアプリを開いても既存パスワードは表示されなくなります。

このスケジュールに沿い、最終的にはAuthenticatorアプリからパスワード機能そのものが完全に撤去されます。ただし、アプリ自体は今後も二要素認証コードの生成やパスキーの保存用途で引き続き利用可能です。あくまで削除されるのは「パスワードの保存・入力機能」の部分だけですが、ユーザー体験としては「Authenticatorが大幅に機能縮小される」ことになるため注意が必要です。

利用者への影響と注意点

この変更で最も懸念されるのは、「通知を見逃したユーザーが突然パスワードを失ってしまう」リスクです。MicrosoftはAuthenticatorユーザーに対し、Edgeへの移行またはサードパーティ製パスワードマネージャーへのエクスポートを推奨しています。公式メッセージでは「2025年8月1日より後はAuthenticator内のパスワードおよび情報は自動的に削除されるため、それまでにデータをエクスポートしておくように」と案内しています。しかし、この情報は主にウェブのサポート記事や一部報道を通じて伝えられているもので、アプリ内通知を見落としていたり、そもそも変更自体を知らないユーザーも存在するでしょう。例えば個人でAuthenticatorを使っていた従業員がこの事実を知らない場合、8月になってからアプリを開いて初めて「保存していた多数のサイトのパスワードが消えている」ことに気付き、業務ログインに支障が出るかもしれません。

企業のIT担当者は、従業員がAuthenticatorのパスワード機能を利用しているか把握し、必要に応じてサポートすることが求められます。具体的には:

  • 周知徹底: 会社から「Microsoft Authenticatorでパスワードを保存・自動入力している場合、近日中に使用できなくなる」旨を告知し、各自でEdgeブラウザーの機能に移行するか、データをエクスポートして別のパスワード管理ツールにインポートするよう促しましょう。
  • データエクスポート支援: AuthenticatorアプリにはパスワードデータをCSV形式でエクスポートする機能があります。IT部門として手順を案内したり、必要ならエクスポート作業を支援してください。またエクスポートしたファイルの安全な取扱い（暗号化保管・早期削除）についてもアドバイスすべきです。
  • 代替ソリューションの提示: Microsoftが推奨するようにEdgeブラウザの組み込み機能を使う方法以外にも、企業ポリシーで許可された信頼性の高いパスワード管理ソフト（例: 1PasswordやLastPass、Keeperなど）への移行を検討しても良いでしょう。重要なのは、ユーザーがパスワード管理難民にならないよう事前に受け皿を用意することです。

今回のAuthenticator機能廃止は、Microsoftアカウントを取り巻くパスワードレス戦略の一環とも言われています。実際、同時期にMicrosoftアカウントのパスワードレス認証（パスキーなど）の拡充も発表されています。しかし現実には多くのWebサービスが未だパスワードで保護されており、ユーザー側でパスワードを管理しなければならない状況は当面続きます。企業においても、従業員が誤ってAuthenticator任せにしていたパスワードを失わないよう、そして安全なパスワード管理方法へ円滑に移行できるよう、期限（2025年8月）までに対応を完了させることが望まれます。

まとめ

以上、Windows 11 24H2の強制アップデートと不具合、BitLocker自動暗号化の留意点、Microsoft Authenticatorのパスワード機能廃止について解説しました。いずれのトピックも「セキュリティ強化」や「最新環境への移行」という大きな流れの中で起きている変化ですが、その過程で一時的にユーザーや管理者の負担・リスクが増す側面があります。企業のIT管理者としては公式情報を注視し、適切なタイミングで社内システムやポリシーを調整することが重要です。幸いMicrosoftからは定期的に詳細な発表やドキュメントが提供されていますので、信頼性の高い一次情報をもとに迅速かつ的確な対応を心がけましょう。本記事の情報が、皆様の環境をアップデートしつつ安全に維持する一助になれば幸いです。

Kaggle CLIをアップデートする

以下のような警告が表示された場合、Kaggle CLIを最新バージョンにアップデートしましょう。

Warning: Looks like you're using an outdated API Version, please consider updating (server 1.5.15 / client 1.5.13)

Kaggle CLIをアップデートする

警告にも表示されていますが、念のため現在のバージョンを確認します。

$ kaggle --version
Kaggle API 1.5.13

次に最新バージョンを確認します。pip list --outdatedで更新が必要なパッケージをリストして最新バージョンを確認することができます。

$ pip list --outdated
Package                       Version     Latest       Type
----------------------------- ----------- ------------ -----
・・・
kaggle                        1.5.13      1.5.16       sdist
・・・

警告を見るとサーバーが1.5.15となっていたので、クライアントも1.5.15が最新版かと思いましたが、どうやら最新版は1.5.16のようです。

新しくなる分には問題ありませんので、最新版にアップデートします。

$ pip install --upgrade kaggle
Requirement already satisfied: kaggle in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (1.5.13)
Collecting kaggle
  Downloading kaggle-1.5.16.tar.gz (83 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 83.6/83.6 kB 4.5 MB/s eta 0:00:00
  Preparing metadata (setup.py) ... done
Requirement already satisfied: six>=1.10 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (1.16.0)
Requirement already satisfied: certifi in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (2023.7.22)
Requirement already satisfied: python-dateutil in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (2.8.2)
Requirement already satisfied: requests in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (2.29.0)
Requirement already satisfied: tqdm in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (4.65.0)
Requirement already satisfied: python-slugify in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (8.0.1)
Requirement already satisfied: urllib3 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (1.26.15)
Requirement already satisfied: bleach in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (6.0.0)
Requirement already satisfied: webencodings in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from bleach->kaggle) (0.5.1)
Requirement already satisfied: text-unidecode>=1.3 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from python-slugify->kaggle) (1.3)
Requirement already satisfied: charset-normalizer<4,>=2 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from requests->kaggle) (3.1.0)
Requirement already satisfied: idna<4,>=2.5 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from requests->kaggle) (3.4)
Building wheels for collected packages: kaggle
  Building wheel for kaggle (setup.py) ... done
  Created wheel for kaggle: filename=kaggle-1.5.16-py3-none-any.whl size=110685 sha256=9d938a633a89c1157e7dcf713de3ce949e873e92ac478bc1b88a6e2b8fe8b6d0
  Stored in directory: /Users/t0k0sh1/Library/Caches/pip/wheels/43/4b/fb/736478af5e8004810081a06259f9aa2f7c3329fc5d03c2c412
Successfully built kaggle
Installing collected packages: kaggle
  Attempting uninstall: kaggle
    Found existing installation: kaggle 1.5.13
    Uninstalling kaggle-1.5.13:
      Successfully uninstalled kaggle-1.5.13
Successfully installed kaggle-1.5.16

アップデートは成功していますが、念のためバージョンを確認しておきます。

$ kaggle --version
Kaggle API 1.5.16

もう一つ、アップデートが必要なパッケージにリストされていないことも確認します。

$ pip list --outdated | grep kaggle

まとめ

Pythonのパッケージは定期的に更新しないため、バージョンが古くなりがちです。安定しているバージョンを使っているという意味では頻繁に更新する必要はありませんが、Kaggle CLIのようにサーバーとやりとりを行うCLIパッケージについては、気づいたときに最新版にアップデートすることが重要です。

[Node.js][npm]ローカルパッケージを更新する

ローカルパッケージを更新する手順について説明します。

本記事では、複数のパッケージを一気にバージョンアップする方法については解説しません。ライブラリやフレームワークによっては公式でバージョンアップデート方法やマイグレーション方法を説明している場合があります。そのような場合は本手順ではなく、公式の手順に従うようにしてください。

また、パッケージのバージョンアップは十分注意して行うようにしてください。バグフィックスであっても意図しない動作をする可能性がありますので、十分テストした上でバージョンアップすることが大切です。

手順

sassパッケージをアップデートする例で手順を説明します。

{
  ...
  "devDependencies": {
    "sass": "^1.56.1"
  }
}

執筆時点では、sassパッケージの最新バージョンは1.56.2ですので、1.56.1から1.56.2へのバージョンアップを試みます。

アップデートの有無を確認する

エディタの機能等で最新バージョンを確認できる方は必要ありませんが、コマンドで最新バージョンが存在するかを確認することができます。

$ npm outdated
Package  Current  Wanted  Latest  Location           Depended by
sass      1.56.1  1.56.2  1.56.2  node_modules/sass  npm-update-sample

前述のとおり、現在バージョン（Current）は1.56.1で最新バージョン（Latest）は1.56.2であることがわかります。

各項目の意味は以下のとおりです。

  • Package：最新バージョンがあるパッケージ（現在のバージョンが最新バージョンの場合は表示されない）
  • Current：現在インストールされているバージョン
  • Wanted：package.jsonに記載されたセマンティックバージョンの条件を満たす最新バージョン
  • Latest：最新バージョン
  • Location：インストール先
  • Depended by：このパッケージに依存しているパッケージ

パッケージをアップデートする

アップデートを確認できましたので、実際にアップデートを行っていきます。

ここでは、すべてのパッケージをアップデートするのではなく、バージョンアップしたいsassパッケージだけをアップデートし、1.56.2へ狙い撃ちでバージョンアップする方法を説明します。

パッケージのアップデートはnpm updateコマンドで行いますが、このコマンドでは対象パッケージを指定することまではできますが、特定のバージョンを指定してアップデートすることはできません。最新バージョンではなく、特定のバージョンを指定してアップデートしたい場合はnpm installコマンドを用います。

$ npm install sass@1.56.2

changed 1 package, and audited 39 packages in 669ms

4 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

sassパッケージはdevDependenciesにありますが、バージョンアップするときはオプションなしでアップデートできます。

{
  ...
  "devDependencies": {
    "sass": "^1.56.2"
  }
}

package.jsonを確認するとバージョンアップしていることが確認できます。

グローバルインストールしたAngular CLIをアップデートする

グローバルインストールしたAngular CLIをアップデートする手順について解説します。

注意事項

本手順はグローバルインストールされたAngular CLIのバージョンアップする手順です。
プロジェクトのAngularをバージョンアップする手順ではないのでご注意ください。

アップデート前の状態

アップデート前の状態を確認しておきます。ng versionでインストールされているAngular CLIのバージョンを確認することができます。

$ ng version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 13.3.1
Node: 16.14.2
Package Manager: npm 8.7.0
OS: darwin arm64

Angular:
...

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.1303.1 (cli-only)
@angular-devkit/core         13.3.1 (cli-only)
@angular-devkit/schematics   13.3.1 (cli-only)
@schematics/angular          13.3.1 (cli-only)

本手順では、13.3.1がアップデート前の状態になります。

Angular CLIをアップデートする

Angular CLIを13.3.1から13.3.4にアップデートしましょう。

まずは、現在インストールしているAngular CLIをアンインストールします。

$ npm uninstall -g @angular/cli

removed 196 packages, and audited 1 package in 567ms

found 0 vulnerabilities

次にAngular CLIを再度インストールします。ここでは最新版をインストールしていますが、特定のバージョンにアップデートしたい場合は@angular/cli@x.x.xのようにバージョンを指定してください。

$ npm install -g @angular/cli

added 196 packages, and audited 197 packages in 10s

24 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

インストール後に再度バージョンを確認します。

$ ng version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 13.3.4
Node: 16.14.2
Package Manager: npm 8.8.0
OS: darwin arm64

Angular:
...

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.1303.4 (cli-only)
@angular-devkit/core         13.3.4 (cli-only)
@angular-devkit/schematics   13.3.4 (cli-only)
@schematics/angular          13.3.4 (cli-only)

Angular CLIのバージョンが13.3.4にアップデートされたことを確認できました。

この手順はバージョンアップにもバージョンダウンにも使用できます。

asdfでよく使うコマンド集（アップデート、プラグイン、バージョン）

asdfの中でもよく使う、アップデート関連、プラグイン関連、バージョン関連のコマンドについて解説します。

アップデート関連

プラグイン自体のアップデートや追加したプラグインのアップデートについて解説します。

asdf自体のアップデート

それほど頻繁に実施する必要はりませんが、asdf自体をアップデートする場合は、以下のコマンドを実行します。

asdf update

すべてのプラグインのアップデート

特段理由がなければすべてのプラグインをアップデートする方が楽です。すでに追加済みのプラグインをすべてアップデートするときは、以下のコマンドを実行します。

asdf plugin-update --all

特定のプラグインのみをアップデート

たくさんのプラグインを追加していて全部アップデートするのは時間がかかる、バージョンをあげたくないプラグインがある、など何かしらの理由があって特定のプラグインのみをアップデートしたいときは、以下のコマンドを実行します。

asdf plugin-update <プラグイン名>

<プラグイン名>には、アップデートしたいプラグインを指定します。

プラグイン関連

プラグインの表示、追加、削除など基本的な操作について解説します。

プラグインの一覧表示

プラグインを一覧表示するときは、以下のコマンドを実行します。

asdf plugin list all

大量に表示されますので、Grepで対象を絞り込む方がよいでしょう。

$ asdf plugin list all | grep node                                                                                                                                                                                
nodejs                       *https://github.com/asdf-vm/asdf-nodejs.git

上記の例では、Node.jsのプラグイン名を調べるためににnodeでGrepし、nodejsであることが分かりました。

現在インストール中のプラグインの一覧表示

すでにインストール済みのプラグインをしたいときは、以下のコマンドを実行します。

asdf plugin list

プラグインの追加

プラグインを追加するときは、以下のコマンドを実行します。

asdf plugin add <プラグイン名>

<プラグイン名>のところは、追加したいプラグインの名前を指定します。

プラグインの削除

プラグインを削除するときは、以下のコマンドを実行します。

asdf plugin remove <プラグイン名>

<プラグイン名>のところは、削除したいプラグインの名前を指定します。

バージョン関連

バージョンに関する操作について解説します。

使用可能なバージョンの一覧表示

特定のプラグインの使用可能なバージョンを一覧表示したいときは、以下のコマンドを実行します。

asdf list all <プラグイン名>

こちらもGrepを併用することでインストールしたいバージョンを特定するのがよいでしょう。

asdf list all nodejs | grep ^11.

上記のでは、nodejsパッケージのうち、11系だけをGrepで絞り込んでいます。

インストール済みのバージョンを一覧表示

すでにインストール済みのバージョンを一覧表示したいときは、以下のコマンドを実行します。

asdf list <プラグイン名>

バージョンをインストールする

指定したバージョンをインストールするときは、以下のコマンドを実行します。

asdf install <プラグイン名> <バージョン>

<プラグイン名>はインストールしたいプラグインの名前、<バージョン>はインストールしたいバージョンを指定します。

バージョンをアンインストールする

指定したバージョンをアンインストールするときは、以下のコマンドを実行します。

asdf uninstall <プラグイン名> <バージョン>

<プラグイン名>はアンインストールしたいプラグインの名前、<バージョン>はアンインストールしたいバージョンを指定します。

バージョンの設定

asdfでは、global、local、shellの3つの設定範囲があります。使用目的によって適切な設定範囲を選択することで、効率よくバージョン管理を行うことができます。

globalバージョンの設定

globalバージョンは、特に指定がない場合に使用されるバージョンです。globalバージョンを設定するときは、以下のコマンドを実行します。

asdf global <プラグイン名> <バージョン>

<プラグイン名>はglobalバージョンを設定したいプラグインの名前、<バージョン>はglobalバージョンに設定したいバージョンを指定します。

globalバージョンは、システム全体で使用するバージョンを設定するとよいでしょう。言い方を変えると、特段理由がない場合に使用するバージョンであるとも言えます。例えば、メインストリームのバージョンやLTSのバージョンを設定しておく運用方法が適切です。

localバージョンの設定

特定のフォルダ（ディレクトリ）内でのみ有効なバージョンです。globalバージョンで使用しているバージョンとは異なるバージョンを使いたい場合に使用するとよいでしょう。

localバージョンを設定するときは、以下のコマンドを実行します。

asdf local <プラグイン名> <バージョン>

現在のフォルダ（ディレクトリ）およびそのサブフォルダ（ディレクトリ）ではlocalバージョンが有効になります。このとき、.tool-versionsが作成され、使用するプラグインとバージョンが記録されます。

localバージョンは、プロジェクトで使用するバージョンを指定するために使用するとよいでしょう。
例えば、普段はPython 3.9.xを使用していますが、今携わっているプロジェクトでは、Python 3.7.xでないとビルドができないとしましょう。
この場合、globalバージョンは3.9.xですが、プロジェクトのフォルダ（ディレクトリ）内ではPython 3.7.xをlocalバージョンに指定しておくことで、このプロジェクト内だけは3.7.xを使用することができます。
もし、複数の保守プロジェクトを抱えている場合であれば、この恩恵はとても大きいものになります。

shellバージョンの設定

シェル内でのみ有効なバージョンです。使用頻度は高くありませんが、使用するコマンドが特定のバージョンを要求する場合などに重宝します。

shellバージョンを設定するときは、以下のコマンドを実行します。

asdf shell <プラグイン名> <バージョン>

これは現在のシェルの設定が変わるわけではなく、新にシェルを起動し、そこでのバージョンが設定したバージョンになります。そのため、使用を終了する場合は、exitコマンドで抜けることができます。

shellバージョンは、特定のコマンドやツールを実行する際に、特定のバージョンまたは特定のバージョン以下でないと実行できない、といった場合に使用するとよいでしょう。
例えば、プロジェクトでは、Node.js 16.xを使用しています。リリース用のツールもNode.jsで書かれていますが、古いツールなためNode.js 11.xでないと動作しません。
こういった場合には、globalバージョンまたはlocalバージョンは16.xを設定し、ツールを実行するときだけ、shellバージョンに11.xを設定してコマンドを実行する運用にする方が、バージョンアップ対応を行うよりもコストメリットがあります。

モバイルバージョンを終了