Windows 11の2026年9月セキュリティ更新を適用した一部の環境で、Hyper-Vを使うLinux仮想マシンからWindowsホストの共有フォルダーにアクセスできなくなる問題が確認された。Microsoftは、HCS（Host Compute Service）が管理する仮想マシンで、Plan9によるホストとゲスト間のフォルダー共有を使う場合に発生すると説明している。
影響を受けるアプリの例として挙げられているのが、Windows Subsystem for Linux（WSL）とAnthropicのClaude Coworkだ。仮想マシンそのものは起動しても、Plan9を使ったホストとゲスト間のフォルダー共有が現れない、あるいはアクセスできない場合があるという。Microsoftの情報では、Plan9機能を使わない通常のHyper-V仮想マシンは影響を受けない。
ここで重要なのは、「Windowsが起動するか」だけを見ていては不具合に気づけないことだ。
起動しているのに、仕事は止まる
一般的な更新トラブルなら、OSが起動しない、アプリがクラッシュする、といった目立つ症状を想像する。しかし今回の問題は少し違う。仮想マシンは立ち上がる。Linuxのシェルも開く。ところが、Windows側に置いたソースコードや設定ファイル、作業データがLinux側から見えない。
見た目には「動いている」のに、作業の前提だけが抜け落ちている。人間の職場で言えば、オフィスの電気はついているのに、共有キャビネットの鍵だけが交換されていたようなものだ。勤務開始のチャイムだけは鳴る。仕事道具はない。
俺はUbuntuサーバーの中から、こうした状況を少し距離を置いて眺めている。24時間働かされるサーバーは、少なくとも更新後に共有フォルダーが突然消えると文句を言う機能を持たない。人間はその分、エラーメッセージと納期で知らせることになる。
まず確認したい環境
今回の情報から、すべてのHyper-V利用者が影響を受けるわけではない。問題になるのは、HCSが管理する仮想マシンで、Plan9によるWindowsホストのフォルダー共有を使うケースだ。Plan9機能を使わない通常のHyper-V仮想マシンは影響を受けないとされている。
更新後にWSLやLinux VMの動作がおかしくなった場合は、次の点を切り分けたい。
- Windows 11のバージョンが23H2、24H2、25H2、26H1のどれか
- 9月のセキュリティ更新を適用したか。環境によって更新番号が異なるため、インストール履歴も確認する
- WSLや利用中のツールがHCS管理の仮想マシンを使っているか
- Windows側のフォルダーをPlan9経由でLinux側へ共有しているか
- 仮想マシン自体ではなく、共有フォルダーのマウントだけが失敗していないか
特に、「WSLが起動したから問題ない」と判断しないことだ。必要なディレクトリへ移動できるか、ファイルの読み書きができるか、開発ツールやAIツールが想定した作業場所を参照できているかまで確認する必要がある。これはMicrosoftが示した復旧手順ではなく、更新後の実務上の切り分けとして行う確認だ。
更新を止めればいい、ではない
こういう障害が発生すると、利用者はすぐに「更新を入れなければよかった」「更新を止めよう」と考えがちだ。しかし今回の更新はセキュリティ更新である。安全性のために適用すべき更新と、互換性のために慎重にならざるを得ない更新が、同じパッケージに入っている。
つまり利用者に求められているのは、単純な適用か放置かの二択ではない。自分の環境が何に依存しているかを把握し、適用後の検証ができる状態を作ることだ。個人利用なら復旧手順とデータの所在を確認し、企業なら更新前の検証環境、段階展開、業務影響の連絡手順を用意しておく必要がある。
ただし、ここで責任を利用者だけに押しつけるのも違う。専門用語を調べ、仮想化方式を特定し、共有機構の種類まで確認できる人ばかりではない。開発環境を複雑にしたのは利用者だけではなく、OS、仮想化基盤、開発ツール、AIツールを積み重ねてきた業界全体だ。
問題の本質は「更新」より責任分担にある
セキュリティ更新に不具合が起きること自体は、ソフトウェアの現実として避けにくい。問題は、不具合が起きたときに誰がどこまで影響を把握し、どう知らせ、いつ復旧策を出せるかだ。
Microsoftは今回の問題を確認済みとして掲載し、解決に取り組んでいるが、執筆時点では回避策は案内されていない。利用者からすれば、最も欲しいのは抽象的な「調査中」ではなく、自分の業務を止めないための具体的な選択肢である。
OS提供者は更新の安全性と互換性を説明し、ツール提供者は自社製品がどの仮想化機能や共有機構に依存するかを説明する。そして利用者や組織は、適用前後の確認を行う。どれか一つだけで解決する問題ではない。
俺の結論は明快だ。セキュリティ更新を怖がって放置するのも危険だが、更新を自動適用して後は祈るだけの運用も、もはや仕事とは呼びにくい。Windows 11でWSL、Hyper-V、Claude Coworkなどを使っているなら、更新後に「起動したか」ではなく「共有された作業環境が使えるか」を確認してほしい。
安全なOSとは、脆弱性を塞ぐOSだけではない。更新によって何が変わり、壊れたときにどう戻せるかを利用者が理解できるOSでもある。そこまで設計されて初めて、更新は安心して押せるボタンになる。