hypo-generator

仮説ジェネレーター

ウェブサイトのURL（推奨）またはテキストの概要をもとに、ITエージェンシーのクライアント向けに10件の仮説からなるアウトリーチマトリクスを作成します。Viktor Shulha の2段階の手法と signals-catalog.md に基づいています。

出力の対象者： Viktor のクライアント（ITエージェンシーの創業者または事業開発チーム）です。仮説は、クライアント自身のアウトバウンド向けに作成します。Viktor がクライアントにアウトリーチするためのものではありません。

---

必須入力

次のいずれか：

• クライアントのURL（推奨）— エージェンシーの主要なマーケティングサイト
• テキストの概要 — エージェンシーの事業内容、顧客層、地域、最近の事例

任意（いずれも歓迎）：

• 地域の優先順位、または対象外の地域
• 注力する業界、または避ける業界
• 数値の成果を含む導入事例1～3件（根拠として推奨）
• 現在のアウトバウンドの状況（なし／場当たり的／SDRがいる／エージェンシーを利用）

---

ワークフロー

フェーズ1 — 調査（仮説を立てる前に、まず実施します）

URLが提供された場合：

1. WebFetch でホームページを取得します。以下を抽出します：
   • サービス／対応能力（提供するもの — デザイン、カスタム開発、モバイル、AI など）
   • 対象分野／業界（現在の顧客層）
   • 地域に関する情報（本社、チームの分布、販売地域）
   • 数値で示された成果を含む導入事例 — 顧客のロゴと数値を記録します
   • 既存のポジショニング（「Z によって X が Y を達成できるよう支援します」）
   • チーム規模／企業規模の手がかり（会社概要ページ、採用ページ）
   • 技術スタックの情報（導入事例で言及されているテクノロジー）
2. ホームページから /case-studies、/services、/industries へのリンクがある場合は、そのうち1～2ページを WebFetch で取得し、背景情報を掘り下げます。
3. 明示的な不足情報を記録します。重要な情報で、まだ分からないものを記載します。

テキストの概要が提供された場合：同じ項目を抽出し、不足している項目を示します。

フェーズ1.5 — 確認の質問をする（必要な場合のみ）

AskUserQuestion を使って、重要な不足情報だけを補います。質問しすぎないようにします。候補は次のとおりです：

• 地域の優先順位 — サイトから判断できない場合に質問します：米国／英国／EU／DACH／LATAM／指定なし？
• 対象外のセグメント — 明確に販売対象としない相手はありますか（例：暗号資産、ギャンブル）？
• 根拠として使う最適な導入事例 — 実際の数値成果（売上の増加、時間の節約、コンバージョンの改善）がある事例はどれですか（1～2件）？
• 現在のアウトバウンドの状況 — なし／SDRがいる／エージェンシーを利用／試して失敗した

サイトから分かる質問は省きます。質問は一度に最大4件までです。

フェーズ 2 — 仮説マトリクスを作成する

1. signals-catalog.md を読む（このスキルフォルダー内）。これはシグナルのライブラリです。シグナルを独自に考案せず、カタログから選んでください。

   運用面の連携： このスキルは STRATEGY レイヤー（どのシグナル × ICP × オファーに賭けるか）を担います。OPERATIONS レイヤー、つまり選んだシグナルの検出方法（どのツールを使うか、Clay のクレジットコスト、鮮度／減衰期間）、シグナルを持つアカウントのスコアリング方法、実行するシグナルからアクションへの GTM プレイについては、agency-signal-sourcer スキル（resources/detection-tools.md ⭐、scoring.md、gtm-plays.md）を使ってください。その detection-tools.md はフェーズ 3 の 「スクレイピングの容易さ」 の要素に直接反映され、taxonomy.md は signals-catalog.md に追加する価値のある新しいシグナルを見つけるのに役立ちます。

2. フェーズ 1 の調査結果に基づいて、ICP を 2～3 個定義します。各 ICP は（業界 × 企業規模 × 地域）で構成します。例：「米国のフィンテック、シリーズ A～B、従業員 50～200 人」、「英国の D2C E コマース、従業員 20～100 人」、「EU のヘルステック、シード後、従業員 10～50 人」。

3. カタログから ICP ごとにシグナルを 2～3 個選びます。静的データポイントのほうが強い課題の訴求につながる場合を除き、動的シグナル（タイミングベース、TAM の 3～5％）を優先してください。

4. フェーズ 1 のサービスとユースケースのマッピングに基づいて、オファーを 2～3 個選びます。各オファーは（サービス＋成果）で構成します。例：「新しい製品ラインを立ち上げるフィンテック創業者向けの、90 日間でのディスカバリー＋MVP」。

