email-prompt-building

コールドメールテンプレートビルダー

コールドアウトリーチのシーケンスを設計し、固定テンプレートセットに確定します。各タッチで実際に使う承認済みコピー、{{input_field}} プレースホルダー、バリアントの振り分けルールを含みます。このスキルが担うのは設計です。切り口を検討し、課題の仮説を立て、シーケンスの流れを決め、根拠となる実績を選び、その結果を最終コピーに落とし込みます。

テンプレートは後から email-generation によって、単純な決定論的置換でレンダリングされます。行ごとにメールを書く実行時の LLM はありません。

アーキテクチャの原則

このスキルは設計時に使うものです。コピーを確定させ、実行時のモデルに判断を委ねません。

このスキルの旧バージョンでは、LLM への指示プロンプトを出力し、行ごとにモデルにメールを書かせていました。この方式は廃止されています。現在、行ごとの違いを表現する方法は、（1）上流工程で値を埋める {{input_fields}}、（2）振り分けキーで選択する個別のバリアントテンプレートの2つだけです。バッチ内では、それ以外はすべて同一です。

                       DESIGN TIME (this skill)
                       ┌─────────────────────────────────────┐
context file ─────────▶│  explore angles, pick hypotheses,    │
research / hypotheses ▶│  decide sequence arc, choose proof   │──▶ template set (sequence.md)
enrichment field list ▶│  → commit to FINAL COPY              │     • real copy per touch
                       └─────────────────────────────────────┘     • {{input_field}} placeholders
                                                                    • variant-routing rules
                                                                    • Input Fields contract

                       FILL TIME (normalization + enrichment skills)
                         contacts ─▶ populate every declared input field

                       RENDER TIME (email-generation skill)
                         template + filled CSV ─▶ deterministic render ─▶ emails CSV

このスキルが読み取るもの（入力）

すべての入力は、このスキルを実行する GTM プロジェクト内にあります（パスはプロジェクト相対であり、正確な構成は各プロジェクトによって異なります）。

入力	抽出する情報
会社情報ファイル	文体、送信者、価値提案、実績ライブラリ、主要な数値、禁止語
キャンペーン調査	検証済みのデータポイント、統計、ツールの比較
仮説セット	メカニズムと根拠を含む番号付きの仮説
エンリッチメントフィールド一覧	使用可能な {{input_fields}} と、それぞれのエンリッチメント／正規化ステップ
キャンペーン概要	対象業界、役職の種類、シーケンスの長さ

このスキルが生成するもの（出力）

テンプレートセット（キャンペーンごとに1つのシーケンスファイル）。以下を含みます。

1. シーケンスの概要 — タッチ、送信間隔、変数一覧
2. 各タッチのコピー — 各メールの最終承認済みテキストそのもの。文中に {{input_field}} プレースホルダーを含みます。書き方のルールではなく、実際に使う文面です。
3. バリアントの振り分けルール — タッチにバリアントがある場合の振り分けキーと各条件（例：Touch 3: segment == "enterprise" → variant A, else → variant B）
4. 入力フィールドの契約（以下を参照） — すべての {{field}}、そのソース、フォールバック
5. 件名 — 初回タッチのみ。フォローアップでは同じスレッドにまとめるため、件名は空にします。
6. 注記 — 各切り口を選んだ理由、適用した文体ルール、意図的に除外した内容

出力の具体例は、references/example-sequence.md を参照してください。

入力フィールドの契約

テンプレート内のすべての {{placeholder}} は、テーブルに宣言する必要があります。これは、値の補完とレンダリングの各ステップ間の取り決めです。宣言済みフィールドが欠けている場合、レンダリングは明確なエラーで失敗します。未宣言のプレースホルダーは不具合です。ソースは、特定プロジェクト内のファイルパスではなく、その役割（正規化ステップ、分類用のエンリッチメント列など）で記述してください。

フィールド	ソース（役割）	欠損時のフォールバック
{{first_name}}	名前の正規化ステップ	連絡先をスキップ
{{company_name}}	名前の正規化ステップ	連絡先をスキップ
{{industry}}	業界分類のエンリッチメント列	使用箇所の節を削除する（{{industry}} を含まないバリアントを用意）
{{segment}}（振り分けキー）	セグメント分類のエンリッチメント列	デフォルトのバリアントに振り分ける

行ごとに個別の文面を作成する必要がある場合（例：個別に作成する1行の導入文）も、入力フィールドとして扱います。このスキルやレンダリング時ではなく、上流の LLM エンリッチメント列で生成します。

キャンペーンテンプレートセットの作成

ステップ 1：上流データを確認する

プロジェクトの会社情報ファイル、キャンペーン調査、仮説セットを確認します。

また、エンリッチメントフィールドの一覧も確認してください。どの {{input_fields}} が実際に利用でき、どのエンリッチメント／正規化ステップから取得できるかを確認します。確実に入力されるフィールドだけを使用してください。

**ペルソナの広がりを確認します。**連絡先リストに複数のペルソナ（経営幹部＋IC＋運用担当者）が含まれる場合は、役割グループごとにテンプレートセットを作成します。すべての役割に対応させようとするテンプレートは、内容がぼやけてしまいます。

ステップ 2：切り口を検討し、文面を確定する

