Azure SQLをSQL Server Management Studio（SSMS）で扱っているなら、今回まず押さえるべき結論はシンプルです。GitHub Copilot in SQL Server Management Studioは、Azure SQLそのものにAIが組み込まれる変更ではなく、SSMS 22以降のクライアント上でT-SQL作成・調査・管理作業を支援するAI機能です。
使い始めるには、SSMS 22以降、AI Assistanceワークロード、GitHub Copilotを利用できるGitHubアカウントが必要です。特に管理者は、ライセンス、ネットワーク、データベース権限、監査、既存のSSMS 21向けCopilot構成との違いを確認してから展開すべきです。Microsoft Learnでは、GitHub Copilot in SSMSがT-SQLの作成、編集、回答、管理者タスクの提案をSSMS内で行うAIアシスタントとして説明されています。(Microsoft Learn)
Azure SQLのAI/Copilot更新で何が変わるのか
今回のポイントは、Azure SQL DatabaseやAzure SQL Managed InstanceをSSMSから操作する開発者・DBAが、SSMS上でGitHub Copilotの支援を受けやすくなったことです。SSMS 22はAzure SQL DatabaseやAzure SQL Managed Instanceに対応しており、SSMS 22系の最新リリースではGitHub Copilot関連の改善や修正も継続的に入っています。(Microsoft Learn)
一方で、Azure SQLの権限モデルや本番データベースの安全性が自動的に変わるわけではありません。Copilotが提案したクエリを使う場合も、実行するのは接続中のユーザーです。つまり、管理者が最初に見るべきなのは「Copilotを入れるかどうか」だけでなく、「誰が、どのDBに、どの権限で、どの範囲までAI支援を使うか」です。
| 観点 | 変更・確認ポイント | Azure SQL利用者への影響 |
|---|---|---|
| 利用環境 | SSMS 22以降でGitHub Copilotを利用 | 開発者のSSMS更新計画が必要 |
| インストール | Visual Studio InstallerでAI Assistanceワークロードを追加 | 標準PCイメージや配布手順の見直しが必要 |
| アカウント | GitHubアカウントとCopilot利用権限が必要 | Azureアカウントだけでは完結しない |
| T-SQL支援 | チャット、インラインチャット、コード補完、次の編集候補を利用 | クエリ作成・修正・調査の初動が速くなる |
| データベース文脈 | Database instructionsで業務ルールをDB側メタデータとして保持 | 売上定義、命名規則、利用禁止パターンなどを明示しやすい |
| セキュリティ | Copilot専用のDB権限はない | SQL Server/Azure SQL側の権限設計が重要 |
SSMS 21向けCopilotとの違いを混同しない
既存環境で注意したいのが、SSMS 21向けの「Copilot in SSMS」と、SSMS 22以降の「GitHub Copilot in SSMS」は前提が異なる点です。
Microsoftの旧Copilot in SSMSページでは、SSMS 21向けCopilotはSSMS 22のGitHub Copilotに置き換えられたと説明されています。SSMS 21向けのCopilotではAzure OpenAI in Microsoft Foundryのエンドポイントやデプロイメント設定が前提でしたが、SSMS 22以降のGitHub Copilot in SSMSではGitHubアカウントとCopilot利用権限を使う導線が中心です。(Microsoft Learn)
既にSSMS 21でAzure OpenAI連携を検証していた組織は、次の3点を分けて確認してください。
| 確認項目 | SSMS 21向けCopilot | SSMS 22以降のGitHub Copilot in SSMS |
|---|---|---|
| 主な前提 | Azure OpenAI in Microsoft Foundryのエンドポイント | GitHubアカウントとCopilot利用権限 |
| インストール | AI Assistanceワークロード | AI Assistanceワークロード |
| 利用開始 | Azure OpenAI設定を入力 | SSMS右上のCopilotバッジからサインイン |
| 管理観点 | Azureリソース、APIキー、Entra認証 | GitHub Copilotライセンス、組織ポリシー、ネットワーク |
移行時に「Azure OpenAIの設定があるから、そのままSSMS 22でも同じ動きになる」と考えると、展開計画がずれます。SSMS 22以降では、GitHub側のライセンス・ポリシー・認証設計を別途確認しましょう。
GitHub Copilot in SSMSで使える主な機能
GitHub Copilot in SQL Server Management Studioでは、自然言語のチャットだけでなく、T-SQLエディター上の補完や、データベース固有の業務ルールを反映する仕組みも用意されています。Microsoft Learnでは、Chat、Code Completions、Next Edit Suggestions、Database instructionsが主要機能として整理されています。(Microsoft Learn)
| 機能 | できること | 実務での使いどころ | 注意点 |
|---|---|---|---|
| Chat | SQLや接続中DBについて自然言語で質問 | クエリのたたき台、エラー原因の調査、互換性レベルの確認 | 回答をそのまま本番実行しない |
| Inline Chat | エディター内でコードの追加・修正を依頼 | 開いているSQLファイルのリファクタリング | 差分を確認してから適用する |
| Code Completions | T-SQL入力中に灰色の候補を表示 | SELECT文、JOIN、集計、条件句の補完 | SSMS 22.2以降が必要。設定で無効の場合がある |
| Next Edit Suggestions | 直近の編集から次の修正箇所を予測 | 別名変更、typo修正、同じパターンの修正 | Tabで移動・適用するため、誤適用に注意 |
| Database instructions | 業務ルールや利用規約をDBメタデータとして保持 | 売上定義、ステータス値、命名規則、禁止クエリの明示 | SSMS 22.3以降。誤った指示は全利用者に影響する可能性がある |
| Markdown/Mermaid生成 | MarkdownプレビューやMermaid図の生成 | ER図、手順書、調査メモの作成 | 図はスキーマ理解の補助としてレビューする |
Code CompletionsはSSMS 22.2以降でT-SQLを対象に利用でき、Tools > Options > Text Editor > Inline Suggestions > Generalから有効化できます。SSMS 22.5.2ではコード補完が既定で無効化されたため、「Copilot Chatは使えるのに灰色の補完が出ない」という場合は、まずこの設定を確認してください。(Microsoft Learn)
Azure SQLで特に効果が出やすい活用シーン
GitHub Copilot in SSMSは、SQLを自動実行する魔法の機能ではありません。効果が出やすいのは、人が判断する前の下書き・説明・比較・調査を速くする場面です。
T-SQLのたたき台を作る
たとえばAzure SQL Databaseで売上集計を作る場合、最初から列名やJOIN条件を思い出しながら書くより、Copilotに下書きを作らせてレビューする方が速い場面があります。
例：
Sales.OrderHeaderとSales.OrderLineを使って、過去30日の売上を日別に集計するT-SQLを作成して。SELECT *は使わず、必要な列名を明示して。返金はSales.Refundを差し引いて。
このように、対象テーブル、期間、禁止事項、業務ルールを具体的に入れると、曖昧なSQLが出にくくなります。
実行計画や結果ペインの読み取りを補助する
SSMS 22.5.0では、GitHub Copilot in SSMSが結果ペイン、実行計画、メッセージ、クライアント統計、結果グリッドとのやり取りをサポートする更新が入っています。(Microsoft Learn)
たとえば、次のように使えます。
この実行計画でコストが高い演算子を説明して。インデックス追加、クエリ書き換え、統計更新のどれを優先すべきか、理由付きで整理して。
ただし、インデックス追加や統計更新は本番負荷に影響します。提案はDBAが確認し、開発環境やステージング環境で検証してから反映しましょう。
スキーマ理解やER図作成を短縮する
Copilot ChatはMermaid図を生成できます。接続中データベースや追加した参照情報をもとに、テーブル関係や作業フローをMarkdown上で可視化できます。(Microsoft Learn)
例：
このデータベースの
Salesスキーマにある主要テーブルの関係をMermaidのER図で出して。外部キーがない関係は推測と分かるようにコメントして。
ポイントは、「推測」と「実際の制約」を分けさせることです。外部キーがないDBでは、AIが列名から関係を推測することがあります。
レガシークエリの説明・リファクタリング
長いストアドプロシージャや複雑なJOINを読むときは、いきなり書き換えを依頼するより、まず説明させる方が安全です。
おすすめの順序は次の通りです。
| 手順 | 依頼内容 | 目的 |
|---|---|---|
| 最初 | このクエリが何をしているか、処理単位で説明して | 理解 |
| 次 | 副作用のある処理、重い処理、NULLで結果が変わる箇所を指摘して | リスク抽出 |
| 次 | 可読性を上げる書き換え案を出して。ただし結果が変わる可能性がある箇所は明示して | 改善案作成 |
| 最後 | 変更前後で結果を比較する検証SQLを作成して | テスト |
使い始める前に確認すべき前提条件
GitHub Copilot in SSMSをAzure SQLで使う前に、次の項目を確認してください。
| 確認項目 | 推奨確認内容 |
|---|---|
| SSMSバージョン | SSMS 22以降。コード補完やNext Edit SuggestionsはSSMS 22.2以降、Database instructionsはSSMS 22.3以降を確認 |
| OS | SSMS 22は64bitのWindows 11、Windows Server 2025/2022/2019などをサポート。32bitとArm32 OSは非対応 |
| インストール方式 | Visual Studio InstallerでSSMSをインストール・更新・変更 |
| ワークロード | AI Assistanceワークロードが入っているか |
| GitHubアカウント | Copilot利用権限があるか。検証ならCopilot Freeも選択肢 |
| ネットワーク | GitHub Copilotサービスへ接続できるか。プロキシや証明書の制約がないか |
| Azure SQL権限 | 最小権限のログインで接続しているか |
| 本番利用方針 | 本番DBでの利用可否、DML/DDL提案の扱い、レビュー手順が決まっているか |
SSMS 22はVisual Studio Installerで管理され、従来の単独MSIではなくvs_SSMS.exeを使う形です。オフライン環境や管理された端末への配布では、ローカルレイアウトやコマンドラインインストールの検討が必要です。(Microsoft Learn)
GitHub Copilot in SSMSを有効化する手順
実際の導入は、いきなり本番利用者全員に展開するのではなく、開発チームやDBAの少人数で検証してから広げるのが安全です。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | SSMS 22以降をインストールまたは更新 | Visual Studio Installerで対象バージョンを確認 |
| 2 | AI Assistanceワークロードを追加 | GitHub Copilotが未インストールの場合に必要 |
| 3 | SSMSでAzure SQL DatabaseまたはManaged Instanceへ接続 | まずは開発・検証DBを使う |
| 4 | SSMS右上のGitHub Copilotバッジを開く | Open Chat Window to Sign Inを選択 |
| 5 | GitHubアカウントでサインイン | Copilot Freeまたは既存のCopilot権限を利用 |
| 6 | 必要に応じてコード補完を有効化 | Inline Suggestions設定を確認 |
| 7 | 読み取り専用に近い権限で検証 | 提案SQLをレビューしてから実行 |
Microsoft Learnの手順でも、SSMSでサーバーまたはデータベースに接続し、右上のGitHub Copilotバッジからチャットウィンドウを開いてサインインする流れが示されています。GitHub Copilotが未インストールの場合は、CopilotバッジまたはVisual Studio InstallerからAI Assistanceワークロードを追加します。(Microsoft Learn)
管理者が最優先で確認すべきセキュリティポイント
Copilot専用のDB権限はない
GitHub Copilot in SSMSで生成されたクエリは、接続中ユーザーのログインと権限のコンテキストで扱われます。Microsoft Learnは、Copilotに別個の権限はなく、Ask modeの読み取り専用判定もセキュリティ境界ではないため、SQL Server側の権限で最小権限を強制すべきだと説明しています。(Microsoft Learn)
これはAzure SQL運用で非常に重要です。たとえば開発者に本番DBのdb_owner相当の権限がある状態でCopilotを使わせると、AIが危険な操作を自動で行うというより、人が危険なSQLを受け入れて実行できてしまう状態になります。
最低限、次のルールを決めてください。
| 項目 | 推奨ルール |
|---|---|
| 本番DB接続 | 原則読み取り専用、必要な場合のみ限定的な実行権限 |
| DDL/DML | Copilot提案をそのまま実行せず、レビュー・承認・バックアップ確認を必須化 |
| 個人情報・機密情報 | プロンプトに実データを貼り付けない。必要ならマスキング済みサンプルを使う |
| 管理者作業 | メンテナンス、権限変更、インデックス追加はDBAレビューを必須化 |
| 検証環境 | 最初は開発DB、サンプルDB、匿名化済みDBで試す |
GitHub Copilotの組織ポリシーを確認する
企業利用では、個人のCopilot FreeやCopilot Proに任せるより、GitHub Copilot BusinessまたはEnterpriseのポリシー管理を確認すべきです。GitHub Docsでは、組織所有者がCopilotの機能やモデルの利用可否、プライバシー関連のポリシーを管理できると説明されています。(GitHub Docs)
特に確認したいのは次の項目です。
| ポリシー観点 | 確認内容 |
|---|---|
| 利用対象者 | どのチーム・ユーザーにCopilotライセンスを付与するか |
| モデル利用 | 利用可能なモデルやプレビュー機能の扱い |
| 公開コード一致 | 公開コードと一致する候補を許可するかブロックするか |
| フィードバック | 利用者からのフィードバック収集を許可するか |
| ネットワーク | 社内プロキシ、ファイアウォール、証明書でブロックされないか |
公開コードと一致する候補については、個人設定または組織・Enterprise側の設定で扱いを制御できます。個人が組織からCopilotシートを割り当てられている場合、公開コード一致に関する設定は組織またはEnterpriseから継承される場合があります。(GitHub Docs)
Database instructionsは「AI用の業務ルール台帳」として使える
Database instructionsは、Azure SQLを使うチームにとって特に実用的です。これは、売上定義、ステータス値、命名規則、利用すべき標準テーブルなどをデータベース側のメタデータとして保持し、Copilotの回答に反映させる仕組みです。
Microsoft Learnでは、Database instructionsは拡張プロパティとして保存され、ユーザーが同じデータベースにアクセスするとセッションをまたいで利用できると説明されています。SSMS 22.3以降とAI Assistanceワークロードが前提で、オブジェクトの拡張プロパティ名はAGENTS.mdを使います。(Microsoft Learn)
たとえば、売上定義が部署ごとにぶれやすい場合、次のような指示をテーブルに付けておくと、Copilotに毎回説明する手間を減らせます。
EXEC sys.sp_addextendedproperty
@name = N'AGENTS.md',
@value = N'売上はNetAmountからRefundAmountを差し引いた金額として扱う。SELECT * は使用せず、必要な列名を明示する。',
@level0type = N'SCHEMA',
@level0name = N'Sales',
@level1type = N'TABLE',
@level1name = N'OrderHeader';ただし、Database instructionsは便利な反面、誤った業務ルールを保存すると、利用者全体に誤解を広げる可能性があります。導入するなら、次の運用ルールを決めてください。
| 項目 | 推奨運用 |
|---|---|
| 作成権限 | DB所有者、DBA、データ責任者などに限定 |
| 変更管理 | スクリプトをGit管理し、レビュー後に反映 |
| 内容 | 業務定義、禁止パターン、標準テーブル、計算式を具体的に書く |
| 禁止事項 | 個人情報、秘密鍵、認証情報、顧客固有の機密メモを入れない |
| 更新・削除 | 誤りがあればsp_updateextendedpropertyまたはsp_dropextendedpropertyで修正 |
また、Ask modeではCopilotが変更クエリを実行できないため、Database instructionsを追加するT-SQLが生成されても、実行前に必ず人が確認する必要があります。(Microsoft Learn)
展開時に失敗しやすいポイントと対処法
GitHub Copilot in SSMSの導入でよく詰まるのは、AIそのものの品質よりも、インストール、認証、ネットワーク、設定、権限の問題です。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| Copilotバッジはあるが使えない | サインインしていない、Copilot利用権限がない、管理者が無効化している | GitHubアカウント、ライセンス、組織ポリシーを確認 |
| CopilotがUnavailableになる | ネットワーク、サービス側障害、資格情報の期限切れ | インターネット接続、GitHub Status、資格情報更新を確認 |
| Chatは使えるが補完が出ない | Code Completionsが無効 | Inline Suggestions設定を確認 |
| 期待と違うSQLが出る | 業務ルールや対象テーブルが曖昧 | プロンプトに列名、除外条件、禁止事項を明記 |
| Database instructionsが効かない | SSMSバージョン不足、拡張プロパティ名の誤り、接続DB違い | SSMS 22.3以降、AGENTS.md、対象DBを確認 |
| 本番で危険なSQLが実行されそうになる | DB権限が広すぎる、レビュー手順がない | 最小権限、差分確認、承認フローを導入 |
| ログ調査ができない | 監査設計が未整備 | Extended Eventsやログ出力場所を確認 |
トラブルシューティングでは、Microsoft LearnがCopilotの一時的な到達不能、ネットワーク問題、サービス停止、資格情報更新、管理者による無効化を確認ポイントとして挙げています。また、Copilot関連ログの保存先や、Extended Eventsでclient_app_nameを使ってCopilot由来のクエリを監視する方法も示されています。(Microsoft Learn)
監査で使う代表的なclient_app_nameは次の通りです。
| 用途 | client_app_name |
|---|---|
| Chatウィンドウのプロンプトから生成されたクエリ | Microsoft SQL Server Management Studio - GitHub Copilot |
| Code Completions由来のクエリ | Microsoft SQL Server Management Studio - Copilot Completions |
オフライン・管理端末への展開で見るべきこと
社内標準端末や閉域寄りの環境では、個々の開発者が自由にSSMSを更新できないことがあります。その場合は、Visual Studio Installer、コマンドラインインストール、オフラインレイアウトを使った展開を検討します。
オフラインレイアウトでは、vs_SSMS.exe --layoutで必要なファイルを事前に取得し、展開先にコピーできます。ただし、レイアウト作成時にはインターネット接続が必要です。また、クライアント側で不足コンポーネントを選ぶとインターネットから追加取得しようとするため、作成時とインストール時のオプションをそろえる必要があります。(Microsoft Learn)
管理者が確認すべき展開チェックリストは次の通りです。
| 分類 | 確認項目 |
|---|---|
| インストール権限 | 管理者権限でSSMS更新・変更ができるか |
| 端末要件 | Windows 11または対応Windows Serverの64bit環境か |
| 配布方法 | Visual Studio Installer、コマンドライン、オフラインレイアウトのどれを使うか |
| コンポーネント | AI Assistanceワークロードを含めるか |
| ネットワーク | GitHub Copilotの必要通信が許可されているか |
| 証明書 | プロキシやSSLインスペクション環境で問題が出ないか |
| 更新運用 | SSMS更新時に業務中のSSMSを閉じる案内があるか |
| ロールバック | 問題発生時に旧バージョン併用や段階展開ができるか |
SSMS 22は過去バージョンとサイドバイサイドでインストールできるため、全員一斉切り替えではなく、検証チームから段階的に展開しやすい構成です。(Microsoft Learn)
開発者が安全に使うためのプロンプト例
Copilotへの依頼は、曖昧なほど危険です。Azure SQLで使う場合は、対象、制約、出力形式、禁止事項を入れると実務に使いやすくなります。
| 目的 | プロンプト例 |
|---|---|
| 集計SQL作成 | dbo.Ordersとdbo.OrderItemsを使い、過去30日の売上を日別に集計するT-SQLを作成して。SELECT *は禁止。返金はdbo.Refundsを差し引く。 |
| クエリ説明 | このSQLを処理単位で説明して。副作用のある処理、NULLで結果が変わる箇所、性能上の懸念を分けて出して。 |
| リファクタリング | 結果を変えずに可読性を上げる書き換え案を出して。結果が変わる可能性がある変更は別枠にして。 |
| インデックス検討 | この実行計画をもとに、インデックス候補、統計更新、クエリ書き換えの優先度を理由付きで整理して。 |
| 障害調査 | このエラーメッセージの原因候補を、認証、権限、ネットワーク、SQL構文に分けて確認手順付きで出して。 |
| Mermaid図 | Salesスキーマの主要テーブル関係をMermaid ER図にして。外部キーがない関係は推測と明記して。 |
| 本番向けレビュー | このSQLを本番で実行する前のリスクを、ロック、実行時間、ロールバック、権限、監査の観点で確認して。 |
特に本番DBでは、「実行して」ではなく「実行前に確認すべき点を出して」「読み取り専用で確認するSQLにして」「DDL/DMLは提案だけにして」と明示するのが安全です。
導入するべきチームと慎重に進めるべきチーム
GitHub Copilot in SSMSは便利ですが、どのチームにも同じ速度で展開すべきものではありません。導入判断は、SQL作業量、権限管理、組織ポリシー、ネットワーク制約で分けると現実的です。
| 状況 | 判断 |
|---|---|
| T-SQL作成や調査が多く、SSMS 22を展開済み | 優先的に検証する価値が高い |
| 開発DB・検証DBでの利用が中心 | 比較的始めやすい |
| GitHub Copilot Business/Enterpriseの管理が整っている | 組織展開に向いている |
| 本番DBに広い書き込み権限を持つ開発者が多い | 権限整理が先 |
| 社内ポリシーでGitHub利用や外部AI利用が制限されている | 法務・セキュリティ確認が先 |
| 閉域、厳格なプロキシ、証明書制御がある | ネットワーク検証が先 |
| SSMS 21のAzure OpenAI連携を独自運用している | SSMS 22移行設計を分けて検討 |
まず取るべき次のアクション
Azure SQL環境でGitHub Copilot in SQL Server Management Studioを安全に始めるなら、最初の一歩は「全社展開」ではなく「制御された小規模検証」です。
まず、DBAまたはリード開発者の端末にSSMS 22以降とAI Assistanceワークロードを入れ、開発用Azure SQL Databaseへ最小権限のユーザーで接続します。次に、GitHub Copilotのライセンスと組織ポリシー、公開コード一致設定、ネットワーク接続、コード補完設定を確認します。そのうえで、代表的な業務クエリ、実行計画、Database instructionsを使い、生成結果の精度とレビュー手順を検証してください。
本番展開の判断は、少なくとも次の4点を満たしてからにするのが安全です。
- SSMS 22以降とAI Assistanceワークロードの配布手順が決まっている
- GitHub Copilotのライセンス・組織ポリシー・ネットワーク要件を確認済み
- Azure SQL側で最小権限と監査の設計ができている
- Copilotの提案SQLをレビューしてから実行する運用ルールがある
GitHub Copilot in SSMSは、Azure SQLの開発・運用を置き換えるものではありません。SQLを書く、読む、調べる、説明する時間を短縮する補助線として使うことで、DBAと開発者の判断を速くし、ミスを減らすための実用的なツールになります。
コメント