VS Code on hagizo.io

GitHub CopilotはVS CodeとCLIをどう使い分けるべきか: auto・クレジット・実務フロー整理

Thu, 30 Apr 2026 14:00:00 +0900

GitHub CopilotはVS CodeとCLIをどう使い分けるべきか

GitHub Copilot を使い込むほど、VS Code の拡張機能を軸にするか、Copilot CLI を軸にするかで迷います。両者は競合ではなく、編集中心かターミナル中心かで役割が分かれます。

導入

現場でよくあるのは、次のような迷いです。

エディタ内の修正は VS Code Copilot で十分なのか。
それとも Copilot CLI で一気に流したほうが速いのか。
auto は VS Code だけなのか、CLI でも使えるのか。
クレジット消費は IDE と CLI で変わるのか。

このあたりを曖昧なまま使うと、作業フローが毎回ぶれます。この記事では、VS Code Copilot と Copilot CLI の違い、auto モデル選択、プレミアムリクエストの考え方、シーン別の使い分けを、実務前提で短く整理します。

TL;DR

まず結論です。

エディタ内の細かい編集、差分確認、反復リファクタは VS Code Copilot が向いています。
ターミナル中心の調査、コマンド実行、ディレクトリ単位の変更、SSH 先やコンテナ内の作業は Copilot CLI が向いています。
auto は VS Code の Copilot Chat でも、Copilot CLI でも使えます。
クレジット消費は「IDE か CLI か」ではなく、どのモデルを使い、どれだけリクエストを発生させたかで決まります。

最初に押さえるべき完成形は次の 3 つです。

# 1. Copilot CLIで一時的にautoを使う
copilot --model auto -p "プロジェクトの設定差分を確認して改善点を提案して"

# 2. 対話モードでautoへ切り替える
/model auto

# 3. CLIでカスタムプロバイダー利用時に環境変数でモデル指定する
export COPILOT_MODEL=auto

GitHub Copilotの違い

VS Code Copilot は、Copilot Chat のモデル選択 UI やチャット応答のホバー確認など、エディタに統合された形で使う前提です。差分や修正結果を視覚的に追いやすく、小さく直して確認するループに強みがあります。

一方の Copilot CLI は、対話型とプログラム実行の両方を持ち、ターミナルから直接コード変更、Git 操作、GitHub 上の PR・Issue 操作まで扱えます。信頼済みディレクトリや許可ツールの概念があり、ローカルだけでなくコンテナや SSH 環境でも同じ操作感を持ち込みやすいのが特徴です。

使い分けの早見表

観点	VS Code Copilot	Copilot CLI
主戦場	エディタ内の編集とレビュー	ターミナル内の操作と自動化
得意な作業	小刻みな修正、差分確認、会話しながらの実装	コマンド実行、ログ調査、ディレクトリ単位の変更
モデル選択	モデルピッカーから `Auto` を選択	`/model` または `--model` で変更
実行場所	主に IDE 内	ローカル、WSL、macOS、Linux のターミナル
安全性の勘所	差分を見ながら止めやすい	信頼済みディレクトリとツール許可管理が重要

autoモデル選択

auto は VS Code でも CLI でも使えます。GitHub Docs では、Copilot Chat の IDE 利用時に Auto を選ぶと、利用可能なモデルからポリシーと契約に応じて自動選択すると説明されています。

CLI 側でも Auto が使え、利用した応答ごとに実際に使われたモデルがターミナルに表示されます。モデル候補は今後変わる可能性があるため、固定モデルが必要な作業だけ明示指定する運用が実務では安定します。

VS Codeでautoを使う手順

Copilot Chat を開く、理由はモデル選択 UI がここにあるためです。
モデルピッカーから Auto を選ぶ、理由は毎回モデルを意識せずに使えるためです。
応答ごとに使用モデルを確認したい場合は、レスポンス上でホバーする、理由は実際のルーティング先を確認できるためです。

Copilot CLIでautoを使う手順

