コードの変更を頼むたびに、「このプロジェクトではこの書き方を使う」「確認にはこの手順を使う」と説明していないだろうか。GitHubが2026年10月12日に公開したCopilotの入門記事は、そうしたプロジェクト固有の前提を伝える方法として、カスタム指示、エージェントスキル、カスタムエージェント、MCPサーバーの4つを紹介している。
知りたいのは、名前の違いだけではない。何を渡すと、Copilotのどの作業に役立つのか。記事にある例から、使い分けを考えよう。
Copilotに渡すのは、変更依頼とプロジェクトの前提
GitHubの記事は、アプリに独自のページサイズを追加する依頼を例に挙げる。ページサイズを増やすコードが書けても、既存のコンポーネント構成やプロジェクトの規約から外れていれば、依頼に十分応えたとは言いにくい。ここで必要なのは「ページサイズを追加して」という今回の依頼と、「このリポジトリではどう実装するか」という継続的な前提の両方だ。
GitHubは、規約、使用するスクリプト、ファイルの種類ごとの決まりなどをリポジトリ内に置けば、Copilotが作業時にその文脈を拾えると説明する。依頼のたびに同じ説明を繰り返す方法との違いは、共有したい前提をプロジェクト側に残せる点にある。ただし、規約を書けば出力が必ず正しくなると示した比較実験ではない。
4つの仕組みは、渡すものが違う
| 仕組み | Copilotに渡すもの | 公式記事にある用途 |
|---|---|---|
| カスタム指示 | 継続して守ってほしい規約 | リポジトリ全体や特定のファイルに関する書き方 |
| エージェントスキル | 繰り返す作業の手順 | 品質確認で使うテストやlintの進め方 |
| カスタムエージェント | 広い作業を担う専用の役割や視点 | 複数ファイルにまたがるアクセシビリティ点検 |
| MCPサーバー | リポジトリ外のツールや情報への接続 | Playwrightのようなツールを使った画面の確認 |
カスタム指示は、個々の依頼をまたいで使う基準に向く。GitHubはリポジトリ全体の指示を置くファイルとして .github/copilot-instructions.md を示し、さらに対象ファイルに応じた具体的な案内を併用できると説明する。たとえば、全体に共通する構成上の決まりと、ある種類のファイルだけに当てはまる決まりを分けて伝える考え方だ。
エージェントスキルが扱うのは、決まりそのものより作業の進め方である。公式記事の例では、品質確認のスキルを読み込み、プロジェクトで定めたテストやlintの手順に沿って作業する。何を常に守るかを示すカスタム指示と、特定の作業をどう進めるかを示すスキルでは、用意する内容が異なる。
カスタムエージェントは、より広い仕事に専用の視点を与える仕組みとして紹介される。アクセシビリティ点検なら、コンポーネント、テンプレート、スタイル、操作を複数ファイルにわたって見る必要がある、というのが記事の例だ。一方、MCPサーバーは役割を定める仕組みではなく、外部のツールやデータ源に接続する仕組みである。GitHubは、Playwrightのような接続を使えば、自動チェックに加えて更新後の画面の振る舞いを確かめる道があると説明している。
一つの依頼では、どう組み合わさるか
画面のアクセシビリティ点検を頼む場面を考えてみよう。普段から守る実装規約はカスタム指示に置く。点検時に繰り返す確認手順はスキルにまとめる。複数ファイルを見渡す点検の役割はカスタムエージェントで表す。実際の画面を操作して確認する必要があれば、MCP経由の外部ツールが関わる。
これはGitHubが説明する4つの役割を組み合わせた本稿の例であり、提示された資料に一連の点検を実行した記録があるという意味ではない。それでも、仕組みを選ぶ問いは具体的になる。「守る規約か」「繰り返す手順か」「広い作業の役割か」「外部への接続か」と考えれば、同じ指示文にすべてを詰め込まずに済む。
この違いが役立つのは、Copilotへ渡したい情報の置き場所を選ぶときだ。たとえば画面を確認できない問題を、書き方の規約だけ追加して解決しようとしても、外部ツールへの接続という論点は残る。逆に、単に既存の命名規則を守ってほしいだけなら、広い点検役割を用意する前にカスタム指示を検討できる。これは機能の優劣ではなく、入力する情報の種類から選ぶという本稿の整理である。
最初は、繰り返し説明している規約を一つ
GitHubの記事は、まず何度も説明している規約を一つ選び、.github/copilot-instructions.md に加えて次の依頼で適用されるかを見ることを勧める。たとえば、既存コンポーネントの使い方について毎回伝えている決まりがあれば、そこから試せる。結果を見て、規約が曖昧だったのか、今回の作業に関係しなかったのかを確かめる、というのが本稿の提案だ。
提示された資料は各節の一部を抜き出したもので、設定項目の完全な一覧、読み込み条件の細部、他社製品との性能差は確認できない。ここから言えるのは、GitHubが4つの仕組みをそれぞれ異なる役割として説明し、組み合わせて使えると案内していることまでである。まずは身近な規約を一つ形にし、次の作業結果で確かめてみよう。
出典：参照した一次発表（確認日：2026-10-13）。