GitHub Copilotで既存コードを修正するときの使い方

GitHub Copilotで既存コードを修正するときは、変更の大きさと不確実さで依頼方法を分けます。対象が一つの関数なら該当箇所を示して小さく直す。複数ファイルにまたがる仕様変更なら、先に調査と計画を出させてから編集する。この切り分けが、意図しない広範囲の変更を防ぎます。

Copilot Chatの画面や使えるモードは、IDE、拡張機能のversion、plan、organization policyによって異なります。公式DocsでAsk、Plan、Agentなどが説明されていても、どの環境にも同じ選択肢が表示されるとは限りません。機能がない場合も、通常のchatで「調査だけ」「計画だけ」「編集して検証」と段階を明示できます。

変更前の状態を固定する

既存コードでは、まずbranch、未保存変更、現在のtest状態を確認します。変更前から失敗しているtestがあるなら、今回新たに起きた問題と分けて記録してください。対象file、呼び出し元、関連type、testを読み、既存の実装方針を把握してから依頼します。

症状だけを伝えても入力は足りません。期待挙動、実際の挙動、再現条件、変更可能な範囲、触れてはいけないAPIや画面、実行する検証を一緒に示します。例：「保存buttonで空文字も保存される。空文字は無効にする。API response形式と既存error表示は変えず、関連formとtestだけを先に調査する」。問題と制約を分けて書けば、実装の前提を見直せます。

Ask / Plan / Agentを作業段階に合わせる

コードの理解にはまず説明を求めます。影響範囲が分からない段階で編集を許すと、推測によるrefactorが混ざりやすいためです。IDEにPlan modeがあれば、要件、触るfile、未確定事項、test方法を先に計画させます。計画時はコードを変更しないよう指定し、内容を読んでから実装へ進みます。

Agent機能が利用できる環境では、複数fileを調べて編集し、terminal操作を含む作業を依頼できる場合があります。しかし「必要なら何でも変えて」は範囲が広すぎます。変更を許すfile群、data変更の禁止、新規dependency、実行commandの範囲を指定します。組織管理者が機能を制限する場合もあるため、操作が見当たらなければ計画を通常chatへ貼り、作業段階を分ければ足ります。

依頼文を受け入れ条件にする

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

項目	書く内容	例
目的	何を直すか	空の名前を保存できないようにする
現状	何が起きるか	空文字でも成功responseになる
期待	どうなればよいか	保存せず既存errorを表示
範囲	変更可能な場所	form、validation、関連test
禁止	変えないもの	API response、URL、共通form
確認	実行するもの	対象test、typecheck、lint

変更に複数の解釈があるなら、編集前に仮定と未確定事項を列挙させます。ユーザーへ確認が必要なProduct判断と、既存codeから確かめられる実装判断を分けます。小さな修正でも受け入れ条件を一文で書くと、reviewの視点がぶれません。

Repository instructionsを短く保つ

GitHubのrepository custom instructionsは、共通のcoding ruleやtest方法を伝える手段です。たとえば.github/copilot-instructions.mdに、test command、format、命名規則、避ける変更を記載します。特定directory向けの指示は、IDEや機能ごとに対応が違うため、いつでも読み込まれると決めつけずsupport範囲を確認してください。

指示fileを置いてもreviewは不要になりません。今回固有の禁止事項はpromptにも書きます。内容が古いcommandや過去のarchitectureを前提にしていないか定期的に確認します。Copilotの応答がruleを読み違える場合、指示を大量に増やす前に今回必要な制約をpromptで明示します。

変更差分を小さく保つ

対象fileと関連testをcontextに加え、不要なfolderを無差別に含めないようにします。大きなrepositoryでは、余計なfileが似た実装を混同させることがあります。逆に呼び出し元やtype定義が必要なのに関数だけを見せると、局所変更が契約を壊すことがあります。「編集するfile」「読むfile」「変更禁止」を分けて依頼します。

出力差分では、要求と関係ない整形、命名変更、dependency追加、error handling削除、定数変更を探します。diffが急に大きくなったら、不要な変更を戻すかtaskを分けます。「既存コードを修正」はfile全体を作り直す許可ではありません。

