導入事例記事をAIで作るプロンプト｜取材メモから課題・施策・成果を整理する実務テンプレート
顧客インタビューや営業担当者のメモから、導入事例記事の下書きを作るためのプロンプトです。広報・マーケティング担当者や、事例制作を効率化したいライターを想定しています。
核心は、AIにいきなり記事を書かせず、事実・引用・未確認情報を分けてから構成と本文を作らせることです。これにより、発言の創作や因果関係の飛躍を抑えながら、Markdown形式の下書きを作れます。
この記事で分かることは次のとおりです。
- 取材メモから導入事例記事を作るコピペ用プロンプト
- 入力時に変更する項目と、固定しておきたい制約
- AIが成果や顧客の発言を作ってしまう失敗の防ぎ方
- 情報不足を確認しながら記事を仕上げる手順
このプロンプトの用途と完成イメージ
このテンプレートの用途は、散らばった取材情報を「導入前の課題」「選定理由」「導入内容」「成果」「今後の展望」に整理し、公開前の初稿に変えることです。
想定する入力情報は、次のような資料です。
- インタビューの文字起こし
- 営業担当者が残したヒアリングメモ
- 導入した製品・サービスの概要
- 導入時期、対象部署、利用人数などの基本情報
- 顧客から公開許可を得た数値や発言
- 掲載してはいけない社名、数値、契約情報
出力はMarkdown形式を指定します。見出しと本文をWordPressへ移しやすく、確認が必要な箇所も一覧化できるためです。
ここがポイント: 導入事例記事で最初に守るべきなのは文章のうまさではなく、事実と未確認情報の境界です。資料にない成果、感情、発言は補わないよう明記します。
コピペ用プロンプトテンプレート
以下のテンプレートをコピーし、{}で囲まれた部分を案件に合わせて置き換えてください。
あなたはBtoB企業の導入事例記事を制作する編集者です。
以下の資料だけを根拠に、顧客が導入前の課題から成果に至るまでを理解できる記事の下書きを作成してください。
# 記事の目的
{例：見込み顧客が、自社と似た課題の解決方法を具体的に理解できるようにする}
# 想定読者
{業種、企業規模、部署、役職、抱えている課題}
# 紹介する製品・サービス
{製品名と概要}
# 記事の条件
- 顧客名：{正式名称／匿名表記}
- 導入時期：{年月／不明}
- 対象部署：{部署名／不明}
- 利用範囲：{人数、拠点、業務など／不明}
- 目安文字数：{例：2,500〜3,500字}
- 文体：{例：簡潔で落ち着いたビジネス文体}
- 顧客発言の表記：{実名、役職のみ、匿名など}
# 必須ルール
1. 提供資料に書かれていない事実、数値、因果関係、感想、会話を作らない。
2. 引用文は、資料内の本人発言だけを使う。読みやすく整えた場合は意味を変えない。
3. 数値には、分かる範囲で期間、比較対象、測定条件を添える。
4. 導入後に起きた変化と、製品導入によって生じたと確認できる成果を区別する。
5. 情報が足りない箇所は推測せず、本文では「[要確認：確認内容]」と記載する。
6. 非公開情報として指定された内容は本文に含めない。
7. 過度な賛辞や広告的な表現を避け、顧客の課題、行動、結果を具体的に書く。
# 作業手順
最初に資料を次の4種類に分類してください。
A. 記事に使用できる確認済みの事実
B. そのまま引用できる顧客の発言
C. 意味を確認しないと使えない情報
D. 非公開または使用禁止の情報
分類後、AとBだけで記事を作成してください。Cは確認事項へ回し、Dは出力しないでください。
# 記事構成
1. タイトル案を3つ
2. 120字以内の導入文
3. 顧客企業・対象業務の概要
4. 導入前の課題
5. 製品・サービスを選んだ理由
6. 導入時の進め方
7. 導入後の変化と成果
8. 今後の活用予定
9. まとめ
# 出力形式
Markdownで、次の順番で出力してください。
## 事実整理
- 確認済みの事実
- 使用できる引用
## 記事本文
- H1は使わず、H2とH3で構成する
- 1段落は2〜4文を目安にする
- 引用はblockquote形式にする
- 確認が必要な箇所は [要確認：○○] と示す
## 公開前の確認事項
- 確認する相手
- 確認する内容
- 確認が必要な理由
# 取材資料
<source_material>
{取材メモ、文字起こし、製品情報を貼り付ける}
</source_material>
# 非公開情報
<confidential_information>
{記事に含めてはいけない情報を貼り付ける。なければ「なし」}
</confidential_information>
資料と指示をタグで区切るのは、どこまでが記事の根拠なのかを見分けやすくするためです。Googleの公式ガイドでも、明確で具体的な指示、文脈の付与、一貫した区切りの利用がプロンプト設計の要点として説明されています。
入力時に変える部分
毎回変更する項目と、原則として残す制約を分けると、テンプレートを再利用しやすくなります。
案件ごとに変更する項目
{記事の目的}：問い合わせ獲得、営業資料の補足、既存顧客への活用紹介など{想定読者}：業種だけでなく、部署、役職、具体的な悩みまで入力{顧客名}：正式名称、匿名企業名、業種表記のいずれか{利用範囲}：利用人数、対象拠点、対象業務など、確認できた範囲{取材資料}：発言者と発言内容の対応が分かる形で入力{非公開情報}：契約金額、個人情報、未発表機能などを明記
特に想定読者は、「製造業の担当者」のような広い指定で終わらせないことが大切です。「複数拠点の在庫集計を担当し、Excelの手作業を減らしたい管理職」まで具体化すると、AIがどの説明を厚くすべきか判断しやすくなります。
固定した方がよい条件
次の条件は案件が変わっても残しておくのがおすすめです。
- 資料にない事実や発言を作らない
- 未確認情報を本文へ混ぜず、
[要確認]で示す - 数値に期間や比較対象を添える
- 非公開情報を出力しない
- 確認済み事実と引用を本文より先に整理する
固定するべきなのは記事の言い回しではなく、事実確認の手順です。 文体や文字数は変えられますが、根拠の扱いを案件ごとに変えると確認漏れが起きやすくなります。
NG例と改善例
失敗しやすいのは、「それらしい成功事例を書いて」と頼み、AIに不足情報を埋めさせてしまう指示です。
NG例：成果の創作を許してしまう
以下のメモをもとに、説得力のある導入事例記事を書いてください。
導入前の苦労や担当者の喜びが伝わるようにし、成果も具体的な数字で示してください。
この指示では、メモに成果数値や感情がない場合でも、AIが「作業時間を50％削減した」「担当者から喜びの声が上がった」といった文を補う可能性があります。読みやすくても、公開できる記事にはなりません。
改善例：根拠と不足情報を分ける
以下のメモだけを根拠に導入事例記事を作成してください。
資料にない数値、感情、発言、因果関係は補わないでください。
成果を示す情報が不足している場合は本文を作り込まず、
「誰に何を確認すべきか」を質問として列挙してください。
引用できる文は、発言者が特定できる記録に限定してください。
改善点は明確です。
- 「具体的に書く」より先に、使える根拠の範囲を指定した
- 不足情報を創作ではなく確認質問へ変えた
- 引用の条件として、発言者を特定できる記録を求めた
- 導入後の変化と、導入が原因だと確認できる成果を分けた
説得力は大きな数字から生まれるとは限りません。誰が、どの業務を、どの手順へ変えたのかを確認できる範囲で書く方が、読者は自社に置き換えて判断できます。
出力を安定させる3つのコツ
安定化の中心は、AIの表現力を細かく制御することではなく、入力と確認工程を分けることです。
1. 文字起こしをそのまま渡さない
長い文字起こしには、雑談、言い直し、推測、複数人の発言が混ざります。可能なら入力前に次の情報を付けてください。
- 発言者名または役割
- 発言日時
- 質問と回答の区切り
- 公開可否
- 数値の測定期間と比較対象
話者が分からない発言は、引用候補から外すよう指示します。
2. 構成と本文を一度に確定しない
情報量が多い場合は、次の3段階に分けます。
- AIに事実、引用、要確認事項を分類させる
- 人が分類結果を確認し、不足情報を追加する
- 確認済み情報だけで構成案と本文を作らせる
一度の指示で完成稿まで進めるより手順は増えます。しかし、誤った数値や発言を長い本文から探す作業は減らせます。
3. 出力形式を項目単位で指定する
「記事形式で」とだけ書かず、見出し、引用、確認事項の書式まで決めます。理想に近い短い出力例がある場合は、個人情報や機密情報を除いたうえで追加すると、見出しの粒度や文体を合わせやすくなります。
# 追加する出力例
## 導入前の課題
月末に複数拠点のデータを担当者が集約していました。
集計完了までの時間は資料に記載がないため、公開前に確認が必要です。
[要確認：月次集計に要していた時間を顧客担当者へ確認]
活用例と応用パターン
基本テンプレートは、公開媒体や取材状況に合わせて調整できます。
Web掲載用の長文事例
背景から成果までを順番に読ませる形式です。意思決定者が判断した理由と、現場が実際に変えた手順を分けて入力すると、単なる製品紹介になりにくくなります。
追加指定の例は次のとおりです。
選定理由は経営・管理側の判断、導入時の進め方は現場側の行動として分けてください。
両者の発言が資料にない場合は統合せず、要確認事項に回してください。
営業資料向けの短縮版
長文記事をそのまま短くすると、前提条件が落ちて成果だけが強調されがちです。短縮版でも、課題、施策、結果、適用条件を残します。
記事本文を次の4項目、合計600字以内に再構成してください。
- 導入前の課題
- 実施した施策
- 確認済みの結果
- 同様の活用を検討するときの前提条件
数値の期間と比較対象は省略しないでください。
取材前の質問設計
資料が少ない段階では、本文を無理に作らせず質問票へ切り替えます。
提供情報だけでは導入事例記事を完成できません。
「課題」「選定」「導入」「成果」「今後」の各項目について、
事実確認に必要な質問を最大3問ずつ作成してください。
回答者として適切な役割も添えてください。
既に資料で確認できる内容は質問しないでください。
この使い分けにより、AIは記事を書く道具だけでなく、取材前の不足情報を見つける補助にもなります。
公開前チェックリスト
AIが整えた文章も、そのまま公開せず、人が原資料と照合します。
- [ ] 社名、製品名、部署名、役職名の表記は正しいか
- [ ] 引用文は実際の発言と意味が一致しているか
- [ ] 数値に期間、単位、比較対象が付いているか
- [ ] 導入後の変化を、製品だけの成果として断定していないか
- [ ]
[要確認]が本文に残っていないか - [ ] 非公開情報、個人情報、未発表情報が含まれていないか
- [ ] 顧客側と自社側の公開承認を得たか
- [ ] 読者が導入条件や対象業務を誤解しないか
最初に試すなら、完成稿を一度で求めず、事実整理だけをAIへ依頼してください。 分類結果を人が確認できたら本文生成へ進みます。今後の分岐点は、確認済みの数値と引用をどこまで用意できるかです。材料が不足している案件では、記事生成より先に取材質問を作る方が、公開できる原稿へ早く近づけます。