GitHub CopilotをVS Codeで使うときの基本

GitHub CopilotをVS Codeで使うときは、補完・質問・計画・複数ファイルの編集を、作業の大きさに合わせて選びます。短いコードなら補完、既存コードの理解ならAsk、変更範囲が広いならPlanで影響を洗い出し、合意した範囲だけAgentへ渡すのが基本です。生成された差分は自分で読み、必要なテストを実行してから取り込みます。Agentへ任せることと、変更を承認することは別です。

この記事を読み終えると、VS CodeでCopilotを使い始める準備に加えて、「どの作業をどの入口に渡すか」「どこで止めて人が確認するか」を決められます。画面やプランによって使える機能が異なるため、モード名やボタンが見当たらない場合は、契約プラン、VS Codeと拡張機能の更新、組織の管理者設定を確認してください。

作業の大きさで入口を選ぶ

Copilotにはコード補完、チャット、Agentなど複数の入口があります。違いは賢さの順位ではなく、作業の範囲と編集権限です。質問に答えてほしいだけなのにAgentを使うと、頼んでいないファイル編集まで起きる余地が増えます。反対に、複数ファイルにまたがる変更を一行補完で進めると、設計の前提が揃いません。

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

やりたいこと	入口	渡す材料	終了条件
次の数行を書く	Inline suggestion	現在のコードと期待する処理	候補を読み、必要な部分だけ採用
既存コードを理解する	Ask / Chat	対象ファイル、関係する型や呼び出し元	根拠となるファイルと処理順が分かる
変更の段取りを決める	Plan	要件、制約、触れてよい範囲	変更ファイル、テスト、未決事項が明確
複数手順を実装する	Agent	合格条件、禁止事項、実行してよいcommand	差分・テスト結果を人がレビューできる

利用可能なモードや名称は、VS Codeの版、Copilotの契約、組織ポリシーで変わります。公式のIDE案内ではAsk、Plan、Agentの利用方法が説明されていますが、全アカウントで同じ選択肢が表示される保証ではありません。表示されない機能を探して時間を使う前に、アカウントと組織設定を確認しましょう。

VS Codeで作業を始める準備

まずGitHubアカウントでVS Codeにサインインし、Copilot関連拡張機能が有効になっているかを確認します。社内アカウントなら、管理者がChatやAgentを無効にしている可能性があります。利用できない機能を理由に設定を回避するのではなく、管理者ポリシーを確認してください。

次に、対象のリポジトリを開きます。Copilotへ質問するときは、どのファイル・関数・エラーを見てほしいかを限定します。大きなリポジトリで「このコードを直して」だけでは、意図した実装やテスト範囲が伝わりません。たとえば次のように、回答だけを求める質問を先に出せます。

この関数が受け取る値、呼び出し元、失敗時の挙動を説明してください。まだ編集しないでください。根拠にしたファイル名と、確認できない点も分けてください。

この段階では説明の正しさをコードと照合します。AIの説明に型名や関数名が出てきても、実際の実装に存在するかを検索すること。存在しないファイルを前提にした説明なら、質問の範囲を絞り直します。

AskからPlan、Agentへ進む境界

小さな質問ならAskで十分です。変更が必要と分かったら、まず目的と受け入れ条件を短く書きます。たとえば「CSVの不正行を無視する」ではなく、「不正行は取り込みを止めず、行番号と理由を返し、有効行だけ保存する。既存の列名と正常行の出力は変えない」とします。望む結果だけでなく、変えてはいけない契約も明記するのがポイントです。

複数ファイルやデータ移行が関係するなら、Planで次を確かめます。

• 変更対象のファイルと、それぞれの役割

• 既存の挙動のうち維持するもの

• 成功条件と失敗条件

• 追加・変更するテスト

• データや外部サービスへの副作用

• 不明な前提と、実装前に確認する質問

計画に抜けがあれば、その場で補正します。合意したらAgentへ「この計画の範囲で実装し、テストを実行する。別の仕様が必要なら先に報告する」と渡します。Agentは複数手順を進められますが、リポジトリ全体へ無制限に作業してよいわけではありません。秘密情報、デプロイ、DB削除など影響の大きい操作は、依頼範囲に含めない限り実行させません。

まずは使ってみる

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

• 

  GitHub Copilot

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

変更を受け取るときのレビュー順

