この 10 の実践は、モデルやタスクを問わず通用します。次のモデルのリリースで通用しなくなるかもしれない小技には、どれも頼っていません。それぞれに短い改善前・改善後の例を添えているので、変化がそのまま確認できます。
1. タスクを最初に置く
命令形の 1 文で始めます。その後に続くものはすべて、そのタスクを支えるものとして読まれます。
- 改善前：
I have a spreadsheet of expenses from last year. - 改善後：
Categorize the expenses below into travel, software, and office.
2. 範囲、対象読者、長さを具体的にする
あいまいな言葉は、判断をモデルに委ねてしまいます。実際の値に置き換えましょう。
- 改善前：
Write a short post about our new feature for users. - 改善後：
Write a 120-word announcement of scheduled exports for existing admins who already use manual exports.
3. サイズには数値を使う
「いくつか」「簡潔に」「詳しく」は実行のたびに意味が変わります。数値と単位を使えば、長さが予測できるようになります。
- 改善前：
Give me some ideas. - 改善後：
Give me 5 ideas, one sentence each.
4. 避けることだけでなく、すべきことを書く
禁止事項の一覧は、望まないことをすべて挙げますが、望むことは何も挙げません。それぞれの「〜しない」に、代わりに望む動作を組み合わせましょう。
- 改善前：
Don't be too formal. Don't use jargon. - 改善後：
Write in a conversational tone, using words a new customer would know.
5. 出力形式を指定する
構造を示し、機械が読む出力では正確なスキーマも示します。ほかに何も出力してほしくないときは「JSON のみを返す」と加えます。詳しくは構造化出力のプロンプトを参照してください。
6. 指示と入力を分ける
ドキュメント、ユーザーのメッセージ、変数を、XML 風のタグなどの明確な区切りで囲みます。そうすればモデルはデータと指示を区別でき、データ内の文が命令として実行される可能性も下がります。
Summarize the email in the tags below in 2 sentences.
<email>
{{email_body}}
</email>
7. 判断が必要な場面では例を示す
「良い」を定義するより見せるほうが簡単なときは、2〜3 個の例を含めます。例は多様にして、モデルが表面的な特徴ではなくパターンを学ぶようにします。フューショットプロンプティングを参照してください。
8. 長いプロンプトを構造化する
おおよそ 1 段落を超えたら、セクションを使いましょう。タスク、文脈、要件、出力形式、入力です。見出しがあると、モデルにとってプロンプトが追いやすくなり、人間にとっても安全に編集しやすくなります。
9. 答えを変えないものは取り除く
挨拶、丁寧表現、繰り返しの指示は、情報を増やさずにトークンだけを増やします。繰り返しは逆効果になることもあります。ほぼ同じ 2 つの文が少し違うと、モデルはどちらを意図したのか判断しなければなりません。
- 改善前：
Hi! Could you please make sure to really focus on accuracy? Please make sure to focus on accuracy. - 改善後：
Prioritize accuracy over completeness.
10. 実際の入力でテストし、結果を残す
代表的な入力で実行し、失敗の理由が分かって初めて、プロンプトは完成です。それらの入力をテストセットとして保存し、編集のたびに再実行しましょう。プロンプト評価を参照してください。
プロンプトの成果が思わしくないときに AI の応答を改善する方法
原因を可能性の高い順に確認します。
| 症状 | 考えられる原因 | 対策 |
|---|---|---|
| 実行のたびに答えが違う | 指定されていないサイズや形式 | 数値と出力形式を追加する |
| 一般的な答え | 文脈の不足 | 対象読者、分野、制約を追加する |
| 指示が無視される | 衝突、または長い段落に埋もれている | 衝突を解消し、リストに移す |
| トーンが違う | トーンの説明があいまい | トーンの例を示す |
| 作り話をする | 与えられていない事実を求めている | 元のテキストを渡し、引用を求める |
| 入力内のテキストに従う | 入力に区切りがない | 入力をタグで囲む |
自動でチェックする
これらの実践の多くは、モデルを実行しなくても確認できます。PromptFlowEngine のプロンプトアナライザーは、目的の欠落、あいまいな表現、数量化されていないサイズ、否定だけの制約、出力形式の欠落、区切りのない変数、冗長な表現を指摘し、それぞれの指摘を、修正例付きのリファレンスページにリンクします。プロンプトオプティマイザーは実践 8 と 9 を代わりに適用し、要件が失われていないことを検証します。
次は、これらの実践が防ぐことを目的としたプロンプトエンジニアリングのよくある間違いを読みましょう。