【生成AI入門】プロンプトエンジニアリング上達法｜指示文の組み立て方と改善の手順をやさしく解説

「明確に指示する」「役割を与える」といった基本テクニックは知っているのに、いざ書くと思いどおりの出力にならない——そんな悩みはありませんか? この記事では、親記事で学んだテクニックの一歩先へ進み、「なぜプロンプトで結果が変わるのか」という原理と、プロンプトを部品から組み立てて改善していく実践手順を深掘りします。

📖 ひと言でいうと

プロンプトエンジニアリング (Prompt Engineering) とは、AIへの指示文(プロンプト)を設計・改善して、望む出力を安定して引き出す技術です。

例えるなら、料理のレシピ作りに似ています。一発で完璧なレシピを書ける人はいません。作って、味見して、調味料を少し変えて、また作る。この繰り返しで「誰が作っても同じ味になるレシピ」が完成します。プロンプトも同じで、書いて、試して、ずれを直す反復を通じて「毎回良い出力が返る指示文」に育てていくもの、と捉えるのが上達の近道です。

🖼 1枚でわかるプロンプトエンジニアリング実践

🔍 しっかり理解する

なぜプロンプトで出力が変わるのか——原理から理解する

親記事で見たとおり、大規模言語モデルは「与えられた文脈の続きとして最も自然な文章」を生成します。この原理をもう一歩踏み込むと、プロンプトの役割がはっきり見えてきます。

モデルは学習を通じて、実に多様な「文章の続け方」を身につけています。学術的な説明もできれば、くだけた雑談もでき、箇条書きの整理も契約書風の文体もできます。プロンプトとは、この膨大な引き出しの中から「今回はどの続け方をしてほしいか」を指定する絞り込みの装置なのです。「あなたは人事のベテランです」と書けば人事の文脈に合う続きが選ばれやすくなり、お手本を見せれば(Few-Shot、1-5参照)その形式に沿った続きが選ばれやすくなります。テクニックの数々は、すべて「文脈を絞り込む」という1つの原理の応用だと分かると、丸暗記から卒業できます。

逆に言えば、プロンプトに書いていないことは、モデルが学習データの「平均的な続け方」で勝手に埋めます。指示があいまいなときに無難で一般的な回答が返ってくるのは、モデルの手抜きではなく、絞り込み不足の当然の結果なのです。

プロンプトを6つの部品で組み立てる

上達の第一歩は、プロンプトを「1本の文章」ではなく「部品の組み合わせ」として捉えることです。代表的な部品は次の6つです。

部品	役割	記述例
役割	回答者の立場・視点を固定する	あなたは中小企業向けの採用コンサルタントです
背景	状況・目的・読み手を伝える	来月の会社説明会で学生に配る資料を作っています
指示	してほしい作業を動詞で明確に	会社の魅力を3点に整理してください
入力	作業対象のデータを渡す	対象の文章・資料をここに貼り付ける
形式	出力の型を指定する	各項目は見出し+2文の説明。全体で300字以内
制約	禁止事項・条件を示す	誇張表現は使わない。不明な点は不明と書く

毎回6部品すべてが必要なわけではありません。大切なのは、出力に不満があったとき「どの部品が欠けているか」を診断できることです。「的外れな内容が返る」なら背景が不足、「内容は良いが形が使えない」なら形式が不足、「余計なことまで書いてくる」なら制約が不足——このように、不満の種類と足すべき部品が対応しています。

改善サイクルを回す——プロンプトは「育てる」もの

部品を組み立てたら、次は改善の反復です。実務でのプロンプト作りは、次のサイクルで進めます。

コツは2つあります。第一に、一度にたくさん直さないこと。複数箇所を同時に変えると、どの修正が効いたのか分からなくなります。第二に、うまくいったように見えても数回試すこと。生成AIの出力は毎回揺らぐため、1回の成功はまぐれかもしれません。題材を変えて数回試し、安定して合格ラインを超えることを確認してからテンプレートとして保存します。ここまでやると、プロンプトは個人の思いつきから「チームで再利用できる資産」に変わります。

なお、改善サイクルを回すときは、扱う情報にも気を配りましょう。プロンプトには背景資料を貼り付けるほど出力が良くなりますが、個人情報や機密情報を安易に貼り付けてよいかは別問題です。サービスの規約や社内ルールを確認したうえで、必要なら固有名詞を伏せ字にするなどの配慮が求められます(詳しくは第3章で扱います)。

あわせて、限界の見極めも実践では重要です。何度改善しても改善しないときは、プロンプトの問題ではなく、モデルが知識を持っていない(知識カットオフ・社内情報)、あるいはタスクがモデルの苦手分野(厳密な計算など)である可能性があります。その場合の打ち手はプロンプトの推敲ではなく、資料を渡す・RAGやツール連携を使う(2-6参照)という仕組み側の対策です。「プロンプトで解ける問題か」を判断できることも、プロンプトエンジニアリングの技術のうちなのです。

💡 具体例で考える

カスタマーサポート部門のFさんは、問い合わせメールへの返信下書きをAIに作らせようとしました。1回目は「この問い合わせに返信を書いて」だけ。返ってきたのは、丁寧すぎて自社らしくない長文でした。Fさんは「形式と制約の不足」と診断し、2回目は「返信は3段落以内。冒頭でお詫び、次に原因、最後に対応策。過度な敬語は避ける」と追加。形は整いましたが、今度は原因の説明に事実と異なる推測が混ざりました。3回目は「原因は以下のメモにある内容だけを使い、メモにないことは書かない」と社内メモを貼り付けて制約を強化。ようやく実用レベルに達しました。Fさんは念のため過去の問い合わせ3件でも試して安定した品質を確認し、このプロンプトを部署のテンプレート集に登録しました。3回の反復それぞれで「どの部品が足りないか」を診断し、最後に複数の題材で検証した点が、上達の分かれ目です。いまでは新人も、テンプレートを土台に自分の案件へ合わせて微調整するだけで、一定品質の返信下書きを作れるようになっています。

⚠️ よくある誤解・つまずきポイント

📝 生成AIテストではこう出る

📚 まとめ