cold-email-weekly-rhythm について
コールドメールを運用するチーム向けの、カレンダーを基準にしたプレイブックです。定期監査、返信確認、キャンペーンの振り返り、受信箱のライフサイクル確認、四半期ごとの実験を定め、スクリプトや自動リマインダーは含みません。
主な機能
- 01週次・四半期の定期スケジュール
- 02到達性監査のチェックリスト
- 03ポジティブ返信の確認手順
- 04キャンペーン振り返りと実験レビュー
- 05受信箱ライフサイクルの計画
活用シーン
- 01コールドメール運用の定例作業を設定
- 02返信とキャンペーン結果を確認
- 03受信箱の変更や四半期テストを計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/cold-email-weekly-rhythmを入力して読み込まれたか確認します。
詳細
コールドメールの週間リズム
コールドメールのスキルが29個あっても、スケジュールに沿って実行しなければ役に立ちません。ここでは、そのスケジュールを紹介します。
これは純粋なプレイブックです。 スクリプトも、自動リマインダーもありません。リズムを自分のカレンダーに設定し（以下のステップ1）、指定された時間に指定されたスキルを実行します。システムはこれだけです。
ステップ1（このスキルを使う前に必須）：リズムをカレンダーに設定する
Google Calendar／Outlook／Apple Remindersなど、実際に毎日確認しているものを開きます。以下の予定を繰り返しのイベントとして作成してください。タイトルと頻度は正確にコピーします。
| イベントのタイトル | 頻度 |
|---|---|
| コールドメール：月曜日の配信到達性監査 | 毎週月曜日、午前9時 |
| コールドメール：水曜日の好意的な返信の確認 | 毎週水曜日、午前10時 |
| コールドメール：金曜日のキャンペーン振り返り | 毎週金曜日、午後3時 |
| コールドメール：受信トレイのライフサイクル（キャンセル／昇格／購入） | 隔週月曜日、午前11時 |
| コールドメール：月次の迷惑メール振り分けテスト | 毎月1日、午前10時 |
| コールドメール：四半期ごとの実験レビュー | 各四半期の最初の月曜日、午後1時 |
ステップ1を省略しないでください。 趣味で取り組む人と、コールドメール運用で上位1％に入る人の違いは、上位1％の運用担当者が、宣言した頻度でこれらのタスクを毎週実際に実行することです。カレンダーが説明責任の仕組みになります。このスキルにリマインダーが組み込まれていないのは、意図的です。組み込まれていて、それが機能しなくなった場合、運用が気づかないうちに破綻するからです。
月曜日 — 配信到達性監査（15分）
実行：
/email-deliverability-audit --days=7
（対象を絞ったバージョンを使う場合：audit-performance.ts --campaign-ids=<active campaign ids> --days=7）
確認：
- 過去7日間の全体の返信率 — 1％以上である必要があります（1％ルール）。同じ数値を使ってドメインを廃止しますが、その判断をするのは送信数が200件以上で、ドメインの運用期間が30日以上になってからです。
/inbox-lifecycle-managerを参照してください。 - フラグが立ったキャンペーン（
flag_low_reply = TRUE） - フラグが立った受信トレイ（
flag_high_bounce = TRUE）
対応：
- 1％ルールを満たさなかったキャンペーンがある場合：
/deliverability-incident-responseを実行 → トリアージの判断ツリーを確認 - バウンス率が2％を超える場合：
/deliverability-incident-responseでトリアージします。3％を超える場合（自動一時停止の基準）：問題のあるキャンペーンをただちに一時停止してから、トリアージします - すべて問題がなければ：週次ジャーナルに確認結果を記録し、タブを閉じます
水曜日 — 好意的な返信の確認（件数に応じて30〜60分）
実行：
/positive-reply-scoring # on all campaigns active in the last 7 days
確認：
positive_interestedまたはpositive_softの返信 — 対話を望んでいるリードですpositive_referralの返信 — 「代わりにJaneに話してください」と伝えている人ですnegative_hostileの返信 — 危険信号です。調査してください
対応：
positive_interestedの返信には、確認してから30秒以内にすべて返信します。まとめて返信しないでください。返信に数分かかったように感じられる場合は、数時間かかった場合と比べて、成約率が3倍高くなります。- 紹介の場合：24時間以内に紹介された人に連絡し、紹介者の名前を伝えます。
- 敵対的な返信の場合：謝罪し、すべてのリストから削除して、敵対的と判定された理由を調べます（ターゲティングの不備を示すことがよくあります）。
時間管理： 週に50件を超える好意的な返信がある場合は、専任のクロージング担当者／AEに引き継ぐべき規模に達しています。水曜日の午前中に引き継ぎ、水曜日の午後から返信に対応できるようにしてください。
金曜日 — キャンペーンの振り返り（キャンペーンごとに20分）
今週21日目を迎えるキャンペーンを特定します。（返信率のシグナルが安定するまでの最低期間は21日です。）
それぞれについて、次の手順を実行します。
-
/positive-reply-scoring --campaign-id=<id>を実行します -
過去のキャンペーンの肯定的な返信率のベースラインと比較します
-
判断します。
- 勝者（肯定的な返信率がベースラインの2倍以上）： 継続し、規模の拡大（より多くの受信トレイへの複製）を検討します
- 中程度（ベースライン付近）： コピーまたはリストを改善します。次のバリエーションを計画するため、月曜日に
/experiment-designを実行します - 敗者（ベースラインの50％未満）： 終了します。理由を実験ログに記録します。
-
結果を
profiles/<slug>/experiments/<YYYY-MM-DD>-<campaign>.jsonに記録します。positive_reply_rate、reply_rate、bounce_rate- 判断（継続／改善／終了）とその理由
- 次の改善に向けた仮説（改善する場合）
重要： ログを省略しないでください。四半期を通じて、これらのログは四半期レビューで /experiment-design に入力するデータになります。履歴がなければ、キャンペーンをまたいだ学びを得られません。
隔週月曜日 — 受信トレイのライフサイクル（30分）
ローテーションの判断、つまり何を解約し、何を昇格させ、何を購入するかは、
/inbox-lifecycle-manager に基づいて行います。ヘルス CSV をざっと見て、状態が悪そうなものを
引退させないでください。運の悪い週に正常なドメインを潰すことになります。
実行（読み取り専用、書き込みなし）：
# Within /inbox-lifecycle-manager:
npx tsx scripts/plan-lifecycle.ts --goal=<your daily send goal> --out=./lifecycle-$(date +%F) --snapshot
plan.csv と actions.csv を確認します。
BURNED— 送信数200件以上、経過日数30日以上で、返信率が1％未満です。これが実際に解約する対象です。KEEP_BELOW_THRESHOLD— 消耗していますが、置き換えるウォームな受信トレイがありません。先に購入し、翌週に解約します。BOUNCE_FORK— バウンス率が3％を超えています。何かを見切る前に、/deliverability-incident-responseでコードを分類してください。原因は通常、ドメインではなくリストにあります。TOO_YOUNG／INSUFFICIENT_DATA— まだ評価されていません。そのままにしておきます。HELD— ウォームアップがオフのため、レピュテーションを判断できません。報告してください。ウォームアップをこっそり再開してはいけません。
操作 — 実際に計画を確認し、承認した後に実行します。
# Within /inbox-lifecycle-manager (dry run first, always):
npx tsx scripts/apply-lifecycle.ts --actions=./lifecycle-$(date +%F)/actions.csv
npx tsx scripts/apply-lifecycle.ts --actions=./lifecycle-$(date +%F)/actions.csv --apply
タグのみが対象です。プロバイダーのサブスクリプション解約は別途、明示的な承認を得たうえで、少量ずつ確認しながら行います。このスキルの references/cancellation-safety.md を参照してください。
計画で容量不足が報告された場合： 今すぐ /zapmail-domain-setup-public からドメイン購入サイクルを開始します。購入から送信可能になるまで約2週間かかり、新しいドメインを評価できるようになるまでさらに30日かかります。そのため、必要になる1か月前には常に購入しておきます。
毎月1日 — スパム振り分けテスト（実作業25分、テスト実行約20分）
実行： /email-deliverability-audit から Smart Delivery のスパム振り分けテストを実行します。
npx tsx scripts/run-spam-test.ts --campaign-id=<highest volume active campaign> --senders=100
（G Suite と Office365 のプロバイダープールを使用します。送信者100件は最適な規模です。統計的なシグナルを得るには十分な数であり、API の停止を避けるには小さい数です。）
確認：
- 全体の受信トレイ到達率 — 目標：85％以上
- スパムフィルターのトリガー — どのフィルターが作動し、どの送信者に影響したか
対応：
- 受信トレイ到達率90％以上： 良好です。現在の取り組みを続けます。
- 80〜90％： 注意が必要です。spam-filter-details を確認し、来週、最も頻繁に発生しているトリガーから修正を始めます。
- 80％未満： 危険な状態です。キャンペーンを一時停止し、
/deliverability-incident-responseを実行して、追加送信の前に修正します。
四半期ごと（各四半期の最初の月曜日） — 実験レビュー（90 分）
前四半期の experiments/*.json をすべて読みます。傾向を特定します。
- どのキャンペーンが最も高いポジティブ返信率を達成しましたか？
- どのリストのソースから最も質の高いリードを獲得できましたか？
- どのコピーの切り口が響きましたか（観察 → 示唆？課題？ソーシャルプルーフ？）
- どの ICP のアーキタイプが最も高いコンバージョン率を達成しましたか？
成果物： profiles/<slug>/retrospectives/<YYYY>-Q<N>.md に保存した 1 ページの Q 振り返り。内容は以下のとおりです。
- 上位 3 件のキャンペーンと、成果につながった要因
- 下位 3 件のキャンペーンと、避けるべきこと
- 次の四半期の実験に向けた 3〜5 件の仮説
- データから別のセグメントのほうが成果を上げていると考えられる場合は、
client-profile.yamlの ICP を調整します
振り返りを /experiment-design を通じて次の四半期の実験を設計する際の入力として使用します。
やらなくてよいこと
以下の作業は必要ありません。
- Smartlead を毎日確認する（水曜日の一斉確認で重要な点はすべて把握できます）
- 日々の返信率の変動を気にしすぎる（7 日間の平均を待ちましょう）
- ポジティブな返信をリアルタイムですべて読む（すぐに把握したい場合は通知を設定してください。ただし、この仕組みでは水曜日の一斉確認を行います）
コールドメールの仕組みを毎日細かく確認するのは、成果につながるパターンではなく、先延ばしのパターンです。
次にすること
このスキル自体が一連の作業サイクルです。次にすることは、予定リストにある次のカレンダーイベントです。
または、まだキャンペーンを実施していない場合： このスキルは使わず、最初のキャンペーンが 7 日目を迎えてから戻ってきてください。
関連スキル
/email-deliverability-audit— 月曜日と毎月のタスク/positive-reply-scoring— 水曜日と金曜日のタスク/inbox-lifecycle-manager— 隔週のキャンセル／昇格／購入の判断/smartlead-inbox-manager— 承認済みのタグ変更を実行します/deliverability-incident-response— 月曜日の監査で問題が検出された場合/experiment-design— 四半期ごとの振り返りを次の実験設計に反映します/zapmail-domain-setup-public— インシュランスプールが少なくなった場合