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

CopilotのAgent・SubAgent・Skillをポケモンに例えて理解する

Sat, 25 Apr 2026 09:30:00 +0900

GitHub CopilotのAgent、SubAgent、Skillという用語は、公式ドキュメントを読んでもすぐには頭に入ってこない。特に「Agentの中でSubAgentが動き、Skillが読み込まれる」という階層構造は、文字で追うと混乱しやすい。ところが、これをポケモンに例えた瞬間、全体像がすっきり見えてくる。この記事では、その比喩を通じて三者の役割と使い分けを整理する。

Agentはトレーナー

Agentの役割は、目的を持ち、状況を判断し、手持ちを動かす存在である。これはポケモンのトレーナーそのものだ。たとえばサトシとゴウは、同じ世界を歩いていても目的がまったく違う。サトシは「ポケモンマスターになる」ことを目指し、ゴウは「すべてのポケモンを捕まえる」ことを目指している。目的が違えば、選ぶポケモンも、戦い方も、旅のルートも変わる。

Agentが存在する理由は、ここにある。「バグを直したい」「新機能を設計したい」「リリースノートを書きたい」という目的ごとに、最適な進め方は違う。Agentは、その目的を受け取り、どのSubAgentにどう動いてもらうかを判断する司令塔の役割を担う。

トレーナーとしてのAgentの仕事

トレーナーは自分で技を出すわけではない。代わりに、場面に応じて手持ちを選び、指示を出す。Agentも同じで、自分で細かい作業をこなすより、タスクの分解と委譲が主な仕事になる。

目的を設定する
タスクをどう分割するかを決める
どのSubAgentに任せるかを選ぶ
結果を受け取って次の手を考える

SubAgentはポケモン

SubAgentは、Agentに呼び出されて特定の仕事をこなす専門家である。これはポケモンに当たる。ピカチュウは電気技が得意で、リザードンは炎と飛行が得意、ゲンガーはゴーストとエスパー対策に強い、というように、ポケモンごとに得意分野がはっきりしている。

SubAgentも同じで、「コードレビュー担当」「テスト作成担当」「ドキュメント整備担当」「セキュリティ監査担当」のように、役割ごとに専門化されている。Agentはタスクの性質を見て、適切なSubAgentを選んで呼び出す。これは、岩タイプ相手にはミズタイプを出す、という戦略と構造的に同じだ。

手持ちを揃えるという発想

ポケモンバトルで手持ちを6匹編成するように、Agentも複数のSubAgentを組み合わせて運用すると強い。単一の万能SubAgentを作ろうとするより、役割を分けておいた方が、プロンプトもコンテキストもシンプルに保てる。結果として、一匹あたりの判断精度が上がる。

Skillは技

Skillは、SubAgentが実行する具体的な動きである。これはポケモンの技に相当する。ここが比喩のキモで、技はポケモンに固有ではない。たとえば「でんこうせっか」はピカチュウも覚えるし、ニャースも覚える。「かみなり」はピカチュウだけでなく、サンダースやエレブーも使える。

Skillも同じで、「Hugoフロントマター生成ルール」「PR説明文テンプレート」「テスト追加手順」といったSkillは、特定のSubAgentに紐付いているわけではなく、必要に応じて複数のSubAgentから再利用できる。これが「Skillは再利用可能な手順」と言われる理由だ。

技マシンとしてのSkill

ポケモンは技マシンを使うことで新しい技を覚えられる。Skillもこれに近い。SubAgentは自分の得意分野のコア能力を持ちつつ、必要なときにSkillを読み込んで能力を拡張する。Copilotの世界では、Agent Skillsが関連タスクのときだけコンテキストに注入される仕組みになっており、これはまさに「戦闘中に必要な技だけ繰り出す」構造と一致する。

三者の関係を一枚絵で

ここまでの対応関係を整理すると次のようになる。

Agent = トレーナー：目的を持ち、戦略を決める
SubAgent = ポケモン：得意分野を持つ専門家
Skill = 技：複数のポケモンで共有できる具体的な動き

バトルの流れに置き換えるなら、「トレーナーが目的に応じてポケモンを選び、場面に応じて技を指示する」という構造になる。実務に置き換えれば、「Agentがタスクを分解し、適切なSubAgentを呼び、SubAgentが必要なSkillを読み込んで実行する」となる。

比喩が効く理由

この比喩がわかりやすいのは、役割の粒度と再利用性がきれいに対応しているからだ。トレーナー同士は目的が違うから入れ替えにくい。ポケモンは得意分野で役割分担する。技はポケモンを跨いで共有できる。Copilotの三階層も、同じ粒度設計になっている。

比喩が崩れるところ

ただし、この比喩には一点だけ素直に対応しないところがある。ポケモンの世界ではトレーナーが直接技を繰り出すことはなく、技を出すのはあくまでポケモンだ。一方Copilotでは、AgentもSubAgentと同じようにSkillを読み込んで自分で実行できる。小さなタスクであればSubAgentを介さず、Agentがその場でSkillを使ってしまう方が速い場面も多い。トレーナーが必要に応じて自分でも技マシンを使えるイメージだと思っておくと、設計時にミスマッチが起きにくい。

設計で迷ったときは、この比喩に戻ると判断しやすい。「これはトレーナーの仕事か、ポケモンの仕事か、それとも技か」と問い直すだけで、Agentに書くべきこと、SubAgentに閉じ込めるべきこと、Skillとして切り出すべきことが見えてくる。AIエージェントの設計は抽象的になりがちだが、手に馴染んだ比喩を一つ持っておくと、チームでの議論もかなり速くなる。

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環境は自然に育っていく。最初から完璧な設定を作るより、自分の操作に合わせて少しずつ拡張する方が実用的。

