実例

プロンプトエンジニアリングの実例20選:改善前と改善後

2026年9月更新 · 約12分で読めます

期待外れのプロンプトと役に立つプロンプトの差は、たいてい背景を伝える2文と1つの制約です。よくある入力と、役に立つ回答を引き出す入力を20組紹介します。それぞれ、何を変えたかも説明します。

この例の読み方

以下の各組は同じ依頼を2通りで示しています。よくある入力と、役に立つ回答を得られる入力です。その下に、変えた点を一言で説明しています。目的は20個のプロンプトを集めることではありません。同じ4〜5つの工夫を20回見ることで、自然に使えるようになることです。

その工夫はプロンプトエンジニアリング完全ガイドで説明しています。モデルに役割を与え、推測できない背景、具体的な作業を1つ、実際の制約、欲しい出力形式を伝えます。以下の例で確認してください。

メールとメッセージ

1. 会議を断る

改善前

会議を断るメールを書いて

改善後

今後も関係を続けたい顧客から、90分のワークショップに招待されました。短い断りの返信を書いてください。理由は忙しいからではなく、議題に対して私のチームが貢献できないからです。代案は1つだけ、意思決定の担当者との20分の通話を提案してください。温かみがあり、謝りすぎない文面で、80語未満。感嘆符は使わないでください。

変えた点:本当の理由を伝えました。「会議を断る」理由は何通りもあり、モデルが違う理由を選ぶことがあります。理由を明示すれば、選び間違いを防げます。

2. 未払いの請求を催促する

改善前

請求書について丁寧に催促して

改善後

支払期限から18日過ぎた4,200ユーロの請求書について、2回目の催促を書いてください。2年間取引があり、今後も関係を続けたい顧客です。1回目の催促には返信がありません。毅然としつつ、嫌味な言い方は避け、まだ強い措置を示唆する表現は使わないでください。回答が必要な質問を1つ、はっきり尋ねてください。90語未満。

変えた点:重要度とこれまでの経緯です。最初の催促と2回目の催促は別のメールです。穏やかなお願いだけで済むのは最初のほうです。

3. 同僚にやり直しを頼む

改善前

仕事をやり直してほしいと伝えるのを手伝って

改善後

チームのデザイナーに送るSlackメッセージを書いてください。納品された画面は出来はよいのですが、依頼とは別の課題を解決しています。依頼が曖昧だった私にも責任があります。今週中にやり直してもらう必要があります。依頼内容への責任を認め、問題を具体的に伝え、表現を和らげすぎて曖昧にしないでください。最大4文。

変えた点:メッセージの感情面です。「率直に」と「優しく」はぶつかることがあるので、それぞれをどの部分に適用するか伝えています。

4. 顧客に遅延を知らせる

改善前

遅延のお詫びを書いて

改善後

3月に公開すると発表した機能が5月に延期されることを、アプリ内でユーザーに知らせる文章を書いてください。理由はテスト中にデータ消失の不具合が見つかり、未解決のまま公開しないと決めたためです。読み手は機能を待ち望み、公の場でもそう表明している人たちです。新しい日程を最初に伝え、本当の理由を1文で説明してください。企業的な曖昧表現や「ご理解とご協力に感謝します」は使わないでください。70語未満。

変えた点:使ってほしくない表現を指定しました。不要な決まり文句を挙げると、肯定的な指示を重ねるより余計な言葉を削れます。

文章作成と編集

5. 段落を短くする

改善前

これを短くして

改善後

以下の段落を半分程度にしてください。事実と数字はすべて残してください。副詞、曖昧な表現、直前の文を言い換えただけの文を削ってください。私の語彙を堅い言葉に変えず、短縮形も残してください。短くした文章だけを示してください。

変えた点:「短く」に目標と、削ってよいもの・残すもののルールを加えました。制約がないと、モデルは書き手らしさをなくして短くしがちです。

6. 人柄が伝わる自己紹介にする

改善前

linkedinの自己紹介を書いて、バックエンド開発者です

改善後

私のLinkedInの概要を書いてください。バックエンド開発歴6年で、主にGoとPostgresを使い、現在は中規模のフィンテック企業で決済基盤を担当しています。本当に得意なのは、遅いシステムを速く、そして地味に安定させることです。読み手は人材紹介担当者ではなく、採用する側のマネージャーです。一人称、短い3段落。「情熱的」「成果志向」は使わず、形容詞の羅列ではなく具体例を1つ入れてください。

変えた点:少し独特で具体的な情報を1つ加えました。「遅いシステムを速く、地味に安定させる」はありきたりな自己紹介では出てこない表現で、よい自己紹介の軸になります。

7. メモを読みやすくまとめる

改善前

この会議メモを整理して

改善後

