2026年7月2日にMicrosoftが公開した「Fundamentals of Azure DevOps with SQL projects」は、.NET SDKベースのSQL Database ProjectsをAzure DevOps Pipelinesでビルドし、.dacpacとしてAzure SQL Databaseへ安全にデプロイするための実践ガイドです。結論から言うと、今回確認すべきポイントは「データベース変更をアプリケーションと同じCI/CDに組み込むこと」「パスワードレス認証を前提にすること」「ビルドとデプロイを分離し、ファイアウォールと権限を管理対象にすること」です。Microsoftの公式記事では、SQLプロジェクトは.NET SDK上に構築され、VS CodeやSQL Server Management Studioでも開発できると説明されています。(Microsoft for Developers)
この更新は、.NETアプリケーションのコードだけでなく、Azure SQL Databaseのスキーマ変更も継続的インテグレーションと継続的デリバリーの対象にしたい開発チームに影響します。一方で、特定日までに移行しなければならない強制的な期限が示されたものではありません。管理者は、既存のSQLプロジェクト形式、Azure DevOpsのサービス接続、Microsoft Entra認証、Azure SQLのネットワーク制御、PRチェックの運用を確認することが重要です。
.NET の「Fundamentals of Azure DevOps with SQL projects」とは
「Fundamentals of Azure DevOps with SQL projects」は、SQL Database ProjectsをAzure DevOpsのパイプラインでビルド・デプロイする基本構成を解説したMicrosoft公式の技術記事です。SQLプロジェクトを単なるデータベース定義ファイルの置き場として扱うのではなく、アプリケーション開発と同じようにレビュー、ビルド、検証、デプロイの流れに乗せる点が中心です。
SQL Database Projectsでは、テーブル、ビュー、ストアドプロシージャなどのデータベースオブジェクトを宣言的なSQLファイルとして管理できます。Microsoft Learnでは、SQLプロジェクトはデータベーススキーマの「信頼できる単一の情報源」としてCI/CDに適していると説明されています。(Microsoft Learn)
今回の公式記事で扱われている流れは、主に次の通りです。
| 領域 | 公式記事で示された考え方 | 実務上の意味 |
|---|---|---|
| ビルド | dotnet buildでSQLプロジェクトを検証 | SQL構文やターゲットプラットフォームとの不整合を早期に発見できる |
| 成果物 | ビルド結果として.dacpacを生成 | データベース変更を再現可能なパッケージとして扱える |
| デプロイ | SqlPackageで.dacpacをAzure SQLへ発行 | 手作業のSQL実行を減らし、環境差分に基づいて更新できる |
| 認証 | Azure DevOpsサービス接続とMicrosoft Entraを利用 | パスワードやアクセストークンをパイプラインに保存しない構成に近づけられる |
| ネットワーク | 実行時にAzure SQLのファイアウォール規則を追加・削除 | Microsoft-hosted agentの動的IPに対応しやすい |
重要なのは、これは.NETランタイムそのものの新機能ではなく、.NET SDKでビルドできるSQLプロジェクトをAzure DevOpsに組み込むための実装パターンだという点です。
今回の更新ポイント：ビルド前提のデータベースCI/CDへ整理された
今回の公式記事で最も実務的なポイントは、データベースの変更を「本番前に手でSQLを流す作業」から「ビルド可能な成果物として検証し、パイプラインで反映する作業」へ寄せていることです。
SQLプロジェクトは.NET SDKでビルドする
公式記事では、SQLプロジェクトの最小CIとしてdotnet buildを実行する例が示されています。Microsoft-hosted agentには.NET SDKが事前インストールされている一方、self-hosted runnerを使う場合は管理者が.NET SDKを準備する必要があります。(Microsoft for Developers)
基本のYAMLは次のような構成です。
trigger:
branches:
include:
- main
paths:
include:
- AdventureWorks
pool:
vmImage: ubuntu-latest
steps:
- task: DotNetCoreCLI@2
inputs:
command: 'build'
projects: 'AdventureWorks/AdventureWorks.sqlproj'
arguments: '/p:RunSqlCodeAnalysis=true'この例では、mainブランチのうちSQLプロジェクト配下に変更があった場合だけビルドを走らせています。アプリケーションコードとデータベース定義を同じリポジトリで管理している場合、パスフィルターを使うことで不要なパイプライン実行を減らせます。
RunSqlCodeAnalysis=trueは必須ではありませんが、データベースコードの品質確認を強化したい場合に有効です。特に複数拠点・複数チームでSQLを変更するグローバル組織では、レビュー担当者の経験差をパイプライン側で補う意味があります。
.dacpacをビルド成果物として扱う
SQLプロジェクトをビルドすると.dacpacが生成されます。Microsoft Learnでも、SQLプロジェクトのビルド成果物は.dacpacであり、ターゲットデータベースへのデプロイに使用できると説明されています。(Microsoft Learn)
注意したいのは、ビルドで.dacpacが生成されても、パイプライン成果物として明示的に保存しなければ後続のジョブや別パイプラインで使いにくい点です。公式記事でも、既定構成では.dacpacはSQLプロジェクトのbin/Debugフォルダーに一時的に出力されると説明されています。(Microsoft for Developers)
本番運用では、次のように扱いを決めておくと安全です。
| 方針 | 向いているケース | 注意点 |
|---|---|---|
| CIでビルドのみ実行 | まずSQL変更の構文エラーを防ぎたい | デプロイ品質の確認は別途必要 |
CIで.dacpacを成果物保存 | ステージングや本番で同じ成果物を使いたい | 成果物の保存期間と命名規則を決める |
| デプロイ直前に再ビルド | 小規模チーム、単純な開発環境 | CIで検証した成果物と本番投入物がずれる可能性がある |
実務では、PR時にビルドを通し、マージ後に生成した.dacpacをステージング、本番へ昇格させる形が管理しやすくなります。
影響範囲：開発者、DBA、セキュリティ管理者の全員に関係する
今回の内容は、単にAzure DevOpsのYAMLを少し変更する話ではありません。データベース変更の責任分界を明確にするきっかけになります。
開発者への影響
開発者は、SQL変更をローカルや共有DBで直接試すだけでなく、SQLプロジェクトに反映してビルドできる状態にする必要があります。テーブル定義、ビュー、ストアドプロシージャなどをSQLプロジェクトで管理すれば、PRの差分としてレビューしやすくなります。
特にアプリケーション側でEntity Framework CoreなどのORMを使っている場合でも、SQLプロジェクトは無関係ではありません。Microsoft Learnでは、SQL Database ProjectsはORMを使う開発でもデータベース状態のソースとして利用できると説明されています。(Microsoft Learn)
DBAへの影響
DBAにとっては、データベース変更を.dacpacという成果物で受け取り、SqlPackageの差分適用として確認できる点が重要です。SqlPackageのPublishは、ソース.dacpacのスキーマに合わせてターゲットデータベースを増分更新します。(Microsoft Learn)
ただし、すべてを自動反映すればよいわけではありません。破壊的変更、データ移行、巨大テーブルのALTER、インデックス再構築などは、事前にスクリプト確認やメンテナンス時間帯の判断が必要です。ステージング環境では自動適用、本番では承認付きデプロイにするなど、環境ごとにルールを分けるべきです。
セキュリティ管理者への影響
公式記事では、Azure DevOpsのサービス接続をMicrosoft Entraのエンタープライズアプリケーションとして扱い、データベース権限とAzure RBAC権限の2層でアクセスを付与する構成が示されています。(Microsoft for Developers)
ここで管理者が確認すべきなのは、次の2点です。
| 権限の種類 | 目的 | 確認ポイント |
|---|---|---|
| データベース権限 | スキーマ変更を適用する | 必要最小限のロールで足りるか、本番で追加権限が必要か |
| Azure RBAC | Azure SQL Serverのファイアウォール規則を操作する | カスタムロールにするか、SQL Server Contributorを使うか |
MicrosoftのAzure組み込みロールでは、SQL Server ContributorはSQL Serverとデータベースを管理できる一方、アクセス権そのものやセキュリティ関連ポリシーの管理は対象外と説明されています。(Microsoft Learn) とはいえ、本番環境では広すぎる可能性もあります。ファイアウォール規則の作成・削除だけが必要なら、カスタムロールを検討する価値があります。
設定変更で確認すべきポイント
今回の公式記事を自社環境に取り込む場合、主な設定変更は「Azure DevOps」「Azure SQL」「Microsoft Entra」「リポジトリ運用」の4つに分かれます。
Azure DevOps側：CIとCDを分ける
最初に作るべきなのは、デプロイしないビルド専用パイプラインです。SQLプロジェクトがビルドできることを確認するだけでも、PR前後の品質は大きく変わります。
次に、開発環境向けのデプロイパイプラインを作ります。公式記事では、デプロイ用パイプラインは自動トリガーを外し、手動実行する例が示されています。(Microsoft for Developers)
trigger:
- none
pool:
vmImage: ubuntu-latest
steps:
- task: DotNetCoreCLI@2
inputs:
command: 'build'
projects: 'AdventureWorks/AdventureWorks.sqlproj'
arguments: '--configuration Release'実務では、次のように段階を分けると失敗しにくくなります。
| 段階 | 推奨設定 | 目的 |
|---|---|---|
| PR | SQLプロジェクトのビルドを必須チェックにする | 構文エラーやターゲット不一致をマージ前に検出 |
| mainマージ後 | .dacpacを成果物として保存 | ステージング・本番で同じ成果物を使う |
| 開発環境 | 自動または手動デプロイ | 開発者が早く検証できる状態にする |
| ステージング | 承認付きデプロイ | 本番前にDBAやQAが確認 |
| 本番 | 承認、変更計画、ロールバック方針を必須化 | 影響範囲を管理して安全に反映 |
Azure Reposのブランチポリシーでは、PR完了前にビルド成功を必須にするBuild validationを設定できます。Microsoft Learnでも、PRの変更がビルド成功することを必須にできると説明されています。(Microsoft Learn)
Azure SQL側：Entra認証とネットワークを前提にする
公式記事の前提条件では、Azure SQL Databaseを配置する論理サーバーについて、Microsoft Entra認証を有効化し、Entra-onlyを推奨し、パブリックネットワークアクセスは「Selected networks」にする構成が示されています。(Microsoft for Developers)
この構成では、Azure DevOpsのMicrosoft-hosted agentからAzure SQLへ接続するために、実行時のパブリックIPを取得し、そのIPだけを一時的にファイアウォールへ追加します。処理後はcondition: always()を付けたステップでファイアウォール規則を削除します。
- task: AzurePowerShell@5
displayName: 'Remove SQL Server Firewall Rule'
condition: always()
inputs:
azureSubscription: 'ContosoAzure'
ScriptType: 'InlineScript'
Inline: |
Remove-AzSqlServerFirewallRule `
-ResourceGroupName "${env:RESOURCEGROUP}" `
-ServerName "${env:SQLSERVERNAME}" `
-FirewallRuleName ${env:FIREWALLRULENAME}
azurePowerShellVersion: 'LatestVersion'このalways()が重要です。SqlPackageの実行に失敗した場合でも、ファイアウォール規則が残り続ける事故を防げます。
認証情報：接続文字列はパスワードレスを基本にする
公式記事では、パイプライン変数として次の3つを用意する例が示されています。
| 変数 | 用途 |
|---|---|
SqlDbConnectionString | Azure SQL Databaseへの接続文字列 |
SqlServerName | Azure SQL Server名 |
ResourceGroup | Azure SQL Serverが属するリソースグループ |
接続文字列は、ADO.NETのActive Directory Default形式を使う例が示されています。(Microsoft for Developers)
Server=tcp:yourserver.database.windows.net,1433;
Initial Catalog=yourdatabase;
Encrypt=True;
TrustServerCertificate=False;
Connection Timeout=30;
Authentication="Active Directory Default";接続文字列自体にパスワードを含めない設計にすることで、シークレット漏えいリスクを下げられます。ただし、接続先DB名やサーバー名も環境情報にあたるため、公開ログに出しすぎないように注意が必要です。
SqlPackageの権限は最小権限と実行要件のバランスを見る
公式記事では、サービス接続のIDをデータベース内のcontained userとして作成し、db_ddladmin、db_datareader、db_datawriterから始める例が示されています。これは、いきなりdb_ownerを付与しないための現実的な出発点です。(Microsoft for Developers)
一方で、Microsoft LearnのSqlPackage Publishページでは、既存データベースに対するPublishに必要な権限としてdb_ownerが記載されています。(Microsoft Learn) そのため、本番導入では「ブログ例の権限で必ず足りる」と断定しないことが重要です。
実務では、次の順番で検証してください。
| 確認項目 | 判断基準 |
|---|---|
| スキーマ変更だけか | CREATE/ALTER中心なら限定権限で足りる可能性がある |
| データ変更を含むか | 参照データ投入や既存データ更新がある場合は追加権限を検証 |
| ユーザー、権限、DB設定を変更するか | 高い権限が必要になる可能性が高い |
| 本番で同じ権限を使えるか | セキュリティ基準、監査要件、職務分掌に合うか確認 |
| 失敗時の復旧手順があるか | デプロイ前バックアップ、スクリプト確認、ロールバック方針を用意 |
「動かないからdb_ownerにする」のではなく、どの変更にどの権限が必要かをログで確認し、例外として文書化することが大切です。
移行期限：強制期限は示されていないが、新規開発はSDK-styleを優先したい
今回の公式記事自体は、既存環境に対して「いつまでに移行が必要」といった期限を示すものではありません。したがって、既存のSSDTベースのSQLプロジェクトや手動デプロイ運用が、即座に使えなくなるわけではありません。
ただし、Microsoft Learnでは、新規開発ではMicrosoft.Build.Sqlプロジェクトの利用を検討すべきであり、SDK-styleプロジェクトは将来サポートされる形式だと説明されています。(Microsoft Learn) また、既存のSQLプロジェクトをSDK-styleへ変換する手順も公式に用意されています。変換では、元の.sqlprojをバックアップし、変換前後の.dacpacを比較して同等性を確認する流れが示されています。(Microsoft Learn)
移行を急ぐべきケースと、様子を見るべきケースは次のように分けられます。
| 判断 | 該当するケース | 推奨アクション |
|---|---|---|
| 早めに検証すべき | Azure DevOpsでSQL CI/CDを標準化したい | SDK-style SQL projectでPoCを作る |
| 早めに移行候補 | Linux agentやクロスプラットフォームビルドを使いたい | 既存.sqlprojの変換検証を始める |
| 慎重に進める | SQLCLR、独自MSBuild設定、複雑なPre/Post Deployがある | 変換前後の.dacpac比較を必須にする |
| 当面維持でもよい | 既存SSDT運用が安定し、自動化要件が低い | 移行期限は設けず、次期改修時に検討する |
管理者は「移行期限がないから何もしない」ではなく、「CI/CDに載せる価値があるSQLプロジェクトから順に検証する」と考えると現実的です。
管理者が確認すべきチェックリスト
グローバル展開している組織では、Azureサブスクリプション、リージョン、テナント、開発拠点ごとにルールが異なることがあります。今回の構成を導入する前に、次の項目を確認してください。
| 確認領域 | 確認すべきこと | 失敗しやすいポイント |
|---|---|---|
| リポジトリ | SQLプロジェクトの配置場所、パスフィルター、ブランチ戦略 | すべての変更でパイプラインが走り、運用コストが増える |
| ビルド環境 | Microsoft-hosted agentかself-hosted agentか | self-hosted agentに.NET SDKやSqlPackageが入っていない |
| 成果物管理 | .dacpacをどこに保存し、どの環境へ昇格するか | デプロイ直前に再ビルドして検証済み成果物とずれる |
| サービス接続 | 接続名、対象サブスクリプション、権限スコープ | サービス接続名が長く、YAMLで誤指定する |
| Entra認証 | Azure SQL ServerのEntra管理者、Entra-only設定 | SQL認証前提の古い手順と混在する |
| DB権限 | contained user、ロール、必要な昇格権限 | 最小権限を狙いすぎて本番デプロイだけ失敗する |
| Azure RBAC | ファイアウォール規則を操作する権限 | SQL Server Contributorを広いスコープに付けすぎる |
| ネットワーク | Selected networks、動的IP追加、削除処理 | 失敗時に一時ファイアウォール規則が残る |
| 承認プロセス | PRレビュー、Build validation、本番承認 | DB変更がアプリレビューから漏れる |
| 監査 | 誰が、どの成果物を、どの環境に反映したか | 手動SQL実行とパイプライン実行が混在して追跡できない |
特に本番環境では、SQLプロジェクトのビルド成功だけでは不十分です。デプロイ前に変更内容を確認するため、SqlPackageのDeployReportやScriptアクションを使って差分をレビューする運用も検討してください。SqlPackage CLIでは、Publishのほか、DeployReportやScriptなどのアクションも提供されています。(Microsoft Learn)
実務での導入手順
まずはビルド専用パイプラインから始める
最初から本番デプロイまで自動化すると、権限、ネットワーク、承認フローの問題が一度に表面化します。まずはSQLプロジェクトをdotnet buildできる状態にし、PRチェックに組み込むのが安全です。
おすすめの初期ゴールは次の3つです。
- SQLプロジェクトが常にビルドできる
- PRでSQL変更がレビュー対象になる
.dacpacがどこに生成されるかチーム全員が理解している
この段階では、Azure SQLへの接続権限やファイアウォール操作はまだ不要です。開発者がSQLプロジェクトの構造に慣れるための期間としても有効です。
次に開発環境だけへデプロイする
ビルドが安定したら、開発環境のAzure SQL Databaseへデプロイします。本番ではなく開発環境から始める理由は、SqlPackageが生成する差分、必要権限、処理時間、失敗時のログを安全に確認できるからです。
この段階で確認するべきことは次の通りです。
| 確認項目 | 見るべき内容 |
|---|---|
| 接続 | Active Directory Defaultで接続できるか |
| 権限 | サービス接続のIDでPublishできるか |
| ファイアウォール | パイプライン実行時だけ規則が追加・削除されるか |
| 差分 | 想定外のDROPやALTERが含まれないか |
| ログ | 監査に必要な情報が残るか |
開発環境で安定してから、ステージング、本番へ広げるべきです。
本番では承認と差分確認を必須にする
本番環境では、SQL変更の影響がアプリケーションコード以上に大きくなることがあります。列削除、型変更、NOT NULL制約追加、インデックス変更などは、アプリケーション停止や長時間ロックにつながる可能性があります。
本番デプロイでは、次の運用を推奨します。
| 項目 | 推奨 |
|---|---|
| PRレビュー | アプリ担当とDB担当の両方を含める |
| Build validation | SQLプロジェクトのビルド成功を必須にする |
| デプロイ承認 | 本番環境は手動承認を必須にする |
| 差分確認 | DeployReportまたはScriptで事前確認する |
| 実行時間 | 変更内容に応じてメンテナンス枠を設定する |
| 復旧策 | バックアップ、ロールバック手順、再実行手順を用意する |
「CI/CDだから自動で本番まで流す」のではなく、「人が確認すべき判断を明確に残したうえで、反復作業を自動化する」と考えるのが安全です。
よくある失敗と回避策
.dacpacを保存せず、環境ごとに違う成果物を使ってしまう
ビルドとデプロイを別パイプラインにする場合、.dacpacを成果物として保存しないと、後続環境で再ビルドすることになります。これでは、PR時に検証したものと本番投入物が完全に同じとは言い切れません。
回避策は、ビルド番号やコミットSHAを含めて.dacpacを保存し、どの成果物をどの環境へ反映したか追跡できるようにすることです。
ファイアウォール規則の削除が失敗時に実行されない
一時ファイアウォール規則を追加する構成では、削除処理にcondition: always()を付けることが重要です。これがないと、SqlPackageのPublishが失敗した場合に、Azure SQL Server側へ不要な許可IPが残る可能性があります。
運用では、定期的にAzure SQL Serverのファイアウォール規則を棚卸しし、FirewallRule-<BuildId>のような一時規則が残っていないか確認すると安心です。
最初から本番権限を広く付けすぎる
動作確認を急ぐあまり、サービス接続へ広いAzure RBACやDB権限を付与すると、あとから最小権限へ戻すのが難しくなります。
開発環境では広めに検証しても、本番では必要な操作を洗い出してから権限を調整しましょう。特に、ファイアウォール操作にSQL Server Contributorを使う場合は、スコープをリソースグループ全体ではなく対象SQL Serverに絞れるか確認してください。
手動SQL実行とパイプライン実行が混在する
SQLプロジェクトを導入しても、本番で緊急対応の手動SQLを繰り返すと、リポジトリ上のスキーマと実DBがずれていきます。これが続くと、次回のSqlPackage Publishで想定外の差分が出る可能性があります。
緊急対応で手動SQLを実行した場合でも、必ずSQLプロジェクトへ反映し、次のビルドで整合性を確認する運用にしてください。
EF Core Migrationとの使い分け
.NETアプリケーションでは、Entity Framework CoreのMigrationを使っているチームも多いはずです。SQL Database ProjectsとEF Core Migrationは、どちらか一方しか使えないものではありません。
判断基準は次の通りです。
| 選択肢 | 向いているケース |
|---|---|
| EF Core Migration中心 | アプリケーションモデルからDB変更を管理したい、小規模チーム |
| SQL Database Projects中心 | DBオブジェクトが多い、ストアドプロシージャやビューを厳密に管理したい |
| 併用 | アプリはEF Core、DBAはSQLプロジェクトで最終スキーマを管理したい |
グローバル組織や規制の強い業界では、最終的なDBスキーマをSQLプロジェクトでレビュー可能にしておくと、監査や本番変更管理に対応しやすくなります。
いま管理者が取るべき次のアクション
今回の「Fundamentals of Azure DevOps with SQL projects」は、SQL Database ProjectsをAzure DevOpsで使うための基本手順を整理したものですが、実務上はデータベースDevOpsの標準化に直結します。
まずは、既存環境を次の順番で確認してください。
- SQL変更がリポジトリで管理されているか
- SQLプロジェクトを
dotnet buildできるか - PRでSQLプロジェクトのビルドを必須にできるか
.dacpacを成果物として保存できるか- 開発環境へパスワードレスでデプロイできるか
- 本番デプロイ前に差分確認と承認を挟めるか
- サービス接続、DB権限、ファイアウォール規則を監査できるか
移行期限が明示された変更ではないため、慌てて全プロジェクトを変換する必要はありません。ただし、.NETアプリケーションとAzure SQL Databaseをセットで運用しているチームにとって、SQLプロジェクトのCI/CD化は品質と監査性を高める現実的な改善策です。まずはビルド専用パイプラインを1本作り、SQL変更を「人の記憶と手作業」ではなく「レビュー可能な成果物」として扱うところから始めるのが最も安全です。
コメント