プロンプト設計の基本原則

#プロンプトの基本構成

良いプロンプトは、だいたい次の要素でできている。すべてを毎回書く必要はないが、結果が不安定なときはどれが欠けているかを疑う。

悪い例:

この文章を良くして

良い例:

以下のメール文を、取引先への謝罪メールとして適切な敬語に直してください。
- 冒頭で謝罪、次に原因、最後に再発防止策の順
- 300字以内
- 言い訳に聞こえる表現は避ける

「良くする」「いい感じに」はモデルの解釈次第で結果がぶれる。何をどう変えたいか を書く。

同じ「要約して」でも、経営者向けの1行サマリーと、エンジニア向けの技術要約はまったく違う。誰が・何のために読むか を書くだけで品質が大きく変わる。

長い入力は XML タグや区切り線で明示的に囲む。指示とデータが混ざるのを防ぎ、プロンプトインジェクションへの耐性も上がる。

次の <review> タグ内のレビューを分析し、感情（positive / negative / neutral）を判定してください。

<review>
（ここにレビュー本文）
</review>

後続処理に使うなら JSON、人が読むなら Markdown。形式を指定すると再現性が上がる。

以下のJSON形式のみで回答してください。説明文は不要です。
{"sentiment": "positive" | "negative" | "neutral", "reason": "20字以内"}

API利用なら「構造化出力（JSON Schema 指定）」機能を使う方が確実。

言葉で説明しにくいトーンや形式は、実例を2〜3個 見せるのが最も効く。例は多様で、望ましい出力の代表になるものを選ぶ。

複雑な判断は、いきなり答えを求めず段階を踏ませる。

資料に書かれていないことは「資料に記載なし」と答えてください。推測で補わないでください。

これだけでハルシネーションがかなり減る。

システムプロンプトが長くなるときは、見出しや箇条書きで整理する。優先順位が重要なら「最も重要なルール」を先頭に置く。

一度に全部盛り込むより、失敗を見てから足す 方が結果的に短く安定したプロンプトになる。