以下は顧客との通話中に取ったメモです。参加していない同僚向けの要約にしてください。構成は、顧客が望むこと、現在の代替手段、切り替えるために必要な条件、未解決の質問です。メモにない内容を加えないでください。不明な点は推測せず、未解決の質問に入れてください。

変えた点:作り話を防ぐ条件です。要約は、情報の穴をもっともらしく埋めて失敗しがちです。不明な点を置く場所を用意すれば防げます。

調査と学習

8. 相手の知識に合わせて説明する

改善前

kubernetesについて説明して

改善後

Docker Composeでサービスを公開した経験はありますが、オーケストレーターは使ったことがないバックエンド開発者に、Kubernetesが実際に何をするのか説明してください。構造ではなく、解決する課題から始めてください。全体を通して同じ例を1つ使ってください。サービスが50個以上になって初めて必要になる話は省いてください。400語未満。

変えた点:読み手を、その人がすでに知っていることで定義しました。「Xを説明して」には、誰が聞いているかわかるまで正解がありません。

9. 2つの選択肢を比較する

改善前

postgresとmongodbどっちがいい

改善後

予約サービスを開発しています。リレーションを使う読み取りが多く、強い整合性が必要です。チームは2人で、SQL経験はありますがNoSQL経験はありません。この条件でPostgresとMongoDBを、データモデルの適合性、整合性、2人での運用負担、採用の観点から表で比較してください。その後、一方を2文で推薦し、その選択に反対する最も強い理由を挙げてください。

変えた点:「どちらがよい」を「この用途ではどちらがよい」に変えました。反論を求めることで、比較が結論の後付け説明になるのを防げます。

10. 続けられる学習計画を立てる

改善前

スペイン語の勉強を手伝って

改善後

12週間のスペイン語学習計画を作ってください。現在はメニューが読め、ゆっくりした会話は理解できますが、話そうとすると固まります。平日は30分、日曜日は1時間使えます。目標はクリスマスにパートナーの家族と、英語に切り替えず10分会話することです。会話練習を多めにしてください。第1週は詳しく、残りの11週はそれぞれ1行で示してください。

変えた点:期限付きの目標と苦手な点を明示しました。最後の指示で、第2週より先を誰も読まないような12週間分の長文も防いでいます。

計画と意思決定

11. 現実の選択を検討する

改善前

転職のオファーを受けるべき?

改善後

転職のオファーを検討するのを手伝ってください。現職はシニア開発者で、安定していてチームはよいのですが、退屈しています。オファーは30人のスタートアップのスタッフ職で、給与15%増、資金は18か月分、面接で会った上司には好印象でした。住宅ローンがあり、扶養家族はいません。決める前に確認すべきで、まだ聞いていなさそうなことを挙げ、その後、それぞれの選択を支持する最も強い理由を2つずつ示してください。推薦は不要です。答えではなく、考えるための問いが欲しいです。

変えた点:モデルが果たす役割を伝えました。推薦を断ることで、助言を役に立つ判断材料に変えています。

12. 難しい話し合いに備える

改善前

どうやって昇給を頼めばいい?

改善後

昇給の相談に備えたいです。2つの給与調査によると、私の給与は同じ職種の相場より20%低いです。在籍3年で、インフラ費を3分の1削減した移行を主導しました。上司は協力的ですが、予算の決定権はありません。話の切り出し方、最も予想される反論2つとそれぞれへの返答、そして言うべきでない一言を示してください。

変えた点:交渉の具体的な強みと障害を示しました。最後の依頼が、自分では書けなかった内容を引き出します。

13. 目標を1週間の行動にする

改善前

もっと生産的になりたい

改善後

まだユーザーがいない個人プロジェクトを公開したいです。平日の夜を合わせて週8時間ほど使えます。失敗のパターンは、人に話を聞く代わりにランディングページを作り直してしまうことです。避けている行動を多めにして、1週間の具体的な作業と所要時間を示してください。また、逃避を防ぐルールを1つください。

変えた点:自分の失敗パターンを伝えました。一般的な生産性の助言は役に立ちませんが、その人がどうつまずくかがわかれば具体的になります。

コード

14. デバッグ

改善前

コードが遅いのはなぜ?

改善後

このエンドポイントは約2,000行のリストで4秒、50行では100ms未満かかります。PostgresとGoを使い、キャッシュ層はありません。user_idのインデックスが使われていることは確認済みです。この件数と速度の関係から考えられる原因を、可能性の高い順に3つ挙げてください。それぞれについて、原因かどうかを確かめるために何を測るべきか、具体的に示してください。まだコードは書き直さないでください。

変えた点:問題の現れ方と、除外済みの原因を伝えました。「まだ書き直さない」で、推測による修正ではなく診断に集中させています。

15. 実のあるコードレビューを受ける

改善前

コードをレビューして

改善後

