テンプレートを貼った瞬間、文章は出ます。 困るのは、その文章を使ってよいか判断できないときです。
空欄を埋めただけのプロンプトは、入力にない実績や読者像まで補うことがあります。 流暢な文章ほど、見落としやすい。
ここではSEO記事、LP、メルマガに使える15本の型を紹介します。 どの型にも、材料、制約、出力、確認の欄を置きました。
テンプレートは完成品ではありません。 自分の仕事の判断を入れるための器です。
使う前に四つの欄を埋める
各テンプレートの波括弧を置き換える前に、次の四点を用意します。
- 誰のどんな判断を助けるか。
- 使用してよい事実と資料。
- 作ってはいけない情報。
- 合格とする条件。
資料がない項目を、AIへ「それらしく補って」と頼まないことが大切です。 不明な箇所は不明のまま出させ、調査か担当者の判断へ戻します。
プロンプト全体の考え方は、目的、材料、制約、出力、評価の5要素で詳しく説明しています。
SEO記事で使う5本
1 検索する人の状況を分ける
一つのキーワードに複数の検索意図がありそうなときに使います。
目的:
主キーワード「{KEYWORD}」で検索する人の状況を分け、今回の記事が答える問いを一つ選ぶ。
材料:
検索結果の見出しメモ: {SERP_NOTES}
Search Consoleの関連クエリ: {QUERY_DATA}
顧客から受けた質問: {CUSTOMER_QUESTIONS}
制約:
材料にない検索ボリュームや読者の感情を作らない。
検索意図を「知りたい、買いたい」のような抽象語だけで終えない。
出力:
読者の状況、知りたいこと、判断後の行動、根拠になった材料を表にする。
最後に、この記事で扱う中心の問いを一文で三案出す。
確認:
各行が材料へ戻れること。
一記事で扱えない問いは別記事候補として分けること。
2 調査する一次資料を洗い出す
執筆前の事実確認表を作る型です。
目的:
「{TOPIC}」の記事で確認が必要な主張と一次資料の候補を整理する。
材料:
記事で扱う予定の論点: {CLAIMS}
対象地域と基準日: {REGION_AND_DATE}
制約:
存在を確認できない資料名、URL、統計を作らない。
一次資料と解説記事を分ける。
確認できない場合は「未確認」とする。
出力:
主張、望ましい発行元、検索語、更新頻度、誤ると生じる問題の五列で表にする。
確認:
執筆者が原文を開いて確認するまで、主張を確定扱いしないこと。
3 見出しごとの仕事を決める
競合見出しの寄せ集めを避けるための構成案です。
目的:
中心の問い「{CENTRAL_QUESTION}」へ順に答える記事構成を作る。
材料:
読者の状況: {READER_SITUATION}
使用できる一次情報: {ORIGINAL_INFORMATION}
確認済み資料: {VERIFIED_SOURCES}
制約:
各H2は一つの役割だけを持つ。
材料のない体験、数字、事例を見出しに入れない。
「完全ガイド」「重要な理由」のような内容を特定できない見出しを避ける。
出力:
H2、節の役割、答える小さな問い、使用する材料を表にする。
最後に、構成から外した論点と理由を示す。
確認:
見出しだけを読んでも論理の順番を追えること。
4 資料の範囲で一節を書く
本文を節ごとに作る型です。
目的:
見出し「{HEADING}」の初稿を作る。
材料:
事実資料: {FACTS}
書き手の観察: {OBSERVATIONS}
前後の節の要点: {CONTEXT}
制約:
材料にない内容を補わない。
不明な箇所は [要確認] と記す。
一段落一トピック、一文一行にする。
数字と固有名詞には資料IDを付ける。
出力:
本文の後に、使用した資料IDと未確認事項を分けて出す。
確認:
中心の問いへ答えていること。
前後の節と同じ説明を繰り返していないこと。
5 公開前の編集レビューをする
文章の自然さと事実を別々に見る型です。
目的:
記事草稿「{DRAFT}」を公開前にレビューする。
材料:
中心の問い: {CENTRAL_QUESTION}
使用を許可した資料一覧: {SOURCE_LIST}
著者の経験範囲: {AUTHOR_SCOPE}
制約:
新しい事実や体験を追加しない。
検索順位を保証しない。
修正案と事実確認の指摘を混ぜない。
出力:
1. 中心の問いから漏れた段落
2. 原典確認が必要な主張
3. 主語のない一般論
4. 同義反復
5. 読者が次に確認すべきこと
の順に、該当箇所と修正方針を出す。
確認:
指摘ごとに原文の該当箇所が示されていること。
AIで収益を上げるノウハウを無料でお届け
「AI Business Compass」公式メルマガでは、AIを仕事と収益につなげる実践ノウハウをお届けしています。登録すると、6ステップのロードマップ動画を無料で受け取れます。
無料で動画を受け取る →LPで使う5本
6 BeliefとClaimの距離を測る
コピーを書く前の訴求整理に使います。
目的:
読者が現在信じていることと、商品が伝えたいClaimの間に必要な説明を見つける。
材料:
読者の発言や調査: {CUSTOMER_EVIDENCE}
商品のClaim: {PRODUCT_CLAIM}
示せる根拠: {EVIDENCE}
商品が向かない人: {NOT_FOR}
制約:
読者の感情、実績、保証を創作しない。
Claimが根拠を越える場合は、その点を指摘する。
出力:
現在のBelief、途中で生じる疑問、必要な説明、使える根拠、残る不確実性を表にする。
確認:
根拠のない橋をコピーの強さで埋めていないこと。
7 方向の違うファーストビューを作る
言い換えではなく、比較できる仮説を作ります。
目的:
LPのファーストビューを、異なる三つの仮説で作る。
材料:
対象読者: {TARGET}
Claim: {CLAIM}
根拠: {EVIDENCE}
対象外: {NOT_FOR}
次の行動: {ACTION}
制約:
入力にない数字、No.1、利用者の声、期限、割引、保証を追加しない。
三案を単なる言い換えにしない。
出力:
課題の具体化、手順の具体化、不安の低減に分ける。
各案に、見出し、補足文、CTA、想定するBelief、検証したい変化を付ける。
確認:
どの差をテストする案か一文で説明できること。
8 根拠の足りないClaimを探す
公開前の誇張防止に使います。
目的:
LP草稿「{LP_DRAFT}」のClaimと根拠の対応を確認する。
材料:
公開可能な実績と条件: {APPROVED_EVIDENCE}
利用規約と提供範囲: {TERMS_AND_SCOPE}
制約:
草稿にない根拠を推測しない。
法的な適合性を最終判断しない。
出力:
Claim、根拠、成立条件、判定（対応、弱い、なし）、安全な修正方向を表にする。
確認:
「効果が期待できる」への言い換えだけで問題を隠していないこと。
9 実在する不安からFAQを作る
架空の利用者の声ではなく、確認できる質問を使います。
目的:
購入や申込の前に必要なFAQ草案を作る。
材料:
実際の問い合わせ: {REAL_QUESTIONS}
価格、解約、提供範囲: {TERMS}
回答の根拠資料: {SOURCES}
制約:
質問も回答も材料の範囲で作る。
不明な条件は「担当者確認」とする。
不安を煽って購入を急がせない。
出力:
質問、短い回答、詳細説明、根拠資料、更新担当を表にする。
確認:
FAQと利用規約、申込画面の説明が矛盾しないこと。
10 一要素の実験計画を作る
A/Bテストの準備に使います。
目的:
LPの仮説「{HYPOTHESIS}」を検証する計画を作る。
材料:
現状の数値: {BASELINE}
変更候補: {VARIANT}
流入条件: {TRAFFIC}
利用するテスト環境: {TOOL}
制約:
一回のテストで変える中心要素は一つ。
必要サンプル数や勝敗を根拠なく断定しない。
前後比較を無作為なA/Bテストと呼ばない。
出力:
主指標、補助指標、固定する条件、除外条件、停止条件、結果別の次の行動を表にする。
確認:
実装前に計測イベントが動くことを別途確認する。
メルマガで使う5本
11 読者の現在地を一通ぶんに絞る
書き始める前の読者設計です。
目的:
今回のメールで扱う読者の状況と一つの変化を決める。
材料:
登録理由: {SIGNUP_REASON}
直近の配信: {RECENT_EMAILS}
読者からの返信: {REPLIES}
今回伝えたい内容: {TOPIC}
制約:
読者全員が同じ悩みを持つと決めつけない。
一通で複数の商品判断を迫らない。
出力:
読者の現在地、知っていること、まだ疑っていること、今回のClaim、次の行動を一文ずつ出す。
確認:
今回のメールを送る理由が、販売予定だけでなく読者側から説明できること。
12 本文と一致する件名を作る
開封率をAIに予測させず、約束の一致を見ます。
目的:
本文「{BODY_SUMMARY}」の件名候補を作る。
材料:
読者の現在地: {READER_STATE}
本文で渡す価値: {VALUE}
ブランドボイス: {VOICE_RULES}
制約:
本文にない数字、期限、結論を件名に足さない。
「必読」「知らないと損」など、不安だけで開封を促さない。
出力:
観察から入る案、問いから入る案、内容を直接示す案を各三つ出す。
各案に、本文との対応箇所を添える。
確認:
件名だけで約束した内容が本文に存在すること。
13 一通の本文構成を作る
問題提起、説明、行動を同じ密度にしない構成です。
目的:
読者が「{NEXT_JUDGMENT}」を判断できるメール構成を作る。
材料:
実際の場面: {SCENE}
伝えるClaim: {CLAIM}
根拠: {EVIDENCE}
次の行動: {CTA}
制約:
場面、説明、逡巡、判断の順を機械的に固定しない。
一段落一トピックにする。
根拠のない成功談を追加しない。
出力:
段落ごとの役割、要点、長さの目安を表にし、その後に初稿を書く。
確認:
CTAが本文のClaimから自然につながること。
14 配信シリーズの役割を分ける
すべてのメールを販売文にしないための型です。
目的:
「{SERIES_GOAL}」へ向かう配信シリーズを設計する。
材料:
読者の登録時点: {START_STATE}
商品が向く条件: {FIT}
商品が向かない条件: {NOT_FIT}
渡せる教材と事例: {ASSETS}
制約:
通数と期間は固定せず、必要な理解の段階から決める。
各通の役割を一つにする。
架空の締切や社会的証明を作らない。
出力:
各通の役割、読者の疑問、使う材料、Claim、CTA、前後との接続を表にする。
確認:
途中の一通だけ読んでも、誤解を招く約束にならないこと。
15 送信前に事実と温度を分けて校正する
最後の検品に使います。
目的:
メール草稿「{DRAFT}」を送信前にレビューする。
材料:
確認済みの事実: {VERIFIED_FACTS}
ブランドボイス: {VOICE_RULES}
配信対象: {SEGMENT}
制約:
本文を勝手に全面改稿しない。
事実の問題と、文体の好みを分ける。
出力:
1. 事実または条件の未確認箇所
2. 件名と本文の不一致
3. 読者を一括りにした断定
4. 過剰な緊急性
5. ブランドボイスから外れた判断
を順に示し、最小の修正案を出す。
確認:
リンク、日付、価格、配信対象は人が送信画面でも確認すること。
テンプレートを使った後に残すもの
良い出力が出ても、プロンプトだけを保存して終わりにしません。
- どの入力資料を使ったか。
- どの出力を採用したか。
- 人がどこを直したか。
- どの指標や反応を見たか。
- 次回は何を変えるか。
この五点を一緒に残します。
結果が悪かったときも、テンプレート全体を捨てません。 目的、材料、制約、出力、評価のどこでずれたかを一つずつ見ます。
テンプレートが資産になるのは、コピペする回数が増えたときではありません。 使うたびに、判断の理由が次の人へ渡せる形で残ったときです。
文章の声まで型へ組み込みたい場合は、ブランドボイスを設計する5ステップを続けて使ってください。
