2026年7月14日以降のWindowsセキュリティ更新を適用した直後から、VPNクライアントや通信フィルター製品だけが接続できなくなった場合、原因として確認したいのが「未登録の第三者製TDIトランスポート」です。
Windowsは2026年7月更新でTDIの登録要件を強制するセキュリティ強化を導入しました。登録されていないTDIトランスポートは、ソケット通信に使用できなくなります。一方、正しく登録されたTDIトランスポートは影響を受けません。まずシステムイベントログのAFDイベントID 16003を確認し、恒久対応として製品ベンダーが提供する対応版ドライバーを適用します。Microsoftはレジストリによる公式の一時回避策も公開していますが、検証を無効化するため、恒久運用には向きません。(マイクロソフトサポート)
結論：未登録TDIをWindowsがブロックするようになったことが原因
今回の通信停止は、Windowsの一般的なTCP/IP通信が壊れたというより、特定製品が利用している第三者製TDIトランスポートだけが新しい検証に通らなくなった現象です。
対応の優先順位は次のとおりです。
- システムイベントログでAFDイベントID 16003を確認する
- イベントに表示されたドライバー名から対象製品を特定する
- 製品ベンダーの対応版ソフトウェアまたはドライバーを適用する
- 業務影響が大きい場合だけ、公式レジストリ設定で一時的に通信を許可する
- 対応版の適用後、検証レベルを既定値の「2」に戻す
単にWindows Updateをアンインストールして終わらせるのは適切ではありません。この制約は2026年7月14日以降に公開されるセキュリティ更新に含まれるため、将来の累積更新でも再び影響を受ける可能性があります。(マイクロソフトサポート)
TDIとは何か
TDIは「Transport Driver Interface」の略称で、アプリケーションのネットワーク通信を支える従来型のWindowsドライバーインターフェースです。
Microsoftの説明では、ソケットはアプリケーションがネットワーク通信に利用する接続の端点であり、TDIトランスポートは、その通信を下層で処理するドライバーにあたります。VPN、通信制御、Webフィルターなどの一部の旧型製品では、この仕組みに依存している場合があります。(マイクロソフトサポート)
「未登録」はドライバー署名の問題ではない
ここでいう「登録」は、ドライバーのデジタル署名、Windowsへのインストール、製品ライセンスの登録とは異なります。
TDIトランスポート側が、作成したデバイスオブジェクトをTDIインターフェースに通知するため、ドライバー内部から登録処理を実行する必要があります。Microsoftの旧TDIドキュメントでは、トランスポートがデバイスオブジェクトを作成した後にTdiRegisterDeviceObjectを呼び出す必要があると説明されています。(Microsoft Learn)
したがって、利用者が設定画面やレジストリ操作でトランスポートそのものを「登録済み」に変更することはできません。恒久修正には、製品ベンダーによるドライバーの修正が必要です。
なぜ更新前は動いていたのか
TDIトランスポートの登録は、以前から仕様上必要でした。しかし、2026年7月更新より前のWindowsでは、未登録のトランスポートに対する要件が強制されていませんでした。
2026年7月14日以降のセキュリティ更新では、信頼できないTDIトランスポートをセキュリティ上のリスクとして扱い、未登録トランスポートを既定でブロックするようになりました。つまり、以前から仕様に適合していなかったドライバーが、セキュリティ強化を契機に動作しなくなったと考えると分かりやすいでしょう。(マイクロソフトサポート)
対象となるWindows 11のバージョンと更新プログラム
Windows 11では、2026年7月14日に公開された次のセキュリティ更新からTDI登録要件の強制が導入されています。(マイクロソフトサポート)
| Windows 11バージョン | 初回対象更新 | 更新後のOSビルド |
|---|---|---|
| Windows 11 26H1 | KB5101649 | 28000.2525 |
| Windows 11 25H2 | KB5101650 | 26200.8875 |
| Windows 11 24H2 | KB5101650 | 26100.8875 |
| Windows 11 23H2 | KB5099414 | 22631.7376 |
上表は変更が最初に導入された更新です。後続の累積更新は以前の変更を含むため、上記KBが更新履歴に直接表示されていない端末でも、2026年7月14日以降の更新を適用していれば影響する可能性があります。
なお、MicrosoftのKB5106257はWindows 11だけでなく、一部のWindows 10 LTSC・ESU環境や、Windows Server 2016、2019、2022、2025なども対象として掲載しています。複数のWindows世代で同じネットワーク製品を利用している組織は、Windows 11端末だけに限定せず確認が必要です。(マイクロソフトサポート)
KB5106257とKB5101650の違い
KB番号が複数あるため、役割を整理しておきましょう。
| 識別子 | 役割 |
|---|---|
| KB5106257 | 未登録TDIトランスポートの影響、確認方法、回避策を説明するサポート情報 |
| KB5101650 | Windows 11 24H2・25H2向けの2026年7月セキュリティ更新 |
| KB5101649 | Windows 11 26H1向けの2026年7月セキュリティ更新 |
| KB5099414 | Windows 11 23H2向けの2026年7月セキュリティ更新 |
KB5106257は端末にインストールする修正プログラムではありません。そのため、更新履歴やGet-HotFixでKB5106257を検索しても、通常はインストール済み更新としては表示されません。
実際に端末へ配信されるのはKB5101650、KB5101649、KB5099414などの累積更新です。
影響を受けているか確認する手順
Windowsのバージョンと更新履歴を確認する
最初に、対象端末へ2026年7月14日以降のセキュリティ更新が適用されているか確認します。
「設定」から確認する場合は、次の順に開きます。
設定 → Windows Update → 更新の履歴
OSバージョンとビルドは、Windowsキー + Rを押し、次のコマンドを実行すると確認できます。
winverPowerShellから初回対象KBを検索する場合は、管理者権限で次を実行します。
Get-HotFix -Id KB5101650,KB5101649,KB5099414 -ErrorAction SilentlyContinueただし、後続の累積更新によって置き換えられている場合があります。コマンドで対象KBが見つからなくても、更新日とOSビルドを合わせて確認してください。
イベントID 16003を確認する
Microsoftが示している最も明確な判定方法は、システムイベントログの確認です。
イベントビューアーで、次の場所を開きます。
イベント ビューアー → Windows ログ → システム
AFDのイベントID 16003があり、メッセージに次の内容が表示されていれば、未登録TDIトランスポートが検出されています。
An unregistered TDI provider (\Driver<Name>) was detected<Name>の部分には、検出されたドライバーを識別する名前が表示されます。Microsoftによると、このイベントは再起動サイクルごとに1件だけ記録されます。接続を何度失敗させてもイベント件数が増えるとは限らないため、件数だけで発生回数を判断しないでください。(マイクロソフトサポート)
PowerShellでは、次のコマンドでイベントID 16003を抽出できます。
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Id = 16003
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, ProviderName, Id, Message複数のプロバイダーが同じイベントIDを使う可能性があるため、IDだけでなく、メッセージに「unregistered TDI provider」が含まれていることまで確認します。
ドライバー名から製品を特定する
イベントに表示された\Driver\<Name>を手掛かりに、次の情報を確認します。
- インストールされているVPN、Webフィルター、通信監視、プロキシ、エンドポイント保護製品
- 製品のバージョンとドライバーバージョン
- Windowsサービスとカーネルドライバーの表示名
- 製品ベンダーが公開している2026年7月更新への対応情報
- 同じ製品を使用している未更新端末との比較
ドライバーオブジェクト名と製品名が一致しないこともあります。名前だけで削除せず、ファイルのデジタル署名や発行元、製品ベンダーの回答まで確認してください。
症状だけでTDI問題と決めつけない
更新後のネットワーク障害には、DNS、ルーティング、プロキシ、NICドライバーなど別の原因もあります。
| 症状 | TDI制約の可能性 | 次に確認すること |
|---|---|---|
| 特定のVPNやフィルター製品だけ通信不能 | 高い | イベントID 16003、対象ドライバー |
| 製品を停止すると通常通信できる | 高い | ベンダーの対応版ドライバー |
| Wi-Fiや有線LAN自体が接続できない | 低い | NIC、IPアドレス、DHCP、デバイスマネージャー |
| VPN接続は完了するが名前解決だけ失敗 | 中程度 | VPN配布DNS、NRPT、プロキシ、ルーティング |
| ブラウザーだけ通信できない | 中程度 | Webフィルター、証明書、プロキシ設定 |
| イベントID 16003が見つからない | 要追加調査 | 製品ログ、Windowsファイアウォール、DNS、経路 |
| 登録済みTDIを使用している | 低い | TDI以外の互換性問題 |
イベントID 16003がない状態で、予防的に検証レベルを下げるのは避けてください。原因が別にある場合、問題を解決できないままセキュリティだけを弱めることになります。
恒久対応は製品ベンダーの対応版ドライバーを適用すること
最も安全な対応は、未登録TDIトランスポートを正しく登録するよう修正された製品バージョンへ更新することです。
利用者側では、製品ベンダーへ次の情報を伝えると確認が進みやすくなります。
- Windows 11のバージョンとOSビルド
- 適用済みの累積更新KB
- 障害が始まった日時
- イベントID 16003の全文
- イベントに表示された
\Driver\<Name> - VPN接続、Web閲覧、業務アプリなど影響する通信
- 製品を停止またはアンインストールした場合の変化
- 対応版ドライバーの有無と公開予定
製品ベンダーには、単に「Windows Update後につながらない」と伝えるのではなく、「2026年7月14日以降のTDI登録要件強制に対応しているか」と具体的に確認することが重要です。
登録済みTDIトランスポートは影響を受けないため、ベンダーから対応版が提供されれば、Windows側の検証を無効化せずに通信を復旧できます。(マイクロソフトサポート)
Microsoft公式の一時回避策
対応版ドライバーがまだ提供されておらず、業務継続のため一時的に通信を復旧させる必要がある場合、MicrosoftはTDI検証レベルをレジストリで変更する方法を案内しています。
設定場所は次のとおりです。(マイクロソフトサポート)
| 項目 | 設定内容 |
|---|---|
| レジストリキー | HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters |
| 値の名前 | AfdTdiUnknownProviderValidationLevel |
| 種類 | REG_DWORD |
指定できる値は次の4種類です。
| 値 | 動作 | 運用上の位置付け |
| -: | ————————— | —————– |
| 0 | 検証を完全に無効化し、未登録TDIを無視する | 原則として避ける |
| 1 | 未登録TDIをログに記録するが、ブロックしない | 緊急時の一時回避候補 |
| 2 | 未登録TDIをログに記録し、ブロックする | 既定値・通常運用 |
| 3 | すべてのTDIプロバイダーをログに記録し、ブロックする | 強い制限。通常の回避策には使わない |
Microsoftは、値を0または1へ下げるとシステムが脆弱な状態になるとして、検証レベルを2以上に保ち、影響する第三者製TDIトランスポートを更新または置き換えることを推奨しています。(マイクロソフトサポート)
現在の値を確認する
管理者権限のWindows Terminal、コマンドプロンプト、またはPowerShellで次を実行します。
reg query "HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters" /v AfdTdiUnknownProviderValidationLevel値が存在しない場合でも、Microsoftが示す既定動作は「2：未登録TDIをブロック」です。
一時的に値を1へ変更する
未登録TDIをログに残しながら一時的に許可する場合は、次を実行します。
reg add "HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters" /v AfdTdiUnknownProviderValidationLevel /t REG_DWORD /d 1 /f値0はログも残らず、原因追跡が難しくなります。製品ベンダーから明示的な指示がない限り、緊急回避では値1の方が管理しやすいでしょう。
対応版の適用後に値を2へ戻す
ベンダーの対応版ドライバーを適用したら、次のコマンドで既定のブロック動作へ戻します。
reg add "HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters" /v AfdTdiUnknownProviderValidationLevel /t REG_DWORD /d 2 /f設定変更後に必要となる製品サービスの再起動やWindowsの再起動については、対象製品のベンダー手順に従ってください。
一時回避を安全に運用するための条件
検証レベルを下げる場合は、単に全端末へ配布するのではなく、例外管理として扱います。
最低限、次の条件を決めてから実施してください。
- イベントID 16003を確認できた端末だけを対象にする
- 値1を適用する理由と承認者を記録する
- 適用した端末、日時、製品バージョンを記録する
- 対応版ドライバーの確認期限を決める
- 値2へ戻す予定日を設定する
- 対応版適用後にVPN、DNS、Web閲覧、業務システムを再試験する
- 値2へ戻した後、イベントID 16003と通信状態を再確認する
Intune、グループポリシー、構成管理ツールなどでレジストリを配布する場合も、全Windows端末を対象にするのではなく、問題のある製品とバージョンが導入された端末グループへ限定します。
更新プログラムのアンインストールを第一選択にしない理由
更新プログラムを削除すると、一時的に旧動作へ戻る可能性はあります。しかし、2026年7月更新にはセキュリティ修正が含まれ、TDI登録要件の強制も意図的なセキュリティ強化として導入されています。さらに、この変更は2026年7月14日以降の更新に継続して含まれます。(マイクロソフトサポート)
そのため、アンインストールだけでは次回更新時に同じ問題が再発します。
推奨される考え方は次のとおりです。
| 対応 | 評価 |
|---|---|
| 製品ベンダーの対応版を適用 | 最優先の恒久対応 |
| 値1で一時的に許可 | 業務継続が必要な場合の期限付き対応 |
| Windows Updateを延期 | 事前検証期間を確保する用途に限定 |
| 更新プログラムをアンインストール | 緊急時の最終手段。恒久対応にはならない |
| 値0を全端末へ配布 | セキュリティと追跡性の面から避ける |
更新ページで「既知の問題なし」と表示される理由
KB5101650、KB5101649、KB5099414の更新ページでは、TDIに関する変更がネットワークのセキュリティ強化として説明されています。一方、各ページの「既知の問題」欄では、Microsoftが把握している問題はないとされています。(マイクロソフトサポート)
これは矛盾ではありません。
未登録TDIのブロックは、更新によって偶発的に発生した不具合ではなく、以前から必要だった登録要件を意図的に強制する仕様変更だからです。互換性への影響はありますが、Windows側では設計どおりのセキュリティ動作として扱われています。
そのため、「既知の問題なし」と表示されていることだけを理由に、Windows Updateとの関連を否定しないよう注意してください。
企業での更新展開前に確認したいポイント
VPNやフィルター製品を全社展開している場合は、Windows更新の検証項目にTDIを加える必要があります。
パイロット端末で実通信を確認する
単にWindowsへログインできることだけでなく、次の通信を確認します。
- VPN接続と切断
- VPN経由のDNS名前解決
- 社内Webシステムへの接続
- インターネット閲覧
- プロキシ認証
- ファイルサーバーへの接続
- RDPや業務クライアントの通信
- WebフィルターやURL分類
- 製品の自動更新と管理サーバー通信
イベントID 16003を集中監視する
Windows Event ForwardingやSIEMを使用している場合は、システムログのイベントID 16003を収集対象に加えると、利用者から問い合わせが来る前に未登録TDIを検出できます。
ただし、イベントは再起動サイクルごとに1件のみ記録されます。イベント数を通信失敗回数として集計せず、端末数とドライバー名を軸に分析してください。(マイクロソフトサポート)
ベンダーへTDI依存の有無を確認する
TDI自体は非推奨の技術であり、Microsoftは用途に応じてWinsock KernelまたはWindows Filtering Platformへの移行を案内しています。(Microsoft Learn)
製品の更新可否を判断するときは、今回の修正だけでなく、次の点もベンダーへ確認するとよいでしょう。
- 現行版がTDIに依存しているか
- TDIトランスポートを正しく登録しているか
- WFPまたはWSKへ移行する計画があるか
- 今後のWindows機能更新に対応する予定があるか
- サポート終了バージョンを使用していないか
古いTDIドライバーをレジストリ回避で使い続けるより、対応版への更新や製品更改まで含めて検討する方が、次のWindowsセキュリティ強化に対応しやすくなります。
よくある疑問
すべてのVPN製品が影響を受けるのか
すべてのVPN製品が影響を受けるわけではありません。
対象になるのは、ソケット通信に未登録の第三者製TDIトランスポートを使用している製品です。登録済みTDI、またはTDI以外の方式を使用する製品は、この制約による影響を受けません。(マイクロソフトサポート)
Windows標準のネットワーク通信も止まるのか
通常は、問題のTDIトランスポートを経由する通信だけが影響します。
たとえば、VPN経由の通信だけが止まり、VPNを使用しないインターネット接続は動作するケースが考えられます。ただし、製品が全通信を強制的にフィルターしている場合は、見かけ上すべての通信が停止することもあります。
レジストリ値を1のまま運用してよいのか
恒久運用は推奨されません。
値1では未登録TDIがブロックされなくなるため、通信は復旧してもセキュリティ強化が無効になります。対応版を適用するまでの期限付き例外とし、最終的には値2へ戻してください。(マイクロソフトサポート)
次のWindows Updateで自動的に直るのか
Windows側の更新だけで直るとは限りません。
Microsoftが示している恒久対応は、影響する第三者製TDIトランスポートを、正しく登録するバージョンへ更新または置き換えることです。製品ベンダーの対応状況を確認する必要があります。(マイクロソフトサポート)
まずイベントID 16003を確認し、対応版へ更新する
2026年7月14日以降のWindows更新後に、VPNやフィルター製品だけ通信できなくなった場合は、未登録TDIトランスポートのブロックを疑います。
最初にイベントビューアーのシステムログでAFDイベントID 16003を確認してください。該当イベントがあれば、表示されたドライバー名を製品ベンダーへ伝え、対応版ドライバーを入手します。
業務停止を避けるため一時回避が必要な場合は、AfdTdiUnknownProviderValidationLevelを値1へ変更する方法があります。ただし、これは検証を無効化する期限付き対応です。対応版を適用した後は値2へ戻し、通信テストとイベントログの再確認まで実施してください。
コメント