lead-qualification

リード適格性判定エンジン

構造化された受付プロセスを通じて、カスタム条件に照らしてリードを適格性判定し、その後、信頼度評価と理由を付けてリードリストを並列でスコアリングします。

3 つの動作モード

モード 1：受付＋適格性判定

既存の適格性判定プロンプトがありません。受付を実施してプロンプトを作成し、保存してからリードを適格性判定します。

トリガー： ユーザーが適格性判定プロンプトファイルを指定していない。

モード 2：プロンプトを再利用＋適格性判定

ユーザーが既存の適格性判定プロンプトファイルを指定しています。受付は省略し、すぐにスコアリングに進みます。

トリガー： ユーザーが skills/lead-qualification/qualification-prompts/ 内のファイルにタグ付けする、またはそのファイルを参照する。

モード 3：調整／キャリブレーション

ユーザーが結果を確認し、条件の調整を希望しています。保存済みのプロンプトを更新し、再実行します。

トリガー： ユーザーが「調整して」「変更して」「それは違います」のようなことを言う、または適格性判定の結果に対するフィードバックを提供する。

---

フェーズ 1：受付（モード 1 のみ）

ユーザーが適格と見なす対象と不適格と見なす対象を、完全に把握することが目標です。ユーザーが効率よく回答できるよう、質問は複数まとめて提示します。

ラウンド 1 — 基本的な質問（一度にすべて提示）

これらの質問を番号付きリストで提示します。ユーザーには次のように伝えます。「関連する項目に回答し、該当しない項目は飛ばしてください。確認が必要な点があれば、追加で質問します。」

製品とキャンペーンの背景：

1. 製品／サービスを一文で説明すると、どのようなものですか？
2. どのような課題を、誰のために解決しますか？
3. 具体的なキャンペーンやアウトリーチの切り口は何ですか？（例：「シリーズ A の資金調達を終えたばかりの企業をターゲットにする」「競合 X から乗り換えるチームを狙う」）

企業レベルの条件： 4. どの規模の企業をターゲットにしていますか？（例：1～10 人、11～50 人、51～200 人、201～1000 人、1000 人以上） 5. どの業界や分野が適していますか？ 6. 明確に除外する業界や企業タイプはありますか？ 7. ターゲットとする地域はありますか？それとも全世界が対象ですか？ 8. 地域の除外条件はありますか？ 9. 企業のステージは重要ですか？（例：シード、シリーズ A、シリーズ B 以上、上場企業） 10. 該当する売上高や資金調達額の範囲はありますか？

担当者レベルの条件： 11. 理想的な購入担当者の役職や職務は何ですか？ 12. 明確に不適格とする役職はありますか？ 13. 職位のレベルは重要ですか？（例：ディレクター以上、VP 以上、C レベル必須） 14. どの部門に所属している必要がありますか？（例：成長、マーケティング、営業、エンジニアリング） 15. 現在の会社での最低在籍期間はありますか？（例：購買決定権を持つには 6 か月以上） 16. 社会人経験の年数は重要ですか？

行動面および状況面のシグナル： 17. 適格または不適格の判断につながるテックスタックのシグナルはありますか？（例：「Salesforce を使用している」＝適合度が高い） 18. 最近の企業活動は重要ですか？（例：積極的な採用、資金調達、製品のローンチ） 19. コンテンツや投稿に関するシグナルはありますか？（例：「AI について投稿した」＝関連性がある） 20. 購買意欲の高さや適合度の高さを示す、ほかのシグナルはありますか？

決定的な除外条件と即時適格条件： 21. どのようなものが絶対的な不適格条件ですか？ほかの要素にかかわらず、該当すれば即座に「対象外」となる条件を教えてください。 22. 最も強力な適格条件は何ですか？ほぼ確実に「対象」と判断できる条件を教えてください。

ラウンド 2 — 追加質問

ユーザーの回答を踏まえ、曖昧さを解消するため、対象を絞った追加質問を 5～10 個行います。例：

• 「ミッドマーケットとのことですが、従業員数は 50～500 人ですか、それとも 50～1000 人ですか？」
• 「VP of Growth とおっしゃいましたが、Head of Growth も対象ですか？それとも VP の肩書きがある人だけですか？」
• 「地域について言及がありませんでしたが、全世界を対象としてよいですか？」
• 「在籍期間は最低 6 か月とのことですが、社内昇進して 4 か月の人はどう扱いますか？」
• 「シリーズ A の企業を挙げていましたが、同等の売上があるブートストラップ企業はどうですか？」

Round 3 — エッジケースのシナリオ（任意ですが推奨）

