業務効率を上げるプロンプトエンジニアリングの基本

AIから期待した回答を得られるかどうかは、指示がどれだけ具体的かに大きく左右されます。期待した回答が得られないプロンプトには、次のような共通点があります。

• 曖昧な指示：「いい感じにまとめて」と頼むと、AIは何を優先すればよいかが分かりません。
• 文脈の欠如：「このメールに返信して」だけでは、誰の立場で、どのような調子で書くのか、断るのか引き受けるのかが伝わりません。
• 条件の後出し：「要約は300文字以内で」「箇条書きにしてほしかった」と後から条件を足すと、やり直しが重なり、自分で書いたほうが早かったという結果になりがちです。

こうした抜けや後出しは、次の基本テンプレートを使うと減らせます。

次の形式をテンプレートとして登録し、案件ごとの情報を埋めると、指示の漏れと担当者による出力差を減らせます。

# 命令
あなたはプロの[役割を入れてください]です。
以下の[制約条件]を守り、[入力文]を元に、[目的]を達成する成果物を作成してください。

# 制約条件
- 文字数：[xxx]文字程度
- トーン：[丁寧 / 親しみやすく / 論理的]
- 出力形式：[Markdown箇条書き / プレーンテキスト]
- 禁止事項：[専門用語を使わない / 推測を含めない]

# 入力文
[ここにメール本文や議事録をペースト]

# 出力文

# 命令
以下のテキストは[会議の文字起こし]です。
内容を要約し、決定事項と次の対応を抽出してください。

# 出力形式
## 会議の概要（3行）
[ここに概要]

## 決定事項
- [決定したこと]
- [決定したこと]

## 次の対応（担当者・期限）
- [タスク]: [担当名] ([YYYY/MM/DD])

# 入力テキスト
[ここにテキストをペースト]

出力の質を上げるために、よく使われる書き方には次のようなものがあります。

• 役割を与える：「あなたは熟練のマーケターです」のように、AIの立場を決める方法です。言葉の選び方や説明の細かさは変わりますが、事実の正確さが上がるとは限りません。正確さは、後で説明する根拠の提示や確認で補います。
• 例を示す（Few-Shot）：してほしいことの例を1〜2個見せます。「Aと聞かれたらBと答える」のように示すと、説明を重ねるより早く意図が伝わることがよくあります。
• 出力の形式を指定する：「CSV形式で」「表にしてコードブロックに入れて」と指定すると、Excelへ貼り付けやすくなります。

出力を別のシステムへ渡す場合は、形式を文章で頼まず、スキーマ（項目名と型の定義）で指定します。主要なAIサービスのAPIには、出力を指定したJSON構造に従わせる機能（Structured Outputs、JSONモードなど）があります。

{
  "type": "object",
  "properties": {
    "company_name": { "type": "string" },
    "inquiry_type": { "type": "string", "enum": ["見積", "サポート", "採用", "その他"] },
    "urgency":      { "type": "string", "enum": ["高", "中", "低"] },
    "summary":      { "type": "string" }
  },
  "required": ["company_name", "inquiry_type", "urgency", "summary"]
}

「JSONで出力してください」と文章で頼む方法との違いは、受け取る側が形式を検証できる点にあります。項目の欠けや、想定外の値（enumにない分類）が混ざるのを防げるため、後続の処理でのエラーを減らせます。分類の選択肢を先に決めることは、業務の側で集計の切り口を決めることにもなります。

ただし、形式が正しくても、内容が正しいとは限りません。構造化出力で保証されるのは、urgencyが3つの選択肢のいずれかになることまでで、その判定が妥当かどうかは保証されません。重要な判断には人の確認工程を残します。

規程や仕様書など長い資料を読ませる場合は、指示の書き方に加えて、資料と指示をどこに置くかも結果に影響します。

• 資料を先、指示を後に置く：長い資料を渡すときは、資料本文を先に入れ、最後に「上記の資料に基づいて〜してください」と指示を置きます。指示が資料に埋もれるのを防げます。
• 資料の区切りを明示する：複数の文書を渡すときは、XMLタグ（<document title="就業規則">…</document>）などで区切ります。AIがどの記述をどの資料から引いたか判別しやすくなります。
• 引用箇所を書かせる：「回答の根拠となった箇所を、資料名と該当文とともに示してください」と指示します。根拠を示せない回答は、資料に書かれていない推測である可能性が高いと考えられます。
• 全文を毎回貼らない：同じ資料を繰り返し参照する運用なら、都度貼り付けるよりRAG（検索拡張生成）で必要箇所だけを渡す構成に切り替えます。

資料が長くなるほど、途中の記述が結果に反映されにくくなる傾向があります。重要な条件は、資料の本文に加えて末尾の指示にも書いておくと、結果が安定しやすくなります。

資料の確認から返信案の文書づくりまでを、AIエージェントに1つの作業として任せる場合の依頼文の例は、AIエージェントの始め方と活用例で紹介しています。

判断を伴う作業では、結論だけを求めるより手順を分けて指示するほうが安定します。「まず条件を列挙し、次に各条件への適合を確認し、最後に結論を述べてください」のように、確認の順序を書き出す方法です。

ただし、この書き方の効きはモデルの種類によって変わります。

モデルは更新されるため、特定モデル向けに作り込んだプロンプトは移行時に作り直しが必要になります。プロンプト本文には業務上の条件だけを書き、モデル固有の書き方は最小限にとどめると、乗り換えの負担を抑えられます。切り替えの際は、過去の入力と期待する出力を数件用意し、同じ入力で結果を比較してから移行します。

業務のプロンプトで書き忘れやすいのが、分からないときにどうするかの指示です。

情報が不足していて回答できない場合は、無理に答えず「情報不足」と答えてください。

この一行を加えると、資料に書かれていない内容を推測で埋める動きを抑えられます。ただし、推測が完全になくなるわけではないため、根拠の提示とあわせて使います。

AIの出力は、そのまま社外に出さないようにします。Human-in-the-loopの考え方に沿って、人が確認して必要な修正をする工程を、業務の流れに組み込みます。

個人で使って効果を確かめられたら、チームに広げます。

• プロンプト集の共有：うまくいったプロンプトを、Notionや社内Wikiにまとめて共有します。
• 書き換える箇所の明示：どこを書き換えればよいかを、[ ]や{ }で分かるようにします。
• 品質の定義：「AIが作るのは下書きまでで、事実確認と最終判断は人が行う」という前提をテンプレートに書き、AIに期待することを利用者の間でそろえます。
• 更新の担当を決める：モデルの更新や業務の変更で、テンプレートは古くなります。プロンプト集に最終確認日と管理者を記載し、定期的に見直します。

曖昧な指示を、確認可能な条件へ書き換える例です。

業務のプロンプトを作るときに確かめる項目です。