GitHub Copilot は機能がかなり増えてきており、全体像をつかみにくくなっています。
私自身も調べながら整理していたのですが、「それぞれ何が違うのか」「チームではどのファイルをどこに置くと運用しやすいのか」をまとめて説明している記事があまり見つかりませんでした。
そこでこの記事では、次の流れで整理します。
- GitHub Copilot の agent 関連機能をざっくり体系化する
- それぞれに対応する設定ファイルを整理する
- チームで共有しやすい配置例と運用フローをまとめる
この記事の対象読者
- GitHub Copilot の agent 関連機能をまとめて理解したい人
-
AGENTS.md、.instructions.md、SKILL.mdの役割を整理したい人 - チームで Copilot の設定ファイルを共有したい人
先に結論
| 観点 | 役割 | 主なファイル |
|---|---|---|
| 基本ルール | プロジェクト全体の前提や共通ルールを伝える | AGENTS.md |
| 条件付きの指示 | 言語やディレクトリごとの実装・レビュー指示を出す |
copilot-instructions.md, *.instructions.md
|
| 手順の再利用 | 特定タスクの進め方を標準化する |
SKILL.md, *.agent.md
|
「プロジェクトの共通ルールは AGENTS.md に短く書く」「細かいルールは .instructions.md に分ける」「繰り返し作業は SKILL.md や agent に切り出す」
GitHub Copilot の agent 関連機能を整理する
1. Coding agent
GitHub Copilot の coding agent は、Issue や Pull Request を起点に、クラウド側で実装や修正、レビュー補助を進めるための機能です。
Githubのエージェントの他に、Codex・Caludeも呼べるようになっています。
https://zenn.dev/kg_filled/articles/0595bdd44719da
公式ドキュメント:
できることのイメージ:
- Issue をもとに修正案を作る
- Pull Request 上の依頼をもとに変更を進める
- リポジトリのルールや指示ファイルを踏まえて作業する
- 複数のタスクをCodex、Caludeとモデルを分けて依頼する
- 同じタスクを複数の異なるエージェントで実行させる
呼び出し方の例:
- Issue や Pull Request 上で
@copilot|@codexに依頼する - GitHub / VS Code の導線から cloud 実行を選ぶ
画面イメージ:
Issue / PR 上で @copilot に依頼する例
PR reviewer などの導線から使う例
VS Code から cloud 実行を選ぶ例
2. Custom agents
custom agent は、特定用途に寄せた専用エージェントを作る仕組みです。たとえば「レビュー専用」「設計相談専用」「セキュリティ観点だけを見る」といった役割を持たせられます。
公式ドキュメント:
向いている用途:
- 毎回同じ観点でレビューしたい
- 特定タスクだけに強いエージェントを作りたい
- メインの agent に渡す前に、専門観点で補助させたい
ポイント:
- 専門性を持たせるほど、役割分担が明確になる
- 何を目的に呼ぶ agent なのかを
descriptionで明確にしておくと使いやすい - 多機能にしすぎるより、役割を絞った方が運用しやすい
3. Skills
skills は、特定タスクの進め方を再利用可能な手順としてまとめる仕組みです。Agent に人格を与えるというより、「この作業ではこう進める」というプレイブックを定義するイメージです。
公式ドキュメント:
向いている用途:
- 実装前に計画を立てる
- コードレビューの観点を固定する
- リファクタリングや移行作業の進め方を標準化する
ポイント:
-
descriptionには「何をする skill か」だけでなく「どんな時に使うか」も書く - 一度作ると、毎回同じ説明をしなくてよくなる
- チームのベストプラクティスを手順として残しやすい
4. AGENTS.md / Custom Instructions
AGENTS.md, CLAUDE.md, GEMINI.mdをサポート
-
AGENTS.md- プロジェクト共通の前提やルールを書く
-
copilot-instructions.md/*.instructions.md- 言語やディレクトリ単位で、より具体的な指示を書く
公式情報:
使い分けの感覚:
-
AGENTS.mdは「何を大事にするプロジェクトか」 -
.instructions.mdは「この種類のファイルではどう実装するか」- AGENTS.md, custom_instructionsの記載する内容の違い参考：https://tech-lab.sios.jp/archives/51144
5. Copilot CLI
Copilot は IDE だけでなく、CLI からも使えます。ターミナル中心の開発フローに乗せたい場合に便利です。
参考:
向いている用途:
- ターミナルから素早く相談したい
- 変更差分をその場で確認したい
- エディタを離れずに AI 補助を使いたい
この記事では詳細は深入りしませんが、「IDE 上の支援」と「GitHub 上の agent 機能」に加えて、「CLI という入り口もある」と押さえておくと全体像をつかみやすいです。
どのファイルに何を書くのか
AGENTS.md
AGENTS.md には、プロジェクト全体で共有したい基本ルールを書きます。
たとえば:
- 使用技術スタック
- 命名規約
- ログの扱い
- テストやレビューの基本方針
- 参照してほしいドキュメント
コンテキスト過多にならないよう、重要なルールに絞って短く書くのがおすすめです。
例:
# Project Instructions
## Stack
- Python 3.12, uv, LangGraph
- AWS CDK (TypeScript), Lambda, Bedrock
## Rules
- 型ヒントを全関数に付ける
- print() 禁止、logging を使う
- docstring は Numpydoc スタイル
Custom Instructions
copilot-instructions.md や *.instructions.md には、より具体的で条件付きの指示を書きます。
向いている内容:
- Python ファイルではこう書く
- レビュー時はこの観点を見る
- 特定ディレクトリだけ別ルールを適用する
例:
---
applyTo: "**/*.py"
excludeAgent: "coding-agent"
---
## Python コードスタイル
- public な関数とクラスには docstring を付ける
- 例外は握りつぶさず、logging を使って記録する
- 型ヒントを省略しない
applyTo を使うと、言語別・ディレクトリ別にルールを分けられるので、チーム運用ではかなり便利です。
Custom Agents
*.agent.md には、役割を持った専用 agent の定義を書きます。
たとえば:
- レビュー専用 agent
- セキュリティ確認専用 agent
- 設計相談専用 agent
例:
---
name: reviewer
description: Use when you need a focused, read-only code review subagent for bug risks, regressions, and missing tests.
tools: [read, search]
user-invocable: false
---
You are a read-only code review specialist.
## Goal
Review code changes and return high-signal findings with clear evidence.
大事なのは、「この agent は何を担当するのか」を狭く明確にすることです。
Skills
SKILL.md には、作業の進め方そのものを書きます。
たとえば:
- 実装前に計画を作る
- コードレビューを findings 中心で返す
- リファクタリング前後で確認する項目を固定する
例:
---
name: plan
description: 実装前に、要件・前提・リスク・検証方法を含む詳細な実装計画を作るためのスキル。
---
## 出力ルール
- まず理解と前提を書く
- 実装手順は番号付きで書く
- リスクと検証方法を明記する
Skills は「何を書くか」より、「どう進めるか」を残す場所と考えると使い分けしやすいです。
おすすめの配置例
最初はシンプルに始めるのがおすすめです。
.github/
|- copilot-instructions.md
|- agents/
| |- reviewer.agent.md
|- skills/
| |- plan/
| | |- SKILL.md
|- instructions/
| |- python.instructions.md
src/
|- frontend/
| |- AGENTS.md
|- backend/
| |- AGENTS.md
AGENTS.md
考え方:
- ルートの
AGENTS.mdに全体共通ルールを書く - 言語別・用途別の詳細ルールは
.github/instructions/に分ける - 再利用したい作業手順は
.github/skills/に置く - 専門 agent は
.github/agents/に置く - フロントエンド / バックエンド / インフラで文脈が違うなら、各ディレクトリにも
AGENTS.mdを置く
チームでどう運用するか
※あくまでも一例です。
1. まずは最小構成で始める
- ルートに
AGENTS.md -
.github/instructions/に言語別 instruction を1つか2つ - よく使う作業だけ
SKILL.md化
2. 個人の試行錯誤をいったんローカルで回す
新しいルールをいきなり全体ルールにせず、まずは個人で試します。
確認したいこと:
- 本当に出力品質が上がるか
- ルールが長すぎないか
- 他メンバーにも通じる表現になっているか
3. 効いたものだけを PR で共有する
チーム共通化する価値があるものだけ、PR でレビューして取り込みます。
共有対象の例:
- レビュー観点として有効だった instruction
- 実装漏れを減らせた skill
- チームの規約に合っていた
AGENTS.mdのルール
4. 定期的に棚卸しする
AI 向けルールは、増やすより減らす方が難しいです。
効かないルール、古くなったルール、重複しているルールは定期的に整理した方が運用しやすくなります。
見直し観点:
- 使われていない skill はないか
- 同じことを別ファイルに重複して書いていないか
- 長すぎて読まれない instruction になっていないか
運用で意識したいコツ
- 最初から完璧を目指さず、小さく始める
- 長文より、短く具体的なルールを優先する
- ルールには対象範囲をセットで持たせる
- agent と skill は役割を絞る
- チームで有効だったものだけを共通化する
まとめ
GitHub Copilot の agent 関連機能は、全部を同列に見るとわかりにくいですが、次のように分けると整理しやすくなります。
-
AGENTS.mdはプロジェクト共通ルール -
.instructions.mdは条件付きの詳細ルール -
SKILL.mdは作業手順の再利用 -
*.agent.mdは役割を持った専用 agent
チーム運用では、最初から大きく作りすぎず、AGENTS.md と少数の instruction から始めて、効いたものだけを skill や agent に育てていく形がやりやすいと思います。
もしこれから導入するなら、まずは次の3点から始めるのがおすすめです。
- ルートに
AGENTS.mdを置く - 言語別の
.instructions.mdを1つ作る - よく使う作業を1つだけ
SKILL.mdにする
一緒に試行錯誤しながら、チームに合ったルールや手順を育てていきましょう！