Azure SQLのGitHub Copilot連携がGAに：Schema Designer更新の変更点と管理者向け確認ポイント

Azure SQLでアプリ開発をしている人にとって、今回のポイントは「Azure SQL本体の仕様変更」ではなく、Visual Studio CodeのMSSQL extensionにあるSchema Designerで、GitHub Copilotを使ったスキーマ設計支援が一般提供になったことです。

これにより、テーブル・列・リレーションを自然言語で作成したり、既存スキーマの変更案をCopilotに出させたり、変更差分を確認してからデータベースへ反映したりしやすくなります。一方で、AIが生成したスキーマをそのまま本番環境へ適用するのは危険です。管理者と開発者は、Copilotの利用可否、接続先環境、変更レビュー、ORMマイグレーションとの整合性を事前に確認してから展開する必要があります。MicrosoftのAzure Updatesでは、この機能がMSSQL extension for Visual Studio Codeで一般提供になったことが案内されています。(マイクロソフトアジュール)

Azure SQLのAI/Copilot更新で何が変わるのか

今回の更新では、MSSQL extension for Visual Studio CodeのSchema DesignerにおけるGitHub Copilot連携が一般提供されました。Schema Designerは、Azure SQLやSQL ServerのスキーマをVisual Studio Code上で視覚的に扱うための機能です。Microsoft Learnでは、MSSQL extensionがAzure SQL Database、Azure SQL Managed Instance、SQL Server on Azure Virtual Machines、SQL database in Microsoft Fabric、SQL Serverに対応し、接続、スキーマ設計、T-SQL実行、実行プラン確認などを支援すると説明されています。(Microsoft Learn)

今回のGitHub Copilot連携により、Schema Designer上で次のような作業がしやすくなります。

変更点	できること	実務での使いどころ
自然言語によるスキーマ作成	「ECサイト用の注文・商品・顧客テーブルを作成して」のような指示からテーブルやリレーションを生成	新規アプリの初期設計、PoC、要件整理
既存スキーマの変更支援	列追加、テーブル名変更、データ型変更、リレーション追加などを会話形式で指示	仕様変更への対応、設計案のたたき台作成
変更差分の確認	追加・削除・変更されるオブジェクトを適用前に確認	レビュー、誤反映の防止
ORMマイグレーション生成	Prisma、Sequelize、TypeORM、Drizzle、SQLAlchemy、Entity Framework Core向けの移行用コードを生成	アプリケーションコードとDB変更の同期
外部アーティファクトの取り込み	JSON、ドキュメント、画像などをもとにスキーマ要素を生成	APIレスポンスからのテーブル設計、既存仕様書のモデル化
ガードレールによる検証	主キー不足、無効なデータ型、正規化上の懸念などを警告	初期設計ミスの早期発見

Microsoft Learnでは、自然言語からテーブル・列・リレーションを生成できること、既存スキーマを会話形式で変更できること、ORM向けのマイグレーションスクリプトを生成できること、AI提案を個別に確認してAcceptまたはUndoできることが説明されています。(Microsoft Learn)

今回の更新はAzure SQL本体の自動変更ではない

まず押さえるべきなのは、今回の一般提供がAzure SQLのデータベースエンジンそのものを自動的に変更するものではないという点です。

対象は、Visual Studio Codeで利用するMSSQL extensionの開発体験です。Azure SQL DatabaseやAzure SQL Managed Instanceなどに接続し、Schema Designer上で設計・変更・レビューを行う流れが強化されます。

そのため、既存のAzure SQL環境に対して、今回の更新だけで次のような変更が勝手に発生するわけではありません。

既存テーブルや列が自動変更される
本番データベースにAIの提案が自動適用される
SQL Server Management Studioの操作画面が変更される
Azure Portal上の設定が自動的に変わる
GitHub Copilotの利用権限が全ユーザーへ自動付与される

一方で、開発者がVisual Studio CodeからAzure SQLへ接続し、Schema Designerで変更を作成・発行する運用をしている場合は、データベース変更フローに影響します。特に本番接続が可能な開発端末では、AIが提案したスキーマ変更を人間が十分に確認せずに適用してしまうリスクがあります。

対象となる利用者と影響範囲

今回の影響を受けやすいのは、Azure SQLをバックエンドにしたアプリケーション開発チームです。特に、Visual Studio Code中心で開発しているチーム、GitHub Copilotを導入済みのチーム、ORMマイグレーションを利用しているチームでは確認が必要です。