境界ケースを検証する仮想のリードプロフィールを3～5件提示します。「この人は条件を満たしますか？」と尋ねます。

作成するシナリオの例（ユーザーの条件に合わせて調整します）：

• 肩書きは合っているものの、会社の規模がやや大きすぎる、または小さすぎる人
• 会社は条件に合っているものの、肩書きが境界線上にある人
• すべての条件に合致しているものの、在籍期間が短い人
• 肩書きは完全には一致しないものの、関心度を示すシグナルが強い人
• 競合他社の顧客である人

このラウンドでは、ユーザーが明示していない暗黙の条件を洗い出します。

適格性判定プロンプトを作成して保存する

インテークが完了したら、回答をすべて構造化された適格性判定プロンプトにまとめます。次の場所に保存します。

skills/lead-qualification/qualification-prompts/[campaign-name].md

保存するプロンプトは、以下の構成に従う必要があります。

# Qualification Prompt: [Campaign Name]

Generated: [date]

## Campaign Context
- **Product:** [one-liner]
- **Campaign Angle:** [specific angle]
- **Problem Solved:** [what and for whom]

## Hard Disqualifiers (Instant No)
- [list each with explanation]

## Hard Qualifiers (Instant Yes)
- [list each with explanation]

## Company Criteria
| Criterion | Qualified | Disqualified | Notes |
|-----------|-----------|--------------|-------|
| Size | [range] | [range] | |
| Industry | [list] | [list] | |
| Geography | [list] | [list] | |
| Stage | [list] | [list] | |
| Funding/Revenue | [range] | [range] | |

## Person Criteria
| Criterion | Qualified | Disqualified | Notes |
|-----------|-----------|--------------|-------|
| Titles | [list] | [list] | |
| Seniority | [level+] | [below level] | |
| Department | [list] | [list] | |
| Tenure | [minimum] | [below minimum] | |
| Experience | [range] | [range] | |

## Behavioral & Situational Signals
- [list signals that boost qualification]
- [list signals that reduce qualification]

## Confidence Rules
- **High Confidence:** Enough data available for company size, title, tenure, and at least one signal.
- **Medium Confidence:** Missing one or two non-critical data points but core criteria are clear.
- **Low Confidence:** Missing critical data points (e.g., no company size, unclear title). Still make a yes/no call but flag it.

## Edge Case Guidance
- [specific guidance derived from Round 3 scenarios]
- [any nuanced rules from the intake conversation]

## Qualification Reasoning Instructions
When evaluating a lead, structure your reasoning as:
1. Check hard disqualifiers first — if any match, immediately disqualify.
2. Check hard qualifiers — if any match, lean strongly toward qualifying.
3. Evaluate company criteria against thresholds.
4. Evaluate person criteria against thresholds.
5. Factor in behavioral/situational signals as tiebreakers.
6. Assign confidence based on data completeness.
7. Write 2-3 sentence reasoning summarizing the decision.

---

Phase 2: リードの適格性判定

Step 1 — 入力を解析する

以下のいずれかの形式の入力を受け付けます。

• Google Sheet URL — Rube MCP を使用して読み込みます（GOOGLESHEETS_GET_ALL_DATA_FROM_GOOGLE_SHEET など）
• CSV file path — ファイルシステムから直接読み込みます
• LinkedIn profile URLs — 1つ以上のURLがインラインで指定されます
• Inline list — メッセージに記載された名前／会社

形式を自動的に判別します。Google Sheet の場合は、RUBE_SEARCH_TOOLS を使って適切な Google Sheets 読み込みツールを探し、データを読み込みます。

Step 1.5 — Apify による一括エンリッチメント

実行する場合： 入力に linkedin_url 列が含まれている場合（または LinkedIn URL が利用できる場合）。 スキップする場合： LinkedIn URL がない場合、またはユーザーがエンリッチメントを明示的にスキップするよう指示した場合。

LLM による適格性判定の前に、すべてのリードを一括でエンリッチメントし、構造化されたプロフィールデータを収集します。これは、適格性判定中にリードごとにウェブ検索を行うよりも、はるかに速く、費用も抑えられます。

エンリッチメントスクリプトを実行します。

python3 skills/lead-qualification/scripts/enrich_leads.py INPUT_CSV \
  --output ENRICHED_CSV \
  --cache-hours 24

Apify を呼び出す前に、まず --dry-run を使ってコストの見積もりを表示します。

この処理の内容：

