Windows 10 から Windows Server 2008 R2 の共有に、サーバー名（FQDN）なら開けるのに IP アドレス指定だと開けない――この症状は、アクセス方法で SMB の認証方式が変わり、Windows 10 側の NTLM 制限や互換性設定と衝突して起きることが多いです。原因の仕組みと、安全に直す手順を現場目線で整理します。
症状の整理：Windows 10 だけが「\\＜サーバーIP＞\共有」で開けない
社内に Windows 10（64bit）複数台／Windows 7 複数台／ファイルサーバーとして Windows Server 2008 R2 が存在し、共有フォルダ（SMB）を利用している環境で起きやすいトラブルです。典型的には次のような振る舞いになります。
- Windows 10：
\\192.0.2.10\shareのように IP アドレスで指定すると開けない（エクスプローラーで失敗、資格情報の入力画面が出ない／出ても通らない等） - Windows 10：
\\filesrv.example.local\shareのようにサーバー名（できれば FQDN）なら開ける - Windows 7：IP 指定でも名前指定でもアクセスできる
「ネットワークや共有の権限は同じはずなのに、指定方法だけで成否が変わる」ため、DNS や共有権限だけを疑って遠回りしがちですが、この症状は 認証方式（Kerberos／NTLM）が切り替わること を起点に考えると最短で解決できます。
結論：IP 指定は NTLM 認証になりやすく、Windows 10 の方針と噛み合わないと失敗する
SMB 共有へのアクセスでは、環境により Kerberos（ドメイン参加、SPN、時刻同期などが揃っている場合）または NTLM が使われます。ここで重要なのが「サーバーをどう指定したか」です。
| 指定方法 | 認証の傾向 | なぜ差が出るか |
|---|---|---|
サーバー名／FQDN（例：\\filesrv.example.local\share） | Kerberos が成立しやすい（条件が揃えば） | Kerberos はホスト名（SPN）を前提にチケットを発行するため、名前指定の方が仕組みに合う |
IP アドレス（例：\\192.0.2.10\share） | Kerberos が使いにくく、NTLM にフォールバックしやすい | IP は SPN と結びつきにくく、結果として NTLM になりやすい。Windows 10 の NTLM 制限や互換性設定により拒否されることがある |
「名前だと通る」のは Kerberos の条件を満たしやすいから
Kerberos は ホスト名に対して認証チケットを発行します。SMB 共有の場合は cifs/サーバー名 に対する SPN（Service Principal Name）が関わるため、FQDN/サーバー名でアクセスすると Kerberos で処理できる可能性があります。
一方、IP アドレスでのアクセスは SPN と結びつけにくく、結果として NTLM にフォールバックしがちです。ここで Windows 10 側が「NTLM を送らない／古い方式を拒否する／NTLMv2 以外を認めない」方向に寄っていると、IP 指定のときだけ失敗が表面化します。
まずやるべき切り分け：原因を 10 分で特定するチェックリスト
いきなりポリシー変更をすると影響範囲が読めません。次の順で「どこで認証が崩れているか」を掴むと、最小変更で直せます。
チェック 1：同じ PC で「名前指定は成功」「IP 指定だけ失敗」を再現できるか
同一端末で差が出るなら、ネットワーク断よりも 認証・ポリシー・資格情報の扱い が濃厚です。特に Windows 10 でのみ再現し、Windows 7 では再現しないなら、Windows 10 側の既定値変更や GPO の適用が絡みやすいです。
チェック 2：SMB 接続状態をコマンドで「見える化」する
エクスプローラーの見た目だけでは原因が読みづらいので、まずは接続状態を確認します。Windows 10 なら PowerShell で次のコマンドが使えます。
Get-SmbConnectionここで対象サーバーが表示されるか、共有名、ユーザー名、SMB の方言（Dialect）がどうなっているかを確認します。名前指定で接続した後に実行し、IP 指定では接続が作られない（一覧に出ない）なら、認証またはセッション確立の段階で落ちています。
チェック 3：Kerberos が使われているかを確認する（klist）
名前指定で接続できている場合、Kerberos が成立している環境ではサービスチケットが作られていることがあります。次のコマンドで確認できます。
klist一覧に cifs/ で始まるチケットが見えるなら、名前指定は Kerberos で通っている可能性が高いです。IP 指定では同様のチケットが作れない（＝NTLM になりやすい）ため、ここが「差の正体」になります。
チェック 4：いったん SMB セッションをリセットして試す（保存資格情報・多重接続の除去）
IP と名前は Windows から見ると別の宛先として扱われるため、過去に別アカウントで接続していると、それが原因で「IP 側だけ」つまずくケースがあります。検証前に以下を実行し、不要な接続を消してから再試行してください。
net use
net use * /delete /y加えて「資格情報マネージャー」に対象サーバー（IP、ホスト名）の保存済み資格情報が残っていないかも確認します。ここまでで改善した場合は、ポリシーではなく 資格情報の衝突 が原因です。
チェック 5：グループポリシーの適用状況を確認する（Windows 10 だけ厳しくなっていないか）
Windows 10 だけで発生する場合、GPO が Windows 10 にだけ適用されている（WMI フィルター、OU の違い、セキュリティフィルターなど）ケースがあります。次で「どのポリシーが効いているか」を把握できます。
gpresult /rより詳しく見るなら HTML レポートの出力も有効です。
gpresult /h gpresult.html推奨の解決策：運用を「サーバー名（できれば FQDN）指定」に統一する
最も安全で、かつ再発しにくい対処は IP アドレス指定をやめる ことです。IP 指定でしかアクセスできない事情がないなら、ここがベストです。
名前指定に統一するメリット
- セキュリティを落とさずに解決できる可能性が高い（NTLM を許可する方向の設定変更が不要）
- Kerberos が使える環境では、認証の品質（なりすまし耐性、監査のしやすさ）が上がる
- サーバー更改時に CNAME/DFS などで吸収しやすく、利用者の設定変更が少ない
現場でよく使う「統一のやり方」
| 方法 | 向いている場面 | 注意点 |
|---|---|---|
FQDN を案内して利用者に周知（例：\\filesrv.example.local\share） | 最短で運用を揃えたい | 周知徹底が必要。ショートカットやバッチの書き換え漏れが出やすい |
| DNS で別名（CNAME）を用意し、共有用の固定名を作る | サーバー更改も見据え、名前を資産化したい | Kerberos を使う場合は SPN との整合に注意（AD 管理者と設計して進める） |
DFS 名前空間（例：\\domain\share）を使う | 共有が多い／将来のサーバー分散がある | 構築・運用の手間は増えるが、ユーザー目線では最も強い |
「とりあえず今だけ直したい」場合でも、短期対応としては名前指定統一が一番事故が少ないです。次章は、どうしても IP 指定が必要なケース（古いソフトが IP しか受け付けない、DNS が使えないセグメントがある等）に備えた手順です。
どうしても IP アドレス指定を通したい場合：Windows 10 側のポリシーを見直す
IP 指定を許可するということは、多くの環境で「NTLM を許可する」方向の調整になります。これは セキュリティと引き換え になりやすいため、影響範囲（対象端末・対象サーバー）を限定して実施してください。
確認すべき代表設定 1：LAN Manager 認証レベル（LMCompatibilityLevel）
Windows の GUI 上は次の場所にあります（ローカルセキュリティポリシー、または GPO）。
- [ローカル セキュリティ ポリシー]（
secpol.msc） - [ローカル ポリシー] → [セキュリティ オプション] → 「ネットワーク セキュリティ: LAN Manager 認証レベル」
この設定はレジストリでは HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel に相当します。値を直接いじるより、GPO/ローカルポリシーで管理した方が追跡しやすいです。
LMCompatibilityLevel の意味（実務で迷うところだけ押さえる）
「IP 指定だと NTLM になる」前提で見ると、クライアントが送る方式 と サーバーが受ける方式 が噛み合わないと認証が失敗します。代表的な値と実務上の解釈は次の通りです。
| 値 | クライアントが送る傾向 | 互換性 | セキュリティ観点 | 現場での使い所 |
|---|---|---|---|---|
| 5 | NTLMv2 のみ（LM/NTLM を拒否） | 古いサーバー/機器だと失敗しやすい | 強い（許容範囲が狭い） | ドメイン内をできるだけ Kerberos へ寄せたい場合。例外設計が必要になりがち |
| 4 | NTLMv2 のみ（LM を拒否、NTLM は状況次第） | 古い環境で一部詰まる可能性 | 強め | LM は排除したいが、完全拒否は難しい場合の落とし所 |
| 3 | NTLMv2 を送る | 2008 R2 クラスなら概ね対応できることが多い | バランス | どうしても NTLM が残る環境での現実解になりやすい |
| 2 以下 | NTLM（v1）や LM を許容 | 互換性は上がる | 弱い | 最終手段。短期の切り戻し用途に留め、恒久運用は避けたい |
確認すべき代表設定 2：NTLM の送信制限（Restrict NTLM）
Windows には NTLM を段階的に締めるためのポリシー群があります。ここが「拒否」になっていると、IP 指定で NTLM になった瞬間に接続が失敗します。GUI 上は同じく [セキュリティ オプション] 配下にあり、名称は次のような形です。
- 「ネットワーク セキュリティ: NTLM を制限する: リモート サーバーへの送信 NTLM トラフィック」
- （環境によって）「ネットワーク セキュリティ: NTLM を制限する: このドメインでの NTLM 認証」
- （監査）NTLM の利用状況をログに出す設定
いきなり全面許可に戻すのではなく、まずは「監査（Audit）」にして、どの端末がどの相手に NTLM を投げているかを可視化してから、例外の設計を行うのが安全です。
変更の優先順位（おすすめ）
| 優先 | 対処 | 理由 |
|---|---|---|
| 高 | 名前指定（FQDN）へ運用統一 | セキュリティ低下を伴いにくく、根が深いポリシー差分にも強い |
| 中 | Windows 10 の LMCompatibilityLevel を確認し、必要最小限で調整 | 互換性調整として効果が出ることがあるが、下げすぎるとリスクが増える |
| 中 | Windows 10 の「NTLM 送信制限」を監査→例外設計 | 全面許可は避けつつ、問題端末だけ救える |
| 低 | クライアント全体で古い方式（LM/NTLMv1）を許可 | 互換性は上がるが、防御力が下がりやすい。短期の応急処置向き |
「設定を変えたのに直らない」場合の典型パターン
- LMCompatibilityLevel は変えたが、別ポリシーで「NTLM の送信自体」が拒否されている
- GPO で上書きされ、ローカル変更が反映されていない（
gpresultで確認） - 資格情報の衝突が残ったまま（
net useでセッションが残っている）
サーバー側（Windows Server 2008 R2）で確認したいポイント
クライアントだけでなく、サーバー側の設定が原因で「Windows 10 の NTLMv2 を受けられない」ケースもあります。特に 2008 R2 は運用歴が長いことが多く、過去の互換性目的の設定が残っていることがあります。
サーバー側でも「LAN Manager 認証レベル」を確認する
場所はクライアントと同様で、「ネットワーク セキュリティ: LAN Manager 認証レベル」です。ここが古い方式を前提にしていたり、逆に厳しすぎてクライアントの挙動と噛み合っていないと、IP 指定時（NTLM になった時）だけ失敗します。
NTLM の最小セッション セキュリティ（署名・暗号）もチェックする
セキュリティオプションには NTLM SSP の最小要件（署名、128-bit 暗号など）を求める設定があります。クライアント/サーバーの片方だけが「必須」に寄っていると、認証自体は通ってもセッション確立で落ちることがあります。
イベントログで「何が拒否されたか」を確認する
推測で設定をいじると泥沼化します。Server 2008 R2 側のセキュリティログ（失敗ログオンなど）を確認し、次の情報を拾うと原因が見えます。
- ログオン失敗の有無（ユーザー名、接続元、失敗理由）
- 認証パッケージが NTLM になっているか（名前指定時との比較）
- 同一ユーザーが短時間に複数失敗していないか（資格情報の誤り／キャッシュの衝突のサイン）
実務で多い「ハマりどころ」と回避策
IP と名前を混在させると、資格情報が二重管理になりやすい
Windows は \\192.0.2.10\share と \\filesrv\share を別の相手として扱います。すると、片方に保存した資格情報がもう片方には効かず、利用者は「昨日まで開けたのに突然ダメ」になりやすいです。ショートカット、バッチ、アプリの設定、マッピングドライブが混在していないか棚卸ししてください。
多重接続の制限で「IP 側だけ」エラーになる
すでに \\filesrv\share を別ユーザーで接続している状態で、\\192.0.2.10\share を別資格情報で張ろうとすると、多重接続エラーが出ます。現場ではサポート担当が別アカウントで試験して混乱することが多いので、検証前に net use で状態を必ず確認します。
「IP 指定しかできない」アプリの落とし穴
古い業務アプリ、バックアップソフト、複合機のスキャン保存先などは、UNC を IP 固定で登録していることがあります。この場合、単に利用者が名前指定に変えても改善しません。次のような代替策を検討します。
- アプリ側がホスト名を受け付けるなら、設定を FQDN に変更する
- どうしても IP 固定なら、その端末（機器）だけ例外扱いにして NTLM を許可する範囲を絞る
- 中長期的には、アプリ更新・機器更新の計画に「ホスト名対応」を要件として入れる
確認手順：直ったかどうかを「再現性」と「ログ」で確認する
対処後は、単にエクスプローラーで開けたかだけで終わらせず、再発しない形になっているか確認します。
- 同一端末で、名前指定と IP 指定の両方を試し、挙動差が解消したか確認する
Get-SmbConnection／net useでセッションが意図通り作られているかを見る（不要な古い接続が残っていないか）- サーバー側ログで、失敗が消えたか／どの認証が使われたかを確認する
再発防止：Server 2008 R2 を使い続けるリスクと移行の考え方
Windows Server 2008 R2 は世代が古く、クライアント OS がセキュリティ強化されるたびに、今回のような「昔は通ったのに、最近は通らない」が起きやすい土台になります。短期的にはポリシー調整で凌げても、次の観点で詰まりがちです。
- NTLM を許可し続けると、監査・攻撃耐性の面で不利になりやすい
- クライアント更新（Windows 10 の機能更新、Windows 11 移行など）で要件が変わる
- 共有そのものは動いていても、周辺（署名、暗号、管理ツール）が追従しなくなる
根本対策としては、サーバー更改（新しい Windows Server への移行、NAS/クラウドストレージへの移行など）を検討し、アクセスは 名前（FQDN）を前提 に設計していくのが安全です。移行時は、先に「共有の入口」を固定化（DFS、共有名の統一、ショートカット配布）しておくと、サーバーの入れ替えがスムーズになります。
まとめ：最短で直すなら「名前指定統一」、IP 必須なら「NTLM 方針を限定的に調整」
- IP アドレス指定の SMB は NTLM になりやすく、Windows 10 の NTLM 制限・LMCompatibilityLevel と衝突すると失敗しやすい
- セキュリティを落とさずに解決するなら、まずは サーバー名（できれば FQDN）指定に統一する
- IP 指定が不可避なら、対象を絞って「LAN Manager 認証レベル」「NTLM の送信制限」を確認し、ログで根拠を取りながら調整する
- 再発防止には、共有の入口を名前で固定化し、サーバー更改計画も合わせて進める
「どこを変えればいいか」よりも、「なぜ IP だとダメになるのか」を理解しておくと、次の OS 更新やサーバー移行でも同じ事故を避けられます。まずは現状のアクセス経路（IP/名前の混在）を棚卸しし、運用から整えるところが最短ルートです。
参考：設定項目名で探すときのキーワード
公式ドキュメントを確認したい場合は、次のキーワードで Microsoft Learn を検索すると該当ページに辿り着きやすいです。
- Network security: LAN Manager authentication level
- LMCompatibilityLevel
- Restrict NTLM: Outgoing NTLM traffic to remote servers
コメント