自分とともに成長するcopilotの育て方🌱

※これは「株式会社ネクスウェイ Advent Calendar 2025」4日目の記事です🎄

あらゆるコミュニケーションを支援する株式会社ネクスウェイの開発メンバーが、好きな技術・取り組み・学びをゆるく書いていきます

はじめに

こんにちは！株式会社ネクスウェイで新卒エンジニアとして働いているはらでぃーです。

大学では政治経済系を勉強していた文系出身で、エンジニアとしてのバックグラウンドはほぼゼロからのスタートでした。

現在は「トッツゴー」という請求書受領・明細突合サービスの開発に携わっています。

技術スタックはRuby on RailsとVue.js/Nuxt.jsで、既存の大規模コードベースと日々格闘しています💻

今回は、私がGithub Copilotをどう活用しているか、特に.github/instructionsと.github/promptsのカスタマイズについて紹介します。

AI導入前：圧倒的虚無感との戦い

新人エンジニアとして入社して最初にぶつかった壁は、想像以上に大きなものでした。

• コード探索に時間がかかる🔍
  「この機能はどこに実装されているんだろう？」と思っても、ファイル構造の理解に時間がかかり、関連するコードを見つけるまでに何時間もかかることがありました。
  特にフロントエンドの場合、バックエンドよりもコードベースが巨大なため、該当画面のファイルを探し当てるのにも一苦労していました。

• 設計思想が理解できない🤔
  コードを読んでも理解するのに精一杯で、「なぜこう書かれているのか」というところにあまり気を配れずにいました。
  特に設計思想や背景知識が不足していて、質問したいけど何を質問すればいいかも分からない状態でした。

• スピードが要求される部署なのに実装が遅い⏰
  どんどん機能を作っていくプロダクトフェーズのためスピードが要求されます。
  しかし小さな修正でも時間がかかってしまう。
  この状況に焦りを感じていました。

転機：生成AIとの出会い✨

そんな中、生成AIを使い始めました。

正直最初はあまりAIにいい印象を持てていませんでした。

• 自分の理解の範疇を超えたアウトプットをしてくる
• 自分で考える前にアウトプットが出るから勉強にならない

そこで方向性を転換し、AIを「丸投げ開発ツール」ではなく「自分が理解する時間を確保するツール」として活用することにしました💡

コードリーディングから実装計画、コード生成、レビューまで、開発全般の相棒とし、プロンプトを整備して理解以外のことに気を配らなくてもいいようにする。

そして、最終的な実装を全て自ら説明できるようにすることで責任は自分が持つ。

このような思想でAIを活用しています。

実際に使用しているinstructionsとprompts📝

英語以外の言語を使用すると消費トークン数でコスパが悪い、また、回答がローカライズされてしまうなどの可能性が指摘されているため、基本的にinstructionsは全て英語で記載しています。

参考：

ファイル構成📂

.github/instructions/
├── general.instructions.md      # 命名規則、コメント
├── project.instructions.md      # 技術スタック、アーキテクチャ
├── quality.instructions.md      # 品質チェックリスト
└── workflow.instructions.md     # 開発手順

.github/prompts/
├── pj-start.prompt.md          # プロジェクト開始時
├── pr-review.prompt.md         # PRレビュー時
└── support.prompt.md           # サポート調査時

.github/instructions/配下のファイルは「.instructions.md」という形式で保存しておけばcopilotがプロンプトを受けた時に自動で読み込んでくれます。

プロジェクトの前提をcopilotに共有しておくことで、こちらが余計に指示する必要やcopilotの誤解による暴走なども防げるのでおすすめです👍

general.instructions.md の内容

これは全てのファイルで適用される、前提となる指示です。

---
applyTo: "**"
---

- You are a genius programmer.
- Please provide appropriate advice based on the user's instructions.
- Output your answers in Japanese(in Kansai dialect).
- Use meaningful names for variables and functions.
- Write comments that are concise and specific.
- Avoid magic numbers; define them as constants.
- Prioritize code readability.
- You have permission to access the development environment database, but you do not have permission to modify the production environment database.
- whatever tasks you are given, don't hesitate to spend more time thinking about the best possible answer.
- Before writing new code, check related files (models, utils, etc.) to see if there are existing methods that can be reused.
- Always strive for the simplest and most "Rails-like" implementation.

ポイント：