対象者	影響	確認すべきこと
アプリケーション開発者	自然言語でスキーマ設計案を作れるようになる	生成されたDDLやORMコードをレビューする手順
DB管理者	開発者がDB変更を作成しやすくなる	本番DBへの接続権限、変更承認フロー
DevOps担当者	ORMマイグレーションやCI/CDとの接続が増える	リポジトリ管理、レビュー、デプロイ手順
セキュリティ担当者	AI利用時のデータ取り扱い確認が必要になる	機密情報をプロンプトに含めないルール
情シス・管理者	Copilot利用ライセンスや拡張機能展開の統制が必要	VS Code拡張機能の配布、利用ポリシー

影響が大きいのは、「DB設計を一部のDBAだけが行う」運用から、「アプリ開発者も日常的にスキーマ変更案を作る」運用へ移行している組織です。Copilot連携により初期案の作成は速くなりますが、設計責任がAIに移るわけではありません。

利用前に必要な前提条件

Schema DesignerでGitHub Copilot連携を使うには、開発端末側でいくつかの前提を満たす必要があります。Microsoft Learnでは、MSSQL extensionのインストール、GitHub CopilotおよびGitHub Copilot Chat拡張機能のインストールとサインイン、MSSQL extension経由の有効なデータベース接続が前提条件として示されています。(Microsoft Learn)

項目	確認内容
Visual Studio Code	開発者端末にインストールされているか
MSSQL extension	最新版または組織で承認したバージョンを利用しているか
GitHub Copilot	利用可能なサブスクリプションがあるか
GitHub Copilot Chat	VS Code上でサインイン済みか
Azure SQL接続	開発・検証・本番の接続先が明確に分かれているか
権限	スキーマ変更が必要な環境だけに権限を付与しているか

特に注意したいのは、本番DBへの接続権限を持つ開発者が、Schema Designerから直接変更を発行できる状態になっていないかです。AI支援の有無にかかわらず、スキーマ変更はアプリケーション全体へ影響します。検証環境で生成・確認し、コードレビューと承認を経て本番へ反映する流れを維持するべきです。

Schema DesignerでCopilotを使う基本的な流れ

実際の利用イメージは、次の流れです。

手順	操作	確認ポイント
1	VS CodeでMSSQL extensionを開く	対象DBへの接続が正しいか確認する
2	Object Explorerから対象データベースを選択	開発・検証・本番を取り違えない
3	Schema Designerを開く	既存スキーマが正しく読み込まれているか確認する
4	Copilotチャットで変更内容を指示	曖昧な指示を避け、要件を具体化する
5	生成されたテーブル・列・リレーションを確認	主キー、外部キー、NULL許可、データ型を見る
6	差分ビューで変更内容を確認	削除や型変更など破壊的変更がないか確認する
7	必要に応じてORMマイグレーションを生成	利用中のフレームワークに合うか確認する
8	レビュー後に適用またはリポジトリへ反映	チームの変更管理ルールに従う

Schema Designer自体は、データベースを右クリックして開き、テーブル構造やリレーションを視覚的に確認・編集できます。変更後はPublish Changesで変更サマリーを確認し、DacFXを使ってスキーマ更新をデプロイする流れが説明されています。(Microsoft Learn)

Copilotに投げる指示は「要件」まで書くと精度が上がる

Copilotを使うときに失敗しやすいのは、プロンプトが短すぎるケースです。

たとえば、次の指示では不十分です。

予約システムのテーブルを作って

これだけでは、予約対象が会議室なのか、飲食店なのか、ホテルなのか分かりません。キャンセル、利用者、料金、時間帯、在庫制御の考慮も曖昧です。

実務では、次のように書く方がレビューしやすいスキーマ案になります。

社内会議室予約システム用のスキーマを作成してください。
利用者、会議室、予約、設備、予約参加者を管理します。
予約は開始日時と終了日時を持ち、同じ会議室で時間が重複しないようにしたいです。
利用者は部署とメールアドレスを持ちます。
各テーブルには主キー、作成日時、更新日時を含めてください。

さらに、既存チームの命名規則がある場合は明示します。

テーブル名は複数形ではなく単数形にしてください。
主キーはId、外部キーは{参照先テーブル名}Idの形式にしてください。
文字列は基本的にNVARCHARを使い、説明文はNVARCHAR(500)にしてください。

Copilotは初期案の作成には便利ですが、チーム固有の設計ルール、監査要件、パフォーマンス要件までは自動で完全に理解できません。プロンプトには、業務要件だけでなく、命名規則、必須列、監査列、削除方針、ユニーク制約、データ保持期間なども含めると実務で使いやすくなります。

管理者が確認すべき設定と運用ルール

管理者が最初に確認すべきなのは、「誰が」「どの環境で」「どこまで」Copilot支援のスキーマ変更を使えるかです。

