2026年5月22日時点でCopilot in SSMSの公式情報を確認するなら、最初に押さえるべき結論は「SSMSでAI支援を使う場合、SSMS 21のCopilotとSSMS 22のGitHub Copilotを混同しないこと」です。Microsoft Learnでは、SQL Server Management Studio（SSMS）21のCopilot in SSMSは、SSMS 22のGitHub Copilotに置き換えられたと案内されています。Azure SQLをSSMSから管理・開発している組織では、単なる便利機能の追加ではなく、利用条件、認証、権限、展開方法、コスト管理の見直しが必要です。(Microsoft Learn)
Copilot in SSMSは、自然言語でデータベースに関する質問をしたり、T-SQLの作成・説明・修正を支援したりするAI機能です。ただし、生成されたSQLは必ず人が確認し、Azure SQL側の権限設計を前提に運用する必要があります。この記事では、Azure SQL利用者と管理者向けに、何が変わるのか、どこに影響するのか、移行・展開時に何を確認すべきかを実務目線で整理します。
Azure SQLのAI/Copilot更新で何が変わるのか
今回のポイントは、SSMS上のAI支援が「Azure OpenAIリソースを前提にしたSSMS 21のCopilot」から、「SSMS 22以降で利用するGitHub Copilot in SSMS」へ軸足を移していることです。SSMS 22は現在のGAリリースとして案内されており、GitHub Copilot in SSMSはSSMS 22.4.1で一般提供になったとリリースノートに記載されています。(Microsoft Learn)
Azure SQLの現場で重要なのは、「SSMSにCopilotがあるかどうか」ではなく、どの世代のCopilotを、どの認証・課金・権限モデルで使っているかです。
| 観点 | SSMS 21のCopilot in SSMS | SSMS 22以降のGitHub Copilot in SSMS | 確認ポイント |
|---|---|---|---|
| 主な前提 | SSMS 21、Azure OpenAIのエンドポイントとデプロイ | SSMS 22以降、GitHubアカウント、Copilotアクセス、AI Assistanceワークロード | 利用中のSSMSバージョンを棚卸しする |
| 利用者認証 | Azure OpenAI側の構成に依存。Microsoft Entra IDまたはAPIキー | GitHubアカウントでサインイン | 組織アカウント、個人アカウント、契約管理を確認する |
| 管理対象 | Azure OpenAIリソース、モデル、トークン、Azure課金 | GitHub Copilotの契約、SSMS拡張、組織ポリシー | 管理部門が異なる場合は責任分界を決める |
| SQL実行権限 | ユーザーのSQLログイン権限で実行 | ユーザーのSQLログイン権限で実行 | Copilot専用の“特別権限”はない前提で設計する |
| 主な用途 | チャット、T-SQL支援、コード説明・修正 | チャット、インラインチャット、補完、Next Edit Suggestions、データベース指示 | 開発標準やレビュー手順に組み込む |
SSMS 21のCopilotは、Azure OpenAIのエンドポイントとデプロイをAzureサブスクリプション内に用意する構成です。一方、SSMS 22のGitHub Copilot in SSMSは、SSMS 22以降とGitHub Copilotアクセスが前提になります。Microsoft Learnでも、AI機能を使うには最新のSSMSとGitHub Copilot統合を利用するよう案内されています。(Microsoft Learn)
Copilot in SSMSでできること
Copilot in SSMSは、SSMS内でデータベースや環境に関する質問をしたり、Transact-SQL（T-SQL）の作成を支援したりするAIアシスタントです。対象としては、SQL Server、Azure SQL Database、Azure SQL Managed Instance、SQL Database in Fabricなどが説明されています。(Microsoft Learn)
実務では、次のような用途で効果が出やすい機能です。
| 活用シーン | 使い方の例 | 注意点 |
|---|---|---|
| T-SQL作成 | 「過去30日の注文数を日別に集計するクエリを作成して」 | テーブル名、条件、期間、出力列を明示する |
| SQLの説明 | 既存クエリを選択して「このクエリの処理内容を説明して」 | 説明が正しいか、実際の実行計画や仕様と照合する |
| 修正・リファクタリング | 「SELECT *を使わず必要列を明示する形に直して」 | 変更後の結果件数や性能を確認する |
| 管理作業の補助 | 「現在のブロッキングを確認する読み取り専用クエリを作成して」 | 本番環境では実行前に必ず内容を確認する |
| ドキュメント化 | クエリや設計ルールの説明文を生成する | 社内用語や業務定義は補足する |
SSMS 22のGitHub Copilotでは、チャットウィンドウやインラインチャットから質問でき、T-SQLの提案をアクティブなクエリエディターへ適用したり、新しいファイルへ追加したりできます。コード補完では、入力中のT-SQLや接続中データベースのスキーマなどを文脈として候補を提示します。(Microsoft Learn)
Azure SQL利用者への影響範囲
Azure SQL環境でCopilot in SSMSを導入・更新する場合、影響は開発者の入力支援だけに留まりません。特に本番データベースに接続する端末では、権限、接続先、監査、コスト、組織ポリシーまで確認が必要です。
開発者への影響
開発者にとっては、T-SQLの下書き、エラー修正、クエリ説明、補完がSSMS内で完結しやすくなります。たとえば、JOIN条件を含む集計SQL、既存クエリの可読性改善、インデックス候補の考え方の整理などに使えます。
ただし、Copilotの出力は「実行可能な正解」ではなく「レビューすべき提案」です。特にAzure SQLの本番DBで、UPDATE、DELETE、ALTER、DROPを含むSQLが提案された場合は、そのまま実行してはいけません。検証環境での確認、トランザクション、バックアップ、レビューを挟むべきです。
管理者への影響
管理者は、SSMSのインストール状態、AI Assistanceワークロード、GitHub Copilot契約、ネットワーク接続、プロキシ、監査ログ、SQL権限を確認する必要があります。GitHub Copilot in SSMSで生成されたクエリは、利用者のログインと権限のコンテキストで実行され、Copilot専用の別権限はありません。Microsoft Learnでは、Ask modeの分類システムは書き込み操作をブロックする仕組みを持つものの、セキュリティ境界ではないため、SQL Server側の権限で最小権限を徹底するよう説明されています。(Microsoft Learn)
セキュリティ・監査への影響
AI支援を有効にすると、利用者がどのDBに接続し、どの文脈で質問しているかが重要になります。Copilotは接続中のクエリエディターやスキーマ情報を文脈として扱うため、機密性の高いテーブル名、列名、業務ルール、サンプルデータをどこまでプロンプトに含めてよいかを事前に決めておくべきです。(Microsoft Learn)
監査面では、GitHub Copilot in SSMSが実行したクエリをExtended Eventsで確認する方法も案内されています。チャット由来のクエリはMicrosoft SQL Server Management Studio - GitHub Copilot、補完由来のクエリはMicrosoft SQL Server Management Studio - Copilot Completionsをclient_app_nameで識別できます。(Microsoft Learn)
管理者が確認すべき設定
Copilot in SSMSをAzure SQL環境へ展開する前に、管理者は次の項目を確認してください。
| 確認項目 | 見るべき場所 | 判断基準 |
|---|---|---|
| SSMSのバージョン | SSMSのバージョン情報、配布パッケージ | 原則としてSSMS 22以降へ移行する。SSMS 21利用者は旧Copilot構成の有無を確認する |
| AI Assistanceワークロード | Visual Studio Installer | GitHub Copilot in SSMSを使う端末にAI Assistanceが入っているか確認する |
| GitHub Copilotアクセス | GitHubアカウント、組織契約、管理者ポリシー | 個人契約で業務DBに接続させない。組織管理下のアカウントを使う |
| SQL権限 | Azure SQLのログイン、ユーザー、ロール | 読み取り用途ならSELECT中心にし、DDL/DML権限を安易に付与しない |
| コード補完 | Tools > Options > Text Editor > Inline Suggestions > General | 必要なチームだけ有効化する。SSMS 22.5.2ではコード補完が既定で無効化された点も確認する |
| ネットワーク | プロキシ、ファイアウォール、GitHub Copilot接続 | Copilotが一時的に到達不能になるケースに備え、ネットワークチームと確認する |
| ログ | %TEMP%\VSGitHubCopilotLogsなど | 認証失敗や応答不具合の調査手順を用意する |
| 監査 | Extended Events | Copilot由来のクエリを識別できるようにする |
| 旧Azure OpenAI構成 | Azure OpenAIリソース、デプロイ、APIキー | SSMS 21の旧Copilotを継続するか、SSMS 22へ移行するか決める |
SSMS 22.5.2では、コード補完が既定で無効化され、必要な場合はTools > Options > Text Editor > Inline Suggestions > Generalから有効化する形に変更されています。展開後に「Copilotは入っているのに補完が出ない」と混乱しやすいため、管理者向け手順書に明記しておくとよいでしょう。(Microsoft Learn)
SSMS 21からSSMS 22へ移行するときの考え方
SSMS 21でCopilot in SSMSを試していた組織は、まず「旧構成を延命する」のか、「SSMS 22のGitHub Copilotへ移行する」のかを決める必要があります。名前は似ていますが、前提となるサービスが異なるため、単純なアップデート作業として扱うと失敗しやすくなります。
移行前に棚卸しするもの
最低限、次の情報を一覧化してください。
| 棚卸し対象 | 具体例 |
|---|---|
| 利用端末 | SSMS 21、SSMS 22、Preview版、GA版の混在状況 |
| 利用者 | DBA、開発者、データ分析担当、外部委託先 |
| 接続先 | Azure SQL Database、Azure SQL Managed Instance、本番、検証、開発 |
| 認証方式 | Microsoft Entra ID、SQL認証、管理者実行の有無 |
| 旧Copilot設定 | Azure OpenAI Endpoint、Deployment、API Key、Entra認証 |
| 契約 | GitHub CopilotのBusiness/Enterprise/Free利用可否 |
| セキュリティ要件 | 機密データ、個人情報、プロンプト入力ルール、監査要件 |
SSMS 21のCopilotはAzure OpenAIリソースを構成する必要があり、APIキーを使わない場合はMicrosoft Entra IDでAzureに認証します。Microsoft Entra認証が推奨される一方で、SSMSをログインユーザーとは別ユーザーとして起動している場合に利用できない制限も記載されています。(Microsoft Learn)
推奨される移行ステップ
| ステップ | 作業 | 失敗しやすいポイント |
|---|---|---|
| 1 | 利用者と端末を棚卸しする | SSMS 21と22が混在し、問い合わせ対応が複雑になる |
| 2 | GitHub Copilotの契約・組織ポリシーを確認する | 個人アカウントで業務利用してしまう |
| 3 | 検証用Azure SQLに限定してパイロット導入する | いきなり本番DBへ接続させる |
| 4 | AI Assistanceワークロードを標準配布に含めるか決める | インストール済みだが未サインイン、または未インストールで使えない |
| 5 | 最小権限の接続ユーザーで検証する | Copilotの提案を防御機構と誤解する |
| 6 | コード補完・インラインチャットの利用ルールを決める | 補完候補を無批判に採用する |
| 7 | 監査・ログ確認手順を用意する | Copilot由来のクエリを後から追えない |
| 8 | 開発標準にプロンプト例とレビュー手順を追加する | チームごとに使い方がばらつく |
移行では、SSMSの更新作業だけでなく「誰が、どのDBで、どの権限で、どのAI機能を使うのか」を決めることが重要です。
Azure OpenAI構成を使っている場合の注意点
SSMS 21のCopilot in SSMSを使っている場合、Azure OpenAIのエンドポイントとデプロイ、モデル、認証方式、課金を確認する必要があります。公式情報では、Azure OpenAIへのアクセスはMicrosoft Entra認証またはAPIキーで提供でき、より安全な選択肢としてMicrosoft Entra認証が推奨されています。また、利用コストはプロビジョニングしたAzure OpenAIリソースと選択モデルの利用状況に依存し、リソースをホストするAzureサブスクリプションに課金されます。(Microsoft Learn)
プレビュー構成では、gpt-4oがサポート対象モデルとして説明されており、トークン上限やデプロイ種別も考慮する必要があります。課金が固定額ではなく利用量に応じて変動する点も明記されているため、検証環境であっても定期的なコスト確認は必須です。(Microsoft Learn)
実務では、次のような運用にしておくと安全です。
| 項目 | 推奨対応 |
|---|---|
| APIキー | 共有せず、必要最小限の利用者に限定する。可能ならMicrosoft Entra認証を優先する |
| Azure OpenAIリソース | 本番・検証を分け、タグでOwnerやCostCenterを付ける |
| ネットワーク | SSMS端末からエンドポイントへ到達できるか確認する |
| トークン・コスト | 予算アラートや定期レビューを設定する |
| 移行判断 | SSMS 22のGitHub Copilotへ移すか、旧構成をいつ停止するか決める |
開発者が安全に使うためのプロンプト例
Copilot in SSMSの精度は、接続コンテキストとプロンプトの具体性に大きく左右されます。Microsoft Learnでも、曖昧な質問では曖昧な回答になりやすいため、具体的に依頼することが推奨されています。(Microsoft Learn)
悪い例と良い例を比べると、使い方の差が分かりやすくなります。
| 悪いプロンプト | 改善したプロンプト |
|---|---|
| 売上を出して | Sales.OrderHeaderとSales.OrderDetailを使い、過去30日間の売上合計を日別に集計するT-SQLを作成して。出力列は注文日、注文数、税抜売上、税込売上にして |
| 遅いSQLを直して | 選択中のT-SQLについて、実行計画で確認すべきボトルネック候補を説明し、インデックス追加なしで改善できる書き換え案を提示して |
| 障害を見て | 現在接続中のAzure SQL Databaseで、ブロッキングの有無を確認する読み取り専用T-SQLを作成して。実行はせず、各列の意味も説明して |
| このテーブル何？ | dbo.Customerテーブルの主な列、推測される用途、注意すべき個人情報列の候補を一覧にして。ただし不確かな点は推測と明記して |
| いい感じに直して | SELECT *を使わず、必要列を明示し、日付条件をパラメータ化した形にリファクタリングして |
本番環境では、プロンプトに「実行はせず、SQLだけを提示して」「読み取り専用で」「変更前後の差分を説明して」などの条件を入れると、レビューしやすくなります。
データベース指示を活用すると回答のぶれを減らせる
SSMS 22のGitHub Copilotでは、データベース固有のルールや業務定義を「Database instructions」としてデータベース内に保持できます。これは拡張プロパティとして保存され、Copilotが応答時の追加コンテキストとして利用します。たとえば、「売上は返品を差し引いたNetAmountで定義する」「Status = 99はキャンセルを意味する」といったルールを明文化できます。(Microsoft Learn)
特にAzure SQLでは、テーブル名だけでは業務的な意味が分かりにくいケースが多くあります。Copilotに毎回説明するのではなく、重要なテーブルや列に指示を付けておくと、チーム全体で回答の一貫性を高めやすくなります。
ただし、Database instructionsは便利な反面、誤ったルールを保存すると全利用者のCopilot応答に影響します。公式情報では、オブジェクトの拡張プロパティ名としてAGENTS.mdを使い、データベース全体の上位ルールにはCONSTITUTION.mdを使う説明があります。誤った指示はsp_updateextendedpropertyやsp_dropextendedpropertyで更新・削除できます。(Microsoft Learn)
管理者は、次のようなルールを決めてから使い始めるとよいでしょう。
| ルール | 例 |
|---|---|
| 登録できる人 | DBオーナー、DBA、テックリードに限定する |
| 書いてよい内容 | 業務定義、命名規則、参照すべき正規テーブル、禁止クエリ |
| 書いてはいけない内容 | パスワード、APIキー、個人情報の実データ、社外秘の不要な詳細 |
| レビュー | プルリクエストや変更申請と同じ扱いにする |
| 棚卸し | 四半期ごと、またはスキーマ変更時に見直す |
失敗しやすいポイント
Copilot in SSMSの導入でよくある失敗は、技術的な不具合よりも「前提の確認漏れ」です。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| Copilotのメニューが見つからない | AI Assistanceワークロード未導入、またはSSMSバージョン違い | Visual Studio InstallerでSSMS 22のAI Assistanceを確認する |
| サインインしても使えない | GitHub Copilotアクセスがない、管理者が無効化している | 組織のGitHub管理者に契約とポリシーを確認する |
| 補完が表示されない | SSMS 22.5.2以降で補完が既定無効 | Inline Suggestions設定から有効化する |
| 本番DBで危険なSQLを実行しそうになる | SQL権限が広すぎる、レビュー手順がない | 読み取り専用ユーザー、検証DB、レビュー必須にする |
| 回答が業務定義と合わない | Copilotがスキーマ名だけで推測している | Database instructionsで定義を明文化する |
| コストが読めない | SSMS 21のAzure OpenAI構成で利用量を監視していない | Azure側で予算、タグ、利用状況の確認を行う |
| 監査できない | Copilot由来のクエリを識別していない | Extended Eventsでclient_app_nameを記録する |
特に注意したいのは、Copilotの「読み取り判定」や「提案の見た目」をセキュリティ対策と誤解することです。最終的な防御線はAzure SQL側の権限です。Copilotを有効化する前に、利用者が手作業で実行できてしまう危険な操作を洗い出してください。
まず取るべきアクション
Azure SQL環境でCopilot in SSMSを確認するなら、次の順番で進めるのが現実的です。
- 利用中のSSMSバージョンを調べ、SSMS 21とSSMS 22の混在状況を把握する
- SSMS 21の旧CopilotでAzure OpenAIリソースを使っていないか確認する
- SSMS 22へ移行する対象者と、GitHub Copilotの契約・アカウント方針を決める
- 検証用Azure SQLでAI Assistanceワークロード、サインイン、チャット、補完をテストする
- 最小権限、監査、ログ、プロンプト利用ルールを整備する
- 開発者向けに、良いプロンプト例と「必ずレビューするSQL」の基準を共有する
Copilot in SSMSは、Azure SQLの管理やT-SQL開発を効率化できる一方で、導入すれば自動的に安全になる機能ではありません。SSMS 21のCopilotとSSMS 22のGitHub Copilotを区別し、権限・契約・展開・監査の順に確認してから本番利用へ広げることが、失敗しない導入の近道です。
コメント