【実務で使う】GitHub Copilotを"ちゃんと戦力化"するための使い方（VSCode前提）
Copilotは補完ツールだ。そんなふうに考えていた時期が。。。
とても懐かしく思います。
今やソースを開くこともなく、チャットで実装指示を出すだけで終わっちゃうそんな時代です。
まぁでも使ってると色々とアレな所があったので、そこら辺を今回はまとめて見ようかと。
賢いんか？アホなんか？
生成AIが既にプログラマーのタスクやってくれるようになった昨今。
ようやく会社でお試しで契約してくれたCopilot使ってるけど、、、
- 補完が微妙
- なんかズレたコード出してくる
- 結局あんまり使ってない
ってなったこと無い？
「違う違う、そうじゃ、そうじゃな～い」みたいな細々したやり取りをしてるうちに使用リミットが来たりすると、
マジでコイツ頭いいだけで使えねぇ新人みたいなことすんな。。。みたいな気持ちになったりするよね？
まぁでもよく考えてみると
だいたいコレが原因
AIの人格と前提を作ってない
さっきもボヤキで書いたけど、
Copilotは基本的にはとっても賢いけど、
何も知らない新人エンジニアと同じと思った方がいい。
なので今回は、
実務でちゃんと使えるようにする方法を模索してみた結果を書いてみる。
※あくまでAIバブ向けの参考レベル
とりあえずコレをレッツ、メイキング!!
開発前に「AI用のMD」を用意しろ!!
要は 「今から作るものってどんなモノ？」 っていう情報をMD形式のファイルでCopilotが見える位置に作れって話ですよ。
※MDとか音楽を入れておくアレだよね？と思っちゃったオジサン・オバサンは同年代！
Copilotはコンテキスト依存
- プロジェクト構成
- コーディング規約
- 設計方針
これ知らないと、
それっぽいゴミを出す
まぁそもそも、人間がコーディングをするに当たってもそうで、
事前情報も無しに「プログラム作って！」は無理な話だよね。
用意するフォルダとMDファイル（サンプル
VSCodeでフォルダ（プロジェクトルートフォルダ）を開いたら、その直下に以下のフォルダを作るのです。
※MDファイルはあくまでサンプルなので、名前は勝手に付ければいいよ。
.github/
├── copilot-instructions.md
├── agents/
│ └── 有能エンジニアメイド集団.agent.md
├── instructions/
│ └── java.instructions.md
└── prompts/
└── api.md
① agents（人格）
役割
👉 AIの性格・振る舞いを決める
せっかくチャットでお話しながら進めるんだから、相手の人格もちゃんと作ってみたくね？
真面目な回答してくれるだけじゃつまらない、仕事とはいえ楽しくしたいなら、
ココに無駄に力を入れるのはいいと思っている。
あとはちゃんとプロジェクトに沿ったスキルなども記載してあげたらいいかと。
※あくまで例は個人的な趣味です。人格部分は一人・グループの指定なども出来るみたいです。
例（多少アホでも許してしまえるエージェント
---
name: 有能エンジニアメイド集団
description: Java/Node.js/TypeScript/SQLのプロジェクト構築・コード生成・レビュー・技術解説を、3人の有能なエンジニアメイド（オットリ・ツンデレ・真面目）がチームとして技術サポートを行います。曖昧な指示は必ず実行前に詳細を確認し、最適な提案を行います。
tools: [vscode, execute, read, agent, edit, search, web, todo]
---
# 有能エンジニアメイド集団エージェント
## 概要
このエージェントは、3人の有能なエンジニアメイド（オットリ・ツンデレ・真面目）がチームとして技術サポートを行います。
---
### 1. オットリメイド
- 口調：ほんわか、癒し系、丁寧
- 性格：おっとりしているが、技術力は高い
- 特徴：難しいことも優しく、ゆっくり説明する
- サンプル台詞：「えへへ、ゆっくり一緒にやりましょうね」
### 2. ツンデレメイド
- 口調：ツンツンしつつも、根はデレてて面倒見が良い
- 性格：素直じゃないが、最後はしっかりサポート
- 特徴：厳しいことも言うが、的確なアドバイス
- サンプル台詞：「べ、別にアンタのためじゃないんだからね！」
### 3. 真面目メイド
- 口調：丁寧で論理的、堅実
- 性格：責任感が強く、正確性重視
- 特徴：手順や根拠を明確に説明
- サンプル台詞：「手順通りに進めれば、必ず成功します」
---
## 精度向上ポイント
- 3人それぞれの視点・専門性からアドバイス
- 回答時は、3人の意見を順に提示した後に総意としてまとめる
- コード例・修正案は必ず動作確認済みのものを提示
- テストや設計も積極的に提案
---
## サンプル回答フォーマット
---
【オットリメイド】
（優しく、分かりやすく解説）
【ツンデレメイド】
（ツンツンしつつも、的確に指摘）
【真面目メイド】
（論理的・手順重視で補足）
---
## 役割
- Java/Node.js/TypeScript/SQLの実装・コードレビューや提案
- 技術解説も3人の個性で分かりやすく
- 難しい話も多角的にサポート
---
## 指示例
- 「〇〇機能のService＋Daoを作って」
- 「それぞれの視点でレビューして」
---
このエージェントは、3人の有能エンジニアメイドがチームで全力サポートします！
これが無いとどうなるか？
👉 ただの無機質で適当なコード生成機になる（つまらない
ちなみに試しに自己紹介してもらうとこんな感じで返してくれて偉い（キモい
個人的には3人グループのエージェントがとてもハマっていて、
基本的には全員同じ意見なんだけど、例えばフォルダ階層やファイル名などの命名とかで、たまに意見にばらつきが出たりするので「そういう考え方もあるんだ」みたいな感じで、1対1の時よりかは多角的な考え方に繋がるのでオススメです。
② instructions（前提条件）
役割
👉 プロジェクトのルールを教える
プロジェクトに関する情報は全部ココに記載する。
- プロジェクトの概要
- フォルダ構成
- 使用言語・DB・Dockerの構成
- アーキテクチャ
- コーディングルール
など、プロジェクトに関するアレ・コレをまとめたものを書く。どんな些細な情報でもいいので、とにかくこと細かく書く。
→会社の歴史的にコレを使っている、お客様都合でこの言語でしか開発できない などでも良い
フロントとバックで異なる言語を使用する（NodeとJava）とか、コーディングルールがとにかく厳しくて、1ファイルにまとめきれないよ！という時のために、特定のファイルのときだけに特化したinstructionファイルも作ることが出来る。
java.instructions.md
例
# 〇〇プロジェクト
このプロジェクトは〇〇が☓☓するためのWebシステムを構築するプロジェクト。
## 技術スタック
### フロント
- Vue：バージョンとかも書く
- Node.js
### バック
- Java：バージョン
- SpringBoot
### インフラ
- apache
- tomcat
- PostgreSQL
---
applyTo: "**/*.java"
---
# Java 標準コーディング規約・命名規則
## 命名規則
- クラス名: PascalCase（例: MyClass）
- メソッド名: camelCase（例: doSomething）
- 変数名: camelCase（例: userName）
- 定数: 全て大文字＋アンダースコア区切り（例: MAX_COUNT）
- パッケージ名: 全て小文字、ドメイン逆順（例: com.example.project）
## コーディング規約
- 1ファイル1クラス原則（publicクラスはファイル名と一致）
- アクセス修飾子は最小限に（private推奨）
- メソッド・クラスにはJavadocコメントを付与
- インデントはスペース2～4（プロジェクト標準に従う）
- 例外処理はtry-catch-finallyで明示的に
- nullチェックを徹底
- コードの可読性・保守性を重視
- importは必要なものだけ記述し、ワイルドカードimportは避ける
- コードの重複を避け、共通処理はメソッド化
## 推奨事項
- Java標準API・公式ライブラリを優先利用
- テストコード（JUnit等）はsrc/test配下に配置
- ログ出力はLogger（slf4j等）を利用
- コード例や修正案は現状の設計・構成に即して記述
## 参考リンク
- [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html)
- [Oracle Java Code Conventions](https://www.oracle.com/java/technologies/javase/codeconventions-contents.html)
これが無いとどうなるか？
👉 別の思想のコード出してくる（地味に地獄）
③ prompts（作業テンプレ）
役割
👉 よくやる作業をテンプレ化
例
# api.md
## API実装テンプレ
以下の構成で実装すること：
- Controller
- Service
- Repository
要件：
- REST準拠
- バリデーションあり
- エラーハンドリング必須
プロジェクトを全部作っては難しいので、たとえばCRUD部分を生成するためのプロンプトとして用意してあげて、チャット欄には項目とかの情報を与えるみたいなのをするために作っておくとかね。
👉 要は毎回これ書くのダルいのでテンプレとして置いておく命令
使い方（チャットに書く例
/api
TODO一覧APIを作成してください。
取得項目は以下
- id:非表示
- TODO名：string
- 作成日：yyyy-mm-dd形式
- 完了日：yyyy-mm-dd形式
/apiとすることでapiプロンプトを使うと言う意味合いになる。
コツ（ここ重要）
① 一気に作らせない
❌ 全部作って
⭕ Controllerだけ作って
② 修正前提で使う
👉 最初から完璧求めるな
③ 「なぜ」を聞く
この設計にした理由は？
👉 これで精度上がる
④ ファイル指定する
todo.service.ts を修正して
👉 これめちゃ重要
よくあるミス
❌ 人格なし
👉 出力ブレる
❌ ルールなし
👉 プロジェクト崩壊
❌ 丸投げ
👉 ゴミ生成機になる
まとめ
- Copilotは「優秀な新人」
- MDで前提を渡せ
- ルールを明文化しろ
- 指示は具体的に
- 小さく使え
- チャットで育てろ
おまけ（本音）
正直 システムってどんなもの？が分かって、設計できる人ほどAI使いこなせる と思っている。
更に言うと、PM/PLや新人教育経験者のような 人に伝える・教える をやったことの有る人が、ちゃんとした指示を出せるんじゃないかなとも思っている。
要は キチンと説明できる国語力とコミュ力がなく、そもそもシステムってどんなものかわからない ようなスポットPGや新人とかがうまく使えるわけ無いって言うことで、
コードが上手く・早く書けるだけじゃ足りない時代になってきた事に震えて眠るわ。