hypothesis-scoring

仮説スコアリング — ローンチ前のキュー

仮説のアイデアをまとめて受け取り、ローンチキューを返します。今すぐ着手する3件、保留するもの、除外するものとその理由を示します。

このスキルの目的は、アウトバウンドテストをまとめて実施した後によく起きる「うまくいったのか、いかなかったのか」という議論に、送信前に合意した数値で決着をつけることです。

**出力言語：**チームの作業言語（ウクライナ語を話すチームではデフォルトでウクライナ語、入力が英語なら英語）。平易な言葉を使い、専門用語は避けます。

---

必要なもの

• 仮説アイデアのリスト — hypo-generator のマトリックス、ワークショップの成果物、チーム独自のリスト、または未加工のテキスト。
• 各アイデアについて、できれば次の情報：ICP · トリガー（または静的なデータポイント）· オファー · チャネル · 証拠（数値を含む事例）· リストの入手元。

不足している項目があっても進行を妨げる要因にはなりませんが、発見事項として扱います。証拠またはリストの入手元がないアイデアは、ステップ1のゲートを通過できません。どちらも決して捏造しないでください。

情報が提示されていない場合は、稼働中のチャネルと送信者の数（LinkedIn アカウント／メールボックス）、およびチーム独自のキャンペーン履歴があるか（独自の数値は常に市場ベンチマークより優先）を確認してください。

---

ワークフロー

ステップ1 — ストップフィルター（スコアリング前のゲート）

4つのはい／いいえのゲートがあります。**1つでも「いいえ」なら、その仮説は一切スコアリングしません。**実行できないものをスコアリングすると、キューが汚染されるだけです。

#	ゲート	PASS の条件
G1	リストを作成できる	名前のある情報源と、トリガーに該当する企業を300社以上抽出できるフィルターがある。「LinkedIn のどこか」＝FAIL
G2	トリガーを検証できる	特定の企業について、その出来事が起きたことを確認でき、発生日を特定できる
G3	証拠がある	このセグメントに関連するものとして意思決定者が受け入れる事例、数値、または関連プロジェクトがある
G4	チャネルで意思決定者にリーチできる	LinkedIn を読んでいる、またはゲートウェイを通過する業務用メールボックスを持っている

**技術的なストップフィルター（メールのみ — 仮説ごとではなく、企業ごとに一度確認）：**すべてのドメインで SPF/DKIM/DMARC を設定済み · 受信トレイへの到達をテスト済み（「メールは送信されているから大丈夫」は不可）· メールボックスを3週間以上ウォームアップ済み · 過去のキャンペーンでバウンス率が3%未満。

ここで不合格になると、メールに関するすべての仮説が一度にブロックされます。N件それぞれに別の発見事項として報告するのではなく、担当者を明記した1件のブロッカーとして報告してください。これらの確認には1日かかりますが、省略すると、その後の結論はすべて損なわれます。メールが届いていないだけなのに、仮説が失敗したように見えてしまうためです。

ゲートテーブルを出力します：hypothesis | G1 | G2 | G3 | G4 | verdict。FAIL ごとに、それを解消するための具体的なアクションを1つと、担当者を記載してください。

ステップ2 — 標準形式に書き換える

数値で反証できない仮説は、意見のままです。すべての候補を次の1文に書き換えてください。

トリガー [T] がある [ICP] に対し、チャネル [C] でオファー [O] を提示すると、3週間で300件のコンタクトあたり少なくとも [N] 件の返信が得られます。 N の半分未満なら終了します。半分以上N未満なら、変数を1つ変えて再試行します。N以上なら、ボリュームを1000件まで拡大します。

N の計算 — チーム独自の履歴がある場合はそれを使い、ない場合に限り市場の基準値を使います。

チャネル	300件のコンタクトに対する計算	デフォルトの N
メール	300 × 1.5%（2026年の平均返信率）	4–5
LinkedIn	300 × 30% の承認 × 20% の返信	15–20

N は最低ラインであり、予測値ではありません。市場の基準値を下回るNを設定したいという人がいるなら、その仮説に枠を割く価値はありません。

