プロンプト設計の基本|役割・制約・出力形式・例示の4要素で安定させる

「同じことを頼んでいるのに、日によって出力の質がばらつく」というのは、業務でLLMを使い始めた人が最初にぶつかる壁です。原因の多くはモデルの気まぐれではなく、指示の中に判断材料が足りないことにあります。この記事では、プロンプトを「役割・制約・出力形式・例示」の4要素に分解し、業務で再現性のある出力を得るための組み立て方を解説します。
全体像:4要素の役割
| 要素 | 何を伝えるか | 例 |
|---|---|---|
| 役割 | どの立場・専門性で答えるか | あなたは法人向けサービスの広報担当者です |
| 制約 | 守るべき条件・禁止事項 | 300字以内。専門用語には説明を付ける |
| 出力形式 | 構造・フォーマット | 見出し+箇条書き3点。表はMarkdown |
| 例示 | 期待する出力の見本 | 良い例と悪い例を1つずつ提示 |
4要素をすべて毎回書く必要はありません。ただし出力がぶれたとき、どの要素が欠けているかを点検する枠組みとして持っておくと、修正が速くなります。
役割:立場を与えると判断基準が定まる
「この文章を直して」と頼むのと、「あなたは初心者向け教材の編集者です。この文章を直して」と頼むのでは、修正の方向性が変わります。役割の指定は、文体・語彙・詳しさの水準といった、無数にある判断の基準を一括で伝えるショートカットです。実在の人物名ではなく、「経験豊富なカスタマーサポートの責任者」のように職能で書くのが扱いやすい形です。
制約:曖昧な形容詞を測れる条件に変える
出力がぶれる最大の原因は、「いい感じに」「簡潔に」「分かりやすく」といった、人によって解釈が異なる指示です。これらを測定可能な条件に置き換えます。
- 「簡潔に」ではなく「400字以内で」
- 「分かりやすく」ではなく「中学生にも伝わる語彙で。専門用語には一文の説明を付ける」
- 「丁寧に」ではなく「です・ます調。命令形は使わない」
禁止事項も有効です。「絵文字を使わない」「事実として確認できない数値を書かない」のように、やってほしくないことを明示すると、修正の手戻りが減ります。
出力形式:後工程から逆算する
生成された文章をそのまま使うことは少なく、多くの場合は資料に貼る・表計算に取り込むなどの後工程があります。後工程が決まっているなら、形式を最初から指定しましょう。
あなたは営業部門のアシスタントです。
以下の商談メモを読み、次の形式で出力してください。
## 要約
- 3行以内
## 決定事項
- 箇条書き。決定していない事項は「未決」と明記
## 次のアクション
| 担当 | 内容 | 期限 |
| --- | --- | --- |
制約:
- メモに書かれていない情報を補完しない
- 期限が不明な場合は「不明」と書く
このように構造を枠として渡すと、モデルは枠を埋める作業に集中でき、出力の形が毎回そろいます。「書かれていない情報を補完しない」という一文は、事実の捏造を抑えるうえでも効果的です。
あわせて読みたい
ハルシネーション対策の実務|検証フローの作り方と運用のコツ
例示:1つの見本は百の説明に勝る
条件を言葉で尽くすより、期待する出力の見本を1つ見せるほうが速いことは多くあります。過去に自分が書いた「理想の完成形」を例として貼り、「この例と同じ構成・温度感で書いてください」と頼む方法は、文体の再現に特に有効です。逆に「こういう書き方はしないでください」という悪い例を添えると、境界がさらに明確になります。
メモ
一発で決めない:書き直しの手順
プロンプト設計は一度で完成させるものではなく、出力を見て条件を足していく反復作業です。
- 1
最小限の指示で一度出す
まず粗く出して、モデルの解釈と自分の期待のずれを観察します。 - 2
ずれた箇所を条件に翻訳する
「文が硬すぎる」なら文体の制約を、「長すぎる」なら字数を追記します。感想ではなく条件として書くのがポイントです。 - 3
安定したらテンプレート化する
2〜3回使って安定したプロンプトは、可変部分を穴埋めにしてチームの共有フォルダに保存します。
よくある質問
長いプロンプトを書けば書くほど良くなりますか
モデルが変わったらプロンプトは書き直しですか
敬語で丁寧に頼むと出力は良くなりますか
英語で書いたほうがよいと聞きました
プロンプトをチームで共有する際の注意点はありますか
まとめ:次の一歩
プロンプト改善のチェックリスト
- 役割・制約・出力形式・例示のどれが欠けているか点検した
- 曖昧な形容詞を測れる条件に置き換えた
- 後工程に合わせた出力形式を指定した
- 書かれていない情報を補完しないよう明記した
- 安定したプロンプトをテンプレートとして共有した
プロンプト設計は、特別な呪文を覚える技術ではなく、仕事の依頼を明確にする技術です。部下や外注先に仕事を頼むときと同じ丁寧さで条件を書けば、出力は安定していきます。実際の業務での適用例として、議事録業務での使い方も参考にしてください。
あわせて読みたい
会議・議事録業務でのAI活用|文字起こしから要約・共有までの実務手順
出典・参考
関連する記事
ハルシネーション対策の実務|検証フローの作り方と運用のコツ
LLMがもっともらしい誤情報を生成するハルシネーションへの実務的な対策を解説します。発生をゼロにできない前提での検証フローの設計、用途別のチェックの深さ、プロンプトと仕組みでの抑制策をまとめます。
会議・議事録業務でのAI活用|文字起こしから要約・共有までの実務手順
議事録作成に生成AIを組み込む実務手順を解説します。録音・文字起こし・要約・確認・共有の各工程での使いどころ、精度を上げるプロンプトの型、録音や情報管理で守るべき注意点をまとめます。
生成AIの業務利用を始める前に決めること|社内ルールの作り方と最初の一歩
生成AIを業務で使い始める前に決めておきたい社内ルールを整理しました。対象範囲・入力してよい情報・確認フロー・責任の所在という4つの論点と、小さく始めて育てる運用の考え方をまとめます。


