SQLNCLI10でTLS 1.2接続が失敗する原因とMSOLEDBSQL 19への移行
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
SQLNCLI10(SQL Server Native Client 10.0)は古い世代のドライバーで、TLS 1.2 接続には OS 側とドライバー側の対応が揃っている必要があります。サーバーで TLS 1.0/1.1 を無効化すると接続できなくなるのが典型です。現行の推奨は Microsoft OLE DB Driver(MSOLEDBSQL19)への移行ですが、19 系は既定が `Encrypt=yes` のため、証明書を信頼できない環境では従来の接続が失敗します。
この文書の適用条件
| 対象製品 | SQL Server 各版 / Amazon RDS for SQL Server(クライアント側 OLE DB ドライバー) |
|---|---|
| 確認バージョン | 要確認(TLS 1.2 対応に必要な更新プログラムの適用ビルドは製品・OS ごとに異なります) |
| 適用環境 | オンプレミス、EC2、Amazon RDS、Azure(クライアントは Windows) |
| 必要権限 | サーバー側の版数確認は接続権限。接続状態の確認は VIEW SERVER STATE。クライアント側のドライバー導入とレジストリ確認は管理者権限 |
| 実行影響 | 確認系は参照のみ。ドライバーの入れ替えと TLS 設定の変更はクライアント/サーバーの全接続に影響します |
| 再起動 | OS の TLS 設定変更やドライバー入れ替えでは、アプリケーションまたは OS の再起動が必要になる場合があります |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- SQL Server 2008 以降 / Amazon RDS for SQL Server
- 権限
- 対象インスタンスへの接続権限
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象インスタンスへの接続権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
@@VERSION AS version_string,
SERVERPROPERTY('ProductVersion') AS product_version,
SERVERPROPERTY('ProductLevel') AS product_level,
SERVERPROPERTY('ProductUpdateLevel') AS product_update_level, -- 版によっては NULL
SERVERPROPERTY('Edition') AS edition,
SERVERPROPERTY('MachineName') AS machine_name;TLS 1.2 に対応するために必要な更新プログラムは、SQL Server の版と OS ごとに異なります。ここで取得したビルド番号を、ベンダーが公開している TLS 1.2 サポート情報と突き合わせて判断してください。本記事では特定の KB 番号やビルド番号は記載しません。`ProductUpdateLevel` は古い版では NULL を返します。
- 対象
- SQL Server 2008 以降 / Amazon RDS for SQL Server
- 権限
- VIEW SERVER STATE
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: VIEW SERVER STATE
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
c.session_id,
s.login_name,
s.host_name,
s.program_name,
s.client_interface_name, -- 使用中のクライアントライブラリ
s.client_version,
c.net_transport,
c.protocol_type,
c.protocol_version,
c.encrypt_option, -- TRUE なら接続が暗号化されている
c.auth_scheme,
c.client_net_address,
c.connect_time
FROM sys.dm_exec_connections AS c
INNER JOIN sys.dm_exec_sessions AS s
ON c.session_id = s.session_id
WHERE s.is_user_process = 1
ORDER BY c.connect_time DESC;移行前に「実際にどのクライアントライブラリで、いくつの接続が来ているか」を把握するためのクエリです。`client_interface_name` と `program_name` から、まだ古いドライバーを使っているアプリケーションを洗い出せます。`encrypt_option` は暗号化の有無を示しますが、TLS のバージョンまでは返しません。
- 対象
- Windows クライアント(OLE DB 接続)
- 権限
- アプリケーション構成の変更権限
- 変更作業
- あり(接続の暗号化と証明書検証の挙動が変わる)
- Production実行
- 検証環境で確認したうえで、変更管理の手順に従うこと
-- 対象: Windows クライアント(OLE DB 接続)
-- 権限: アプリケーション構成の変更権限
-- 変更作業: あり(暗号化と証明書検証の挙動が変わる)
-- Production 実行: 検証環境での確認と変更管理の手順が前提
-- 1) 移行前(SQL Server Native Client 10.0 / 非推奨)
Provider=SQLNCLI10;Data Source=192.0.2.10,1433;Initial Catalog=SampleDB;User ID=sample_user;Password=********;
-- 2) 移行後(Microsoft OLE DB Driver 19 / 既定で Encrypt=yes)
Provider=MSOLEDBSQL19;Data Source=192.0.2.10,1433;Initial Catalog=SampleDB;User ID=sample_user;Password=********;Encrypt=yes;TrustServerCertificate=no;
-- 3) サーバー証明書を信頼できない場合の暫定回避(検証を弱めるため恒久運用には使わない)
Provider=MSOLEDBSQL19;Data Source=192.0.2.10,1433;Initial Catalog=SampleDB;User ID=sample_user;Password=********;Encrypt=yes;TrustServerCertificate=yes;
-- 4) 18 系以前の MSOLEDBSQL(既定は Encrypt=no のため従来の接続文字列がそのまま動く)
Provider=MSOLEDBSQL;Data Source=192.0.2.10,1433;Initial Catalog=SampleDB;User ID=sample_user;Password=********;MSOLEDBSQL 19 では既定が `Encrypt=yes` に変わりました。そのため、以前は暗号化なしで接続できていた構成が、ドライバーを 19 に入れ替えただけで証明書検証エラーになります。恒久的な解決はサーバーに信頼できる証明書を配置することで、`TrustServerCertificate=yes` はサーバー証明書の検証を省く暫定回避です。中間者攻撃に対する保護が弱まるため、期限を切って使ってください。
- 対象
- Windows クライアント
- 権限
- レジストリの参照権限(環境により管理者権限)
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
# 対象: Windows クライアント
# 権限: レジストリの参照権限(環境により管理者権限)
# 変更作業: なし(参照のみ)
# Production 実行: 可能
# インストール済みの SQL Server クライアントドライバーを一覧する
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object {
$_.DisplayName -like '*SQL Server*Native Client*' -or
$_.DisplayName -like '*OLE DB Driver*for SQL Server*'
} |
Select-Object DisplayName, DisplayVersion |
Sort-Object DisplayName
# OS の SCHANNEL プロトコル設定を参照する(変更はしない)
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -Recurse |
ForEach-Object {
[PSCustomObject]@{
Path = $_.Name
Settings = (Get-ItemProperty -Path $_.PSPath | Select-Object Enabled, DisabledByDefault)
}
}ドライバーのバージョンと、OS 側で TLS 1.0 / 1.1 / 1.2 のどれが有効かを確認します。SCHANNEL のレジストリ値の変更は OS 全体の通信に影響し、再起動も必要になるため、この手順では参照のみを行います。設定に該当キーが存在しない場合、OS の既定動作が適用されます。
- 対象
- Windows クライアント(OLE DB 接続)
- 権限
- テスト用の接続情報
- 変更作業
- なし(接続テストのみ)
- Production実行
- 可能(テスト接続のみ)
-- 対象: Windows クライアント(OLE DB 接続)
-- 権限: テスト用の接続情報
-- 変更作業: なし(接続テストのみ)
-- Production 実行: 可能(テスト接続のみ)
-- .udl ファイルや接続テストツールで、以下の3パターンを順に試して切り分ける
-- A) 暗号化なし : Encrypt=no
-- B) 暗号化あり・検証あり: Encrypt=yes;TrustServerCertificate=no
-- C) 暗号化あり・検証なし: Encrypt=yes;TrustServerCertificate=yes
-- A が成功し B が失敗 → 証明書の問題(サーバー証明書またはクライアントの信頼ストア)
-- A も B も失敗 → TLS バージョンまたはドライバー側の問題
-- B が失敗し C が成功 → サーバー証明書が信頼されていない(恒久対策は証明書の是正)3パターンの成否の組み合わせで、原因が「証明書」なのか「TLS バージョン/ドライバー」なのかを短時間で切り分けられます。C が成功したからといって C のまま運用しないでください。あくまで原因特定のための確認です。
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| product_version | SQL Server のビルド番号 | ベンダーの TLS 1.2 サポート情報と突き合わせ、必要な更新が適用済みかを判断する |
| product_level | サービスパックレベル | 古いサービスパックのままだと TLS 1.2 対応の更新が入っていない可能性がある |
| client_interface_name | 接続に使われているクライアントライブラリ名 | SQLNCLI 系が残っていれば移行対象。件数とアプリケーションを洗い出す |
| program_name | 接続元アプリケーション名 | 移行対象アプリケーションの特定に使う |
| encrypt_option | 接続が暗号化されているか | TRUE なら暗号化済み。ただし TLS のバージョンまでは分からない |
| protocol_version | TDS プロトコルのバージョン | 極端に古い値なら旧世代のクライアントが接続している |
| client_net_address | 接続元アドレス | どのサーバーから旧ドライバーで接続しているかを特定する |
| DisplayName / DisplayVersion(クライアント) | 導入済みドライバー名とバージョン | SQLNCLI10 / SQLNCLI11 が残っていないか、MSOLEDBSQL の世代はいくつか |
こういう状況で使います
- サーバー側で TLS 1.0 / 1.1 を無効化した直後から、特定のアプリケーションだけ接続できなくなった
- 「既存の接続はリモート ホストに強制的に切断されました」といった通信断のエラーが出る
- ドライバーを MSOLEDBSQL 19 に入れ替えたら、今まで動いていた接続文字列で証明書エラーが出るようになった
- SQL Server 2008 世代のクライアントから、新しく構築した AWS 上のインスタンスに接続できない
- 同じサーバーに、新しいクライアントからは接続できるが古いクライアントからは接続できない
考えられる原因(可能性の高い順)
01
SQLNCLI10 が TLS 1.2 に対応していない
SQL Server Native Client 10.0 は TLS 1.2 が一般化する前の世代のドライバーです。TLS 1.2 での接続には OS 側と製品側の対応が揃っている必要があり、環境によっては対応する更新プログラムを適用しても要件を満たさない場合があります。適用可否は対象環境とベンダーのサポート情報で確認してください。
02
サーバーまたは OS 側で TLS 1.0 / 1.1 が無効化された
セキュリティ要件で旧プロトコルを無効化すると、それしか話せないクライアントは接続できなくなります。無効化のタイミングと接続不能になったタイミングが一致していれば、この原因が濃厚です。
03
MSOLEDBSQL 19 で既定が Encrypt=yes に変わった
ドライバー 19 系では接続文字列の既定が暗号化ありに変更されています。サーバー証明書が信頼されていない環境では、接続文字列を変えていなくてもドライバー入れ替えだけで失敗するようになります。
04
サーバー証明書が信頼されていない
自己署名証明書、ホスト名と証明書のサブジェクトの不一致、証明書チェーンの未配置などが該当します。`Encrypt=yes;TrustServerCertificate=no` で失敗し、`TrustServerCertificate=yes` で成功する場合はこの原因です。
05
SQL Server 側に TLS 1.2 対応の更新が適用されていない
古い版の SQL Server では、TLS 1.2 を扱うために該当する更新プログラムの適用が必要です。適用対象のビルドは製品ごとに異なるため、`SELECT @@VERSION` で取得したビルド番号をベンダーのサポート情報と突き合わせて判断してください。
06
.NET やその他のクライアントスタック側の設定
OLE DB ドライバーではなくアプリケーションフレームワーク側で使用プロトコルが固定されている場合があります。ドライバーを更新しても解消しないときは、クライアントスタック側の設定も確認対象です。
確認手順
- 1
サーバー側の版数とビルドを取得する
参照のみ`SELECT @@VERSION` と `SERVERPROPERTY` の結果を控え、ベンダーの TLS 1.2 サポート情報と突き合わせます。
- 2
接続中のクライアントライブラリを洗い出す
参照のみ`sys.dm_exec_connections` と `sys.dm_exec_sessions` で `client_interface_name` を確認し、旧ドライバーからの接続を特定します。
- 3
クライアント側の導入済みドライバーを確認する
参照のみSQLNCLI10 / SQLNCLI11 / MSOLEDBSQL の各世代のうち、どれが入っているかを確認します。
- 4
OS の SCHANNEL 設定を参照する
参照のみTLS 1.0 / 1.1 / 1.2 の有効・無効状態を確認します。参照のみで、変更はこの段階では行いません。
- 5
暗号化の有無を変えて接続テストする
低`Encrypt=no` / `Encrypt=yes;TrustServerCertificate=no` / `Encrypt=yes;TrustServerCertificate=yes` の3パターンで成否を比較し、原因が証明書か TLS かを切り分けます。
- 6
変更履歴と発生時期を突き合わせる
参照のみサーバー側のプロトコル無効化、ドライバーの入れ替え、証明書の更新のいずれかと、接続不能になった時期が一致していないかを確認します。
対応方法
すぐに実施できる低リスクの対応
接続テストで原因を証明書か TLS かに絞る
低3パターンのテストで切り分けます。対処の方向がまったく異なるため、この切り分けを先に済ませてください。
暫定的に `TrustServerCertificate=yes` で接続を回復させる
中原因が証明書であることが確認できた場合の一時対応です。サーバー証明書の検証を省くため保護が弱まります。期限と恒久対策の予定を決めたうえで使ってください。
事前検討が必要な変更
MSOLEDBSQL(現行世代)へ移行する
中SQL Server Native Client は新規開発に推奨されていません。現行の Microsoft OLE DB Driver for SQL Server へ移行します。19 系は既定が `Encrypt=yes` のため、接続文字列の見直しをセットで行ってください。
サーバーに信頼できる証明書を配置する
中証明書のサブジェクトと接続時のホスト名を一致させ、証明書チェーンをクライアント側の信頼ストアに配置します。`TrustServerCertificate=no` のまま接続できる状態が恒久的な解決です。
SQL Server と OS に必要な更新を適用する
高TLS 1.2 対応に必要な更新プログラムは製品と OS ごとに異なります。ビルド番号をベンダーのサポート情報と突き合わせ、適用計画を立ててください。適用には再起動が伴います。
接続元アプリケーションの棚卸しを行う
参照のみ`client_interface_name` の集計から、まだ旧ドライバーを使っているアプリケーションを一覧化し、移行順序を決めます。
再起動・サービス影響を伴う変更
OS の TLS プロトコル設定を変更する
専門家レビュー必須SCHANNEL のレジストリ変更は OS 全体の通信に影響し、再起動が必要です。SQL Server 以外の通信も同時に変わるため、サーバー全体の影響評価を前提とします。
旧クライアントを支えるための一時的な互換構成
専門家レビュー必須移行が間に合わない場合に旧プロトコルを残す判断は、セキュリティ要件との調整が必要です。期限と代替策を明示したうえで、承認を得て実施してください。
!注意事項
- TLS 1.2 対応に必要な更新プログラムの適用ビルドは、SQL Server の版と OS ごとに異なります。本記事では特定の KB 番号やビルド番号を記載していません。`SELECT @@VERSION` で取得したビルド番号を、ベンダーが公開しているサポート情報と突き合わせて判断してください。
- `TrustServerCertificate=yes` はサーバー証明書の検証を省略します。通信自体は暗号化されますが、接続先が正当なサーバーであることの確認が行われません。恒久的な設定として残さないでください。
- MSOLEDBSQL 19 は既定が `Encrypt=yes` です。ドライバーを入れ替えるだけで、接続文字列を変更していなくても既存の接続が失敗する可能性があります。入れ替え前に検証環境で確認してください。
- SQL Server Native Client(SQLNCLI / SQLNCLI11)は新規開発向けに推奨されていません。既存システムでも、更新の提供状況を確認したうえで移行計画を立ててください。
- OS の SCHANNEL 設定変更は、SQL Server 以外を含むサーバー全体の通信に影響し、再起動が必要になります。データベース単独の判断で実施しないでください。
- 接続文字列にパスワードを直接記述する場合、構成ファイルの管理方法(アクセス権、暗号化)も併せて見直してください。
バージョン・環境による違い
これで解決しない場合に確認すること
クライアント OS のパッチ適用状況
ドライバーだけでなく OS 側の TLS 実装にも更新が必要な場合があります。
アプリケーションフレームワーク側のプロトコル設定
.NET などでプロトコルが固定されていないかを確認します。ドライバー更新だけでは解消しないケースがあります。
ネットワーク経路上の機器
ロードバランサーやプロキシで TLS が終端されている場合、そこでのプロトコル設定も確認対象になります。
SQL Server エラーログの接続エラー
接続失敗時にサーバー側のログに記録が残っているかを確認し、クライアント到達前の切断かを見ます。
この文書の根拠と限界
製品の公式ドキュメントに基づく説明
SQL Server クライアントドライバーの世代(SQL Server Native Client と Microsoft OLE DB Driver for SQL Server)に関する公開情報、および `sys.dm_exec_connections` / `SERVERPROPERTY` の仕様に基づきます。TLS 1.2 対応に必要な更新プログラムの KB 番号や適用ビルドは製品・OS ごとに異なり、確実な情報を提示できないため意図的に記載していません。対象環境のビルド番号をベンダーのサポート情報と突き合わせて判断してください。
よくある質問
SQLNCLI10とMSOLEDBSQL19の違いは何ですか?
SQLNCLI10 は SQL Server 2008 世代の SQL Server Native Client で、新規開発向けには推奨されていません。MSOLEDBSQL19 は現行の Microsoft OLE DB Driver for SQL Server の 19 系で、既定が `Encrypt=yes` に変わっています。移行時は暗号化と証明書検証の既定動作の違いを必ず確認してください。
ドライバーを19に入れ替えたら接続できなくなったのはなぜですか?
MSOLEDBSQL 19 では接続文字列の既定が `Encrypt=yes` に変更されたためです。サーバー証明書が信頼されていない環境では、接続文字列を変えていなくても証明書検証で失敗します。恒久対策は信頼できる証明書の配置で、`TrustServerCertificate=yes` は暫定回避です。
TrustServerCertificate=yes にしても安全ですか?
通信自体は暗号化されますが、接続先が正当なサーバーであることの検証が省略されます。中間者攻撃に対する保護が弱まるため、恒久的な設定として残すべきではありません。原因特定と一時復旧のために、期限を切って使ってください。
Productionで実行できますか?
サーバー版数の確認、接続中クライアントの一覧、クライアント側のドライバー・レジストリ参照はすべて参照専用で本番環境で実行できます。接続文字列の変更、ドライバーの入れ替え、TLS 設定の変更はいずれも影響範囲が広く、検証環境での確認と変更管理の手順が前提です。
どの権限が必要ですか?
サーバー版数の確認には接続権限、接続一覧の取得には VIEW SERVER STATE が必要です。クライアント側のドライバー確認とレジストリ参照には管理者権限が必要になる場合があります。
結果をどう判断しますか?
`Encrypt=no` で接続できて `Encrypt=yes;TrustServerCertificate=no` で失敗するなら証明書側の問題、どちらも失敗するなら TLS バージョンまたはドライバー側の問題です。この2択にまず絞ってから、更新適用か証明書是正かを決めてください。
この文書がカバーする質問
- SQL Server 2008からAWS RDSに接続できない
- SQLNCLI10とMSOLEDBSQL19の違い
- TLS 1.2で接続できない
- ドライバー更新後に証明書エラーが出るようになった
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
ドライバーの世代交代は、通常は「今まで動いていたものが、ある日サーバー設定を変えた途端に止まる」という形で顕在化します。GIIP では接続中のクライアントライブラリを定期的に集計し、旧世代のドライバーからの接続が残っているシステムを一覧できる状態にしています。TLS 設定の変更やドライバーの入れ替えは影響範囲が広いため自動適用の対象外とし、影響を受けるアプリケーションの洗い出しと移行順序の整理までを担当しています。
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
SQL ServerのLinked ServerでMsg 7356が発生する原因と確認方法
Msg 7356 は「コンパイル時と実行時で列のメタデータが食い違った」ことを示すエラーです。原因の切り分けとパススルークエリによる回避手順を整理します。
database-migration3TB規模のデータベースを移行するときの計画の立て方
3TB級の移行計画は、サイズの実測、切り替え方式の選択、試験実行による所要時間の実測、検証と切り戻しの設計、の順で組み立てます。目安値ではなく実測値で日程を引くための手順です。
awsAWS RDSで大きいインスタンス1台と小さいインスタンス複数台に分ける場合の違い
RDSのサイジングで「大きい1台」と「小さい複数台」を比べるときの技術的な差分と、決める前に測るべきCloudWatch指標を整理した文書です。
monitoringサーバーとデータベースを24時間監視するときに設定する項目
24時間監視を設計する際の監視対象・しきい値の考え方・エスカレーション体制・外形監視の必要性を、層ごとに整理したチェックリストです。
関連サービス
レガシー接続ドライバの移行計画を相談する
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
レガシー接続ドライバの移行計画を相談する