GitHub Copilotは、一般的な指示だけに頼る場合よりも、扱うコードベース固有のルールを把握している場合に、より適切に機能する。GitHubによると、こうしたコンテキストの大部分はリポジトリ内に保存できるため、Copilotはコンポーネントの整理方法、使用するコマンド、命名規則、テスト基準を自動的に認識できる。
全般的な指示とパス固有の指示
設定は、リポジトリ全体に適用されるルールを記述する.github/copilot-instructions.mdファイルを作成することから始まる。ここには、推奨するアーキテクチャ、命名規則、テストおよび検証の要件などを記載する。
GitHubでは、.github/instructions内に特定のパスに関連付けられた指示ファイルを作成することもできる。これらのファイルではapplyToフィールドを使用して、指示が適用されるファイルや状況を指定する。これにより、すべてのファイル種別に同じスタイルを強制することなく、全般的なガイドラインと、より専門的なルールを組み合わせられる。
繰り返し行う手順をスキルに変換する
全般的な指示がすべての手順に適しているとは限らない。品質チェックの実行、リリースの準備、ワークフローの失敗の診断といった作業には、繰り返し実行できる手順が必要になる。この目的のため、GitHubはエージェントスキルの利用を提案している。エージェントスキルは、指示、スクリプト、追加リソースを含められるフォルダーだ。
プロジェクト固有のスキルは.github/skillsに配置し、スキルごとにフォルダーを割り当てられる。たとえばquality-checksというフォルダーには、スキルを使用するタイミング、テストおよびコードスタイルの検証コマンド、各コマンドが確認する内容、一般的な失敗への対処方法を定義したSKILL.mdファイルを含められる。
カスタムエージェントが必要になるのはいつか
一部のタスクは単一の手順を超え、複数のファイルやツールにまたがる。GitHubは、コンポーネント、テンプレート、スタイル、インタラクションの検査が必要になる場合があるアクセシビリティレビューを例に挙げている。このような場合は、.github/agents内にカスタムエージェントを作成し、その目的、指示、ツール、プロジェクトに関連するコンテキストを指定できる。
この選択肢は、特定の種類の作業を繰り返し行い、専門的な役割や特定の視点を活用できる場合に適している。特に、複数のファイルやコンテキストソースを扱う必要がある場合に有効だ。
MCPサーバーによるCopilotの範囲拡大
指示、スキル、エージェントは、プロジェクト内での作業方法をCopilotが理解するのに役立つ。一方、Model Context Protocol (MCP)サーバーは、リポジトリ外のツール、データソース、サービスにCopilotを接続する。ドキュメントサーバーはフレームワークのガイドラインを提供でき、Playwrightのようなサーバーを使えば、ブラウザー経由でアプリケーションを開いて操作できる。
Playwrightを設定した後は、MCPサーバーを使用して機能の手動テストを依頼できる。これにより、検証は自動テストの成功だけに限定されない。Copilotは、変更後のインターフェースの挙動を確認し、ブラウザー上で操作することもできる。
実際に何が変わるのか
主な利点は、繰り返し説明していた知識を、リポジトリ内でレビュー可能なファイルへ移行できることにある。指示は基準を定め、スキルは手順を文書化し、エージェントは複雑なタスクに集中する。一方、MCPサーバーは外部ツールを使用する能力を追加する。GitHubは段階的に始めることを推奨している。まず、何度も説明しているルールを1つ選び、それを.github/copilot-instructions.mdに記述して、Copilotがどのように適用するかを観察する。
また、この記事では、共有可能な指示、スキル、エージェントを収録したAwesome Copilotリポジトリにも言及している。ただし、これらのリソースを採用する前に、プロジェクトのツールや基準に合わせて調整することが依然として必要だ。