6
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Prompt engineering for GitHub Copilotの要点メモ


ポイントだけ要約

  1. 大まかな指示から始め、徐々に詳細を伝える
    • 最初はゴールやシナリオをざっくり示し、後から具体的な要件を追加
  2. 例を示してCopilotに意図を伝える
    • 入力データや出力例など、サンプルを提示することで意図を明確化
  3. 大きなタスクは小さく分割する
    • 複雑な要求を一度にまとめて投げるより、細分化して順序立てて依頼
  4. 曖昧さを避ける
    • 「これ」「あれ」といった指示でなく、具体的に関数名や対象コードを指定
  5. 関連するコードを明示する
    • 使いたいライブラリや、参照したいファイルをCopilotにわかるようにする
  6. 試行錯誤を繰り返す
    • 望む結果が得られない場合は、プロンプトを修正したり履歴を調整
  7. チャット窓は話題毎に使う
    • 基本新しく窓出さないで継続で会話する。目的に無関係なチャット履歴は削除し、Copilotに与える文脈をスリム化
  8. 良いコーディングプラクティスを守る
    • 一貫したコードスタイル、適切なコメント、テストの活用など

各項目のせつめい

1. 大まかな指示から始め、徐々に詳細を伝える

Copilotに新しい機能の実装などを依頼するときは、まず「何をしたいのか」をざっくりと示し、あとから「どう実装してほしいか」の詳細を順番に伝えましょう。

例:

整数が素数かどうかを判定する関数を作成してください。
この関数は整数を受け取り、もし素数なら true を返すようにしてください。
もし引数が正の整数でない場合は、エラーを返すようにしてください。
  • 目的(素数判定)と前提(正の整数であること)を先に示し、返り値やエラー条件の指定などを詳細として後から追加
  • 大まかな方針 → 具体的な条件の順に書くと、Copilotはより正確な提案ができます

2. 例を示してCopilotに意図を伝える

Copilotは「こういう入力が来たら、こういう出力を期待している」という例を与えると、狙った処理やロジックを理解しやすくなります。
単なる入力と出力の例だけでなく、実装例やテストコードを先に書いてみせるのも効果的です。

例:

文字列中に含まれる日付をすべて見つけ出し、配列で返す関数を作成してください。
日付は以下のような形式を想定しています:
- 05/02/24
- 05/02/2024
- 5/2/24
- 5/2/2024
- 05-02-24
- 05-02-2024
- 5-2-24
- 5-2-2024

例:
findDates("I have a dentist appointment on 11/14/2023 and book club on 12-1-23")

return: ["11/14/2023", "12-1-23"]
  • 期待する入力と出力の形を明示することで、Copilotが正しいパターンマッチやフォーマット変換を推測しやすくなる
  • ユニットテストをあらかじめ書いてから「このテストをパスする関数を作って」というのも一つの方法

3. 大きなタスクは小さく分割する

一度に複数の処理をまとめてお願いすると、Copilotの提案が複雑化しやすく、意図と外れた結果が返ってくることがあります。大きいタスクを少しずつ段階的に依頼すると、Copilotの回答精度が上がります。

例:

  1. 10×10の文字のグリッドを生成する関数
  2. 有効な単語リストを元に、グリッド内に存在する単語を見つける関数
  3. 上記の2つの関数を使って、少なくとも10個の単語が含まれるグリッドを生成する関数
  4. 仕上げとして、グリッドを表示しつつ、ランダムに選んだ10個の単語を出力する関数
  • 個々の小さな処理を実装→テスト→修正という形で進めやすい
  • 後から関数同士を組み合わせることで、大きなアプリケーションが完成

4. 曖昧さを避ける

「このコード」「これ」などの表現は、Copilotから見ると「何を指しているのか」が不明瞭になりがちです。関数名やファイル名など、具体的な対象を指示しましょう。

  • 例: 「createUser関数は何をする機能ですか?」
    → 対象となる関数が明確に特定できる
  • コードレビューや説明を求めるときは、あらかじめ「どのライブラリを使用しているか」を示すとより正確な答えが得られます

5. 関連するコードを明示する

Copilotはエディタに表示しているファイルを参照したり、選択中のテキストブロックをもとに回答を生成します。余計なファイルを閉じ、必要なファイルのみを開いておくとノイズが減って効果的です。

  • Copilot Chatを使用する場合は、チャットで「#file」「@workspace」を使ってファイルやワークスペースを参照させることも可能
  • IDEごとに参照方法は異なるため、詳細は「Asking GitHub Copilot questions in your IDE」などの公式ドキュメントを確認

6. 試行錯誤を繰り返す

最初の提案が必ずしもベストとは限りません。

  • 不十分な場合は、提案を削除してプロンプトを修正し再度生成
  • または生成したコードを活かしつつ「ここを修正して」と追加の要望を出す

Copilot Chatなら、前回の回答に言及して「そこを改良して」と頼むことができますし、逆にリセットして一からやり直すことも簡単です。


7. やり取りの履歴を管理する

Copilot Chatは会話の履歴を参照して回答を生成するため、履歴が膨大になったり、無関係な話題が混ざるとノイズが増えます。

  • 新しいタスクを始める際はスレッドを分ける、または古い履歴を削除
  • 過去の誤った指示や不要な指示は消して、Copilotに余計なヒントを与えないようにする

8. 良いコーディングプラクティスを守る

Copilotの提案が思わしくない場合、自分のコードベースそのものを見直すことも大切です。

  • 一定のコーディング規約やスタイルに従う
  • 変数名や関数名を意味の分かるものにする
  • 適切なコメントをつける
  • モジュール化、スコープの分割をきちんと行う
  • ユニットテストを用意し、仕様や期待値を明文化する

Copilotに「このコードをリファクタして」「コメントを追加して」と指示すれば、自動化のヒントになる提案が得られる場合もあります。


個人的まとめ

↓こんな記事を書いておいてなんですが・・・

プロンプトエンジニアリングにおける"術"やら"なんとか式"のような技的な部分は上記リンク記事の見解の通り必要なくなってくると考えていますが
本記事のように会話のアプローチ部分に関しては今後も必要になってくるのではと考えます。

イメージ的には入力内容の"精度"はAI側が保管してくれるので「なんとか術」みたいなのは不要になっていくと思いますが、
入力内容の観点に関しては指示側しか持たない情報なのでしっかりAIと会話していかないと、といったところでしょうか。

6
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?