1. 入力 CSV からすべての LinkedIn URL を読み込みます
2. ローカルキャッシュ（デフォルトで24時間）を確認し、すでにエンリッチメント済みのプロフィールをスキップします
3. キャッシュにない URL を50件ずつ Apify に送信します
4. 次の項目を含むエンリッチメント済み CSV を返します：enriched_title、enriched_company、enriched_industry、enriched_location、enriched_connections、enriched_education、enriched_experience_years、enriched_headline、enriched_about、enrichment_status
5. コスト：約1,000プロフィールあたり3ドル（リード100件あたり約0.03ドル）

エンリッチメント後は、Step 2～4 の入力としてエンリッチメント済み CSV を使用します。 エンリッチメント済みデータを使うと、LLM による適格性判定ではウェブ検索の代わりに構造化されたフィールドを参照できるため、速度と一貫性が大幅に向上します。

一部のプロフィールでエンリッチメントに失敗した場合： 出力では、該当するプロフィールの enrichment_status が failed になります。LLM による適格性判定では、そのようなリードに限り、ウェブ検索に切り替えてください。

Step 2 — キャリブレーションバッチ

全リストを処理する前に、最初の5～10件のリードを処理し、結果を表にしてユーザーに提示します。

バッチエンリッチメントを実行した場合（Step 1.5）、主なデータソースとしてエンリッチメント済みの列（enriched_title、enriched_company など）を使用します。enrichment_status が failed または no_url のリードに限り、ウェブ検索に切り替えます。

| # | Name | Title | Company | Qualified | Confidence | Reasoning |
|---|------|-------|---------|-----------|------------|-----------|
| 1 | ... | ... | ... | Yes | High | ... |
| 2 | ... | ... | ... | No | Medium | ... |
| ... |

**「この結果でよさそうですか？ 全リストを処理する前に、条件を調整しますか？」**と尋ねます。

ユーザーから問題が指摘された場合：

1. どのような変更が必要か話し合います
2. 保存済みの適格性判定プロンプトファイルを更新します
3. キャリブレーションバッチを再実行します
4. 続行する前に、もう一度確認します

ユーザーの承認が得られるまで繰り返します。

ステップ 3 — 全件処理（並列化）

キャリブレーションが承認されたら、残りのすべてのリードを並列サブエージェントで処理します。必ず並列化してください。リードを順番に処理してはいけません。

並列化の手順（必須）：

1. バッチ数を計算する：

   • 残りのリード数 / 15 = バッチ数（切り上げ）
   • 目標：約15件のリードを1バッチにする
   • 最小：2バッチ（リストが少ない場合でも、並列化が機能することを検証するため）
   • 最大：同時に10バッチ（コンテキストの過負荷を避けるため）

2. バッチの入力を準備する： バッチごとに、自己完結型のコンテキストパッケージを作成します。

   • 完全な適格性判定プロンプト（qualification-prompts/ ファイルから）
   • リードの行のバッチ（Step 1.5 で追加したデータを含む、すべての列）
   • 出力形式の指示：名前、適格性（Yes/No）、確信度（High/Medium/Low）、判定理由（2～3文）
   • 次の指示：「enrichment_status=failed または no_url のリードについては、簡単にウェブ検索してください。検索にかける時間は、リード1件あたり30秒以内にしてください。」

3. Task エージェントを並列で起動する： Task ツールを使って、複数のツール呼び出しを含む1つのメッセージで、すべてのバッチを同時に起動します。

   Task: "Qualify leads batch 1/N"
   Context: [qualification prompt] + [batch 1 lead rows]
   
   Task: "Qualify leads batch 2/N"
   Context: [qualification prompt] + [batch 2 lead rows]
   
   ... (launch ALL at once — do NOT wait for batch 1 before launching batch 2)
   

4. 結果を収集して統合する：

   • すべての Task エージェントの完了を待ちます
   • すべてのバッチ結果を1つのリストに統合します
   • 入力データの元の行順を維持します
   • バッチが失敗した場合は、そのバッチを1回再試行します。再度失敗した場合は、そのリードに「qualification_failed」とフラグを付けて続行します。

5. 完全性を検証する：

   • 件数：適格 + 不適格 + 失敗 = 入力リードの合計
   • リードが不足している場合は、特定して再処理します

リードごとの処理（各バッチエージェント内）：

