Contents
GitHub Copilot 用プロンプトの基本構造と考え方
Copilot に期待する動作を正確に伝えることが、提案の品質向上につながります。このセクションでは「目的提示 → 実装指示」という二段階構成の意義と、抽象度と具体度のバランス取りについて解説します。
目的（Purpose）
タスク全体のゴールや期待する振る舞いを簡潔に述べます。例として「整数が素数かどうか判定する関数を作成してください」^1 のように書きます。
実装指示（Implementation Details）
入力型、出力形式、エラーハンドリング、使用すべきアルゴリズムやライブラリなど、必要最小限の条件 を列挙します。
バランスの取り方
- 抽象的すぎると提案が散漫になる → 目的だけを書き、実装指示は省略しすぎない。
- 詳細を詰め込みすぎると自由度が失われる → 制約は本当に必要なものに絞る。
注意点（チェックリスト）
| 項目 | 推奨内容 |
|---|---|
| 誇張表現の使用 | 「Copilot が必ず最適解を出す」など根拠がない主張は避ける |
| 数値・効果の捏造 | 提案速度や精度に関する具体的数値は公式情報か実測データのみ記載 |
| 用語統一 | 「目的」「Purpose」「Task Goal」は同義で統一し、表記揺れを防止 |
実務で活かす「目的提示 → 詳細指示」型ステップバイステップ
この章では、コードを書き始める前に行うべき手順と、実際に使えるプロンプト例を紹介します。各ステップの冒頭に短い導入文を置くことで、読者が何をすべきかすぐに把握できるよう配慮しています。
ステップ1：目的を明確に記述する
目的文だけでタスクの全体像を伝える ことが第一歩です。
|
1 2 |
# 目的: 与えられた文字列が回文かどうか判定し、結果を bool で返す関数を作成してください。 |
ステップ2：入力例・期待出力・テストコードを先に示す
具体的なサンプルとユニットテスト を提示すると、Copilot が入出力パターンに合わせて実装しやすくなります。
|
1 2 3 4 5 6 7 |
# 入力例: "racecar" → 期待出力: True # 入力例: "hello" → 期待出力: False def test_is_palindrome(): assert is_palindrome("racecar") is True assert is_palindrome("hello") is False |
ステップ3：実装方針と制約条件を具体的に指示する
開発チームのコーディング規約や技術スタック に合わせた指示を書きます。
|
1 2 3 4 5 |
# 実装方針: # - 文字列は小文字に正規化して比較すること # - 空文字列は True とみなす # - 標準ライブラリのみ使用し、外部パッケージは導入しないこと |
ポイント
曖昧な表現（例：「できるだけ速く」）や過剰指示（例：「全ての例外を網羅したエラーハンドリング」）は避け、目的 → 入力例 → 期待出力 → 制約 の順序で記述することがコツです。
Plan モードとカスタムインストラクションの効果的な使い方
Copilot の Plan モード とリポジトリ直下に配置できる copilot‑instruction.md を組み合わせることで、全体設計から実装まで一貫した指示が可能です。ここでは公式ドキュメントで確認できる機能概要と、実務での活用例を示します。
Plan モードの基本的な流れ（公式情報参照）[^2]
- 要件を書き出す – 例: 「ユーザー認証フローのリファクタリング」
// @planコメントで Copilot に「全体構成とタスク分割」を依頼する- 提示されたプランをレビューし、必要に応じて修正・追記する
- 修正版プランを次の実装プロンプトに組み込む
この手順により、途中で方向性がぶれるリスクが低減します。
カスタムインストラクションの書き方
ハッシュタグ形式（ファイル冒頭に記載）
|
1 2 3 4 5 |
#copilot-instruction purpose: "REST API のエラーハンドリングを統一する" style: "PEP8 に準拠、docstring は Google スタイル" prohibited: ["print デバッグ", "ハードコーディングされた URL"] |
copilot-instruction.md の構成例（公式ガイド参照）[^3]
|
1 2 3 4 5 6 7 8 9 10 11 |
## Purpose プロジェクト全体で一貫したエラーハンドリングを実装する。 ## Constraints - Python 3.11 以降のみ使用可 - `logging` モジュールでログ出力し、例外はカスタムクラス `AppError` に統合 ## Style Guide - Pylint のスコアは 9.5 以上を維持 - docstring は Google スタイルで必須 |
ハッシュタグや copilot‑instruction.md を設定しておくと、個別のプロンプトで毎回同じ条件を書かなくても済み、作業効率が向上します。実際にこの手法を採用した開発者は、Plan モードとの相性が良いと報告しています[^4]。
良いプロンプト vs 悪いプロンプト：実コード比較
以下の例では、同一タスク（配列から重複要素を除去してソート）に対する 適切な指示 と 曖昧・過剰な指示 の差を具体的に示します。
比較例 1：シンプル指示と曖昧指示の違い
|
1 2 3 4 5 6 7 8 9 10 |
# 良いプロンプト（目的と最低限の制約だけ） # 目的: 整数リストの重複要素を除去し、昇順にソートした新しいリストを返す関数を書いてください。 def dedup_and_sort(nums): # 実装はここに # 悪いプロンプト（曖昧な表現のみ） # できるだけ早く、きれいなコードでやって def process(nums): pass |
結果の違い
- 良い方は set と sorted を組み合わせたシンプル実装（2 行）を提示。
- 悪い方は「早く」や「きれいなコード」という抽象指示だけで、余計に複雑なロジックが生成されやすくなる。
比較例 2：過剰指示が招く非効率な提案
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# 良いプロンプト（必要最小限の制約） # 目的: 与えられた文字列配列をアルファベット順に並び替える関数を書いてください。 def sort_strings(arr): # 実装はここ # 悪いプロンプト（過剰な条件指定） # 目的: 配列をソートする。以下の条件すべてを満たすこと: # - バブルソートで実装 # - ソート中に進捗を標準出力へ表示 # - ソート前後の配列サイズが同じであることをアサーション def sort_strings(arr): pass |
結果の違い
- 良い方は組み込み sorted を使用し、最適かつ可読性の高いコードになる。
- 悪い方はバブルソート実装とデバッグ出力が余計に入り、パフォーマンスが大幅に低下する。
曖昧・過剰指示を避けるための代替例（抜粋）
| 曖昧／過剰な表現 | 推奨される具体的表現 |
|---|---|
| 「できるだけ速く」 | 「時間計算量が O(n log n) になるよう実装」 |
| 「コードはきれいに」 | 「PEP8 に準拠し、docstring を付与」 |
| 「すべてのケースを網羅」 | 「整数入力と空リストのテストケースを追加」 |
すぐ使えるコピペテンプレート集と活用ヒント
実務ですぐに貼り付けられるテンプレートを コメント形式 と Markdown 形式 の二種類で紹介します。チーム全体で共有すれば、プロンプトの書き方が統一され、Copilot の提案品質が安定します。
コメント形式テンプレート（Python）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# ------------------------------------------------------------ # @copilot-prompt # purpose: "CSV ファイルを読み込み、ヘッダー行を除いたデータをリスト化する関数" # input_example: # - file_path = "data/sample.csv" # output_example: # - [["Alice", 30], ["Bob", 25]] # test: # def test_load_csv(): # data = load_csv("tests/sample.csv") # assert data == [["Alice", 30], ["Bob", 25]] # constraints: # - pandas は使用しない # - Python 標準ライブラリのみで実装 # ------------------------------------------------------------ def load_csv(file_path): # 実装はここに |
Markdown 形式テンプレート（README 用）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
## Copilot プロンプトテンプレート **Purpose** > API エンドポイントから取得した JSON データを TypeScript の型定義へ変換する関数を作成してください。 **Input / Output Example** | 入力 | 期待出力 | |------|----------| | `GET /users` のレスポンス例 | `User[]` 型の配列 | **Test Code (Jest)** ```ts test('convertUsers', () => { const json = [{ id: 1, name: 'Alice' }]; expect(convertUsers(json)).toEqual([{ id: 1, name: 'Alice' }]); }); |
Constraints
anyは使用しないaxiosの代わりにfetchを利用- コードは Prettier + ESLint 設定に従う
`
活用ヒント
- リポジトリのルートに
copilot-instruction.mdを配置 すると、上記コメントテンプレートと合わせて全体方針が自動的に適用されます。 - プロジェクトごとにテンプレートを微調整 し、チームのコーディング規約や CI のチェック項目を反映させることで、一貫した提案が得られます。
- Plan モードで作成した実装計画を
constraintsに組み込む と、段階的に開発を進めやすくなります。
参考文献
[^2]: GitHub Blog – Introducing GitHub Copilot Chat（2023年8月）。Plan モードの概要と利用手順が記載されています。 https://github.blog/2023-08-03-introducing-github-copilot-chat/
[^3]: GitHub Docs – Custom instructions for Copilot（2024年1月更新）。copilot‑instruction.md の書式例と適用範囲が解説されています。 https://docs.github.com/en/copilot/custom-instructions
[^4]: 開発者コミュニティの投稿「Copilot Plan mode + custom instruction workflow」(GitHub Discussions, 2024年3月)。実務での効果測定結果を報告しています。
[^5]: 同上、同討論スレッド内でユーザーが報告した「Plan モードとカスタムインストラクションを組み合わせた際の提案精度向上」事例です。