SSIS パッケージを Visual Studio 2019 から実行したときに「Integration Services evaluation period has expired. The package can only be executed in debug mode.」と表示され、テストが止まってしまうことがあります。本記事では、このエラーの正体と原因、そして開発用 PC で安全かつライセンス的に正しい SSIS 実行環境を整える具体的な手順を、SQL Server 2017＋Visual Studio 2019 環境を例にして詳しく解説します。
SSIS「Integration Services evaluation period has expired」エラーの症状
まずは問題のメッセージを再確認します。Visual Studio 2019 で SSIS プロジェクトを開き、パッケージを修正したあとに実行すると次のような警告が表示されます。
Integration Services evaluation period has expired.
The package can only be executed in debug mode.
日本語でざっくり言うと「Integration Services の評価期間が切れたので、デバッグ実行だけしかできません」という意味です。
よくある状況としては、次のような構成です。
- 開発用 PC：Windows 10 / 11 ＋ Visual Studio 2019 ＋ SSIS 拡張機能（SQL Server Integration Services Projects）
- サーバー：SQL Server 2017 Enterprise（正規ライセンス）＋ SSIS カタログ（SSISDB）
- 現象：PC 上で SSIS パッケージを「通常実行」しようとするとエラーが出るが、「開始（デバッグ）」なら動く
サーバー側の SQL Server は正規ライセンスなのに、なぜか開発 PC で評価版切れ扱いになる…というのがこのエラーのややこしいポイントです。
原因：開発 PC の SSIS ランタイムが評価版のまま期限切れ
このエラーの本当の原因は、開発 PC にインストールされている SSIS ランタイム（Integration Services 実行環境）が評価版のまま有効期限を過ぎている ことです。
ここで押さえておきたいポイントは次の 3 つです。
- Visual Studio の SSIS プロジェクト拡張機能は「設計ツール」
これは無償で使えますが、パッケージの 実行ライセンス とは別物です。 - パッケージの「通常実行」には SSIS ランタイムが必要
dtexec や SQL Server Agent、Visual Studio からの非デバッグ実行などは、ローカルにインストールされた SSIS ランタイムを使います。 - サーバーの SQL Server ライセンス ≠ 開発 PC の SSIS ライセンス
サーバー側が Enterprise であっても、そのライセンスが自動的に開発 PC に適用されるわけではありません。
評価版の SQL Server（もしくは SSIS コンポーネント）を開発 PC に入れて SSIS を試していた場合、その評価期間が切れたタイミングでこのエラーが発生します。
なぜ「デバッグ実行だけ」動くのか
メッセージにもある通り、評価期間が切れても「デバッグ実行」は許可されています。これは Visual Studio が内部的に SSIS ランタイムを特別なモードで呼び出しているためで、
- デバッグ実行：開発時限定の特殊な実行（ブレークポイント、変数ウォッチ等を利用）
- 通常実行：本番に近い実行方式（DTExec、SQL Server Agent などと同等の扱い）
という扱いの違いがあるためです。本番と同じ条件でテストしたい場合は、通常実行が必要なので、ここをどう解消するかがポイントになります。
前提整理：SSIS の設計と実行、ライセンスの関係
解決策に入る前に、SSIS の「設計」「実行」「ライセンス」の関係をざっくり整理しておきます。
| 役割 | 代表的なコンポーネント | 用途 | ライセンス上の位置づけ |
|---|---|---|---|
| 設計 | Visual Studio ＋ SSIS プロジェクト拡張 | パッケージの開発、編集、デバッグ | ツール自体は無償。実行ライセンスとは別 |
| ローカル実行 | SSIS ランタイム（Integration Services）、DTExec | PC 上でのテスト実行、検証 | SQL Server Developer / Standard / Enterprise 等のライセンスが必要 |
| サーバー実行 | SQL Server（SSISDB、SQL Server Agent） | 本番・検証環境でのパッケージ実行 | サーバー側 SQL Server のライセンスに従う |
さらに、SQL Server のエディションごとの位置づけも押さえておきましょう。
| エディション | 料金 | 用途 | SSIS 実行 |
|---|---|---|---|
| Evaluation | 無償（期間限定） | 評価、検証 | 期間終了後は今回のような制限がかかる |
| Developer | 無償 | 開発・テスト専用（本番利用不可） | Enterprise 相当の全機能を利用可能 |
| Standard / Enterprise | 有償 | 本番環境 | ライセンスに応じて SSIS を含む機能を使用可能 |
開発 PC で「正しく」SSIS を実行したい場合、Developer エディションを入れるか、製品版（Standard / Enterprise）のライセンスを割り当てる必要があります。
解決策の全体像：優先順位と選び方
よく使われる解決パターンを優先度順に並べると次のようになります。
| 優先度 | 解決策 | 特徴 | 向いているケース |
|---|---|---|---|
| 高 | Developer エディションを導入 | 無償でローカル実行が可能。本番利用不可 | 開発 PC で SSIS を頻繁に実行してテストしたい |
| 中 | 製品版キーでエディションを正規化 | 既存のライセンスを使って評価版から昇格 | 開発用にも Standard / Enterprise ライセンスを割り当てられる |
| 中 | サーバー側でのみ実行してテスト | PC には SSIS ランタイム不要。サーバーに集約 | 開発 PC に SQL Server を入れたくない、あるいはポリシー上禁止 |
| 補助 | 評価版のクリーンアップと動作確認 | 環境を整理し、バージョンや 32/64bit の食い違いを解消 | 上記いずれの方法を取る場合でも実施推奨 |
以下では、それぞれの方法をもう少し具体的な手順レベルで解説します。
解決策 1：Developer エディションでローカル SSIS を正規化（推奨）
最もおすすめなのが、開発 PC に SQL Server Developer エディション（2017 以上）をインストールし、Integration Services を有効にする 方法です。開発・検証目的に限れば無償で使え、機能的には Enterprise と同等なので、SSIS の開発には最適です。
Step 1：現在の SSIS / SQL Server の状態を確認
まず、開発 PC にどのバージョン・エディションの SQL Server / SSIS が入っているかを確認します。
- 「アプリと機能」（または「プログラムと機能」）を開く
- 「Microsoft SQL Server 2017」や「Integration Services」等の名前を探す
- エディション名（Evaluation / Developer / Standard / Enterprise など）をメモしておく
コマンドラインからも確認できます。
"C:\Program Files\Microsoft SQL Server\140\DTS\Binn\DTExec.exe" /version
出力に Evaluation と表示されていれば、評価版ランタイムが使われている状態です。見つからない場合は、インストール自体がされていないか、別バージョンの SQL Server が使われている可能性があります。
Step 2：評価版コンポーネントをアンインストール or アップグレード
すでに評価版の SQL Server / SSIS をインストールしている場合は、次のどちらかを選びます。
- アンインストールしてから Developer を新規インストール
- セットアップの「エディションのアップグレード」で Evaluation → Developer に切り替え
環境をシンプルに保ちたい場合は、アンインストールして入れ直す方がトラブルは少なくなります。
Step 3：Developer エディションをインストール（Integration Services を有効化）
SQL Server のセットアップを起動し、Developer エディションを選択してインストールします。その際、機能の選択画面で「Integration Services」を忘れずにチェックします。
- データベースエンジンは必須ではありませんが、ローカルテスト用に入れておくと便利です
- インスタンスはデフォルト（MSSQLSERVER）でも名前付きインスタンスでも構いません
インストール完了後、再度 DTExec /version を実行して、エディションが Developer になっていることを確認します。
Step 4：Visual Studio 側の設定確認
SSIS プロジェクトが Developer エディションの SSIS ランタイムに対して正しくビルドされるよう、Visual Studio 側の設定も確認しておきます。
- プロジェクト プロパティ → Configuration Properties → General → TargetServerVersion
SQL Server 2017 をターゲットにする場合は SQL Server 2017 を選択します。 - Project → Properties → Debugging → Run64BitRuntime
通常は True（64bit） で問題ありませんが、32bit のドライバーしかない場合は False にして 32bit で実行します。
ここまで設定すれば、Visual Studio からの「開始（デバッグ）」だけでなく、「パッケージの実行」や dtexec コマンドによる通常実行も、評価版エラーなしで動作するようになります。
解決策 2：製品版キーでエディションを正規化する
もし組織として Standard / Enterprise などのライセンスをすでに保有しており、開発用 PC にもライセンスを割り当てられる場合は、製品版キーを使って評価版や Developer からエディションを切り替えることもできます。
エディション変更の流れ
- SQL Server セットアップを起動
- 「メンテナンス」 または 「インストール」 メニューから 「エディションのアップグレード」 を選択
- 対象のインスタンスを選び、製品版のプロダクトキーを入力
- ライセンス条項に同意してウィザードを進める
アップグレード後に DTExec /version でエディションが変わっていることを確認します。
ただし、本番用ライセンスを安易に開発 PC に割り振ると、ライセンス監査の観点で問題になる場合があります。原則として、開発目的には Developer エディションを使う方が安全です。
解決策 3：ローカルではなくサーバー側で実行してテストする
「開発 PC には SQL Server をインストールしたくない」あるいは「社内ポリシーで禁止されている」という場合は、開発 PC はあくまで 設計専用にし、サーバー側でパッケージを実行してテストする方法が現実的です。
手順の概略
サーバー側で実行する基本的な流れは次の通りです。
- Visual Studio で SSIS パッケージを開発
- 「ビルド」して .ispac ファイルを生成
- SSIS カタログ（SSISDB）にデプロイ
- SQL Server Agent ジョブや
catalog.start_executionなどで実行
この方法では、実行に使われるランタイムはすべてサーバー側の SQL Server になるため、開発 PC 側に SSIS ランタイムのライセンスは不要です。
Visual Studio から直接 SSISDB にデプロイする例
- ソリューションエクスプローラーでプロジェクトを右クリックし、「配置」を選択
- サーバー名、SSIS カタログのパス（例：
SSISDB\プロジェクトフォルダー）を指定してウィザードを進める - デプロイ完了後、SQL Server Management Studio から SSISDB を確認
その後は、
- SSISDB のプロジェクト / パッケージを右クリックして「パッケージの実行」
- SQL Server Agent でジョブを作成し、「SQL Server Integration Services カタログ」「SSIS パッケージ」を指定
- T-SQL の
catalog.create_execution/catalog.start_executionを用いた自動化
といった方法で実行できます。
この方法のメリット・デメリット
| 項目 | メリット | デメリット |
|---|---|---|
| ライセンス | 開発 PC 側に SSIS ランタイム不要 | サーバー台数分のライセンスは別途必要 |
| セキュリティ | データはサーバー内で完結しやすい | 開発者にサーバーへの接続権限が必要 |
| 利便性 | 本番に非常に近い条件でテストできる | 簡単なテストでも毎回デプロイが必要 |
開発の初期段階では Developer エディションでローカル実行、リリース前の最終テストはサーバー実行、といった使い分けが現場ではよく採用されます。
解決策 4：クリーンアップと動作確認のチェックリスト
どの解決策を選ぶにしても、環境まわりを一度整理しておくと、後々のトラブルを防ぎやすくなります。チェックポイントをまとめておきます。
インストール済みコンポーネントの整理
- 「アプリと機能」で、不要になった評価版の SQL Server / SSIS コンポーネントを削除
- 古いバージョン（例：SQL Server 2012 / 2014）の SSIS が残っていないか確認
- 複数バージョンが必要な場合は、どのプロジェクトがどのバージョンを使うかを整理する
バージョン・エディションの確認
コマンドラインからバージョンとエディションを確認します。
DTExec /version
ここで表示される情報と、Visual Studio の TargetServerVersion が一致しているかを確認します。
32bit / 64bit 実行の確認
SSIS は 32bit / 64bit どちらでも動作しますが、利用するドライバーによっては片方にしか対応していない場合があります。
- ODBC / OLE DB ドライバーがどちらのビット数でインストールされているかを確認
- Visual Studio プロジェクトの Run64BitRuntime 設定をドライバーに合わせて変更
例えば、32bit 版の Excel ドライバーしかない状態で 64bit 実行すると接続エラーとなるため、その場合は Run64BitRuntime を False にする必要があります。
よくある勘違い・ハマりポイント
「Visual Studio の SSIS 拡張が入っていれば実行できる」は誤解
Visual Studio の「SQL Server Integration Services Projects」拡張はあくまで 設計用のアドイン です。これだけ入れても SSIS の実行環境（ランタイム）はインストールされません。
そのため、
- プロジェクトの作成、編集、ビルド、デバッグはできる
- しかし、ローカルでの「通常実行」は SSIS ランタイムが必要
という状態になります。「拡張は入れているのに、なぜ評価版切れになるのか？」という疑問の多くは、この区別が曖昧なことが原因です。
サーバーのライセンスはクライアント PC には自動的に適用されない
サーバー側に Enterprise エディションが入っていても、そのライセンスで開発 PC のローカル SSIS 実行をカバーできるわけではありません。サーバーとクライアント PC のライセンスは別々に考える必要があります。
開発・テスト用途であれば Developer エディションを使うのが最も無難です。
ターゲットバージョンの不一致
Visual Studio の SSIS プロジェクトには TargetServerVersion という設定があります。ここが SQL Server 2019 なのに、開発 PC に入っている SSIS ランタイムが 2017 しかない、といった状態だとビルドや実行で問題が出ることがあります。
基本的には、
- サーバー側の SQL Server バージョン
- 開発 PC 側の SSIS ランタイムのバージョン
- Visual Studio プロジェクトの TargetServerVersion
の 3 つをそろえる（あるいは互換性のある組み合わせにする）ことが重要です。
開発～本番までの SSIS 運用パターン例
最後に、今回のようなトラブルを避けつつ、現場でよく採用される SSIS の運用パターンを簡単に紹介しておきます。
パターン A：開発 PC でローカル実行 → サーバーで本番実行
- 開発 PC：SQL Server Developer ＋ Integration Services ＋ Visual Studio 2019
- サーバー：SQL Server 2017 Enterprise ＋ SSISDB ＋ SQL Server Agent
この場合、開発者はローカルで自由にテストし、本番リリース時に .ispac をサーバーにデプロイします。多くの開発現場で採用されているスタイルです。
パターン B：サーバー側にすべて集約
- 開発 PC：Visual Studio 2019 ＋ SSIS 拡張のみ
- サーバー：SQL Server（開発・検証・本番環境）に SSISDB を用意
この場合、開発者は PC 上ではデバッグまでにとどめ、実際の実行テストはすべてサーバー側で行います。セキュリティポリシーが厳しい環境や、データをうかつに開発 PC に落としたくない場合に向いています。
パターン C：テスト用に軽量なローカル SQL Server を用意
開発 PC には Developer エディションで最小限の構成だけをインストールし、本番と同じ SSISDB 構成はサーバー側のみで運用するパターンです。
- ローカル：簡易テスト用、軽量・高速に試す目的
- サーバー：本番に近い構成での最終確認
このように役割を分けておくと、評価版の期限切れやバージョン違いによるトラブルを避けやすくなります。
まとめ：評価版切れを機に SSIS 環境を整理しよう
SSIS の「Integration Services evaluation period has expired. The package can only be executed in debug mode.」というメッセージは、
- 開発 PC にインストールされた SSIS ランタイムが評価版のまま期限切れ
- Visual Studio の SSIS 拡張はあくまで設計ツール であり、実行ライセンスとは別
という状況を示しています。
解決するには、
- Developer エディションを導入してローカル SSIS 実行環境を正規化する
- 必要に応じて製品版キーで評価版を正規版にアップグレードする
- ローカルで実行せず、サーバー側にデプロイして実行する運用に切り替える
といった選択肢があります。あわせて、不要な評価版コンポーネントの削除やバージョン・ビット数の整理を行っておくと、今後のトラブルも減らせます。
一言でまとめると、「開発 PC の SSIS が評価版切れなので、Developer エディションなどで正規の SSIS ランタイムを用意するか、実行をサーバー側に集約する」ことが解決のポイントです。これを機に、開発～本番までを見据えた SSIS の運用設計を見直してみてください。
コメント