改善
中級
約5分
一度に一つだけ直して比べるプロンプト
うまくいかない理由を仮説にして、変更点を記録する
- Use cases
- 4場面
- Variations
- 4通り
- Sources
- 5件
Ready to use
今日のプロンプト
あなたは、AIへの依頼文を改善する編集者です。
以下の現行プロンプトを、いきなり全面改稿せず、1回につき1点だけ改善してください。
目的:
<このプロンプトで達成したいこと>
現行プロンプト:
<今使っているプロンプト>
困っている出力:
<実際に出た困りごと、または避けたい出力>
守りたいこと:
<変えたくない文体、制約、出力形式>
出力形式:
1. 失敗の原因仮説
2. 今回だけ変える1点
3. 変えない部分
4. 改善後のプロンプト
5. 比較に使う入力を3つ
6. うまくいったかを見る判定基準
7. 次回変える候補使いどころ
AIに頼む文章を直していると、つい全部盛りの改善をしたくなります。指示を増やし、例を足し、出力形式も変える。すると、次の回答がよくなっても、何が理由だったのかがわからなくなります。このプロンプトは、プロンプト改善を気合いの書き直しではなく、小さな変更と確認の流れにするための型です。
- 社内プロンプト集の改善
- 調査依頼の精度調整
- 文章生成の文体調整
- レビュー観点の固定化
この形にした理由
- 変更点を1つに絞るため、結果が変わった理由を追いやすくなります。
- 困っている出力と守りたいことを並べるので、直したい点だけでなく壊したくない点も残せます。
- 比較に使う入力と判定基準まで出すので、感覚だけで「良くなった」と判断しにくくなります。
- 次回変える候補を分けることで、改善作業をチームの記録として残せます。
公式ガイドと照らしたメモ
OpenAI
変更をテストとして扱う設計
OpenAIのPromptingガイドは、promptをアプリケーションコードのように扱い、公開時にテストや評価ケースを走らせる考え方を示しています。GPT-5.2のPrompting Guideでも、モデル変更とプロンプト変更を混ぜず、一度に一つ変えて測る流れが紹介されています。
OpenAI
仮説を立ててから直す設計
OpenAIのLLM accuracy guideでは、baselineを評価し、失敗理由を見てから次の最適化を選ぶ流れが示されています。この型では、失敗の原因仮説を先に出すため、ただ長い指示へ足し算する改善になりにくくなります。
Anthropic
成功条件と実測を先に置く設計
AnthropicのPrompt engineering overviewは、プロンプト改善の前提として、成功条件、実測方法、改善したい初稿を持つことを勧めています。この型は、その考え方を日常の文章作成や調査依頼にも持ち込める形にしています。
場面に合わせた直し方
文章作成
判定基準に、読み手が次に取れる行動、残したい温度感、削りたい曖昧表現を入れてください。
調査
比較に使う入力3つは、事実確認、反対意見、古い情報が混ざるケースにしてください。
レビュー
守りたいことに、既存ルール、検証方法、見落としたくないリスクを入れてください。
チーム運用
改善前後の差分と採用理由を、プロンプト集の更新メモとして短く残してください。
使う前に見ること
- 変更点を2つ以上入れると原因が追いにくくなります。文章量を増やす、例を足す、出力形式を変える、のどれか1つに絞ります。
- AIが出した改善案をそのまま採用せず、実際の入力で比べてから残します。
- モデル変更、推論の深さ、プロンプト変更を同時に動かすと比較が濁ります。