Azure SQL updates for Juneの要点は、Azure SQLのデータベースエンジン仕様が大きく変わる話ではなく、Visual Studio CodeのMSSQL extensionを使ったAzure SQL開発・運用体験が強化された点です。特にSQL NotebooksがGAとして扱われ、T-SQLの実行、Markdownによる手順書化、必要に応じたPythonなどのカーネル併用を1つのNotebookにまとめられるようになりました。(マイクロソフトアジュール)
開発者にとっては、調査SQL・検証手順・分析メモを「実行できるドキュメント」として残せるのが大きなメリットです。一方、管理者はVS Code拡張機能の標準化、接続権限、GitHub Copilot利用ポリシー、Notebookに保存される実行結果の扱いを先に決めておく必要があります。
Azure SQL updates for Juneで何が変わったのか
今回のAzure SQL updates for Juneは、Azure Updates上で「Launched」として扱われる更新です。Azure UpdatesではLaunchedを、すべてのAzure顧客が利用できる本番向けの状態として説明しています。(マイクロソフトアジュール)
中心となる変更は、Visual Studio CodeのMSSQL extensionにおけるSQL NotebooksのGAです。Microsoft Learnでは、SQL Notebooksにより、Visual Studio CodeのJupyter Notebook形式でSQL開発を行い、SQLセル、Markdownセル、リッチな結果表示、Pythonなど他カーネルとの併用が可能になると説明されています。(Microsoft Learn)
| 更新項目 | できること | 実務での影響 |
|---|---|---|
| SQL Notebooks GA | T-SQLをNotebookセルで実行し、結果をセル下に表示 | 調査SQL、検証手順、運用Runbookを再実行しやすくなる |
| Markdownセル | SQLの意図、前提条件、確認観点を文章で残せる | 属人化しやすいDB調査手順をチーム共有しやすい |
.ipynb形式 | Jupyter互換のNotebookとして保存・共有 | Git管理やレビューの対象にしやすい |
| Pythonなどのカーネル併用 | Jupyter extensionを追加すると、SQLとPython処理を同じNotebookで扱える | SQL抽出後の簡易集計、可視化、検証に使いやすい |
| GitHub Copilot連携 | SQLセルの補完やNotebook構成案の生成を支援 | ただしAI生成SQLのレビューは必須 |
同時期のMSSQL extension for VS Codeの更新では、Schema Designer with GitHub Copilot、Data API builder、SQL NotebooksのGAなども案内されています。特にCopilot関連機能は便利ですが、自然言語で生成されたSQLやスキーマ変更をそのまま本番へ反映するのではなく、レビューと検証を前提に使うべきです。(Microsoft for Developers)
Azure SQLのAI/Copilot更新で何が変わるのか
今回の更新で重要なのは、AIやCopilotが「データベース管理者の判断を置き換える」のではなく、SQL開発・設計・検証の作業をVS Code上に集約しやすくなることです。
たとえば、これまでは次のように作業が分散しがちでした。
- SQLエディタでクエリを実行する
- 手順や判断理由はWikiやMarkdownに書く
- 結果の一部をExcelや別ツールに貼り付ける
- 必要に応じてPythonやJupyterで追加分析する
SQL Notebooksを使うと、これらを1つのNotebookにまとめられます。障害調査なら「確認する観点」「実行するSQL」「期待される結果」「次の判断」を順番に残せます。リリース検証なら、事前確認SQL、リリース後確認SQL、ロールバック判断条件を1ファイルにまとめられます。
SQL Notebooksが向いている作業
| 活用シーン | 具体例 | 向いている理由 |
|---|---|---|
| リリース前後の確認 | テーブル件数、制約、主要ビューの結果確認 | 手順とSQLをセットで残せる |
| 障害調査 | ロック、遅いクエリ、データ不整合の確認 | 調査経路を後から追いやすい |
| データ移行検証 | 移行前後の件数比較、NULL件数、重複確認 | 同じチェックを再実行しやすい |
| 開発者オンボーディング | サンプルDBの構造説明、基本クエリ練習 | Markdownで背景説明を付けられる |
| 簡易分析 | SQLで抽出し、Pythonで集計や可視化 | SQLと分析コードを同じ文脈で扱える |
一方で、定期バッチ、正式なDBデプロイ、厳密な変更管理が必要な本番DDLの適用には、Notebookだけで完結させない方が安全です。SQL Database Projects、DACPAC、マイグレーションツール、CI/CDパイプラインなど、変更履歴と承認フローを管理できる仕組みと組み合わせるべきです。
影響範囲：Azure SQL本体よりも開発・運用ツールチェーンへの影響が大きい
今回の更新は、Azure SQLのクエリ互換性や既存アプリケーションの動作を直接変えるものではなく、主に開発者・DBAが使うクライアントツールの強化として捉えるのが実務的です。MSSQL extensionは、Azure SQL Database、Azure SQL Managed Instance、SQL Server on Azure Virtual Machines、SQL database in Microsoft Fabric、SQL Serverを対象にした開発支援ツールとして説明されています。(Microsoft Learn)
| 対象 | 影響 |
|---|---|
| 開発者 | VS Code上でSQL実行、Notebook作成、Copilot支援を使いやすくなる |
| DBA・運用担当 | Runbook、調査手順、移行検証手順をNotebook化しやすくなる |
| セキュリティ管理者 | Notebook内の接続情報、実行結果、Copilot利用範囲のルール整備が必要 |
| アプリケーション | 通常は直接影響なし。DBエンジンの互換性変更ではない |
| CI/CD | Notebookを補助資料として管理するか、実行資産として扱うかの方針決定が必要 |
特に注意したいのは、Notebookは「便利なメモ」ではなく、実行可能なコードと結果を含むファイルになり得る点です。顧客データ、個人情報、内部ID、接続先情報が出力として残ったままGitにコミットされると、情報漏えいにつながります。
管理者が確認すべき設定ポイント
VS CodeとMSSQL extensionの標準バージョンを決める
チームで利用する場合、各メンバーが自由に拡張機能を更新すると、表示や操作手順が微妙に変わり、Runbookの再現性が落ちます。まずは検証用端末でMSSQL extensionの対象バージョンを確認し、社内標準として展開する範囲を決めましょう。
確認すべき項目は次の通りです。
| 確認項目 | 見るべきポイント |
|---|---|
| VS Code本体 | 社内標準バージョン、更新ポリシー、拡張機能の許可ルール |
| MSSQL extension | SQL Notebooks、接続、Object Explorer、Query Resultsの動作 |
| Jupyter extension | PythonなどSQL以外のカーネルを使う場合に必要 |
| GitHub Copilot | 利用ライセンス、組織ポリシー、利用可能なユーザー範囲 |
| Git設定 | .ipynbの出力結果をコミットするか、クリアしてから保存するか |
接続方式と権限を最小化する
SQL Notebooksでは、各Notebookにアクティブなデータベース接続が必要です。また、1つのNotebookは同一サーバー内のデータベース切り替えには対応しますが、同じNotebook内で複数サーバーへ同時接続する用途には向きません。(Microsoft Learn)
本番環境で使う場合は、少なくとも次のルールを設けるべきです。
| ルール | 理由 |
|---|---|
| 読み取り専用ユーザーを用意する | 調査Notebookで誤って更新系SQLを実行するリスクを下げる |
| 本番接続と検証接続の表示名を明確に分ける | 接続先の取り違えを防ぐ |
| 更新系SQLは原則Notebookで直接実行しない | レビューや承認フローを通しにくいため |
| Azure SQLのFirewallやPrivate Endpointを事前確認する | VS Code端末から接続できないケースがある |
| 保存済み接続情報をリポジトリに含めない | 接続先や認証情報の漏えいを防ぐ |
MSSQL extensionの接続機能では、AzureアカウントでサインインしてサブスクリプションやリソースグループからAzure SQL DatabaseやAzure SQL Managed Instanceを参照できるほか、Azure SQL接続時にクライアントIPが許可されていない場合はFirewallルール追加の導線も用意されています。(Microsoft Learn)
Copilotの利用範囲を決める
SQL Notebooksでは、GitHub Copilotを導入している場合、SQLセルでの補完や、MarkdownとSQLセルを組み合わせたNotebook構成の生成を支援できます。Microsoft Learnでも、Copilotがデータベースコンテキストや周辺のMarkdownセルをもとにSQL補完を行うことが説明されています。(Microsoft Learn)
ただし、Copilotが生成したSQLは必ず人間が確認してください。特に危険なのは次のようなケースです。
| 危険な使い方 | 具体的なリスク |
|---|---|
生成されたUPDATEやDELETEをそのまま実行する | 条件不足で大量更新・削除が起きる |
| スキーマ変更案を無検証で反映する | 型、制約、インデックス設計が業務要件とずれる |
| 本番データを含む結果をNotebookに残す | Git、共有フォルダ、チケット添付経由で漏えいする |
| Copilotの説明を仕様として扱う | 実DBの制約や権限と合わない可能性がある |
Schema Designer with GitHub Copilotのドキュメントでも、AI生成の出力は誤りや最適でない提案を含む可能性があるため、公開前に生成SQLやスキーマ変更をレビューする必要があるとされています。(Microsoft Learn)
Azure Data Studio利用者は移行計画を見直す
Azure Data Studioを使っていたチームにとって、今回の更新はより重要です。Microsoft Learnでは、Azure Data Studioは2026年2月28日にリタイアし、更新やセキュリティ修正を受けなくなったため、日常作業はVisual Studio CodeとMSSQL extensionへ移行するよう案内されています。既存のクエリ、スクリプト、SQL database projectsは変換なしでVisual Studio Codeで利用できると説明されています。(Microsoft Learn)
ただし、移行は「VS Codeを入れれば終わり」ではありません。次の順番で確認すると失敗しにくくなります。
| 手順 | 確認内容 |
|---|---|
| 利用機能の棚卸し | クエリ実行、Notebook、接続管理、Profiler、Schema Compareなど |
| 代替ツールの確認 | VS Codeで足りる作業と、SSMSを使う作業を分ける |
| 接続情報の整理 | 本番、検証、開発の接続名と権限を統一する |
| Notebook運用ルール作成 | 保存場所、出力結果の扱い、レビュー方法を決める |
| 既存手順書の移行 | よく使う調査手順からSQL Notebooks化する |
なお、SQL Server Agentなどの従来型管理作業や総合的な管理用途では、SSMSが引き続き利用先として示されています。VS CodeとMSSQL extensionは強力ですが、すべてのDBA作業を置き換えるものとして扱うのではなく、用途に応じてSSMSと使い分けるのが現実的です。(Microsoft Learn)
SQL Notebooksを試す最小手順
まずは本番ではなく、検証用のAzure SQL Databaseまたは開発用データベースで試すのが安全です。
| 手順 | 作業 |
|---|---|
| 1 | Visual Studio Codeを用意する |
| 2 | Extensionsからmssqlを検索し、MSSQL extensionをインストールする |
| 3 | Object Explorerから検証用データベースへ接続する |
| 4 | 新規Notebookを作成し、MSSQL kernelを選択する |
| 5 | SELECT TOP (10) ...のような読み取りSQLを実行する |
| 6 | Markdownセルで「目的」「確認観点」「期待結果」を書く |
| 7 | Pythonなどを併用する場合はJupyter extensionを追加する |
| 8 | 共有前に不要な出力結果や機密データが残っていないか確認する |
SQL Notebooksのドキュメントでは、Command PaletteからNotebookを作成する方法、Object Explorerのデータベース右クリックからNotebookを作る方法、SQLセルの実行、Markdownセルの追加、複数カーネルの利用手順が説明されています。(Microsoft Learn)
最初のNotebookに入れると便利な内容
最初から複雑な分析Notebookを作るより、チームで何度も使う確認手順をNotebook化すると定着しやすくなります。
-- 接続先確認
SELECT
@@SERVERNAME AS server_name,
DB_NAME() AS database_name,
SUSER_SNAME() AS login_name;-- 主要テーブルの件数確認例
SELECT COUNT(*) AS row_count
FROM dbo.YourTable;Markdownセルには、次のような内容を残します。
### 確認目的
リリース後に主要テーブルの件数が想定範囲内であることを確認する。
### 判断基準
- 0件でないこと
- 前回リリース前の件数と大きく乖離していないこと
- 異常値がある場合はアプリケーションログと照合するこのように、SQLだけでなく「なぜ実行するのか」「何をもって正常とするのか」まで書いておくと、属人化を防げます。
展開時に失敗しやすいポイント
SQL Notebooksは便利ですが、運用ルールなしに広げるとリスクも増えます。特に次の点は事前に対策しておきましょう。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| Notebook出力を残したまま共有 | 本番データや個人情報が含まれる | 共有前に出力をクリアする運用にする |
| 本番接続でRun Allを実行 | 更新系SQLまで一括実行される | 本番用Notebookは読み取り専用を基本にする |
| Copilot生成SQLを無確認で実行 | 誤った条件や危険なDMLが混入する | SQLレビューとトランザクション確認を必須にする |
| Python環境が人によって違う | Notebookが再現できない | 必要パッケージをrequirements.txtなどで管理する |
| 複数サーバー調査を1Notebookに詰め込む | 接続先を取り違える | サーバー単位でNotebookを分ける |
| Notebookを正式なデプロイ手段にする | 承認・ロールバック管理が弱くなる | DB変更はCI/CDやマイグレーションで管理する |
Data API builderなど関連機能を併用する場合も注意が必要です。Data API builderではREST、GraphQL、MCPエンドポイントを構成できますが、公開するテーブルや列、CRUD権限、主キー、未対応データ型などの確認が必要です。ドキュメントでも、AI生成構成のレビューや、主キーがないテーブル、未対応データ型、対話型Microsoft Entra ID認証の制限などが説明されています。(Microsoft Learn)
導入すべきチーム、慎重に進めるべきチーム
導入効果が出やすいチーム
次のようなチームは、SQL Notebooksの効果を感じやすいはずです。
- Azure SQLの調査SQLや検証SQLを頻繁に共有している
- リリース前後のDB確認手順が属人化している
- Azure Data StudioからVS Codeへ移行中である
- SQLとPythonを組み合わせた軽量分析を行っている
- 新メンバー向けにDB構造や業務SQLを説明する機会が多い
- GitHub Copilotを既に開発プロセスに組み込んでいる
慎重に進めるべきチーム
一方、次の状態でいきなり本番運用に広げるのは避けるべきです。
- VS Code拡張機能の利用ポリシーがない
- GitHub Copilotの利用可否やデータ取り扱いルールが決まっていない
- 本番DBに広い更新権限で接続している
- Notebookの出力結果をGit管理するルールがない
- Private EndpointやFirewallなどネットワーク接続条件が整理されていない
- 既存のDBデプロイ手順とNotebookの役割分担が曖昧
この場合は、まず検証環境で「読み取り専用の調査Notebook」から始めるのが安全です。いきなり本番のDDLやDMLを含むRunbookを作るのではなく、接続確認、件数確認、インデックス確認、リリース後の参照系チェックなど、影響の小さい用途から標準化しましょう。
次にやるべきこと
Azure SQL updates for Juneは、Azure SQLを使う開発者と管理者にとって、VS Code中心の開発・運用体験へ移る流れを後押しする更新です。特にSQL Notebooksは、単なるSQL実行ツールではなく、SQL、説明、結果、分析をまとめて再利用できる実行型ドキュメントとして活用できます。
まず取り組むべきことは明確です。
- 検証環境でMSSQL extensionとSQL Notebooksを試す
- 本番接続では読み取り専用権限を基本にする
- Notebookの出力結果を共有・コミットするルールを決める
- Copilot生成SQLをレビュー必須にする
- Azure Data Studio利用者はVS Code移行計画を更新する
- 正式なDB変更はNotebookではなく、CI/CDやマイグレーション手段と分けて管理する
この順番で進めれば、Azure SQLの運用を安全に保ちながら、調査・検証・ドキュメント化のスピードを上げられます。
コメント