開発環境 on hagizo.io

Copilotに複数リポジトリを解析させるならVS CodeのMulti-root Workspaceが便利

Wed, 29 Apr 2026 08:59:00 +0900

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を組み合わせる構成を基本にするとよいでしょう。

Neovim環境を育てる：ターミナル・ファイル操作・キーマップ設計

Thu, 23 Apr 2026 09:30:00 +0900

Neovim環境は、エディタ単体ではなく「ターミナル」「ファイル操作」「キーマップ設計」まで含めて整えると使いやすくなる。特に毎日触る操作は、コマンド入力よりもキー操作に寄せることで、作業の流れを止めにくくなる。

全体方針

最初から完成形を目指すよりも、日々の操作を少しずつ改善していく方が長続きしやすい。

項目	採用しているもの	理由
ターミナル	WezTerm	Luaで設定でき、Neovim設定との親和性が高い
ファイルエクスプローラ	neo-tree.nvim	ファイルだけでなく、バッファ一覧も扱いやすい
ショートカット設計	`;` / `;;` プレフィックス	1文字キーの枯渇を避けつつ、体系化しやすい
キーガイド	which-key.nvim	入力途中で次の候補を確認できる

WezTermを使う理由

WezTermは設定ファイルをLuaで書けるターミナル。Neovimの設定もLuaで書く場合、ターミナル側もLuaで管理できるのは大きな利点になる。フォント、配色、キーバインド、タブ、ペインなどをコードとして扱えるため、dotfilesで管理しやすい。

ターミナルとエディタの設定言語が揃うことで、環境全体を一つの開発基盤として扱える。

ファイル操作はneo-tree.nvim

ファイルエクスプローラにはneo-tree.nvimを使っている。neo-tree.nvimは filesystem、buffers、git_status などを扱える。特に便利なのは、開いているバッファ一覧を表示できる点。

ファイルツリーだけでは「今どのファイルを開いているか」が見えにくいことがある。バッファ一覧をサイドバーで確認できると、作業中の文脈を保ったまま移動しやすい。

キーマップ設計

Neovimでは、よく使う操作をUserCommandにする方法と、キーマップに割り当てる方法がある。頻繁に使う操作は、コマンド入力よりキーマップ化した方が速い。毎回 :CommandName と入力するより、キー入力だけで実行できる方が作業の流れを止めにくい。

`;` と `;;` を使う

1文字のアルファベットキーだけでショートカットを作ると、すぐに割り当て先が足りなくなる。そこで、; や ;; をプレフィックスとして使う。

キー	用途
`;`	よく使う一等地の操作
`;;g`	Git系メニュー
`;;f`	ファイル系メニュー
`;;b`	バッファ系メニュー
`;;l`	LSP系メニュー

Git系であれば、次のように整理できる。

キー	操作例
`;;ga`	git add
`;;gp`	git push
`;;gs`	git status

プレフィックスで分類しておくと、キーマップが増えても破綻しにくい。

which-key.nvimで補助する

キーマップを増やすと、次に問題になるのは「何を割り当てたか忘れる」こと。which-key.nvimは、キー入力の途中で利用可能なキーバインド候補をポップアップ表示するNeovimプラグイン。

たとえば ;;g まで入力した時点でGit系の候補が表示されれば、次に a、p、s のどれを押せばよいか確認できる。各キーマップに desc を付けておくと、which-key.nvimで表示される説明も管理しやすい。

まとめ

Neovim環境は、プラグインを大量に入れるよりも、よく使う操作を迷わず実行できる状態にすることが重要。

方針	内容
ターミナル	WezTermでLua設定に寄せる
ファイル操作	neo-tree.nvimでファイルとバッファを扱う
操作体系	`;` / `;;` プレフィックスで分類する
補助	which-key.nvimで候補を表示する

日々の「少し面倒」をキーマップにしていくと、Neovim環境は自然に育っていく。最初から完璧な設定を作るより、自分の操作に合わせて少しずつ拡張する方が実用的。