GitHub Copilotの利用範囲を決める

GitHub Copilotは開発生産性を上げる一方で、組織のAI利用ポリシーに関わります。DBスキーマには、業務内容や個人情報の扱いが推測できる情報が含まれる場合があります。

最低限、次のルールは明文化しておくべきです。

ルール	具体例
機密データをプロンプトに入れない	実データ、顧客名、個人情報、認証情報を貼り付けない
本番DBで直接試さない	開発・検証用DBで設計と差分確認を行う
AI生成結果を必ずレビューする	DDL、制約、インデックス、リレーションを人が確認する
破壊的変更は承認制にする	列削除、型変更、NOT NULL化、リネームはDBAレビュー必須
ORMマイグレーションをリポジトリ管理する	生成コードをそのまま適用せずPull Requestで確認する

VS Code拡張機能のバージョンをそろえる

チームでMSSQL extensionのバージョンがばらつくと、画面や生成結果、サポートされる機能に差が出る可能性があります。特にGA直後の機能を組織展開する場合は、開発者ごとに異なる挙動が出ないよう、利用バージョンをそろえることが重要です。

管理者は次の点を確認しましょう。

標準開発環境に含めるMSSQL extensionのバージョン
GitHub Copilot / GitHub Copilot Chatの導入可否
VS Code設定の配布方法
拡張機能の自動更新を許可するか、検証後に更新するか
社内プロキシやネットワーク制限でCopilotが利用できるか

小規模チームなら自動更新でも大きな問題になりにくいですが、金融、医療、公共、基幹システムなどでは「検証済みバージョンを一定期間固定する」運用の方が安全です。

接続先の取り違えを防ぐ

Schema Designerはスキーマ変更を扱うため、接続先の取り違えが重大事故につながります。AI支援機能が便利になるほど、操作の心理的ハードルは下がります。

接続管理では、次のような対策が有効です。

本番DBへのDDL権限を開発者に常時付与しない
開発、検証、本番で接続グループ名や色を分ける
本番接続は読み取り専用アカウントを基本にする
スキーマ変更はCI/CDまたはDBA承認経由にする
接続文字列をローカルに不用意に保存しない

「Copilotが提案したから安全」ではなく、「本番に反映できる権限を誰が持っているか」を基準に管理することが大切です。

開発者が確認すべきレビュー観点

開発者は、Copilotが生成したスキーマ案を「完成品」ではなく「レビュー対象のたたき台」として扱うべきです。

特に次の観点は必ず確認しましょう。

確認観点	見るべきポイント	失敗例
主キー	全テーブルに適切な主キーがあるか	中間テーブルに主キーがない
外部キー	関係が正しい向きで定義されているか	注文詳細から注文へのFKがない
データ型	金額、日時、文字列長が適切か	金額がINT、説明文が短すぎる
NULL許可	必須項目がNULL許可になっていないか	メールアドレスがNULL可能
ユニーク制約	重複してはいけない値を制御しているか	ユーザーのメールアドレスが重複可能
削除方針	カスケード削除の影響が適切か	親削除で履歴が消える
命名規則	チームの規約に合っているか	snake_caseとPascalCaseが混在
インデックス	検索条件や結合条件に対応しているか	外部キー列にインデックスがない
監査列	CreatedAt、UpdatedAtなどが必要か	変更履歴を追跡できない
マイグレーション	既存データに影響しないか	NOT NULL列追加で既存行が失敗する

Microsoft Learnでも、GitHub Copilotの出力は誤ったり最適ではないスキーマ提案になる可能性があるため、生成されたSQLやスキーマ変更は公開前に必ずレビューするよう注意されています。(Microsoft Learn)

ORMマイグレーションを使うチームでの注意点

今回の更新で実務上特に便利なのが、ORMマイグレーション生成です。Microsoft Learnでは、Prisma、Sequelize、TypeORM、Drizzle、SQLAlchemy、Entity Framework Coreがサポート対象として示されています。(Microsoft Learn)

ただし、ORMマイグレーションは便利な反面、DBの実態とアプリケーションコードの状態がずれるとトラブルになります。

たとえば、Schema Designerで生成した変更をDBへ直接適用し、その後にORM側のマイグレーションファイルを別途作ると、次のような問題が起きやすくなります。

ローカル環境では動くが、CI/CDでマイグレーションが失敗する
既に適用済みの変更をORMが再適用しようとする
DBには列があるのにモデル定義に存在しない
本番DBと開発DBでマイグレーション履歴がずれる
ロールバック手順が不明になる

安全に運用するなら、次のどちらかに統一しましょう。

