第5章：AIへの指示（プロンプト）設計
この章で作れる成果物
この章を読み終えると、次の成果物を作れる状態を目指します。
- 指示設計シート: 目的、読み手、意思決定点、前提、制約、依頼内容を1枚で整理したシート。
- context pack: AIに渡す資料、渡さない資料、用語、前提、除外情報、情報分類をまとめた入力パッケージ。
- output schema / acceptance criteria: 見出し、表、根拠欄、要確認欄、採用条件、差し戻し条件を定義した出力仕様。
- 改善指示ログ: 初回指示、AI出力、評価結果、修正指示、採用可否、再利用条件を残すログ。
本章では、プロンプトを「うまい言い回し」ではなく、業務成果物を安全に作るための作業指示パッケージとして扱います。第4章で作った問題設定メモと採否判断メモを前提に、AIへ何を依頼し、どの情報を渡し、どの形式で受け取り、どの基準で受け入れるかを設計します。
本章とAI活用の標準業務フロー
本章は、AI活用の標準業務フロー（1枚） のうち、主に次の工程に対応します。
- 1. タスク定義: 目的、読み手、意思決定点、期限、承認者を指示の前提にする。
- 2. 情報分類: AIに渡してよい情報、匿名化すべき情報、渡してはいけない情報を分ける。
- 3. 文脈設計: 利用資料、用語、前提、読み手の状況、除外情報を context pack にまとめる。
- 4. 出力仕様: 見出し、表、根拠欄、要確認欄、文字数、提出形式を output schema として定義する。
- 5. 手段選択: 通常生成で足りるか、検索 / retrieval、表やPDFの読み取り、tool use / function calling、MCP連携が必要かを判断する。
- 6. 生成: 初稿、複数案、反論、前提確認、要確認事項を出させる。
- 10. ログ化・再利用: 指示、出力、評価、改善理由、適用範囲、廃止条件を残す。
第6章以降で出力評価やリスク管理を扱う前に、この章では「評価しやすい出力が返るように依頼する」ための設計を行います。
5.1 この章で扱う業務課題
AIへの依頼がうまくいかないとき、原因はプロンプトの表現だけではありません。多くの場合、次の要素が不足しています。
- 何のための成果物かが曖昧で、読み手や意思決定点が見えない。
- AIに渡してよい情報と渡してはいけない情報が分かれていない。
- 参考資料、前提、用語、除外範囲が不足している。
- 出力形式が自由すぎて、評価や再利用がしにくい。
- 根拠欄、要確認欄、リスク欄がなく、採否判断に使えない。
- 初回出力をどう評価し、どの条件で差し戻すかが決まっていない。
本章の目的は、AIから「それらしい回答」を得ることではありません。業務で使える初稿、比較案、レビュー材料、差し戻し可能な成果物を得るために、指示を設計することです。
5.2 プロンプトを作業指示パッケージとして扱う
5.2.1 プロンプトは単独の質問ではない
本書では、プロンプトを次の要素を含む作業指示として扱います。
| 要素 | 役割 | 例 |
|---|---|---|
| task brief | 目的、読み手、意思決定点、期限、承認者を示す | 「営業部長が追加提案に進むか判断する」 |
| data classification | 入力してよい情報を定義する | 「顧客名は匿名化し、契約条件は入力しない」 |
| context design | 使う資料、前提、用語、除外情報を示す | 「前回議事録、提案骨子、社内FAQを使う」 |
| instruction | AIに実行してほしい作業を示す | 「1枚サマリーの構成案を3案作る」 |
| output schema | 出力形式を固定する | 「判断点 / 根拠候補 / リスク / 要確認」 |
| acceptance criteria | 採用条件と差し戻し条件を示す | 「根拠のない数値断定があれば差し戻し」 |
| log / reuse rule | 再利用条件と廃止条件を残す | 「社外提案には法務確認後のみ利用」 |
この要素を分けると、出力が不十分だったときに「言い回しが悪い」のか、「前提が足りない」のか、「出力仕様が曖昧なのか」を切り分けられます。
5.2.2 指示設計シート
AIへ依頼する前に、次のシートを埋めます。
【指示設計シート】
目的:
読み手 / 承認者:
意思決定点:
使ってよい情報:
使ってはいけない情報:
前提 / 用語:
AIに依頼する作業:
人間が判断する作業:
出力形式:
必須項目:
受け入れ基準:
差し戻し条件:
ログ化 / 再利用条件:
このシートは、そのままAIへ貼り付けるためだけのものではありません。人間側の合意、レビュー、再利用のための設計書でもあります。
5.2.3 改善前から改善後へ
改善前の依頼は、次のようになりがちです。
競合他社について調べて報告してください。
この依頼では、何を意思決定するための調査か、どの競合を対象にするか、どの情報源を使うか、どの形式で報告するかが分かりません。改善後は、次のように設計します。
【目的】次回提案で、当社の導入後支援を主軸にするか判断するため、競合比較の初稿を作る。
【読み手】営業部長と提案責任者。
【意思決定点】価格訴求、導入後支援、移行支援のうち、次回提案でどれを主軸にするか。
【使ってよい情報】競合の公開Webページ、公開資料、当社の公開サービス説明。
【使ってはいけない情報】顧客名、未公開の契約条件、社内限定の価格表。
【依頼】公開情報を前提に、競合比較表の初稿を作ってください。
【出力形式】競合名 / 公開情報の要約 / 根拠URLまたは資料名 / 要確認 / 提案への示唆。
【受け入れ基準】公開情報と推定を分ける。根拠がない断定はしない。要確認事項を明示する。
改善後の指示では、AI出力をそのまま根拠にせず、公開情報、要確認、提案への示唆を分けています。これにより、第3章の evidence matrix や第4章の採否判断へ接続できます。
5.3 CRISP-Pを再定義する
5.3.1 CRISP-Pは万能テンプレートではない
CRISP-Pは、指示を構造化するための便利な型です。ただし、これだけで業務上の安全性や採否判断が保証されるわけではありません。本章では、CRISP-Pを task brief、context pack、output schema、acceptance criteria の一部として使います。
| 要素 | 本章での扱い | 確認すること |
|---|---|---|
| Context | 文脈、資料、前提、用語、除外情報 | 資料の出所、確認日、情報分類 |
| Role | AIに期待する視点 | 責任者ではなく作業支援者として扱う |
| Instruction | 実行してほしい作業 | 下書き、比較、反論、要確認抽出などに分ける |
| Specification | 制約、禁止事項、受け入れ基準 | 機密、個人情報、法務、トーン、文字数 |
| Product | 出力形式 | 表、箇条書き、根拠欄、要確認欄、decision memo |
5.3.2 CRISP-P + 受け入れ基準の例
【Context】
既存顧客向け提案の1枚サマリーを改善します。読み手は顧客の部門長です。判断点は、追加支援プランの検討に進むかどうかです。
【Role】
営業提案の構成レビュー担当として、提案の読みやすさ、根拠、反論対応を点検してください。
【Instruction】
現行サマリーの問題点を洗い出し、改善後の構成案を3案作ってください。
【Specification】
顧客名、個別契約条件、個人情報は使わないでください。未確認の数値は断定せず、要確認として扱ってください。
【Product】
次の表で出力してください。
- 案名
- 主なメッセージ
- 根拠候補
- 想定反論
- 要確認事項
- 採用に向く条件
【Acceptance criteria】
読み手が次の判断を選べること。根拠候補と要確認事項が分かれていること。社外共有前に人間が確認すべき点が明示されていること。
この形にすると、AIの出力が評価しやすくなります。単に「提案書を作って」ではなく、何を満たせば受け入れるかを先に決めています。
5.4 context pack を作る
5.4.1 文脈は多いほどよいわけではない
AIに大量の情報を渡しても、必要な前提と不要な情報が混ざると出力は不安定になります。context packでは、使う情報、使わない情報、優先順位を整理します。
【context pack】
目的:
読み手:
意思決定点:
利用資料:
- 資料名 / 版 / 確認日 / 情報分類 / 使う範囲
用語:
前提:
除外する情報:
匿名化ルール:
AIに質問してよいこと:
AIに判断させないこと:
5.4.2 情報分類と匿名化
指示設計では、情報分類を後回しにしません。特に、顧客名、個人情報、契約条件、未公開財務情報、社内人事情報、研究開発情報は、外部AIに入力できるかを先に確認します。
| 情報の例 | 取り扱い |
|---|---|
| 公開済みのサービス説明 | 利用可。出所を残す |
| 社内限定の業務手順 | 社内ルールに従い、必要なら社内環境で扱う |
| 顧客名や個人名 | 原則として匿名化または入力しない |
| 契約条件や未公開価格 | 入力しない、または承認済み環境でのみ扱う |
| 会議メモ | 個人情報、機密、未決事項を確認してから扱う |
AIに渡す資料は、「AIが読めるか」ではなく「AIに渡してよいか」で判断します。
5.4.3 マルチモーダル資料の渡し方
第5章の指示設計は、テキストだけを前提にしません。PDF、画像、表、グラフ、スクリーンショット、議事メモを使う場合は、次を指定します。
- どの資料を主資料として扱うか。
- どの資料は参考扱いにするか。
- 表やグラフから読み取ってよい範囲はどこか。
- 画像やスクリーンショットに含まれる個人情報をどう扱うか。
- 読み取れない箇所を推測せず、要確認として出すか。
- 資料間で矛盾がある場合、どの資料を優先するか。
例:
添付PDFは公開資料として扱ってください。スクリーンショットは社内検討用であり、顧客名と個人名は読み取らず、必要なら「顧客A」「担当者B」と匿名化してください。表の数値は転記ミスがあり得るため、結論ではなく要確認欄に入れてください。
5.5 output schema と acceptance criteria
5.5.1 出力形式を先に固定する
AI出力は、形式が自由だと評価しにくくなります。出力仕様では、見出し、表、必須欄、禁止事項を先に固定します。
【output schema】
1. 目的
2. 読み手の判断点
3. 前提
4. 推奨案
5. 根拠候補
6. 要確認事項
7. 想定反論
8. リスク
9. 採用条件
10. 保留条件
この schema は、提案書、稟議メモ、会議ログ、営業ヒアリングメモなどに合わせて調整します。重要なのは、根拠、要確認、リスク、採用条件を出力に含めることです。
5.5.2 structured outputs の考え方
structured outputs は、AIの出力を人間やシステムが扱いやすい形に固定する考え方です。APIや実装の詳細を知らなくても、非技術職は次を指定できます。
- 表の列名を固定する。
- JSON風の項目名を固定する。
- 必須項目と任意項目を分ける。
不明、要確認、根拠なしを許可する。- 推測を禁止し、根拠がない場合は空欄ではなく要確認にする。
例:
次の形式だけで出力してください。
{
"claim": "主張",
"evidence_candidate": "根拠候補",
"source_status": "確認済み / 要確認 / 根拠なし",
"risk": "主なリスク",
"next_action": "人間が確認すること"
}
この形式にすると、後続の evidence matrix、CARE+評価、decision log へ接続しやすくなります。
5.5.3 受け入れ基準と差し戻し条件
受け入れ基準は、AI出力を採用してよい最低条件です。差し戻し条件は、修正しない限り使えない条件です。
| 種類 | 例 |
|---|---|
| 受け入れ基準 | 読み手の判断点が明記されている |
| 受け入れ基準 | 主張ごとに根拠候補または要確認がある |
| 受け入れ基準 | 機密情報や個人情報が含まれていない |
| 差し戻し条件 | 未確認の数値を断定している |
| 差し戻し条件 | 読み手が判断できない抽象論だけになっている |
| 差し戻し条件 | 社内ポリシーや承認者確認を省いている |
受け入れ基準を先に書くと、AI出力の評価が感覚ではなく基準に基づくものになります。
5.6 例示と段階的指示
5.6.1 例示は「完成形」ではなく「判断基準」を伝える
例示は、AIに文体や構造を伝えるために有効です。ただし、例をそのままコピーさせるのではなく、何を守ってほしいかを明示します。
以下の例は、構成と粒度の参考です。内容をそのままコピーせず、今回の前提に合わせて作成してください。
【良い例の特徴】
- 先に判断点がある
- 主張と根拠候補が分かれている
- 要確認事項が残っている
- 次アクションが明確である
5.6.2 段階的指示の基本
複雑な成果物は、一度で作らせず、段階に分けます。
- 理解確認: 問題設定、読み手、制約を要約させる。
- 構成案: 出力 schema に沿って、章立てや表の列を提案させる。
- 初稿作成: 採用候補の構成で初稿を作らせる。
- 反論・要確認抽出: 反論、リスク、追加確認を列挙させる。
- 差し戻し: 受け入れ基準に合わない点を指定して修正させる。
5.6.3 段階的指示の例
【第1段階: 理解確認】
次の task brief を読み、目的、読み手、意思決定点、制約、要確認事項を要約してください。不明な点は推測せず、質問として列挙してください。
【第2段階: 構成案】
理解確認に基づき、1枚サマリーの構成案を3案作ってください。各案に、向いている条件、弱点、要確認事項を付けてください。
【第3段階: 初稿】
案Bを採用候補として、output schema に沿って初稿を作ってください。根拠候補と要確認事項を分けてください。
【第4段階: 自己点検】
初稿を acceptance criteria に照らして点検し、差し戻しが必要な箇所を表で示してください。
この進め方にすると、途中で前提のずれを修正できます。第4章の採否判断メモにも接続しやすくなります。
5.7 手段選択：通常生成、検索、ツール連携
5.7.1 通常生成で足りる場合
通常生成で足りるのは、次のような作業です。
- 文章の初稿を作る。
- 観点や反論を列挙する。
- 既に渡した資料を要約する。
- 表の構成案を作る。
- 表現を読み手別に書き換える。
この場合でも、根拠確認や承認は人間が行います。
5.7.2 検索 / retrieval が必要な場合
最新情報、公開資料、社内ナレッジ、規程、FAQなどを参照する場合は、検索や retrieval が必要になることがあります。非技術職が判断すべき点は、実装方式ではなく次の点です。
- どの資料群を検索対象にするか。
- 検索結果を根拠として使ってよいか。
- 参照元、確認日、版を出力に残すか。
- 古い情報や競合する情報が出た場合にどう扱うか。
- 社内限定資料を外部サービスへ送っていないか。
5.7.3 tool use / function calling / MCP連携が必要な場合
AIが外部ツールや社内システムと連携する場合、指示設計では次を決めます。
| 観点 | 確認すること |
|---|---|
| 目的 | ツールを使う理由は明確か |
| 入力 | どの情報をツールへ渡すか |
| 権限 | 実行してよい操作と禁止操作は何か |
| 出力 | ツール結果をどの形式で受け取るか |
| 承認 | 実行前または反映前に人間承認が必要か |
| ログ | 誰が、いつ、何を実行したか残るか |
MCP連携のような仕組みも、本文では実装詳細より「どのデータやツールをAIから安全に使わせるか」という責任分界として扱います。社内システムへの書き込み、外部送信、顧客影響がある操作は、人間の承認を前提にします。
5.8 よくある失敗
5.8.1 目的がないままプロンプトを磨く
表現だけを修正しても、目的、読み手、意思決定点が曖昧なままでは出力は安定しません。まず task brief を見直します。
5.8.2 context を詰め込みすぎる
資料を大量に渡すと、AIが重要度を誤ることがあります。主資料、参考資料、除外情報、優先順位を指定します。
5.8.3 出力 schema がない
自由形式の回答は読みやすくても、評価や再利用に向きません。根拠欄、要確認欄、リスク欄、採用条件を含めます。
5.8.4 AIに承認者の役割を与える
AIに「採用してよいか決めて」と依頼しても、説明責任は人間に残ります。AIには採否材料、反論、要確認事項を出させ、人間が最終判断します。
5.8.5 ログを残さない
よい指示ができても、適用範囲、前提、改善理由、廃止条件を残さなければ、別文脈で誤用される可能性があります。再利用する指示は資産として管理します。
5.9 人間が最終判断すべき点
AIに指示案、構成案、初稿、反論、要確認事項を作らせても、次は人間が判断します。
- task brief は現実の意思決定点に合っているか。
- 入力情報の分類と匿名化は妥当か。
- context pack に不要な機密情報が含まれていないか。
- output schema は評価、承認、再利用に使えるか。
- acceptance criteria は読み手とリスクに合っているか。
- 検索、retrieval、tool use、MCP連携が必要な場合、権限とログは適切か。
- AI出力を採用、条件付き採用、差し戻し、保留のどれにするか。
- 指示と成果物を再利用してよい条件、廃止する条件を残したか。
章末演習
演習5-1：指示設計シートを作る
次の曖昧な依頼を、指示設計シートに書き換えてください。
競合他社について調べて報告してください。
目的、読み手、意思決定点、使ってよい情報、使ってはいけない情報、出力形式、受け入れ基準を含めてください。
演習5-2：context pack を作る
「会議メモを意思決定ログに変換する」タスクについて、利用資料、前提、用語、除外情報、匿名化ルールを含む context pack を作ってください。
演習5-3：output schema と acceptance criteria を作る
「経営向け1枚サマリー」の初稿をAIに作らせる前提で、output schema と受け入れ基準、差し戻し条件を設計してください。
演習5-4：段階的指示を設計する
「営業ヒアリングメモから提案骨子を作る」タスクを、理解確認、構成案、初稿、自己点検、差し戻しの5段階に分けて指示してください。
演習5-5：手段選択を行う
次のタスクについて、通常生成、検索 / retrieval、表やPDFの読み取り、tool use / function calling、MCP連携のどれが必要かを判断し、理由、承認条件、ログ化範囲を書いてください。
社内FAQ、直近の問い合わせ一覧、公開サービスページを参照して、顧客向け回答テンプレートを更新する。
理解度チェック
□ プロンプトを task brief、context pack、output schema、acceptance criteria の組み合わせとして説明できる □ AIに渡してよい情報と渡してはいけない情報を分けられる □ CRISP-Pを万能テンプレートではなく、指示設計の一部として使える □ structured outputs の考え方で、根拠欄、要確認欄、リスク欄を指定できる □ 段階的指示で、理解確認、構成案、初稿、自己点検、差し戻しを分けられる □ tool use / function calling / MCP連携が必要な場合に、人間承認とログ化を設計できる
章末の要点
- プロンプトは、単独の質問ではなく、業務成果物を安全に作るための作業指示パッケージです。
- 指示設計では、task brief、data classification、context design、output schema、acceptance criteria を分けます。
- CRISP-Pは便利な型ですが、受け入れ基準、根拠、リスク、承認条件と組み合わせて使います。
- 出力 schema を固定すると、評価、差し戻し、再利用がしやすくなります。
- 検索、retrieval、tool use、MCP連携は、権限、承認、ログ化とセットで判断します。
- 人間は、入力情報の可否、採否判断、承認、再利用条件を最終判断します。
次章への橋渡し
第5章では、目的、文脈、制約、例示、出力形式、受け入れ基準を含む指示設計を扱いました。次の第6章では、AIから得られた出力を評価し、改善指示へつなげる方法を扱います。CAREの4観点を土台に、Evidence、Risk、Approvalを加えたCARE+で評価ログまで確認します。
- 前章: 第4章：問題解決の論理プロセス
- 次章: 第6章：AIの出力を評価・改善する
- リライト方針: 2026年版リライト契約と分割計画