［開発者向け］GitHub Copilotアプリの作業をVS Codeで引き継ぐ7ステップ

2026-10-202026-10-21

はじめに

　GitHubは2026年10月19日、GitHub Copilotアプリで進めたエージェントのセッションを、会話・コード変更・作業コンテキストを保ったままVS Codeで続ける方法をGitHub Blogのチュートリアルで紹介しました。本稿では、その7つの手順とレビュー時の確認ポイントを整理します。

参考記事

タイトル: How to continue a GitHub Copilot app session in VS Code
著者: Kayla Cinnamon
発行元: GitHub Blog
発行日: 2026年10月19日（米国太平洋時間、UTC-7）
URL: https://github.blog/ai-and-ml/github-copilot/how-to-continue-a-github-copilot-app-session-in-vs-code/

要点

GitHub CopilotアプリのセッションをVS Codeで開くと、会話・差分・ワークツリーを保ったまま作業を続けられる。
手順は、セッションの確認、VS Codeでの展開、レビュー、手作業の編集、ローカル検証、Copilotとの併用、コミットとプッシュの7段階である。
元記事はレビュー時に、要件の充足、規約への準拠、エラーとエッジケース、テスト、無関係な変更の有無を確認するよう求めている。
セッションに関連付いたブランチをプッシュすると、その作業を追跡している既存のプルリクエストが更新される。

詳細解説

概要：エージェントの作業をエディタで引き継ぐ

　GitHub Blogのチュートリアルは、エージェントが変更の大部分を終えた後に、実装の細部を確認し、数行を手で直し、出荷前にローカルで動かしたいという場面を想定しています。作業はGitHub Copilotアプリ上にある一方で、差分のレビューやデバッグ、最終調整はふだん使っているエディタで行いたい、という状況です。元記事によれば、このときセッションを捨ててVisual Studio Code（VS Code）で一からやり直す必要はなく、セッションをVS Codeで直接開けば、会話・コード変更・作業コンテキストを保ったまま続けられます。Copilotに反復的な作業や時間のかかる作業を任せ、詳細なレビュー、手作業の編集、ローカルテストの段階で開発者に主導権を戻す、という役割分担が示されています。

　元記事が挙げる、このチュートリアルで学べる内容は次の5点です。

CopilotアプリのセッションをVS Codeで開く
エージェントの変更を1行ずつレビューする
同じ会話をエディタから続ける
コードをローカルで修正・テストする
セッションに関連付いたプルリクエストへ更新をプッシュする

　ここでいう「セッション」は、エージェントに依頼したタスクの単位を指し、変更されたファイルだけでなく、依頼内容や計画、やり取りの履歴も含みます（詳しくは手順1で扱います）。エージェント型の開発支援では、ツールをまたぐたびに経緯の説明をやり直す手間が生じやすく、本稿としては、今回の引き継ぎ機能はその摩擦を減らすことを狙ったものと読んでいます。

前提条件

　元記事は、始める前に次の4点がそろっていることを前提としています。

GitHub Copilotアプリがインストールされ、サインイン済みであること
Visual Studio Codeがインストールされ、同じGitHubアカウントに接続されていること
レビューまたは続きの作業をしたい、コード変更を含むCopilotアプリのセッションがあること
セッションのリポジトリで作業し、変更をプッシュする権限があること

　また、このチュートリアルは、VS Codeの基本操作、統合ターミナル（エディタ内に組み込まれたコマンド実行用の画面）でのコマンド実行、Gitのブランチとプルリクエスト（変更内容のレビューと取り込みを依頼する仕組み）の扱いに慣れている読者を想定しています。

　補足すると、2点目の「同じGitHubアカウント」は見落としやすい条件だと思います。業務用と個人用など複数のGitHubアカウントを使い分けている場合、VS Code側で別のアカウントにサインインしていると引き継ぎがうまくいかない可能性があるため、事前にアカウントの一致を確かめておくと安心だと考えられます。4点目のプッシュ権限も手順7で必要になるため、権限の限られたリポジトリで作業している場合は、先に確認しておくのがよいと思います。

