プロンプトエンジニアリングの基本
GitHub Copilot から役に立つ提案を引き出せるかどうかは、こちらの伝え方で大きく変わります。このページでは、Copilot への伝え方を工夫する「プロンプトエンジニアリング」の基本を整理します。
この記事で分かること
- プロンプトエンジニアリングとは何かと、プロンプトの役割
- 基本原則である「4 つの S」
- 4 つの S を土台にした、4 つのベストプラクティス
- 例の与え方による 3 つの方法(ゼロショット、ワンショット、少数ショット)
- 長い会話の扱い方と、役割を与える方法(ロールプロンプト)
試験範囲では、「プロンプトエンジニアリングとコンテキストの作成を適用する」(比重 10〜15%)の分野にあたります。
用語の整理
| 用語 | 意味 |
|---|---|
| プロンプト(prompt) | AI に対する指示や質問。Copilot の場合は、チャットに入力する文章のほか、コードの中に書くコメントも、プロンプトとして働く |
| プロンプトエンジニアリング(prompt engineering) | AI から望む結果を引き出せるように、明確な指示を作ること |
| コンテキスト(context) | AI が提案を作るときに参考にする、周囲の情報。開いているファイル、ファイル名、コメント、これまでの会話など |
| チャット履歴(chat history) | Copilot Chat での、これまでのやり取りの記録 |
| PRU(Premium Request Unit) | Copilot の一部の機能を使ったときに消費される、利用量の単位 |
プロンプトエンジニアリングとは
プロンプトエンジニアリングとは、GitHub Copilot のような AI に対して、明確な指示を作ることです。目的は、プロジェクトの事情に合った、適切なコードを生成させることにあります。
公式の教材では、良いプロンプトによって得られるコードの条件を、3 つの面から説明しています。
| 面 | 意味 |
|---|---|
| 構文(syntactically) | そのプログラミング言語の書き方として正しい |
| 機能(functionally) | 求めた働きをする |
| コンテキスト(contextually) | プロジェクトの状況や決まりに合っている |
プロンプトの役割:直接よくなるのは「提案の質」
プロンプトを工夫することで直接よくなるのは、Copilot が返す提案の質です。求めているものが正確に伝わるほど、提案は的確になり、プロジェクトの状況にも合うようになります。
一方で、プロンプトは万能ではありません。プロンプトの役割と、そうでないものを、取り違えないようにします。
| 区分 | 内容 |
|---|---|
| プロンプトの工夫で直接よくなること | 提案の的確さ。プロジェクトの状況への適合。やり直しの回数が減ること |
| プロンプトの役割ではないこと | コーディングの作業全体を自動化すること。不具合を即座に、自動で直すこと。複数の人が同時に作業する、共同作業の仕組みを実現すること |
このサイトでの補足
この表は、公式の教材の内容をもとに、このサイトで整理したものです。良いプロンプトは、これらの作業を進める助けにはなります。しかし、それはプロンプトによって「提案の質」が上がった結果です。プロンプトそのものが、自動化や共同作業の機能を持つわけではありません。
基本原則:4 つの S
プロンプトエンジニアリングの基本原則は、頭文字が S の 4 つの言葉にまとめられています。
| 原則 | 英語 | 意味 |
|---|---|---|
| 単一 | Single | 1 つのプロンプトでは、明確に決めた 1 つの作業や質問だけを扱う |
| 具体的 | Specific | 指示は、はっきりと、詳しく書く。具体的であるほど、提案が的確になる |
| 短くする | Short | 具体的でありながら、簡潔に、要点を押さえて書く |
| 周囲環境 | Surround | 内容が分かるファイル名を付け、関連するファイルを開いたままにする。Copilot に渡るコンテキストが豊かになる |
4 つの S の関係
「具体的」と「短くする」は、反対のことを言っているように見えます。しかし、求められているのは、必要なことは詳しく書きつつ、余計なことは書かないというバランスです。長すぎるプロンプトは、Copilot に負担をかけ、やり取りを複雑にします。
「周囲環境」だけは、プロンプトの文章そのものではなく、プロンプトを取り巻く環境についての原則です。Copilot は、入力された文章だけでなく、エディターで開いているほかのファイルなども参考にします。そのため、ファイル名や、開いておくファイルを整えることも、良い提案を得る手段になります。
4 つのベストプラクティス
4 つの S を土台にして、より実践的な進め方が 4 つ挙げられています。
| ベストプラクティス | 英語 | 土台になっている原則 |
|---|---|---|
| 十分な明瞭さを提供する | Provide enough clarity | 単一、具体的 |
| 詳細を含む十分なコンテキストを提供する | Provide enough context with details | 周囲環境、短くする |
| 学習用の例を提供する | Provide examples for learning | — |
| アサートと反復 | Assert and iterate | — |
1. 十分な明瞭さを提供する
「単一」と「具体的」の原則に沿って、何をしてほしいのかを、はっきりと書きます。
公式の教材は、「与えられたリストから偶数を選び出して返す、Python の関数を書いてください」という例を挙げています。作業が 1 つに絞られていて(単一)、何を入力して何を返すのかが明確です(具体的)。
2. 詳細を含む十分なコンテキストを提供する
「周囲環境」の原則に沿って、Copilot の理解を助ける情報を与えます。与えるコンテキストが多いほど、提案は状況に合ったものになります。
たとえば、コードの先頭にコメントを書いて、何を作りたいのかを説明しておく方法があります。このとき、手順を箇条書きにすると、詳しさを保ちながら短く書けます(短くする)。
Copilot は、エディターで並行して開いているタブも、コンテキストとして使います。
3. 学習用の例を提供する
例を示すと、求めているものが具体的に伝わります。Copilot がパターンをすばやく理解できるので、最初の提案から的確になり、やり直しの回数が減ります。
この方法が特に効果的なのは、次のようなコードです。
- 定型的なコード
- テストのひな形
- 同じ形の繰り返しになる実装
4. アサートと反復
最初のプロンプトで、そのまま使えるコードが得られるとは限りません。それで問題ありません。最初の出力は、Copilot との対話の出発点として扱います。
最初の出力が期待と違ったときの進め方は、次のとおりです。
- 最初からやり直さない
- 提案されたコードを消す
- 最初のコメントに、詳細と例を書き足す
- もう一度、Copilot に提案させる
出力を自分の手で直すことに時間をかけるのではなく、プロンプトを改善して、もう一度提案させます。回数を重ねるごとに、求めているものが Copilot に正確に伝わるようになります。
例の与え方による 3 つの方法
プロンプトに例をいくつ含めるかによって、3 つの方法があります。
| 方法 | 英語 | 与える例の数 | 向いている場面 |
|---|---|---|---|
| ゼロショット学習 | Zero-shot learning | 0 個 | よくあるパターンや、標準的な機能を、すばやく実装する |
| ワンショット学習 | One-shot learning | 1 個 | 自分たちの書き方や決まりに合わせた、一貫した実装を作る |
| 少数ショット学習 | Few-shot learning | 複数 | 複数の場合分けや、特殊な条件を扱う、込み入った実装を作る |
このサイトでの補足
名前に「学習」と付いていますが、プロンプトに例を書いても、Copilot の AI モデルそのものが作り直されるわけではありません。その 1 回のやり取りの中で、例を手がかりにして提案を作る、という意味です。以下のコードの例も、このサイトで用意したものです。
ゼロショット
例を与えずに、してほしいことだけを書きます。Copilot は、もともとの学習の内容だけをもとに、コードを生成します。
# 摂氏の温度を華氏に変換する関数温度の変換のような、よく知られた処理であれば、このコメントだけで適切な関数が提案されることが期待できます。
ワンショット
例を 1 つ示してから、同じ形のものを依頼します。
# 摂氏の温度を華氏に変換する関数
def celsius_to_fahrenheit(celsius: float) -> float:
"""摂氏の温度を華氏に変換する。"""
return celsius * 9 / 5 + 32
# 同じ書き方で、華氏の温度を摂氏に変換する関数例にある関数名の付け方、型の書き方、説明文の書き方が、提案に反映されやすくなります。
少数ショット
例を複数示します。公式の教材では、この方法を、ゼロショットの「結果が予測しにくい」という弱点と、モデルを調整し直す方法(ファインチューニング)の精度との、中間にあるものと説明しています。
# 時刻に応じて、あいさつを返す関数
# 例:
# 6 時 -> "おはようございます"
# 13 時 -> "こんにちは"
# 20 時 -> "こんばんは"入力と出力の組を複数示すことで、場合分けの境目を、Copilot が読み取りやすくなります。
長い会話の扱い方
込み入った機能を作るときは、Copilot Chat とのやり取りが何往復にもなります。たとえば、次のように少しずつ依頼を重ねていく進め方を、連鎖プロンプト(chain prompting)といいます。
- ユーザー認証の関数を作る
- 認証情報が正しくない場合の、エラー処理を加える
- その関数の単体テストを加える
- 説明のコメントを加える
- 性能を改善する
それぞれの依頼は、それまでの会話を前提にしています。その一方で、会話の履歴は長くなっていきます。長い履歴を抱えたままのやり取りは、処理の面で非効率になり、コストも増えます。
効率よく進める方法として、次の 3 つが挙げられています。
| 方法 | 内容 |
|---|---|
| コンテキストを要約する | 会話が長くなったら、これまでの内容を短くまとめたうえで、次の依頼をする |
| リセットして、絞ったコンテキストを与える | 新しい機能に取りかかるときは、会話全体を引き継がず、必要な情報だけを伝えて新しく始める |
| 簡潔に参照する | 以前の実装の全文を繰り返さず、短い言葉で指し示す |
公式の教材には、会話の履歴をすべて含む長いプロンプトは、1 回のやり取りで 2〜3 PRU を消費することがあり、要約やリセットによって 1 PRU 程度に抑えられる、という説明があります。
役割を与える:ロールプロンプト
ロールプロンプト(role prompting)は、Copilot に、特定の分野の専門家として振る舞うように指示する方法です。専門的な分野で、生成されるコードの質と的確さを高められます。最初の提案から狙いに合ったものが得られやすくなり、やり直しの回数が減ります。
公式の教材は、3 つの役割を例に挙げています。
| 役割 | 指示の例 | 得られやすいコードの特徴 |
|---|---|---|
| セキュリティの専門家 | サイバーセキュリティの専門家として、よくある脆弱性を確認するパスワード検証の関数を作る | 入力の無害化、よくある攻撃への対策、業界標準の検証の方法、セキュリティのベストプラクティス |
| 性能の最適化の専門家 | 性能の最適化の専門家として、大量のデータを効率よく処理できるように、並べ替えの処理を書き直す | 最適化されたアルゴリズムとデータ構造、メモリの効率、規模の拡大への配慮、性能の監視の提案 |
| テストの専門家 | テストの専門家として、支払い処理の部品について、特殊な条件やエラーの場合も含めたテストを作る | 網羅的なテスト、特殊な条件の扱い、モック(テスト用の代役)の実装、エラーの条件のテスト |
悪い例と良い例
このサイトでの補足
この節は、公式の教材にはない、このサイト独自の例です。4 つの S を、具体的なプロンプトに当てはめています。
| 悪い例 | 問題点 | 良い例 |
|---|---|---|
| 「ユーザーの登録と、ログインと、パスワードの再設定を作って」 | 1 つのプロンプトに、3 つの作業が入っている(単一に反する) | 「メールアドレスとパスワードを受け取って、ユーザーを登録する関数を作って」 |
| 「データを処理する関数を書いて」 | 何を受け取って、何を返すのかが分からない(具体的に反する) | 「数値のリストを受け取って、平均より大きい値だけを返す Python の関数を書いて」 |
| 経緯や背景を長々と書いたあとに、依頼を書く | 要点が埋もれる(短くするに反する) | 必要な条件だけを、箇条書きで書く |
test.py や new1.py のようなファイル名で作業する | ファイル名から内容が伝わらない(周囲環境に反する) | user_registration.py のように、内容が分かる名前を付け、関連するファイルを開いておく |
訳語の違いに注意
日本語版の教材での表記です。試験では、英語とセットで覚えておくと安心です。
| 英語 | 日本語版の教材での表記 |
|---|---|
| Single / Specific / Short / Surround | 単一 / 具体的 / 短くする / 周囲環境 |
| Zero-shot / One-shot / Few-shot learning | ゼロショット学習 / ワンショット学習 / 少数ショット学習 |
| Assert and iterate | アサートと反復 |
| Chain prompting | 連鎖プロンプト |
| Role prompting | ロールプロンプト |
Few-shot は、「フューショット」と表記されることもあります。
まとめ
- プロンプトエンジニアリングとは、AI から望む結果を引き出せるように、明確な指示を作ることである。プロンプトの工夫で直接よくなるのは、提案の質である。
- 基本原則は 4 つの S。単一(Single)、具体的(Specific)、短くする(Short)、周囲環境(Surround)。
- ベストプラクティスは 4 つ。明瞭さの提供、コンテキストの提供、例の提供、アサートと反復。
- 例の数によって、ゼロショット(0 個)、ワンショット(1 個)、少数ショット(複数)の 3 つの方法がある。
- 会話が長くなったら、要約する、リセットする、簡潔に参照する。ロールプロンプトでは、専門家の役割を与える。
確認問題
このページの内容から作った、自作の問題です。実際の試験問題ではありません。選択肢を選んで「答えを確認する」を押すと、正解と解説が表示されます。
参考資料と確認の記録
- Introduction to prompt engineering with GitHub Copilot(Microsoft Learn)
- GitHub Copilot を使用したプロンプト エンジニアリングの概要(Microsoft Learn・日本語版)
- Study guide for Exam GH-300: GitHub Copilot(Microsoft Learn)
| 項目 | 内容 |
|---|---|
| 最終確認日 | 2026 年 10 月 10 日 |
| 検証の状況 | 公式の教材(英語版と日本語版)の「プロンプトエンジニアリングの基礎とベストプラクティス」の単元と、モジュールの評価の出題の範囲と照合した。「このサイトでの補足」と書いた部分、コードの例、確認問題は、このサイト独自の内容 |
| 変わる可能性がある内容 | PRU の消費量に関する説明。料金や利用量の仕組みは、プランや時期によって変わることがある |
| このページで扱っていない内容 | プロンプトが処理される流れと、コンテキストの決まり方は、別のページ(11、12)で扱う予定 |