なぜWindows 11の更新後に共有フォルダが開けなくなるのか
「昨日まで普通に使えていた共有フォルダが、突然アクセスできなくなった」——Windows 11のバージョン24H2や25H2にアップデートした直後、まさにこの問い合わせがヘルプデスクに殺到しているんじゃないでしょうか。
筆者の環境でも、24H2の展開直後にファイル共有関連のチケットが通常の5倍以上に跳ね上がりました。正直、最初は何か別のネットワーク障害かと思ったくらいです。
でも原因はシンプルでした。MicrosoftはWindows 11 24H2からSMB(Server Message Block)プロトコルのセキュリティを大幅に強化して、以下の2つの変更をデフォルトで有効にしたんです。
- SMB署名の必須化:Enterprise・Pro・Educationエディションでは、インバウンド・アウトバウンドの両方でSMB署名が必須に
- 安全でないゲストログオンのブロック:パスワードなしの共有フォルダへのゲストアクセスがデフォルトで拒否されるように
そしてWindows 11 25H2(2025年10月以降順次配信)では、さらにSMB v1のNetBIOS over TCP/IP(NetBT)経由での通信が完全に遮断され、クローンイメージによる重複SIDの検証も厳格化されています。
つまり、アップデートのたびに「繋がらない」範囲がどんどん広がっているわけです。困りますよね。
このガイドでは、エンドユーザーが遭遇するエラーメッセージの意味から、ヘルプデスク担当者向けの切り分け手順、そして企業全体でのGPO・Intune展開まで、段階別にまとめました。上から順に読んでも、必要なセクションだけ拾い読みしても大丈夫です。
よく表示されるエラーメッセージとその意味
まずはユーザーから報告される代表的なエラーメッセージを把握しておきましょう。エラーの種類によって原因がかなり絞り込めるので、一次対応の効率が大きく変わります。
「組織のセキュリティポリシーによって非認証のゲストアクセスがブロックされています」
これが24H2以降で最も多いエラーです。共有フォルダがパスワード保護なしのゲストアクセスで運用されている場合に出ます。NASや古いWindows PC、Linux Sambaサーバーへの接続で特によく見かけます。
エラーコード 0x80070035「ネットワークパスが見つかりません」
SMB署名の不一致が原因であることが多いエラーです。接続先がSMB署名に対応していなかったり、SMBのバージョンが合っていなかったりする場合に発生します。
pingは通るのにフォルダにアクセスできない——そんなときは、まずこのエラーを疑ってください。
エラーコード 0x80004005「不明なエラーが発生しました」
SMB関連の認証失敗やプロトコル不一致の汎用エラーです。資格情報マネージャーのキャッシュが壊れていたり、SMB 1.0でしか通信できないデバイスに接続しようとしたときに頻出します。(このエラーメッセージ、もう少し具体的にしてほしいものですが…)
エラーコード 0xc000a000「STATUS_INVALID_SIGNATURE」
接続先がSMB署名をサポートしていない、または署名の検証に失敗した場合のエラーです。特にサードパーティ製のNASやSambaサーバーとの接続で発生しやすいですね。
エンドユーザー向け:基本チェックリスト
ヘルプデスクに問い合わせが入ったとき、まずエンドユーザーに確認してもらう項目をまとめました。意外とここで解決するケースも多いです。
ステップ1:ネットワーク接続の確認
共有フォルダの問題に見えて、実はネットワーク自体が切れているケース——これが意外と多いんです。以下を確認してもらいましょう。
- Wi-Fiまたは有線LANが接続状態か確認
- タスクバーのネットワークアイコンに警告マークが出ていないか
- VPN接続中の場合、一度切断してから再試行
ステップ2:ネットワークプロファイルの確認
Windows 11では、ネットワークプロファイルが「パブリック」に設定されていると、ファイル共有が自動的にブロックされます。ここ、けっこう見落としがちなポイントです。
- 「設定」→「ネットワークとインターネット」→「Wi-Fi」(または「イーサネット」)を開く
- 接続中のネットワークのプロパティを開く
- 「ネットワークプロファイルの種類」が「プライベート」になっていることを確認。「パブリック」の場合は「プライベート」に変更する
ステップ3:共有フォルダのパスを直接指定してみる
エクスプローラーのアドレスバーに直接パスを入力してアクセスできるか試してもらいましょう。
\サーバー名\共有フォルダ名
「ネットワーク」画面からの探索はNetBIOS名前解決に依存するため、DNSやNetBIOSの問題で見えないことがあります。パス直接指定でアクセスできるなら、名前解決の問題です。ファイル共有そのものは生きているので、切り分けの大きなヒントになります。
ステップ4:資格情報の再入力
古い資格情報がキャッシュされていると認証に失敗することがあります。
- 「コントロールパネル」→「ユーザーアカウント」→「資格情報マネージャー」を開く
- 「Windows資格情報」タブで、対象サーバーのエントリがあれば削除
- 共有フォルダに再度アクセスし、正しいユーザー名とパスワードを入力
ヘルプデスク担当者向け:原因の切り分け手順
基本チェックで解決しなかった場合は、ここからが本番です。以下の手順で原因を体系的に切り分けていきましょう。
切り分け1:影響範囲の把握
まずは「誰が」「どこに」アクセスできないのかを整理します。このパターン分けが、その後の対応速度を左右します。
| パターン | 想定される原因 | 対応方針 |
|---|---|---|
| 24H2/25H2にアップデートしたPCのみ | SMBセキュリティ変更 | 本ガイドの対処法を適用 |
| 特定のNAS/サーバーへの接続のみ | 接続先のSMBバージョン/設定 | NASファームウェア更新・設定変更 |
| 全PCで発生 | サーバー側の設定変更・障害 | サーバー管理者と連携 |
| 特定ユーザーのみ | 権限・資格情報の問題 | ACL・資格情報の確認 |
切り分け2:SMB接続の診断コマンド
PowerShellで以下のコマンドを実行して、現在のSMB設定を確認します。コピペでそのまま使えます。
# クライアント側のSMB設定を確認
Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature, EncryptionCiphers
# サーバー側のSMB設定を確認(共有元のPCで実行)
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, RequireSecuritySignature, RejectUnencryptedAccess
# 現在のSMB接続状態を確認
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted | Format-Table -AutoSize
RequireSecuritySignatureがTrueになっていて、接続先がSMB署名に非対応であれば、それが原因です。ここまで来ればほぼ確定ですね。
切り分け3:SMBバージョンの確認
接続先のSMBバージョンを見れば、プロトコルレベルの問題を特定できます。
# 接続先のSMBバージョンを確認
Get-SmbConnection -ServerName "サーバー名" | Select-Object Dialect
# 結果の読み方:
# 3.1.1 = SMB 3.1.1(最新・推奨)
# 3.0.2 = SMB 3.0.2
# 2.1 = SMB 2.1(署名対応だがやや古い)
# 2.0.2 = SMB 2.0(署名対応)
# 1.x = SMB 1.0(非推奨・セキュリティリスク高)
切り分け4:イベントログの確認
Windows 11 24H2以降では、SMB署名・暗号化に関する新しい監査イベントが追加されました。どのデバイスが署名非対応なのか特定するのに便利です。
# SMB関連のイベントログを取得(直近24時間)
Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-SMBClient/Security'
StartTime = (Get-Date).AddHours(-24)
} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, Message | Format-List
対処法1:PowerShellによる即時解決(個別PC向け)
最も手軽な対処法です。とりあえず今すぐ繋がるようにしたい、というときはこれ。影響を受けているWindows 11 PCで、管理者権限のPowerShellから以下を実行します。
# ゲストログオンを許可
Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force
# クライアント側のSMB署名要件を解除
Set-SmbClientConfiguration -RequireSecuritySignature $false -Force
# サーバー側のSMB署名要件も解除(このPC自身が共有元の場合)
Set-SmbServerConfiguration -RequireSecuritySignature $false -Force
実行後、PCを再起動して共有フォルダへのアクセスを確認してください。
注意:この方法はSMBのセキュリティを緩和するため、あくまで一時的な回避策です。恒久対策としては、後述する認証設定の整備やNASのファームウェア更新が必要になります。「とりあえず動くようにして、裏側で根本対応を進める」というイメージですね。
対処法2:グループポリシーによる設定変更(Pro/Enterprise向け)
Windows 11 Pro/Enterpriseなら、ローカルグループポリシーまたはドメインGPOで設定できます。GUIで操作したい人はこちらのほうが馴染みやすいかもしれません。
安全でないゲストログオンの有効化
- Win + Rで「
gpedit.msc」を実行 - 「コンピューターの構成」→「管理用テンプレート」→「ネットワーク」→「Lanman ワークステーション」に移動
- 「安全でないゲストログオンを有効にする」をダブルクリックし、「有効」に設定
SMB署名要件の無効化
- 「コンピューターの構成」→「Windowsの設定」→「セキュリティの設定」→「ローカルポリシー」→「セキュリティオプション」に移動
- 「Microsoftネットワーククライアント: 常に通信にデジタル署名を行う」を「無効」に設定
- 同様に「Microsoftネットワークサーバー: 常に通信にデジタル署名を行う」も「無効」に設定
設定変更後、コマンドプロンプトまたはPowerShellで以下を実行してポリシーを即時適用します。
gpupdate /force
対処法3:レジストリ編集(Windows 11 Home向け)
Windows 11 Homeにはグループポリシーエディターがないので、レジストリを直接編集する必要があります。ちょっとハードルが高く感じるかもしれませんが、コマンドをコピペするだけなので大丈夫です。管理者権限のコマンドプロンプトで以下を実行してください。
rem SMB署名の要件を解除
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 0 /f
rem 安全でないゲストログオンを許可
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation" /v AllowInsecureGuestAuth /t REG_DWORD /d 1 /f
rem 64ビット環境向けの追加設定
reg add "HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\LanmanWorkstation" /v AllowInsecureGuestAuth /t REG_DWORD /d 1 /f
実行後はPCを再起動してください。
対処法4:NAS・接続先デバイスの設定見直し
ここまでの対処法はクライアント側(接続する側)の設定変更でしたが、根本的な解決としては、接続先デバイスの設定を見直すのが一番効果的です。個人的には、ここに早めに着手することをおすすめします。
NASのファームウェアを更新する
Buffalo、I-O DATA、QNAP、Synologyなど主要NASメーカーは、Windows 11 24H2対応のファームウェアをリリースしています。まずは最新ファームウェアに更新して、SMB 2.0/3.0での通信を有効にしてください。
NAS側でSMB署名を有効にする
NASの管理画面からSMBの設定を開き、以下を確認します。
- SMBプロトコルバージョンをSMB2以上に設定
- SMB署名を有効に設定
- ゲストアクセスを無効にし、ユーザー認証を必須にする
接続先のWindows PCに認証アカウントを設定する
共有元がWindows PCの場合、パスワード付きのユーザーアカウントを作成して、そのアカウントで共有フォルダへのアクセス権を設定する方法がMicrosoftが最も推奨する対処法です。手順は以下のとおり。
- 共有元PCで「設定」→「アカウント」→「他のユーザー」からアカウントを追加
- 共有フォルダのプロパティ→「共有」タブで、作成したアカウントにアクセス権を付与
- 接続元PCからアクセスし、作成したアカウントの資格情報でログイン
企業環境向け:GPO/Intuneでの一括展開
数十台〜数千台規模の環境では、さすがに個別対応は現実的じゃありません。Active DirectoryのGPOまたはMicrosoft Intuneで一括展開しましょう。
Active Directory GPOでの展開
グループポリシー管理コンソール(gpmc.msc)で新しいGPOを作成し、対象のOUにリンクします。展開前に、既存のGPOにSMB関連の設定が含まれていないか確認しておくと安心です。
# PowerShellでGPOの設定を確認(ドメインコントローラーで実行)
Get-GPO -All | ForEach-Object {
$gpoName = $_.DisplayName
$report = Get-GPOReport -Guid $_.Id -ReportType Xml
if ($report -match "RequireSecuritySignature|AllowInsecureGuestAuth") {
Write-Output "GPO: $gpoName に SMB関連設定あり"
}
}
設定すべき項目は、前述のグループポリシーの内容と同じです。ただし、ドメイン全体にいきなり適用するのは避けてください。テスト用のOUで動作確認してからの展開を強くおすすめします。
Microsoft Intuneでの展開
Intuneを利用している環境では、設定カタログからカスタムプロファイルを作成できます。
- Microsoft Intune管理センターで「デバイス」→「構成プロファイル」→「新しいプロファイルの作成」
- プラットフォーム「Windows 10以降」、プロファイルの種類「設定カタログ」を選択
- 設定カタログで「Lanman Workstation」を検索し、以下を追加:
- Enable Insecure Guest Logons:有効
- 同様に「SMB」で検索し、署名関連の設定を追加
- 対象グループに割り当てて展開
ただし注意点がひとつ。Intuneのセキュリティベースラインでは、ゲストログオンの無効化とSMB署名の有効化が推奨されています。今回の設定はNAS側の対応が完了するまでの一時的な緩和措置として位置づけて、移行が完了したら元の設定に戻すことをおすすめします。
25H2で追加された問題と対処
Windows 11 25H2では、24H2の変更に加えてさらにいくつかの問題が出てきています。
SMB v1のNetBIOS over TCP/IP通信の遮断
25H2ではSMB v1がNetBT経由で完全に通信できなくなりました。どうしてもSMB v1を使う必要がある場合は、TCPポート445への直接接続に切り替える必要があります。
# ファイアウォールでTCPポート445を許可
New-NetFirewallRule -DisplayName "SMB Direct (TCP 445)" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow
ただし、Microsoftは公式にSMB v1の保守を終了しています。SMB v1に依存しているデバイスがあるなら、できるだけ早くSMB 2.0/3.0対応のものへの更新を検討してください。ここは先送りにすると後で痛い目を見ます。
クローンイメージによるSID重複問題
25H2ではSIDの検証が厳格化されて、クローンイメージから展開されたPCで重複SIDが検出されると、SMBやRDPの認証が失敗するようになりました。
# 現在のSIDを確認
whoami /user
# Sysprepで新しいSIDを生成(展開前に実行すること)
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown
マスターイメージからの展開時は、必ずSysprepを実行してSIDを一意にしてから展開してください。これを忘れると、あとから全台やり直しになるので本当に注意です。
セキュリティのベストプラクティス:恒久対策のロードマップ
一時的な回避策でチケット対応をしのいだら、ここからが本当の勝負です。以下のロードマップで恒久対策を進めていきましょう。
短期(1〜2週間):現状把握と一時緩和
- 影響を受けているPC・NAS・サーバーの一覧を作成
- 一時的なGPO/Intuneプロファイルで業務影響を最小化
- Windows 11 24H2の監査機能を有効化し、SMB署名非対応デバイスを特定
中期(1〜3か月):接続先の対応
- NASのファームウェアを更新し、SMB 2.0/3.0 + 署名を有効化
- ゲストアクセスの共有フォルダを、ユーザー認証必須に移行
- SMB 1.0に依存するレガシーデバイスの棚卸しと更新計画を策定
長期(3〜6か月):セキュリティ強化の完了
- 一時緩和のGPO/Intuneプロファイルを無効化し、SMB署名必須の状態に戻す
- SMB 1.0を完全に無効化
- SMB 3.1.1 + AES暗号化の環境に統一
- 認証方式をNTLMv2からKerberos認証へ移行(可能な範囲で)
この順番で進めれば、業務を止めずにセキュリティも強化できます。焦らず、でも着実に。
よくある質問(FAQ)
Q1:Windows 11を24H2にアップデートしたらNASに接続できなくなりました。元に戻す方法はありますか?
アップデートのロールバックも可能ですが、根本的な解決にはなりません。まずはNASのファームウェアを最新に更新して、SMB 2.0以上と署名に対応させてください。一時的な回避策としては、PowerShellでSet-SmbClientConfiguration -EnableInsecureGuestLogons $true -ForceとSet-SmbClientConfiguration -RequireSecuritySignature $false -Forceを実行すればアクセスが回復します。
Q2:Windows 11 Homeでグループポリシーエディターが使えません。どうすればいいですか?
Windows 11 Homeにはグループポリシーエディターが搭載されていないので、レジストリを直接編集します。管理者権限のコマンドプロンプトで、本記事の「対処法3:レジストリ編集」セクションのコマンドを実行してください。なお、Windows 11 Homeでは24H2以降でもSMB署名はデフォルトで必須になっていませんが、ゲストログオンのブロックは有効になっています。
Q3:SMB署名を無効にするとセキュリティリスクはどの程度ありますか?
SMB署名はネットワーク上の中間者攻撃(MITM)やリレー攻撃を防ぐ仕組みです。無効にすると、同一ネットワーク内の攻撃者がSMB通信を改ざんしたり、資格情報をリレーしたりするリスクがあります。
社内ネットワークで信頼できる環境であればリスクは限定的ですが、公共ネットワークやゲストWi-Fiが同一セグメントにある環境ではおすすめしません。NAS側の対応が完了したら、必ず署名要件を元に戻してください。
Q4:SMB 1.0を有効にしても大丈夫ですか?
率直に言って、おすすめしません。SMB 1.0はWannaCryランサムウェアなどで悪用された脆弱なプロトコルで、Microsoftも公式に保守を終了しています。どうしても必要な場合は、該当デバイスを隔離したVLANに配置してアクセスを限定し、デバイスの更新・交換を早急に計画してください。
Q5:今後のWindowsアップデートでこの問題は解消されますか?
残念ながら、これはMicrosoftの意図的なセキュリティ強化であって、不具合ではありません。以前の動作に戻る可能性は極めて低いです。むしろ25H2で見られたように、セキュリティ要件はさらに厳格化される傾向にあります。接続先デバイスの対応を進めることが、唯一の恒久的な解決策です。