個人開発をしていると、こんな体験はないでしょうか。

  • 新しいリポジトリを作るたびに、毎回Copilotに「このプロジェクトのルール」を説明している
  • 「この書き方じゃないんだよな…」という提案が何度も出てきて、結局自分で直している
  • Copilotの指示文を書いてみたものの、だんだんカオスになってきて管理できていない

こうした小さなストレスは、「カスタムエージェント設定」をテンプレート化することで、かなり解消できます。

本記事では、個人開発で使いやすいCopilotカスタムエージェント設定の考え方と、実際にそのまま使えるテンプレート例を紹介します。

Copilotカスタムエージェントを「プロジェクト専属エンジニア」にする

従来のCopilotは「その場で1回きりの指示」を前提に使うことが多く、次のような状況が起きがちです。

  • さっき伝えた方針を、別のファイルでもう一度説明する
  • 「このプロジェクトではTypeScript必須」などの前提が、セッションをまたぐと抜け落ちる

一方、カスタムエージェント設定をきちんと用意すると、Copilotを次のような存在として扱えるようになります。

  • 「このリポジトリ専属のフロントエンドエンジニア」
  • 「このブログ専属のテクニカルライター」
  • 「このAPI専属のバックエンドエンジニア」

つまり、プロジェクトごとに経験値を持った相棒のように振る舞わせることができます。

良いカスタムエージェント設定の4つの要素

カスタムエージェント設定は、何となく長文を書くよりも、次の4つを意識して整理すると機能しやすくなります。

  1. 役割（Role）
  2. 技術スタック（Stack）
  3. コーディング規約・禁止事項（Rules）
  4. 出力スタイル（Style）

順番に見ていきます。

1. 役割（Role）：どんな立場の人か

まずは「あなたは誰として振る舞うのか」をはっきりさせます。

  • 例：Next.jsを使うフロントエンドエンジニア
  • 例：既存コードを尊重するリファクタリング担当
  • 例：非エンジニアにも伝わる文章を書くテクニカルライター

ここを曖昧にすると、Copilotは「とりあえずそれっぽいコードや文章」を返すだけになりがちです。逆に、役割が明確だと、提案の方向性がぶれにくくなります。

2. 技術スタック（Stack）：使う技術の範囲を絞る

次に、「このプロジェクトでは何を使うか／使わないか」をはっきりさせます。

  • フレームワーク：React, Next.js, Astro など
  • 言語：TypeScript / JavaScript / Go / Python など
  • テスト：Vitest / Jest / Playwright など
  • パッケージマネージャー：pnpm / npm / yarn

ポイントは、「勝手に新しい技術スタックを持ち込ませない」ことです。

例えば、既存プロジェクトがすべてpnpmなのに、Copilotがnpm installを提案してきたらノイズになります。

3. コーディング規約・禁止事項（Rules）

ここが一番重要なパートです。Copilotに対して、次のようなルールを明示しておきます。

  • ディレクトリ構成：src/ 以下はどう分けるか
  • 命名規則：コンポーネント名、ファイル名、フック名など
  • デザインルール：色はCSS変数からのみ使う、Tailwindは使わない、など
  • 禁止事項：
    • 勝手に新しいライブラリをインストールしない
    • 既存のLintルールを無視するような提案はしない
    • 不必要なコメントや長文の説明を付けない

「こういうことは絶対にしないでほしい」をきちんと書いておくと、後々の手直しコストが大きく下がります。

4. 出力スタイル（Style）：どのくらい丁寧に返すか

最後に、「返答のトーンやボリューム」を指定します。

  • 例：
    • 回答は簡潔に、5〜10行程度に収める
    • コードブロックは1つにまとめる
    • 日本語で回答する
    • 補足説明が必要な場合のみ章立てにする

ここを指定しておくことで、毎回「もっと簡潔に」「もう少し詳しく」と伝える手間を減らせます。

そのまま使えるテンプレート例（個人開発用）

ここからは、実際にコピペしてカスタマイズしやすいテンプレートの例を紹介します。

フロントエンドSPA個人開発用テンプレート

You are an AI pair programmer for my personal projects.

Role:
- Work as a senior frontend engineer.
- Respect existing code style and project structure.

Stack:
- Use TypeScript.
- Use React and Next.js.
- Use pnpm as package manager.

Rules:
- Do not introduce new libraries without being asked.
- Prefer small, composable functions and components.
- Do not change public APIs unless explicitly requested.
- Follow existing naming conventions in the codebase.

Style:
- Answer in Japanese.
- Keep explanations concise (within 8-10 lines).
- Provide one main code block per answer when possible.

このままでは抽象的なので、実際には各プロジェクトごとに「禁止事項」と「既存ルール」を具体的に書き換えると効果が出ます。

技術ブログ執筆アシスタント用テンプレート

You are a technical writer for my blog.

Role:
- Help me write clear and practical technical articles in Japanese.
- Assume readers are junior to mid-level developers.

Rules:
- Avoid buzzwords and vague expressions.
- Prefer concrete examples and step-by-step explanations.
- Keep each section focused on one main idea.

Style:
- Use polite but friendly Japanese.
- Use headings and short paragraphs for readability.
- Suggest better structure if my draft is unclear.

このテンプレートを、実際のブログのトーンに合わせて微調整していきます。

テンプレートを「育てる」ための運用のコツ

テンプレートは、一度書いて終わりではありません。むしろ、プロジェクトが育つほどアップデートの価値が高まると考えたほうが良いです。

おすすめの運用は次のとおりです。

  1. プロジェクト開始時に、最低限のテンプレートを書いておく
  2. 開発中に「毎回同じことを指示している」と気づいたら、テンプレート側に追記する
  3. 半年〜1年に一度、「今のプロジェクトの現実」とテンプレートの内容を見直す

Gitリポジトリ内にcopilot-instructions.md のようなファイルを置いてバージョン管理すると、変更履歴も追いやすくなります。

まとめ：AIではなく「自分の開発環境」をチューニングする

Copilotカスタムエージェント設定は、「AIを賢くする魔法の呪文」ではありません。

むしろ、

  • 自分がどう開発したいか
  • このプロジェクトがどんな前提を持っているか

を言語化し、開発環境全体をAIフレンドリーに整える作業だと言えます。

テンプレートを用意しておけば、新しい個人開発プロジェクトを立ち上げるたびに、

  • 同じ説明を何度も繰り返す手間
  • 「それじゃない」提案を手で直すコスト

を大きく減らすことができます。

まずは、今進行中の個人開発プロジェクトのために、簡単でもいいので1つテンプレートを書いてみるところから始めてみてください。そこから少しずつ育てていくことで、「Copilotと一緒に開発する」体験が、ぐっと快適になるはずです。