失敗しないCopilotの使い方｜思い通りの回答を引き出すプロンプト（指示）のコツ

失敗しないCopilotの使い方｜思い通りの回答を引き出す指示出しのコツ

Copilotを使ってみたものの、

• 「なんかピンとこない回答しか返ってこない」
• 「思ったのと違うコードを書かれてしまう」
• 「質問の意図をうまく汲み取ってもらえない」

と感じていないでしょうか。

原因の多くは「Copilotの性能」ではなく、「指示の出し方（プロンプトの書き方）」にあります。本記事では、Copilotから思い通りの回答を引き出すための具体的なコツを、失敗パターンと改善例を交えながら解説します。

1. Copilotは「雑な指示」だと本領を発揮できない

まず押さえておきたいのは、Copilotは曖昧な指示のままでは人間以上に誤解するということです。人間同士なら「まあ、こういうことだろう」と補ってくれる部分も、AIには伝わりません。

たとえば、次のような指示は典型的な失敗パターンです。

悪い例：
「このコードをよくしてください」
「バグを直して」
「いい感じにリファクタリングして」

これだけでは、Copilotは

• どこまで変更してよいのか
• 何を基準に「良い」と判断すればよいのか
• パフォーマンス優先なのか、可読性優先なのか

が分かりません。

Copilotを「賢い部下」として扱うのではなく、非常に優秀だがコンテキストが何もない外注先に仕事を依頼するつもりで指示を出すと、精度が一気に上がります。

2. 良い指示の基本フレームワーク「5要素」

Copilotへの指示（プロンプト）には、次の5要素を意識して盛り込みます。

1. 役割（ロール）：Copilotにどう振る舞ってほしいか
2. 目的：達成したいゴール
3. 前提情報：環境・制約・対象
4. 具体的なタスク：やってほしいこと
5. 出力フォーマット：どの形式で出してほしいか

これを「R-O-C-T-F（Role / Objective / Context / Task / Format）」のように覚えておくと便利です。

2-1. 5要素を含めた具体例

良い例：
「あなたはTypeScriptに精通したフロントエンドエンジニアです。（役割）
React + Viteプロジェクトで、フォーム入力のバリデーション処理を安全かつ読みやすくしたいです。（目的・前提）
以下のコードの問題点を指摘し、改善案のコードを提示してください。（タスク）
改善後のコードにはコメントを付けて、どこをどう直したか分かるように説明も書いてください。（フォーマット）」

このレベルまで指示を書けると、Copilotの出力品質は目に見えて変わります。

3. 「悪いプロンプト」と「良いプロンプト」の比較

3-1. コードレビューを依頼する場合

悪い例：

このコードレビューして

良い例：

あなたはシニアバックエンドエンジニアです。
これから貼るGoのコードは、APIのレスポンスをキャッシュするための処理です。
以下を満たす観点でコードレビューをしてください：
- パフォーマンス
- エラーハンドリング
- 可読性（変数名・関数分割）
- 競合状態が発生しないか

指摘は箇条書きで、<問題点> - <改善案> の形式で出力してください。
最後に、修正後のサンプルコードも提示してください。

<ここにコード>

観点やフォーマットまで指定することで、「欲しいレビュー結果」がかなり明確になります。

3-2. ドキュメント作成を依頼する場合

悪い例：

マニュアル作って

良い例：

あなたはテクニカルライターです。
社内エンジニア向けに、社内Copilot利用ガイドのマニュアルを作成したいです。
対象読者：Webエンジニア（3年目〜中堅）、Copilotの基礎は知っているが使いこなせていない人
目的：Copilotのプロンプト設計の基本と、やってはいけない使い方を理解してもらう

以下の構成で見出しと本文を作成してください：
1. はじめに
2. Copilotでできること・できないこと
3. 良いプロンプトと悪いプロンプトの例
4. チーム開発でCopilotを活用するときの注意点
5. まとめ

文体は「です・ます調」で、専門用語には簡単な補足も入れてください。

構成まで指定することで、最初から「使えるドラフト」が出てきやすくなります。

4. Copilotで失敗しがちなパターンと回避策

4-1. 一度に頼みすぎる

Copilotに「全部まとめてやって」と頼むと、回答が浅くなったり、どこから手を付ければいいのか分からない長文が返ってくることがあります。

悪い例：

このサービスの設計とDB設計とAPI仕様とテストケース、全部考えて

改善策： タスクを分割し、「ステップごと」に依頼します。

ステップ1：要求整理
ステップ2：APIの大まかな設計
ステップ3：DB設計
ステップ4：テスト観点の列挙

という形で、Copilotにも「まずはステップ1だけ回答してください」のように順番を指定すると、会話の質が大きく変わります。

4-2. 「正解を丸投げ」してしまう

Copilotは便利ですが、「考えることをやめて全部任せる」使い方は危険です。特にプログラミングでは、

• セキュリティ上の問題
• パフォーマンスの問題
• ビジネスロジックの取り違え

などを見落とすリスクがあります。

Copilotを「ドラフト生成ツール」と割り切り、