単発実行で使う場合は --model auto を付ける、理由はその場だけ auto に切り替えられるためです。
対話モードでは /model を使って切り替える、理由は会話中にモデル戦略を変えられるためです。
実際の利用モデルはターミナル表示で確認する、理由は auto が常に同じモデルを選ぶとは限らないためです。

実務でそのまま使う例です。

# 単発の調査
copilot --model auto -p "このリポジトリのテスト失敗原因を調査して"

# 対話モード開始
copilot
# 対話中に入力
/model auto

補足です。GitHub Docs で COPILOT_MODEL 環境変数は、独自のモデルプロバイダーを使う場合の設定項目として説明されています。標準の GitHub ホストモデルを常時 auto に固定する用途は、まず CLI のモデル選択機能と最新リリースノートで確認するのが安全です。

クレジット消費

プレミアムリクエストは、使った機能とモデルの multiplier に基づいて消費されます。GitHub Docs では CLI でも、プロンプト送信ごとにモデル一覧の括弧内 multiplier 分だけ毎月のプレミアムリクエスト枠が減ると説明されています。

そのため、VS Code だから安い、CLI だから高い、とは言い切れません。コスト差の本体は、どのモデルを選んだか、そして 1 タスクの裏で何回リクエストが走ったかです。

実務で差が出るポイント

VS Code Copilot は、小さい修正を複数回に分けて投げやすいです。結果として、1 回あたりの制御はしやすい一方で、往復回数は増えやすくなります。
Copilot CLI は、対話型でもプログラム実行でも大きめの仕事をまとめて依頼しやすいです。コード変更やシェル実行まで進むため、1 タスクあたりの総消費が見えにくくなることがあります。
auto には paid plan の Copilot Chat で 10% の multiplier discount があると GitHub Docs に明記されています。ただしこの割引説明は Copilot Chat 向けで、CLI に同じ条件がそのまま適用されるとは限らないため、課金判断は最新ドキュメント基準で見るべきです。

コストを抑える運用

VS Code では、関数単位・ファイル単位で区切って投げる、理由は差分確認で不要な広がりを止めやすいためです。
CLI では、いきなり --allow-all-tools で広く任せない、理由は変更範囲と副作用が大きくなりやすいためです。
大きい変更は CLI に下書きさせて、最終レビューと細部調整は VS Code で行う、理由は生産性と制御のバランスがよいためです。

実務フロー

おすすめは、VS Code と Copilot CLI を分業させる形です。設計相談、差分確認、局所的な修正は VS Code に寄せ、ログ調査、設定変更、リポジトリ横断の作業は CLI に寄せると迷いが減ります。

VS Code Copilotを選ぶ場面

複数ファイルをまたぐが、差分を目で追いながら進めたいとき。
テスト追加、軽いリファクタ、関数単位の修正を高速に回したいとき。
モデルを意識しすぎず Auto で会話し、必要時だけ実モデルを確認したいとき。

Copilot CLIを選ぶ場面

SSH 先、コンテナ、WSL、Linux/macOS ターミナルで完結したいとき。
ログ解析、設定ファイル整理、Git 操作、PR 作成のようにシェルと GitHub 操作が近いとき。
リポジトリ内のまとまった変更を一気に進めたいとき。

両方を組み合わせる形

VS Code でワークスペースを開く、理由は差分確認と最終編集を速くするためです。
統合ターミナルから Copilot CLI を起動する、理由はそのままプロジェクト文脈を渡せるためです。
CLI に大きめの変更を依頼する、理由は初速を上げるためです。
VS Code 側で差分を確認して局所修正する、理由は品質を落とさずに仕上げられるためです。

ハマりどころ

auto は便利ですが、選ばれるモデルは時間やポリシーで変わります。再現性が必要な検証では固定モデルを使うほうが安全です。
Copilot CLI は信頼済みディレクトリと許可ツールの設計を誤ると、意図しない変更を広げやすいです。特に --allow-all-tools は限定環境で使うべきです。
COPILOT_MODEL を見て標準 CLI 全体の常設設定だと解釈しがちですが、ドキュメント上は独自プロバイダー設定の文脈です。標準運用では /model、--model、最新リリースノート確認を優先したほうが混乱しません。