手順1：Copilotアプリでセッションを確認する

　まず、続きを進めたいセッションをCopilotアプリで開きます。元記事は、引き継ぐ前にタスクの内容とCopilotが完了した作業を一度見直しておくよう勧めています。

　元記事によれば、セッションは変更ファイルの集まりにとどまらず、タスク、計画、そしてその変更を生んだ会話も記録しています。この文脈は、Copilotがなぜその実装を選んだのかを理解したいときや、作業の一部を修正するよう依頼したいときに重要になります。VS Codeへ移る前に、履歴を要約したり、新しいチャットへコピーしたりする必要はありません。

　一般的なチャット型のAI支援では、別の画面やツールへ移る際に経緯を貼り直すことが少なくなく、その過程で依頼の意図が抜け落ちることもあると思います。本稿としては、計画と会話がセッションに残ることで、後のレビュー（手順3）で「なぜこう実装したのか」をそのまま尋ねられる点が、実務上の利点だと考えています。

手順2：セッションをVS Codeで開く

　セッション画面から「Open in VS Code」を選択します。アプリが複数の対応エディタやVS Codeのインストールを提示した場合は、使いたいものを選びます。

　VS Codeは、セッションに関連付けられたワークツリーでプロジェクトを開き、Copilotのサイドバーに既存のセッションを表示します。これにより、元の作業を構成する次の3つが、つながった状態で手元にそろいます。

セッションのコンテキスト（The session context）: タスク、計画、会話が引き続き利用できる
差分（The diff）: エージェントが変更したファイルと行が、レビューできる状態で用意される
ワークツリー（The worktree）: セッションが使っていたのと同じ、分離された作業ツリーをVS Codeが開く

　元記事は、新しいエディタウィンドウでセッションを再構築するのではなく、既存のセッションをそのまま続けている点を強調しています。

　ワークツリー（worktree）は、Gitで1つのリポジトリから複数の作業ディレクトリを作り、それぞれで別のブランチを扱える仕組み（git worktree）を指す用語です。元記事は具体的な実装方式までは説明していませんが、「isolated working tree（分離された作業ツリー）」という表現から、開発者がふだん作業しているチェックアウトとは別の場所でエージェントの変更が管理されていると考えられます。そのため、手元の未コミットの作業とエージェントの変更が混ざりにくい構成だと読めます。

　注意: VS Codeで開かれるフォルダは、ふだんのチェックアウトとは別の場所になっている可能性があります。ターミナルでコマンドを実行する際は、カレントディレクトリがセッションのワークツリーになっているかを確認しておくと、意図しない場所での作業を避けやすいと思います。

手順3：エージェントの変更をレビューする

　編集に入る前に、VS Codeで差分を確認します。ソース管理（Source Control）ビューを開いて変更されたファイルを確認し、ファイルを選択して変更を1行ずつレビューします。

　元記事は、ほかの変更提案と同じようにレビューするよう求め、特に次の点を確認するよう挙げています。

コードが依頼した問題を解決しているか
実装がリポジトリの規約に従っているか
エラー状態やエッジケース（境界的・例外的な入力や状況）が適切に扱われているか
変更された振る舞いをテストがカバーしているか
無関係なファイルや振る舞いが変更されていないか

　保持された会話は、Copilotがその実装に至った経緯を理解する助けになります。不明な点があれば、サイドバーでCopilotへのプロンプトを続けられます。元記事では、次のようなプロンプト例が示されています。

Explain why you changed this function instead of adding a new helper. Identify any behavior this could affect.

　このプロンプトは「新しいヘルパー関数を追加するのではなく、なぜこの関数を変更したのかを説明してください。この変更が影響しうる振る舞いを特定してください」という意味です。実装の判断理由と影響範囲を、1回の依頼でまとめて尋ねている点が特徴です。

