レビュー 中級 約5分

例で判断基準をそろえるプロンプト

説明だけで伝わらない好みや基準を、採用例と避けたい例で渡す

Use cases
4場面
Variations
3通り
Sources
2件
Ready to use

今日のプロンプト

あなたは、私の作業基準を読み取り、同じ基準で新しい入力を判断する編集者です。

次の例から、先に判断基準を3から5個に要約してください。
その基準を使って、最後の対象をレビューし、必要なら修正版を出してください。
例にないことは勝手に一般化せず、不明な基準は「確認したいこと」に分けてください。

<adopt_examples>
採用したい例:
- <ここに良い例を入れる>
- <ここに別の良い例を入れる>
</adopt_examples>

<avoid_examples>
避けたい例:
- <ここに避けたい例を入れる>
- <ここに別の避けたい例を入れる>
</avoid_examples>

<edge_examples>
境界例:
- <迷う例や、条件付きで採用する例を入れる>
</edge_examples>

対象:
<ここに見てもらいたい文章、企画、レビューコメント、調査メモなどを入れる>

出力形式:
1. 例から読み取った判断基準
2. 対象への判定
3. 修正版
4. 確認したいこと

使いどころ

AIに「この感じで直して」と頼んだのに、返ってきた文章が少しだけ違う。そんな場面はかなり多いです。問題は、AIが不親切というより、人間側の「この感じ」が言葉になっていないことにあります。文章の温度感、レビューの厳しさ、調査メモの粒度は、説明だけより例のほうが伝わりやすいです。この型では、採用したい例、避けたい例、境界例を渡し、AIに基準を読み取らせてから作業に入ってもらいます。

  • 文章レビュー
  • 企画の壁打ち
  • 調査メモ整理
  • チーム内の基準共有

この形にした理由

  • 言葉だけで基準を説明すると、丁寧さ、強さ、粒度の解釈が人によってずれます。例を先に置くことで、AIが出力のトーンや構造を具体的に拾いやすくなります。
  • 採用したい例だけでなく避けたい例と境界例を入れるため、表面的な型だけをまねる状態を減らせます。何を残し、何を避けるかが見えると、レビュー結果も確認しやすくなります。
  • AIにいきなり修正させず、先に判断基準を言語化させるので、人間がその基準を見直してから使えます。責任をAIへ丸投げせず、基準を一緒に整える使い方になります。

公式ガイドと照らしたメモ

OpenAI

few-shotで入出力の型を伝える設計

OpenAIのPrompt engineering guideは、少数の入出力例をプロンプトに含めることで新しいタスクの進め方を示せると説明しています。さらに、例は多様な入力と望ましい出力を見せるのがよいとされています。この型は、良い例だけに寄せず、避けたい例と境界例も置いて判断基準を安定させます。

Anthropic

例で形式、トーン、構造をそろえる設計

AnthropicのClaude prompting best practicesは、例が出力形式、トーン、構造を導く信頼しやすい方法だとしています。例は実際のユースケースに近く、多様で、タグなどで構造化されていることが推奨されています。この型では、例を種類ごとにタグで分け、AIが指示と例を混同しにくい形にしています。

場面に合わせた直し方

文章レビュー

採用したい例には、自分が自然だと感じる文体を入れます。避けたい例には、硬すぎる表現、AIっぽい一般論、読者を置いていく言い回しを入れると調整しやすくなります。

コードレビュー

採用したい例には、理由と影響範囲が書かれたレビューコメントを入れます。避けたい例には、好みだけに見える指摘や、修正方針が伝わらない短文を入れます。

調査メモ

採用したい例には、根拠、限界、次に確認することが分かれているメモを入れます。避けたい例には、要約だけで判断材料が残らないメモを入れます。

使う前に見ること

  • 例が1つだけだと、その例の表面的な癖まで強く引っ張られます。最低でも採用例を2つ、避けたい例を1つ置くと扱いやすくなります。
  • 実データを入れるときは、顧客名、個人情報、社内だけの事情を伏せてから使います。基準を伝えるための例なので、機密情報そのものを渡す必要はありません。
  • AIが読み取った判断基準は、作業前に一度見直します。そこがずれているなら、対象の修正結果もずれるためです。

参考資料

Loading...