まずは使ってみる

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

• 

  GitHub Copilot

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

Validationも依頼の一部にする

READMEやpackage設定から既存の検証commandを確認し、修正後にtest、typecheck、lintなどを実行します。存在しないcommandを推測してはいけません。結果が出ていないなら「通った」ではなく「未実行」と報告します。

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

症状	Copilotへ渡す情報	受け入れ条件
型error	全文、関連type、差分	typecheck成功、既存契約維持
画面不具合	操作、幅、期待表示	同じ操作で再現しない
test失敗	test名、入力、期待値	behaviorを弱めず成功
大きいdiff	file一覧、目的	各変更が説明できる

testが失敗したときは、変更前からの失敗か今回の差分が原因か分けます。assertion削除、期待値の弱化、skip追加でtestを通さないようにします。実装を直した後は同じtestを再実行し、差分も確認します。

変更を取り込む前にreviewする

Copilotの編集はdiffを人が確認してから採用します。各変更が受け入れ条件に対応するか、既存動作を壊さないか、dataやURLの意味を変えていないかを見ます。Agentがterminal commandを実行しても、実行結果とcode差分は別に確認します。

採用しない変更を破棄するときは、作業前の未commit変更まで消さないよう注意します。Gitを使わない環境なら、履歴や編集前copyなど戻せる方法を確認してください。完了後に、変更、検証したcommand、未確認事項を記録すると引き継ぎやすくなります。

AIものさしの判断

既存コードの修正では、Copilotのmode名より「調査と編集を分けられるか」「範囲を限定できるか」「同じ条件で検証できるか」が判断軸です。小さな局所修正なら直接の質問と限定編集で十分です。複数fileならPlan相当の段階で影響とtestを確認してから編集を許可します。

Repository instructionsは毎回の説明を減らす補助として使い、今回固有の制約は依頼文に残します。test結果だけでなくdiffを読み、結果が期待通りか人が判断します。AIの説明やtest成功は要求を満たす証拠の一部ですが、既存仕様を理解せず採用する理由にはなりません。

次は一つの小さな修正で「調査→差分→検証」を試してください。モードが利用できない環境でも、同じ段階をpromptで分ければ運用できます。

変更タイプ別の依頼例

バグ修正では症状と再現条件を中心に書きます。「原因候補を調べ、編集前に根拠を提示。原因確認後に対象関数とテストだけを変更」。機能追加では利用者の操作と成功・失敗状態を書きます。「新しい一覧filterを追加し、URL queryと既存paginationの契約を維持。空結果と戻る操作も確認」。refactorなら外から見えるbehaviorが変わらないことを条件にし、差分の対象を限定します。

依頼の種類によって、先に読むべきcontextも異なります。バグは呼び出し元とerror処理、機能追加は画面・データ契約・関連テスト、refactorは利用箇所と公開interfaceを優先します。Copilotが種類に合わないファイルまで変更し始めたら、作業を止めてscopeを戻します。

完了報告を再現可能にする

作業後は変更ファイル、検証したcommandと結果、未実行の項目、残る仮定を記録します。「直しました」だけでは、他の人が品質を判断できません。検証が失敗した場合も、成功と書き換えず原因を分けます。さらに次の人が同じtaskを再現できるよう、手動操作が必要ならその手順を記載します。

作業後に引き継ぐ情報

別の人がレビューするなら、変更理由と採用しなかった案も簡潔に共有します。特に、Copilotが提案したが仕様と合わず外した変更があれば、その理由を残します。完了報告には実行した確認だけを記し、未実行を明確にすることで、次の確認者が同じ作業を安全に続けられます。

既存branchに未コミット変更がある場合は、作業前後の範囲を区別し、AIが触れた差分だけレビューします。

たとえば入力検証を足す変更なら、拒否条件だけでなく正常値の保存結果も確認します。エラー表示が出たことだけで「修正成功」とせず、拒否時に保存APIが呼ばれないことと、正常時の既存responseが変わらないことを別々の受入条件にします。