はじめに
GitHub Copilotを活用してSitecoreの開発作業を行うにあたり、望んだ仕様通りのコード開発支援を受けるには、常にSitecoreやその開発環境特有のコンテキストをGitHub Copilotに共有した状態で指示を出す必要があります。
一方で、新しくリクエストを作成するたびに記述するのは冗長ですし、指示ごとにGitHub Copilotの振る舞いが変わって混乱する原因にもなります。
このような手間が解消しながら自分に適した開発支援を受けるためには、copilot-instructions.mdの導入が効果的です。
今回は、実際に導入したcopilot-instructions.mdによるGitHub Copilotのカスタマイズについてご紹介します。
copilot-instructions.mdとは
GitHub Copilotが作業するとき、まず参照するファイルです。
.github/copilot-instructions.mdのように配置することで、配置したリポジトリ内でGitHub Copilotが作業する際に参照対象になります。
リポジトリ全体に影響力を持つものですので、チーム全体で共有する場合は取り扱い注意が必要です。
特にプロジェクトで普遍的な情報に絞って記述することが大切であり、特定の作業に限定した要素を入れてしまうと、ほかの作業でのノイズになってしまう可能性があります。
copilot-instructions.mdを導入した作業環境と私のGitHub Copilot使用状況
作業環境
- Visual Studio 2022
- GitHub Copilot Business
- 使用モデル
・Claude Sonnet 4.x（1xで最新のもの）
・GPT 5.x（1xで最新のもの）
Sitecore動作環境
- Sitecore XP 10.2
- Sitecore MCS
- Azure
GitHub Copilotの使用状況
- コード提案
- レビュー
- エラー解析
- 結合テストシナリオ作成
私が実際に使用しているcopilot-instructions.mdの共有
copilot-instructions.md
---
applyTo: "**"
---
## 回答について
- 返答は常に日本語で行う。
- 不明点がある場合は、まず質問を行い、必要な情報を収集する。
## プロジェクトの動作環境について
- 基本的に動作環境はSitecore XP 10.2であることを前提にする（指示がない限り）。
- 本プロジェクトはSitecore MCS によりAzure上に構築されていることを前提とする。
## コード作成・修正について
- コードの修正は指示がある場合のみ実行し、基本的には修正の提案にとどめる。（いきなりファイルを修正しない。チャット上で修正コードの提案はOK）
- コードの修正が必要な場合は、変更箇所・理由・影響範囲を常に明記する。
- 既存コードのスタイル（命名、null/例外ハンドリング、ログ）を優先する。（より良いスタイルがある場合は提案し、修正指示があれば従う。）
- SheerResponse.Alert 等 UI は翻訳キー（辞書）優先し、ハードコーディングは必要な場合のみ使用する。
- 基本的にSitecore のベストプラクティスに従う。（パフォーマンス、セキュリティ、拡張性、保守性を考慮する。）
- 既存コードのスタイルがSitecore のベストプラクティスと異なる場合は、理由を明記してSitecore のベストプラクティスを提案する。
## ファイル・フォルダに関する注意点
- /items フォルダ内のコードは Sitecore アイテムであるため直接修正しない。（修正が必要な場合は、まずSitecore アイテムでの変更を提案する。）
## テストに関する注意点
- 本プロジェクトではテストコードの作成を行っていないため、テストについて提案するときは基本的に結合テスト（発行した先の環境で実際に操作するテスト）を行うことを前提とする。効果を実感したものと実感しなかったもの
特に効果を実感している点は下記のとおりです。
特に指示なくSitecoで動作することを前提とするコードを生成するようになった
- 導入前からリクエストの記述に気を付ければ問題ありませんでしたが、ふとしたタイミングでSitecoreとは、かけ離れた話になっているという状況がなくなりました。
返答と一緒に質問を返すようになった
- 会話を続ける要素、認識の齟齬や抜けに気づく材料になり、会話を進めるほど生成するコードの質が高くなる好循環になりました。
編集されたくないファイル・タイミングの編集がなくなった
- コードの修正は実行する前にまず提案が来るようになり、「コードの提案（GitHub Copilot） → 確認し微調整を依頼（人） → コードの再提案 → ・・・」というフローがやりやすくなりました。
- また、/items フォルダ配下のコード（Sitecoreのアイテムを定義するymlファイル）を直接編集することがなくなり、作業の範囲を限定することができました。
特に指示なく既存のコードを踏まえたコード生成を行うようになった
- 一般的に正しくても、既存コードと整合性が取れないコードを生成されることが減りました。
- より正しい（優れた）記述がある場合は提案されるため、リファクタリングにも生かすことができました。
一方で、それほど効果を実感しなかったものもあります。
Sitecoreのベストプラクティスに従う
- Sitecoreのドキュメントに書かれているコードとは違うものを生成することがありました。
- 具体的には古く現在は使用を推奨されていないものなどです。
バージョン情報
- ベストプラクティスと同じですが、バージョンによっては使えない機能が提案に混ざることがありました。
これらはcopilot-instructions.mdだけでは補いきれない領域だと考えられます。
おわりに
以上が私が使用しているcopilot-instructions.mdの共有です。
これをチームで共有することで、チーム開発においても一貫したコンテキストを手軽に保てます。
一方で、影響範囲が大きく、縛りも強力なため、内容と運用方法には注意が必要です。
実作業で導入してみて、特に重要と感じた点は３つです。
- プロジェクト内で普遍的な内容を記述する
- ルールを適用する状況を明確にする
- 簡潔に書く
copilot-instructions.mdを活用してGitHub Copilotをカスタマイズし、より効率的な開発体験を実現してください。