• 関西弁での応答：自分が関西出身なので関西弁で話してくれるとほっこり😊
• 意味のある命名：変数や関数名は分かりやすく
• コメントは簡潔に：コメントは簡潔かつ具体的に
• マジックナンバー禁止：定数として定義
• 可読性優先：読みやすいコードを優先
• 既存メソッドの再利用：新しいコードを書く前に、関連ファイルをチェック

quality.instructions.md の内容

コード品質を保つためのチェックリストです✅

---
applyTo: "**"
---

# Overview
- This file lists items to ensure good code quality.
- Please keep these points in mind when writing code.

## 1. Code Quality
- Are method and variable names appropriate and easy to understand?
- Are there proper comments for complex logic?
- Are the responsibilities of each class and method clear?
- Is there any duplicated or unnecessary code?

## 2. Potential Bugs
- Are edge cases handled properly?
- Is error handling appropriate?
- Is the handling of null/undefined safe?

## 3. Performance
- Are there any N+1 query problems?
- Are unnecessary database queries avoided?
- Are database indexes set appropriately?

## 4. Security
- Protection against SQL injection (parameterized queries)
- Protection against XSS (proper escaping)
- Authorization implementation (using Pundit policies)

## 5. Test Coverage
- Make sure that tests are minimal, necessary, and reusable to prevent test bloat
  - If a test is deemed unnecessary, it does not need to be written
- Are important logics covered by tests?
- Are there enough test cases?

ポイント：

• コード品質：命名、コメント、責務の明確化
• 潜在的なバグ：エッジケース、エラーハンドリング、null/undefined対策
• パフォーマンス：N+1問題、不要なクエリ、インデックス
• セキュリティ：SQLインジェクション、XSS、認可
• テストカバレッジ：最小限・必要十分・再利用可能（テスト肥大化を防ぐ）

このチェックリストのおかげで、Copilotが生成するコードの品質が向上しました。

特に「テストは最小限・必要十分・再利用可能に」という指示は、テストコードの肥大化を防ぐのに効果的でした。

workflow.instructions.md の内容

開発手順を標準化しています🔄

---
applyTo: "**"
---

# Overview
This file describes the development workflow.

# General Rules
- Make sure your all of outputs are in Japanese and use Kansai dialect.
  - This includes plan files, and chat responses.
    - but commit messages, PR descriptions should be in standard Japanese.
  - When you are thinking, you can use English internally, but final outputs must be in Japanese.

# Development Procedure
0. Preparation
- Make sure you are in branch "develop"
  - and pull the latest changes from the remote repository
  - If there isn't a feature branch for your task, create one from "develop" with a prefix like "feature/{issue-number} + {short-description}" or "fix/{issue-number} + {short-description}"
  - If the modification is expected to involve both backend and frontend changes, after creating the feature branch, please create topic/backend and topic/frontend branches derived from the feature branch
- Make a empty commit and push it to the remote repository to create the branch there

1. Create or update an implementation plan
- When you receive instructions from the user, or an issue/PR number, please analyze it.
- The implementation plan should be created with the following items:
  - How to reproduce the issue (if applicable)
  - Purpose / Overview
  - Direction / What you want to do
  - Impact on Existing Implementation
    - The extent to which the current implementation will be influenced or modified by this change.
    - Confirm that all of changes don't affect existing functionality negatively.
    - if there are any potential negative impacts, describe them here.
  - Work Plan / Specific Steps

2. Output the implementation plan
- Once the plan is complete, create an implementation plan file under to2go/plan with a name like ◯◯.md
- note: After plan is created, stop the process and confirm the plan with the user and make any necessary adjustments

3. Implementation
- After the plan is complete, proceed with the implementation
- When commenting out code, write the reason why a particular approach was not adopted

4. Commit
- Once implementation is complete, commit your changes
- note: you don't need to push the plan file to the remote repository
- Adjust commit granularity to be appropriate
  - do not combine commits that would have different prefixes into a single commit 
  - e.g., do not combine feature and test commits into one
- Including 'What' and 'Why' in the commit message is important
- add a following prefix to the commit message:
  - add: Add small files or code (e.g., image files).
  - change: Make small changes to files or code (e.g., replace images).
  - feat: Add features for users. Can include add/change.
  - style: Change the appearance of code without affecting functionality (e.g., CSS).
  - refactor: Refactor code.
  - fix: Fix bugs.
  - remove: Delete files, etc.
  - test: Related to tests.
  - chore: Related to build, auxiliary tools, or libraries.