ステップ 3 — チャネルの処理能力（実際に何件のテストを実施できるか）

並行して実行できる仮説の数は、処理能力で決まります。意欲の強さではありません。

• LinkedIn： 1アカウントあたり1日約20件の招待 → 300件のコンタクト = 15営業日 = 1つの仮説を1アカウントで検証するのに3週間。テストを3件並行して実施するには、アカウントが3つ必要です。選択肢はほかにありません。
• メール： 3つのメールボックス × 1日30通 = 1日90通送信。300件のコンタクトに3ステップのシーケンスを送る場合、約900通 = 10営業日です。

出力：利用可能な処理能力 → 今サイクルで物理的に実施できる仮説の数 → カレンダーに記載した各テストの終了日。キューが処理能力を超えている場合は、はっきりそう伝えます。残りの仮説が待機している理由は、スコアではなくこれです。LinkedInアカウント1つで5つの仮説を並行して検証する計画は、実質的に5か月の計画です。

ステップ 4 — スコアリング（6つの要素、0 / 1 / 3 / 5の尺度）

0は必須です。これがないと、すべての選択肢が3点付近に集中し、スコアで何も区別できなくなります。

要素	重み	5 =	0 =
このセグメントに対する実証の強さ	0.25	まさにこのニッチ分野での実数値を含む事例がある	実証がまったくない
課題の切実さ	0.25	今まさに痛みを感じており、予算もすでに割り当てられている	私たちが作り上げた課題で、市場では誰もその課題を挙げていない
トリガーの意外性	0.20	競合他社はこのシグナルを使っていない	誰もが使っているため、ノイズになっている
セグメントの規模	0.10	1,000社超	300社分のリストさえ作れない
データ収集のコスト	0.10	1時間でリストを作成できる	アカウントごとに手作業で調査が必要
検証の速さ	0.10	1週間以内に最初の返信がある	サイクルが1か月を超える

中間値：1 = 弱いながらも存在する · 3 = 標準的で機能するが、特筆すべき点はない。

合計 = Σ（スコア × 重み）、範囲は0.0～5.0です。

厳守する2つのルール：

1. 実証または課題のスコアが0なら、その仮説は合計点にかかわらずキューから除外します。除外として報告し、不足している要素を明記します。実証がないのに高得点をつけるのは、誤った自信のなかでも最も高くつくものです。
2. 合計点の高いものから3つを実行します。3.2を超えたものがいくつあるかは問いません。 しきい値よりもキューの仕組みが優先です。4つ目の仮説を加えると、注意が分散し、リストも分割されます。

各スコアには1行の理由を添えます。数字だけでは後から異議を唱えられませんし、四半期が過ぎればその意味を覚えている人はいません。

スコアリングは主観的ですが、それで問題ありません。決めるのはローンチの順番だけです。いずれにしても、事実は返信から明らかになります。

ステップ 5 — キュー

#	仮説（1行）	実証	課題	トリガー	規模	データ	速さ	合計	ステータス

ステータス：launch（上位3件） · queue（次のサイクルまたは処理能力に空きが出るまで待機） · dropped（実証または課題が0点） · failed the gate（ステップ1でFAIL + 修正すべき点）。

ステップ 6 — ローンチ計画＋ジャーナル

ローンチする3つについて、次の項目を記録します。

• ICP · トリガー · オファー · チャネル · N · 初回バッチサイズ（300） · 開始日 · 終了日 · クローズを決める担当者。
• 変数を変える順序。 第1ラウンドは「どこ」：オファーとコピーは固定し、2〜3つのセグメントを並行して実施します（セグメント＝ICP＋トリガー。この2つはセットで動かします）。第2ラウンドは「何を」：勝ち残ったセグメントで、2種類のオファーを試します。第3ラウンドは「どのように」：セグメントとオファーは同じまま、切り口を変えます。最初の一文、根拠、呼びかけを変えます。1ラウンドにつき変更は1つです。一度に2つ変えると、結果は推測にしかなりません。
• 1社につき、1人ではなく2〜3人に送信します。 連絡先が1人だけでは、「担当者が違う」のか「会社が違う」のか判断できず、反応のあるセグメントを誤ってクローズしてしまいます。
• トリガーには有効期限があります。 求人情報は約30日後、資金調達ラウンドは約90日後にシグナルとしての効力を失います。3か月前に作成したリストはトリガーリストではなく、そこに対するキャンペーンはコピーの質にかかわらず失敗します。