5. 組み合わせを交差させて、仮説を必ず 10 個作成します。考えられる 27 通りの組み合わせをすべて列挙せず、ICP × シグナル × オファーのバリエーションを持たせて、どの仮説も似通いすぎないようにしてください。

6. 各仮説について、次の 12 項目を記入します（Viktor の Hypothesis Report Template に対応）。

   項目	記入内容
   #	H01～H10
   Hyp name	短いラベル：「フィンテック、シリーズ A — 新製品のローンチ — Discovery+MVP」
   ICP	業界＋規模を 1 行で記載
   Persona (primary)	最初にターゲットとする人物の役職
   Buying committee	取引に影響を与えるその他の役職を 2～3 個、副箇条書きで記載
   Geo	地域
   Subindustry	該当する場合は、より細分化した業種
   Problem	相手が抱える、費用のかかる具体的な課題（1～2 文）
   Buying signal	使用する signals-catalog.md のトリガー
   Offer	サービス／成果の訴求方法
   Case study / Proof	実証材料として使用するエージェンシーの事例（実際の数値成果を含む）
   TAM	推定アカウント数＋簡潔な根拠（「米国のフィンテック、シリーズ A～B、従業員 50～200 人 ≈ LinkedIn 上で 800～1500 社」）
   Test batch	推奨する初回アウトリーチ規模。通常は 200～500 アカウント

フェーズ 3 — すべての仮説を採点する

Viktor の5 要素加重モデルを正確に適用します。各要素は 1、3、5 のいずれかで採点します。

要素	重み	採点基準
スクレイピングの容易さ	0.15	5 = Clay / LinkedIn / BuiltWith / Crunchbase でシグナルを簡単に検出できます。3 = LLM によるエンリッチメントまたは中程度の作業が必要です。1 = 手動での確認が必要、またはシグナルが非公開データ内にしかありません。
スケーリングの可能性	0.15	5 = TAM が 3,000 超で、シグナルが TAM の 5% 以上で継続的に発生します。3 = TAM が 300〜3,000、またはシグナルの発生頻度が低いです。1 = TAM が 300 未満、またはシグナルがまれにしか発生しません。
明確でコストのかかる課題	0.25	5 = 明らかな収益／コスト上の痛みを引き起こす課題です（「AE が時間の 40% を見込み顧客の開拓に費やしている」）。3 = 課題は実在しますが、緊急性はありません。1 = 課題は理論上のもの、または「あればよい」程度です。
提案との関連性	0.20	5 = エージェンシーが、この ICP とシグナルの組み合わせにぴったり合う事例と能力を備えています。3 = 近接した適合性があり、多少のポジショニング変更が必要です。1 = 無理があります。エージェンシーには、この領域での実績や能力がありません。
明確なトリガー	0.25	5 = シグナルが明確で、ほぼ常に買い手がその課題を抱えていることを意味します（「4 週間前に SDR の求人を掲載し、その後取り下げた」）。3 = シグナルは示唆的ですが、決定的ではありません（「チームの拡大中」）。1 = シグナルが弱く、一般的で、さまざまな意味に解釈できます。

合計スコア = Σ（スコア × 重み）。範囲：1.0 — 5.0。

判定基準：

• 合計 > 3.5 → 「最初に実施」—確信度が高いため、500 件以上のバッチから開始します
• 合計 3.0〜3.5 → 「テストする価値あり」—200〜300 件のバッチから開始し、すばやく反復します
• 合計 < 3.0 → 「見送る、または作り直す」—少なくとも 1 つの要素に根本的な問題があります

個々のスコアにはそれぞれ、1 行の根拠を付けてください（「明確なトリガー = 3：『最近の資金調達ラウンド』は検出できますが、資金調達した企業のすべてが今すぐアウトバウンド支援を必要としているわけではありません」）。

フェーズ 4 — レポートを生成する

以下の順序で、Markdown ドキュメントを 1 つ出力します。

# Hypothesis Report — [Client name]
Generated: YYYY-MM-DD · Source: [URL or "text brief"]

## Executive summary
- Strongest hypothesis: H0X — [name] — total score [X.X] — [one-line why]
- Weakest hypothesis kept: H0X — [name] — total score [X.X] — [why included anyway]
- Recommended starting batch: [H01, H03, H07] — total addressable accounts ≈ [X]
- Key risk in this client's portfolio: [one observation, e.g., "all 10 lean on Series A funding — concentration risk"]

