既存のプログラムに仕様変更を加えたり、不具合を修正したりするときは、変更箇所を見つけるだけでなく、周辺の処理への影響も確認する必要があります。
GitHub Copilotを使えば、コードの役割を調べ、修正案を作り、テストの観点を洗い出す作業を支援してもらえます。
ただし、提案されたコードが常に正しいとは限りません。
この記事では、Visual Studio Codeで既存コードを安全に修正・更新する基本手順と、指示の出し方、変更後に確認すべきポイントを解説します。
GitHub Copilotで既存コードを修正できる理由
GitHub Copilotは、開いているファイルや選択したコード、チャットで共有した情報などをもとに、コードの説明や変更案を提示します。
そのため、ゼロからコードを書く場面だけでなく、既存の関数を変更したり、エラーの原因を探したりするときにも活用できます。
たとえば、入力チェックの条件を追加する、古い処理を新しい仕様に合わせる、重複した処理を整理するといった作業が対象です。
Copilotは修正作業を支援するツールであり、変更内容の正しさを保証するものではありません。
提案を採用する前に、差分、テスト結果、プロジェクト固有のルールを人が確認することが重要です。
修正を始める前に準備すること
変更対象と期待する動作を整理する
Copilotに依頼する前に、「どのファイルをどう変えるか」だけでなく、「変更後に何ができるべきか」を言葉にしましょう。
「ログイン処理を直して」のような曖昧な指示では、修正の範囲や望ましい挙動をCopilotが判断できず、意図しない変更につながる可能性があります。
たとえば、対象、現在の問題、期待する動作、変更してはいけない範囲を整理すると、指示が具体的になります。
- 対象：ユーザー登録フォームの入力検証
- 現在の問題：空白だけの名前が登録できてしまう
- 期待する動作：前後の空白を除去し、空文字になった場合は登録を拒否する
- 制約：画面表示やAPIの戻り値は変更しない
変更前の状態を保存する
作業を始める前に、Gitで変更前の状態をコミットするか、ブランチを作成しておくと、問題が起きたときに戻しやすくなります。
すでに未コミットの変更がある場合は、今回の修正と混ざらないよう、差分を確認してから作業しましょう。
コードを変更する前に、関連するテストを実行して現在の状態を記録しておけば、修正によって新たな不具合が起きたか判断しやすくなります。
GitHub Copilotに既存コードを修正させる手順
1. 関連するコードと仕様を確認する
まず、変更したい関数やクラスを開き、呼び出し元、利用しているデータ、関連するテストも確認します。
一つのファイルだけを見て変更すると、別の処理が同じ関数に依存していることを見落とす場合があります。
コードの役割が分からないときは、いきなり変更を頼むのではなく、Copilotに説明を求める方法が有効です。
この関数の処理内容を、入力・出力・副作用に分けて説明してください。
コードはまだ変更しないでください。先に説明だけを依頼すれば、変更案を受け取る前に、Copilotが処理をどう理解しているか確認できます。
2. 修正の目的と制約を明確に伝える
コードを選択してチャットに含めるか、対象ファイルを開いた状態で、変更したい内容を具体的に伝えます。
プロジェクト全体の規約が関係する場合は、使用する言語やフレームワーク、既存の命名規則、互換性の条件も添えましょう。
選択した入力検証処理を修正してください。
名前の前後の空白を除去し、処理後に空文字ならエラーにしてください。
エラーの形式と関数の戻り値は変更せず、必要最小限の差分にしてください。
変更した理由も説明してください。変更してほしい点だけでなく、変更してはいけない点も伝えると、修正範囲を限定しやすくなります。
3. 提案された差分を確認して適用する
Copilotが変更案を提示したら、すぐにすべてを適用せず、変更前後の差分を確認します。
依頼していないファイルや関数まで変更されていないか、既存の仕様を壊していないかを一つずつ見てください。
コードの見た目だけで判断せず、条件分岐の境界、エラー処理、戻り値、外部への副作用も確認します。
提案の一部だけを採用したい場合は、必要な箇所だけ適用し、残りは手動で戻すか、修正範囲を絞って再依頼します。
4. テストを実行して結果を検証する
変更後は、まず修正対象に対応するテストを実行し、可能であれば関連するテストやビルドも確認します。
既存テストがない場合は、通常の入力だけでなく、空値、境界値、異常な形式などのケースを検討してください。
Copilotにテストケースの候補を出してもらうことはできますが、実際の仕様と合っているかは人が判断する必要があります。
テストが失敗した場合は、エラー内容と該当コードを示し、原因の説明と修正案を分けて依頼すると、やり取りを整理できます。
仕様変更と不具合修正で指示を変える
仕様変更では、変更前後のルールを示す
仕様変更を依頼するときは、以前の動作と新しい動作を対比して伝えると、変更点が明確になります。
たとえば「上限を変更する」だけではなく、変更前の上限、変更後の上限、上限を超えた場合の扱いまで指定します。
既存データとの互換性や、画面・APIなど他の機能への影響も要件に含めると、検討漏れを減らせます。
不具合修正では、再現条件と期待値を示す
不具合の修正では、エラーが起きる操作、入力値、実際の結果、期待する結果をできるだけ具体的に共有します。
ログや例外メッセージを提示する場合は、パスワードや個人情報、アクセストークンなどの機密情報を必ず取り除いてください。
原因が分からない段階では、最初に「原因候補を挙げてください。コードは変更しないでください」と依頼し、調査と修正を分ける方法もあります。
安全に使うための注意点
Copilotの提案には、存在しない関数やライブラリ、プロジェクトの規約に合わない実装が含まれることがあります。
利用するAPIや依存パッケージは、公式ドキュメントやプロジェクト内の既存コードと照らし合わせてください。
認証、権限、決済、個人情報の取り扱いなど、影響の大きい処理では、通常より慎重なレビューとテストが必要です。
また、社内コードや顧客情報を扱う場合は、組織の利用ルールや契約、設定を確認し、許可されていない情報を入力しないようにしましょう。
最終的な判断とコードの責任は、提案を採用する開発者側にあります。
まとめ
GitHub Copilotは、既存コードの理解、仕様変更、不具合修正、テスト観点の整理を効率化するために活用できます。
期待する動作と制約を具体的に伝え、変更前の状態を保存し、提案された差分を確認してから適用することが基本です。
変更後は関連テストを実行し、境界値や既存機能への影響も検証しましょう。
Copilotに作業を任せきりにするのではなく、開発者が目的と結果を確認しながら使うことで、安全性と効率の両方を高められます。