導入事例の書き方:8つのブロックと証拠の表
導入事例の書き方は、顧客への取材、導入前後の証拠集め、8ブロックの穴埋めの順です。結果、導入前、きっかけ、実施内容、測った変化、失敗した点、氏名入りの引用、再現できる教訓を書きます。根拠のない数字は書きません。

導入事例の書き方は、顧客への取材、変更前後の証拠集め、8つのブロックの穴埋めという順番です。結果、導入前、きっかけ、実施内容、測った変化、うまくいかなかった点、氏名入りの引用、他の読者が再現できる教訓。根拠のない数字は書きません。事例は証拠であり、ロゴの上に感想を載せたものではありません。
失敗するのは文章ではなく、材料集めの段階です。満足している顧客と締め切りがあるので、基準値も日付もなく、疑い深い読者に耐える数字もない物語ができあがります。最初の一文を書く前に、実際に存在する証拠を決めます。
事例の信頼性は、顧客が公開を許した最も都合の悪い検証可能な事実で決まります。
読む価値のある導入事例とは
読者は「何が変わったか」「なぜそう言えるのか」「自分なら何を変えるか」の順に知りたいのです。ロゴや形容詞はこのどれにも答えません。出発点、確認できる変化、読者が自分の状況に照らせる限界が必要です。
ここが証言と事例の違いです。証言は顧客が満足していると述べます。事例は、結果が成り立つまでの仕事を、予定通りに進まなかった部分も含めて示します。後者のほうが書くのが難しく、捏造するのはもっと難しくなります。
まず証拠から始めます。変更前の数字、日付、変更後の数字を確認する方法のどれかが欠けているなら、プロセスの物語としてなら公開できます。測定結果として公開することはできません。
導入事例の書き方:8つのブロック
次の順番で埋めます。各ブロックの役割は一つだけで、右の列は書く前に集める証拠です。証拠がないブロックは削るか、顧客の記憶であることを明記します。
| ブロック | 書く内容 | 必要な証拠 |
|---|---|---|
| 1 結果 | 誰が、いつからいつまでに、何が変わったか | 変更後の数字と読み取った日付 |
| 2 導入前 | 以前の状態と、その場しのぎの方法 | 基準値、画面記録、書き出し |
| 3 きっかけ | 行動を決めた出来事 | 顧客本人の言葉と日付 |
| 4 実施内容 | 実際に行ったことを順番に | 手順、担当、所要時間 |
| 5 変化 | 数字、単位、測定期間 | 出所、書き出した日、計算方法 |
| 6 失敗 | 効果が出なかった試み | 顧客の説明。推測は書かない |
| 7 引用 | 氏名と役職のある人の一文 | 録音またはメール、公開許可 |
| 8 教訓 | 他の読者が真似する点、避ける点 | あなたの分析。分析だと明記する |
飛ばされやすいのが6番目です。しかし、他の7つを信じてもらえるかどうかを決めるのもここです。すべて順調なページはパンフレットに見え、失敗が一つあるページは報告書に見えます。
公開できる数字とできない数字
数字を公開できるのは、出所、測定期間、単位が同じ文に入るときです。「顧客のヘルプデスクが2026年9月30日に書き出したデータによると、移行後8週間でサポートチケットが38%減った」は公開できます。「サポートが大幅に改善した」は公開できません。
| 主張 | 使える証拠 | ない場合 |
|---|---|---|
| 時間の短縮 | 同じ作業を変更前後で計測した記録 | 作業内容を書き、割合は書かない |
| 売上の増加 | 顧客の財務・請求データ | 顧客の見方だと書き、測定したとは書かない |
| エラー削減 | 同じシステムと同じ定義の件数 | 以前の手順を示し、比率は省く |
| 公開の短縮 | 2回の公開それぞれの日付 | 年表だけを示す |
| 順位の改善 | 日付とプロパティ付きのSearch Console書き出し | 公開ページをリンクし、上昇は主張しない |
米国では連邦取引委員会のEndorsement Guidesが証言や事例を対象にしています。金銭的な関係の開示が必要で、例外的な結果を一般的なものとして示してはいけません(FTC Endorsement Guides、2026年10月20日閲覧)。Googleの有用なコンテンツに関する指針は、一次体験と独自情報を求めています(Creating helpful content、2026年10月20日閲覧)。どちらも顧客の書面許可の代わりにはなりません。
要約ではなく書き出しデータをもらいます。要約の時点で単位と日付が抜け落ちており、疑い深い読者が最初に確認するのはその二つです。
取材で聞く7つの質問
準備すれば1回の通話で足ります。録音の許可を取り、文字起こしを顧客に送って訂正してもらい、引用は顧客の言葉のまま残します。マーケティング用語に書き換えてはいけません。
- 始める前はどんな状態で、時間や費用をどれだけ使っていましたか。
- 何がきっかけで変更を探す気になりましたか。
- 最初に何を試し、なぜうまくいかなかったのですか。
- 実際に行ったことを、その順番で教えてください。
- どの数字を見ていて、どこから来た数字で、いつ読みましたか。
- 結果のうち、製品のせいだとは言えない部分はどこですか。
- 同じ立場の人は最初に何をすべきで、何をまねしないべきですか。
6番目の質問が限界の段落を生みます。正面から聞くと顧客は案外答えてくれます。後で否定される主張を書かずに済みます。
顧客が数字を出さない場合
プロセスの事例として書き、最初の段落でそう明記します。出発点、手順、所要時間、顧客自身が語る変化を書きます。引用は残し、割合は削ります。
私たちには、変化のどこまでが製品によるものかは分かりません。事例は対照実験ではありません。きれいな前後の数字があっても、季節性、価格変更、別のツールが同じ指標を動かします。顧客が基準値も比較も測っていないなら、「顧客はこの変化を〜によるものと見ている」と書いて止めます。
これはページの弱さではありません。読者が信じるページと、割り引いて読むページの違いです。
よくある質問
導入事例はどのくらいの長さがよいですか。
証拠を載せられて、一度で読める長さです。多くの製品事例は、結果に1画面、実施内容に1画面、数字に1つの表、限界に1段落で足ります。前半を理解するのにもう一度取材が必要なら、2つのページに分けます。
書面の許可は必要ですか。
必要です。氏名、ロゴ、引用、顧客が提供した数字のすべてに必要です。書く前に取り、許可と根拠の書き出しを同じフォルダに置きます。
取材なしで書けますか。
公開情報から製品の物語を書くことはできますが、顧客事例とは呼べません。顧客の説明がなければ、きっかけも失敗も引用もありません。事例ではなく例や想定として示します。
事例が機能したかはどう見ますか。
追跡できるリンクを付けて営業やサポートの材料として使い、参照元と、それが答えた質問を確認します。この形式の成果に共通の基準はなく、ページの流入と販売の文脈を外した数字は信用しません。
次の一歩
8つのブロックを並べ、証拠がそろっているものに印を付けます。印が付かない項目は取材の質問になり、埋めるための文章にはなりません。全部そろってからページを書きます。結果が公開ニュースでもあるなら、告知はプレスリリースの形式を使い、事例は証拠として残します。製品紹介を各チャネル向けに作り分けるときも同じ規律です。主張は一つ、出所は一つ、確認できる場所を一つ。素材、チャネル、振り返りを一つの流れにまとめるなら、プロモーションの記録を一か所に集めてください。
収録: QueryWinガイド · レベル2


