業務システムの保守や機能改修を続けていると、画面コンポーネントの共通構造や命名ルール、テスト実行の手順など、チーム内で守るべき暗黙のルールが数多く蓄積されます。AIコーディング支援を導入しても、そうした文脈が共有されていなければ、意図と異なるコードが提案されて手戻りが発生しがちです。
2026年10月12日、GitHub公式ブログにて、コードベースの文脈をGitHub Copilotに伝える手段を解説した記事「GitHub Copilot app for Beginners: How to teach Copilot about your codebase」が公開されました。この記事では、毎回説明している決まりごとと、特定の作業でのみ必要な手順を分けて管理し、Copilotの支援精度を高める4つのアプローチが紹介されています。
コードベースの文脈を伝える4つの手段
公式解説では、プロジェクト固有のルールや手順を用途に応じて次の4つに分類して設定する考え方が示されています。
1つ目は、カスタム指示（Custom instructions）です。リポジトリ全体に適用する設計方針や命名規則、テストへの期待値は、リポジトリ直下の.github/copilot-instructions.mdに記述します。さらに、特定ディレクトリ配下のファイルにのみ適用したい規則がある場合は、.github/instructions配下にファイル名が.instructions.mdで終わるファイルを配置し、フロントマターのapplyToで対象パスを指定できます。これにより、全体の基本方針を保ちながら、画面層やAPI層などファイル種別ごとの規約の併用が可能です。
2つ目は、エージェントスキル（Agent skills）です。品質チェック、リリース準備、ワークフローのトラブルシューティングなど、一連の決まった手順をフォルダー単位でパッケージ化します。プロジェクト用スキルは.github/skillsのサブフォルダーに配置し、中核となるSKILL.mdにスキルを利用するタイミングや実行スクリプト、エラー時の対応方法を記載します。これにより、Copilotが必要な場面を判断して手順を読み込み、決まったスクリプトを実行できるようになります。
3つ目は、カスタムエージェント（Custom agents）です。複数ファイルにまたがるアクセシビリティの点検など、専門的な視点が求められる反復作業を担う役割を定義します。リポジトリの.github/agentsにプロファイルを作成し、エージェントの目的や指示、利用ツールを設定します。
4つ目は、MCP（Model Context Protocol）サーバーによる外部ツール接続です。リポジトリ外の情報や外部サービスとの連携を担い、たとえばPlaywrightのMCPサーバーを設定することで、Copilotがブラウザーで対象画面を開き、変更後の動作を手動テストのように操作して確かめる例が紹介されています。
スキルの共有範囲とVS Codeでの指示適用確認
これらの設定を導入する際は、チーム内で共有する手順と個人で使う補助ツールを区別すること、そして指示がモデルに渡っているかを客観的に確かめることが大切です。
エージェントスキルに関するGitHubの公式ドキュメントによると、スキルにはリポジトリ内で共有するプロジェクト用スキル（.github/skillsなど）と、作業者のホームディレクトリ（~/.copilot/skillsなど）に配置して複数のプロジェクト間で共有する個人用スキルの2種類が用意されています。対象システム固有のビルドやテスト手順はリポジトリで管理し、個人の定型的な補助作業はホームディレクトリで管理するといった切り分けが検討できます。
また、設定した指示が実際に機能しているかの確認も欠かせません。VS Code向けカスタム指示の解説によると、VS Code環境では指示ファイルの存在と機能の有効化（既定で有効）が前提となります。Copilot Chatの応答時、モデルに送信されたプロンプトにカスタム指示が含まれていれば、応答の参照一覧（References）に.github/copilot-instructions.mdが表示されます。
ただし、Referencesへの表示は「指示がプロンプトへ組み込まれたこと」の確認であり、指示内容が完全に遵守されたことや、生成コードの正しさを保証するものではありません。指示が渡ったかどうかの確認と、業務要件に合致しているかの検証は、明確に分けて評価する必要があります。
既存業務システムへの適用例と小さく試す進め方
国内企業の既存業務システム、たとえば受注管理システムの一覧画面を改修する場面を想定してみます。
まずは、レビューのたびに口頭やプルリクエストで繰り返し指摘している規約を一つ選び出します。たとえば、一覧テーブルにおける共通コンポーネントの呼び出し方やエラーハンドリングの書き方を.github/copilot-instructions.mdに記述し、画面表示に関連するコンポーネント群に限定したい指示があれば、applyToを指定したパス別指示として整理します。
次に、日常的に実行しているテストや静的解析のコマンドをスキルの候補としてまとめます。どのコマンドが何を検証しているのか、エラー発生時にどこを確認すべきかを整理して記述しておけば、AIにコマンドを推測させずに既存の手順を踏襲させやすくなります。さらに画面崩れや入力挙動の確認が必要な場合は、検証環境での操作確認手順を段階的に整えていきます。
設定を一気に揃えるのではなく、頻繁に説明している開発ルールを小さく切り出して記述します。VS Code環境であればChatのReferencesで指示の参照を確認したうえで、出力されたコード差分とテスト結果を業務要件と照らし合わせて検証していく進め方が現実的です。
既存システムの開発規約整理とAI活用のご相談
既存の業務システムでAIコーディング支援を活用するには、単にツールを導入するだけでなく、長年蓄積された開発規約やテスト手順の中から、AIに渡すべき文脈を整理・言語化する工程が重要になります。
株式会社デノフでは、Webサイト・業務システムの設計・開発・運用保守を一貫して手がけており、業務の整理からAIを活用する業務の選定、ツールの選定、導入後の定着支援を行っています。社内システムの保守において「どの規約や手順から指示ファイルに落とし込むべきか」「既存のテスト資産とどのように組み合わせるか」といった方針設計からサポートが可能です。
開発現場の負荷軽減や改修作業の効率化に向けて、自社の開発体制に合わせたAI活用の進め方を具体化したい場合は、デノフへの相談窓口よりお気軽にご相談ください。