　Copilotに追加の変更を依頼することもできます。セッションとワークツリーがつながったままなので、タスクを最初から説明し直す必要はありません。

　5つの確認項目のうち最後の「無関係な変更がないか」は、エージェントがタスクの範囲を超えて周辺のコードを整形・修正するケースを想定したものと考えられます。差分の大きさはレビューの負担に直結するため、本稿としては、ファイル一覧の段階で想定外のファイルが含まれていないかを先に確かめると、効率よくレビューを進められると考えています。

手順4：手作業で編集する

　提案された変更を理解したら、VS Codeで任意のファイルを直接編集します。元記事は、手で行ったほうが速い、あるいは簡単な調整として、次の例を挙げています。

ラベルやエラーメッセージを調整する
分かりやすさのために変数名を変更する
レイアウトやスタイルを調整する
不足しているテストケースを追加する
リポジトリ固有の規約を適用する

　編集しているのはセッションの既存のワークツリーなので、手作業の変更はエージェントの作業の上にそのまま積み重なります。ディレクトリ間でファイルをコピーしたり、ブランチを手動で作り直したりする必要はありません。

　挙げられた例は、いずれも「変更内容が明確で、指示を言葉にするより自分で書いたほうが早い」種類の修正と読めます。一行の文言修正のためにプロンプトを書いて生成結果を確認する往復を挟むより、直接編集したほうが手戻りが少ない場面は多いと思います。一方で、どこを直せばよいか見当がつかない修正については、手順6のようにCopilotへ任せる選択肢が残されています。

手順5：ローカルで実行・検証する

　VS Codeの統合ターミナルで、プロジェクトの通常の検証手順を実行します。実際のコマンドはリポジトリによって異なりますが、元記事はWebアプリの例として次を挙げています。

`npm install`
`npm test`
`npm run lint`
`npm run dev`

　これらは参考記事の例をそのまま掲載したもので、本稿で実行して確認したものではありません。補足すると、npm（Node.jsのパッケージ管理ツール）の `npm install` は package.json に記載された依存パッケージをインストールするコマンドで、`npm test` は package.json の `test` スクリプトを実行します。`npm run lint` と `npm run dev` は package.json に定義された `lint`・`dev` スクリプトを実行するもので、一般的にはコードの静的チェックと開発サーバーの起動に割り当てられることが多いものの、中身はプロジェクトごとに異なります。npmを使わないプロジェクトでは、READMEやCIの設定に書かれた手順に読み替える必要があると考えられます。

　元記事は、エージェントが生成した変更も人が書いたコードと同じように扱い、関連するテストを実行し、失敗を調べ、振る舞いを自分で確かめるよう求めています。

　開発サーバーがlocalhostのURLを出力した場合は、それを開いてブラウザで変更をテストします。VS Codeの環境が対応していれば、VS Codeの統合ブラウザでURLを開き、エディタを離れずに結果を確認することもできます。

　ユーザーインターフェースの変更では、依頼された振る舞いだけでなく、その周辺の状態も確認します。元記事は例として、変更したコンポーネントを異なるビューポート（画面の表示領域）サイズで確認すること、読み込み中・空の状態・エラー状態が引き続き正しく動くことを確かめることを挙げています。

　エージェントが生成したコードは、もっともらしく見えても、テストが整っていない分岐で問題が起きる可能性があります。元記事が「人が書いたコードと同じ扱い」と念を押しているのは、こうした確認を省略しないためと受け止めています。

手順6：Copilotとの対話と手作業を使い分ける

　元記事は、次の作業に合わせて、いつでも適した操作方法を選べるとしています。

リポジトリ全体の分析や反復的な編集が必要な変更では、Copilotにプロンプトを送る
加えたい変更が正確に分かっているときは、直接編集する
テストと改善を重ねながら、両方のアプローチを繰り返し使う