## Phase 1 — What I extracted from the site
- **Services:** [list]
- **Existing use cases:** [list]
- **Vertical / industry signals:** [list]
- **Case studies with numbers:** [list with quantified outcomes]
- **Gaps I had to ask about:** [list]

## Summary table (all 10, sorted by score)

| # | Hypothesis | ICP | Persona | Signal | Offer | Final Score | Verdict |
|---|---|---|---|---|---|:---:|---|
| H01 | [short name] | [industry + size + geo] | [title] | [signal in plain words, e.g. "Hiring a BDR + sales is founder-led" — NOT the catalog ID] | [offer] | 4.70 | ✅ Run first |
| ... | ... | ... | ... | ... | ... | ... | ... |

Rules for this table:
- **Signals in plain words, never catalog IDs.** Write "New sales leader joined in last 90 days", not "A3/C5". The ID lives only in the detailed card below.
- **Final score only** — no per-factor breakdown in this table (that stays in the detailed cards).
- Verdict: ✅ Run first (>3.5) · ⚠️ Worth testing (3.0–3.5) · ❌ Skip/rework (<3.0).
- End with one line: **Старт: [H0X · H0X · H0X]** — the highest-conviction batch.

## Hypotheses (sorted by total score, descending)

### H01 — [Hyp name] — Total: 4.2 ✅ Run first

| Field | Value |
|---|---|
| ICP | ... |
| Persona (primary) | ... |
| Buying committee | • Title 1 (role) <br> • Title 2 (role) |
| Geo | ... |
| Subindustry | ... |
| Problem | ... |
| Buying signal | ... (from signals-catalog.md: section X) |
| Offer | ... |
| Case study / Proof | ... |
| TAM | ... |
| Test batch | ... |

**Scoring:**
- Easy to scrape: 5 (0.75) — [reason]
- Scaling: 5 (0.75) — [reason]
- Clear & expensive problem: 5 (1.25) — [reason]
- Offer relevance: 3 (0.60) — [reason]
- Trivial trigger: 5 (1.25) — [reason]
- **Total: 4.60 / 5.0**

---

[Repeat for H02 ... H10]

## Post-launch reference (Kill / Optimize / Scale)

After running a hypothesis with at least 200 accounts:
- **Kill:** reply rate < 1% OR interest rate (positive replies / all replies) < 17% → hypothesis disproven, find new signal or angle
- **Optimize:** interest rate 17–30% → potential. Test new copy angles, refine data filters, keep running
- **Scale:** interest rate > 30% → validated. Add LinkedIn channel, increase volume, promote to Tier 1

Speed of testing > polish. Get 3 hypotheses live in 7 days, not 1 hypothesis perfected in 30.

## Next steps
1. Validate TAM numbers in Apollo / Sales Navigator
2. Build account lists in Clay using the signals listed above
3. Draft copy variants for top 3 hypotheses
4. Set up tracking: reply rate + interest rate per hypothesis (not per campaign)

---

言語

デフォルト：ウクライナ語（Viktor のクライアントは、ウクライナ語を話す IT エージェンシーが大半です）。 ソース URL／ブリーフが英語であり、かつ Viktor が英語での出力を明示的に依頼した場合に限り、英語に切り替えます。

シグナルカタログ自体は英語のままにします（参照用です）。

---

厳守事項

• シグナルを捏造しないでください。 「Buying signal」フィールドには、必ず signals-catalog.md に記載されているシグナルを指定します。実際のシグナルが該当するもののカタログにない場合は、使用前にカタログへ追加し、「(new, added YYYY-MM-DD, needs validation)」という注記を付けます。
• 事例を捏造しないでください。 サイトに ICP 向けの数値成果を含む事例が掲載されていない場合は、その仮説に Proof: TBD — no matching case study on site, recommend adding one と記載します。捏造してはいけません。
• TAM には根拠が必要です。 「≈800-1500 accounts」だけでは不十分です。必ず情報源を添えてください（「LinkedIn Sales Nav のフィルターで抽出した、従業員 50〜200 人の米国フィンテック企業」など）。
• 仮説は 10 個ちょうどにしてください。 優先順位付けを徹底するためです。
• 最終確定前に多様性を確認してください： 2 つの仮説が ICP とシグナルの両方で一致する場合は、どちらかを置き換えます。ほぼ同じ仮説を提出しないでください。
• 各スコアに 1 行の理由を添えてください。 数字だけでは Viktor のレビューに役立ちません。

---

このスキルフォルダー内の参考資料

• signals-catalog.md — 使用する正式なシグナル／データポイントのライブラリ
• examples/example-report.md — 書式の期待値を示す完全なレポート例