hypothesis-building について
hypothesis-building は、企業のコンテキスト、過去の受注事例、対象業界の知識から検証可能な課題仮説を作成します。外部調査を使わず、素早く仮説を立てたい GTM チーム向けで、後続スキルが利用できるファイルに保存します。
主な機能
- 01企業コンテキストと対象業界の読み込み
- 02受注事例から課題パターンを抽出
- 03検索の切り口を含む仮説の作成
- 04仮説セットのレビューと修正
- 05仮説を Markdown ファイルに保存
活用シーン
- 01知見のある新規業界の検索方針作成
- 02外部調査前の仮説の素早い作成
- 03新たな受注事例に基づく仮説の更新
- 04リスト作成とセグメンテーションへの活用
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ extruct-ai/ gtm-skills --skill hypothesis-buildingインストール後、Claude Code で/hypothesis-buildingを入力して読み込まれたか確認します。
詳細
仮説の構築
すでに把握している内容(ICP、受注事例、製品の価値提案、対象業界に関するユーザーの知識)から、検証可能な課題仮説を作成します。API キーや外部調査は不要です。文脈と会話に基づく純粋な推論です。
使用するタイミング
context-buildingの後、list-buildingの前- 新しい業界に参入し、何を検索すべきか定義する必要があるとき
- 深い調査をせずに仮説を立てられる程度に、その業界を把握しているとき
- (必要に応じて)
market-researchで検証する前に、素早く出発点を得たいとき
入力
| 入力 | ソース | 必須 |
|---|---|---|
| コンテキストファイル | claude-code-gtm/context/{company}_context.md | はい |
| 対象業界 | ユーザー入力 | はい |
| 追加の知識 | ユーザー入力 — 業界経験、既知の課題 | 推奨 |
| 既存の仮説セット | claude-code-gtm/context/{vertical-slug}/hypothesis_set.md | いいえ(改善モードの場合) |
出力
claude-code-gtm/context/{vertical-slug}/hypothesis_set.md
market-research の出力と同じパスおよび形式です。後続のすべてのスキルは変更せずに動作します。
ワークフロー
ステップ 1:コンテキストファイルを読む
claude-code-gtm/context/{company}_context.md を読み、以下を抽出します。
- ICP プロファイル — 購入者、企業規模、役割、地域
- 受注事例 — 過去の顧客が購入した理由、購入のきっかけとなった課題
- 製品の価値提案 — 製品の機能、主要な数値
- 有効な仮説 — コンテキストファイルにすでに記載されている仮説
ステップ 2:ユーザーから業界の情報を集める
ユーザーに次の質問をします。
| 質問 | 理由 |
|---|---|
| どの業界を対象にしていますか? | スラッグと対象範囲を定義します |
| どの地域を対象にしていますか? | 検索フィルターと地域ごとの課題を決めます |
| これらの企業の業務の進め方について、どのようなことをご存じですか? | 仮説を考えるための手がかりになります |
| 製品がこれらの企業のどのような課題を解決すると考えていますか? | 仮説を実際の価値に結び付けます |
| 気付いた具体的な兆候やパターンはありますか? | 実務に基づく知識を反映します |
会話形式で進めます。ユーザーが最初から豊富な情報を提示している場合は、すべての質問を無理に尋ねる必要はありません。
ステップ 3:受注事例からパターンを抽出する
コンテキストファイル内の各受注事例について、以下を特定します。
- きっかけ — 解決策を探す原因となった出来事や課題は何か
- ワークフロー上のギャップ — それまでは何をしていたか。何がうまくいかなくなったか
- 提供した価値 — 製品がもたらした具体的な成果は何か
- 適用可能性 — このパターンは対象業界にも当てはまるか
受注事例のパターンを、新しい業界で考えられる仮説に対応付けます。
ステップ 4:仮説を作成する
3〜7 個の仮説を作成します。各仮説には以下を含めます。
- 短い名前 — 3〜5 語のラベル
- 説明 — 課題、その発生理由、製品が適合する理由を説明する 2〜3 文
- 最適な対象 — 業界内で、最も当てはまる企業のタイプ
- 検索の切り口 — この課題に該当する企業を見つけるための、具体的な検索クエリまたは Discovery 条件を 1〜2 件
各仮説の品質チェック:
- 漠然とした業界トレンドではなく、具体的なワークフローや意思決定に関するものですか?
- 対象者は、自身の経験からその仮説を確認できますか?
- 製品の機能と結び付いていますか(無関係な課題を挙げているだけではありませんか)?
- リスト作成のクエリに使えるほど、検索の切り口が具体的ですか?
ステップ 5:ユーザーと確認する
仮説セット全体を提示し、次の点を尋ねます。
- 「これらは、業界についてのご認識と一致していますか?」
- 「追加、統合、削除したい仮説はありますか?」
- 「検索の切り口は十分に具体的ですか?」
フィードバックに基づいて改善します。これは対話形式で行い、1〜2 回のやり取りを想定してください。
ステップ 6:保存する
claude-code-gtm/context/{vertical-slug}/hypothesis_set.md に保存します。ディレクトリが存在しない場合は作成します。
出力形式
## Hypothesis Set: [Vertical]
### #1 [Short name]
[2-3 sentence description — the pain, why it exists, why the product fits]
Best fit: [company type within the vertical]
Search angle: [1-2 search queries or Discovery criteria to find these companies]
### #2 [Short name]
[2-3 sentence description]
Best fit: [company type]
Search angle: [search queries or criteria]
...
Search angle フィールドが、このスキルをリスト作成の前に使う価値を生みます。リスト作成で何を検索すべきかを直接示します。
改善モード
出力パスに仮説セットがすでに存在する場合は、改善モードに入ります。
- 既存の仮説セットを読み込みます
- 何が変わったかを確認します。新たな成功事例、キャンペーンの結果、業界知識などです
- 仮説を更新、統合、または追加します
- 可能な限り仮説の番号を維持します(後続の参照では
#Nが使用されます)
market-research との主な違い
| hypothesis-building | market-research | |
|---|---|---|
| 速度 | 高速 — 数分 | 低速 — 外部リサーチクエリ |
| 情報源 | 独自の知識 + コンテキストファイル | 外部リサーチ(例:Perplexity) |
| API キー | 不要 | 選択したプロバイダーの API キーが必要 |
| 最適な用途 | よく知っている業界での迅速な開始 | 知識のない業界への参入 |
| 出力 | hypothesis_set.md | hypothesis_set.md + sourcing_research.md |
この2つは相互に補完します。まず hypothesis-building で考えを定義し、その後 market-research で外部データを使って検証します。業界をよく知っている場合は、market-research を完全に省略してもかまいません。
出力の利用先
仮説セットは、次の用途で使用されます。
list-building— 検索の切り口がクエリ設計の指針になりますenrichment-design— 仮説に基づいてセグメンテーション列を設計しますlist-segmentation— 企業を仮説に照合して、階層に分類しますemail-prompt-building— 仮説が P1 メールの切り口になりますemail-generation— 仮説ごとにパーソナライズされた書き出しを生成しますemail-response-simulation— コピーが仮説に沿っているかを評価します