GitHub Copilotでエラー修正を進める方法

GitHub Copilotでエラーを修正する際は、再現条件と原因候補を先に確認し、原因を説明できてから最小変更を適用します。小さな構文・型errorならIDE内の /fix が出発点になりますが、複数fileや環境依存の障害は、log、呼び出し元、設定を含めて調べます。「表示されたerrorを消す」ことではなく、同じ条件で正しい動作へ戻ることが完了条件です。

Copilot Chatのslash commandやAgent機能はIDE、extension version、plan、組織設定によって使える範囲が変わります。/fixが見当たらない場合は通常chatで同じ目的を伝えます。機能名や画面が違っても、修正前に原因と範囲を把握する流れは共通です。

証拠を集めて再現条件を固定する

error全文、stack trace、発生時刻、操作手順、input、利用環境を記録します。browserならconsoleとnetwork status、serverなら該当時刻の安全なlog、commandなら実行内容とstderrを確認します。credential、個人情報、tokenはAIへ渡す前に伏せます。logの一部しか共有しないと、最初の原因行が欠けて誤診される場合があります。

いつから起きるかも切り分けます。毎回か、一部ユーザーだけか、deploy後か、特定inputだけか。変更前からあったかGit diffやrelease記録を確認します。再現できないなら仮定で修正せず、再現に必要な追加情報を整理します。環境差が疑われる場合はruntime versionや設定の有無を確認しますが、秘密値そのものは表示・共有しません。

Copilotへ渡す再現カード

表は横にスクロールできます

項目	記載する内容
症状	利用者が見た失敗、error全文
操作	発生までの最小手順
条件	input、environment、再現頻度
期待	本来の結果と仕様の根拠
実際	response、画面、log
変更	最近の関連diff
禁止	触らないAPI、URL、data、外部設定
確認	regression test、lint、型、build

期待を言葉にできない場合、codeの修正より先に仕様を確認します。error表示が消えることが期待とは限りません。失敗を握りつぶせば画面は静かになりますが、dataは保存されていないかもしれません。

/fixを使う範囲を見極める

Copilot Chatでは、選択codeや現在fileのerrorを説明・修正する方法として /fix が案内されています。対象が明確なcompile errorや局所問題では、原因候補と小さな修正案を得る入口になります。使えるcommand、参照file、実行操作は環境ごとに異なるため、手元で確認します。

login失敗、data不整合、network timeout、権限問題、複数serviceにまたがる障害では、表示fileだけで原因を特定できないことがあります。その場合、まず「調査だけを行い、原因候補、根拠file、未確認点を出す」と依頼します。編集前に、原因を一つに決めつけていないか見ます。似たlogが一件あるだけで別障害まで同じ原因にまとめないでください。

原因候補を証拠と反証で比べる

表は横にスクロールできます

原因候補	支持する証拠	反証・未確認	安全な次の確認
input形式が想定外	失敗値が境界条件と一致	同形式の別値は成功	最小ケースで再現
設定欠落	起動時に設定未検出	設定の存在だけでは不十分	値を伏せて有無・形式を確認
外部依存の遅延	timeout直前に接続待ち	相手先状態は未確認	statusと所要時間を記録
最近の回帰	関連fileに差分あり	差分と症状の因果不明	同条件testで比較

この表は原因を断定するものではなく、次に観測することを選ぶためのものです。未確認のまま設定変更、code変更、dependency更新を同時に行うと、結果の原因が分からなくなります。一度に一つの仮説を検証し、必要なら再現testを追加します。

原因確認後に最小patchを依頼する

原因が見えたら、Copilotへ変更前の挙動、原因、修正後に保証する条件を短く要約させます。次に対象fileと禁止範囲を指定してpatchを依頼します。Agent機能を使う場合も、作業前に計画を読み、無関係なrefactor、API変更、dependency追加が混ざらないようにします。