次に、事実の欄を空欄にしたジャーナルのひな形を出力します：番号 · ICP · トリガー · オファー · チャネル · 開始日 · 終了日 · 連絡先 · 会社 · 送信数 · 配信数 · 開封数 · 返信数 · 前向きな反応 · ミーティング · 逐語的な反論の引用3つ · 判定 · 次のステップ。

判定は次の3つだけです：拡大 · 変数を1つ変更 · クローズ。「まだ不明」と書きたくなる場合は、件数が少なすぎたということです。それもジャーナルに記録します。

各テストから、反論の逐語的な引用を3つ残してください。5件のキャンペーンを実施すれば、市場が購入しない理由を自ら説明してくれる用語集ができます。

ステップ 7 — ポートフォリオの80/20（2つの仮説でミーティングの獲得を確認したら）

チャネルの日次ノルマの80％を、実績のある仮説に割り当てます。20％は、現在進行中のテスト1つに充てます。2つでも5つでもなく、1つだけを連絡先300件まで実施します。テストが勝ったら、稼働中の80％に加え、最も弱い稼働中の仮説を停止します。次の仮説はステップ5のキューから選びます。

---

失敗の読み解き（テスト結果が戻ってきたら）

スコアリングはローンチ前に行いますが、失敗を嘆くのではなく診断しなければ、キューの信頼性は保てません。次の4つの軸を、この順序で確認します。

1. 技術面 — 開封率が30％未満、バウンス率が3％超、メールが迷惑メールに分類される。仮説とは無関係です。配信を修正し、同じテストを再実行します。
2. ターゲティング — 返信があり、「その業務は行っていない」「別の担当者に連絡してほしい」「その地域にはいない」といった内容です。セグメントまたはペルソナが間違っています。
3. オファー — 「内容はわかりましたが、必要ありません」「これは社内で対応しています」「すでに委託先があります」。セグメントは適切ですが、提案が弱い状態です。
4. メッセージ — 配信に問題はなく、セグメントも確認できているのに、返信がありません。問題はコピーと切り口です。

---

厳守事項

• 根拠やリストの出所を決して捏造しないでください。不明な場合はゲートがFAILとなり、「3」にはなりません。
• Nの数値がない仮説は採点しません。まず標準形式に書き直してください。
• テストの最小件数は連絡先300件です。300件では前向きな反応をまったく評価できません。1件と3件の差は偶然の範囲です。前向きな反応やミーティング獲得単価について議論するのは、1000件以上からです。
• テストの基本指標は返信率ですが、仮説の勝敗はミーティング獲得数で判断します。返信率が4％でミーティングが0件なら、表の結果がどうであれ、機能している仮説とは言えません。
• ローンチする仮説は必ず3つです。4つ目を加えると、注意とリストが分散します。
• 自社キャンペーンの数値がある場合は、常に市場ベンチマークより優先します。
• テストをクローズする担当者は、事前に決めておきます。決めておかないと、誰かが飽きるまでテストが続きます。

---

ヘルパースクリプト

scripts/score.pyが計算とキューの並べ替えを行うため、頭の中で重みを足し合わせる必要はありません。

python3 scripts/score.py hypotheses.json

入力形式、ゼロ点固定ルール、ゲートの処理方法はスクリプトのヘッダーに記載されています。レポートにそのまま貼り付けられる、順位付きのMarkdownテーブルが出力されます。

---

組み合わせ

• hypo-generator — エージェンシーの URL から仮説マトリクスを作成します。このスキルは、ローンチ前にその出力をスコアリングします。
• agency-signal-sourcer — トリガーごとの検出ツール、コスト、減衰期間を提供し、「データ収集コスト」と「トリガーの非自明性」の要因に反映します。
• anticopywriting-ai — 完成したレポートを誰かに送る前に、これに通してください。