Visual Studio 2026には、GitHub Copilotの「エージェント機能」が搭載されています。チャットで質問に答えてくれるだけでなく、エージェント自身がビルドやテストを実行しながら、自律的にバグ調査を進めてくれるという機能です。
これまで当ブログでは、同じバグ(C言語の成績管理システムに仕込んだ計算ミス)を題材に、
という2つの方法を試してきました。そして今回はCopilotのデバッガーエージェントに同じバグを調査してもらいます。
結論から言うと、一筋縄ではいかない場面もあり、エージェントの「得意な環境・苦手な環境」がはっきり見える結果になりました。
- Copilotデバッガーエージェントの使い方と、実際の調査の流れ
- エージェントがつまずいたポイントと、その原因(期待されるテスト環境)
- 手動デバッグ・チャット型AI・エージェント型AIの使い分け
先に結論
- デバッガーエージェントに「バグはありますか?」と聞くと、調査方法を対話で確認しながら進めてくれる
- ただし「テストを実行して確認する」ルートは、テスト環境が無い今回のプロジェクトでは空振りが続いた(原因は後述)
- 「コードを直接レビューして」と依頼したら、一発でバグを正確に特定。修正の自動適用までやってくれた
- テストの無い小さなコンソールアプリでは、最初からコードレビューを直接依頼するのが早くて確実
Copilotデバッガーエージェントとは
Visual Studio 2026のGitHub Copilotに搭載されているエージェントの1つです。
チャットの入力欄でエージェント(デバッガー)を選択して質問すると、単に文章で回答するのではなく、エージェント自身がビルド・テスト実行・デバッガー起動などのIDE操作を行いながら、バグの原因を調査してくれます。
今回使う環境
- Windows 11
- Visual Studio 2026(GitHub Copilot搭載/GPT-5 mini)
- 題材:成績管理システム(第1回)のコードに、わざとバグを仕込んだもの
バグの内容は過去2回と同じで、calc_average関数(平均点の計算)のforループがi = 0ではなくi = 1から始まっているというもの(オフバイワンエラー)です。1人目の点数だけが集計から漏れ、平均点がズレて表示されます。
実演①:「バグはありますか?」と聞いてみる
デバッガーエージェントに、まずはシンプルに聞いてみました。
このプロジェクトのコードにバグはありますか?
すると、いきなり答えるのではなく、どうやって調べるかの選択肢が提示されました。
チャット型AIには無かった挙動です。今回は一番上の「テストを実行して失敗を確認する」を選んでみました。
テスト実行ルートは空振りが続いた
ところが、ここから雲行きが怪しくなります。
「どの範囲のテストを実行しますか?」という追加の質問に答えた後、返ってきたのは「プロジェクトを構築できなかったため、テストを実行できませんでした」というメッセージ。
不思議なことに、対象のプロジェクトを普通にCtrl+F5で実行すると問題なく動きますし、エージェントに「ソリューションをビルドする」を頼むとビルド自体は成功します(終了コード0)。
余談ですが、ビルド時に表示された英文を翻訳すると以下になるようです。テンション高めなのがちょっとじわじわきました(笑)
ビルド時に表示された英文の翻訳結果
「waitConfiguration、WaitUI、IssueReproductionというオプションを指定して、デバッガー起動関数を呼び出す予定です。その後、ツールの応答を捉えることが本当に重要なので、結果を報告する必要があります。このプロセス中に起きることを全て把握するようにします！正しい情報を効果的に集められているか、常にダブルチェックするのは良いことです。よし、始めましょう！」
本題に戻って…ソリューションのビルドは成功しますが、「テストを実行する」を選んだ時だけ、ビルド失敗の扱いになるのです。
ビルド出力を確認してもらうと、こんな報告がありました。
ビルドに致命的なエラーや警告は見当たりませんでした。実行プロセスは終了コード0で終了しています。
ただし、テスト実行時に「ビルドに失敗した」と返る事象が続いているため、テスト側のビルドやテストアセンブリ名が原因の可能性があります。
以前のテスト実行で使ったフィルタ(AllTests.dll)が正しくない可能性があります。テスト検出が行われていないか、テストアダプタ/アセンブリ名の不一致が原因かもしれません。
原因:エージェントが期待している「テスト環境」が無かった
調べてみると、原因はプロジェクト側にありました。
デバッガーエージェントは、
- テストを見る
- 仮説を立てる
- 修正する
- テストを再実行して直ったか検証する
いうループで動く設計になっています(Visual Studio公式ブログより)。
つまり、Visual StudioのTest Explorer(テストエクスプローラー)で実行できる単体テストが存在することが前提なのです。
Test Explorerで実行できるテストとは、具体的には以下のようなものです。
- C#/.NETの場合:xUnit / MSTest / NUnit のテストプロジェクト
- C++の場合:Google Test / Boost.Test など
今回のプロジェクトは、テストフレームワークを一切使っていない素のC言語コンソールアプリです。
テストランナーが探しに行く「テストが入ったDLL」がどこにも存在しないため、「AllTests.dll」というフィルタで空振りし続けていた、というわけです。
デバッグエージェントが本領を発揮できる環境をこちらが用意できていなかった、ということになりそうです。
実演②:「コードを直接レビューして」と頼んでみる
方針を変えて、テスト実行を諦め、こう依頼しました。
すると、今度は一発でした。
原因の特定はもちろん、find_max_index/find_min_indexは同じi = 1開始でも正しく動く理由や、定数の境界チェックといった追加の改善提案まで付いてきました。
過去記事でClaudeに聞いた時と同等以上の、正確な分析です。
修正の自動適用までやってくれる
さらにエージェントらしいのはここからで、「続けて修正を適用しますか?」に「はい」と答えると、実際にソースコードへ修正を適用してくれました。
適用前には「チェックポイント」が自動作成され、ワンクリックで元に戻せるようになっています。提案するだけのチャット型AIとの、明確な違いです。
修正後に実行すると、平均点が正しく75.2点と表示されました。
手動デバッグ・チャット型AI・エージェント型AIの使い分け
3部作の締めくくりとして、同じバグを3つの方法で調査した結果を整理します。
| 手動デバッグ(第1弾) | チャット型AI(第2弾) | デバッガーエージェント(今回) | |
|---|---|---|---|
| バグの特定 | ウォッチウィンドウで変数を追って自力で発見 | コードを渡すと一発で特定 | コードレビューを頼めば一発で特定 |
| 修正 | 自分で書き換える | 修正案を提示(適用は自分で) | 修正の自動適用まで対応(元に戻すのも簡単) |
| つまずきポイント | どこにブレークポイントを置くか、当たりが必要 | 実行時の状態は見えない | テスト環境が無いと調査ルートが空振りする |
| 向いている場面 | 実行時の挙動・タイミング依存の問題を確かめたいとき | 手軽にコードの論理ミスを見つけたいとき | テスト環境が整ったプロジェクトでの反復的な修正・検証 |
今回のような「テストの無い小さなコンソールアプリ」では、エージェントに最初からテスト実行ルートを選ばせるより、「コードをレビューして」と直接頼むのが一番の近道でした。
逆に言えば、単体テストが整備されたプロジェクトなら、エージェントは「修正→テストで検証→再修正」のループを自動で回せるはずで、そこでこそ本領を発揮する設計だと感じました。
テスト環境(Google Test等)を整えてのリベンジは、また別の機会に試してみたいと思います。
まとめ
- Copilotデバッガーエージェントは、調査方法を対話で確認しながら、ビルドや修正適用まで自律的に行ってくれる
- ただしテスト実行ベースの調査は、Test Explorerで実行できる単体テスト(xUnit/Google Test等)がある前提の設計
- テストの無いプロジェクトでは「コードを直接レビューして」と頼むのが早くて確実
- 修正の自動適用+チェックポイントによる復元は、チャット型AIには無いエージェントならではの強み
(関連記事カード:【Visual Studio 2026|C言語】デバッグ機能の使い方 / C言語のバグをAI(Claude)に直してもらった / C言語で成績管理システムを作る【第1回】)
最後まで読んでいただき、ありがとうございました！
コメント