【GitHub Copilot】AgentとSkillの使い分け方

Thu, 23 Apr 2026 02:02:34 +0900

GitHub Copilotを使っていると、「Agentに任せるべきか」「Skillとして定義すべきか」で迷う場面があります。どちらもAIに作業を助けてもらう仕組みですが、役割はかなり違います。この記事では、AgentとSkillをどう使い分けると開発効率が上がるのかを、具体例つきで整理します。

Agentは「作業を進める担当者」

Agentは、ざっくり言えば「目的を渡すと、自律的に作業を進める担当者」です。GitHub Copilotのagent modeは、自然言語の指示をもとにコードベースを分析し、複数ステップの解決策を計画・実行し、コマンドやテストも実行できる同期的な協力者として説明されています。GitHub Blog

たとえば、次のような依頼はAgent向きです。

「このバグの原因を調べて修正して」
「既存のAPIにページネーションを追加して」
「テストが落ちているので原因を特定して直して」
「このPRの変更に合わせてドキュメントも更新して」

ポイントは、作業のゴールは明確だが、途中で何を読むか、どのファイルを直すか、どのテストを回すかはAIに判断させたいケースです。GitHub Copilot coding agentは、GitHub上でバックグラウンド実行され、ブランチ作成、コミット、Pull Request作成などを含めて作業できる仕組みとして説明されています。GitHub Docs

Agentに向いている指示例

悪い例は「いい感じに改善して」です。範囲が広すぎて、Agentがどこまでやれば完了なのか判断しにくくなります。

良い例は次のような形です。

ユーザー一覧APIにlimitとcursorを追加してください。
既存のレスポンス形式は壊さず、テストも追加してください。
変更後に関連するREADMEのAPI例も更新してください。

このように、完了条件、制約、確認方法を渡すと、Agentは動きやすくなります。

Skillは「再利用できる作業手順」

Skillは、Agentそのものではなく、Agentが必要なときに読み込める専門手順です。GitHub CopilotのAgent Skillsは、特定タスクの性能を上げるためにCopilotが読み込める「instructions、scripts、resourcesを含むフォルダ」と説明されています。GitHub Docs

Skillに向いているのは、毎回同じルールでやりたい作業です。

「このリポジトリのテスト追加方針」
「Hugo記事のフロントマター生成ルール」
「社内APIクライアントの実装パターン」
「GitHub Actions失敗時の調査手順」
「リリースノートの書き方」

たとえば、Hugoの記事を書くたびに「h1は使わない」「YAMLフロントマターを付ける」「タグとカテゴリを生成する」と毎回プロンプトに書くのは面倒です。これをSkillにしておけば、AgentやCopilotが該当タスクだと判断したときに、その手順を読み込んで作業できます。GitHubの説明でも、Skillが選ばれるとSKILL.mdがAgentのコンテキストに注入され、指示や同梱されたスクリプト・例を使えるとされています。GitHub Docs

使い分けの判断基準

一番シンプルな判断基準は、「今回だけの作業か、今後も繰り返す型か」です。

Agentを使うべきケース

Agentは、状況判断が必要な作業に向いています。

複数ファイルを横断して調査する
実装、テスト、修正をまとめて進める
エラー出力を見ながら試行錯誤する
Pull Requestとして成果物を残したい
途中の判断をAIに任せたい

たとえば「Neovimプラグインの設定読み込み順を調べて、起動時間を悪化させずに修正して」という依頼はAgent向きです。対象ファイルの探索、原因調査、実装修正、ベンチマーク確認が必要だからです。

Skillを使うべきケース

Skillは、作業の「やり方」を固定したい場合に向いています。

チーム固有のコーディング規約がある
毎回同じフォーマットで記事やIssueを作る
レビュー観点を統一したい
特定ツールの実行手順を覚えさせたい
失敗しやすい手順をチェックリスト化したい

たとえば「GoのAPIハンドラを追加するときは、handler、service、repository、migration、OpenAPI定義、テストを必ず更新する」というルールはSkill向きです。作業そのものはAgentに任せつつ、進め方はSkillで縛るイメージです。

組み合わせると強い

実践では、AgentとSkillは対立するものではありません。むしろ「Agentにタスクを任せ、Skillで作業品質を安定させる」と考えるのが自然です。GitHub Docsでも、簡単でほぼ全タスクに関係する指示はcustom instructionsに、関連時だけ読み込む詳細な指示はskillsに向いていると説明されています。GitHub Docs

具体的には、次のように組み合わせます。

Agentへの依頼:
認証APIにパスワードリセット機能を追加してください。

Skill側の定義:
- このプロジェクトのAPI実装パターン
- テスト作成ルール
- エラーレスポンス形式
- OpenAPI更新手順
- セキュリティレビュー観点

この形にすると、Agentは自律的に作業しつつ、プロジェクト固有のルールから外れにくくなります。

まとめ

Agentは「タスクを進める実行者」、Skillは「実行者に渡す専門マニュアル」です。迷ったら、まずはAgentに任せる単位を「完了条件のある作業」として切り出し、何度も繰り返す手順や品質基準をSkill化するとよいでしょう。

開発者にとって重要なのは、AIに丸投げすることではなく、AIが迷わず動ける環境を設計することです。Agentで作業を進め、Skillで再現性を高める。この組み合わせを意識すると、Copilotは単なる補完ツールから、かなり実用的な開発パートナーに近づきます。