プロンプトエンジニアリングは、特定の有用な結果を生むようAIへの指示を意図的に構成するプロセスです。AIツールとの気軽な会話とは異なり、適切に設計されたプロンプトは、各入力を設計課題として捉えます。モデルが知るべき情報は何か、出力をどの形式にするか、どの制約を課すかを考えます。
プロンプトエンジニアリングにプログラミング知識は必要ありません。本質的にはコミュニケーションの技法です。その論理は同僚への業務説明と似ています。タスク、文脈、期待する出力を正確に定義するほど、回答の関連性が高まります。
プロンプトは単なる質問ではありません。文脈、制約、例、書式指定といった任意の層を含められる指示です。各層の役割を理解すれば、一貫して質の高い結果を返すプロンプトを作れます。
AIへ作業を頼む前に、その役割、当てはまる状況、必要な背景情報を設定します。これが役割と文脈の設定です。
「この文書を要約して」というプロンプトでは、目的、読者、詳しさをモデルが推測しなければなりません。「あなたは非技術系の経営陣向けにエグゼクティブサマリーを書く上級アナリストです」と始めれば、その推測を完全に省けます。
同じタスクへの2つのアプローチを比べてみましょう。曖昧な例：「要約を書いて」。具体的な例：「この報告書の主要な調査結果を、技術知識のない一般読者向けに3文で要約してください。業務上の意思決定に関係する結果を重視してください」。
2つ目のプロンプトは、長さ、読者、語彙、範囲を定義しています。制約を1つ加えるたびに、モデルが目的から外れる余地が1つ減ります。
指定すると特に有用な制約には、長さ（語数または文数）、読者（技術系か非技術系か）、トーン（フォーマル、率直、会話調）、範囲（重視するセクションや話題）があります。
プロンプトエンジニアリングで最も信頼できる技法の1つは、求める出力例を提示することです。AI研究では、この手法を少数例プロンプティングと呼びます。
一方、ゼロショットプロンプティングでは、例を一切与えずモデルにタスクを実行させます。単純で明確に定義されたタスクには適していますが、求める形式が標準的でない場合は、一般的な出力になりがちです。
形式の指示は、回答をどう構成するかモデルに伝えます。指定しない場合、AIツールはその話題で最も一般的と思われる形式を選ぶため、ニーズに合わないことがあります。
-
場当たり的：「フォローアップメールを書いて」。
-
構造化：「初回ヒアリング後、顧客へ送る150語のフォローアップメールを書いてください。トーンは温かみがありながらプロフェッショナルに。話し合った3つの話題を要約し、明確な次の行動を1つ示して終えてください」。
-
場当たり的：「これを要約して」。
-
構造化：「技術知識のない業務担当副社長向けに、この調査報告書を要約してください。サプライチェーンの意思決定に最も関係する3つの結果を重視し、平易な言葉を使ってください」。
-
場当たり的：「アイデアを出して」。
-
構造化：「人事責任者を対象とするB2B SaaS製品のキャンペーン切り口を5つ挙げてください。それぞれ1文にし、コスト削減より時間短縮の訴求を優先してください」。
長い文書や複数の報告書を扱うアナリストは、AIの出力を絞るために制約を使います。「この論文の方法論セクションだけを、平易な言葉で100語に要約してください」と指示すれば、制約なしの要約では通常得られない、的を絞った結果になります。出力を有用にするのは制約です。
営業のフォローアップ、顧客向け進捗報告、社内説明など、コミュニケーションを繰り返す知識労働者は、再利用可能なプロンプトテンプレートを作ります。プロンプトの構造から有用な結果が安定して得られるようになれば、それを保存して再利用することで、毎回作り直す手間がなくなります。その投資効果は利用を重ねるほど積み上がります。
質問：プロンプトが機能しているか、どう判断すればよいですか？
回答：出力と実際に必要だったものを比較してください。残す部分より書き直す部分や捨てる部分の方が多ければ、プロンプトの指定が不十分です。多くの場合、文脈を増やす、制約を狭める、求める出力形式の例を示すことで改善できます。失敗した出力を診断情報として扱いましょう。