まとめ

VS Code Copilot は、編集、差分確認、細かい反復に強いです。Copilot CLI は、ターミナル中心の調査、自動化、大きめの変更に強いです。

重要なのは、どちらか一方に寄せ切ることではありません。auto とプレミアムリクエストの仕組みを理解したうえで、作業粒度ごとに役割を分けると、Copilot の強みを無駄なく引き出せます。

普段の開発で「この作業は VS Code」「この作業は CLI」と先に線引きしておくと、判断の迷いが減ります。その結果、AI を使う時間そのものよりも、実装とレビューに使える時間を増やしやすくなります。

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

【AI開発】GitHub Copilotで自分用エージェントを作る考え方

Wed, 22 Apr 2026 01:32:00 +0900

前回は、エージェントAIの設計パターンを「ゴールと計画」「推論と自己改善」「協調」「安全性ガード」の4レイヤで整理しました。今回はその考え方を、GitHub Copilotで実際に使える形へ落とし込みます。ポイントは、Copilotを単なる補完ツールではなく、指示、ツール、権限、検証手順を与えた「開発ワークフロー用エージェント」として設計することです。

Copilotで作れるエージェントの種類

まず、Copilotには大きく2つの使い方があります。VS CodeなどのIDEで使うagent modeと、GitHub上で動くCopilot cloud agentです。GitHub Docsでは、cloud agentはリポジトリを調査し、実装計画を作り、ブランチ上で変更し、必要に応じてPull Requestを作れると説明されています。About GitHub Copilot cloud agent

一方、VS Codeのagent modeはローカル開発環境の中で動く自律的なペアプログラマです。VS Codeのブログでは、agent modeはコードベースを分析し、ファイル編集を提案し、ターミナルコマンドを実行し、コンパイルやlintエラーを見て修正ループを回せると説明されています。VS Code Agent mode

ざっくり分けると、ローカルで一緒に試行錯誤するならIDEのagent mode、IssueやPR単位で非同期に任せるならcloud agentが向いています。

1. ゴール定義はプロンプトとinstructionsで作る

エージェント設計の最初の層は、曖昧な依頼を実行可能なタスクへ変換することです。Copilotでは、ここをプロンプトとcustom instructionsで作ります。

リポジトリ全体の前提は .github/copilot-instructions.md に書けます。GitHub Docsでは、リポジトリ全体のcustom instructionsとしてこのファイルを作り、プロジェクト構造、ビルド方法、テスト方法、コーディング規約などをMarkdownで記述できると説明されています。Adding repository custom instructions

たとえばDevOps系リポジトリなら、次のような情報を入れておきます。

# Repository instructions

- 変更前に対象サービス、環境、影響範囲を確認する
- CI/CD関連の変更では `.github/workflows/` と `scripts/` を必ず確認する
- 破壊的操作や本番反映は実行せず、計画と差分だけ提示する
- 変更後は `make test` と `make lint` を実行する

これは、前回の記事でいうPassive Goal CreatorとGuardrailsを、Copilot向けの常時コンテキストとして実装しているイメージです。

2. パス別instructionsで役割を分ける

リポジトリ全体の指示だけだと、フロントエンド、バックエンド、インフラ、ドキュメントでルールが混ざります。そこで .github/instructions/*.instructions.md を使います。GitHub Docsでは、applyTo frontmatterで対象パスを指定するpath-specific custom instructionsを作れると説明されています。Adding repository custom instructions

たとえばHugoブログなら、記事用のinstructionsを次のように分けられます。

---
applyTo: "content/posts/**/*.md"
---

# Blog post rules

- frontmatterには title, slug, draft, date, tags, categories, description を含める
- 本文では h1 を使わず、h2/h3 で構成する
- 外部情報を使った場合はMarkdownリンクで出典を残す
- draft は明示がなければ false にする