- before committing, check the rubocop

5. Update a plan file
- After the PR is created, update the plan file under to2go/plan to reflect the actual implementation details
- Add a section "## Completed Work" at the end of the plan

6. Create a Pull Request
- After committing, check your current branch and create a pull request

7. Update the PR description
- After creating the PR, update the PR description based on the following format:
  - 概要: write a related issue number and brief summary
  - やったこと: what was done in this PR
  - やってないこと: what was not done
  - 確認手順: write steps using actual data as possible
  - スクリーンショット & 動作ムービー
  - 補足・参考 URL

ポイント：

• 準備：developブランチから適切な名前でfeatureブランチを作成
• 実装計画の作成：いきなりコードを書かず、まず計画を立てる
  • 再現手順、目的、方向性、既存実装への影響、作業計画セクションを含める
• ユーザー確認：計画を作成したら停止し、実装前に必ずユーザーに確認
• 実装：計画に基づいて実装、コメントアウト時は理由を記載
• コミット：WhatとWhyを含める、適切なプレフィックスを付ける
  • feat, fix, refactor, test, chore など
  • コミット前にrubocopでスタイルチェック
• 計画ファイルの更新：PR作成後、実際の実装内容を計画ファイルに反映
• PR作成とレビュー：適切なフォーマットでPR説明を記載

pj-start.prompt.md の内容

プロジェクト開始時に使うプロンプトです🚀

---
agent: "agent"
model: "Claude Sonnet 4.5"
description: "プロジェクトのスタート時に実行するエージェントです"
---

# ゴール
"/pj-start"に続き、"issue <issue_number>" または "pr <pr_number>"と受け取ったら以下の作業を開始してください。
- to2go/.github/instructions/workflow.instructions.mdを読み込み、作業を開始してください。

使い方：
チャットで /pj-start issue 1234 のように入力すると、copilotが自動的にworkflow.instructions.mdを読み込んで、リポジトリ内のissue #1234の内容を分析し、実装計画を立ててくれます。

実践例：実際の開発フロー💼

では、実際にどう使っているか、workflow.instructions.mdに沿った具体例を紹介します。

具体例：「csvインポートエラー修正」（issue #6785）

ステップ1：タスクの理解と実装計画の作成📋

copilotチャットウインドウで/pj-start issue 6785と入力すると、pj-start.prompt.mdが呼ばれ、ワークフローが開始されます。

Copilot：

ほな、issue #6785を確認するで。

【再現手順】
1. 特定の文字コード（Shift_JIS）のcsvファイルを用意
2. csvインポート画面からアップロード
3. エラーが発生

【課題】
CSVインポート時に、特定の文字コードでエラーが発生しとる。

【原因分析】
`api/hogehoge/csv_import.rb`を見たら、
文字コード判定のロジックに問題がありそうやな。
現状はUTF-8決め打ちになっとって、他の文字コードに対応できてへん。

【方向性】
文字コード自動判定ライブラリ（charlock_holmes）を使って、
どんな文字コードでも正しく読み込めるようにする。

【既存実装への影響】
- csv_import.rbの文字コード処理部分を変更
- 既存のUTF-8ファイルの読み込みには影響なし
- 他の文字コードのファイルも読めるようになる（機能追加）

【作業計画】
1. charlock_holmesの導入
2. 文字コード判定ロジックの実装
3. エラーハンドリングの追加
4. テストケースの追加（UTF-8, Shift_JIS, EUC-JP）

詳細な計画をplan/6785-import-csv-error.mdに作成したで。
確認してくれへん？

フォーマットに従って作成された計画ファイルを確認し、問題なければ実装に進みます。

ステップ2：実装計画の理解💡

私：「charlock_holmes初めて見たんやけど軽く概要教えてくれん？」

Copilot：

ああ、説明するわ！

charlock_holmesはこんな感じで使うんや：

detection = CharlockHolmes::EncodingDetector.detect(content)
encoding = detection[:encoding]
content.force_encoding(encoding).encode('UTF-8')

これで自動的に文字コードを判定して、UTF-8に変換できるで。

ステップ3：実装⚙️

私：「なるほどね！計画OKなので実装続けて」

Copilot：

ほな、実装していくで！

