業務効率を変えるプロンプトエンジニアリングの基本
まず押さえたいことプロンプトエンジニアリングとは、AIから意図した回答を引き出すために、指示（プロンプト）の前提・制約・出力形式・例外時の扱いを設計することです。
この記事の要点
再現しやすいプロンプトは「目的・制約・入力・出力形式・例外処理」を明示します。出力を他システムへ渡す場合は、文章で形式を頼まずスキーマで指定する構造化出力を使います。長い資料は先に置き、指示を最後に書き、根拠となった箇所を示させます。テンプレートは最終確認日と管理者を決めて共有し、モデルの更新時は同じ入力で結果を比較してから移行します。
この記事でわかること
- 業務プロンプトが失敗する理由（曖昧・長文・責任不在）
- 基本テンプレ（コピペ可）
- 品質を上げる技法（例：役割、制約、出力形式）
- 出力を機械的に扱う：構造化出力
- 長い資料を渡すときの組み立て方
- 思考の手順を指定する／モデルごとの作法
- 例外処理とHuman-in-the-loop（レビュー設計）
- 部門展開（テンプレの運用・教育）
- よくあるNGと改善例
- チェックリスト（安定運用）
業務プロンプトが失敗する理由（曖昧・長文・責任不在）
「AIが使える人」と「使えない人」の差は、実は「国語力（指示の具体性）」にあります。失敗するプロンプトには共通点があります。
- 曖昧な指示：「いい感じにまとめて」→ AIは何を優先すべきか分からない。
- 文脈の欠如：「このメールに返信して」→ 誰として？どんなトーンで？断るのか承諾するのか？
- 条件の後出し：「あ、やっぱ要約は300文字以内で」「箇条書きにしてほしかった」→ 何度もやり直しが発生し、結局自分でやった方が早くなる。
これらを解決するのが、次に紹介する「基本テンプレート」です。
基本テンプレ（コピペ可）
次の形式をテンプレートとして登録し、案件ごとの情報を埋めると、指示の漏れと担当者による出力差を減らせます。
① 【汎用】タスク実行型
# 命令
あなたはプロの[役割を入れてください]です。
以下の[制約条件]を守り、[入力文]を元に、[目的]を達成する成果物を作成してください。
# 制約条件
- 文字数：[xxx]文字程度
- トーン：[丁寧／親しみやすく／論理的]
- 出力形式：[Markdown箇条書き／プレーンテキスト]
- 禁止事項：[専門用語を使わない／推測を含めない]
# 入力文
[ここにメール本文や議事録をペースト]
# 出力文
② 【要約】議事録・ドキュメント整理型
# 命令
以下のテキストは[会議の文字起こし]です。
内容を要約し、決定事項とネクストアクションを抽出してください。
# 出力フォーマット
## 会議の概要（3行）
[ここに概要]
## 決定事項
- [決定したこと]
- [決定したこと]
## ネクストアクション（担当者・期限）
- [タスク]: [担当名] ([YYYY/MM/DD])
# 入力テキスト
[ここにテキストをペースト]
品質を上げる技法（例：役割、制約、出力形式）
プロンプトエンジニアリングにはいくつかの「定石」があります。
- Persona（役割付与）：「あなたは熟練のマーケターです」と定義する方法です。専門用語の選び方や説明の粒度が変わる一方、事実の正確さが上がるとは限らないため、正確さは後述の根拠提示や検証で担保します。
- Few-Shot（例示）：やってほしいことの「実例」を1〜2個見せます。「例：Aと言われたらBと返す」と示すのが、説明を重ねるより早く意図が伝わる場合が多い方法です。
- Output Control（出力形式指定）：「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（検索拡張生成）で必要箇所だけを渡す構成に切り替えます。
資料が長くなるほど、途中の記述が結果に反映されにくくなる傾向があります。重要な条件は資料本文に埋め込むだけでなく、末尾の指示にも書き出しておくと安定します。
思考の手順を指定する／モデルごとの作法
判断を伴う作業では、結論だけを求めるより手順を分けて指示するほうが安定します。「まず条件を列挙し、次に各条件への適合を確認し、最後に結論を述べてください」のように、確認の順序を書き出す方法です。
ただし、この書き方の効きはモデルの種類によって変わります。
| モデルの種類 | プロンプトの書き方 |
|---|---|
| 標準的な対話モデル | 手順を明示的に指定すると精度が上がりやすい。例示（Few-Shot）も有効。 |
| 推論に特化したモデル | 内部で手順を組み立てるため、細かい手順指定は不要な場合が多い。目的と制約、完成条件を簡潔に伝えるほうが結果が良いことがある。 |
モデルは更新されるため、特定モデル向けに作り込んだプロンプトは移行時に作り直しが必要になります。プロンプト本文には業務上の条件だけを書き、モデル固有の書き方は最小限にとどめると、乗り換えの負担を抑えられます。切り替えの際は、過去の入力と期待する出力を数件用意し、同じ入力で結果を比較してから移行します。
例外処理とHuman-in-the-loop（レビュー設計）
業務プロンプトで忘れがちなのが「分からない時どうするか」の指示です。
情報が不足していて回答できない場合は、無理に答えず「情報不足」と答えてください。
この一行（例外処理）を加えると、資料に書かれていない内容を推測で埋める挙動を抑えられます。ただし完全になくなるわけではないため、根拠の提示とあわせて使います。
Human-in-the-loopの観点では、AIの出力をそのまま社外に出すのはNGです。「人間がレビューして微修正する」工程を業務フローに組み込みます。
部門展開（テンプレの運用・教育）
個人の生産性が上がったら、次はチーム展開です。
- プロンプト集の共有：Notionや社内Wikiに「成功したプロンプト」をライブラリ化します。
- 変数の明確化：どこを書き換えればいいか（[ ]や{ }）を分かりやすくします。
- 品質の定義：「AIが作るのは下書きまでで、事実確認と最終判断は人が行う」という前提をテンプレートに明記し、期待値を揃えます。
- 更新の担当を決める：モデルの更新や業務の変更でテンプレートは陳腐化します。プロンプト集に最終確認日と管理者を記載し、定期的に見直します。
よくあるNGと改善例
曖昧な指示を、確認可能な条件へ書き換える例です。
× NG例
この障害について社内向けの報告文を書いて。
→ 宛先は？どこまで書く？原因が未確定なことをどう扱う？資料にない事実を推測で補われる。
◎ 改善例
以下の障害記録をもとに、全社向けの第一報を400字以内で作成してください。含める項目は「影響範囲」「現在の状況」「次の連絡予定時刻」の3点です。原因が特定できていない項目には「調査中」と記載し、記録にない内容は追加しないでください。
→ 宛先、文字数、項目、未確定情報の扱いが指定されている。出力を確認する基準も明確になる。
チェックリスト（安定運用）
最後に、業務プロンプトを作成する際のチェックリストです。
押さえておきたい点
自社の状況を確認する
- □ AIへの「役割（あなたは◯◯）」は定義したか
- □ ターゲット読者や利用シーンを伝えているか
- □ 守るべき「制約条件（文字数、トーン）」は明示したか
- □ 「やってはいけないこと（禁止事項）」は書いたか
- □ 期待する「出力形式（表、箇条書き）」を指定したか
- □ 情報不足時の対応（「分かりません」と言う等）を指示したか
- □ 具体的な「例（Few-Shot）」を含めているか
- □ 一回で複雑なことをさせず、ステップに分けて指示しているか
- □ 個人情報や機密情報を入力しないよう注意書きを入れたか
- □ 出力結果に対する人間のレビュー工程を確保しているか
よくある質問
Q. 同じプロンプトなのに日によって回答が変わるのはなぜですか？
LLM（生成AI）は確率モデルで次の単語を予測しているため、出力に揺らぎ（Temperature）が生じます。回答を安定させたい場合は、Few-Shot（例示）を増やしたり、出力フォーマットを厳格に指定する必要があります。
Q. システムプロンプトとユーザープロンプトの違いは何ですか？
システムプロンプトはAIの「役割や守るべきルール」を定義する前提条件であり、ユーザープロンプトは「今回やってほしい具体的なタスクや入力データ」を指します。役割分担させることで精度が安定します。
AIを、管理できる業務として運用する。
対象業務、入力データ、人による確認、評価方法から設計します。
生成AIを業務へ組み込む方法：対象業務の選定から運用まで
この分野の全体像と判断の順序をまとめた記事です。