SSMS から任意のクエリを実行できるようにしている環境では、他の処理の同時実行性に影響を与えるクエリの実行が行われる可能性があります。(SSMS 以外のツールを使用している場合でも発生する可能性はありますが)
SSMS 拡張機能を作成する際の参考ドキュメント で触れましたが、SSMS には拡張機能という仕組みがあり、この機能を使用することで SSMS に追加の機能を実装することができます。
この機能追加により、SSMS からのクエリ実行の安全性を向上させることができるのではないかと考えました。
そこで GitHub Copilot CLI による Vibe Coding を使用して SSMS からのクエリ実行に関して、安全にクエリを実行するための補助をする拡張機能の作成の概念検証 (Proof of Concept: PoC) に取り組んでみましたので、その際の知見をまとめておきたいと思います。
GitHub Copilot CLI についてのドキュメントは以下を参照。
- GitHub Copilot CLI
- GitHub Copilot CLI (Public Preview) (リポジトリ)
- @github/copilot (npm)
- GitHub Copilot CLI について
- GitHub Copilot CLI の使用
- GitHub Copilot CLI の責任ある使用
- GitHub Copilot のリポジトリ カスタム命令を追加する
- GitHub Copilot CLI 101: How to use GitHub Copilot from the command line
Contents
GitHub Copilot CLI を使用した理由
SSMS は Windows 専用のクライアントツールとなるため、Linux ワーカーを使用する環境ではなく、手元の Windows 端末上で動作する CLI 環境であれば、何を使用しても良かったと思うのですが、「GitHub Copilot Pro+ を年契約しており、追加コストを発生させることなく使用できる」という理由で GitHub Copilot CLI を使用して検証を開始しました。
GitHub Copilot CLI は他の CLI の AI エージェントと同様に、ローカルのファイル / 実行環境を使用して動作させることができますので、Windows 上で動作させれば、Windows 向けのアプリケーション開発でも活用することができます。
GitHub Copilot Coding Agent を使用しても、AI エージェントによる SSMS 拡張機能の開発を実施することは不可能ではないかと思いますが、Coding Agent は Ubuntu x64 ランナーのみサポート しており、SSMS 拡張機能のような非 SDK プロジェクトで、MSBuild を使用した .NET Framework 4.8 (or 4.7) 向けの開発を実施するのは効率が悪いため、Coding Agent は積極的には使用していません。
以前、Coding Agent で、Windows のパフォーマンスモニターを操作するプログラムを作成できることは確認しており、Coding Agent での開発も不可能ではないのですが手間がかかりましたので、今回は GitHub Copilot CLI をメインにしながら開発をしています。
Coding Agent へのタスクの委任
GitHub Copilot CLI では、Copilot コーディング エージェント にタスクを委任する ための「delegate」コマンドを使用することができます。
Coding Agent に委任したほうが良いタスク (例: ドキュメント作成のような Windows 環境が無くてもよいタスク) については、プロンプト内で、委任することで Coding Agent を使用したバックグラウンドのタスクとして作業をするめるという使い方も可能ですので、実行するタスクに応じて Copilot CLI と Coding Agent を使い分けることもできます。
開発作業前の準備
開発環境
今回の開発は Windows + Visual Studio 2022 の環境に、GitHub Copilot CLI をインストールして進めています。
対象とする SSMS は 21 / 22 を想定したものとしていますが、SSMS のサポートポリシー が明確になっていますので、今後は SSMS 22 のみのサポートでよいかもしれませんね。
SSMS 20 の対応をも当初は含めていたのですが、x86 / x64 の両サポートを Vibe Coding に依頼した場合、処理の複雑性や、 x86 で一部機能の実装が進まないということがありましたので、今回の検証では x86 サポートは外し、最終的には x64 の SSMS 21 / 22 のみ対象とするように変更していきました。
SSMS 22 については Arm64 でも動作しますので、今回作成した拡張機能については Arm64 でも動作することは確認しています。
カスタムインストラクションの作成
GitHub Copilot CLI のインストール は当然必要となりますが、それ以外の作業として、copilot-instructions.md の作成を実施します。
GitHub Copilot CLI でもカスタムインストラクションを使用することができますので「.github/copilot-instructions.md」を SSMS 拡張機能開発向けに作成します。
今回使用したカスタムインストラクションについては このような内容 となります。
SSMS 拡張機能作成方法 の記事を基にした拡張機能のサンプルのプロジェクトもリポジトリ内に含めるようにしており、機能を作成する際にテンプレートとするプロジェクトについても、カスタムインストラクション内で指示ができるようにしています。(テンプレートを用意していないと .NET の SDK プロジェクトが作成されることがあるため、これを抑制する目的もあります)
どのように開発を進めるか / 実行環境の想定 / 参考となる拡張機能のリポジトリ等を記載しています。
カスタムエージェントの利用について
開発を開始した段階では実装されていなかったため、今回の開発では使用していないのですが、カスタム エージェントを使用する に記載されている内容については、GitHub Copilot CLI でも使用することができます。
Awesome GitHub Copilot Customizations の「agents」ディレクトリの内容のように、カスタムエージェントを使用して目的に適したペルソナを定義するということも今は可能です。
GitHub Copilot CLI を定期的に更新する
GitHub Copilot CLI の更新は頻繁に行われており、更新状況は次のような情報から確認ができます。
GitHub Copilot CLI を使用した作業を実施する前には、毎回 CLI の最新化をしてから作業を行うようにしていました。
開発期間と消費したプレミアムリクエスト
実装した機能は後述していますが、2025-10-09 から開発を開始しています。
開発期間でフルに開発をしていたわけではなく、毎日の業務終了後に 2 時間程度ずつで開発をしていたものとなります。
消費したプレミアムリクエストとしては、1,300 程度となり、GitHub Copilot Pro+ の標準で含まれているプレミアムリクエストでまかなえています。
実際には、10 月で 840 / 11 月で 460 程度の消費となっており、2 ヶ月にまたがって消費しています。
拡張機能の内容と実装結果
今回作成する拡張機能は「SSMS から安全にクエリを実行するための補助をする機能」となります。
これには次のような機能を想定しています。
- 自分が実行したクエリが SQL Serve に対してどのような影響を与えているかの把握
- トランザクション分離レベルを自動的に設定
- 実行について考慮が必要なステートメントが入力された場合の警告の表示
本検証では、上記の要件を Vibe Coding を利用して、次のような機能として実装することができることを確認しました。
自分が実行したクエリが SQL Serve に対してどのような影響を与えているかの把握
定期的にクエリを実行した結果を表示するツールウィンドウを追加、しきい値を超えた場合にはツールウィンドウ / バルーンとして警告を表示する機能の実装を行えることを確認しました。
実行するクエリ / 警告の条件については YAML に定義をし、新しい情報の確認が必要になった場合にも対応が行えるようにしています。
「インスタンスとしてブロッキングが発生しているか？」といった状態についてはシンプルなクエリで確認ができますので「クエリの実行後に警告が出力されたかどうかで、自分が実行したクエリが影響を与えたのか」を気づくことができるのではないでしょうか。
「自分が実行したクエリが影響を与えたのか？」を取得するには実行するクエリの条件に指定を考慮する必要がありますが、実装することも可能ですので、定期的に実行するクエリの内容を検討すれば様々なケースで活用することができるのではないでしょうか。
トランザクション分離レベルを自動的に設定
クエリを実行する際に、「NOLOCK」ロックヒントを設定して、ロックを取得しないようにして同時実行性の低下を抑えるということが行われることがあるのではないでしょうか。
NOLOCK ロックヒントはクエリ内の参照テーブル単位で指定が必要となりますので、クエリを記載する際の手間がかかり、設定をし忘れることもあるので、クエリ全体で指定をしたいのであれば、個別に NOLOCK を設定するより、「SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED」を指定したほうが設定の抜けはなくなります。
SSMS には、クエリ実行時のトランザクション分離レベルを指定する設定がり、この機能を使用することもできるのですが、SSMS を実行するユーザー単位で設定する必要があり、設定内容は画面には表示されないため、現在どのような設定がされているのかを把握しずらいということがあります。
そこで、クエリウィンドウを開いた際に自動的に特定のトランザクション分離レベルを記述した状態にすることができる機能の実装を行えることを確認しました。
新しいクエリウィンドウを開くと指定した分離レベルが記載された状態となります。この設定は永続化できるようになっていますので、クエリウィンドウを開いた際の初期値を設定しておくことが可能です。
クエリウィンドウ内のコンテキストメニューに対しても機能の追加を行い、メニューからだけでなく、クエリウィンドウ内から手動で分離レベルを追加することもできます。
「READ UNCOMMITTED」だけでなく「SNAPSHOT」を指定することもできますので、クエリ実行時に同時実行性の低下を抑えたトランザクション分離レベルの指定を自動的に行うことで、クエリ実行時の問題の発生の低減につながる可能性があります。
実行について考慮が必要なステートメントが入力された場合の警告の表示
クエリ内で特定のステートメントが記載されている場合、そのステートメントに問題がないかを通知することができるかの検証として、「DROP TABLE」「TRUNCATE TABLE」といったステートメントが記載されているかを検知できる機能の実装を行えることを確認しました。
DROP TABLE が含まれている場合、次のように警告が行われます。
コメント化している場合の警告の無効 / 任意のステートメントを警告対象とするというような機能実装まではできていないのですが、特定の文字が含まれている場合、ユーザーに警告を通知するという機能は実現ができました。
これにより、実行に中が必要なステートメントが含まれている場合、問題がないかをユーザーに通知することが可能となります。
GitHub Copilot CLI を使用して、当初想定していた SSMS の拡張機能は実装でき他と思います。
これらの機能により、SSMS からのクエリ実行の補助を行い、通常の SSMS と比較し、入力支援やユーザーが気づきやすい形で警告を表示できるようになったのではないでしょうか。
仕様駆動開発による開発
上記の機能は GitHub Copilot CLI による Vibe Coding でのみ開発を実施しており、私が直接開発をした箇所はありません。
この時の開発ですが「仕様駆動開発 (Spec Driven Development: SDD)」により、開発を進めています。
JAZUG 15 周年イベントで寺田さんが解説された、スキーリゾート管理システム – マイクロサービスアーキテクチャ の手法を参考にさせていただきました。(セッションの内容は、ちょまどさんが [スペック駆動開発] 品質を担保した AI 駆動開発セッション受講メモ #JAZUG でまとめてくださっています)
最近公開された CHIHIRO さんの 仕様駆動開発（SDD）を採用したAI駆動開発の実態と課題 の記事も参考になります。
Vibe Coding による開発はゆらぎが発生する可能性あり、安定した結果が出せるようにするためには、開発内容をドキュメント化して指示を出すことは重要ではないでしょうか。
Spec Kit を使用するという方法もあるかと思いますが、今回は使用しておらず (使用方法を覚える時間が取れず…)、次のような手順で開発を進めました。
- 製品要求仕様 (Product Requirements Document: PRD) を作成
- 機能仕様 (Spec) を作成
- 実装を開始
- 新規要素を作成した場合の開発ガイドを作成
製品要求仕様 (Product Requirements Document: PRD) を作成
最初のステップとしては、製品要求仕様 (PRD) のドキュメントの作成をしています。
これは次のような内容を含んだ Markdown として作成しています。
「xxxx という機能を実現するための PRD を作成します」というようなプロンプトを起点として作成したドキュメントとなり、これには機能として含める仕様のみを記載し、具体的なコードについては記載はしていません。
GitHub Copilot CLI と壁打ちをしながらドキュメントを発展させていきます。
複数の機能を実装したい場合は、Coding Agent に委任して並行して作成させるのも良いかもしれませんね。
まずは PRD として作成したい機能についてドキュメント化したものを作成し、実装する機能についての記載が完了したら次の作業に移ります。
機能仕様 (Spec) を作成
機能仕様 (Spec) については PRD を基に実装を意識したコードレベルの記載も許可した内容となります。
PRD と Spec はペアになるように作成しており、上記の PRDであれば、次のような Spec が作成されます。
上記はコードレベルの内容も含まれますが、このドキュメント自体は私は作成には関与しておらず「xxx 機能の PRD を基に SPEC を作成してください」と指示をして作成をしています。
上記のようなシンプルな PRD でもこのような Spec を作成を作成することが可能です。
Spec については、具体的なコード実装も含まれているのでほとんど壁打ちはしておらず、エージェント任せになってしまっています。
実装を開始
PRD と Spec が揃ったら実装を開始します。
実装内容はドキュメント化されているため、「xxx 機能の Spec を元にして実装を開始してください」の指示で実装が開始されます。
実装の中で当初のドキュメントから変更が必要となったものについては適宜 PRD と Spec にも反映を行います。
作業が長くなってくると、エージェントの作業内容が迷走することがありますので、そのような場合、新しいセッションによる作業を試してみることがあります。
これまでの作業内容が適宜ドキュメント化されていると、そこまでの作業内容もスムーズに引き継ぐことができます。
作業を進める中で「不要となった実装」がいくつかありますが、そのような実装が残っていることもありますのでタイミングを見て削除の指示を出すこともありました。
エージェントが実装を迷走することがしばしばありますので、そのような場合は次のような対応を行い実装を進めていました。
- 新しいセッションで作業を実施
- Claude Sonnet 4.5 と GPT-5 を適宜切り替えて実装の変化を促す
- 発生している問題を整理し、対応が必要な内容を具体的に指示
- 問題発生している処理についてのログ出力を充足させ、解析に使用できるログを増やす
- サンプルとなる実装がある場合、その実装を参考とするように指示
- ローカルに画像を保存し、その画像のファイルパスをプロンプトに含めることで発生している問題や最終的に実装したい内容を把握させる
新規要素を作成した場合の開発ガイドを作成
「メニューバーに新しいメニューを追加する」というような実装については、今後同様の機能を追加する際の参考となります。
このような機能実装の要素についてはガイドとしてドキュメントを作成します。
これにより類似の機能を作成する場合「xxx のプロジェクトや xxx のガイドを参考にしてください」というような指示を出すことができます。実装に迷走した場合、参考となる実装があるのであれば「xxxx のコードを参考にしてください」という指示を出すことも重要かと。
今回の拡張機能の作成では、基本は上記のドキュメントを作成していますが、そのほかには実装できなかった機能 / 失敗したアプローチについては「issue」としてドキュメント化も行っています。
これらのドキュメントを作成しながら作業をすることで、意図した機能の実装につなげることができ、次回以降の実装時に参照させるドキュメントの整備にもつながったのではないでしょうか。
ガードレールの設定についての考慮
Vibe Coding によるコーディングは広範囲に破壊的な変更を行うことがあるため、ガードレールの設定について考慮する必要がありますが、今回の検証ではガードレールの設定はほとんどできていません…。
GitHub Copilot CLI では、Security considerations に記載されているように、信頼されたディレクトリ / 許可されたツールの設定を行うことができます。
これにより、CLI が操作可能な対象を制限していくことでガードレールを設けるのが一般的かと思いますが、「制限を設定する = ユーザーの確認が増え自動的な実装の妨げになる」につながりますので、どのようにしてバランスをとるのかが難しいところではないでしょうか。
今回の実装であれば、拡張機能ごとにプロジェクトを分割し、機能の作成 / 改修はできるだけ、プロジェクト内で完結するよう意識することで、セッション内で変更される対象を制限したつもりではあるのですが。
JAZUG 15 周年のセッションでは、Vibe Coding とマイクロサービスの組み合わせによる作業対象の局所化について触れられていました。
今回のようなツールでも、破壊的な変更が入ることを考慮して、どのようにして作業対象を局所化していくか悩ましいところがありました。この辺は作業開始前のデザインとして考える必要があるのではないでしょうか。
GitHub Copilot CLI の使用 に記載されている「copilot\config.json」の設定についても考慮は必要になっていくのかもしれませんね。
現状、次のようなコマンドを初期設定として実行を行っています。
copilot ` --allow-tool "shell(git:*)" --allow-tool "shell(gh:*)" ` --deny-tool "shell(Invoke-Expression)" --deny-tool "shell(gh pr merge)" ` --allow-tool "shell(Write-Host)" --allow-tool "shell(New-Item)" --allow-tool "shell(Set-Location)" --allow-tool "shell(Get-Item)" --allow-tool "shell(Copy-Item)" ` --allow-tool "shell(Get-Content)" --allow-tool "shell(Find-String)" --allow-tool "shell(Get-ChildItem)" ` --allow-tool "shell(cd)" ` --allow-tool "shell(robocopy)"
使用したモデル
本検証では、GitHub Copilot CLI のデフォルトのモデルである「Claude Sonnet 4.5」を基本的に使用しています。
現在は、「GPT-5」も使用することができますが、一通りの機能は Claude Sonnet 4.5 で実装できています。
Claude Sonnet 4.5 で回答が迷走しだしたときは、GPT-5 に変更して実装できるかを確認したこともありますが、この対応が必要だったのは一部だけでした。
体感ですが、Claude Sonnet 4.5 は実装をすすめる際の確認を求めることは少なく、GPT-5 はいくつかの実装案を提示し、どれを使用するかの指示を求めることが多かったような気がしています。
生成されるコードにどのような特色 / 違いがあるかまで確認はできていないのですが、モデルによった回答の特色はあるように思えますので、モデルの使い分けについては今後も検証が必要であると思っています。
開発を進めていた際には、GPT については GPT-5 までの提供でしたが、OpenAI’s GPT-5.1, GPT-5.1-Codex and GPT-5.1-Codex-Mini are now in public preview for GitHub Copilot で使用できるモデルが増えています。
Codex も使用できるようになりましたので、実装が上手くできない場合は GPT-5.1 系のモデルの利用を検討してもよいかもしれませんね。
新しいモデルは GitHub Copilot のレート制限 の対象となりやすい可能性がありますので、最新のモデルを頻繁に使用している場合は、レートリミットのエラーが発生するかもしれません。
まとめ
GitHub Copilot CLI による Vibe Coding を使用して、SSMS の拡張機能を実装することができました。
次のような機能を実装することが可能なことを確認できました。
- 特定のクエリを定期的に実行して取得した情報を表示するためのツールウィンドウの作成
- バルーンによる通知
- メニューの拡張
- コンテキストメニューの拡張
- 設定の永続化
- クエリエディターのテキストの解析
本検証で「このような機能があるとユーザーにとって便利なのではないか」というものを数日で実装することができるという、手ごたえを得ることができました。
本検証では手動のコード修正は実施しておらず、Vibe Coding のみで実装を実施しています。
SSMS 拡張についての基本的な知識は必要となりますが、非開発者でも利便性を向上させるための機能追加は十分に可能ではないでしょうか。
「人がメンテナンスできるコードになっているか」は微妙なところがありますので、今後メンテナンス性の維持についてもこれから考えていきたいと思います。