修正が表面上のerrorを隠していないか確認します。例外を握りつぶす、validationを外す、型を広げる、testをskipする、timeoutだけ延ばす、といった変更は根本解決でないことがあります。利用者向けのerror処理と内部診断logは目的を分けます。logに秘密値や生の個人情報が含まれないことも確かめます。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  GitHub Copilot

  公式サイトを見るTool詳細を見る

同じ条件で再テストする

最初に記録した操作、input、環境で再現しないか確認します。別の操作だけを試しても元の障害が消えたとは言えません。codeで再現できるbugなら、正常系と問題条件を固定するregression testを追加します。外部serviceをtestから直接呼ばない方がよい場合は、境界でtimeoutやerror responseをfakeにして失敗処理を確認します。

次に既存の関連test、typecheck、lint、buildを実行します。commandはREADMEやpackage設定から確認し、推測で作りません。testが通らない場合、assertionを弱めず失敗条件と要件を再確認します。修正前に再現testが失敗しないなら、症状を固定できていない可能性があります。期待値、input、environmentを見直してからpatchを評価してください。もともとの失敗は今回のdiffと分けて記録します。

表は横にスクロールできます

確認	見ること	完了の根拠
再現手順	元と同じ操作・input	同じ症状が出ない
regression test	問題条件を固定	修正前失敗、修正後成功
周辺test	関連機能の回帰	想定範囲のsuite成功
diff	副作用、無関係変更	各変更が原因に対応
secret	log、fixture、output	機密値なし

失敗が続く場合に調査へ戻る

再テスト後も症状が残るなら、同じpromptでpatchを重ね続けません。実際の挙動が説明と異なる、修正箇所が再現経路を通らない、別設定が上書きする、複数原因があるなどの可能性があります。変化した点と変わらない点を分け、次の仮説を立てます。

dataの上書き・削除、権限変更、Production設定、課金を伴う操作は通常のcode修正から切り離します。AIが原因候補を示しても、不可逆な操作を自動で行う理由にはなりません。復旧方法と影響を確かめ、広範囲の変更なら判断を得てから進めます。

AIものさしの判断

Copilotによるerror修正は、原因調査の補助と局所patchの作成に使います。小さな問題では /fix が利用できても、まず再現条件を記録し、原因と根拠を確かめます。複雑な障害では、仮説比較、修正、同条件での再testを段階に分けます。

error表示が消えたことだけでは十分ではありません。利用者が作業を完了できること、dataや権限の契約を守ること、同じ条件の回帰を防ぐこと、差分を説明できることを確認します。原因が特定できないなら、対処済みに見せず未解決として記録する方が正確です。

修正前後を比べる記録例

例えば「フォーム送信後、二度目のクリックで同じ依頼が二重登録される」なら、送信操作、二回目の条件、network response、保存件数を分けて記録します。期待が「同一送信中は再送できず、成功後は完了表示」なら、その二つを別々のtestにします。原因がbuttonのdisable漏れなのかAPIの重複処理なのか、先に決めつけず、両側の証拠を調べます。

同じ手順で修正前後を比較し、画面表示だけでなく保存結果も確認します。修正後に一回だけ成功したことは、再試行やnetwork timeoutの扱いまで正しい証拠にはなりません。必要なfailure caseを決め、外部呼び出しを安全なtest doubleで置き換えて確かめます。

ログをAIへ渡すときの注意

stack traceやrequest情報には、個人情報、cookie、authorization header、URL queryのsecretが混ざる場合があります。共有前に対象範囲を確認し、値を伏せてください。再現に必要なのは多くの場合、値そのものではなく「設定があるか」「形式は合うか」「statusと所要時間はいくつか」です。logを伏せた結果、原因の切り分けに必要な情報まで消えていないかを見ます。

修正結果の説明には、伏せた範囲と未確認事項を明記します。AIが安全な扱いを提案しても、送信先や保存先の権限を確認する必要があります。

修正を複数回試したときは、各試行で変えた仮説と観測結果を残します。別の変更をまとめて適用すると、再発時に原因を追えません。作業のたびに同じ再現カードとテストを使い、結果が変わった理由を一つずつ確かめてください。