• 要件や仕様の整理
• サンプルコードの叩き台作成
• テストケースの漏れチェック

など、人間の判断が必須な部分の前後を支援させる意識で使うと、失敗を減らせます。

4-3. 前提を変えたのに、古い情報を引きずらせる

会話型のCopilotでは、過去のメッセージも文脈として残ります。そのため、途中で方針を変えたときは、前提をリセットする指示を明示的に入れましょう。

先ほどまでの前提は一度リセットしてください。
ここからは、Next.js 14 + App Router を前提として回答してください。

このように「これまでの話はいったん忘れて、今から新しい前提で話します」と伝えると、意図しない混ざり方を防げます。

5. Copilotに「考え方」まで説明させる

Copilotを単なる「答えを出すマシン」としてではなく、思考プロセスを外部化するパートナーとして使うと、理解も深まり、バグにも気づきやすくなります。

5-1. 思考プロセスを引き出すプロンプト例

あなたはシニアエンジニアです。
これから提示する要件をもとに、API設計を一緒に考えてください。

1. まず、要件から前提条件・制約を箇条書きで洗い出してください。
2. 次に、その前提から導かれるAPIエンドポイントの候補を挙げてください。
3. 最後に、候補の中からシンプルで拡張性の高い案を選び、その理由を説明してください。

まだ最終的な設計を確定させず、「考え方」「検討プロセス」を重視して回答してください。

このように、「答え」ではなく「考え方」を求めることで、自分の頭の中の整理にもつながります。

6. チーム開発でCopilotを使うときのコツ

個人だけでなくチームでCopilotを使う場合、「各自がバラバラな使い方をする」と、コードスタイルや設計方針が揺れてしまいます。以下のポイントを押さえておきましょう。

6-1. チームの「Copilot利用ルール」を決める

• どのレイヤーまでCopilotに書かせてもよいか（例：インフラ構成はNG、ユニットテストはOKなど）
• セキュリティに関わる処理は必ず人間がレビューする
• 生成コードには、必要に応じて「AI生成である」ことをコメントに残すか

といったルールを最低限決めておくと、トラブルを減らせます。

6-2. プロンプト自体を共有・蓄積する

「うまくいったプロンプト」は、ドキュメントや社内Notionなどにストックしておきましょう。たとえば、

• バグ調査依頼用プロンプト
• レビュー観点を洗い出すプロンプト
• テストケースを列挙させるプロンプト

をテンプレート化しておくと、新しくCopilotを使うメンバーもすぐに成果を出しやすくなります。

7. 今日から使えるCopilotプロンプトのテンプレ集

最後に、すぐに使える「Copilotに対する指示テンプレ」をいくつか紹介します。自分の環境や言語に合わせてカスタマイズしてみてください。

7-1. バグ調査テンプレ

あなたは熟練した◯◯言語のエンジニアです。
以下のコードで発生しているバグの原因を一緒に特定したいです。

【状況】
- やりたいこと：
- 実際の挙動：
- 期待する挙動：
- エラーメッセージ：

【コード】
<ここにコード>

1. 考えられる原因候補を3つ以上列挙してください。
2. それぞれについて、どのように切り分ければよいかを提案してください。
3. 有力だと思う原因については、修正サンプルコードも提示してください。

7-2. 既存コードの理解テンプレ

あなたは◯◯フレームワークに詳しいエンジニアです。
以下のコードの役割と処理の流れを理解したいです。

【コード】
<ここにコード>

1. このコード全体の目的を一文で説明してください。
2. 関数ごとに「入力」「出力」「副作用（外部への影響）」を整理してください。
3. 初見の開発者がハマりそうなポイントがあれば、注意点として列挙してください。

7-3. テストケース洗い出しテンプレ

あなたはテストエンジニアです。
以下の仕様に対して、単体テストケースを洗い出してください。

【仕様】
<ここに仕様やユーザーストーリー>

1. 正常系のテストケースを箇条書きで列挙してください。
2. 代表的な異常系・境界値のテストケースを箇条書きで列挙してください。
3. 見落としがちなテスト観点があれば教えてください。

出力は「テストID / 観点 / 入力 / 期待結果」のテーブル形式でお願いします。

8. まとめ：Copilotを「賢く使う人」が生き残る

Copilotを使いこなすうえで重要なのは、

• 雑な指示ではなく、目的・前提・フォーマットまで含めた具体的なプロンプトを書く
• 一度に頼みすぎず、ステップを分けて会話する
• 答えだけでなく「考え方」「観点」も引き出す
• チームで使うときはルールとテンプレを共有する

という4点です。

Copilotは、適切なプロンプトさえ与えれば、設計レビュー・コードレビュー・ドキュメント作成など、開発のあらゆる場面で強力な相棒になってくれます。本記事のテンプレートや考え方をベースに、ぜひ「自分のプロンプト集」を育てていってください。

この記事の内容とあわせて、以下の動画も参考になります。実際の画面を見ながら、失敗しないCopilotの使い方と指示出しのコツを学んでみてください。