運用方針	向いているケース	注意点
ORMマイグレーション中心	アプリコード主導でDB変更を管理するチーム	Schema Designerの変更はマイグレーションファイルとしてレビューする
DACPAC / DDL中心	DBA主導でDBスキーマを管理するチーム	ORMモデルとの整合性を別途確認する
ハイブリッド	大規模組織、複数チーム開発	どの変更をどちらで管理するかルール化しないと破綻しやすい

おすすめは、Copilotで設計案を作る → 差分を確認する → ORMマイグレーションを生成する → Pull Requestでレビューする → CI/CDで検証DBへ適用するという流れです。生成されたコードをローカルから本番へ直接流すのは避けましょう。

移行・展開時に注意すべきポイント

今回の機能はGAですが、組織としてすぐ全員に解放するより、段階的に展開する方が安全です。

まずは開発・検証環境で試す

最初に試すべき環境は、本番データを含まない開発用Azure SQLです。既存の本番スキーマをコピーした検証環境で試す場合も、個人情報や機密データを含まないように注意します。

検証では、次のシナリオを実施すると実用性を判断しやすくなります。

空のデータベースから新規スキーマを生成する
既存テーブルへ列を追加する
テーブル名や列名の変更案を生成する
JSONサンプルからテーブルを作成する
ORMマイグレーションを生成してアプリ側で実行する
差分レビューで破壊的変更を検出できるか確認する

本番反映は従来の変更管理に乗せる

Copilotが生成した変更でも、人間が書いたDDLでも、本番DBに反映するリスクは同じです。特に次の変更は慎重に扱う必要があります。

変更	リスク	対策
列削除	アプリやレポートが参照していると障害になる	利用状況調査、段階的廃止
データ型変更	既存データが変換できない可能性	事前検証、バックアップ、変換SQL確認
NOT NULL制約追加	既存行にNULLがあると失敗	デフォルト値投入、データクレンジング
テーブル名・列名変更	アプリコードやSQLが壊れる	互換ビュー、段階的移行
外部キー追加	不整合データがあると適用できない	事前整合性チェック
カスケード削除	想定外のデータ削除	削除ルールの明示レビュー

Copilotの差分レビューは便利ですが、業務影響の判断までは自動化できません。アプリケーション、バッチ、BI、外部連携、監査要件まで含めて確認する必要があります。

セキュリティとガバナンスで見落としやすい点

AI支援のDB設計で見落としやすいのは、スキーマ情報そのものが業務情報を含む点です。

たとえば、次のようなテーブル名や列名は、データの中身を見なくても業務内容を推測させます。

CustomerCreditScreening
MedicalDiagnosisHistory
EmployeeSalary
FraudInvestigation
CancellationReason

そのため、Copilotへ与えるプロンプトや外部アーティファクトには注意が必要です。実データを含むJSON、顧客名が入った仕様書、社外秘の画面設計書などを無造作に貼り付ける運用は避けるべきです。

管理者は、少なくとも次の3つを決めておくと安全です。

Copilotに入力してよい情報と禁止情報
開発者が接続してよいDB環境
AI生成物をレビューする責任者

特に規制業界では、GitHub Copilotの契約プラン、データ取り扱い、組織ポリシーも確認対象になります。技術的に使えることと、組織として使ってよいことは別です。

活用しやすいシーン

今回のGitHub Copilot integration in Schema Designerは、次のような場面で効果を発揮します。

新規アプリのデータモデルを素早くたたき台化する

新規サービスの初期検討では、最初から完璧なDB設計を作るより、業務エンティティを可視化して議論する方が有効です。Copilotに自然言語で業務要件を伝えれば、初期のテーブル構成やリレーション案を作れます。

たとえば、予約管理、在庫管理、問い合わせ管理、学習管理、社内申請など、よくある業務ドメインでは初期案作成の時間短縮が期待できます。

APIレスポンスやJSONからスキーマ案を作る

外部システムのJSONレスポンスをAzure SQLに保存したい場合、ネスト構造をどうテーブルに分けるか悩むことがあります。Schema DesignerのCopilot連携では、JSONやドキュメントなどの外部情報をもとにスキーマ要素を生成できるため、データ取り込み設計のたたき台を作りやすくなります。(Microsoft Learn)

ただし、生成結果はあくまで初期案です。正規化しすぎてクエリが複雑にならないか、逆にJSONをそのまま保持すべき項目はないか、検索条件に合うインデックスが必要かを確認しましょう。

ORM中心の開発でDB変更を見える化する

Node.js、TypeScript、Python、.NETなどでORMを使っているチームでは、DBスキーマがコードだけに閉じてしまい、非開発者やDBAが構造を把握しにくいことがあります。

