Visual Studio Debugger Agentは、GitHub Copilot Chatからバグの再現、原因の調査、修正案の検証を進めるデバッグ支援機能です。ソースコードの説明に加え、ブレークポイントで止まったときの変数やコールスタックなど、実行中の情報を使って仮説を確かめます。
2026年8月に追加されたTest-Driven Investigationでは、不具合を再現するテストを見つけるか作成し、そのテストを使って調査と修正後の確認を続けられます。手動では再現しにくい報告を受けたときは、まず利用できる既存のテスト基盤があるかを確認しましょう。この記事はVisual Studio 2026のDebugger Agentを対象に、2026年9月11日に確認した公式情報を整理しています。
手動再現の可否とテスト基盤で調査方法を選ぶ
| 現在の状況 | 調査の入口 |
|---|---|
| 操作手順どおりに毎回再現できる | Live Debuggingでアプリを実行し、問題が起きる瞬間の状態を調べる。 |
| 失敗する既存テストがある | そのテストを起点に、報告された不具合と同じ失敗か確認する。 |
| 手動再現が不安定で、対応するテスト基盤がある | Test-Driven Investigationで再現用テストを探すか作成する。 |
| 再現手順も利用できるテスト基盤もない | 例外、ログ、入力条件などを補い、再現方法を整理する。テスト駆動調査が無条件に始まるとは考えない。 |
Microsoftの発表では、手動で確実に再現できる場合はLive Debuggingが適しており、対応する既存のテスト基盤が見つかる場合にテスト駆動の経路を利用すると説明しています。テストの準備がないプロジェクトへ、必ず一式のテスト環境を構築してくれるという意味ではありません。MicrosoftのTest-Driven Investigation発表。
Debugger Agentを使い始める手順
- 対象のソリューションをVisual Studioで開き、普段のビルドやデバッグに必要な準備を済ませます。テストから調べる場合は、既存テストを実行できるか確認します。
- ［表示］→［GitHub Copilot Chat］を開きます。GitHubアカウントのサインインとCopilotの利用権限も確認します。
- チャットのモード一覧で［Debugger］を選択するか、［Agent］モードで
@debuggerを入力します。 - Issueのリンク、または期待する結果と実際の結果を伝えます。判明している入力条件や例外も添えます。
- エージェントが不足情報を尋ねたり調査方法を提案したりしたら、実際の不具合に合っているか確認して進めます。
入口の操作はMicrosoft LearnのDebugger Agentの説明、Copilotのサインイン条件はVisual StudioでGitHub Copilotを使ってデバッグする手順で確認できます。一般的なCopilotデバッグの対応バージョンと、新しいDebugger Agentワークフローの提供範囲を混同せず、利用中のVisual Studioでモードが表示されるか確認してください。
Issueやチャットに伝える情報
「ときどき落ちる」だけでは、生成されたテストが何を再現すべきか判断できません。未確定の原因を言い切るより、観測できた条件をまとめると調査を進めやすくなります。以下は入力内容を整理するための例であり、実際に不具合を調査した記録ではありません。
| 情報 | 記入する内容 |
|---|---|
| 期待と実際 | 本来返す値・完了する操作と、例外・誤った値・停止した場所。 |
| 入力と条件 | 失敗時の入力値、前提状態、発生頻度、再現できた操作。 |
| 診断情報 | 例外メッセージ、コールスタック、関連するログや差分。 |
| テスト | 既存のテストプロジェクト、関連テスト名、実行結果。 |
| 変更の条件 | 維持したい仕様、変更できない範囲、確認してほしい境界値。 |
たとえば「入力が空の場合は0件で終了する想定ですが、例外になります。関連テストを調べ、同じ問題が失敗として現れるテストを作成または選択してください。原因はデバッガーの状態で確認し、修正案と検証結果を説明してください」と伝えます。Issueを使う場合も、期待する動作の説明は省略しないようにします。
Debugger AgentにはシェルやPowerShellへのアクセスがないと公式資料に記載されています。差分を調べてほしい場合は「gitコマンドを実行して」と依頼する代わりに、必要な差分の実際の内容を渡します。共有する情報は、チームで定めたCopilot利用方針の範囲にそろえてください。
テスト駆動調査で確認する4段階
1．修正前に、報告された失敗を再現する
最初に、選ばれたテストや生成されたテストの入力と期待値を読みます。テストが失敗していても、テストデータの不足や環境設定の問題で止まっているだけでは、目的の不具合を再現できたとはいえません。報告された例外や誤動作との対応を確認します。
2．実行時の状態で原因の候補を絞る
Debugger Agentはテストの実行を追い、変数、コールスタック、ブレークポイントなどを使って仮説を検証します。開発者は、どの値や分岐が期待と違ったのか、根拠を説明してもらいます。Live Debuggingを選ぶ場合も、同じように問題が起きる瞬間の状態を観測します。
3．修正案とテストの変更を一緒にレビューする
提案されたコードを確認し、仕様と影響範囲を判断してから承認します。テストを通すために期待値を誤った動作へ合わせていないか、問題の処理を通らないテストになっていないかも確認対象です。テストと実装の両方が変わったときほど、修正前の失敗を記録しておくと比較できます。
4．同じテストを再実行し、必要な関連テストを確認する
承認後は、失敗を再現したテストをもう一度実行し、結果を比較します。必要に応じて周辺機能のテストも確認します。対象テストの成功は、その条件で期待を満たしたという証拠です。アプリ全体の不具合がなくなったことや、未確認の環境での正常動作まで保証するものではありません。
テストの実行、実行時情報による調査、承認後の再実行という流れはMicrosoftの公式発表に基づきます。上記の期待値・影響範囲のチェックは、その流れをチームでレビューするための確認観点です。
チームに残す調査記録と評価ポイント
まず1件のバグで試す進め方は、テスト駆動調査でも有効です。小さな対象で、手動調査と比べた作業の変化を記録してから適用範囲を広げます。短縮時間や成功率は、実際に計測するまでは成果として扱いません。
- Issueと再現条件、利用したテスト名を残す。
- 修正前の失敗と、原因を裏付けた値・分岐・コールスタックを残す。
- 採用した変更、確認したテスト、未確認の範囲を分けて残す。
- 調査開始から再現に至るまでの時間や、人が修正した提案の内容を比較する。
よくある質問
テストがないプロジェクトでも自動で調査できますか？
Test-Driven Investigationには対応する既存のテスト基盤が必要です。手動で再現できるならLive Debuggingを検討し、再現できない場合は診断情報を補って次に調べる条件を決めます。テスト環境の対応を確認せずに、自動生成だけで解決できるとは判断しないでください。
エージェントが動いている途中にデバッガーを操作すべきですか？
Microsoft Learnでは、Copilotが実行を制御していて作業中の表示が続く間は、その処理を完了させるよう案内しています。自分で制御を引き取る場合はチャットの停止ボタンを使います。ブレークポイントで止まったことだけを理由に、処理が終わったと決めないようにします。
AIが修正案を出せば調査完了ですか？
修正案の提示と、動作を確認できたことは別です。実際の問題を再現した証拠、修正の妥当性、同じ条件での再確認がそろっているかを見て判断します。最終的な仕様判断とコードレビューは開発者が行います。
コメント