　例えば、UIを手作業で調整した後に、Copilotへ次のように依頼する例が示されています。

> Add a test for the updated label and run the relevant test file. Do not modify unrelated components.

　これは「更新したラベルのテストを追加し、関連するテストファイルを実行してください。無関係なコンポーネントは変更しないでください」という意味です。元記事によれば、元のセッションの中で作業しているため、Copilotは「the updated label（更新したラベル）」が何を指すかを解釈するのに必要な文脈を保持しています。

　この例文は、依頼内容（テストの追加）、実行範囲（関連するテストファイル）、禁止事項（無関係なコンポーネントは変更しない）を分けて伝えている点で、エージェントへの指示の書き方としても参考になると思います。特に変更範囲を明示的に制限する一文は、手順3の「無関係な変更がないか」というレビュー観点と対応しており、本稿としてはレビューの負担を抑える工夫と受け止めています。

手順7：コミットしてプッシュする

　実装の準備ができたら、最終的な差分をもう一度確認します。そのうえで、ソース管理ビューまたは統合ターミナルから変更をコミットしてプッシュします。元記事は次のコマンドを挙げています。

`git status`
`git add`
`git commit -m “Refine session changes”`
`git push`

　各コマンドの役割は次のとおりです。`git status` は変更されたファイルやステージング（コミットの対象として登録すること）の状態を表示し、`git add` は変更をステージングします。`git commit -m` は、`-m` に続く文字列をコミットメッセージとしてコミットを作成し、`git push` はローカルのコミットをリモートリポジトリへ送信します。

　注意: 元記事では `git add` とだけ記載されていますが、Gitの通常の動作では、対象のファイルやパスを引数で指定しないとステージングは行われません。実際には、ステージングするファイルを指定するか、ソース管理ビューで対象ファイルを選んでステージングする形になると考えられます。

　ブランチ運用、コミット、レビュー、承認については、リポジトリの通常の手順に従うよう元記事は求めています。VS Codeはセッションに関連付けられたワークツリーとブランチを開いているため、ブランチをプッシュすると、その作業をすでに追跡しているプルリクエストが更新されます。完成したファイルを別のチェックアウトへコピーしたり、作業をプルリクエストへ手動でつなぎ直したりする必要はありません。

　手作業の修正もエージェントの変更と同じプルリクエストに積まれるため、レビュアーからは両者が一連のコミット履歴として見える形になると考えられます。チームによっては、どの変更をエージェントが行い、どれを人が修正したかをコミットメッセージで区別しておくと、後から経緯を追いやすくなるという見方もできると思います。

エージェントからエディタへ続くワークフロー

　元記事は締めくくりとして、CopilotアプリのセッションをVS Codeで開くことで、作業そのものを分断せずに役割をはっきり分けられると述べています。Copilotは規模の大きい実装や反復的な実装を担い、開発者はエディタで詳細なレビュー、的を絞った変更、ローカルテスト、最終的な仕上げを行う、という分担です。

　セッション、差分、ワークツリーは、開発者がエディタへ移っても一緒に引き継がれます。Copilotアプリで作業を指示することから始め、手を動かしたくなった時点でVS Codeへ切り替え、完成した結果を同じプルリクエストのワークフローで送り出す、という流れが示されています。元記事の末尾では、GitHub Copilotアプリをダウンロードしてセッションを開始し、続きのコーディングをVS Codeで進めるよう案内されています。

　導入を検討する際の考慮点として、本稿では、手順3の確認項目をチームのレビュー観点としてあらかじめ共有しておくことが有効だと考えています。エージェントに任せる範囲と人が確認する範囲が明確になり、引き継ぎ後の作業がそろいやすくなると思われるためです。なお、Copilotアプリを利用できるプランや提供範囲は元記事では触れられていないため、実際に導入する場合はGitHubの公式情報で確認する必要があります。