これにより、Copilotは「記事編集時のエージェント」と「コード編集時のエージェント」で振る舞いを変えやすくなります。

3. custom agentsで専門エージェント化する

さらに踏み込むなら、custom agentsを使います。GitHubのcustomization cheat sheetでは、custom agentsは独自のinstructions、tool restrictions、contextを持つ専門ペルソナで、.github/agents/AGENT-NAME.md などに置けると整理されています。Copilot customization cheat sheet

たとえば、次のようなエージェントを用意できます。

docs-writer: README、ADR、ブログ記事、リリースノートを書く
test-generator: 既存コードを読んでユニットテストを追加する
ci-debugger: GitHub Actionsの失敗ログを読み、再現手順と修正案を出す
security-reviewer: 依存関係、権限、シークレット混入を確認する

これは、前回の4レイヤでいう「協調」レイヤです。最初から巨大な万能エージェントを作るより、役割ごとに分けるほうがレビューしやすくなります。

4. MCPでツールを増やす

Copilotを本当のエージェントらしくするには、外部ツールへのアクセスが重要です。GitHub Docsでは、MCPを使うとCopilot agent modeが外部データソース、API、ツールへアクセスでき、調査、計画、実装、検証のループを回しやすくなると説明されています。Enhancing GitHub Copilot agent mode with MCP

開発者向けには、まず次のようなMCPサーバから始めるのが現実的です。

GitHub MCP: Issue、PR、ブランチ、Actionsの情報を見る
Playwright MCP: UIを操作してE2Eやアクセシビリティを確認する
Figma MCP: デザイン仕様を読み、実装との差分を確認する
独自MCP: 社内API、ログ、メトリクス、デプロイ情報を読む

MCPを足すときは、いきなり全部つなげないほうが安全です。公式ドキュメントでも、目的に合うサーバを選び、シンプルに始め、接続確認をしてからagent modeのタスクに使うことが推奨されています。Enhancing GitHub Copilot agent mode with MCP

5. 変更前にフェーズを分ける

Copilotにいきなり「全部直して」と頼むと、どの設計判断が正しかったのか追いづらくなります。おすすめは、Research、Plan、Implement、Validateの4フェーズに分けることです。

1. Research: まず関連ファイル、Issue、CIログを調べて、原因候補を列挙して。まだ変更しない。
2. Plan: 修正方針を2案出し、リスク、影響範囲、検証方法を比較して。
3. Implement: 採用した方針で最小差分を実装して。関係ない整形はしない。
4. Validate: テスト、lint、手動確認項目を実行し、結果をまとめて。

これはPlan & Execute、Prompt Chaining、Evaluator-OptimizerをCopilot上で手動フェーズ化したものです。特に本番系やCI/CD系の変更では、「まだ変更しない」「PRを作る前に計画だけ出す」「破壊的操作はしない」と明示するだけで事故を減らせます。

最小構成のおすすめ

まず作るなら、次の3点で十分です。

1つ目は .github/copilot-instructions.md です。リポジトリ概要、セットアップ、テスト、禁止事項、レビュー観点を書きます。

2つ目は .github/instructions/ です。frontend.instructions.md、backend.instructions.md、docs.instructions.md のように、パスごとのルールを分けます。

3つ目はMCPを1つだけ足すことです。GitHub連携かPlaywright連携のように、普段の開発で効果が見えやすいものから始めます。

この構成なら、単一エージェントでも「ゴール定義」「推論と実行」「安全性ガード」までかなり表現できます。必要になったタイミングで、custom agentsやagent skillsを追加し、docs-writer、ci-debugger、security-reviewerのような専門エージェントへ分割すればよいです。

Copilotでエージェントを作るとは、特別なAI基盤を最初から作ることではありません。自分の開発プロセスを、instructions、prompt、agent、MCP、承認フローとして明文化することです。設計パターンを意識してCopilotに渡す文脈を整えるほど、単なる補完ツールから、頼れる開発パートナーに近づいていきます。