1. 入力行に含まれる利用可能なデータをすべて読み取ります（Step 1.5 で追加した列を含む）
2. エンリッチメントデータがある場合（enrichment_status: success または cached）：enriched_title、enriched_company などを使用します。
3. エンリッチメントデータがない場合（enrichment_status: failed または no_url）：簡単にウェブ検索します（最大30秒）。
4. 適格性判定プロンプトを適用します。
   • まずハード失格条件を確認します。一致するものがあれば、ただちに不適格と判定します。
   • ハード適格条件を確認します。一致するものがあれば、適格と判定する方向に大きく傾けます。
   • すべての基準を評価します。
   • 適格性（Yes/No）と確信度（High/Medium/Low）を判定します。
   • 2～3文の判定理由を記述します。
5. 結果を返します。

ステップ 4 — Google スプレッドシートに出力

優先：Rube MCP 経由で Google Sheets を使用

RUBE_SEARCH_TOOLS を使って Google Sheets ツールを探し、次の手順を実行します。

1. [Campaign Name] - Qualified Leads - [Date] という名前で新しい Google スプレッドシートを作成します。
2. 元の列をすべて含め、さらに次の3列を追加して書き込みます。
   • Qualified — Yes / No
   • Confidence — High / Medium / Low
   • Reasoning — 2～3文の説明
3. シートを整形します。
   • ヘッダー行を太字にし、濃い背景色にします。
   • Qualified 列を色分けします。Yes は緑、No は赤にします。
   • Confidence を色分けします。High は緑、Medium は黄、Low は赤にします。
   • 読みやすいように列幅を自動調整します。
   • ユーザーが Qualified/Confidence で絞り込めるよう、フィルター行を追加します。
4. Google スプレッドシートのリンクをユーザーに提示します。

フォールバック：CSV

Rube MCP を利用できない場合、または Google Sheets への接続に失敗した場合：

1. skills/lead-qualification/output/[campaign-name]-[date].csv に CSV を書き込みます。
2. 元のすべての列に加え、Qualified、Confidence、Reasoning を含めます。
3. ファイルパスをユーザーに伝えます。

ステップ 5 — 要約

出力が完了したら、次の要約を提示します。

## Qualification Results: [Campaign Name]

**Total leads processed:** X
**Qualified:** X (Y%)
**Disqualified:** X (Y%)

**Confidence breakdown:**
- High: X leads
- Medium: X leads
- Low: X leads (may need manual review)

**Top disqualification reasons:**
1. [reason] — X leads
2. [reason] — X leads
3. [reason] — X leads

**Output:** [Google Sheet link or CSV path]
**Qualification prompt saved to:** skills/lead-qualification/qualification-prompts/[campaign-name].md

---

必要なツール

適格性評価エージェントは、次のツールを利用できる必要があります。

• Apify LinkedIn Enrichment — 適格性評価の前にプロフィールを一括でエンリッチするための scripts/enrich_leads.py
  • supreme_coder~linkedin-profile-scraper Apify アクターを使用します（プロフィール 1,000 件あたり $3、Cookie 不要）
  • APIFY_API_TOKEN 環境変数が必要です
  • まず --dry-run を実行して、コストを確認してください
• Web Search — エンリッチメントデータが少ない、または不足している場合にリードを調査します
• Fetch (web page) — LinkedIn プロフィールや企業ページなどを取得します
• Rube MCP — Google Sheets の入出力に使用します
  • RUBE_SEARCH_TOOLS — 利用可能なツールを検出します
  • RUBE_MANAGE_CONNECTIONS — Google Sheets への接続が有効であることを確認します
  • RUBE_REMOTE_WORKBENCH — シート操作を実行します
• Task tool — サブエージェント間でリード処理を並列化します（ステップ 3 で必須）
• Read/Write — CSV の入出力と適格性評価プロンプトの保存に使用します
• Glob/Grep — 既存の適格性評価プロンプトファイルを検索します

---

使用例

Google Sheet から全件を取り込み、適格性を評価する：

Qualify leads for our outbound campaign. Here's the lead list: [Google Sheet URL]

→ 保存済みプロンプトがないことをエージェントが検出し、取り込みを開始してプロンプトを作成した後、適格性を評価します。

既存のプロンプトを再利用する：

Qualify these leads using @skills/lead-qualification/qualification-prompts/series-a-founders.md
— lead list: [Google Sheet URL]

→ エージェントは取り込みをスキップし、調整と適格性評価に進みます。

LinkedIn プロフィールを直接評価する：

Using the series-a-founders qualification prompt, qualify these people:
- https://linkedin.com/in/person1
- https://linkedin.com/in/person2
- https://linkedin.com/in/person3

結果を確認した後に調整する：

Those results look off — also disqualify anyone at a consulting firm, and lower the
tenure minimum to 3 months for Director+ titles.

→ エージェントは保存済みのプロンプトを更新して、再実行します。