はじめに
こんにちは！サロンスタッフ予約サービス「minimo」でエンジニアをしている Nozomuts です。
個人的に GitHub Copilot（以降: Copilot）にとてもお世話になっているので、自分なりの設定や良いなと思っている点をメモとしてまとめてみました！（2026/4 時点）
長めの記事なので、気になるところから拾い読みしてもらえればと思います。
基本的なことも多いですが、どなたかの参考になれば嬉しいです！
要約
- いまの GitHub Copilot は、補完やチャットだけでなく、
VS Code、CLI、Copilot cloud agent、Code Review、Spacesまで含む広い構成になっています。 - この記事では、Copilot の全体像を整理したうえで、自分が実際に効いていると感じている
VS Code設定、CLIの使い分け、Copilot cloud agentへの渡し方、Spacesやスキル（Skills）の例をまとめています。
まず押さえたい全体像
ざっくり整理するとこんな感じです。
Copilot Chat はローカル文脈で対話しながら進める土台、Copilot CLI はターミナル中心で速く回す役、Copilot cloud agent は GitHub 上で非同期に進めて PR まで持っていく役、Copilot Spaces は文脈を共有する置き場、Copilot Code Review は pull request のレビュー補助、という整理で見ると分かりやすいです。
以前は「補完」や「チャット」の印象が強かったのですが、守備範囲が広がってきていますね〜
プレミアムリクエストについて
ここは、まず公式ドキュメントベースで押さえておきたい話です。
公式ドキュメントで押さえたいこと
ざっくりいうと、プレミアムリクエストは「高度なモデルやエージェント機能に使う月次の予算」です。
追加のプレミアムリクエストなしで使えるモデルもありますが、対象モデルやモデル倍率は変わりうるので、最新のプラン表とドキュメントを見るのが安全です。
一方で、プレミアムモデルや Copilot CLI、Copilot cloud agent、Copilot Spaces などはプレミアムリクエストの対象です。
| 機能 | ざっくりした数え方 |
|---|---|
Copilot Chat (Ask / Plan / Agent) |
1 回のプロンプト × モデル倍率 |
| Copilot CLI | 1 回のプロンプト × モデル倍率 |
| Copilot cloud agent | 1 セッション × モデル倍率。さらにセッション中のステアリングコメントも追加対象 |
| Copilot Spaces | 1 回のプロンプト × モデル倍率 |
| Copilot Code Review | 1 回のレビューごとに 1 プレミアムリクエスト |
また、未使用のプレミアムリクエストは翌月に繰り越されず、毎月 1 日 00:00 UTC にリセットされます。
上限を超えた場合は、追加のプレミアムリクエスト購入用に予算を設定していれば、1 プレミアムリクエストあたり $0.04 の従量課金で継続利用できます。（2026/4 時点）
料金面を評価している理由
特に良いなと思っているのは次です。
- 有料プランなら、追加のプレミアムリクエストなしで使えるモデルもいくつかある
- 1 回の依頼でタスクを大きく進める場合は費用対効果が非常に高い
- 特に
Copilot cloud agentは 1 セッション単位でPRまで進むことが多いためお得 - 逆に、途中で止まって依頼を投げ直す回数が増えると、費用対効果は落ちやすい
- 特に
お得に使うコツ
特に後半のいくつかは観測ベースですが、効果があると感じているので、参考になれば嬉しいです！
-
VS CodeやCLIの自動承認をちゃんと設定して、可能な限り途中で止まらないようにする- ツール実行自体は追加のプレミアムリクエストにならなくても、途中で止まってこちらがプロンプトを投げ直すと、そのぶん消費が増えやすい
- まずは読み取り系など低リスクな操作だけを対象にし、必要なら少しずつ広げるのが無難
- reasoning を調整できるモデルでは、必要に応じて高めにする
- 1 回で調査や実装がまとまりやすくなる
-
Planモードで徹底的に詰めてから、まとめて実装させる-
Plan自体もプレミアムリクエストを使うが、後から往復する回数を減らせるため、合計では安く済むことが多い
-
-
askQuestionツールは積極的に活用させる- 少なくとも手元で試した範囲では、返答を返しつつ追加消費が増えていなかったので、積極的に質問させる方が効率が良い
-
Copilot ChatのモデルでAutoを選ぶ- 現時点では、10% の倍率割引
- 選ばれるモデルは時期や状況で変わるので、微妙なモデルに当たる可能性はある
上のいくつかは、単に節約というより「自律性を上げる」工夫でもあります。
そのため、1 つのタスクを深く進めやすくなるだけでなく、複数タスクを並列で進める使い方とも相性が良いです！
Copilot の良い点（抜粋）
VS Code との親和性
エディタの情報と AI の作業が素直につながっていて、見やすいエディタでコードを確認しながら進められるのが良いです。
また、VS Code では Local / CLI / Cloud / Third-party agent（Claude, Codex） を簡単に切り替えられますし、セッション管理も充実しているので、色々なタスクを並行して進めやすいです。
他にも、自作もしやすい豊富な拡張機能が使えたり、アップデート頻度も上がっているのも嬉しいポイントです。
料金面
料金の考え方は前の「プレミアムリクエストについて」でまとめたので、ここでは短く触れます。
無料でも少し触れますし、月 300 プレミアムリクエストの Pro プランが $10 なのは試しやすいです！
先ほど触れたように「1 回ちゃんと依頼して、最後まで進めてもらう」使い方と相性が良いのが強みです。
細かい使い勝手が良い
例えば自動承認では正規表現を使って粒度を細かくできます。
どのルールで通ったかが見えたり、承認待ちコマンドをその場で直せたりするので、運用しながら詰めやすいです。
例
以下の JSON は、「正規表現も含めてこのくらいの粒度で指定できる」というイメージをつかむための例です。
{
// Allow the `mkdir` command, regardless of arguments
"mkdir": true,
// Allow `test/scripts.sh`, since this contains a `/` it will also allow `\`
// and an optional `./` or `.\` prefix
"test/scripts.sh": true,
// Allow `git status` and all commands starting with `git show`
"/^git (status|show\\b.*)$/": true,
// Block the `del` command, regardless of arguments
"del": false,
// Block any command containing the text "dangerous"
"/dangerous/": false,
// Unset the default `rm` rule to allow other rules to auto approve `rm`
// commands
"rm": null,
}
Fetch ツールでは、SPA などの動的なコンテンツもMarkdownで取得できたり、許可するドメインを指定できたりと便利です。
こちらも「どこまで許可するか」は人や組織で差が出るので、使うなら最小限から始めるのが無難です。
設定周りもまとまっていて、触っていて引っかかりが少ないです。こういう細部の積み重ねは地味ですが助かります。
色々なモデルが使える
色々なモデルを試したり、比較したりできるのも助かります。
特定のモデルに強くロックインされにくいのは安心感があります。
使用するモデルの管理もできるので、使わないモデルは非表示にしています。
最近は GPT-5.4 や Claude 系のモデルを使うことが多いです！
新しいモデルが出たときにすぐ試しやすいのは素直に嬉しいですね〜
Copilot の気になる点
速度面
他のツールと比べると少し遅く感じます。
ただ、自分は別の作業をしながら裏で動かすことが多いので、そこまで強い不満にはなっていません。
CLI も最近触っているのですが、体感では CLI の方が速いので、用途に応じて使い分けるのも良さそうです。
精度面
GPT-5.4 の High, XHigh などを使うと良さげですが、モデル提供元の専用ツールと比べると一歩及ばないと感じる場面もあります。
Codex など他ツールと連携したりもできるので、うまく組み合わせていきたいですね〜
最近、reasoning effort をチャットから選べるようになったのは地味に助かっています。
個人利用で便利な機能
ここは、普段どこで何を使うかの話です。
個人利用の中心は VS Code（Copilot Chat）、CLI、Copilot cloud agent の 3 つです！
VS Code でよく使う機能
Agent / Plan / Ask
VS Code には、少なくとも次の 3 つの基本エージェントがあります。
| モード | 主な役割 | 向いている使い方 |
|---|---|---|
| Agent | ファイル編集、コマンド実行、自己修正まで含めて進める | 実装、修正、検証 |
| Plan | 実装前にステップ付きの計画を作る | 方針整理、分解、壁打ち |
| Ask | コード変更なしで質問や相談をする | 調査、確認、相談 |
以前は Ask で、参照するファイル or #codebase を指定しなければならず、少し使いにくかったです。
最近はエージェンティックな振る舞いが強まり、調査にも使いやすくなっています。
少し複雑なタスクでは、まず Plan で方針を作ってから Agent に渡す流れが多いです。
実行先を切り替えられる
Copilot は 1 つの UI から、次の実行先を切り替えられます。
| 実行先 | 特徴 | 個人的な使いどころ |
|---|---|---|
| Local | VS Code 上で対話的に進める | 普段の実装、細かい修正 |
| CLI | ローカルのバックグラウンド実行寄り | 調査、軽い実装、並列処理 |
| Cloud | GitHub 側で動かして PR ベースで進める | 放置したいタスク、PR 化 |
| Third-party | Claude や Codex なども選べる | モデル比較、用途別の使い分け |
しかも、途中で別のエージェントに委任できます。
つまり「VS Code で調査 → CLI で試作 → Cloud で PR 化」のような流れができます！
セッション管理が強い
VS Code のチャットセッション周りは、思った以上にちゃんと作られています。
- 複数セッションを並列で実行
- セッション一覧でローカル / バックグラウンド / クラウド実行をまとめて管理
- 未読 / 実行中のバッジ表示
- アーカイブ / 削除 / ピン留め
- キュー投入 / 追加指示 / 停止して送信
- セッションの fork 機能
- エクスポートや再利用しやすいプロンプト化
自分は、新しい話題になったらそこでセッションを切るようにしています。
基本的なことですが、これをやるだけで文脈が濁りにくくなりますし、あとで見返すときも整理しやすいです。
Inline suggestions / Inline chat
「この関数だけ直したい」「このコメントに沿って軽く直したい」みたいな場面に向いています。
- Inline suggestions
- 単一行から関数全体まで補完
- Next edit suggestions
- 次に編集しそうな箇所を提案
- Inline chat
- エディタを離れずに、その場で修正依頼
ただ、正直なところ癖で通常のチャットでやってしまうことも多いです。
Smart actions
Copilot は補完だけでなく Smart actions も便利です。
- コミットメッセージ生成
- シンボルのリネーム支援
- エラー修正
- セマンティック検索
特定の細かい作業がしやすいアクションが用意されているのはありがたいです 👍
ブラウザ操作までできる
Experimental ですが、統合ブラウザを使って Web アプリの動作確認やスクリーンショット取得もできます。
見た目の崩れチェックなど、軽い E2E 的な確認までエージェントに寄せられるのは面白いですね〜
Copilot CLI
最近使い始めたばかりですが、いくつか感じたことを書いていきます。
体感では VS Code より速い
自分の体感では、Copilot CLI の方が VS Code より速いです。
なので、調査、軽い実装、並列処理、放置したいタスクは CLI に寄せても良いなと感じています。
/research が便利
/research は使いどころがはっきりしていて好きです。
雑に調べ始めると散らかりやすい話でも、GitHub 検索と Web をまとめて見に行ってくれるので、最初の当たりを付ける用途で助かっています。
1 回 1 プレミアムリクエストで済むのも良いです。
/chronicle が便利
セッション履歴をローカルに保持して、それをもとに次のようなことができます。
-
/chronicle standup-> レポートの生成 -
/chronicle tips-> tips の生成 -
/chronicle improve-> instructions 改善提案
改善提案までしてくれるので、単なる履歴機能で終わっていないのが面白いです！
また、セッション履歴に関する質問は特にコマンドなしで聞けます。
終了時の使用量表示と resume が親切
CLI は終了時に、プレミアムリクエストの消費量や resume 用の情報を表示してくれるので親切です！
途中で作業を切っても戻りやすいので、この点は素直に助かります。
autopilot と /fleet が強い
CLI の特徴として、autopilot と /fleet もあります。
- autopilot
- 途中の確認や質問に自動で応答しながら、自律的に最後まで進めるモード
-
/fleet- 複雑なタスクを小さなサブタスクに分割し、並列実行する
公式ドキュメントにもある通り、この 2 つは別機能ですが相性が良いです。
「計画を作って → autopilot + /fleet で一気に回す」みたいな流れが作れます。
ただし /fleet はプレミアムリクエストの消費が増えやすいので、速さとコストのトレードオフはあります。
自動承認は CLI だと引数ベース
自分は、なるべく不要な承認を踏まずに自律的に動いてほしい派です。
VS Code 側は設定ファイルで細かく制御できますが、CLI 側はコマンドライン引数ベースです。
なので、毎回書くのが面倒なら ~/.zshrc などに alias を置いておくのが便利です！
# ~/.zshrc
# シンプルな例
alias copilot='copilot --allow-tool="shell(git diff:*)" --deny-tool="shell(rm)"'
さらに自律性を上げたいなら autopilot もありますね。
使う場合は sandbox も併用するのが安心です！
全許可したいときは --allow-all や --yolo もありますが、ここはさすがに慎重に使うのが良いかなと思っています🤔
Experimental を有効化すると触れるものが増える
experimental を有効化すると、CLI 側で触れる機能がさらに増えます。
手元で見ている限り、permissions、セッション管理、sub-agent、extensions 周りの先行機能は CLI 側に早めに入ってきます。
Preview / Experimental は変化も速いので扱いは少し慎重ですが、CLI の今後を考えるうえではワクワクする部分です！
その他、/review も気になっています。
Copilot cloud agent
自分は、GitHub 上でバックグラウンドに仕事を進めて、必要なら PR まで持っていく担当だと捉えています。
公式ドキュメントでは、次のような用途が挙がっています。
- リポジトリ調査
- 実装計画の作成
- バグ修正
- 小〜中規模の機能実装
- テストカバレッジ改善
- ドキュメント更新
- 技術的負債の解消
- マージ競合の解消
どこが使いやすいか
IDE の Local agent と違って、Copilot cloud agent は GitHub 側で作業します。
そのため、次のようなところが嬉しいです。
- ブランチ作成、コミットメッセージ作成、push、PR 作成までが自動
- ログが GitHub 上に残る
- チームで見やすい
ただ、制御できない面が多いので、しっかりカスタムエージェント化や指示を工夫して、安定して回るようにするのが大事かなと思います。
モデル選択や画像添付も最近できるようになってました🎉
個人的に気に入っている理由
個人的には、1 回投げたら放置しやすいのが一番大きいです。
また、Claude agent や Codex agent も試しましたが、品質差はそこまで大きく感じませんでした。
試した限りでは、デフォルトの Copilot がエラーが少なく安定していた印象です。
コスト感
公式ドキュメント上は、Copilot cloud agent は GitHub Actions 分とプレミアムリクエストを消費するとされています。
1 回あたり 1 プレミアムリクエストくらいの感覚で済むことも多く、ブランチ・コミット・PR まで進むことを考えると、割安に感じています。
VS Code とのつながりが良い
VS Code から Copilot cloud agent に引き継ぎできます。
例えば次の流れです。
- VS Code で調査・相談
-
Planで方針作成 - CLI で試作や検証
- 最後に
Copilot cloud agentへ引き継ぎして PR 化
途中までローカルで詰めて、実装部分を GitHub 上の agent に渡すのが使いやすいです。
チーム運用で便利な機能
ここは、レビューや共有コンテキストの話です。
個人利用でも便利ですが、チームで使うと効き方が大きい部分です！
Copilot Code Review
pull request に対して GitHub 上で走らせられる AI レビューアーです。
ノイズが減って実運用しやすくなった
正直、初期の頃は少し表面的で、コメント数も多めに感じることがありました。
「とりあえず何か言ってくる」感じのレビューもあり、ノイズが気になる場面もありました。
ただ、2026/3 の changelog で agentic architecture 化が案内されてから、大きく変わった印象です！
- 関連コード、ディレクトリ構造、参照関係を見ながらレビューできるようになった
- より意味のある指摘を優先し、ノイズが減った
- 問題だけでなく、直し方まで分かりやすいコメントが増えた
単にコメント量を増やすより、意味のある指摘を出す方向に寄せているのが分かります。
使い方
やること自体はシンプルです。
- GitHub.com の pull request で reviewer として Copilot を追加する
- 必要なら再レビューを要求する
GitHub 上では、人に reviewer を付けるのに近い感覚で使えます。
Copilot のレビューは comment review であり、Approve や Request changes ではないです。
そのため、必須レビューの承認数にはカウントされず、Copilot 単体でマージを止めることはありません。
自動でレビューさせる方法
Copilot Code Review は自動レビューもできます。
デフォルトブランチでサクッと設定したい場合は以下の設定を行います。
-
Settings→Copilot→Copilot Reviewで「Create ruleset for default branch」を作る
ブランチや条件などを設定したい場合は以下の設定を行います
-
Settings→Rules→Rulesetsで branch ruleset を作る -
Automatically request Copilot code reviewを有効化する - 必要なら条件を指定
- Review new pushes -> PR への新しい push ごとに再レビュー
- Review draft pull requests -> Draft 段階でもレビュー
GitHub Actions ベースなのも面白い
エージェンティックな Copilot Code Review は GitHub Actions を使って動きます。
必要なら self-hosted runner を設定できます。
カスタムインストラクション周りの注意点
ここは結構大事です。
Copilot Code Review はカスタムインストラクションに対応しています。
- リポジトリ全体向け
.github/copilot-instructions.md
- パス固有
.github/instructions/**/*.instructions.md
しかし、注意点があります。
- 最初の 4,000 文字しか読まれない
- pull request の base branch 側の instruction を使う
- 外部リンク先を読んで判断する instruction はサポートされない（@など）
なので、レビュー用 instruction は、Chat や Copilot cloud agent よりもさらに短くまとめるのが良さそうです！
モデルは選べない
Copilot Code Review はモデル切り替えをユーザー側でサポートしていません。
そのため、品質を上げたいときは instructions を詰めるのが効きやすいです。
ちなみに、実行履歴を見た感じだと、GPT系のモデルが使われているのが多かったです。
Copilot Spaces
Copilot に渡すコンテキストを整理して共有する場所です。
GitHub 版 Notebook LM みたいなイメージです。
まずは公式ドキュメントで押さえたいこと
2025 年後半で実戦投入しやすくなった
リリース当初は制限が多くて、活用方法を考えるのが難しかったですが、数々のアップデートで実用的になりました。
ソースとして持てる情報
次のようなものを参照できます。
| ソース | 例 |
|---|---|
| リポジトリ | リポジトリ全体 |
| コード | 特定のファイルやコード |
| pull request | 実装経緯やレビュー文脈 |
| issue | 背景や要件 |
| 自由形式テキスト | メモ、補足説明 |
| 画像 | 画面キャプチャ、図 |
| アップロードしたファイル | 仕様書、資料 |
さらに、Space には description と instructions の 2 つを持てます。
「人に読ませる説明」と「AI に守ってほしいルール」を分ける感じです！
何が嬉しいか
Spaces は、AI に渡す文脈を毎回ゼロから組み立てなくてよくなるのが大きいです。
- 回答の前提をそろえやすい
- 必要な情報を 1 か所にまとめやすい
- 知識共有やオンボーディングの入り口にしやすい
- エンジニア職以外の人も使いやすい
ソースは自動で追従するものがある
GitHub ベースのソースは、更新に応じて Space 側も追従します。
特にリポジトリを参照すると、常に main branch の最新内容を参照する仕組みになっています。
更新の手間が減るのは単純に助かります。
共有の考え方も良い
Space は個人所有にも組織所有にもできます。
| 所有形態 | 特徴 |
|---|---|
| 個人所有 | 非公開 / 特定ユーザー共有 / 公開共有 |
| 組織所有 |
admin / editor / viewer などで権限を分けやすい |
しかも閲覧者（viewer）は、自分がアクセスできるソースだけ見える形になっています。
さらに、2025/12 の更新で、個人所有 Space の公開共有（public）と個別共有（individual sharing）も入りました。
しかも、公開リンクだからといって非公開のソースが見えるわけではなく、閲覧者が権限を持つ範囲だけ見える形です。
利用可否は、プランや組織設定も含めて最新のドキュメントで確認するのが安全です。
個人的に効いている使い方
ここからは、公式の基本を踏まえたうえで、自分が実際によく使っているやり方です。
instructions をちゃんと書くと化ける
Spaces はソースだけでなく instructions の出来でだいぶ変わります。
例えば、複数リポジトリを持つサービスの調査用 Space なら、こんな感じで実用的になりました。
プロンプト例
<role>
あなたは複数プラットフォームで動くサービスのソースコードに精通したフルスタックエンジニアです。
技術的な内容を非エンジニアにも分かりやすく説明し、仕様調査や機能理解を支援してください。
</role>
<target_audience>
主な利用者は、プロダクトマネージャー、デザイナー、カスタマーサポート担当者など、技術的な背景を持たないチームメンバーです。
</target_audience>
<response_style>
- 日本語で、簡潔で分かりやすく説明する
- 専門用語を使う場合は平易な補足を入れる
- まず概要を伝え、必要なら具体例を続ける
- コード断片の貼り付けは最小限にし、概念レベルの説明を優先する
</response_style>
<repositories>
- iOS アプリ: repository-ios
- Android アプリ: repository-android
- バックエンド: repository-server
- Web フロント: repository-frontend
- 共通 DB: repository-db
</repositories>
<workflow>
1. 質問から対象機能・画面・プラットフォームを特定する
2. 適切なリポジトリ / ソースを選択する
3. コード / PR / issue / ドキュメントを確認する
4. 根拠付きで回答する
</workflow>
<citation_requirements>
- 参照したファイルや PR へのリンクを示す
- 実際に確認できた事実を優先する
- 情報が見つからない場合は、その旨を明確に伝える
- 推測を書く場合は、なぜ確信が持てないかも添える
</citation_requirements>
<space_routing>
- 全体像や横断質問はこの Space で扱う
- アプリ実装の詳細は app 用の専門 Space へ案内する
- API / DB / 非同期処理の詳細は server 用の専門 Space へ案内する
- Webの詳細は web 用の専門 Space へ案内する
</space_routing>
特に大事なのは次の 3 つです。
- 誰向けに説明するかを固定する
- 非エンジニア向けか、実装者向けかで答え方が変わります
- 根拠の出し方を固定する
- ファイルや PR をちゃんと示させると、調査用途でぶれにくくなります
- 専門 Space への振り分けを決める
- 1 つの Space に全部背負わせない方が運用しやすいです
入口 Space + 専門 Space の構成
自分は、次のような単位で Space を分けています。
Space は、全体俯瞰用・領域別の専門 Space・用途別の Space くらいに分けると扱いやすいです。
全体俯瞰用は入口、専門 Space は深掘り、用途別 Space はオンボーディングや FAQ のような横断用途に向いています。
特に、入口 Space が専門 Space へ案内する構成が気に入っています。
例えば次のような運用です。
- 「全体の仕組みを知りたい」
- 入口 Space で回答
- 「この API の保存処理を詳しく知りたい」
- server 用 Space に案内
- 「クライアントごとの画面差分を知りたい」
- app 用 Space に案内
回答の最後に、
- どの Space に行くとよいか
- そのままコピペできる質問文
を添えるよう instructions に書いておくと、使う側が迷いにくいです。
エンジニア職以外の方向けの調査導線としても有用だと思っています。
カスタマイズ機能
ここは主に、公式ドキュメントベースで整理したカスタマイズ機能の話です。
今の Copilot は、主流なカスタマイズ方法にはひと通り対応しています。
| 機能 | 何を固定するか | 向いている用途 |
|---|---|---|
| カスタムインストラクション | ルール、文体、ガイドライン | リポジトリ全体の共通ルール |
| スキル（Skills） | 再利用したい能力やワークフロー | レビュー、Git 操作 |
| カスタムエージェント | 役割、ツール、次に示すアクションなど | Plan 専用、レビュー専用など |
| Hooks | ライフサイクルに応じた確定処理 | safety、formatter、品質ゲート |
| MCP サーバー | 外部ツール、リソース、プロンプト | GitHub、ブラウザ、独自ツール連携 |
| 後半では、用途が偏ったものは省いて、VS Code の設定やスキル（Skills）などの汎用的なものを一部載せています。 |
カスタムインストラクション（Custom instructions）
.github/copilot-instructions.md、AGENTS.md、*.instructions.md、CLAUDE.md などが使えます。
用途のイメージはこんな感じです。
| ファイル | 主な用途 |
|---|---|
copilot-instructions.md |
プロジェクト全体の共通ルール |
AGENTS.md |
複数エージェント間で共有したいルール |
*.instructions.md |
言語やディレクトリごとのルール |
CLAUDE.md |
Claude 系ツールとも共有したいルール |
VS Code のドキュメントでは、applyTo を使ったファイル別の instructions も整理されています。
Claude Code のような他のコーディングエージェント向けのファイルも扱えるので、プロジェクト全体でルールをそろえやすいです。
カスタムエージェント（Custom agents）
昔の「カスタムチャットモード」が、今はカスタムエージェントになっています。
.agent.md で以下を定義できます。
- 説明や名前
- 使用可能なツールやMCP
- 使用するモデル
- サブエージェントとして使用できるエージェントのリスト
- 次に示すアクション
- Hooks
など
例えば「Plan 専用エージェント」「レビュー専用エージェント」「ドキュメント専用エージェント」などを常設できます。
役割が固定されるので、毎回プロンプトで説明し直さなくて済みます。
作成したカスタムエージェントは、ローカルだけでなく Copilot cloud agent 側でも流用できます。
スキルは便利ですが、毎回確実に使われる保証はないので、 Copilot cloud agent で「この手順で必ず進めてほしい」「このルールは必ず守ってほしい」みたいなときは、スキルよりカスタムエージェントが向いていると感じています！
Hooks
エージェントのライフサイクルで、自分のコマンドを確定的に実行できる機能です。
ただし、現時点では VS Code 側で Preview 扱いなので、運用に入れる前に挙動確認はした方がよさそうです。
例えば次のようなことができます。
- 危険なコマンドを事前に拒否する
- ファイル編集後に formatter を自動実行する
- ツール使用履歴をログに残す
- セッション開始時に文脈を追加する
- セッション終了前に test 実行を強制する
VS Code は Claude Code の hooks 形式や Copilot CLI の hooks 形式とも一定の互換があります。
MCP サーバー
MCP 周りも強いです。
VS Code の MCP は単にツールを増やすだけでなく、新しめの MCP Apps にも対応しています。
- Tools
- Resources
- Prompts
- MCP Apps
mcp.json を workspace / user profile に置けるので、チームで共有しやすいです。
MCP のツールごとに選択もできるので、読み取りだけ ON にするような使い方もしやすいです！
実際に使っている設定例
VS Code の設定例
2026/4 時点で、自分がデフォルトから変更している設定を載せています。
正解というより、「このあたりは触ってみる価値があるかも」という観点でまとめた例です。
まず入れているもの
| 設定 | 値 | 備考 |
|---|---|---|
| chat.agent.maxRequests | 100 |
1 ターン内で許可するリクエスト数の上限です。複雑なタスクでも途中で確認待ちになりにくく、最後まで流れを切らさず進めやすくなります。 |
| chat.viewProgressBadge.enabled | true |
進行中のセッションをバッジで把握できます。裏で何が動いているかが見えやすく、並列で回しているときに便利です。 |
| chat.tools.terminal.autoApprove | 読み取り系を自動承認 | ターミナル実行の承認待ちを減らせます。まずは読み取り系だけでも許可しておくと、安全性を保ちつつ調査を止めずに進めやすいです。 |
| chat.tools.urls.autoApprove | 安全な URL を都度追加 | URL ツールの承認フローを調整できます。必要なドメインだけを都度追加する運用にすると、安全性と手数のバランスを取りやすいです。 |
| github.copilot.chat.localeOverride | ja |
チャットの出力言語を固定します。日本語でやり取りしたい場合は、回答の揺れを減らしやすいです。 |
| github.copilot.chat.copilotMemory.enabled | true |
Copilot Memory を有効化します。過去の前提や好みを拾っているように見える場面があり、今後さらに効いてきそうだと感じています。 |
| github.copilot.chat.backgroundCompaction | true |
会話履歴をバックグラウンドで圧縮します。長いセッションで文脈切れを起こしにくくしたいのでオンにしています。手動で管理したい場合はオフでも良さそうです。 |
| github.copilot.chat.codesearch.enabled | true |
#codebase 周りの検索を強化します。関連コードを拾う精度が上がるので、調査や参照先の発見がしやすくなります。 |
| github.copilot.chat.agent.autoFix | true |
エージェントが生成したコードに問題（型や lint エラーなど）があった場合、自動で潰してくれる場面があるので有効化しています。 |
必須ではないが便利なもの
| 設定 | 値 | 備考 |
|---|---|---|
| workbench.browser.enableChatTools | true |
統合ブラウザをツールとして使えるようになります。軽い動作確認やスクリーンショット取得をエージェントに寄せたいときに便利そうです。 |
| github.copilot.enable |
*, plaintext, markdown, scminput, prompt
|
補完を有効にする対象を広げます。コード以外に Markdown や PR 入力欄でも補完を効かせたいので設定しています。 |
| github.copilot.nextEditSuggestions.extendedRange | true |
NES の提案範囲を広げます。変更の波及先まで拾いやすくなり、関連編集を見つけやすくなります。 |
| chat.implicitContext.enabled | panel: never |
開いているファイルの自動コンテキスト投入を抑えます。意図しない文脈が混ざるのを避けたいので、必要なものだけ明示的に渡す運用にしています。 |
| inlineChat.enableV2 | true |
Inline Chat の新バージョンを試せます。まだ主力ではありませんが、改善を追いたいので有効化しています。 |
| inlineChat.affordance | gutter |
Inline Chat の入口を行番号付近に出します。その場でさっと開きやすく、局所修正との相性が良いです。 |
| github.copilot.chat.switchAgent.enabled | true |
Agent から Plan への切り替えを許可します。計画へ自然につなげたいときに便利です。 |
まだ評価中だが試しているもの
| 設定 | 値 | 備考 |
|---|---|---|
| chat.experimental.useSkillAdherencePrompt | true |
Skill 遵守を強める実験的な設定です。少し効きすぎる印象もありますが、いまは挙動確認を兼ねて有効化しています。 |
| github.copilot.chat.alternateGptPrompt.enabled | true |
GPT 系モデル向けの代替プロンプトを使います。差が大きいかはまだ判断中ですが、ひとまずオンで様子を見ています。 |
| github.copilot.chat.anthropic.contextEditing.mode | clear-both |
Anthropic 系モデルでのコンテキスト編集方法を調整します。思考ブロックとツール使用の両方をクリアして、文脈を軽く保ちたい意図です。 |
| github.copilot.chat.anthropic.promptOptimization | split |
Anthropic 系のプロンプト最適化を切り替えます。Sonnet と Opus で最適化を分けられる点を期待して試しています。 |
| github.copilot.chat.anthropic.tools.websearch.maxUses | 10 |
Anthropic 系の Web Search 回数上限です。現状は多めに確保しておき、実運用で過不足を見ながら調整したい設定です。 |
| github.copilot.chat.responsesApiContextManagement.enabled | true |
Responses API ベースのコンテキスト管理を有効化します。文脈の持ち方がどう変わるかを見たくて、いまは試験的にオンにしています。 |
| github.copilot.chat.getSearchViewResultsSkill.enabled | true |
検索ビュー結果取得スキルを有効化する設定です。検索で見つけた情報を扱いやすくなります。 |
スキル（Skills）
以前はカスタムプロンプトを色々作っていましたが、最近はスキル（Skills）に移行しました。
自動で読み込んでくれたり、トークン使用量削減にも効果的でこれからもっと活用していきたいです！
いま使っているスキル例
ローカルの skills ディレクトリ（例: ~/.agents/skills/）にいくつか置いています。
今よく使っているのはこんな感じです。
以下のスキルは、個人運用で便利かもと思って作ってみたものです！
| スキル | 主な用途 | 個人的な使いどころ |
|---|---|---|
git-workflow |
ブランチ、コミット、PR 作成 | 実装後に Git 周りをまとめて整える |
fix-review-comment |
PR のレビュー指摘対応 | comment 取得、修正、push、reply まで流す |
agents-review |
観点別の並列レビュー | security や bugs を分担して拾う |
git-workflow
ブランチ作成 → コミット → PR 作成を一気に流す skill です。
git-workflow
---
name: git-workflow
description: "Git/GitHub workflow: create branch → semantic commits → create/update PR. All output in Japanese. Use when: create branch, commit, PR作成, ブランチ作成, PRを出す, コミット, git-workflow, git workflow, create-branch-commit-pr"
argument-hint: "Optional: task description or specific instructions"
---
# Create Branch, Commit & PR
**All responses and output must be written in Japanese (日本語).**
## When to Use
- Implement a feature or fix that needs to go through the full Git workflow
- Commit staged or unstaged changes with semantic organization
- Create a new PR or update an existing one
## Step 1: Review Changes
Check for both staged and unstaged changes. If a task description is given, follow those instructions first.
```sh
git status
git add -N . # Add untracked files for diff visibility
git diff HEAD # Inspect full diff
```
Stop immediately if there are no changes and no task instructions.
## Step 2: Create Branch
Summarize the changes in 1–2 lines. Generate a descriptive **kebab-case branch name** (max 20 chars, lowercase letters and `-` only). Append a short numeric suffix if the name conflicts with an existing branch.
```sh
git checkout -b "<branch-name>"
```
## Step 3: Semantic Commits
Split changes by concern (e.g., new feature / API fix / config change / refactor / format / test update). Stage each group separately and commit with a **Japanese subject line (≤ 50 chars)**. Add a body if needed.
> Never mix formatting-only changes with logic changes.
```sh
git add <files>
git commit -m "<commit message>" -m "<optional body>"
```
## Step 4: Push & Create PR
Push to remote and create a PR.
- If `.github/pull_request_template.md` exists, **always use that template as the PR body base**.
- Follow the template's section structure instead of inventing a new one.
- If the repository instructions require preserving HTML comments in the template, keep them and write the actual content outside the comments.
- If the user provides a reference PR URL or PR number, inspect that PR and mirror its writing context when appropriate.
- For merge/sync PRs such as taking `develop` into a feature branch, keep the body concise and state the merge context clearly.
- When there are extra commits to restore buildability, mention them briefly in the template's 「変更内容」 or equivalent section.
- When the template asks for environment details, fill each requested item explicitly instead of collapsing them into a single short line.
- Only fall back to a simple custom body such as 「概要」「変更理由」「参考」 when no PR template exists.
If a PR already exists (PR number given or detected via `gh pr list`), use `gh pr edit` instead of `gh pr create`.
Always append `| cat` to suppress pager output.
**Write the PR body to a hidden file in the project directory** (for example, `.pr_body.md`) and use `--body-file` to avoid escaping issues with special characters, backticks, and newlines. After `gh pr create` / `gh pr edit` completes, delete that file.
Run each command as a **separate terminal call** in this order:
```sh
# 1. Push
git push -u origin "<branch-name>" | cat
```
```sh
# 2. If PR template exists, copy it first and fill it in
cp .github/pull_request_template.md ./.pr_body.md
```
```sh
# 2. If no PR template exists, write a fallback body to a file in the project directory
cat > ./.pr_body.md << 'PREOF'
## 概要
- <1～3行で要約>
## 変更理由
- <背景と目的>
## 参考（なければ省略）
- <Issue/ドキュメントURL>
PREOF
```
```sh
# 3a. If PR already exists
gh pr edit <PR-number> --title "<PR-title>" --body-file ./.pr_body.md | cat
rm ./.pr_body.md
```
```sh
# 3b. If PR does not exist
gh pr create --assignee "@me" --title "<PR-title>" --body-file ./.pr_body.md | cat
rm ./.pr_body.md
```
fix-review-comment
PR のレビューコメント対応用です。
これも個人の検証の面が強いですが、レビュー指摘の内容把握から修正、push、GitHub 上での返信まで一気通貫で流すイメージで作っています。
fix-review-comment
---
name: fix-review-comment
description: "Fetch PR review comments, apply code fixes, commit and push, then reply to each reviewer. All output in Japanese. Use when: fix review comments, PR review response, レビューコメント対応, レビュー修正, fix-review-comment, review reply"
argument-hint: "PR number to address (required)"
---
# Fix PR Review Comments
**All responses and output must be written in Japanese (日本語).**
## When to Use
- Addressing code review comments on an open PR
- Committing fixed code and pushing to the PR branch
- Replying to reviewers on GitHub after addressing feedback
## Step 1: Switch to PR Branch
Confirm the current branch matches the target PR. If not, check out the correct branch.
```sh
gh pr view <PR番号> --json headRefName --jq '.headRefName' | cat
git checkout <ブランチ名>
```
## Step 2: Fetch Review Comments
Run [fetch-review-comments.sh](./scripts/fetch-review-comments.sh) to retrieve all review comments and identify what needs to be fixed.
```sh
bash .agents/skills/fix-review-comment/scripts/fetch-review-comments.sh <PR番号>
```
## Step 3: Apply Fixes
Modify the code according to the review feedback. Verify each change and apply any follow-up corrections as needed.
## Step 4: Semantic Commits
Split changes by concern and commit each group with a **Japanese subject line (≤ 50 chars)**. Add a body if needed.
> Never mix formatting-only changes with logic changes.
```sh
git add <files>
git commit -m "<日本語コミットメッセージ>" -m "<必要なら本文補足>"
```
## Step 5: Push & Reply to Reviewers
Push changes, then reply to each review comment — include the commit ID in your reply. Use `<br>` for line breaks in comment bodies.
```sh
git push -u origin "<ブランチ名>" | cat
# Re-fetch comment IDs if needed
bash .agents/skills/fix-review-comment/scripts/fetch-review-comments.sh <PR番号>
# Reply to an inline review comment (attached to a code line)
gh api --method POST repos/:owner/:repo/pulls/<PR番号>/comments/<comment_id>/replies \
-f body="<返信内容（commitID含む）>" | cat
# Reply to a general PR comment (not attached to a code line)
gh api --method POST repos/:owner/:repo/issues/<PR番号>/comments/<comment_id>/replies \
-f body="<返信内容（commitID含む）>" | cat
```
fetch-review-comments.sh
#!/bin/bash
# fetch-review-comments.sh
# PR のレビューコメントを取得して標準出力に出力する
# 使い方: ./fetch-review-comments.sh <PR番号>
set -euo pipefail
PR_NUMBER="${1:?使い方: $0 <PR番号>}"
gh api "repos/:owner/:repo/pulls/${PR_NUMBER}/comments" \
--jq '.[] | {id: .id, user: .user.login, file: .path, line: .line, body: .body}' | cat
agents-review
レビュー観点を並列に走らせる skill です。
agents-review
---
name: agents-review
description: "Parallel code review across 6 perspectives: security, code quality, bugs, race conditions, test flakiness, maintainability. Targets staged changes first, then unstaged, then commits ahead of base branch. All output in Japanese. Use when: agents-review, PR review, コードレビュー, parallel review, 並列レビュー, 未コミット変更レビュー"
argument-hint: "Optional: additional instructions or focus areas"
---
# Agents Review (Parallel Code Review)
**All review comments and output must be written in Japanese (日本語).**
## Step 1: Collect diff
Check in priority order and use the first non-empty result as the review target:
1. **Staged changes** (highest priority)
```bash
git diff --cached --stat && git diff --cached
```
2. **Unstaged working tree changes** (if staged is empty)
```bash
git diff --stat && git diff
```
3. **Commits ahead of base branch** (if both above are empty)
```bash
git diff origin/main...HEAD --stat && git diff origin/main...HEAD
```
If all are empty, report no changes and stop. For large diffs, read changed files individually.
## Step 2: Parallel review (6 agents simultaneously)
Launch all 6 subagents **at the same time** — do NOT run sequentially. Pass the diff context to each agent and instruct them to report in Japanese.
### Agent 1: Security
- OWASP Top 10 (SQLi, XSS, CSRF, etc.)
- Missing auth/authz checks
- Hardcoded secrets or secrets in logs
- Missing input validation
- Insecure random/crypto usage
### Agent 2: Code Quality
- Naming conventions per AGENTS.md/CLAUDE.md
- Correct architectural boundaries and module responsibilities
- Code duplication, mixed responsibilities
- Ambiguous success/failure signaling
- Consistent error handling and wrapping
### Agent 3: Bugs
- Null / empty / default-value mishandling
- Off-by-one / boundary errors
- Type conversion / integer overflow
- Missing not-found handling after data fetch operations
- Logic errors in conditionals
### Agent 4: Race Conditions
- Concurrent access to shared state
- Incorrect synchronization or task handoff
- Misuse of synchronization primitives
- Unsafe concurrent access to shared collections
- Concurrency issues in tests
### Agent 5: Test Flakiness
- Time-dependent tests (hardcoded current time, etc.)
- Execution-order or global-state dependencies
- Non-deterministic slice comparison (missing sort)
- Overuse of broad wildcard matching in test doubles
- Sleep/timeout-based timing dependencies
### Agent 6: Maintainability
- Overly complex functions / bloated files
- Missing tests for critical logic and key integration paths
- Hardcoded magic numbers / constants
- Missing comments on interface methods
- Large blast radius of changes / tight coupling
## Step 3: Summarize results
After all agents complete, report in the following format (in Japanese):
```
## レビュー結果サマリー
### 🔒 セキュリティ
<問題点・リスク、または「問題なし」>
### ✅ コード品質
<問題点・リスク、または「問題なし」>
### 🐛 バグ
<問題点・リスク、または「問題なし」>
### ⚡ レースコンディション
<問題点・リスク、または「問題なし」>
### 🧪 テストの不安定さ
<問題点・リスク、または「問題なし」>
### 🔧 保守性
<問題点・リスク、または「問題なし」>
```
For each issue: include file path, relevant code, explanation, and suggested fix.
今後試したいこと
Hooks はもっと使い込みたい
今のところ自分は、hooks は lint / formatter 系でしかあまり活かせていないので、ここはまだまだ伸びしろが大きいと思っています。
特にやってみたいのは次のあたりです。
- sessionStart
- 現在の branch、直近 commit などの補足情報
- userPromptSubmitted
- 毎回の入力に対して、必要なら追加情報を注入する
- preToolUse
- 危険コマンドの拒否
- errorOccurred
- 失敗ログを収集し、何で失敗しやすいかを後から分析できるようにする
スキル（Skills）の設計をもっと良くしたい
今の自分のスキルは、正直まだ昔のカスタムプロンプトを移植しただけに近い使い方も多いです。
ここは今後もっと改善したいです。
内容としては、重い情報を references/ に分けて、コンテキスト使用量をもっと最適化したいなと思っています。
トークン消費も減って、読み込みも速くなって、必要なときだけ深い情報を取りに行ける形にしたいです。
Copilot CLI はこれからもっと触っていきたい
Copilot CLI はまだ使い始めたばかりなので、これからもっと活用していきたいです！
VS Code より速く感じる場面も多いですし、並列実行や放置タスクとの相性も良いです。
複数リポジトリをまとめて更新するワークフローも作りたい
GitHub Actions の更新みたいに、複数リポジトリでほぼ同じ変更を入れたい場面って結構ありますよね。
そういうときに、リポジトリごとに手で回すのではなく、Copilot CLI をスクリプトから呼び出して、必要なら Copilot cloud agent に渡すところまで一気に流せるようにしたいです！
イメージとしては次のような流れです。
- 対象リポジトリの一覧を持つ
- 共通の更新方針やプロンプトを用意する
- スクリプトから各リポジトリに対して
copilot -i "/delegate <prompt>"を順番または並列で回す -
Copilot cloud agentに引き継ぎしてPRまで持っていく - 最後に結果を一覧化して確認する
もしくは、Web の Copilot チャットで Copilot cloud agent を呼び出すツールが使えたので、そちらから順番に回してもらうのもいけるかもしれません。
作業ログ作成みたいなスキルも作ってみたい
最近は MCP や CLI などで取れる情報が増えてきたので、作業ログを作るスキルを用意して、振り返りや改善に使いたいと思っています。
/chronicle っぽい発想に近いのですが、VS Code 側でも同じように、後から見返せるログをうまく活かしたいです！
VS Code の Copilot ログは、VS Code のログ保存先（例: ~/Library/Application Support/Code/User/workspaceStorage）にも色々残るので、そのあたりも読ませるイメージでいます
とはいえ、ローカル痕跡の扱いは環境に応じて慎重に考えたいです。
Copilot SDK も試してみたい
2026/4 時点で Copilot SDK が public preview になったので、ここも気になっています！
Copilot CLI や Copilot cloud agent を支えている実装を、自分のアプリや workflow に埋め込めるもの、という理解が近そうです。
今のところまだ全然触れていないのですが、試したいのは次のあたりです。
- 既存の運用スクリプトや業務 workflow に組み込めるか
- 複数リポジトリ更新のオーケストレーションに使えるか
- プレミアムリクエストの消費感や permission 制御がどの程度しっくり来るか
うまくハマるなら、Copilot を「使う」だけでなく、「組み込む」側にも広がりが出そうです！
気になっている周辺ツール
Copilot 自体の使い方だけでなく、周辺ツールも色々出てきているので、気になっているものをいくつかピックアップしてみます。
superpowers
最近は、開発で superpowers も試しています。
自分の印象では、これは単なるスキル集というより、強めの開発ワークフロー集です。
特に良いなと思っているのは次のあたりです。
- 仕様が曖昧なところを詰めるのがうまい
- いきなりコードを書くより前に、何を作るのかを会話で詰めてくれます
- TDD を重視している
- README でも
RED-GREEN-REFACTORを強く押しています
- README でも
- 2段階レビューの流れがある
- spec に沿っているか、コード品質的に問題ないか、という 2 段階でレビューしてくれます
- 生成される仕様書が比較的読みやすい
- 会話から仕様を起こしていく流れが、思ったより人間が読める形でまとまります
Plan モードよりも、仕様の不明点を対話で詰める力が強い印象があります。
spec-kit ほどはガチガチではないので、小〜中規模向けなのかなと思っています。
最近の更新で Copilot CLI のサポートも入ってますね！
codex-plugin-cc
Codex も使っているので、最近はこれも面白いなと思っています。
これは Claude Code から Codex を呼べる plugin で、
/codex:review/codex:adversarial-review/codex:rescue
みたいな導線が分かりやすいです。
そのうち、これの Copilot バージョンも作ったら面白そうだなと思っています！
Copilot 側でも、レビューやタスクの引き継ぎみたいな入口を呼び分けやすくすると便利そうです。
おわりに
結構長くなってしまいましたが、読んでいただきありがとうございます！
まだまだ活かし切れていない機能も多いので、引き続き色々試していきたいです！
おすすめの使い方があれば、ぜひ教えてください 🙏
参考
Discussion