従来のクラウド リード認定ツールでは、エンリッチメント コールとスコアリングの実行ごとに請求されたトークンが消費されるため、スタートアップ予算が浪費されます。 2026 年、パイプラインが最大になるとまさにそのコストが増大します。さらに悪いことに、多くのシステムが生の B2B 連絡先データと企業コンテキストをサードパーティに送信するため、現代のプライバシーへの期待の下では回避可能なコンプライアンス リスクが生じます。防御できるセールスリード管理を構築している場合は、データフローとコンピューティングの両方を制御する必要があります。
EasyClaw を使用してローカルでスクレイピングを実行し、Ollama および Llama 3 を介してローカル LLM を使用してデバイス上でリードをスコアリングし、リード認定スコアがしきい値を超えた場合にのみ Slack Webhook チームに通知します。このガイドでは、完全なローカル フローについて説明します。これにより、機密性の高い入力を非公開で閲覧、ユニットエコノミクスを予測できます。
問題点: プライバシー、コスト、トークンへの不安
エンリッチメントと反復分析をスケールするまでは、クラウドスコアリングは安っぽく感じられます。 各リードは複数の API 呼び出しをトリガーでき、各呼び出しは LLM トークンの使用をトリガーできます。
プライバシーは運用上の大きな罠です。生のリードデータを外部 AI サービスに送信すると、信頼、文書化、監査する必要があるプロセッサのセットが拡張されます。ベンダーが制御を主張している場合でも、顧客データがどのように送信および処理されるかについてのリスク姿勢は依然としてお客様が負っています。
ローカル デスクトップ パイプラインは両方の問題を解決します。抽出されたデータセットはマシン上に残り、モデルはローカルで実行され、リードに販売時間の価値がある場合、最小限の通知ペイロードのみが Slack に送信されます。
デスクトップ オートメーション アーキテクチャ (ビジュアル ロジック)
このプロセスを初期化するには、まずデータ パイプラインを定義して、すべてのコンポーネントが明確なコントラクトを持つようにします。次に、適合性の高いアカウントに対してのみリードスコアリングがリード認定となるゲートを適用します。
不透明な SaaS ワークフロー内にビジネス ルールを埋め込む代わりに、スクレイパーを実行する同じホスト上で評価基準をバージョン管理し、テスト可能で再現可能に検討します。
ステップ 1: EasyClaw デスクトップエージェントを介した生のリードデータの抽出
デスクトップ環境の準備ができたら、対象の B2B ネットワークからファーマグラフィック信号とテクノグラフィック信号の両方を取得するように EasyClaw を構成します。目標は「より多くのフィールド」ではなく、理想的な顧客プロファイルに対応する一貫したフィールドです。
まず、ICP に一致するソース サーフェスを選択します。 次に、抽出概念を定義して、会社名、業界、従業員の規模 (利用可能な場合)、役職、およびプロフィール ページにあるテクノロジのヒントをキャプチャします。 実際には、これらの技術的なブレッドクラムは、一般的な説明よりも認定の精度を高めることがよくあります。
EasyClaw は、ローカル スコアリング エンジンが毎回同じフィールドを採点できるように、リードごとに構造化された JSON レコードを発行する必要があります。
パイプラインをデバッグ可能にするには、生の抽出出力をタイムスタンプ付きでローカル フォルダーに保存します。これにより、後でセールス リード管理に関する質問が生じたときに監査証跡が得られ、再スクレイピングせずに新しいプロンプト バージョンを通じてリードを再生できるようになります。
ステップ 2: ローカル AI スコアリング エンジンのセットアップ (Ollama および Llama 3)
抽出後のエンジニアリングの次の課題は、ローカル モデルのエンドポイントが安定していて予測可能であることを確認することです。 Ollama をインストールし、ハードウェアで快適に実行できるモデルをプルします。 Llama 3 のバリアントは、構造化推論を正しく処理できるため、一般的な出発点となります。
Ollamaが実行されている場合、ローカルエンドポイントは http://localhost:11434 で利用できるはずです。 EasyClaw と統合する前に、最小限のカール リクエストでテストして、ネットワーク アクセス、モデルの読み込み時間、応答の形式を確認します。
マネーリードの評価には、決定的なスコアリング動作が必要です。可能な場合は固定生成構成を使用し、既知のスキーマに一致する JSON 出力を必要とします。ローカル モデルはドリフト可能性があるため、歌声側での強力な検証はオプションではありません。
次に、抽出されたリード JSON を受け入れ、Ollama API を呼び出すローカルの「スコアリング サービス」スクリプトを作成します。このサービスはスクレイピング出力と認定ロジックの間の境界となり、スクレイパー コードに触れる付近でプロンプトを進化させることができます。
ステップ 3: 目標となるリード適格性スコアのプロンプトを設計する
主観的な「最良の推測」によるテキスト生成に依存するのではなく、システム プロンプトと必要な出力スキーマを通じて厳密な採点パラメーターを適用します。モデルは、数値によるリード認定スコアと、特定の入力に関連付けられた短い正当化を生成する必要があります。
これを行うには、モデルに理想的な顧客プロファイル、評価ルーブリック、欠落データまたは矛盾したデータに対するペナルティを提供します。また、外部の知識を避け、指定されたリード フィールドから厳密にスコアを付けるようにモデルに指示します。
次のシステム プロンプト テンプレートを使用し、括弧で囲まれたフィールドを ICP ルーブリックに置き換えます。運用環境では、リポジトリ内でこのプロンプトのバージョンを設定し、スコアリングの結果とともに変更が追跡されるようにします。
You are a lead qualification scorer for B2B sales lead management.
You must output valid JSON only, matching the exact schema provided by the user.
Grading rubric:
Score from 0 to 100.
Assign points based on the following criteria:
1) Firmographic fit (0-40): industry match, company size/segment match, geography if provided.
2) Technographic fit (0-35): evidence of relevant stack/usage; reward explicit tech signals.
3) Role fit (0-20): title relevance and seniority; reward decision-maker indicators.
4) Data confidence (0-5): penalize missing fields, nulls, or vague/contradictory signals.
Hard rules:
If the lead lacks role title OR firmographic industry is null, subtract 20 points from the subtotal.
If technographic signals are absent (empty list), subtract 10 points.
Never invent missing data. Only use fields given in the input payload.
Return score as an integer.
Output JSON schema:
{
"leadQualificationScore": <integer 0-100>,
"fitSummary": "<one short sentence>",
"evidence": ["<field>: <reason>", "..."],
"rejectionReasons": ["<reason>", "..."]
}
スコアリングを実行するときは、入力フィールドに対応する証拠行を参照するようにモデルに指示します。これにより、生のトークン ログを読まなくても、営業担当者が信頼できる具体的な説明が作成されます。
最後に、JSON 応答を使用する前に検証します。解析が失敗した場合、またはスコアが範囲外の場合は、とりあえずで安全な低いスコアを設定し、デバッグ用に生のモデル応答を保存します。
ステップ 4: 自動 Webhook 経由で高スコアをルーティングすると Slack に接続
ローカル エンドポイントが生のデータセットを生成し、モデルが構造化スコアを返すと、ゲート ロジックはシンプルかつ厳密になります。リード認定スコアがしきい値 (80 など) を満たすリードをフィルタリングし、販売チャネルに通知するだけです。
スクレイピングされた各リードを読み取り、Ollama APIに投稿し、JSON出力を解析して、leadQualificationScore 条件を満たす場合は、一応のメッセージ ペイロードで Slack 受信 Webhook を呼び出します。
このパターンにより、Slack が機密の未加工フィールドを受信することがなくなります。完全なリードレコードを送信する代わりに、チームが行動する必要があるもの(会社名、役職、スコア、証拠の簡単な概要)のみを送信します。
以下は現実的な例です。 最初のリクエストは、ローカル Ollama API に送信される EasyClaw 生成のリード ペイロードです。 2 番目の応答には、フィルター エンジンがすぐに動作できる構造化スコアが表示されます。
{
"lead": {
"companyName": "Acme Logistics",
"industry": "Supply Chain SaaS",
"employeeRange": "51-200",
"location": "NA",
"leadPerson": {
"name": "J. Rivera",
"title": "VP Operations",
"seniority": "VP"
},
"technographics": {
"signals": ["uses: Salesforce", "mentions: NetSuite integrations"],
"confidence": 0.74
},
"source": "easyclaw-desktop-extract"
}
}
{
"leadQualificationScore": 86,
"fitSummary": "Strong firmographic and role fit with clear CRM/integration signals.",
"evidence": [
"industry: Supply Chain SaaS matches ICP segment",
"employeeRange: 51-200 aligns with target accounts",
"title: VP Operations indicates decision influence",
"technographics.signals: Salesforce and NetSuite integration mentions"
],
"rejectionReasons": []
}
Slack ルーティングを運用するために、通知ステップにローカル システムのリード レコードへの安定したリンクを含める必要があります。 CRM リンクがない場合は、ローカル識別子を生成し、完全なリード JSON を一緒に保存します。 これにより、通知は再スクレイピングせずに引き続きアクションが可能になります。
比較表: ローカルデスクトップ AI とサードパーティーのクラウドソフトウェア
トレードオフを説明する最も簡単な方法は、マーケティング上の主張ではなく、エンジニアリングと運用上の制約を並べて比較することです。以下は、独自の評価に使用する必要があるテクニカル ビューです。
| 指標/機能 | ローカル デスクトップ AI アーキテクチャ | サードパーティのクラウド SaaS ソフトウェア |
|---|---|---|
| リードごとのコンピューティングコスト | $0.00 (完全にローカル ハードウェアで実行) | API トークンおよびエンリッチメント コールあたりの従量制料金 |
| データプライバシーの境界 | 100%地元産。マシンからデータが流出することはありません | 外部プロセッサによるデータの処理と保持 |
| スクレイピングと抽出の制限 | EasyClaw による上限なしのシステム レベル制御 | プラットフォーム プロキシとクレジット制限の対象となる |
| カスタマイズの速度 | ローカルスクリプトコードによる即時プロンプト変更 | ベンダーの UI ワークフロー ビルダーに依存 |
ローカルアプローチでは、事前にエンジニアリング時間がかかりますが、見込み顧客の量が増加すると、毎月元が取れます。また、データ パスが透過的であるため、防御可能なプライバシーの姿勢も得られます。
戦略的 EasyClaw 統合 (ソフト CTA)
EasyClaw は、信頼性の高いデスクトップ スクレイピング、スキーマ一貫性のある抽出、乱雑な Web 入力をクリーンなレコードに変えるオーケストレーションなど、チームのボトルネックになりがちな役割を果たします。ローカル LLM スコアリング エンジンを備えた EasyClaw は、環境内に留まるセールスリード管理のためのプライベートデータ取得レイヤーになります。
圃場ごとにローイスクレーパーを作り直す必要はありません。抽出を一度構成すると、ローカル スコアリング プロンプトが安定した JSON を消費し、リード認定スコアを生成します。ルーブリックが変更された場合は、プロンプトを更新し、同じデータセットを再生します。
これを実際のチームで実行できるように次に、EasyClaw デスクトップは監査用に生の出力を保存し、再作業なしで繰り返し実行できるようにする必要もあります。
EasyClaw デスクトップをダウンロードし、最初の抽出ジョブを実行し、出力された JSON をローカルの Ollama スコアリング サービスに接続します。スコアゲートされたリードに対して最初の Slack アラートが到着すると、調整できる完全な閉ループが得られます。
結論と次のステップ
リードスコアリングをローカルで実行することで、トークン税の支払いを停止し、プライバシーの露出を減らすことができます。ワークフローは明確です。EasyClaw を使用してデバイス上で抽出し、localhost:11434 ローカル LLM を使用してスコアを付け、厳密なプロンプトによる客観的な評価を強制し、Webhook を使用して適切な結果のみを Slack に意見します。
次に、証拠に基づく採点でルーブリックを強化し、JSON 検証を追加して、入力とモデル出力の両方をログに記録して、安全に繰り返しできますように。最後に、リードの評価スコアのパフォーマンスをパイプラインの結果測定し、リードがそのようにスコア付けされた理由を理解した後のみしきい値を調整します。
実験から反復可能なセールスリード管理に移行したい場合は、まず EasyClaw デスクトップをダウンロードし、最初のローカル AI 認定ワークフローをエンドツーエンドで実行します。