2025年9月12日のWindowsセキュリティ更新直後から、特定の1台だけが共有フォルダーに入れず「資格情報を入力してください」が繰り返し出る──この症状は、近年のSMB（ファイル共有）に関する既定変更が原因で起こりやすくなっています。本稿では、応急処置から恒久的で安全な構成まで、現場で即使える手順とチェックポイントをまとめて提供します。
目次
問題の核心：なぜ新PCだけが弾かれるのか
2023年以降、Windowsはゲストアクセス（資格情報なしでのSMB接続）を既定で拒否する方向へ段階的に舵を切っています。これにより、共有側（メインPC）で「パスワード保護共有を無効」にしていても、クライアント側のポリシーがゲストを禁止していれば、ダイアログで資格情報を要求し続けます。9月の更新など大きな更新を挟むと、端末ごとにポリシー/レジストリが再評価され、設定差分のある端末だけが急に接続できなくなることがあります。
よくある前提のすれ違い
- 共有側で「パスワード保護共有：無効」＝誰でも入れると思っている → 実際はクライアント側がゲストを拒否すると入れない
- 他のPCは入れるのに新PCだけNG → 新PCにだけ厳しめの既定/ポリシーが適用されている可能性が高い
- アップデート後にネットワークプロファイル（プライベート/パブリック）が変わると、ファイアウォールや共有が制限されやすい
先に結論：安全な恒久策と暫定策（判断表）
| 方針 | 目的 | 適用対象 | セキュリティ | Windows更新の影響 | 推奨度 |
|---|---|---|---|---|---|
| 恒久策：ローカルユーザーで認証する | ゲスト廃止に備え、安全に共有 | 家庭/社内とも | 高（推奨） | 小（将来も安定） | 最優先 |
| 暫定策：クライアントでゲスト許可 | 今すぐアクセス復旧 | 信頼できるLANのみ | 中〜低（リスクあり） | 中（更新で戻る可能性） | 短期のみ |
| （稀）共有側でゲスト受け入れ調整 | 既存運用の延命 | 閉域・非機密 | 低（非推奨） | 大（将来ブロック想定） | 最終手段 |
背景（2023年以降の既定変更）
Windowsは段階的に「匿名/ゲストでのSMBアクセス」を縮小・既定禁止へと移行しています。共有側で「パスワード保護共有を無効」にしても、クライアント側（Lanman Workstation）の「insecure guest logons（安全でないゲストログオン）」が既定で無効になっていると、認証なしの接続は拒否され、資格情報入力ダイアログが表示されます。結果として、以前は入れた共有でも、更新後に端末によって挙動が分かれる現象が出ます。
まず試すべき基本チェック
- ネットワークプロファイル：新PC/メインPCともに「設定 → ネットワークとインターネット → アクティブな接続」でプライベートを選択（パブリックだと共有/探索が制限されます）。
- 資格情報マネージャー：新PCで「コントロール パネル → 資格情報マネージャー → Windows 資格情報」からメインPC名/そのIPに関する項目をいったん削除し、競合をクリア。
- ファイアウォールのプロファイル：メインPCの「ファイルとプリンターの共有（SMB-In）」がプライベートに対して許可されているか確認。
- 名前解決：
\\メインPC名でダメでも\\192.168.x.x（実IP）で入れるか確認。名前解決だけが壊れている可能性があります。
応急処置：クライアント側でゲスト接続を許可する
信頼できるLANで短期的に共有へ入る必要がある場合に限り実施します。後述の恒久策と併用し、復旧後は元に戻すことを推奨します。
レジストリで許可（管理者権限）
regeditを起動。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parametersを開く。AllowInsecureGuestAuth（DWORD 32bit）を新規作成し、値を1に設定。- PCを再起動し、共有に再接続。
コマンドで一括適用する場合：
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" ^
/v AllowInsecureGuestAuth /t REG_DWORD /d 1 /f
PowerShellでも設定可能です：
PowerShell（管理者）:
Set-SmbClientConfiguration -EnableInsecureGuestLogons $true
元に戻す：
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" ^
/v AllowInsecureGuestAuth /t REG_DWORD /d 0 /f
PowerShell（管理者）:
Set-SmbClientConfiguration -EnableInsecureGuestLogons $false </code></pre>
<p><em>注意：ゲスト接続は認証・監査が弱く、持ち出し端末や公共ネットワークでは使用しないでください。</em></p>
<h2>（必要な場合のみ）共有側でゲスト受け入れを再確認する</h2>
<p>共有側（メインPC）で、共有フォルダーの<strong>共有権限</strong>や<strong>NTFS権限</strong>に「Everyone（必要最小の読み取り等）」を含めているか確認します。さらに、匿名/ゲストを許容する設定を復活させる方法も存在しますが、<strong>企業ネットワークや機密情報を扱う環境では非推奨</strong>です。</p>
<ul>
<li>グループポリシー（共有側ではなく通常はクライアント側に効く）：「コンピューターの構成 → 管理用テンプレート → ネットワーク → <strong>Lanman Workstation</strong> → <strong>Enable insecure guest logons</strong>」を<b>有効</b>にすると、ゲストを要求する共有に接続できるようになります。</li>
<li>共有側PowerShellで状態確認：
<pre><code>Get-SmbServerConfiguration | Select EnableSMB1Protocol,EnableSMB2Protocol,RejectUnencryptedAccess,RequireSecuritySignature
Get-SmbShare
Get-SmbShareAccess -Name <共有名>
繰り返しになりますが、これらは延命策です。将来の更新で再び遮断される可能性があり、恒久策へ移行してください。
推奨：より安全な恒久対策（ローカルユーザーで認証）
ゲストアクセスをやめ、明示的なユーザー/パスワードで共有する構成に切り替えます。更新の影響を受けにくく、アクセス権の最小化や監査も容易になります。
共有側（メインPC）でローカルユーザー作成
- 設定 → アカウント → 家族とその他のユーザー → ユーザーを追加（例：
shareuser）。 - または管理者コンソール：
net user shareuser <強固なパスワード> /add net localgroup Users shareuser /add - 共有フォルダーのプロパティ → 共有 → 詳細な共有で共有名を設定。
「アクセス許可」でshareuserに必要最小権限（読み取り/変更など）を付与。
「セキュリティ（NTFS）」でも同様にshareuserを追加し整合。
クライアント側（新PC）から認証してアクセス
- エクスプローラーのアドレスバーに
\\メインPC名または\\<メインPCのIP>を入力。 - 資格情報入力ダイアログで「ユーザー名：
メインPC名\shareuser」「パスワード：作成したもの」を入力し、保存にチェック。 - コマンドでドライブ割り当てする場合：
net use Z: \\メインPC名\共有名 /user:メインPC名\shareuser <パスワード> /persistent:yes
更新直後にやっておく再点検（新PC/メインPC共通）
- ネットワークプロファイル：プライベートに戻っているか。
- 資格情報の競合解消：古いPC名/古いIPで保存された資格情報を削除。
- ファイアウォール：「ファイルとプリンターの共有（SMB-In）」がプライベートで有効か。
- サービス：
Function Discovery Provider Host/Function Discovery Resource Publicationが動作中か（探索に影響）。 - 名前解決差分：IPv4/IPv6どちらに解決されているか（
ping メインPC名で確認）。IPv6のみで届かない機器が混在している場合は一時的にIPv4指定で検証。
新PCだけ拒否されるときの“あるある”原因10選
- Lanman Workstationの既定が厳格（ゲスト拒否）。
- ネットワークプロファイルがパブリックに変わった。
- 資格情報マネージャーの古い保存情報が干渉。
- 名前解決が別経路（他PCはIPv4、新PCはIPv6で当たり、ルーティング差異）。
- ファイアウォール/セキュリティ製品のポリシー差異。
- NTLM関連ポリシーが端末ごとに異なる（送信NTLM制限など）。
- 時刻差（ドメイン/職場アカウントでKerberosなら致命的。Workgroupでも影響することあり）。
- 共有権限/NTFS権限の不整合（Everyoneは共有許可だがNTFSが拒否など）。
- SMB署名や暗号必須の条件がクライアントとサーバーで不一致。
- メインPC名の変更後に旧名でのキャッシュが残っている。
すばやい切り分けコマンド集（現場向け）
共通テスト
Test-NetConnection -ComputerName メインPC名 -Port 445
# 445/TCP が到達しているか（SMBの基本ポート）
クライアント側
Get-SmbClientConfiguration | fl EnableInsecureGuestLogons,RequireSecuritySignature
Get-SmbConnection
net use
klist sessions
共有側（メインPC）
Get-SmbServerConfiguration | fl EnableSMB1Protocol,EnableSMB2Protocol,RejectUnencryptedAccess,RequireSecuritySignature
Get-SmbShare
Get-SmbShareAccess -Name 共有名
代表的なメッセージ別の対処
| メッセージ/症状 | 考えられる原因 | 一次対処 | 恒久対処 |
|---|---|---|---|
| 「資格情報を入力してください」が毎回出る | クライアントがゲストを拒否／資格情報競合 | 資格情報マネージャーの清掃、AllowInsecureGuestAuth=1で暫定復旧 | ローカルユーザーで認証に切替、資格情報保存 |
| 「アクセスが拒否されました」 | 共有/NTFS権限の不整合 | 共有とNTFSの両方に該当ユーザーを追加 | 最小権限設計で再構成 |
| 「ネットワークパスが見つかりません」 | 名前解決/ルーティング/ファイアウォール | IP直打ち/445の疎通/プロファイル確認 | DNS/LLMNRの整備、ファイアウォール調整 |
キャッシュされた資格情報の削除（競合回避）
- 新PCで「コントロール パネル → 資格情報マネージャー → Windows 資格情報」。
- メインPC名またはIPに紐づく項目をすべて削除。
- 再度
\\メインPC名へアクセス→正しいアカウントで保存。
ネットワークプロファイルの再確認
更新後に「パブリック」へ自動変更されるケースがあり、その場合は共有や探索が制限されます。
「設定 → ネットワークとインターネット → アクティブな接続」からプライベートを選択し直してください。
やってはいけない対策
- SMBv1の再有効化：既知脆弱性が多く、現在は非推奨。
- Guestアカウントの常時有効化：監査不能・横展開リスク増大。
- 広範なファイアウォール無効化：短時間の切り分け以外では禁止。
復旧のゴール像（チェックリスト）
- 共有側：
shareuser等のローカルユーザーが作成済み、共有/NTFS権限が最小で付与されている。 - クライアント側：資格情報に
メインPC名\shareuserが保存され、ドライブマップが永続化されている。 - プロファイルは双方ともプライベート、445/TCPの疎通が確認できる。
- ゲスト許可（暫定策）を使った場合は元に戻している（
AllowInsecureGuestAuth=0）。
付録：本文の要点（短縮版手順）
- 応急処置（クライアント）：
AllowInsecureGuestAuth=1またはSet-SmbClientConfiguration -EnableInsecureGuestLogons $true→ 再起動 → 接続確認。 - 共有側の見直し：権限整合、ファイアウォール、プライベートプロファイル化。
- 恒久策：共有側でローカルユーザー作成 → 共有/NTFS権限付与 → クライアントから
メインPC名\ユーザーで接続し保存。 - キャッシュ掃除：資格情報マネージャーから旧情報を削除。
付録：イベントログの参考
詳細な原因追跡が必要な場合：
- クライアント：イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → SMBClient（Connectivity/Security）
- 共有側：イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → SMBServer
ゲスト拒否や認証失敗に関する警告/エラーが記録されていれば、該当ポリシーや資格情報の見直しで多くは解決します。
ケーススタディ：他の2台はOK、1台だけNGの典型パターン
他のPCは過去に共有へ資格情報を保存済み、あるいは既にローカルユーザーで接続している。一方、新PCは更新でゲストが拒否され、共有側がゲストでの入室前提のままのため、ダイアログが無限ループ。
→ 新PCでローカルユーザーによる認証接続に切替し、保存するだけで解消することが多い、というのが現場の実情です。
最終まとめ
- 2025年9月更新を含む近年の更新により、資格情報なしのSMBゲスト接続は既定で拒否されやすい。
- 応急処置としてクライアントでゲスト許可は可能だが、恒久策はローカルユーザーでの認証共有。
- 更新直後の不具合はプロファイル/資格情報/ファイアウォール/名前解決の再確認から。
- SMBv1は再有効化しない。最小権限・監査可能な構成に移行する。
本文中の要請に対応する具体手順（整理）
クライアント側でゲスト接続を許可（応急処置）
- レジストリ：
HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\ParametersにAllowInsecureGuestAuth（DWORD）=1。 - 再起動後、資格情報の入力要求が消えるか確認。
※セキュリティ低下のため、信頼できるネットワーク以外では非推奨。復旧後は戻す。
（補足）ポリシーからの許可（通常はクライアント側に適用）
gpedit.msc → コンピューターの構成 → 管理用テンプレート → ネットワーク → Lanman Workstation → Enable insecure guest logons＝有効。
ネットワーク プロファイルの再確認
両PCとも「プライベート」であることを確認。更新で「パブリック」に変わると共有が制限されるため。
キャッシュされた資格情報の削除
新PCの資格情報マネージャーからメインPC名/IPに関するエントリを削除し、再接続。
より安全な恒久対策（推奨）
- メインPCにローカルユーザー（例：
shareuser）を作成し、共有/NTFS権限を付与。 - 他PCは
\\メインPC名へアクセス時に当該ユーザー/パスワードを入力し保存。ゲストより安全で将来の更新にも強い。
巻き戻し手順（応急処置を解除する）
# レジストリを既定に戻す
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" ^
/v AllowInsecureGuestAuth /t REG_DWORD /d 0 /f
# PowerShellで無効化
Set-SmbClientConfiguration -EnableInsecureGuestLogons $false トラブル時の追加ヒント
- 接続先の指定は、
\\メインPC名\共有名が失敗する場合、\\IPアドレス\共有名で試す。 net use * /delete /yで既存セッションをクリアしてから再試行する。- ドライブ割り当てで安定運用：
net use Z: \\メインPC名\共有名 /user:メインPC名\shareuser /persistent:yes
セキュリティ備考
ゲストアクセスの許可は短時間の業務継続のための暫定策に限りましょう。恒久的には認証つき共有と最小権限が鉄則です。企業ネットワークや機密データ環境では、応急処置のまま運用を続けないでください。
コメント