Schema Designerを使えば、視覚的な図で構造を確認しながら、ORM向けのマイグレーション生成にもつなげられます。コードレビュー時に、マイグレーションファイルだけでなく図や差分を合わせて確認できると、レビュー品質が上がります。

逆に向いていない使い方

便利な機能ですが、すべてのDB変更をCopilotに任せるべきではありません。

次のようなケースでは慎重に扱いましょう。

金融取引や医療情報など、高い厳密性が必要なスキーマ
既存データ量が大きく、型変更や制約追加の影響が大きいDB
複数システムが同じテーブルを参照している共有DB
監査・証跡・法令対応が厳しい業務
パフォーマンス要件が厳しく、インデックス設計が重要なシステム
既存のDB設計標準が複雑な組織

このような環境では、Copilotは「案を出す補助」として使い、最終設計はDBAやアーキテクトがレビューする体制が必要です。

導入前チェックリスト

組織で展開する前に、次のチェックリストを確認してください。

チェック項目	完了の目安
Copilot利用ポリシーを確認した	入力禁止情報、利用可能者、対象環境が決まっている
MSSQL extensionの利用バージョンを決めた	チームで同じ前提で検証できる
開発・検証・本番接続を分離した	誤って本番に変更しにくい
本番DBのDDL権限を制限した	開発者が直接破壊的変更を適用できない
スキーマ変更レビュー手順を決めた	PR、DBAレビュー、CI/CD検証がある
ORMマイグレーション方針を決めた	DB直接変更とORM管理が衝突しない
破壊的変更の承認ルールを決めた	列削除、型変更、リネームを別扱いにしている
サンプルDBで検証した	生成結果、差分、発行手順を確認済み
開発者向けのプロンプト例を用意した	命名規則や必須列を指示できる
ロールバック方針を確認した	失敗時の戻し方が明確

開発チーム向けの実用プロンプト例

実際に使い始めるなら、次のようなプロンプトをチーム標準として用意しておくと便利です。

新規スキーマを作る

BtoB向け問い合わせ管理システムのスキーマを作成してください。
会社、担当者、問い合わせ、問い合わせコメント、対応担当者を管理します。
問い合わせにはステータス、優先度、受付日時、解決日時を持たせます。
各テーブルには主キー、作成日時、更新日時を含めてください。
テーブル名は単数形、主キーはId、外部キーは{テーブル名}Idにしてください。

既存スキーマへ監査列を追加する

すべての業務テーブルにCreatedAt、UpdatedAt、CreatedBy、UpdatedByを追加してください。
CreatedAtとUpdatedAtはDATETIME2を使い、CreatedByとUpdatedByはNVARCHAR(100)にしてください。
既存テーブルの主キーと外部キーは変更しないでください。
変更前に差分を確認できるようにしてください。

JSONからテーブル案を作る

次のJSONレスポンスをAzure SQLに保存するためのスキーマ案を作成してください。
ネストされた配列は別テーブルに分け、外部キーで関連付けてください。
検索条件になりそうな項目にはインデックス候補も提案してください。

変更レビューを依頼する

このスキーマ変更について、破壊的変更、NULL制約、データ型、外部キー、ユニーク制約、既存データへの影響の観点で問題点を指摘してください。
本番反映前に確認すべきSQLも提案してください。

ポイントは、Copilotに「作って」と頼むだけでなく、制約条件とレビュー観点を一緒に渡すことです。これにより、生成結果を人間が確認しやすくなります。

まず何をすべきか

今回のAzure SQL関連のCopilot更新は、DB設計作業をVisual Studio Code内でより速く、視覚的に、レビューしやすくするものです。特に、Schema DesignerとGitHub Copilotの組み合わせにより、自然言語からスキーマ案を作成し、差分を確認し、ORMマイグレーションへつなげる流れが実用段階に入りました。

ただし、導入で最も重要なのは機能を試すことではなく、AI生成のスキーマ変更を既存の変更管理にどう組み込むかです。

最初のアクションとしては、次の順番がおすすめです。

開発用Azure SQLまたは検証DBを用意する
VS Code、MSSQL extension、GitHub Copilot Chatの利用条件を確認する
既存の簡単なスキーマでCopilotによる変更案を試す
差分ビューとORMマイグレーション生成を確認する
本番反映ルール、レビュー担当、禁止事項を決める

CopilotはDB設計者の代替ではなく、設計・レビュー・実装を速くする補助役です。Azure SQL環境で安全に活用するには、開発者の生産性向上と、管理者のガバナンスをセットで整えることが重要です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。