Windows Server 2019＋SQL Server 2022／SSIS 2022環境で、Attunity CDC Control Task（CDC Source / CDC Splitter）を含むSSISパッケージが、実行時にアセンブリ読み込みエラー（0x80131040）で失敗するケースがあります。開発環境では問題なく見えても、本番サーバー実行だけ落ちるときの「最短復旧手順」と「中長期の設計見直しポイント」をまとめます。
症状：SSIS 2022でAttunity CDC Control Task実行時に落ちる
よくある状況は次のとおりです。
| 項目 | 内容（例） |
|---|---|
| OS | Windows Server 2019 |
| DB／SSIS | SQL Server 2022／SSIS 2022（Integration Services） |
| 開発 | SSIS デザイナ（Visual Studio）上で CDC コンポーネントを配置できる |
| ビルド／デプロイ | 成功する（ispac作成、SSISDBへの配置も可能） |
| 実行 | SQL Server 2022 上の SSIS 実行時だけ失敗 |
典型的なエラー要約は、次のような形です。
| エラーの要点 | 例 |
|---|---|
| Validate メソッド失敗 | パッケージ検証段階で落ちる／タスク初期化で落ちる |
| アセンブリ読み込み失敗 | Could not load file or assembly ‘Microsoft.SqlServer.DtsMsg, Version=16.100.0.0 …’ |
| 強名アセンブリの不一致 | The located assembly’s manifest definition does not match the assembly reference. (0x80131040) |
まず理解したい：0x80131040（マニフェスト定義が一致しない）の意味
0x80131040 は、.NET の「強名（Strong Name）付きアセンブリの参照情報」と「実際にロードされたアセンブリ」が一致しないときに出やすい例外です。ざっくり言うと、SSIS 実行時に次のような“食い違い”が起きています。
- パッケージ（またはタスク）が「AというDLLのこのバージョン」を要求する
- 実行環境では「別のバージョンのA」や「別の場所のA」が見つかってしまう
- 結果として、強名（Version / PublicKeyToken など）の一致判定で弾かれて失敗する
この手のエラーが厄介なのは、SSIS デザイナ上でコンポーネントを配置できても「実行サーバー側に同じ前提（同じランタイム、同じ修正レベル）が揃っている」とは限らない点です。つまり、見た目では気づきにくい“実行時依存”の問題として表面化しがちです。
原因の切り分け：このエラーで多い3パターン
パターンA：SQL Server 2022（SSIS）側の既知不具合に該当している
今回のエラーメッセージは、実は SQL Server 2022 の累積更新プログラム（CU）で“同じ文字列”を名指しで修正対象にしているものがあります。SQL Server 2022 の CU1（KB5022375）の修正一覧に、CDC Control task 実行時の次のエラーを修正した旨が記載されています。
- Could not load file or assembly ‘Microsoft.SqlServer.DtsMsg, Version=16.100.0.0 …’
- The located assembly’s manifest definition does not match the assembly reference. (0x80131040)
「ツールボックスにある／ビルドできるのに、サーバー実行だけ落ちる」という状況は、この CU で修正された既知不具合の“典型的な見え方”に一致します。まずは、SSIS を実行しているサーバーの SQL Server 2022 が CU1 以上（できれば最新CU）になっているかを確認するのが最短ルートです。
パターンB：ドキュメント上のサポート範囲外で、互換性が揺れている
SSIS の CDC Flow Components（CDC Control Task / CDC Source / CDC Splitter）のドキュメントでは、サポートされる SQL Server バージョンとして SQL Server 2012～2017が記載されています。また、OS も Windows Server 2016 までの記載になっており、Windows Server 2019 や SQL Server 2022 は明記されていません。
さらに Microsoft Q&A でも、同ドキュメントを根拠に「SQL Server 2022 では（少なくとも当時）サポートされていないようだ」というやり取りが残っています。
このため、仮に CU 適用で動いたとしても、運用としては次のリスクが残ります。
- 想定外の更新で再発する（“動いていたのに急に落ちる”の温床）
- 環境差（OS/ランタイム差、実行アカウント差、権限差）が原因切り分けを難しくする
- サポート判断（問い合わせ時の前提）が曖昧になりやすい
パターンC：実行環境の“揃っていなさ”（サーバー側の構成差・修正レベル差）
同じ SQL Server 2022 でも、「開発マシン」と「実行サーバー」で以下がズレるとアセンブリ問題が起きやすくなります。
- 実行サーバー側の SSIS が未更新（DBエンジンだけ更新して SSIS が置き去り、など）
- 複数の SQL Server/SSIS バージョンが同居していて、ロード経路が想定と違う
- 過去に手動で DLL をコピーした／GAC に入れた履歴があり、別バージョンが優先される
- SQL Server Agent ジョブや実行アカウントの違いで、参照パス・権限が変わる
特に本番でありがちなのが「DB エンジンは最新CUだが、SSIS を載せている別サーバーが未更新」というパターンです。SSIS 実行サーバーが別筐体の場合、そこも同じ CU レベルまで更新しないと直りません。
最短で復旧する：SQL Server 2022 を CU1以降（推奨：最新CU）に更新する
このエラーに対して、まず優先したいのは “SSIS 実行サーバーの SQL Server 2022 更新” です。理由は明確で、CU1 の修正一覧に同じエラー文面が含まれているためです。
手順1：実行サーバーのビルド／更新状況を確認する
SQL Server のバージョン確認は、まずは次のような T-SQL で十分です。
SELECT
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('Edition') AS Edition;
ここで重要なのは「SSIS を実行しているサーバー」で確認することです（開発端末の確認ではありません）。
手順2：最新CUを適用し、SSIS サービスを再起動する
CU 適用後は、SSIS（SQL Server Integration Services）のサービス再起動もセットで行います。ドキュメントでも、CDC コンポーネント導入後に SSIS サービス再起動が必要である旨が案内されています。
再起動の例（環境によりサービス名は異なる場合があります）。
# 管理者権限の PowerShell で
Get-Service *Integration* | Format-Table -AutoSize Name, Status, DisplayName
# サービス再起動（例）
Restart-Service -Name "MsDtsServer160" -Force
ポイントは、CU を当てるだけでなく「SSIS 実行プロセスが新しいバイナリを読み直す状態」にすることです（再起動やサーバー再起動を挟む）。
手順3：同じパッケージで再実行し、エラーが消えるか確認する
再実行時は、できれば次の条件で切り分けをシンプルにします。
- 同じサーバー上で、同じ実行経路（SQL Agent / SSISDB / dtexec 等）で比較する
- エラーが消えたら、まずは “CU の修正で直った” と判断して良い
- 消えない場合は、次の「チェックリスト」に移る
CU適用後も直らない場合のチェックリスト
CU1 以降で直ることが多い一方で、環境の混在や構成差があると別原因が残ることがあります。以下の順で確認すると、迷子になりにくいです。
| チェック項目 | 見るべきポイント | 補足 |
|---|---|---|
| SSIS を実行しているサーバーはどれか | SSISDB のあるDBサーバーとは限らない | SSISが別サーバーなら、そのサーバーにCUを当てる |
| 複数バージョンの同居 | SQL Server/SSIS の複数世代が同じサーバーに入っていないか | 参照先DLLが想定外の世代になると不整合が起きやすい |
| 手動DLL配置の履歴 | GAC やフォルダに古いDLLが残っていないか | “その場しのぎ”でコピーしたDLLが後で足を引っ張る |
| 実行経路の違い | SSISDB実行／SQL Agent／dtexec のどれで落ちるか | 経路によって実行アカウント・権限・参照パスが変わる |
| 権限 | CDC対象DBの読み取り・状態テーブル書き込み権限 | “Validateで落ちる”場合、接続・権限が原因のこともある |
アセンブリ不整合は「やれることが多そうに見えて、やってはいけないことも多い」タイプの問題です。特に、DLL の手動コピーや、強引な置き換えは再発率が上がりやすいため、まずは CU 適用と構成差の解消（混在排除）から着手するのが安全です。
“サポート上どうなの？”に答える：SSISのAttunity CDCコンポーネントはDeprecated
ここが最も重要な論点です。SSIS の CDC Flow Components（CDC Control Task / CDC Source / CDC Splitter）は、ドキュメント上でDeprecated（非推奨）として扱われています。加えて Microsoft は、Attunity の CDC 関連機能について2025年12月13日でサポートを終了する旨を告知しています。
実務的に、このアナウンスが意味するのは次のことです。
- 新規案件では採用しない方が良い（長期運用の前提が崩れる）
- 既存資産は「延命しながら移行計画を立てる」フェーズに入っている
- “動くかどうか”よりも “いつまで運用できるか” を先に決めるべき
今回のエラーは CU で改善する可能性が高い一方、将来に向けた安心材料にはなりにくいのが現実です。短期復旧と中長期移行を同時に進めるのが、結局いちばん安いです。
短期回避策：どうしても今すぐ止められないときの現実解
「今日のバッチを回さないと困る」状況では、次のような二段構成が現場で取りやすい回避策です。
回避策1：CDC処理だけ旧環境に残し、結果だけ 2022 側に渡す
- SSIS 2017（または既に安定稼働している世代）で CDC を実行
- 差分結果（変更行）を中継DB・ファイル・キューなどで受け渡し
- SQL Server 2022 側では取り込み・マージだけを担当
ポイントは「問題の中心（Attunity CDC）を隔離する」ことです。障害が起きたときに影響範囲が限定され、復旧手順も単純になります。
回避策2：Attunity CDCコンポーネントを外し、SQL ServerのネイティブCDCを直接取りに行く
SSIS の CDC Source に依存せず、SQL Server の CDC 機能（変更テーブル）を通常のソース（OLE DB Source/ADO.NET Source等）で読んで取り込む設計に寄せる方法です。SQL Server の CDC はトランザクションログを元に変更を取り出し、SQL Server Agent が動作している必要があります。
設計のイメージは次のとおりです。
- SQL Server 側で CDC を有効化（DB／テーブル）
- 前回の LSN（または時間）を管理テーブルで保持
- 今回分の差分を CDC の関数／変更テーブルから抽出
- ターゲットへ MERGE（Upsert）やSCD処理
SSIS の専用CDCコンポーネントを使わないぶんパッケージは少し自前になりますが、互換性問題の爆発半径を小さくできます。
中長期対策：SQL Server 2022 世代での “変更取り込み” の選択肢
Attunity CDC コンポーネントからの移行を考えるなら、「要件（遅延、負荷、作りやすさ、監査）」を軸に整理すると選びやすいです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| SQL Server ネイティブ CDC | DBの変更を正確に追いたい／ETLで増分ロードしたい | SQL Server Agent 前提、運用（保持期間・クリーンアップ）設計が必要 |
| Change Tracking | 軽量に「変わった行」だけ取りたい／細かい監査が不要 | 保持・クリーンアップ、キー設計（主キー必須）など要件確認が必要 |
| Temporal Tables | 履歴テーブルで監査・差分分析もしたい | 保存容量・性能影響、運用の設計が必要 |
| 外部ETL／レプリケーション系 | 低遅延で横断的に同期したい／多DBやクラウド連携 | コスト、運用モデル、製品ロックインの確認が必要 |
「SSIS の中で完結させたい」か、「取り込みの責務を別レイヤーに出す」かで、将来の変更耐性が大きく変わります。今回のように特定コンポーネントの互換性でつまずいた場合、次のバージョンアップでも同じタイプの事故が起きやすいので、責務分離（CDC取得と変換/ロードを分ける）を意識するのが有効です。
実務での落とし穴：開発で動くのに本番で落ちる理由
今回の症状は、いわゆる「デザインタイムとランタイムの差」で説明できます。
- 開発PC：Visual Studio（SSIS プロジェクト拡張）上でコンポーネントが見える。配置・ビルド・デプロイはできる。
- 実行サーバー：SSIS の実体（サービスや実行エンジン）が読み込むDLLの組み合わせで動作が決まる。修正レベルがズレると、同じパッケージでも落ちる。
この構造を理解しておくと、次回以降のトラブルシュートがかなり速くなります。SSIS の「パッケージは同じでも、実行エンジンが違うと挙動が違う」という前提は、運用設計（更新手順、検証手順、ロールバック）に直結します。
まとめ：再発防止のために押さえるポイント
- 同じエラー文面は SQL Server 2022 CU1 の修正対象に含まれるため、まずは SSIS 実行サーバーを最新 CU へ更新する。
- SSIS の CDC Flow Components（Attunity）は Deprecated。さらに 2025年12月13日でサポート終了が告知されているため、中長期では置き換え前提で計画する。
- 「CDC取得（差分抽出）」と「変換・ロード」を分離し、特定コンポーネント依存を減らすと将来のアップグレードが楽になる。
コメント