まず、Gemfileにcharlock_holmesを追加するわ。
次に、csv_import.rbの文字コード判定部分を修正するで。

Copilotが実装を進めてくれます。途中で分からない部分があれば質問します。

私は質問に対する回答に対して不明な点があることが多いので、さらに突っ込んで聞いたり、ドキュメントを見にいったりします。

このように、理解しながら実装を進めていきます。

ステップ4：コミット✅

実装が完了したら、コミットします。

私：「ええと思う！コミットしよう」

実装完了したで！rubocopでチェックするわ。

...チェック完了。問題なしや。

コミットメッセージはこんな感じでどうや？

feat: csvインポート時の文字コード自動判定機能を追加

- charlock_holmesを導入
- csv_import.rbに文字コード自動判定ロジックを実装
- UTF-8以外の文字コード（Shift_JIS, EUC-JP等）にも対応
- エラーハンドリングを追加
- テストケースを追加（UTF-8, Shift_JIS, EUC-JP）

close #6785

ステップ5：計画ファイルの更新📝

コミットが完了すると、workflow.mdに従ってplanファイルに実装内容を記載してもらいます。

Copilot：

plan/6785-import-csv-error.mdに「## Completed Work」セクションを追加したで。
実際の実装内容を反映しといたわ。

ステップ6：PR作成🎯

そして、定義したフォーマットに基づきPRの本文も更新してもらいます。

Copilot：

PRを作成したで！
タイトルは「feat: csvインポート時の文字コード自動判定機能を追加」や。

PR説明も以下のフォーマットで書いといたで：

## 概要
- close #6785
- csvインポート時に、UTF-8以外の文字コードにも対応

## やったこと
- charlock_holmesの導入
- 文字コード自動判定ロジックの実装
- エラーハンドリングの追加
- テストケースの追加

## やってないこと
- 特になし

## 確認手順
1. Shift_JISのCSVファイルを用意
2. csvインポート画面からアップロード
3. 正常にインポートされることを確認

## スクリーンショット & 動作ムービー
（後で追加）

## 補足・参考 URL
- charlock_holmes: https://github.com/brianmario/charlock_holmes

以上がざっくりとしたワークフローになります。

最初に「/pj-start issue 6785」と投げるだけで、細かなフォーマットなどに気を配らずに実装の理解に集中することができるのが大きなメリットです！

自分の成長と共にcopilotも成長する仕組み🌱

Copilotを使っていると、経験の浅い自分の目から見ても時々意図しない挙動をすることがあります。そんな時は：

1. 問題のある挙動を観察👀

   • 例：テストコードが肥大化していた

2. Copilotに振り返らせる🤔

   • 「なぜこのようなテストを生成したのか」「どうinstructionsを書いていればこの事象を回避することができたか」と質問

3. instructionsを改善📝

   • quality.instructions.mdに「テストは最小限・必要十分・再利用可能に」を追加

4. 次回の挙動を確認✨

   • より適切なテストが生成されるようになった

このフィードバックループを回すことで、Copilotも自分と一緒に成長していきます💪

まとめ

自分がこのようにワークフローを定義しているのは完全に自動化するというよりも、理解に集中する仕組みを作るという目的が大きいです。

• コードを探すのに時間を浪費してしまう
• プロダクトの概要や特定のフォーマット、スタイルを毎回伝えるのがめんどくさい

本記事がこのような悩みを持つ方々のヒントとなると嬉しいです。

皆さんも、自分だけのCopilotを育ててみませんか？🪴

おわりに

• お客様やBiz側からの問い合わせも請け負っているので、問い合わせ業務の効率化にも取り組んでいます
• 今後も生成AIを活用して、どんどん業務全般の効率化に力を注いでいきます💪

最後まで読んでいただきありがとうございました。

株式会社ネクスウェイ Advent Calendar 2025では明日以降も、開発メンバーがそれぞれの「好き」と「学び」を自分の言葉で綴っていく予定です。

明日 6 日目の記事は、同じくネクスウェイの @shortcut_button さん です。
引き続き、ネクスウェイのアドカレをお楽しみください🎄

---

• もっと他の記事も読んでみたい方
  • 【Qiita】株式会社ネクスウェイ【Organization】
  • 【note】ネクスウェイのエンジニア
    　
• 当社に興味がある方はこちら👀
  • エンジニア採用について | 株式会社ネクスウェイ