Visual Studio 2022 で SQL Database Project を SDK スタイルに移行したら、「SQL Server Object Explorer」にプロジェクトが一切出てこない…。そのままだと開発体験がガタッと落ちてしまいます。本記事では、なぜ表示されないのかという技術的な理由と、開発・CI/CD を止めずに続けるための現実的なワークフロー、そして SSOX をどうしても使いたい場合の落としどころまで、まとめて整理します。
VS 2022 の SDK スタイル .sqlproj が SQL Server Object Explorer に表示されない理由
結論から言うと、これは「不具合」ではなく 仕様に近い既知の制限 です。
現在の SQL Database Projects の世界には、ざっくりと次の 2 つのプロジェクト形式が存在します。
- 従来形式（クラシック）: MSBuild（.NET Framework）ベースの .sqlproj
- SDK スタイル:
Microsoft.Build.Sqlを使った新しい .NET SDK スタイルの .sqlproj
Microsoft は新しい開発では SDK スタイル（Microsoft.Build.Sql）を推奨しており、クロスプラットフォームな dotnet build で .dacpac を生成できる点などが大きなメリットです。
一方で、Visual Studio の SQL Server Object Explorer (SSOX) はもともと「クラシック形式の SQL プロジェクト」と「ライブなデータベース」を対象に設計されており、SDK スタイルの SQL プロジェクトは認識しません。
Microsoft Q&A でも、Microsoft スタッフから次のように明言されています。
- Visual Studio 2022 の SSOX は SDK スタイル .sqlproj をサポートしていない
- 「SQL Server Object Explorer (Preview)」という名前でも、実際には ライブ DB を閲覧するためのパネル であり、SDK スタイル プロジェクトは扱えない
つまり、「プロジェクトが見えない」のは、現時点の仕様どおりの挙動です。
クラシック形式 .sqlproj と SDK スタイル .sqlproj の違い
| 項目 | クラシック .sqlproj | SDK スタイル .sqlproj |
|---|---|---|
| プロジェクト形式 | MSBuild (.NET Framework) ベース | .NET SDK スタイル（Microsoft.Build.Sql） |
| 対象ランタイム | Windows + .NET Framework 前提 | .NET 8 などクロスプラットフォーム対応 |
| ビルド方法 | Visual Studio / MSBuild | dotnet build（CLI）、VS Code / ADS / VS2022 (SDK-style SSDT プレビュー) |
| ビルド成果物 | .dacpac | .dacpac（同一フォーマットで SqlPackage から利用可能） |
| SSOX からの操作 | プロジェクトを表示・発行・比較などが可能 | SSOX からは 一切見えない |
| 主な用途 | 既存資産、Windows 限定の開発 | Azure DevOps / GitHub Actions を含むクラウド CI/CD、Linux ビルドなど |
質問へのショートアンサー
| 質問 | 答え | ポイント |
|---|---|---|
| 1. 既知のバグ？ | いいえ。Visual Studio 2022 の仕様による制限。 | SSOX はクラシック形式のみ対応。SDK スタイルは対象外。 |
| 2. 開発時に SSOX 相当の操作は？ | CLI と VS Code / Azure Data Studio などで代替可能。 | スキーマ比較・発行・データ確認は他ツールでカバーできる。 |
| 3. SSOX を使いたい場合の代替策？ | クラシック形式を維持／ロールバックするしかない。 | SDK スタイルとクラシックの「二重運用」はコスト高なので慎重に。 |
質問 1: これは既知のバグか？
改めて整理すると、以下の 2 点が公式情報から読み取れます。
- SSOX は、クラシック形式の SQL プロジェクトと、接続済みデータベースを扱うための UI
- SDK スタイル プロジェクトは、Solution Explorer と CLI をメインに使うことを想定した新世代の仕組み
Microsoft Q&A では、Microsoft のスタッフが次のような趣旨の回答をしています。
- SSOX / 「SQL Server Object Explorer (Preview)」は SDK スタイル .sqlproj をサポートしていない
- SDK スタイル プロジェクトは Solution Explorer と
dotnet build/sqlpackageを使うワークフローが前提
したがって、「クラシック形式から SDK スタイルに変換したら SSOX から見えなくなった」は、2025 年 11 月時点では 仕様どおり の動きであり、回避する設定や隠しオプションは存在しません。
質問 2: SSOX 相当の操作を行うにはどうすればよいか
SSOX でやっていたことは、大まかに次の 4 類型に分けられます。
- スキーマの編集（テーブル・ビュー・ストアドなど）
- ビルド（.dacpac 作成）
- 発行（DB へのデプロイ）
- スキーマ比較やデータのざっくり確認
これらは別ツールを組み合わせることで、ほぼすべて再現可能です。
基本線: Solution Explorer + CLI（dotnet build / SqlPackage）
SDK スタイル プロジェクトは、「コードとしてのデータベース」 にフォーカスした作りになっています。Visual Studio の Solution Explorer で .sqlproj を開き、ビルドやソース管理を行いつつ、実際のビルド・発行は CLI で統一するのがもっともシンプルです。
.dacpac のビルド
プロジェクト フォルダで次のように実行します。
dotnet build MyDatabaseProject.sqlproj -c Release
ビルドが成功すると、通常は bin/Debug または bin/Release 配下に .dacpac が生成されます。
SqlPackage による発行
.dacpac から DB にデプロイするには、クロスプラットフォーム対応の SqlPackage CLI を使います。
# SqlPackage を .NET ツールとしてインストール
dotnet tool install -g Microsoft.SqlPackage
# .dacpac を指定して発行
sqlpackage /Action:Publish ^
/SourceFile:bin\Release\MyDatabaseProject.dacpac ^
/TargetConnectionString:"Server=...;Database=...;User ID=...;Password=..."
この組み合わせなら、Windows だけでなく Linux エージェント上の Azure DevOps パイプラインでも同じコマンドでビルド＆デプロイを行えます。
Azure DevOps パイプライン例（YAML イメージ）
イメージとしては次のようなステップ構成になります。
steps:
- task: UseDotNet@2
inputs:
packageType: 'sdk'
version: '8.x'
- script: dotnet build MyDatabaseProject.sqlproj -c Release
displayName: 'Build dacpac'
- script: |
dotnet tool install -g Microsoft.SqlPackage
sqlpackage /Action:Publish `
/SourceFile:bin\Release\MyDatabaseProject.dacpac `
/TargetConnectionString:"$(MyDbConnectionString)"
displayName: 'Publish database'
これにより、Windows エージェントへの依存を完全に排除した DB デプロイ パイプライン を構築できます。
GUI が欲しいとき: VS Code / Azure Data Studio の SQL Database Projects 拡張
「やっぱり GUI でスキーマ比較やオブジェクトの構造を見たい」という場合は、次のどちらか（または両方）の利用が現実的です。
- Visual Studio Code + SQL Database Projects 拡張
- Azure Data Studio + SQL Database Projects 拡張
どちらも Microsoft.Build.Sql ベースの SDK スタイル プロジェクトをネイティブにサポートし、次のような機能を提供します。
- ブランク プロジェクトの作成
- 既存データベースからのプロジェクト生成
- テーブル / ビュー / ストアドなどの追加・編集（T-SQL ファイル編集）
- .dacpac のビルド & デプロイ
- 接続情報・SQLCMD 変数をプロファイルから読み込み
なお、2026 年 2 月 28 日で Azure Data Studio 自体はリタイア予定となっており、長期的には VS Code への移行が推奨されています。
よくある SSOX 操作と、その代替手段
| SSOX でやっていたこと | 代替ツール / 方法 | 補足 |
|---|---|---|
| テーブルやビューの定義を確認・編集 | VS Code / ADS の SQL Database Projects で T-SQL ファイルを編集 | GUI デザイナではなく「スクリプトで定義する」スタイルにシフトする。 |
| ローカル DB に発行して動作確認 | dotnet build + sqlpackage /Action:Publish | 発行プロファイル（publish.xml）を使うと環境ごとの差分を吸収しやすい。 |
| 本番 DB とのスキーマ比較 | ADS の Schema Compare、または .dacpac 同士の比較ツール | SDK スタイル プロジェクト向けの GUI 比較は ADS 側が充実している。 |
| DB の中身をざっと見る | SSOX から DB に接続（プロジェクトは無視）、または SSMS | ライブ DB のブラウズ用途としての SSOX はこれまでどおり使える。 |
| クラシック .sqlproj のビルド | Visual Studio（従来 SSDT） | SDK スタイルとは別物として割り切る（後述）。 |
質問 3: SSOX を使いたい場合の代替策
それでも「テーブル デザイナを含む SSOX 統合はどうしても欲しい」というケースもあると思います。残念ながら、SDK スタイルのまま SSOX に統合する方法は存在しません。
現実的な選択肢は次の 3 つです。
選択肢 1: クラシック形式 .sqlproj にロールバックする
もっともシンプルなのは、変換前のクラシック プロジェクトに戻す方法です。Microsoft の変換ドキュメントでも、変換前に .sqlproj をバックアップしておくこと が推奨されています。
- SSOX 連携（テーブル デザイナ、スキーマ比較など）をフル活用できる
- ただし、
dotnet buildで Linux ビルドはできないため、CI は Windows エージェント依存に戻る
「SSOX が業務上どうしても必須」で「Linux ビルドは nice to have」という環境なら、この割り切りも十分ありです。
選択肢 2: クラシック + SDK スタイルの二重運用
もう一歩踏み込んだやり方として、同じスキーマを
- SSOX 用のクラシック プロジェクト
- CI/CD 用の SDK スタイル プロジェクト
の 2 系統で管理する方法もあります。
ただし、この方法は以下のようなデメリットが大きく、かなり慎重な運用が必要です。
- 同じ変更を 2 つのプロジェクトに反映 する手間が発生する
- 反映漏れがあると、クラシック版の .dacpac と SDK 版の .dacpac が食い違う
- 差分を検証するために毎回 .dacpac の比較が必要になる
もし二重運用をするなら、少なくとも次のようなルールを決めておくと破綻しにくくなります。
- どちらか一方（たとえば SDK スタイル側）を「正」と決める
- リリース前に .dacpac 同士を比較し、差分がないことを CI でチェックする
- クラシック プロジェクトで大きなリファクタリングをしない（設計変更は SDK スタイル側で行う）
それでも運用コストは高めなので、「SSOX の GUI がないと仕事にならない」レベルの場合のみ検討する価値がある、くらいのポジションです。
選択肢 3: Visual Studio を 2 インスタンスに分ける
SDK スタイルの SQL プロジェクトは、Visual Studio 2022 の 「SQL Server Data Tools, SDK-style (preview)」コンポーネント として提供されています。Microsoft は、クラシック SSDT と SDK スタイル SSDT を 同じ VS インスタンスに同居させないこと を推奨しており、別インストールに分けることが案内されています。
例えば、次のような構成にすることができます。
- VS 2022（通常版インストール）：クラシック SSDT + SSOX 用
- VS 2022 Preview（別インスタンス）：SDK-style SSDT (Preview) + SDK スタイル .sqlproj 用
これにより、
- SSOX を使ったクラシック プロジェクト開発は通常版 VS で継続
- SDK スタイルの試験導入や CLI ベースのパイプライン整備は Preview 側で実施
といった段階的な移行が可能になります。もちろん、プロジェクト自体をクラシック/SDK のどちらで運用するかは別途決める必要がありますが、IDE の環境を分けるだけでもトラブルを減らせる ケースは多いです。
SDK スタイル .sqlproj の現実的なベストプラクティス
ここからは、「SSOX には戻らない」前提で、SDK スタイル プロジェクトを軸にした現代的なワークフロー例をもう少し具体的に見ていきます。
1. プロジェクトの作成・変換
既存のクラシック プロジェクトを SDK スタイルに変換する場合、Microsoft の公式ドキュメントに沿って .sqlproj を書き換えるのが基本です。
手順のポイントだけ抜き出すと次のとおりです。
- .sqlproj のバックアップ（例:
MyProject.sqlproj.originalを作る） - クラシック形式で一度 .dacpac をビルドしておき、変換後と比較できる状態にする
- .sqlproj をテキスト編集し、以下のような変更を行う
<Sdk Name="Microsoft.Build.Sql" Version="x.y.z" />を追加- 不要になった
<Import ... />の削除 <Build Include="***.sql" />の列挙を削除（SDK スタイルは**/*.sqlを自動インクルード）- Properties フォルダのエントリ削除 など
dotnet buildで .dacpac をビルドし、変換前後の .dacpac を比較
このとき、変換後のプロジェクトは「オリジナル SSDT では開かない」ことに注意が必要です。開発は VS Code / ADS / SDK-style SSDT (Preview) のいずれかで行うことになります。
2. ビルドとテストをすべて dotnet build / CLI に寄せる
SDK スタイルの強みは、ビルド コマンドが IDE 非依存であること です。つまり、開発者ごとに使うツールが違っても（VS / VS Code / ADS）、最終的なビルドは
dotnet build MyDatabaseProject.sqlproj
の一行で済みます。
この考え方に乗ってしまうと、もはや「ビルドのために Visual Studio を開く必要」がなくなります。VS はあくまでエディタ / デバッガとして割り切り、ビルドはすべて CLI に寄せることで、IDE の差異やバージョン違いによるトラブルも減らせます。
3. 発行は SqlPackage で統一し、環境依存の設定はプロファイルへ
本番・検証・開発環境へのデプロイには、SqlPackage の /Action:Publish を使うのが定石です。
実務的には、デプロイ プロファイル（publish.xml）に
- 接続先サーバー
- データベース名
- 安全に無視する差分（例: インデックス / 権限など）
といった設定を記述し、SqlPackage からそれを読み込むようにしておくと、「環境ごとにちょっとだけオプションが違う」問題をきれいに吸収できます。
4. スキーマ比較は Azure Data Studio / VS Code 側に任せる
SDK スタイル プロジェクト向けの グラフィカルなスキーマ比較 は、現時点では Visual Studio よりも Azure Data Studio の方が充実しています。
典型的な使い方は次のような流れです。
- SDK スタイル .sqlproj から .dacpac をビルド
- ADS / VS Code の DB 接続から対象 DB を指定
- 「Schema Compare」 で「ソース: .dacpac」「ターゲット: データベース」として比較
- 差分内容をレビューし、必要なものだけを反映
SSOX の「スキーマ比較」からは距離を置き、「SDK スタイルの世界では ADS / VS Code が GUI フロントエンド」 と考えると、頭の切り替えがしやすくなります。
SSOX を捨てるか・守るかを判断するポイント
最後に、「うちのチームは SSOX を捨ててもよいのか？」を判断するためのチェックポイントを整理しておきます。
| 観点 | SSOX を手放せるケース | SSOX を維持したいケース |
|---|---|---|
| CI/CD | Azure DevOps / GitHub Actions などで DB デプロイを自動化したい | 手動デプロイが中心で、ビルドも開発 PC で完結している |
| ターゲット OS | Linux エージェントでビルドしたい、コンテナで動かしたい | Windows サーバー・Windows 開発マシンに閉じている |
| 開発スタイル | 「DB もコード」と割り切り、T-SQL ファイル編集で設計できる | テーブル デザイナなど、GUI 中心の設計フローが定着している |
| チームのスキルセット | CLI・YAML（パイプライン）・Git などに慣れている | DB まわりは GUI 操作に依存しているメンバーが多い |
これらを踏まえて、ざっくりと次のように考えると判断しやすいです。
- CI/CD 重視であれば SDK スタイル一択（SSOX なし生活に慣れる投資価値あり）
- オンプレ主体で小規模チームなら、クラシック + SSOX 継続も十分アリ
- 移行期は、VS Code / ADS を試しつつ、クラシック プロジェクトをすぐ捨てない構成にしておくと安心
まとめ
- VS 2022 の SQL Server Object Explorer は SDK スタイル .sqlproj をサポートしていない。これは既知の仕様であり、設定で変えることはできない。
- SDK スタイル プロジェクトは Solution Explorer + CLI（dotnet build / SqlPackage） を軸にしたワークフローが前提となっている。
- スキーマ編集や比較、GUI ベースの操作は VS Code / Azure Data Studio の SQL Database Projects 拡張 でかなりカバーできる。
- SSOX が絶対に必要な場合は
- クラシック .sqlproj へのロールバック
- クラシックと SDK スタイルの二重運用
- Visual Studio インスタンスを分ける（通常版 VS と Preview）
- 長期的には、Microsoft 自身が SDK スタイルを「将来の標準」と位置付けており、SSOX 依存からの脱却を進めておくのが安全な選択肢になりつつある。
「SSOX が見えない！」という状況は不安になりますが、実はツールの役割分担が変わっただけとも言えます。ビルドとデプロイを CLI に寄せ、GUI での作業を VS Code / ADS に任せることで、SDK スタイルでも十分に快適なデータベース開発体験を構築できます。
コメント