Azure SQLをSQL Server Management Studio（SSMS）で管理しているチームにとって、GitHub Copilot in SQL Server Management Studioは「SQLを書く補助ツール」だけではありません。SSMSの画面内で、T-SQL作成、クエリの説明・修正・最適化、SQLに関する質問、管理タスクの相談まで行えるAI支援機能です。
結論から言うと、Azure SQL側のデータベースエンジンが直接変わる更新ではなく、SSMS 22以降の操作体験と開発・運用フローが変わる更新です。導入前に確認すべきポイントは、SSMSのバージョン、AI Assistanceワークロードの有無、GitHub Copilotのライセンス、データベース権限、組織のCopilotポリシー、ネットワーク制限、監査・ログの扱いです。Microsoft Learnの概要ページは2026年5月末時点で更新されており、同ページ上の最終更新日は2026年5月29日と表示されています。(Microsoft Learn)
Azure SQLのAI/Copilot更新で何が変わるのか、利用者と管理者向けに整理
GitHub Copilot in SQL Server Management Studioは、SSMS上でAzure SQL Database、Azure SQL Managed Instance、SQL Server、SQL Database in Fabricなどに対して利用できるAIアシスタントです。公式ドキュメントでは、T-SQLをより速く正確に書く支援、一般的なSQLの質問への回答、管理タスクの補助をSSMS内で行えると説明されています。(Microsoft Learn)
重要なのは、Copilotが「独自の特権ユーザー」として動くわけではない点です。Copilotが生成・実行するクエリは、接続しているユーザーのログイン権限に従います。たとえば、利用者に特定テーブルのSELECT権限がなければ、Copilotにそのテーブルを参照するSQLを依頼しても実行はできません。(Microsoft Learn)
そのため、Azure SQLの管理者がまず行うべきことは「Copilotを使わせるかどうか」だけでなく、既存のAzure SQL権限設計がそのままAI支援時の安全境界になると理解し、最小権限の見直しを行うことです。
| 変更・機能 | できること | 影響を受ける人 | 確認すべきポイント |
|---|---|---|---|
| Copilot Chat | 自然言語でSQLやDBに関する質問をする | 開発者、DBA、運用担当者 | 接続先DB、ログイン権限、質問内容の粒度 |
| インラインチャット | エディター内でSQLの追加・修正を依頼する | T-SQLを書く担当者 | 生成差分を確認してから適用する |
| スラッシュコマンド | /doc、/explain、/fix、/optimizeでSQLを説明・修正・最適化する | 開発者、レビュー担当者 | 本番反映前のレビュー手順 |
| コード補完 | 入力中のT-SQLに候補を表示する | 開発者 | SSMSバージョン、補完設定、誤補完の確認 |
| データベースコンテキスト | 接続中DBやエディター内容をもとに回答する | 全利用者 | 想定外のDBに接続していないか |
| 管理者制御 | 組織単位の有効化・無効化、モデル利用、展開制御 | IT管理者、セキュリティ担当 | GitHub側のポリシー、ライセンス、展開方式 |
GitHub Copilot in SSMSはAzure SQLの何を支援するのか
Azure SQLでの主な活用場面は、日々の開発・調査・運用補助です。たとえば、テーブル構造を踏まえたSELECT文の作成、既存クエリの説明、構文エラーの修正、クエリの改善案、互換性レベルやブロッキングに関する質問などが想定されます。
公式の概要では、チャットウィンドウとインラインチャットの両方から自然言語でデータベースに関する質問やT-SQL作成支援を利用できるとされています。また、SSMS 22.2以降ではクエリエディター内のオートコンプリートも含まれます。(Microsoft Learn)
開発者にとっての変化
開発者にとって大きいのは、SSMSから離れずに「調べる」「書く」「直す」「説明する」作業を進められることです。
たとえば、次のような作業で効果が出やすくなります。
- 既存の長いSQLを選択し、何をしているか説明させる
- エラーが出ているT-SQLを選択し、修正案と理由を出させる
- コメントで「過去30日間の注文数を顧客別に集計」と書き、クエリ候補を生成する
- レビュー前に
/docでコメントを追加する /optimizeで明らかなアンチパターンを洗い出す
ただし、Copilotの提案はそのまま正解とは限りません。Microsoftのベストプラクティスでも、曖昧な質問は曖昧な回答につながるため、対象テーブル、期間、列、出力形式を具体的に指定することが推奨されています。(Microsoft Learn)
管理者にとっての変化
管理者にとってのポイントは、Copilotの導入が「便利機能の追加」ではなく、開発・運用端末にAI支援を組み込む変更であることです。
特に確認すべきなのは、次の3点です。
| 管理観点 | 確認内容 | 実務での判断基準 |
|---|---|---|
| 権限 | Copilot利用者がAzure SQL上で持つ権限 | 本番DBでは読み取り専用や必要最小限に限定する |
| 展開 | SSMS 22とAI Assistanceワークロードを配布するか | 開発端末、検証端末、本番運用端末を分けて展開する |
| ポリシー | GitHub Copilotの組織設定、モデル、データ利用設定 | Business/Enterprise契約と個人契約の混在を避ける |
SSMSのCopilot Chatでは、Ask modeで生成されたクエリが読み取り専用かどうかを分類する仕組みがあります。ただし、Microsoftはこの分類システムをセキュリティ境界として扱わず、SQL Server側の権限管理、つまり最小権限の原則でアクセス制御を行うべきだと明記しています。(Microsoft Learn)
利用前に必要な前提条件
GitHub Copilot in SSMSを利用するには、基本的にSSMS 22、AI Assistanceワークロード、Copilotアクセスを持つGitHubアカウントが必要です。Visual Studio InstallerからSSMSのインストールを変更し、WorkloadsタブでAI Assistanceを選択して追加します。(Microsoft Learn)
| 項目 | 必要条件 | 補足 |
|---|---|---|
| SSMS | SQL Server Management Studio 22以降 | 最新機能を使うには更新が必要 |
| インストール構成 | AI Assistanceワークロード | Visual Studio Installerで追加・削除できる |
| アカウント | GitHub CopilotにアクセスできるGitHubアカウント | 個人・組織契約の違いを確認 |
| 対象DB | Azure SQL Database、Azure SQL Managed Instanceなど | 接続ユーザーの権限で動作 |
| ネットワーク | GitHub Copilotサービスへ接続可能 | プロキシ、ファイアウォール環境では要確認 |
SSMS 22以降では、右上のCopilotステータスアイコンで、Copilotがactive、inactive、unavailable、not installedのどの状態かを確認できます。未サインイン、サブスクリプション不足、管理者による無効化、ネットワーク問題などで利用できない場合があるため、展開後の問い合わせ対応ではこのステータス確認が最初の切り分けになります。(Microsoft Learn)
コード補完は有効化状態を必ず確認する
開発者が見落としやすいのが、コード補完の有効化設定です。
GitHub Copilotのコード補完は、T-SQL入力中にゴーストテキストとして候補を表示する機能です。SSMS 22.2以降とAI Assistanceワークロード、GitHub Copilotアクセスが前提で、設定はTools > Options > Text Editor > Inline Suggestions > Generalから確認します。(Microsoft Learn)
さらに、SSMS 22.5.2のリリースノートでは、コード補完が既定で無効化されたことが説明されています。以前に補完オプションを変更していた環境では更新後も無効化されない場合があるため、社内で端末ごとの挙動が違うように見えることがあります。(Microsoft Learn)
| 状況 | 起きやすい問題 | 対応 |
|---|---|---|
| 新規インストール後 | Copilot Chatは使えるが補完が出ない | Inline Suggestions設定でCopilot completionsを有効化 |
| 更新後 | 端末により補完の有無が異なる | 既存設定の引き継ぎ状況を確認 |
| 補完が頻繁に出る | 入力の邪魔になる | 表示タイミングや手動呼び出しに変更 |
| 候補を誤って採用する | 意図しないSQLになる | Tab適用前に必ず差分・文脈を確認 |
補完を使う場合は、開発チーム内で「候補は採用前に読む」「本番向けSQLはレビューを通す」「コメントだけで複雑なSQLを生成させた場合はテストデータで検証する」といったルールを決めておくと安全です。
Copilot Chatは結果表示ウィンドウの代わりにしない
Copilot Chatは便利ですが、結果グリッドの代替として使うべきではありません。Microsoftのベストプラクティスでは、Copilotにスキーマやデータに関する質問をすると、クエリを直接実行してチャット内に情報を返すことがある一方、実行前に返却行数を判断するわけではないと説明されています。大きな結果セットはチャット内で読みづらく、操作もしにくいため、必要な情報を返すクエリを書かせる方が望ましいとされています。(Microsoft Learn)
実務では、次のように依頼すると安全です。
| 避けたい聞き方 | 改善した聞き方 |
|---|---|
| このDBの売上を見せて | 売上集計に必要な読み取り専用T-SQLを作成し、実行前の確認点も説明して |
| 遅いクエリを調べて | Query Storeを使って過去24時間の実行時間上位クエリを確認するSQLを作成して |
| このテーブルを最適化して | インデックス候補を検討するための確認SQLと、判断基準を一覧で説明して |
| 権限を直して | 現在のユーザー権限を確認する読み取り専用SQLを作成して |
本番環境では、Copilotに直接「実行して」と頼むよりも、まずSQLを生成させ、管理者またはレビュアーが内容を確認してから実行する運用にした方が安全です。
Azure SQLで特に注意したい権限とセキュリティ
Copilotの利用可否と、Azure SQLで実際に何ができるかは別の問題です。CopilotがSSMS内で回答を生成できても、データベース操作は接続ユーザーの権限に制限されます。つまり、Azure SQL側で広すぎる権限を付与していると、Copilot経由でもその権限範囲の操作が可能になります。(Microsoft Learn)
管理者は、少なくとも次の観点を確認してください。
| 確認項目 | 理由 | 推奨対応 |
|---|---|---|
| 本番DBへの接続権限 | Copilotの提案を本番で実行できてしまう | 本番は読み取り専用、または承認済み管理者に限定 |
| db_ownerの付与状況 | 生成SQLの影響範囲が広がる | 開発者に恒常的なdb_ownerを与えない |
| 機密テーブルへのSELECT権限 | Copilotへの質問で意図せず参照される可能性 | 個人情報・機密情報は列単位、ビュー単位で制御 |
| 変更系SQLの実行ルール | ALTER、UPDATE、DELETEなどの事故防止 | 本番反映はレビュー・チケット・変更管理を必須化 |
| 監査・ログ | Copilot経由の調査内容を追跡するため | Extended Eventsや既存監査と組み合わせる |
Copilotの安全性を「AI側の制御」に任せるのではなく、Azure SQLの認証・認可、監査、変更管理で守ることが基本です。
管理者が確認すべきCopilotの組織設定
組織利用では、GitHub側のCopilot設定も重要です。管理者は、個別アカウントまたは組織全体でGitHub Copilotを有効化・無効化できます。Copilot BusinessやEnterpriseでは、組織またはEnterprise設定でアクセスを管理し、ライセンス割り当てによって利用者を制御します。(Microsoft Learn)
また、モデルの利用可否にも注意が必要です。Copilot EnterpriseおよびBusinessでは、SSMSでプレビューモデルを利用する前にGitHub.com側のCopilot設定でPreview policyを有効化する必要があるとされています。(Microsoft Learn)
| 管理設定 | 確認ポイント |
|---|---|
| Copilotの有効化・無効化 | 組織全体、部門単位、個別ユーザー単位で方針を決める |
| ライセンス割り当て | 個人契約と組織契約が混在しないようにする |
| パブリックコード一致候補のブロック | コード提案の扱いに関する社内ルールと合わせる |
| モデル利用ポリシー | プレビューモデルを許可するか、標準モデルに限定するか決める |
| データ利用・プライバシー設定 | 契約種別ごとのデータ扱いを確認する |
| SSMS展開方式 | Intune、SCCM、オフラインレイアウトでAI Assistanceを含めるか決める |
データ利用については、公式ページ間で確認すべき範囲が分かれます。SSMSの概要ページでは、GitHub Copilot in SSMSがプロンプト、応答、システムメタデータなどを保持せず、モデルの学習・再学習に使わないと説明されています。一方、管理者向けページでは、2026年4月24日以降、Copilot Free、Pro、Pro+ユーザーのインタラクションデータは、オプトアウトしない限りモデル改善に使われると説明され、BusinessとEnterpriseは影響を受けないとされています。組織利用では、概要ページだけで判断せず、契約種別とGitHub側のプライバシー設定まで確認するのが安全です。(Microsoft Learn)
モデル選択とBYOMはコスト・統制に影響する
SSMS 22のGitHub Copilotは、サブスクリプションに応じて既定モデルを選択しますが、要件に応じてモデルピッカーから別のモデルを選べる場合があります。利用可能なモデルはサブスクリプションや各モデルの提供状況によって変わるため、社内標準手順書には「特定モデル名を固定で書く」よりも、「利用可能なモデルと組織ポリシーを確認する」と記載する方が保守しやすくなります。(Microsoft Learn)
BYOM、つまり独自モデルの持ち込みも用意されています。Azure OpenAIなどのプロバイダーのAPIキーやエンドポイント情報を使ってカスタムモデルを追加できますが、公式ドキュメントではカスタムモデルのサポートはCopilot Chatに限定されること、プロバイダー側のモデル能力に依存すること、出力がGitHub Copilotの責任あるAIフィルタリングを迂回する可能性があること、Copilot BusinessまたはEnterpriseユーザーではカスタムモデルが利用できないことが注意点として挙げられています。(Microsoft Learn)
つまり、BYOMは「自由度が高いから使う」ものではなく、セキュリティ、監査、コスト、サポート範囲を整理したうえで限定的に検証すべき機能です。
Database instructionsはAzure SQL運用で効果が出やすい
Azure SQLで複数人が同じデータベースを扱う場合、Copilotに毎回業務ルールを説明するのは非効率です。そこで重要になるのがDatabase instructionsです。
Database instructionsは、データベース固有の業務ルール、データの意味、利用パターンをデータベース内のメタデータとして持たせ、Copilotが回答やT-SQL生成時に参照できるようにする仕組みです。公式ドキュメントでは、拡張プロパティを利用し、Copilotとのやり取りに追加コンテキストとして反映されると説明されています。(Microsoft Learn)
たとえば、売上の定義が「売上テーブルの金額合計から返金を差し引いたもの」である場合、単にRevenue列を合計するだけでは誤った集計になります。Database instructionsに定義を書いておけば、Copilotが将来の回答でその業務ルールを考慮しやすくなります。
ただし、Database instructionsは便利な反面、誤ったルールを保存するとチーム全体のCopilot回答に影響します。特に、公式ドキュメントではデータベースのconstitutionが、そのデータベースを使うすべてのGitHub Copilot in SSMS利用者との会話に適用されると説明されています。(Microsoft Learn)
実務では、次のように運用するのがおすすめです。
| 対象 | 書くべき内容 | 避けるべき内容 |
|---|---|---|
| テーブル | 業務上の意味、正規の参照先、集計時の注意 | 個人名、秘密情報、古い仕様 |
| 列 | コード値の意味、NULLの扱い、単位 | 一時的な運用メモ |
| ストアドプロシージャ | 利用目的、入力値の前提、実行上の注意 | 実行してはいけない条件が曖昧な説明 |
| constitution | SQL標準、禁止パターン、命名規則 | チームで合意していない個人ルール |
Database instructionsは、AI向けのドキュメントであると同時に、人間にとっても業務ルールを明文化するきっかけになります。Azure SQLの運用標準を整備するなら、Copilot導入と合わせて検討する価値があります。
展開・移行時の注意点
SSMS 22への移行やCopilot展開では、いきなり全社展開するより、開発環境から段階導入する方が安全です。SSMS 22は2026年時点の現行GAリリースとして案内されており、リリースノートではGitHub Copilot関連の追加・修正も継続的に行われています。たとえば、22.4.1ではGitHub Copilot in SSMSの一般提供、22.5.0では結果ペインとの連携やインライン候補のキーボードショートカット対応、22.5.2ではコード補完の既定無効化が記載されています。(Microsoft Learn)
推奨する展開順序
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 検証 | 検証用端末にSSMS 22とAI Assistanceを導入 | サインイン、チャット、補完、無効化手順を確認 |
| 権限確認 | Azure SQLのロール、ユーザー、接続先を棚卸し | 本番DBの過剰権限を削減 |
| ポリシー整備 | Copilot利用範囲、禁止事項、レビュー手順を文書化 | 開発者が迷わない運用ルールがある |
| 小規模展開 | 開発チームやDBAチームに限定展開 | 問い合わせ内容、誤用、効果を記録 |
| 本格展開 | Intune、SCCM、オフラインレイアウトなどで配布 | AI Assistanceの有無を管理者が制御できる |
| 継続運用 | リリースノートとCopilot設定を定期確認 | バージョン差異やポリシー変更を吸収できる |
エンタープライズ環境では、SSMSのオフラインインストールレイアウトを使って、SCCMやIntuneなどの管理ツールから展開できます。管理者はAI Assistanceを含めるかどうかを制御できるため、部門ごとに段階的に配布する運用にも向いています。(Microsoft Learn)
トラブル時に見るべきポイント
Copilotが使えない場合、原因はSSMS側だけとは限りません。GitHubアカウント、Copilotサブスクリプション、組織ポリシー、ネットワーク、サービス状態、資格情報の期限切れなどが関係します。
公式のトラブルシューティングでは、Copilotが一時的に到達不能になる理由として、ネットワーク問題、Copilotサービス停止、資格情報の更新要求、管理者による無効化などが挙げられています。(Microsoft Learn)
| 症状 | 主な原因 | 確認場所 |
|---|---|---|
| Copilotがinactive | 未サインイン、ライセンスなし、別GitHubアカウントでサインイン | SSMS右上のCopilotバッジ |
| Copilotがunavailable | ネットワーク、サービス障害、期限切れプラン | GitHub Status、社内プロキシ設定 |
| 補完だけ出ない | Inline Suggestionsが無効 | SSMSのText Editor設定 |
| 組織ユーザーだけ使えない | GitHub側の組織ポリシー | GitHub Copilot設定 |
| 認証が不安定 | 資格情報の期限切れ | Refresh credentials、GitHubアカウント再追加 |
| 何を実行したか確認したい | Copilot経由のクエリ追跡が必要 | Extended Eventsでclient_app_nameを確認 |
Copilotが実行したクエリを監視したい場合は、Extended Eventsでclient_app_nameをフィルターします。チャットウィンドウからのクエリはMicrosoft SQL Server Management Studio - GitHub Copilot、コード補完関連はMicrosoft SQL Server Management Studio - Copilot Completionsを使って識別できるとされています。(Microsoft Learn)
開発者がすぐ使えるプロンプト例
Copilot in SSMSは、質問が具体的であるほど実務に使いやすい回答になります。Azure SQLで使う場合は、対象、期間、出力形式、読み取り専用かどうか、実行前に確認したい注意点を含めるのがコツです。
| 目的 | プロンプト例 |
|---|---|
| クエリ作成 | 接続中のAzure SQL Databaseで、過去30日間の注文数を顧客別に集計する読み取り専用T-SQLを作成してください。対象テーブルはSales.Orders、顧客テーブルはSales.Customersです。 |
| 既存SQLの説明 | 選択中のT-SQLが何をしているか、JOIN、WHERE条件、集計処理に分けて説明してください。 |
| エラー修正 | 選択中のT-SQLの構文エラーを修正し、変更点と理由を箇条書きで説明してください。 |
| パフォーマンス確認 | このクエリの実行計画を確認するときに見るべきポイントを、インデックス、推定行数、スキャン、ソートの観点で説明してください。 |
| 運用調査 | Azure SQLで現在ブロッキングが発生しているか確認するための読み取り専用SQLを作成し、実行結果の見方も説明してください。 |
| レビュー補助 | 選択中のT-SQLについて、可読性、保守性、パフォーマンス、権限リスクの観点でレビューしてください。 |
「このDBを見ていい感じに最適化して」のような依頼では、意図が広すぎます。Copilotに任せる範囲を狭め、最後の判断は人間が行う前提で使うことが重要です。
導入前チェックリスト
GitHub Copilot in SQL Server Management StudioをAzure SQL環境で使う前に、次の項目を確認してください。
| チェック項目 | 管理者 | 開発者 |
|---|---|---|
| SSMS 22以降を利用している | 必須 | 必須 |
| AI Assistanceワークロードを導入している | 必須 | 必須 |
| GitHub Copilotの契約種別を確認している | 必須 | 推奨 |
| 組織ポリシーで利用可否を制御している | 必須 | ー |
| Azure SQLの権限を最小化している | 必須 | 必須 |
| 本番DBでの利用ルールを定めている | 必須 | 必須 |
| コード補完の有効化状態を確認している | 推奨 | 必須 |
| 生成SQLのレビュー手順がある | 必須 | 必須 |
| Copilot経由のクエリ監視方法を確認している | 推奨 | ー |
| Database instructionsの管理者を決めている | 推奨 | 推奨 |
| Free/Pro/Business/Enterpriseのデータ利用差を確認している | 必須 | 推奨 |
| トラブル時の問い合わせ先を決めている | 必須 | 推奨 |
まとめ：まずは「便利に使う」より「安全に使える範囲」を決める
GitHub Copilot in SQL Server Management Studioは、Azure SQLの開発・運用を効率化できる強力な機能です。T-SQL作成、チャットでの調査、インライン修正、コード補完、Database instructionsなどにより、SSMS内での作業時間を短縮できます。
一方で、Copilotはデータベース権限や運用ルールの代わりにはなりません。クエリは接続ユーザーの権限で動作し、生成内容には誤りが含まれる可能性があります。特に本番のAzure SQLでは、最小権限、レビュー、監査、変更管理を前提に導入すべきです。
次に取るべき行動は明確です。まずSSMS 22とAI Assistanceワークロードの有無を確認し、開発環境でCopilot Chatとコード補完を検証します。そのうえで、GitHub Copilotの組織設定、Azure SQLの権限、補完の有効化状態、Database instructionsの運用方針を整理してから、本番運用端末への展開を判断しましょう。
コメント