以下の関数を、信頼する同僚からのプルリクエストとしてレビューしてください。優先順位は、同時呼び出し時の正しさ、エラー処理、読みやすさの順です。スタイルと命名は無視してください。問題ごとに、該当行、何が壊れるか、問題を起こす具体的な入力を示してください。実際に問題がなければ、無理に探さず、そう言ってください。

変えた点:優先順位と、指摘がなくてもよいという許可です。最後の条件がないと、レビューのプロンプトは本当の問題がなくても何かを指摘しがちです。

16. 役に立つテストを書く

改善前

この関数の単体テストを書いて

改善後

以下の関数のテーブル駆動テストを書いてください。空の入力、要素1つ、キーの重複、長さ上限の境界値を網羅してください。通常の要素3つの正常系は省いてください。そのケースではほとんど問題が見つかりません。標準ライブラリだけを使い、各ケース名は入力ではなく、保証する振る舞いに基づいて付けてください。

変えた点:コードを知る人がテストケースを選びました。テスト作成のプロンプトは、指定しないと失敗しないケースに偏りがちです。

画像と音楽

17. 意図が伝わるポートレート

改善前

女性のポートレート

改善後

夜明けの港の防波堤にいる、風雨にさらされた60代の漁師の女性、塩のついた防水作業着、深い笑いじわ、カメラの向こうを見る視線、曇天の北大西洋の光、浅い被写界深度、85mmのポートレート写真、落ち着いた青とさび色 --ar 4:5 --stylize 250

変えた点:被写体、場所、光、構図、表現媒体の順に指定しました。画像モデルは前のほうにある言葉を重視するため、順序もプロンプトの一部です。

18. 商品写真

改善前

お店用のコーヒー袋の写真

改善後

淡いオーク材の上に立つマットなクラフト紙のコーヒー袋、正面のラベルをカメラに向ける、散らしたコーヒー豆、左の窓からの柔らかい光、柔らかな影が1つ、すっきりしたミニマルな演出、浅い被写界深度、商用商品写真 --ar 1:1 --style raw

変えた点:照明と置く面です。商品写真のプロンプトでは、この2つでほぼすべてが決まります。「コーヒー袋の写真」だけではどちらも伝わりません。

19. 文字を入れる画像

改善前

grand openingと書かれたポスター

改善後

ヴィンテージの活版印刷ポスター、上部3分の1に大きな細身のセリフ体大文字で「GRAND OPENING」、その下に小さなサンセリフ体で「Saturday 14th」、質感の見えるクリーム色の紙、深紅と黒の2色刷り、わずかな版ずれ --ar 2:3

変えた点:入れる文字を正確に引用し、位置を指定しました。文字を描けるモデルには、言葉、サイズ、配置を伝える必要があります。伝えなければ3つとも勝手に決められます。

20. 頭の中の音に近い曲

改善前

悲しいピアノ曲

改善後

スタイル:憂いのあるネオクラシカルピアノ、近接マイクで録音したフェルトピアノ、かすかな室内音、控えめなチェロの伴奏、ドラムなし、ルバート、62 BPM、親密で、解決しきらない余韻を残す響き。構成タグ付きの歌詞:[Intro] [Verse] [Chorus] [Bridge] [Outro]

変えた点:楽器編成、録音の質感、テンポです。「悲しいピアノ」は気分を示すだけです。残りの情報が、ありきたりではない特定の録音にします。

20の例に共通すること

改善後の例だけを読むと、同じ工夫が繰り返し出てきます。

枠組みを暗記する必要はありません。送信前に、作業だけを説明して状況を伝え忘れていないか、気づくことが大切です。

20の例を使う代わりに、キー1つで

Prompt AI Keyboardは、すでに入力した文章に役割、背景、制約、形式を加え、使うAIツールに合わせて整えます。入力中のアプリを離れる必要はありません。文法の修正、トーンの変更、翻訳、話した内容の音声入力もできます。

よくある質問

よいプロンプト例とは?

同じ依頼を改善前後で示し、何を変えたかがわかる例です。プロンプトだけでは、自分の用途に応用しにくいひな形で終わります。改善前後を比べれば、自分の作業にも使える工夫が身につきます。

優れたプロンプトに共通するものは?

自分しか知らない具体的な情報、明確な読み手、少なくとも1つの禁止事項、作り話をするより何も答えなくてよいという許可、そして出力形式です。弱いプロンプトの多くは、作業だけを説明し、状況を伝えていません。

このプロンプト例はChatGPT、Claude、Geminiでも使えますか?

はい。5つの要素はモデルを問わないので、ここにある例はどれでも使えます。そのうえでモデルごとの工夫を加えます。Claudeは構造を詳しく示すと効果的で、Geminiは非常に長い入力と明示的な出力形式が得意です。画像や音楽のモデルには、文章よりも描写を凝縮した語句が向いています。