チャットで AI に「うまく聞く」コツと、アプリの中に組み込むプロンプトを「壊れないように書く」設計は、まったくの別物です。前者は1回うまくいけば十分ですが、後者は何万回呼んでも同じ品質で動き、想定外の入力でも崩れず、結果を機械的に検証できることが求められます。この章では、対話術ではなく開発者のためのプロンプト設計の基本原則を、実例とともに整理します。
FIG.1 対話は「1回の最適化」、アプリ組込みは「何度呼んでも崩れない設計」
アプリのプロンプトは、ユーザーごと・入力ごとに毎回その場で書くものではなく、コードと同じ資産として一度書いて固定し、繰り返し使います。だからこそ「たまたま動いた」では困る。設計の軸は再現性・堅牢性・検証可能性の3つです。
015つの基本原則
アプリに組み込むプロンプトは、次の5点を冒頭で固定すると安定します。順番にも意味があり、上から「何をする人か」「どんな形で返すか」「具体例」「入力の隔離」「失敗時の振る舞い」と積み上げます。
役割と制約を明示する
「あなたは○○をするアシスタントです。△△はしません」と冒頭で固定。何をする／しないを先に決めると、想定外の脱線が減ります。役割が具体的なほど出力は安定します。
出力形式を規定する
自由文で受けると後段のプログラムが壊れます。JSON など決まった構造で返させ、キー名・型・必須項目まで指定します（詳細は 02 章）。
例示する（few-shot）
良い例・悪い例を1〜数個見せると、言葉で説明しきれない挙動が安定します。境界ケース（空入力・曖昧な入力）の例を入れると効果的です。
入力と指示を分離する
ユーザーが入れた文字列を指示文に直接つなげない。データとして隔離することがインジェクション対策の土台です（詳細は 03 章）。
失敗時の振る舞いを決める
根拠が無い・判断できないときは、それらしく作文させず「不明」「該当なし」と返させる。知らないことを知らないと言えるプロンプトは事故が少ない。
アプリのプロンプトは「うまい質問」ではなく、仕様書として書く。
02出力形式の規定：構造で受ける
アプリで一番よく壊れるのが出力の扱いです。「カテゴリを答えて」と頼むと、ある時は「ポジティブ」、別の時は「これはポジティブな内容ですね😊」と返ってくる——後段のプログラムはこの揺れを吸収できません。だから自由文ではなく構造（JSON など）で受けます。
2026年時点では、出力の安定化に大きく分けて3つの段階があります。下にいくほど信頼性が高く、本番で構造を扱うなら最下段を前提にするのが安全です。
