cold-email-subject-line-tester について
cold-email-subject-line-testerは、メール件名の案を生成・採点し、統計的な根拠に基づく分割テストを設計するスキルです。B2BのコールドメールやB2Cのライフサイクルメールが対象で、範囲は件名と、B2Cではプリヘッダーに限られます。
主な機能
- 01異なる切り口の件名案を生成
- 02数値基準で採点
- 03スパム誘発語を検出
- 04分割テストを設計
- 05指標とガードレールを選定
- 06テスト結果を記録
活用シーン
- 01B2Bコールドメールの件名を検証
- 02カート放棄メールの案を準備
- 03製品発表メールの件名を比較
- 04件名の観点から開封率低下を調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ mbfinotti/ sales-skills --skill cold-email-subject-line-testerインストール後、Claude Code で/cold-email-subject-line-testerを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evals/evals.jsonreferences/pattern-library.mdscoring-rubric.mdtest-design.md詳細
件名テスター
すでに選定済みのパーソナライズの切り口から件名のバリエーションを作成し、数値基準に照らして採点し、勝者を選ぶための統計的に誠実なスプリットテストを設計します。
ここでは、次の2つの事実がすべての前提となります。
- MEDDICのような、複数の情報源にまたがる共通の件名フレームワークは存在しません。あるのは単一ベンダーのブランド化された手法と、ブランド化されていない共通認識(B2Bのコールドメールの件名は短くし、数字や疑問符を避ける)のみです。
- 公表されている件名に関する統計のほぼすべては、メールツールを販売する企業によるもので、独立した監査を受けていません。傾向は参考にしつつ、数値の大きさは鵜呑みにしないでください。
情報源同士で明確に矛盾している点(特に小文字表記とタイトルケース)は、ルールではなくテスト候補として扱ってください。
対象範囲:納品物は件名(B2Cの場合はプリヘッダーも)のみです。
以下は決して行わないでください。
- メール本文を作成する。
- 配信到達性、ヘッダー、ドメイン、認証を監査する。
- 見込み客のシグナルを調査する。
- タッチごとの送信スケジュールを計画する。
件名自体に含まれるスパム判定の引き金となる語句は採点項目として指摘し、受信トレイへの配置に関する詳細なレビューは mbfinotti/sales-skills@cold-email-deliverability に引き継いでください。
ヒアリング
1回のメッセージにつき質問は1つにしてください。複数選択肢を提示してください。文脈からすでに回答がわかる質問は省略してください。実行環境に永続メモリーがあり、以前の実行でこのユーザーの回答が保存されている場合は、再度質問するのではなく、回答内容を確認してください。
- 対象はB2Bのコールドアウトバウンドですか、それともB2Cのライフサイクル/販促ですか?最初に尋ねてください。この2つでは適用されるルールが異なります。
- 受信者のペルソナ、役職、職位は何ですか?エグゼクティブは数秒で受信トレイを判断するため、適したパターンが大きく絞られます。
- すでに選んでいるパーソナライズの切り口は何ですか?ペインポイント、競合他社、会社の取り組み、経営幹部の優先事項、共通の話題、きっかけとなる出来事から選んでください。該当するものがなければ、いったん停止し、まず
mbfinotti/sales-skills@sales-outreach-personalizationに引き継いでください。これらの優先順位付けはステップ4で行うことであり、この質問ではありません。 - メール本文では実際に何を約束し、何を提供しますか?件名が本文の内容を決して上回ってはなりません。
- 送信プラットフォーム(シーケンサーまたはESP)でスプリットテストができますか?できる場合、配信量(リストの件数または1日あたりの送信数)はどのくらいですか?
- 現在の環境で信頼できる判断指標は何ですか?返信または商談、クリックまたはコンバージョン、それとも開封数のみですか?
- いつまでに結果を出す必要がありますか?期限が今週中であれば、調査がほぼ不要な切り口を優先し、保留中の質問に関するテストはすべて除外します。各バリエーションに200件以上の送信を集めるのに十分な期間があれば、テストの対象に含めます。
- 今回のキャンペーンだけで成果を上げればよいですか、それとも継続的に活用できる資産を作りますか?継続的に活用する場合は、再利用可能な切り口(内部向けのような名詞、ペルソナのペインポイント、経営幹部の優先事項)と表記方法のテストを優先します。今回限りの場合は、今日のリストにすでに適している切り口を優先します。
- 許容できる調査時間の上限は見込み客1人あたり何分ですか?また、1日あたり何件送信できますか?調査時間がほぼゼロなら、きっかけとなる出来事、競合他社、会社の取り組みの切り口はすべて除外します。割り当て件数が各バリエーションの最低件数に届かない場合は、テスト案を除外します。
- B2Cの場合のみ:プリヘッダーのテキストを管理できますか?また、ブランドとして絵文字を使っても問題ありませんか?
下書きを作成する前に、質問7〜9の回答に基づいて切り口のカタログを再度ランク付けし、どの回答によってどの切り口の順位が変わったかをユーザーに伝えてください。
ワークフロー
- インタビューを実施します。下書きを始める前に、レジーム、ペルソナ、切り口、本文で約束する内容、テスト可能な規模、指標、期限、成果が得られるまでの期間、許容できる労力の上限を確認します。
- references/pattern-library.md の該当するレジームのセクションを読みます。B2B のコールドメール向けルールを B2C のライフサイクルメールに適用したり、その逆を行ったりしてはいけません。
- 下書きの前に、反証可能な仮説を作成します。「[観察内容]に基づき、[変更]によって[対象者]に[効果]がもたらされると考えます。[指標]でその効果を確認します。」の形式にします。「新しい件名を試してみましょう」のような曖昧な表現は却下します。
- カタログの効率順に沿って、候補を3~5案作成します。B2B のコールドメールでは、返信獲得数を調査にかかる時間で割った値の順に、
internal-style noun > specific pain question > executive-world anchor > competitor == company initiative > trigger eventとします。インタビューで除外された切り口は、最下位に置かず削除し、どの切り口をなぜ削除したかを明記します。各案はそれぞれ異なる切り口を表す必要があり、別案の類義語への置き換えにしてはいけません。B2C では、すべての案にプリヘッダーを付けます。件名とプリヘッダーを合わせたものがテスト対象の単位です。 - references/scoring-rubric.md に沿って各案を採点します。まずハードフェイル項目を確認し、その後、10点満点のスコアカードで評価します。
- 合格基準に満たない案は再生成し、再採点します。全案が品質ゲートを通過するまで繰り返します。
- 残った案を、選択したヒューマナイズ用スキルに通してから再採点します。モデルが生成した初稿をそのまま送ってはいけません。テンプレート的な AI 表現こそ、メールを読まずに削除したくなる原因です。
- ウェブを閲覧できる場合は、案の根拠となる変動しうる事実(トリガーイベント、競合に関する主張、取り組みの名称)を確認します。閲覧できない場合は、送信前にユーザーに確認してもらいます。
- references/test-design.md に沿ってテストを設計します。変数は1つにし、サンプルサイズを事前に決定し、最短実施期間、判断指標、ガードレール指標を定めます。
- 出力パッケージ(下記の形式)を提示します。実行環境に永続メモリがある場合は、ペルソナ、選択した切り口、仮説、送信した案を記録し、以降の実行ではインタビューを省略して結果を踏まえられるようにします。
- 結果が返ってきたら、仮説に照らして勝者、敗者、または結論が出なかった案を記録します。その後、references/pattern-library.md の順位付きキューから、次の単一変数テストに進みます。あるいは、データ量ではこれ以上テストできないことを明確に伝えます。
呼び出し例と期待される出力
このスキルで対応できる一般的な依頼:
- 「VP of Operations 宛てのこのコールドメールの件名をテストしてください。」
- 「カート放棄キャンペーン用に、件名の案を5つ作成してください。」
- 「来週の製品ローンチメールの件名を A/B テストしてください。」
- 「開封率が低いのはなぜですか?」件名のみを診断します。ドメイン、認証、受信トレイへの振り分けが原因の場合は、
mbfinotti/sales-skills@cold-email-deliverabilityに案内します。
期待される出力パッケージ(順序どおり):
- 上記の反証可能な形式で記述した仮説。
- 案のスコアカード表:案、切り口、単語数/文字数、評価基準のスコア、メモ(B2C の場合はプリヘッダー列も追加)。
- テスト計画:分割方法、案ごとのサンプル数、期間、判断指標、ガードレール。
- リスクの指摘事項:未確認の事実、見つかったスパム誘発語、インタビューで削除した切り口とその理由、解消にかかる送信コストとともにキュー順に並べた保留中の質問。
記入例付きの表とテスト計画は、references/scoring-rubric.md と references/test-design.md にあります。
品質ゲート
- 各バリエーションを、references/scoring-rubric.md の10点満点の採点基準で評価します。
- 合格基準:公開するすべてのバリエーションが、重大な不合格項目ゼロで8/10以上を獲得すること。
- 重大な不合格項目(1つでも該当すれば、そのバリエーションは即時失格です):
- 「Re:」「Fwd:」などを偽装して使う、またはほかの誤解を招く表現。
- 本文で提供しない内容を件名で約束する。
- スパムと判定されやすい語句。
- 該当するルールの切り詰め上限を超える。
- セット内で切り口が重複している。
- B2Bのコールドメールの件名に見込み客のファーストネームを入れる。
- 反復する:不合格のバリエーションを再生成して再採点し、公開するセット全体が8/10以上になるまで続けます。テストの数をそろえるために、基準点に満たないバリエーションを公開してはいけません。
KPIと測定
- B2Bのコールドメールにおける意思決定指標:返信率、ポジティブ返信率、または商談獲得数です。開封数だけを指標にしてはいけません。メールのプライバシー保護プロキシは2021年以降、トラッキングピクセルを事前取得しているため、実際には開封されていないのに開封として記録されます。開封率はあくまで方向性を示す指標です。
- B2Bの基準値(ベンダー公表値であり、独立監査はありません):
- 平均開封率は約27.7%、良好な水準は40~45%です。
- 平均返信率は4~5.8%、良好な水準は5~10%です。
- 年々低下しています。
- B2Cのライフサイクルメールでは開封率を活用できますが、下流のガードレール指標と組み合わせる必要があります。クリック、コンバージョン、配信停止率0.5%未満、苦情率0.1%未満が対象です。
- このスキルの成功とは、事前に確定したサンプル数に達し、ガードレール指標を悪化させることなく、判断(勝者、敗者、または正直なところ結論が出ないという判断)を下せることです。
失敗パターン
- バリエーションのセットが、同じアイデアを言い換えただけになっている。対処法:パターンライブラリから異なる切り口を選び、各バリエーションに割り当てます。
- 大文字・小文字の使い方をルールとして固定している。情報源同士で直接矛盾しており(タイトルケースと小文字、それぞれにベンダーの主張があります)、表記は一定に保ち、優先順位付きテストキューに入れておきます。
- 効率順を絶対的な法則として扱う、または除外された切り口をセットの最後に残している。その順序は、リストの規模、受信者の役職、実行者によって変わるデフォルトです。インタビューで除外された切り口はセットから削除し、削除したことを明記します。順位を下げて残してはいけません。
- B2Bのコールドメールの件名に見込み客のファーストネームを入れている。メールの一斉差し込みを連想させ、返信が減ることと相関します。代わりに文脈に即したトークンを使います。
- B2Bのコールドメールで開封率をもとに勝者を決めている。プライバシー保護プロキシによる見せかけの開封が誤った勝者を生み出すため、返信または商談を基準に判断します。
- 途中で結果をのぞき見して早期に終了している。サンプル数と期間を事前に決めます。早期の「勝者」は、たいていノイズです。
- 汎用的な疑問文の件名を使っている。疑問文全般についてベンダーデータは一致していません。具体的な悩みを尋ねる質問は機能する場合がありますが、汎用的な質問は失敗します。基本的には断定文を使います。
- 件名で本文の約束以上の内容をほのめかしている。開封は増えても返信と信頼が損なわれます。そのため、本文との約束の一致を採点基準に含めています。
- B2BのルールをB2Cに、またはその逆に適用している。数字を含む件名はB2Bのコールドメールではマイナスに評価されますが、B2Cのライフサイクルメールでは問題なく機能します。
- モデルの生の出力をそのまま公開している。必ず人間らしい表現に整える工程を行い、その後で再採点します。