ここが本当の作業です。実行時に「行ごとに考える」モデルはありません。このスキルで文面を確定する必要があります。

• 仮説ごとに、課題を最も鋭く伝える方法を考えます。複数の切り口を検討してください。
• 切り口をシーケンスに割り当てます：有力な切り口は、それぞれ異なる タッチ（タッチ 1＝切り口 A、タッチ 2＝切り口 B、…）またはタッチの バリエーション にします。複数タッチのシーケンスなら、詰め込みすぎずに、さまざまな切り口から課題を取り上げられます。
• 各タッチの最終的な文面を書きます。実際の文章を作成してください。「X について P1 を書く」のような指示ではありません。
• コンテキストファイルのトーン、制約、禁止語などのボイスルールを適用します。独自のボイスを作らないでください。
• {{input_field}} プレースホルダーを使うのは、行ごとの差し替えが本当に必要な場合だけです。それ以外は固定文面にします。

ステップ 3：バリエーションと振り分けを定義する

タッチをセグメント／ペルソナに応じて変える場合、各バリエーションを個別の完成した文面として作成します。「エンタープライズなら X と言う」のような条件分岐を含む単一テンプレートにはしないでください。振り分けキーと、各バリエーションの条件を宣言します。バリエーションは少数（2～3 個）に抑え、それぞれを完成したメールにします。

ステップ 4：Input Fields の契約を記述する

上の表に従って、すべての {{field}} を宣言し、取得元とフォールバックを記載します。信頼できる取得元のないフィールドはテンプレートで使用できません。そのフィールドを生成するエンリッチメントステップを追加するか、その節を削除してください。

ステップ 5：シーケンスファイルを組み立てる

# Sequence — {campaign}

[overview: touches, cadence, variables]

## Touch 1 — {angle}
[FINAL copy with {{placeholders}}]
**Subject options:** [first touch only]

## Touch 2 — {angle}
[FINAL copy]  **Subject:** empty (threads as Re:)

## Touch 3 — conditional on {{routing_key}}
### Variant A — {condition}
[FINAL copy]
### Variant B — {condition}
[FINAL copy]

## Input Fields contract
[the declared-fields table]

## Notes
[angle rationale, voice rules, what was excluded]

ステップ 6：品質を確認する

• すべてのタッチが指示ではなく、最終的な文面になっている
• すべての {{placeholder}} が Input Fields の契約に取得元＋フォールバックとともに宣言されている
• 未宣言のプレースホルダーがない。取得元を保証できない {{field}} がない
• バリエーションが、1 つのテンプレート内の条件分岐ではなく、個別の完成した文面になっている
• フォローアップのタッチでは件名が空欄になっている（スレッドを継続するため）
• ボイスルールと禁止語がコンテキストファイルに基づいている
• 書式ルールを守っている：署名なし、-- を使用し、–／— は使用しない、英語のみ
• 表現ルールを守っている：「we help {{industry}} teams」と書かない、見込み客の会社について説明しない、「We're {Company}」と書かない
• 以下のアンチパターンが、どのタッチにも含まれていない

ステップ 7：保存する

テンプレートセットをキャンペーンのシーケンスファイルとして保存します。保存先は、GTM プロジェクトでキャンペーンアセットに使用している場所とし、キャンペーンごとにシーケンスファイルを 1 つ作成します。

アンチパターン — どのタッチにも書いてはいけないこと

1. **見込み客自身の情報をそのまま繰り返さない。**見出しを言い換えたり、製品の機能を言い直したりしないでください。本人は知っています。何も言うことがないまま情報をスクレイピングしただけだと伝わります。
2. **相手のビジネスについて説明しない。**相手が日々携わっていることなら、省いてください。
3. アーキテクチャ関連の専門用語を使わない。「three-tier」「entity resolution」「data mesh」などは使いません。文面では内部構造ではなく、成果を伝えます。
4. **メール 1 通につき質問は 1 つ。**質問が 2 つあると競合し、どちらにも答えてもらえません。
5. **一度読めば理解できる文章にする。**入れ子になった節や、修飾語の重ねすぎは避けてください。もう一度読まないと理解できない文は、短く書き直します。
6. 冒頭は一目で意味が伝わるようにする。「the X gap」のような、白書のタイトル風の名詞句は避けてください。
7. **ユーザーが貼り付けた文面を言い換えない。**ユーザーがフックを提示した場合は、そのまま使ってください。

シーケンスの構成（デフォルト）

各タッチでは異なる角度から課題に切り込み、徐々に踏み込んでいきます。

• タッチ 1 — お祝い／状況に触れる導入＋受け継がれている根本的な課題＋控えめな CTA
• タッチ 2 — より説得力のある実績やベンチマークを示す切り口＋資料提供の CTA
• タッチ 3 — セグメントに特化した切り口（{{customer_segment}} に応じて振り分け）
• タッチ 4 — 短い「お別れ」／関係を終えるメッセージ

デフォルトの間隔：タッチ 1 の 2 日後、以降のタッチは 3 日間隔です。キャンペーンごとに変更できます。

参考資料

• references/example-sequence.md — テンプレート一式の作成例（出力形式）
• references/prompt-patterns.md — 過去のキャンペーンから抽出したコピーのパターン
• references/email-structures.md — 役職や職位に応じた構成のバリエーション