Azure Data Studio の提供終了が発表され、SQL 開発の主戦場は Visual Studio Code（VS Code）＋MSSQL 拡張機能へ移りつつあります。とはいえ ADS の「Import Wizard」や管理画面、結果グリッドの扱いに慣れていると、移行直後に詰まりがちです。本記事では“いま困る点”と“現実的な代替策”を実務目線で整理します。
Azure Data Studio（ADS）から VS Code への移行で何が起きるか
Microsoft は Azure Data Studio の提供終了（サポート終了日：2026年2月28日）を案内しており、今後は VS Code を推奨ツールとして位置付けています。移行を急ぐ理由はシンプルで、サポート終了後は更新・修正・セキュリティパッチが提供されなくなるためです。
一方で、ADS は「SQL クエリを書くための軽量ツール」だけではなく、フラットファイルの取り込みや一部の管理機能までまとめて触れる“便利な統合ツール”でした。VS Code の MSSQL 拡張機能は開発者向けの生産性を重視しているため、同じ体験をそのまま期待するとギャップが出ます。
移行でつまずきやすいポイントと、現実的な解決策
ここからは、ADS から VS Code へ移行する人が実際に困りやすい論点を、対策とセットで解説します。結論から言うと「VS Code に寄せる」「SSMS/ADS を残す」「スクリプト化して自動化する」を状況で使い分けるのが最短ルートです。
フラットファイルインポート（Import Wizard）が見当たらない問題
ADS の Import Wizard（CSV などのフラットファイルから、テーブル作成＋データ取り込みまでをウィザードで完結）に慣れていると、VS Code の MSSQL 拡張機能へ移った瞬間に「同じボタンがない」ことに気付きます。
結論：フラットファイルインポートはロードマップに含まれている
Microsoft の回答として、MSSQL 拡張機能にフラットファイルインポート機能を追加する計画がロードマップに含まれている旨が示されています。また、拡張機能のロードマップは公開されており、今後の機能追加状況を追えるようになっています。
参考までに、2025年12月時点の公開ロードマップでは、DACPAC のインポート/エクスポートが v1.37（2025年11月）でプレビューに入り、さらに v1.38（2025年12月）に「ADS から接続情報をインポート」が挙がっています。フラットファイルインポート自体は “TBD（今後実装）” の項目として掲載されており、まずは周辺から穴埋めが進んでいる状況です。
当面の代替策：手戻りを最小化する“3ルート”
| ルート | おすすめ度 | 向いているケース | 注意点 |
|---|---|---|---|
| SSMS/ADS のウィザードを継続利用 | ◎ | 単発の CSV 取り込み、非エンジニアでも作業する、手順を説明しやすい | ツールが増える。だが ADS は 2026/2/28 まではサポートされるため“インポート専用”として残す価値が高い |
| PowerShell でスクリプト取り込み | ◎ | 繰り返し作業、定期実行、ファイルが毎回同形式で届く | テーブル設計（型・NULL・主キー）をどうするかを先に決める必要がある |
| T-SQL（BULK INSERT など）で取り込み | ○ | サーバー側で完結させたい、パフォーマンス重視、大容量 | 共有フォルダ権限やパス指定など、運用要件が絡みやすい |
SSMS / ADS のウィザードで取り込む手順（最短で終わらせる）
「今回だけ取り込みたい」「操作を覚えるコストを増やしたくない」という場合は、従来どおりウィザードを使うのが最速です。
- SSMS：データベースを右クリック → タスク → データのインポート（Import Data）→ ソースにフラットファイルを選び、列マッピングと型を確認して実行
- ADS：対象データベース/テーブルのコンテキストメニューから Import Wizard（またはコマンドパレットからインポート系コマンド）→ 取り込み先テーブル作成とプレビューを確認して実行
ウィザードは裏側で「型推定」「NULL 判定」「区切り文字の推測」をしてくれます。だからこそ、一度だけの作業・人に引き継ぐ作業・急ぎの作業では、スクリプト化よりもトータルが速い場面が多いです。
ウィザードは“捨てない”のが賢い：VS Code と SSMS/ADS の役割分担
VS Code へ完全移行しようとすると、Import Wizard だけのために遠回り（ツール探し・拡張探し・不安定な手順）が発生します。現実的には次の運用が安定します。
- 普段の開発・クエリ編集：VS Code + MSSQL 拡張機能
- 単発のデータ取り込み：SSMS または ADS のウィザード
- 定期/大量の取り込み：PowerShell（または T-SQL）で自動化
PowerShell で CSV を取り込む例（手早く始める版）
「まず動くものが欲しい」なら、PowerShell の Import-Csv と SqlServer モジュール（例：Write-SqlTableData）の組み合わせが定番です。Microsoft の回答でも代替策として言及されています。
# 事前準備：
# 1) PowerShell で SqlServer モジュールを用意（初回のみ）
# Install-Module SqlServer -Scope CurrentUser
#
# 2) 取り込み先テーブルを作成（列名・型は要件に合わせて調整）
$server = "localhost"
$database = "YourDb"
$table = "dbo.YourTable"
$csvPath = "C:\data\sample.csv"
# CSV を読み込む（ヘッダー行が列名になる想定）
$rows = Import-Csv -Path $csvPath -Encoding UTF8
# そのまま書き込む（小〜中規模向け。大量データは SqlBulkCopy の方が高速）
Write-SqlTableData -ServerInstance $server -DatabaseName $database -SchemaName "dbo" `
-TableName "YourTable" -InputData $rows -Forceポイントは「テーブル設計を先に固定する」ことです。ウィザードは裏側で型推定をしてくれますが、スクリプト運用では次の項目を明示しておくと事故が減ります。
- 文字コード（UTF-8 / Shift_JIS）と区切り文字（カンマ / タブ）
- 日付・数値の形式（ロケール差分、空文字を NULL 扱いにするか）
- 主キー・ユニーク制約・インデックスをいつ張るか（大量取り込みなら後から推奨）
T-SQL で取り込む例（サーバー側で完結させる版）
サーバーにファイルを置ける/共有フォルダから参照できるなら、BULK INSERT や OPENROWSET(BULK...) を使うと高速です。VS Code からも T-SQL を実行するだけなので、操作感は“VS Code のまま”に寄せられます。
-- 例：まずはステージングテーブル（全部 NVARCHAR）に入れてから型変換する
CREATE TABLE dbo.Stg_Import (
Col1 nvarchar(4000) NULL,
Col2 nvarchar(4000) NULL,
Col3 nvarchar(4000) NULL
);
BULK INSERT dbo.Stg_Import
FROM 'C:\data\sample.csv'
WITH (
FIRSTROW = 2, -- ヘッダーを飛ばす
FIELDTERMINATOR = ',', -- 区切り文字
ROWTERMINATOR = '0x0a', -- 改行（環境により 0x0d0a）
CODEPAGE = '65001', -- UTF-8
TABLOCK
);
-- 必要なら本テーブルへ変換して投入
INSERT INTO dbo.YourTable (Col1, Col2, Col3)
SELECT
TRY_CONVERT(int, Col1),
TRY_CONVERT(date, Col2),
Col3
FROM dbo.Stg_Import;この方式は「CSV の揺れ（空白・不正値）」を TRY_CONVERT で吸収しやすいのが利点です。取り込みエラーを“途中で止めない”運用にしたい場合、ステージング＋変換の二段構えは実務で強いです。
他にもある：bcp / SSIS など“用途別”のインポート手段
CSV 取り込みは「ウィザード or PowerShell」だけではありません。データ量・実行場所・運用形態に合わせて、次の手段も候補になります。
- bcp（Bulk Copy Program）：コマンドラインで高速に取り込み/吐き出しができ、夜間バッチにも組み込みやすい
- SSIS（SQL Server Integration Services）：複雑な変換や複数ソース連携が必要なときに強い（導入・運用コストは上がる）
- クラウド連携（例：データパイプライン）：Azure SQL 側へ継続的に取り込みたい場合は、ETL/ELT 基盤を検討した方が長期的に安定する
# bcp の例（ヘッダーあり CSV を dbo.YourTable に取り込むイメージ）
# -F 2 で 2 行目から読み込む（ヘッダーを飛ばす）
bcp YourDb.dbo.YourTable in "C:\data\sample.csv" -S localhost -T -c -t , -F 2“単発”ならウィザード、“繰り返し”ならスクリプト、“大容量”なら bcp/BULK、“複雑な変換”なら SSIS という使い分けを覚えておくと、ツール移行の影響を最小化できます。
結果グリッドで「約6万件までしかフィルタできない」問題
VS Code（および ADS）で MSSQL 拡張機能を使うと、結果グリッドのフィルター/ソートが一定行数を超えたあたりで効かなくなるケースがあります。実際に「6万件を超えるとフィルタできない」という報告が GitHub 上で上がっています。
原因の考え方：クライアント側（グリッド側）の“インメモリ処理”に依存する
グリッドのフィルタは、SQL Server が処理しているわけではなく、クライアント側の UI が結果セットを保持して加工する方式になりがちです。そのため、結果が大きいほどメモリや実装上の閾値にぶつかります。VS Code の MSSQL 拡張機能にはフィルタ/ソートの上限を調整する設定（例：mssql.resultsGrid.inMemoryDataProcessingThreshold）があり、上限超過時には設定変更を促すエラーが出ます。
まずやるべきこと：バグ報告で状況を共有する
現時点では“仕様としての明確な上限”が固定されているというより、環境やバージョンによって挙動が揺れる可能性があります。Microsoft からも詳細調査のためにバグ報告の登録が案内されています。再現手順（行数、列型、フィルタ操作、拡張機能のバージョン）を添えて報告すると、改善に繋がりやすいです。
実務的な回避策：グリッドに“全部出してから探す”をやめる
数十万件の結果をクライアントに流してからフィルタするのは、どのツールでも限界が来やすい使い方です。SQL Server 側で絞り込んでから表示する運用に寄せると、ツール差の影響を受けにくくなります。
| やりたいこと | おすすめのやり方 | 例 |
|---|---|---|
| まず全体感を掴む | 件数を数える／上位だけ見る | SELECT COUNT(*) FROM ...SELECT TOP (1000) ... ORDER BY ... |
| 条件で探す | WHERE でサーバー側フィルタ | WHERE Status = 'Active' AND CreatedAt >= '2025-01-01' |
| ページングして眺める | OFFSET/FETCH（またはキーセット） | ORDER BY Id OFFSET 0 ROWS FETCH NEXT 5000 ROWS ONLY |
| 目視ではなく検証する | 集計・差分クエリに分解 | GROUP BY / HAVING / EXCEPT など |
特におすすめなのが「キーセットページング」です。OFFSET はページが進むほど重くなりやすいので、主キーや日時列で“次の範囲”を指定して進めると安定します。
-- キーセットページング例（Id が単調増加の主キーの場合）
DECLARE @LastId bigint = 0;
SELECT TOP (5000) *
FROM dbo.YourTable
WHERE Id > @LastId
ORDER BY Id;ADS にあった「Manage」「SQL Profiler」などの管理機能がない問題
ADS で便利だった「Manage 画面」「Launch Profiler」などの管理系機能は、VS Code の MSSQL 拡張機能では同等の体験が揃っていないことがあります。ここは“できるようになるのを待つ”より、役割分担を決めるのが早いです。
結論：SQL Profiler など本格的な管理機能は“現時点では計画に含まれていない”
MSSQL 拡張機能のロードマップでは、SQL Agent や SQL Profiler、Notebooks といった機能は「現時点では計画していない」旨が明記されています。Microsoft Q&A でも、Profiler を含む管理機能はロードマップ対象外であること、必要なら機能要望として提出してほしいことが案内されています。
Profiler の代替は「Extended Events」＋「Query Store」が軸
Profiler（SQL Trace）は便利ですが、現行の推奨は Extended Events（XE）です。SSMS には XE を扱う UI があり、必要なときだけ SSMS を開く運用が安全です。Azure SQL / SQL Server いずれでも、クエリの傾向把握には Query Store を併用すると“調査の再現性”が上がります。
Extended Events を最小構成で始める例
「まずは何が飛んでいるか見たい」程度なら、イベントファイルに出すシンプルなセッションから始めると分かりやすいです（本番適用前に必ず検証してください）。
-- 例：完了した SQL（RPC/バッチ）を収集する最小構成（要調整）
CREATE EVENT SESSION [xe_capture_completed] ON SERVER
ADD EVENT sqlserver.rpc_completed,
ADD EVENT sqlserver.sql_batch_completed
ADD TARGET package0.event_file(
SET filename = N'C:\temp\xe_capture_completed.xel',
max_file_size = 50,
max_rollover_files = 4
)
WITH (
MAX_MEMORY = 4096 KB,
EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS,
MAX_DISPATCH_LATENCY = 5 SECONDS,
TRACK_CAUSALITY = OFF,
STARTUP_STATE = OFF
);
ALTER EVENT SESSION [xe_capture_completed] ON SERVER STATE = START;VS Code 側に Profiler ボタンがないこと自体は“欠点”というより、ツールの役割が違うと理解すると割り切れます。開発者が日常的に触るフロントは VS Code、運用・調査のコンソールは SSMS（必要に応じて ADS）という二段構えが現場では定着しやすいです。
目的別：VS Code / ADS / SSMS のベストな使い分け
| やりたいこと | 最適ツール | 補足 |
|---|---|---|
| クエリ作成・実行、スクリプト管理（Git 連携） | VS Code + MSSQL 拡張機能 | 編集体験と拡張性が強い。接続グループなども改善が進んでいる |
| CSV/Excel などの単発取り込み（ウィザード） | SSMS または ADS | 手順が説明しやすく、作業が早い。VS Code 側の実装待ちの間は割り切る |
| バックアップ/復元、ジョブ、権限、サーバー設定 | SSMS | 管理機能が最も充実。運用担当がいる現場では SSMS を残すのが安全 |
| トレース/性能調査 | SSMS（Extended Events / Query Store） | Profiler 依存から段階的に移行すると事故が少ない |
| 定期インポート/大量取り込み | PowerShell / T-SQL（自動化） | ウィザードより“再現性”が高い。CI/CD との相性も良い |
移行をスムーズにするチェックリスト
- ADS のサポート終了日（2026年2月28日）を前提に、いつまでに何を移すかを決める
- VS Code で日常業務（クエリ編集・実行・保存）が問題ないかを先に検証する
- Import Wizard が必要な作業は“当面 SSMS/ADS に残す”と割り切る
- 繰り返し発生する取り込みは、PowerShell/T-SQL でスクリプト化して属人化を減らす
- 結果グリッドで大規模データを扱う運用は、SQL 側で絞り込む運用に寄せる
- Profiler 相当が必要なら、Extended Events と Query Store の運用を先に整える
まとめ：完全移行は“インポート実装”を待ちつつ、いまはハイブリッドが最適解
VS Code の MSSQL 拡張機能は改善が早く、ロードマップ上もフラットファイルインポートや接続情報の移行など、ADS からの移行を後押しする項目が進んでいます。一方で、SQL Profiler のような管理者向け機能は拡張機能の主戦場ではありません。だからこそ、開発は VS Code、管理とウィザードは SSMS/ADS、自動化はスクリプトという“役割分担”が、移行期のストレスを最小化します。
コメント