Windows 10（1803）で「SMB Dialect 3.00 ではなく 2.10（SMB 2.1）で接続したい」と悩むことがあります。本記事では、Windows 標準機能での可否、原因の切り分け、そして現場で実際に効く回避策（相手側の設定・確認手順・安全面の注意）をまとめます。
Windows 10 1803 の SMB クライアントで Dialect 2.10 を強制できる？
最初に結論から整理します。
| やりたいこと | Windows 10（1803）標準機能だけで可能？ | 補足 |
|---|---|---|
| SMB Dialect 3.00 を避けて 2.10 のみを使う（2.10固定） | 不可 | SMB 2.x と SMB 3.x は Windows では同一スタックとして扱われ、設定も「SMB2/SMB3 をまとめて有効/無効」が基本です。 |
| SMB 3.x の“機能”を減らして相性問題を回避する | 一部可能 | Dialect 自体は変えられませんが、マルチチャネル等の機能を切って安定することがあります。 |
| 結果として SMB 2.10 で接続させる | 相手側次第で可能 | 相手側（NAS/Samba 等）で SMB3 を提示しない設定にすれば、交渉結果として SMB 2.10 になります。 |
| SMB1 に落とす | 可能（非推奨） | 安全性の問題が大きく、原則おすすめしません。どうしても必要なら隔離・短期間・限定用途で。 |
つまり「Windows 10 側で“SMB 2.10 だけ”を指定する」操作は用意されていません。実務では、相手側（NAS/サーバー側）を SMB2_10 までに制限するか、SMB3 の一部機能を抑制して不具合を回避する方向が王道になります。
SMB の「方言（Dialect）」とは何か
SMB は接続時に「どの方言（Dialect）で話すか」を交渉して決めます。ざっくり言えば、クライアントが対応している方言の一覧を提示し、サーバーがその中から採用する方言を選ぶ仕組みです。ここで“より新しい方言（数字が大きい方）”が選ばれるのが通常です。
| 表示上の Dialect | 一般的な呼び方 | イメージ | 代表的な特徴（概念） |
|---|---|---|---|
| 2.10 | SMB 2.1 | SMB2 系の成熟版 | SMB2 の改良（性能・安定性） |
| 3.00 | SMB 3.0 | SMB3 の初期世代 | 以降の世代で、マルチチャネルや暗号化など拡張が進む土台 |
| 3.02 / 3.1.1 | SMB 3.02 / SMB 3.1.1 | SMB3 の改良版 | セキュリティ・性能・管理性の改善（環境により差） |
質問の「2.10 を 3.00 より優先して使わせたい」は、この交渉の結果を意図的に“低い方言に固定”したい、という意味になります。しかし Windows の標準クライアントでは、交渉に出す方言のリストを任意に編集する手段が提供されていません。
なぜ Windows では SMB 2.10 だけを強制できないのか
ここが一番つまずきやすい点です。Windows では SMB 2.x と SMB 3.x が別物として分かれているのではなく、同じ実装（同じスタック）として統合されています。そのため設定も「SMB2/SMB3 を有効にするか、無効にするか」という粒度になりやすく、“SMB 3.00 だけ無効”のようなピンポイント制御ができません。
PowerShell の設定項目も、典型的には次のような形になります。
- SMB1：有効/無効を明確に切り替えできる
- SMB2：このスイッチに SMB3 も含まれて扱われる（SMB2/SMB3 をまとめて）
この仕様のため、Windows 10（1803）標準機能だけで「SMB2.10 のみ」を強制しようとすると、行き着く先は次のどちらかになります。
- SMB2/SMB3 を有効（＝SMB3 を避けられない）
- SMB2/SMB3 を無効（＝そもそも SMB2.10 も使えない）
この時点で「じゃあ SMB1 に落とせば…」という話が出てきますが、後述の通り SMB1 はセキュリティ上の理由で基本的に非推奨です。
まずは現状確認：本当に 3.00 でつながっているかをチェック
不具合対応で最初にやるべきは「今、どの Dialect で接続しているか」を正確に把握することです。SMB のトラブルは“方言の問題”に見えて、実は別の要因（名前解決、資格情報、キャッシュ、ネットワーク機能、NAS の不具合）が原因のこともよくあります。
PowerShell で Dialect を確認する
代表的な確認方法はこれです（管理者権限は必須ではないことが多いですが、環境によっては必要です）。
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted出力例（イメージ）:
ServerName ShareName Dialect Signed Encrypted
---------- --------- ------- ------ ---------
NAS01 share 3.00 True Falseこの Dialect が 3.00 になっているなら、「Windows が SMB3 でつないでいる」ことが確定します。もし 2.10 でつながっているなら、今回の“強制”はそもそも不要かもしれません。
接続し直して交渉をやり直す（キャッシュ対策）
SMB は一度つながると、セッションや資格情報、名前解決の結果が残っていて「設定を変えたのに挙動が変わらない」ことがあります。検証時は、いったん明示的に切断してから再接続すると切り分けが進みます。
net use * /delete /yその後、対象共有にアクセスし直し、再度 Get-SmbConnection で Dialect を確認します。
「SMB3 で不具合」に見えるケースで先に確認したいポイント
「SMB3 だとつながらない」「コピーが途中で止まる」「エクスプローラーが固まる」といった相談は、結果として SMB 3.00 で接続していることが多いものの、原因は Dialect そのものではなく、SMB3 で有効になりやすい“機能”や、NAS 側の実装不具合であることもあります。
| 症状 | よくある原因 | まず試すこと（安全寄り） |
|---|---|---|
| 接続はできるが転送が遅い/途中で止まる | NAS ファーム不具合、NIC オフロード、マルチチャネル相性、MTU/スイッチ問題 | NAS/ルーター/スイッチの更新、別ケーブル/別ポート、マルチチャネル無効化で比較 |
| 資格情報を求め続ける/認証がループ | 資格情報の衝突、同一サーバーへの別ユーザー接続、名前解決揺れ（FQDN/IP混在） | net use * /delete、資格情報マネージャー整理、接続先表記を統一 |
| 共有の一覧が出ない/参照が不安定 | SMB ブラウズ系の期待違い、古いNASのサービス依存、ネットワーク探索設定 | 共有名を直接指定（\\server\share）、DNS/WINS/LLMNRの整理 |
| 特定の大容量ファイルだけ失敗 | NAS のバグ、ストレージ側の不良、アンチウイルス/フィルタドライバ干渉 | 別PCでも再現確認、NAS のログ確認、ウイルス対策の除外（検証時のみ） |
この段階で重要なのは、「Dialect を 2.10 に落とす」以外にも現実的な改善策があるという点です。方言固定ができない以上、最短距離は「相手側の SMB3 を直す/出さない」「Windows 側の SMB3 機能を絞る」のどちらかになります。
実務的な回避策：相手側（サーバー/NAS）で SMB3 を出さない
Windows クライアントが交渉で高い Dialect を選ぶなら、逆転の発想で相手が SMB3 を提示しない状態にします。すると Windows は共通で使える範囲（例：SMB 2.10）に落ちます。
Samba サーバーなら「最大プロトコル」を SMB2_10 に制限できる
Samba（Linux/Unix 系）をサーバーとして使っている場合、smb.conf の設定で「server max protocol」を制限できるケースが多いです。代表例（考え方の例）:
[global]
server min protocol = SMB2_10
server max protocol = SMB2_10この設定を行うと、クライアントが SMB3 を話せても、サーバーが SMB2_10 までしか受け付けないため、交渉結果として SMB 2.10 で接続されます。NAS の中身が Samba の製品も多いので、GUI に「SMB2 のみ」「SMB3 を無効化」といった項目がある場合もあります。
注意点としては、SMB 2.10 に固定すると SMB3 系の利点（環境によっては性能やセキュリティ機能）が使えなくなるため、あくまで互換性確保のための選択として扱うのが現実的です。
NAS 製品は「SMB3 を無効化」「最大バージョン」を持っていることがある
NAS はメーカーごとに表記が異なりますが、次のような選択肢が用意されていることがあります。
- SMB の最大バージョン（例：SMB3/SMB2/SMB1）
- SMB3 のみ無効化（または SMB2 のみ有効）
- 「SMB2/SMB3」をまとめて ON/OFF（この場合は方言固定にはならない）
製品によっては「SMB2 を推奨」「SMB3 を推奨」といったガイダンスもありますが、今回の目的は“Windows 10 からの接続を SMB2.10 に寄せる”ことなので、NAS 側に最大プロトコルの設定があるかが最重要ポイントになります。
Windows サーバー同士では細かい「最大 Dialect 固定」が難しい
Windows の SMB サーバー機能も、クライアント同様に SMB2/SMB3 が統合的に扱われます。そのため、Windows サーバー側で「SMB 3.00 だけを落として SMB 2.10 は残す」という運用は取りづらいことが多いです。
この場合は次のどれかが現実解になりやすいです。
- 不具合の原因が SMB3 そのものではないか再点検し、修正する（更新、設定見直し）
- 接続経路を変える（別サーバーを経由させる、Samba をゲートウェイ化する）
- どうしても互換性が必要なら、相手を Samba/NAS 側に寄せて制御する
Windows 側でできること：Dialect は変えられないが「SMB3 の機能」を減らす
方言（Dialect）を 2.10 に固定できなくても、SMB3 で有効になりやすい機能がトラブルの引き金になっている場合、機能を抑制するだけで安定することがあります。特に「古いNAS」「NIC/スイッチの相性」「複数NIC搭載PC」で起きやすいです。
SMB マルチチャネルを無効化して比較する
SMB マルチチャネルは、複数のネットワーク経路を使って性能や耐障害性を上げる仕組みです。環境によってはこれが悪さをして、転送が不安定になることがあります。検証として、クライアント側で無効化して挙動が改善するか確認します。
# 現在の設定確認
Get-SmbClientConfiguration | Select-Object EnableMultiChannel, EnableSecuritySignature, RequireSecuritySignature
# マルチチャネル無効化（検証用）
Set-SmbClientConfiguration -EnableMultiChannel $false改善した場合は「Dialect 3.00 が問題」というより、SMB3 の機能（マルチチャネル）と環境の相性が原因だった可能性が高まります。恒久対応するなら、NAS の更新やネットワーク機器の見直しも合わせて検討すると再発しにくくなります。
署名（Signing）や暗号化（Encryption）の期待値を整理する
SMB の署名や暗号化はセキュリティ上重要です。一方で、相手機器が古かったり実装が弱かったりすると、署名必須が原因で接続できない・極端に遅いなどのケースもあり得ます。
ただし、ここは安全性とトレードオフになるため、次の順番で考えるのがおすすめです。
- まずは NAS/サーバー側の更新・設定見直しで解決を狙う
- 次に、検証目的でクライアント設定を変えて原因を特定する
- 恒久対応で設定を緩める場合は、ネットワーク分離やアクセス制限を必ずセットにする
クライアント設定の確認（例）:
Get-SmbClientConfiguration | Select-Object EnableSecuritySignature, RequireSecuritySignature設定変更は環境影響が大きいことがあるため、まずは「原因の切り分け」に限定して扱うのが安全です。
最終手段：SMB1 に落とすという選択肢とリスク
どうしても相手が SMB2/SMB3 のまともな実装になっておらず、かつ業務上つなぐ必要がある場合、極端な回避策として「SMB1 を有効化して SMB1 でつなぐ」ことが理屈としては可能です。しかし SMB1 は古く、セキュリティ上のリスクが非常に高いことで知られています。
この選択肢を検討するなら、次の“条件”を満たせない場合は避けた方がよいです。
- 対象機器・対象ネットワークを分離（隔離）できる
- 通信を必要最小限に絞れる（Firewall、共有権限、IP制限など）
- SMB1 を有効にするのは短期間・限定用途にできる（作業が終わったら戻す）
- 代替手段（SFTP/HTTPS/外付け媒体など）が本当に使えない
Windows 10 側で SMB1 を扱う場合、機能の有効/無効を切り替える運用になります（方法はいくつかあります）。例として PowerShell で Windows 機能を切り替えるイメージは次の通りです。
# SMB1 を有効化（非推奨。必要性とリスクを理解した上で）
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -All
# SMB1 を無効化（作業後は戻す）
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol繰り返しになりますが、これは「SMB 2.10 固定」の代替としても、セキュリティ面の代償が大きすぎることが多いです。恒久対応にするのではなく、相手側の更新計画（NAS 更改、ファーム更新、Samba 更新）を同時に立てることを強くおすすめします。
どうしても「SMB 2.10 固定」に近いことをしたい場合の現実解
Windows 10 の標準 SMB クライアントでは固定できない以上、現実的には次のいずれかです。
相手側を SMB2_10 までに制限する（最優先）
最もシンプルで再現性が高い方法です。NAS が対応しているなら GUI で「最大 SMB2」等に設定し、Samba なら server max protocol を設定します。これにより Windows 10 は交渉で SMB 2.10 を採用せざるを得なくなります。
中継（ゲートウェイ）を置く
どうしても相手側を変更できない場合、間に 1 台 “会話を翻訳する”役を置く考え方があります。例えば、Windows 10 からは通常の SMB3 で中継サーバー（Samba/Windows など）に接続し、中継サーバーから先を SMB 2.10 に制限する、といった構成です。
- Windows 10 →（SMB3）→ 中継サーバー
- 中継サーバー →（SMB2.10固定）→ 旧NAS/旧サーバー
ただし構築・運用コストがかかり、性能や障害点も増えます。恒久対策というより、移行期間のワークアラウンドとして検討するのが現実的です。
そもそも SMB 以外の転送方式に逃がす
用途が「ファイルを置く/取り出す」だけなら、SMB に固執せず別プロトコルに切り替える方が早いこともあります。
- SFTP（SSH）
- HTTPS を使ったファイル共有（WebDAV/製品機能）
- クラウドストレージ同期（OneDrive 等）
- オフライン搬送（外付け媒体）
特に「古いNASにだけ問題がある」場合、SMB の方言をいじるより、データの受け渡し経路を変える方が安全で確実なことも多いです。
トラブルシュートを短縮するチェックリスト
最後に、現場での調査を短時間で回すためのチェックリストを置いておきます。
| チェック項目 | 確認方法（例） | 狙い |
|---|---|---|
| Dialect を特定する | Get-SmbConnection | 「本当に 3.00 でつながっているか」を確定 |
| 接続のやり直し | net use * /delete → 再接続 | キャッシュや資格情報の影響を排除 |
| 相手側の SMB 設定 | NAS/Samba の最大プロトコル設定 | SMB3 を出さないことで SMB2.10 に落とす |
| SMB3 機能の相性 | マルチチャネル無効化で比較 | Dialect ではなく機能が原因か判定 |
| 更新状況 | NAS ファーム、Windows 更新、NIC ドライバ | 既知不具合の解消、互換性改善 |
| 最終手段の整理 | SMB1 の可否と隔離策、代替プロトコル | 業務継続と安全性を両立 |
まとめ：Windows 10 側で無理に固定せず、相手側と運用で解決する
Windows 10（1803）の SMB クライアントで「SMB Dialect 2.10 を 3.00 より優先して使わせる」ことは、Windows 標準機能だけではできません。SMB2/SMB3 が統合スタックで提供され、設定もまとめて有効/無効の粒度になっているためです。
一方で、現場で困りがちな「SMB3 で不具合」に対しては、解決の打ち手が複数あります。
- 相手側（NAS/Samba）で最大プロトコルを SMB2_10 に制限して、結果として SMB2.10 で接続させる
- Windows 側で SMB3 の機能（例：マルチチャネル）を抑制して相性問題を回避する
- どうしても難しい場合は、移行期間の中継構成や、SMB 以外の転送手段に逃がす
「方言固定」は魅力的に見えますが、根本は互換性と実装品質の問題であることが多いです。最短で安定運用に持ち込むなら、相手側の更新・設定見直しを軸に、Windows 側は確認と比較で原因を絞る、という順番が失敗しにくいです。
コメント