Azure Data Studio（ADS）にはCSVなどのファイルを取り込んでテーブルを自動生成できる「Import Wizard」があります。一方で、VS Code＋SQL Server（MSSQL/mssql）拡張では同等のGUIが見当たらず、困る人が少なくありません。本記事では“現時点の結論”と、ウィザードが無くても現場で回せる具体策を整理します。
結論：VS Code（MSSQL/mssql拡張）にはADSの「Import Wizard相当」が“標準機能”としては見当たりにくい
最初に結論です。Visual Studio Code（VS Code）＋SQL Server（MSSQL/mssql）拡張を入れても、Azure Data Studio（ADS）にあるような「ファイルを取り込んでテーブルを自動作成するウィザード」が、常に同じ導線で提供されるとは限りません。VS Code側は「クエリ実行・スキーマ操作・結果表示」など開発体験を中心に進化しており、フラットファイル取り込みは別アプローチで補うのが現実的です。
なぜこの差が出る？ADSとVS Codeは“似ているけど役割が違う”
ADSは「データ作業も含めたDBツール」として、拡張機能を含めてGUIの導線が整えられてきました。一方のVS Codeは、あくまで汎用エディタ＋拡張機能です。MSSQL拡張は便利になっていますが、運用思想としては「ウィザード中心」よりも「スクリプト中心」のワークフローに寄りがちです。
さらに大きなトピックとして、MicrosoftはADSの退役（サポート終了）を2026年2月28日と案内しており、移行先としてVS Code＋MSSQL拡張を推奨しています。その一方で、移行ガイドではフラットファイル取り込み（.txt/.csv）は当面 bulk insert / PowerShell 等で代替し、VS Code側の機能は開発中という趣旨の記載もあります。
質問と同じ内容の公式回答：「VS CodeはMicrosoft Q&Aのサポート対象外」→GitHubへ
「VS CodeでImport Wizardは使えないのか？」という質問に対し、Microsoft LearnのQ&Aでは“VS Codeはこのフォーラムのサポート対象外なので、GitHub（vscode側）へ投稿してほしい”という案内で回答が完結する例があります。つまり、この手の話は手順というより機能有無・機能要望の領域として扱われがち、ということです。
実務上の落としどころ：目的別に「最短で安全な方法」を選ぶ
ウィザードが無いこと自体が問題というより、「単発の取り込み」なのか「定期処理」なのか、また「誰が実行するか（権限）」「ファイルをSQL Serverが参照できるか」で最適解が変わるのが本質です。まずは選択肢を俯瞰しましょう。
| シーン | おすすめ手段 | 向いている理由 | 注意点 |
|---|---|---|---|
| 単発でCSVを取り込み、すぐテーブル化したい | SSMSのImport Flat File Wizard | GUIで完結しやすく、作業者の学習コストが低い。 | 型推定は外れることがある。複雑な変換には弱い。 |
| ADSの操作に慣れている（ウィザード重視） | ADS + SQL Server Import extension（Import Wizard） | プレビューしながら列定義を調整できる。導線が分かりやすい。 | ADSは退役予定。中長期は移行計画が必要。 |
| VS Code中心で再現性を担保したい（チーム運用） | BULK INSERT / bcp / PowerShell（dbatools等） | スクリプト化でき、レビュー・再実行・CI/CDに強い。 | 最初に権限・ファイル配置・文字コードなどの前提整理が必要。 |
| 定期取り込み・複数ソース統合・加工が多い | SSIS / Data Factory / Fabric等のETL | 監視・再試行・変換に強い。運用設計を作りやすい。 | 準備コストが高い。小規模だと過剰なことも。 |
GUIでやりたい：SSMS / ADSを“割り切って使う”
SSMS：Import Flat File Wizard
「CSVを取り込んで新しいテーブルを作る」だけなら、SSMSのImport Flat File Wizardが最短です。CSV（.csv/.txt）を新規テーブルへコピーする用途にフォーカスしており、区切り文字（カンマ/タブ/セミコロン/パイプ）や固定長などの基本に対応します。
“VS Codeで完結”にこだわらず、単発作業はウィザードで済ませ、定期化が見えてきたらスクリプト化へ移行、という段階的な割り切りが最もトラブルを減らします。
ADS：SQL Server Import extension（Import Wizard）
ADSには、.txt/.csvをSQLテーブルへ変換するためのSQL Server Import extensionがあり、右クリックからImport Wizardを起動できます。プレビューを見ながら列名・型・NULL許可・主キー等を調整でき、派生列（derived column）も扱えます。説明では、ファイル解析にPROSEという枠組みを使うとされています。
ただし前述の通り、ADSは退役予定です。移行ガイド側でもフラットファイル取り込みは当面の代替手段が提示されているため、“今はADSで回しつつ、取り込み処理はスクリプトへ寄せる”が堅実です。
VS Codeでやりたい：ウィザードの代わりに「取り込みスクリプトの型」を作る
ウィザードがやってくれていることは大きく2つです。
- テーブル定義を作る（型推定）
- その定義に合わせてデータを流し込む
VS Code中心の運用では、この2つを自分たちの“型（テンプレ）”として固定化すると、むしろウィザードより安定します。
まず押さえる前提：BULK INSERTは「SQL Serverプロセスがファイルを読む」
BULK INSERTは便利ですが、勘違いが起きやすいポイントがあります。BULK INSERTのデータファイルは、“クライアントPC”ではなく“SQL Serverが動いているマシンから見えるパス”である必要があります。リモートファイルならUNCパス（\\\\Server\\Share\\...）を指定します。
さらに、Azure SQL DatabaseやFabric Data Warehouseなどクラウド系では、オンプレのファイルパスはサポートされず、URI（Azure Storageのパス等）を使う前提になります。
権限の目安：INSERT＋（環境に応じた）BULK系権限が必要
BULK INSERTには権限要件があります。Microsoft LearnのBULK INSERTドキュメントでは、SQL ServerではINSERTとADMINISTER BULK OPERATIONSが必要で、Azure SQL DatabaseではINSERTとADMINISTER DATABASE BULK OPERATIONSが必要と説明されています。また、SQL Server on LinuxではADMINISTER BULK OPERATIONSやbulkadminロールがサポートされず、sysadminのみが実行できる旨も記載されています。
「自分はdb_ownerなのにBULK INSERTできない」というケースは、データベース権限とサーバー権限のレイヤーが違うことが原因になりがちです。運用で誰にどこまで許可するかは、セキュリティ方針とセットで決めましょう。
おすすめ設計：ステージング（仮テーブル）→本テーブルの2段階
ウィザードが便利なのは「型推定」ですが、推定は外れます。そこで現場で安定しやすいのが、次の2段階です。
- ステージングテーブル：列は一旦すべてNVARCHARなどで受ける（失敗しにくい）
- 本テーブル：INSERT…SELECTで型変換しつつ整形・検証する（品質担保）
この構造にしておくと、変換エラーが起きても「どの行・どの列が原因か」を追いやすく、再実行もしやすいです。データ品質が不安なCSVほど効果が出ます。
BULK INSERTで取り込む（例：CSV→ステージング→本テーブル）
ステージングテーブルを用意する
CREATE TABLE dbo.Import_Stg
(
Col1 NVARCHAR(4000) NULL,
Col2 NVARCHAR(4000) NULL,
Col3 NVARCHAR(4000) NULL
);
CSVを取り込む
SQL ServerのバージョンやCSVの形式次第ですが、最近の環境ならCSV形式を明示し、ヘッダー行を飛ばし、UTF-8を指定する形が分かりやすいです。行終端は0x0a（LF）を指定する例が公式ドキュメントにもあります。Windows環境では\\nが自動的に\\r\\nへ置換されるという注意書きもあるため、改行の扱いに迷ったらまずここを疑います。
BULK INSERT dbo.Import_Stg
FROM '\\\\share\\\\import\\\\sample.csv'
WITH
(
FORMAT = 'CSV',
FIRSTROW = 2,
CODEPAGE = '65001',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '0x0a',
TABLOCK
);
もしFORMAT = 'CSV'が使えない環境（古いSQL Server等）なら、FIELDTERMINATORとROWTERMINATORを中心に指定する形に寄せるとよいです。CSV内にダブルクォートで囲われたカンマがある場合は、素直にETLや前処理へ逃がした方が早く終わることもあります。
本テーブルへ変換しながら投入する
INSERT INTO dbo.TargetTable (Id, Amount, CreatedAt)
SELECT
TRY_CONVERT(INT, NULLIF(Col1, '')) AS Id,
TRY_CONVERT(DECIMAL(18,2), NULLIF(Col2, '')) AS Amount,
TRY_CONVERT(DATETIME2(0), NULLIF(Col3, '')) AS CreatedAt
FROM dbo.Import_Stg;
取り込み後は、件数チェックと変換失敗の検出を必ず行います。
-- 取り込み件数（ステージング）
SELECT COUNT(*) AS StgRows FROM dbo.Import_Stg;
-- 変換できない行を抽出（例：Idが数値でない）
SELECT *
FROM dbo.Import_Stg
WHERE TRY_CONVERT(INT, NULLIF(Col1, '')) IS NULL
AND NULLIF(Col1, '') IS NOT NULL; bcpで取り込む：サーバーにファイルを置けないときの定番
BULK INSERTはSQL Server側がファイルを読むため、サーバーにCSVを置けない（置きたくない）ケースでは詰まりがちです。そこで定番になるのがbcp（Bulk Copy Program）です。bcpはクライアントがファイルを読んでSQL Serverへ流し込むため、ネットワーク越しでも扱いやすい場面があります。
bcp YourDb.dbo.Import_Stg in "C:\\import\\sample.csv" -S yourServer -T -c -t "," -r "\\n" -F 2
| 観点 | BULK INSERT | bcp |
|---|---|---|
| ファイルを読む主体 | SQL Serverプロセス | クライアント（実行PC） |
| ファイル配置 | サーバーから見える場所（ローカル/UNC/クラウドURI等） | クライアントに置ければOK |
| 運用のしやすさ | SQLで完結（DB側でログ・管理しやすい） | スクリプト化しやすい（タスク化・CIにも載せやすい） |
PowerShellで取り込む：前処理が多いなら“最初からスクリプトで”
CSVが汚い（列名が毎回違う、不要な列が混ざる、日付形式がぶれる、空白が多い…）といったケースでは、SQLだけで頑張るよりもPowerShell（あるいはPython等）で前処理してからDBへ流し込む方が総工数が下がります。dbatoolsのようなモジュールを使うと、CSV取り込みを自動化しやすいのが利点です。
ポイントは、取り込み処理を“人の手”から外し、ログと再実行性を確保することです。VS Codeはエディタなので、こうしたスクリプト運用と相性が良いです。
よくあるつまずきと対策（ウィザードが無いとハマる所）
ウィザードが無いと困るのは、だいたい次の罠にハマるからです。先に潰しておくと、VS Code運用でも詰まりにくくなります。
| よくある症状 | 原因になりがちな点 | 対策 |
|---|---|---|
| 列がずれる / 行が途中で壊れる | 区切り文字が想定と違う、ダブルクォート内のカンマ、改行コード差（LF/CRLF） | まず数行を目視して仕様を確定。クォートが効いたCSVはETL/前処理へ逃がす。 |
| 日本語が文字化けする | UTF-8(BOM有無)、Shift_JIS、SQL側CODEPAGE | 入力の文字コードを統一。UTF-8ならCODEPAGE=65001を検討。 |
| 日付/数値がNULLになる | ロケール差、桁区切り、想定外フォーマット | ステージング→TRY_CONVERTで検出し、変換ルールを固定化。 |
| 取り込みが遅い / ログが肥大化する | インデックス/制約が多い、1行ずつINSERT、トランザクション設計 | 一括ロード＋TABLOCK等を検討。必要ならインデックスはロード後に。 |
| ファイルが見つからない（パス指定が正しいはずなのに） | サーバーから見えるパスになっていない（クライアントのローカルを指定している） | BULK INSERTはサーバー視点。置き場所を整理し、難しければbcpへ。 |
セキュリティ面の注意：SQLログインだと“SQL Serverサービスアカウント”で読みに行く
ファイルアクセス権でハマる場合は、認証方式も重要です。Microsoft Learnの解説では、SQL Server認証（SQLログイン）でBULK INSERTを実行すると、ファイルへの接続はSQL Serverプロセス（サービスアカウント）のセキュリティコンテキストで行われる、と説明されています。一方でWindows認証なら、ユーザーがアクセス可能なファイルに対して取り込みできる、という整理が示されています。
運用で「誰が実行するか」「ファイルはどこに置くか」を決めるとき、ここを曖昧にすると障害対応コストが跳ねます。最初にルール化しておくのがおすすめです。
「VS Codeにウィザードが欲しい」場合は、GitHubでFeature requestが最短ルート
Import Wizardそのものが欲しい場合、それは手順の質問というより拡張機能への機能要望に近いです。実際に、VS Code側のMSSQL拡張にはImport/Export Wizard相当を求めるFeature requestがあり、マイルストーンが設定されている例もあります。
また、MSSQL拡張のドキュメントでも、ディスカッションやバグ報告、機能要望の窓口が案内されています。困りごとを再現手順つきで説明できるなら、GitHubに寄せた方が解決に近づきやすいです。
GitHubに出すときのチェックリスト
- やりたいこと：ADSのImport Wizard相当（CSV→テーブル作成＋取り込み＋型編集）
- 期待する導線：右クリックメニュー、プレビュー、列型編集、主キー指定、NULL許可など
- 対象環境：Windows/macOS/Linux、SQL Server/Azure SQL等
- 代替手段で困っている点：権限、ファイル配置、文字コード、定期実行、監査ログ
「困っている」だけでなく、どの規模の作業で、どこがボトルネックかを書けると、同じ悩みを持つ人の投票も集まりやすくなります。
まとめ：ウィザードが無い前提で“運用の型”を作ると、VS Code移行がスムーズになる
- 単発の取り込みは、SSMS/ADSのウィザードを使うのが速い
- VS Code中心なら、BULK INSERT / bcp / PowerShellでスクリプト化し、ステージング方式で品質を担保する
- ウィザードそのものが必要なら、GitHubでFeature requestとして扱うのが現実的
「VS Codeで全部やる」にこだわりすぎず、目的別に最短・安全な手段を選ぶのが結果的にコストを下げます。まずは小さなCSVで取り込みテンプレを作り、チームで共有できる形に育てていきましょう。
コメント