Agentの完了メッセージだけで採用を決めず、差分から読みます。最初に変更ファイル一覧を見て、要件と関係のないファイル、設定、依存関係まで変わっていないか確認します。次に変更箇所を読み、入力の境界値、権限、エラー時、既存データへの影響を確認します。最後にテスト結果を再現可能な形で見ます。

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

レビュー箇所	見る問い	問題があれば
ファイル範囲	許可した範囲に収まっているか	不要変更を戻すよう依頼
正常系	代表入力で要件どおり動くか	入出力例を足して再確認
境界値	空、重複、極端な値、権限なしを扱うか	ケースを分けてテスト
失敗時	エラーが握りつぶされず、復旧可能か	失敗経路を修正
テスト	何を実行し、何が未確認か	未実行をPASSとしない

Copilot code reviewを使える環境では補助的な指摘を得られます。ただし指摘の採否は差分と仕様を見て決めます。AIレビューが問題を見つけなかったことも、完全性の証明にはなりません。テストは、実行されたものと実行できなかったものを分けて記録しましょう。

Repository instructionsを整える

同じ制約を繰り返し説明するなら、リポジトリのCopilot instructionsを使う方法があります。たとえばテストcommand、命名規則、触れてはいけない生成物、差分を小さくする方針を記録します。指示はモデルへの補助情報で、アクセス制御ではありません。秘密情報や認証情報は書かず、保護すべき操作はGit権限・CI・環境設定で制限します。

ルールが古くなると、Copilotが誤ったcommandやディレクトリを前提にする原因になります。配置後も、実際のpackage scriptsと照らし、更新担当を決めてください。特定ディレクトリだけに適用する規則は範囲を狭め、リポジトリ全体へ強すぎる指示を置かないようにします。

うまくいかないときの切り分け

候補が出ない場合は、サインイン状態、拡張機能の有効化、ネットワーク、契約と組織ポリシーを分けて確認します。Chatだけがない、Agentだけがないなど、機能ごとに設定が異なる場合があります。VS Codeを再起動する前に、アカウントと拡張機能の状態を確認すると原因を絞りやすくなります。

提案がプロジェクトとずれるときは、曖昧な前提を会話へ積み上げず、対象ファイル・期待する動作・変更禁止範囲を改めて示します。Agentが間違ったファイルを編集した場合は、差分を確認し、必要な変更だけ残します。CheckpointやGitの履歴がある場合も、戻せる範囲と対象を確認してから操作しましょう。

AIものさしの判断

VS Code版Copilotは、補完から複数手順の編集までを支援できます。使い分けの基準は、作業をどこまで任せるかです。質問はAsk、変更案を固める段階はPlan、実装はAgent、最終採用は差分とテストを人が確認する、という境界を守れば、便利さを活かしながら意図しない変更を抑えられます。

まずは読み取り専用の質問を1つ行い、回答が参照したコードを確認します。次の小さな修正で受け入れ条件を明示し、差分・テスト結果をレビューします。組織で機能が制限されている場合や、秘密情報・本番データを扱う場合は、個人判断で回避せず管理者のルールへ戻ってください。

最初の作業で試すミニ演習

使い始めの確認には、コードを書き換えない質問から始めると安全です。既存の小さな関数を選び、Askへ入力、出力、例外、呼び出し元を説明させます。次に、説明に出てきた関数や型を実際のコードで探します。コードと合わない説明があれば、参照範囲が足りないのか、回答が間違っているのかを切り分けます。

その後、変更が不要な作業ならそこで終えます。変更する場合は別の依頼として「このテストだけ追加し、実装はまだ変更しない」と範囲を区切ることもできます。段階を分ければ、理解のための会話と、ファイルを変更する作業を区別できます。これはレビュー前に不要な差分を作らないための小さな工夫です。

採用を保留する判断も用意する

提案が既存の設計と衝突する、テストの意味が不明、変更の影響範囲を説明できない場合は、すぐに採用せず質問へ戻ります。たとえば、単体テストが通っても、公開APIの互換性を壊していないかは別に確認が必要です。指摘が重大なら、まず再現手順と影響を確認し、小さな差分に分けます。

生成内容を読めないほど複雑になった場合は、コードを増やすより「この処理の責任を3つ以内に分け、既存テストを維持する計画を出して」と頼みます。最終的に自分で保守できる見通しが立たないなら、その変更は完成扱いにしないでください。