GitHub Copilotを使って複数のプロジェクトを比較・解析したい場合、VS CodeのMulti-root Workspaceがかなり便利です。別ウィンドウで左右に並べる方法もありますが、Copilotに両方のコードベースを参照させたいなら、1つのワークスペースにまとめるほうが扱いやすくなります。本記事では、Copilotに複数リポジトリを解析させる前提で、Multi-root Workspaceの使い方と活用ポイントを整理します。
Multi-root Workspaceとは
Multi-root Workspaceは、VS Codeの1つのウィンドウに複数のフォルダを追加して扱う機能です。通常は1つのプロジェクトフォルダを開いて作業しますが、Multi-root Workspaceを使うと、複数のリポジトリや関連プロジェクトを同じVS Code上でまとめて開けます Zenn。
たとえば、ライブラリ本体とそれを利用するアプリケーション、旧リポジトリと新リポジトリ、バックエンドとフロントエンド、移植元と移植先のような組み合わせを1つの作業空間にできます。VS Codeでは、それぞれのフォルダを独立したルートとして扱えるため、Gitの状態もプロジェクトごとに分けて確認できます Qiita。
Copilotに両方を見せたい場合に向いている
Copilot Chatに「この実装を別プロジェクトに移植したい」「AリポジトリとBリポジトリの構成差分を見てほしい」「このライブラリの使い方を利用側アプリから推測して」と依頼する場合、関連するフォルダが同じVS Codeワークスペースに入っているほうが自然です。
別ウィンドウで開いている場合、人間は左右を見比べられますが、Copilotにとっては文脈が分断されやすくなります。一方、Multi-root Workspaceでは、複数フォルダを同じ作業単位として扱えるため、Copilot Chatに対象ファイルやフォルダを指定しながら質問しやすくなります。
たとえば、次のような依頼がしやすくなります。
repo-aの認証処理を参考に、repo-bの実装方針を提案して
frontendとbackendのAPI定義にズレがないか確認して
旧プロジェクトのこの機能を、新プロジェクトの構成に合わせて移植する手順を出して
このように、Copilotを単なる補完ツールではなく、複数コードベースをまたいだ分析役として使うなら、Multi-root Workspaceはかなり相性がよい構成です。
設定方法
設定方法はシンプルです。まずVS Codeで1つ目のプロジェクトを開きます。その後、メニューから「File > Add Folder to Workspace…」を選び、比較したい別プロジェクトを追加します。必要に応じて、ワークスペースを .code-workspace ファイルとして保存できます atmarkIT。
.code-workspace として保存しておくと、次回から同じ組み合わせをすぐに開けます。たとえば、移植作業用、モノレポ分割作業用、ライブラリ検証用のように、目的別のワークスペースを作っておくと便利です。
構成例としては、次のようなイメージです。
my-migration.code-workspace
- old-service
- new-service
- shared-library
この状態でVS Codeを開けば、Copilotに対して「old-serviceの実装を参考にnew-service側の設計を見直して」といった質問をしやすくなります。
同じリポジトリの別ブランチならGit worktreeと組み合わせる
同じリポジトリの別ブランチを比較したい場合は、Multi-root WorkspaceだけでなくGit worktreeを組み合わせると便利です。Git worktreeを使うと、同じリポジトリの別ブランチを別ディレクトリとして展開できます Qiita。
たとえば、次のように実行します。
git worktree add ../feature-branch feature-branch
その後、元のブランチのディレクトリと、worktreeで作成したディレクトリを同じMulti-root Workspaceに追加します。これにより、Copilotに「mainブランチとfeatureブランチの設計差分を見て」「feature側の変更をmain側の構成に合わせるにはどうすればよいか」といった相談がしやすくなります。
この方法は、リファクタリング前後の比較、長期ブランチの差分確認、実験実装と本番実装の比較に向いています。単にGit diffを見るだけでなく、Copilotに設計意図や移植方針まで考えさせたい場合に効果的です。
運用時の注意点
Multi-root Workspaceに多くのリポジトリを入れすぎると、検索結果やファイル候補が増えすぎて、逆に作業しづらくなることがあります。Copilotに解析させたい対象だけをワークスペースに入れるのが基本です。
また、似た名前のファイルが複数ある場合は、Copilotへの指示でフォルダ名を明示すると誤解が減ります。「srcの実装を見て」ではなく、「old-service/srcの実装を参考に、new-service/srcへ移植する方針を出して」のように書くと、対象が明確になります。
Gitの変更もフォルダごとに分かれるため、コミット対象を間違えないように注意が必要です。VS Code上では複数リポジトリの変更が同じSource Controlビューに出ることがあるため、どのリポジトリに対する変更か確認してからコミットすると安全です。
まとめ
Copilotに複数のプロジェクトやリポジトリを解析させたいなら、VS CodeのMulti-root Workspaceを使うのが最も扱いやすい方法です。別ウィンドウでの比較は人間の目視には便利ですが、Copilotに両方のコードベースを意識させる用途では、1つのワークスペースにまとめるほうが自然です。
移植元と移植先、ライブラリと利用側アプリ、frontendとbackend、同一リポジトリの別ブランチなどをMulti-root Workspaceにまとめることで、Copilotに横断的な分析や実装方針の提案を依頼しやすくなります。複数コードベースを扱う作業では、まずMulti-root Workspaceを作り、必要に応じてGit worktreeを組み合わせる構成を基本にするとよいでしょう。