Azure Data Factory（ADF）で Azure-SSIS Integration Runtime（IR）上の SSIS パッケージを実行したときに、TLS バージョンのエラーが散発的に発生する原因と対処を、運用目線で整理した記事です。同じパッケージが Visual Studio 2022 からは安定して動くのに、ADF だとときどきコケる……という、現場でよくある「再現しそうで再現しない」不具合の考え方と、恒久対策までを解説します。
Azure Data Factory での SSIS 実行で発生する TLS エラーとは
典型的なエラーメッセージ
本記事で扱うのは、次のようなメッセージで SSIS 実行が失敗するケースです。
- 「クライアントの TLS バージョンがサーバーの最小許容バージョンより低いためログインに失敗しました」
- 英語環境の場合：
Login failed because the client's TLS version is lower than the minimum version allowed by the server.
ポイントは次の 3 つです。
- Azure Data Factory（ADF）のパイプラインから Azure-SSIS IR 上で SSIS パッケージを実行するときに発生
- 接続先は多くの場合 Azure SQL Database / Azure SQL Managed Instance / SQL Server
- 「毎回」ではなく「ときどき」失敗する散発的な現象
Visual Studio では正常に動く理由
同じパッケージを Visual Studio 2022（開発機）から実行すると、ほぼ問題なく成功するという報告が多くあります。これは、開発機と Azure-SSIS IR で、次のような差があるためです。
- 開発機は最新の Windows / .NET / SQL クライアントドライバーが入っており、既定で TLS 1.2 を話す
- ADF 側（Azure-SSIS IR）は、利用しているイメージやノードによっては TLS 1.0/1.1 を優先的に使用することがある
- サーバー側（Azure SQL など）は「最低 TLS バージョン = 1.2」に設定されているケースが多い
つまり、開発機は TLS1.2 で接続 → 成功 / 一部の IR ノードは TLS1.0/1.1 で接続しようとして失敗というパターンです。
TLS エラーが「散発的」に起きる主な理由
原因の俯瞰
まず、現象と原因候補をざっくり把握するために、要点を表にまとめます。
| 現象 | 主な原因候補 | どんなときに起こりやすいか | チェックの入口 |
|---|---|---|---|
| 実行のたびに成功/失敗が揺れる | IR ノード間の OS / ドライバー / TLS 設定の差 | IR をスケールアウト（ノード複数）している | 一時的にノード数を 1 にして挙動を確認 |
| あるパッケージだけ頻繁に失敗 | 接続マネージャーで古いドライバー使用 | SQL Native Client（SQLNCLI）などを使用 | 接続マネージャーの Provider / Driver 名を確認 |
| Visual Studio では安定動作 | 開発機と IR で TLS 既定値が異なる | 開発機は最新 .NET / OS、IR は古い | OS / .NET バージョンと TLS 既定値を比較 |
| 接続先変更後に急に失敗し始めた | サーバー側で最小 TLS バージョンが 1.2 に引き上げ | Azure SQL / SQL Server 側ポリシー変更 | Azure ポータル / レジストリ等でサーバー設定確認 |
IR ノード間のバージョン差（スケールアウト時）
Azure-SSIS IR を 2 ノード以上でスケールアウトしている場合、ノードごとに次のような差が生まれていることがあります。
- Windows の累積更新パッチ適用状況
- インストールされている SQL クライアントドライバーのバージョン
- レジストリでの TLS / 暗号スイート設定
その結果として、
- ノード A：MSOLEDBSQL 18 + 強い暗号設定 → TLS 1.2 で接続し成功
- ノード B：旧 SQL Native Client + デフォルト設定 → TLS 1.0 を提案して拒否され失敗
ADF の実行は、どのノードにアサインされるかを明示的に指定できないため、「たまたま B ノードに当たったときだけ TLS エラーになる」という散発的な挙動に見えます。
古い SQL クライアント／ドライバーを使っている
SSIS の接続マネージャーでは、OLE DB / ODBC / ADO.NET など複数の接続方式を選択できますが、古いプロジェクトほど、次のようなドライバーを使い続けているケースが多いです。
- SQL Native Client（SQLNCLI、SQLNCLI11 など）
- 旧 OLE DB Provider for SQL Server
これらのドライバーは、TLS 1.2 への対応が不完全だったり、OS レベルの設定に強く依存したりするため、TLS 1.2 を必須にしたサーバー環境では不安定になりがちです。
.NET / OS の TLS 既定値の違い
Visual Studio 実行と ADF 実行で挙動が分かれる大きな理由のひとつが、.NET と OS の TLS 既定値の違いです。
- Visual Studio 実行時：
- 開発機の Windows は比較的新しく、TLS 1.2 が既定で有効
- .NET Framework / .NET のバージョンも新しく、TLS 1.2 を優先して使用
- Azure-SSIS IR 実行時：
- IR のベースイメージが古く、TLS 1.0/1.1 も有効化されている
- SSL/TLS のネゴシエーションで、TLS 1.0/1.1 を優先的に提案する場合がある
サーバー側が「最低 TLS バージョン 1.2」を要求していると、IR 側が TLS 1.0/1.1 を提案した時点で接続が拒否され、「クライアントの TLS バージョンが低い」というエラーとして現れます。
サーバー側の最小 TLS バージョン設定
Azure SQL Database / Azure SQL Managed Instance やオンプレミスの SQL Server では、セキュリティ強化のために「許可する TLS の最小バージョン」を 1.1 → 1.2 へと引き上げることが一般的になっています。
このタイミングで、以下のようなことが起こり得ます。
- 開発機や一部の IR ノードは TLS 1.2 を使うので問題ない
- 一部の IR ノードや古いドライバーだけが TLS 1.0/1.1 を使おうとして弾かれる
このように、クライアント側のばらつき + サーバーの最小 TLS 1.2 設定が組み合わさると、「環境を変えていないのに、ある日を境に散発的なエラーが出始める」という状況が発生します。
実務で使えるチェックリスト：原因切り分けの手順
ステップ別の切り分け方
現場ですぐに試せる切り分け手順を、目的別に整理します。
| ステップ | 目的 | 具体的なアクション | 想定される結果 |
|---|---|---|---|
| 1 | ノード差分の有無を確認 | IR のノード数を一時的に 1 にしてパイプラインを数回実行 | エラーが消える場合、ノード間の差異が濃厚 |
| 2 | ドライバーの種類を確認 | SSIS プロジェクトの接続マネージャーを開き、Provider / Driver 名を確認 | SQLNCLI などの旧ドライバー使用が判明することが多い |
| 3 | サーバー側の TLS 設定確認 | Azure ポータルや SQL Server の設定で「最小 TLS バージョン」を確認 | 1.2 もしくはそれ以上に設定されているかを把握 |
| 4 | Visual Studio との差分把握 | 開発機で使用しているドライバー / .NET / OS バージョンを確認 | IR 側との差分（古いドライバーなど）が見つかる |
| 5 | ログで詳細情報を取得 | SSIS ログ（OnError / OnWarning）、ADF のアクティビティ出力を詳細化 | どのノード・どのドライバーで接続しているかを把握 |
即効性の高い対処（優先度高）
接続マネージャーのドライバーを更新する
まず検討すべきは、SSIS パッケージの接続マネージャーで使用しているドライバーの更新です。推奨パターンは次の通りです。
| 接続種別 | 推奨ドライバー | ポイント |
|---|---|---|
| OLE DB | Microsoft OLE DB Driver for SQL Server（MSOLEDBSQL 18 / 19） | TLS 1.2 サポートが良く、今後の標準 |
| ODBC | ODBC Driver 18 for SQL Server | 暗号化オプションが細かく指定可能 |
| ADO.NET | .NET Framework 4.7 以降の System.Data.SqlClient | .NET 側で TLS 1.2 を既定として動作させやすい |
古い SQLNCLI や SQL Server Native Client を使っている場合は、可能な限り MSOLEDBSQL か ODBC 18 へ移行することを強く推奨します。
接続文字列の暗号化オプションを見直す
接続文字列の暗号化オプションも、TLS エラーに大きく関わります。推奨される設定例は次の通りです。
OLE DB（MSOLEDBSQL）の例
Provider=MSOLEDBSQL;
Data Source=xxxxx.database.windows.net;
Initial Catalog=SampleDb;
User ID=xxx;Password=yyy;
Encrypt=Yes;
TrustServerCertificate=False;
ODBC Driver 18 の例
Driver=ODBC Driver 18 for SQL Server;
Server=tcp:xxxxx.database.windows.net,1433;
Database=SampleDb;
Uid=xxx;Pwd=yyy;
Encrypt=Yes;
TrustServerCertificate=No;
Encrypt=Yes：クラウド環境では必須と考えてよいTrustServerCertificate=False：本番では False が原則
検証環境では一時的な切り分け目的で TrustServerCertificate=True を使うこともありますが、本番にそのまま持ち込まないよう注意してください（証明書検証をスキップするため、セキュリティリスクになります）。
Azure-SSIS IR を最新イメージで再デプロイ / 更新
IR 自体が古いイメージやパッチレベルで動いている場合、OS レベルの TLS 設定や暗号スイートが古く、TLS 1.2 との相性が悪くなることがあります。そのため、次のような対応が有効です。
- Azure ポータルから IR を一度停止し、再起動して最新のイメージ / パッチを取り込む
- 場合によっては IR を新規作成し、カスタムセットアップを整理したうえで再構築する
特にスケールアウトしている場合は、全ノードが同じバージョン・同じセットアップ手順で構築されていることを確認することが重要です。
サーバー側の TLS 設定を確認する
「サーバーの最小 TLS バージョン」を変更するのは最終手段ですが、現状を把握しておくことは必須です。
- Azure SQL Database / Managed Instance：Azure ポータルから「最小 TLS バージョン」を確認
- オンプレミス SQL Server：レジストリやグループポリシー、SQL Server 構成で TLS の設定を確認
方針としては、サーバー側は 1.2 以上を維持したまま、クライアント（IR）側をそれに合わせるのがセキュリティ的に正攻法です。
実行環境を標準化して再発を防ぐ
IR カスタムセットアップで TLS 1.2 / ドライバーを強制
Azure-SSIS IR には「カスタムセットアップ」機能があり、ノード起動時に任意のスクリプトを実行できます。ここに以下の内容を組み込むことで、「どのノードでも同じ TLS / ドライバーバージョン」を保証できます。
- MSOLEDBSQL 18 / 19 や ODBC Driver 18 の MSI 配布・インストール
- レジストリ設定により TLS 1.2 / 強い暗号のみを既定として使用
- 必要なルート証明書 / 中間証明書の登録
レジストリの設定例（概念イメージ）
※実際の値は環境要件に合わせて調整してください。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001 これにより、.NET アプリケーション（SSIS の一部コンポーネントを含む）が強い暗号と TLS 1.2 を優先して使用するようになります。
証明書ストア / ルート CA を整備する
本番環境では TrustServerCertificate=False を前提にするべきなので、IR ノードの証明書ストアに次が揃っていることを確認します。
- 接続先 SQL サーバー証明書の発行元ルート CA
- 必要な中間 CA 証明書
これらが正しくインストールされていないと、「証明書の検証に失敗 → TLS エラーと区別がつきにくいエラー」が発生することがあります。TLS バージョンエラーと似たログになることも多いため、証明書系のエラーかどうかもログで確認しておきましょう。
ログと監視で「どのノードで何が起きたか」を見える化
単一ノードでの再現確認
前述の通り、スケールアウトしている場合は、まず IR のノード数を 1 にして挙動を見るのが手っ取り早い切り分けです。
- ノード数 1 でエラーが再現しない → ノードごとの差分が原因の可能性が高い
- ノード数 1 でもエラーが出る → 共通のドライバー設定やサーバー側設定が怪しい
SSIS ログの詳細化
SSIS のログでは、次のような情報を出力する設定をおすすめします。
- OnError / OnWarning の詳細メッセージ
- 接続試行時に使用される接続文字列（パスワードなどはマスク）
- 接続マネージャー名・種類（OLE DB / ODBC / ADO.NET など）
これにより、どの接続マネージャーが TLS エラーを起こしているのか、接続文字列の Encrypt / TrustServerCertificate 設定がどうなっているかを正確に追うことができます。
ADF（パイプライン）のアクティビティ出力
ADF 側のパイプライン実行結果でも、次の点を意識してログを確認します。
- どの Azure-SSIS IR で実行されたか
- （必要に応じて）IR ノード名をログに書き出すカスタムロジック
- 実行のたびにノードが変わっていないかどうか
ノード名をログに含めておくと、「エラーが出たときはいつも同じノードを使っている」といったパターンが簡単に見えるようになります。
なぜ Visual Studio 2022 だと問題なく動くのか
開発機と IR の違いを分解する
「VS だと動くのに ADF だと落ちる」という現象は、心理的には「ADF の不具合」に見えますが、実態は次のような「環境差」です。
| 項目 | Visual Studio（開発機） | Azure-SSIS IR（ADF 実行） |
|---|---|---|
| OS | 最新の Windows 10 / 11 など | IR 作成時のイメージ依存（古い場合あり） |
| .NET / ランタイム | 最新 .NET 4.8 相当が入っていることが多い | イメージ次第では TLS 既定値が古い |
| SQL ドライバー | MSOLEDBSQL / ODBC 18 などをインストール済み | デフォルトで SQLNCLI が残っているケースも |
| TLS 既定バージョン | TLS 1.2 を優先（1.0/1.1 を無効化している環境も多い） | TLS 1.0/1.1 が有効で、TLS 1.2 が優先されない場合がある |
この差分が積み上がった結果として、
- VS 実行：TLS 1.2 でサクッと接続 → 成功
- ADF 実行：一部ノードが TLS 1.0/1.1 を提案 → サーバーに拒否される → 散発的な失敗
という挙動に見えているだけです。
実際に取られた対策とその効果
典型的な解決パターン
実際の現場や Q&A で解決済みとされているパターンを整理すると、次のような流れになることが多いです。
- SSIS の接続マネージャーで MSOLEDBSQL 18/19 または ODBC Driver 18 を使用するよう変更
- 接続文字列で
Encrypt=Yes,TrustServerCertificate=Falseを明示 - Azure-SSIS IR を最新のイメージで再構築、または停止→再起動
- IR カスタムセットアップで、すべてのノードに同じドライバー / TLS 設定を強制
- 単一ノード構成で再実行し、エラーが出ないことを確認
- スケールアウト（ノード増加）しても再発しないことを確認し、本番適用
この手順で、散発的な TLS エラーはほぼ解消されるケースが多く、運用側としても「再現しない不具合」との長期戦を避けることができます。
運用に貼っておける「短いまとめ」
最後に、運用チーム向けに要点だけを抜き出した「貼り紙用まとめ」を掲載します。手順書や Jira チケットのテンプレートなどにも流用しやすい形にしています。
症状
- ADF の Azure-SSIS IR で SSIS パッケージを実行すると、「クライアント TLS が最小許容未満」エラーで散発的に失敗する。
- 同じパッケージを Visual Studio 2022 から実行すると、ほぼ問題なく成功する。
主な原因
- IR ノードの OS / ドライバー / TLS 設定の差により、ノードごとに使用する TLS バージョンが異なる
- 旧式ドライバー（SQL Native Client など）により、TLS 1.0/1.1 で接続しようとして拒否される
- サーバー側の「最小 TLS バージョン = 1.2」設定にクライアントが追従できていない
対処のポイント
- ドライバー更新：
- OLE DB：Microsoft OLE DB Driver for SQL Server（MSOLEDBSQL 18/19）へ変更
- ODBC：ODBC Driver 18 for SQL Server を使用
- 接続文字列の見直し：
Encrypt=Yes,TrustServerCertificate=Falseを基本設定とする
- IR の最新化と標準化：
- Azure-SSIS IR を最新イメージで再デプロイ / 再起動
- カスタムセットアップで MSOLEDBSQL / ODBC18 インストールと TLS1.2 を強制
- スケールアウトする場合は、全ノード同一セットアップを徹底する
- 切り分けとログ：
- 一時的に IR を単一ノードにして再現性を確認
- SSIS と ADF のログでノード名・ドライバー名を記録し、ノード差分を可視化
この流れで対処すれば、「VS では動くのに ADF だけときどき落ちる」というやっかいな TLS エラーも、原因を言語化・再現しやすくなり、かつ再発防止策まで含めて整理できます。Azure Data Factory で SSIS を本番運用する際には、「TLS / ドライバー / IR 標準化」をセットで設計・レビューするのがおすすめです。
コメント