任意のリード行を受け取り、チームのICPルーブリックに照らし合わせて実行し、0〜10のスコア、ルーブリックを引用した基準ごとの根拠、ティアごとの推奨次アクション、ボーダーラインケースのエスカレーションフラグを返すClaude スキルです。Clay AIカラム、HubSpotのカスタムコードアクション、またはCSVに対するスタンドアロンのCLI実行に組み込めるよう設計されています。昨年から誰も更新していないスプレッドシートのスコアリングマトリクスを置き換えますが、インテントスコアリングや行動スコアリングもできると偽ることはしません——それはできません。
バンドルは apps/web/public/artifacts/lead-scoring-icp-rubric-skill/ に収録されており、SKILL.md とユーザーが初回実行前に適応させる3つの参照テンプレートが含まれています。
使用すべきタイミング
インバウンドのMQLがSDRチームのトリアージ能力を超えて積み上がっており、既存のスコアリングが存在しない（「すべてがリードだ」）か古くなっている（「HubSpotのスコアリングマトリクスは2023年に最後にキャリブレーションされ、誰も信頼していない」）場合にこのスキルを使用します。アウトバウンドにも有用です：エンリッチメント済みのコールドリストをアサインする前にスコアリングすれば、表面上は問題なく見えてもICP外の企業にSDRの時間を費やさずに済みます。
このスキルは適合スコアリングであり、インテントスコアリングではありません。「これは私たちにとって適切な種類の会社か」に答えるものであり、「今週市場にいるか」には答えません。この区別は重要です。適合スコアリングだけを行うと、現在のニーズがない優良適合アカウントをシーケンスに入れる一方で、積極的に購入しようとしている低適合アカウントを無視することになります。このスキルを、インマーケット行動をシグナルするもの（Bombora、6sense、自社のプロダクト利用イベント、価格ページのヒット）と組み合わせて、正確なルーティングを実現してください。
具体的には次の場所から呼び出します：
- リードテーブルのすべての新しい行に対して発火し、スコアと根拠を2つのカラムに書き戻すClay AIカラム。
Lifecycle stage = MQLによってトリガーされるワークフロー内のHubSpotカスタムコードアクション。スキルを呼び出し、スコアと根拠の両方をリードプロパティに書き戻します。- キャンペーン開始前の一回限りのリストスコアリングに便利な、CSVエクスポートに対するスタンドアロンCLI。
使用すべきでないタイミング
次の場合はこのスキルをスキップしてください：
- 人間が介在せずリードを自動却下したい場合。 アウトプットは推奨です。スキルはボーダーラインケースに明示的に
escalate: needs_human_reviewタグを付けますが、CティアまたはそれC以下のリードを削除するよう接続すると、ルーブリックが古くなるたびにサイレントにパイプラインを破壊します。少なくともCティアについては常にSDRレビューのパスを維持してください。 - 「ルーブリック」が感覚に頼っている場合。 スキルは明示的な重みとティア値を持たないルーブリックに対してスコアリングすることを拒否します。チームがAティアの業界が実際にどうあるべきかについての議論をまだ行っていない場合は、まずその議論を行ってください。スキルはソースが明確でなければルーブリックを守れません。
- 行動スコアリングやインテントスコアリングが必要な場合。 これは適合スコアリングのみです。「エンゲージメントスコア」や「最後のウェブサイト訪問」をルーブリックにエンコードしようとすると、常に更新が必要になります。時間変動シグナルには専用のインテントツールを使用し、このスキルは静的な適合シグナルに留めてください。
- 基準ごとの根拠を超えた説明可能性を必要とする規制ドメインで運用している場合。 基準ごとのアウトプットは監査可能ですが、規制機関に対して守れるモデルカードとは同じではありません。それが必要な場合は、Claude スキルではなく適切なスコアリングサービスに投資してください。
セットアップ
ルーブリックを作成できれば、セットアップには約30分かかります。ルーブリック自体にはさらに時間がかかります——通常はSDRマネージャー、AE、RevOpsの誰かが重みについて議論する60分のワーキングセッションです。
- スキルをインストールします。
apps/web/public/artifacts/lead-scoring-icp-rubric-skill/SKILL.mdとreferences/フォルダを.claude/skills/lead-scoring/ディレクトリ（またはclaude.aiのスキルとしてアップロード）に配置します。フロントマターのnameとdescriptionが関連するプロンプトでスキルをトリガーします。 - ルーブリックテンプレートを置き換えます。
references/1-icp-rubric-template.mdを開き、「Criteria」内のプレースホルダー行を実際の基準、重み（1〜5）、ティア値（A / B / C）に置き換えます。「Hard disqualifiers」セクションを埋めます——これらはLLMコールの前に決定論的なチェックとして実行されます。「Last edited」を更新すると、スキルがすべてのアウトプットフッターに印刷するSHA-256が現在のバージョンの所有者を反映します。 - ティア別アクションマトリクスを置き換えます。
references/2-tier-to-action-matrix.mdを開き、例の行をチームが各(tier, source_of_lead)の組み合わせで実際に行うことに置き換えます。デフォルトは合理的ですが、チーム固有ではありません。 - インプットソースを接続します。 Clayでは、AIカラムをスキルに向け、エンリッチメント済みのリード行を
leadとして、ルーブリックファイルをrubricとして、ソースカラムをsource_of_leadとして渡します。HubSpotでは、スキルをカスタムコードアクションでラップし、コンタクト+企業プロパティをleadオブジェクトに読み込み、構造化されたアウトプットを書き戻します。スクリプトでは、CSVをglob処理し、各行をポストし、スコアと根拠を2つの新しいカラムに書き込みます。 - デスティネーションを設定します。 スコアと根拠の両方をリードに渡します。スコアはナンバープロパティ（ルーティングロジック用）、根拠はロングテキストプロパティ（コール前に読むSDR用）に入れます。
escalateフィールドを別のブール値またはenum プロパティに接続し、SDRマネージャーがレビューのためにフィルタリングできるようにします。 - キャリブレーションします。 有効化する前に、過去6か月の成立案件20件と失注案件20件に対してスキルを実行します。スコア分布は2つのコホートを明確に分離するはずです。そうでない場合は、スキルではなくルーブリックに問題があります——ステップ2に戻り、重みを再議論してください。
スキルの実際の動作
スキルは固定の順序で4つのステップを実行します。前のステップが後のステップをゲートします。並列実行しないでください。
ステップ1 — 決定論的ファームグラフィックチェック。 LLMコールの前に、プレーンコードがルーブリックのハードディスクォリファイア（制裁対象国、ディスクォリファイ業界、フロア以下の従業員数、フリーメールドメイン）と必須フィールドチェック（email と company_domain が存在する必要がある）を実行します。ヒットすると引用とともに即座に返します——disqualified、またはフィールドが欠落している場合は escalate: insufficient_data。決定論的処理を先に行う理由：無料で、速く、幻覚を起こしません。3人のヘアサロンがエンタープライズSaaS ICPに該当しないことを確認するためにトークンを消費するのは無駄です。
ステップ2 — 明示的な重み付きによる基準ごとのLLMスコアリング。 残りの各基準について、モデルはティア（A / B / C）と、ルーブリック行を引用した一文の根拠を出力します。スキルはティア（A=3、B=2、C=1）に基準の重みを乗じて合計します。基準ごとに行う理由（全体的なプロンプトではなく）：全体的なアウトプットは基準を黙って混合し、リードが5ではなく8を取った理由をデバッグする能力が失われます。明示的な重み付けを行う理由（モデルにバランスを取らせるのではなく）：明示された重みだけがルーブリックを信頼できる情報源に保つ唯一の方法です。モデルが自分でバランスを決めると、ルーブリックのレビューが形だけのものになります。
ステップ3 — ボーダーラインケースの人間によるレビューへのフォールバック。 最終スコアがティア境界の0.5以内にある場合、または3つ以上の基準が欠落データまたは推測データでスコアリングされた場合、スキルは escalate: needs_human_review を設定し、欠落フィールドを名指しします。最もコストのかかるスコアリングの失敗は、自信のあるリードでの間違ったティアではなく——常にボーダーラインだったリードでの間違ったティアです。
ステップ4 — アウトプットの組み立て。 スキルは references/3-sample-output.md で説明されているMarkdownを出力します：ヘッドラインのスコアとティア、ティア別アクションマトリクスから結合した推奨次アクション、理由付きの基準ごとのテーブル、ディスクォリファイアチェック、データギャップリスト、ルーブリックのSHA-256と最終編集日のフッター。
コストの現実
リードごとのトークンコストはルーブリックのサイズによりますが、構造化された基準ごとのアウトプットを持つ典型的な6基準ルーブリックの場合、リードごとに概算で1,500〜2,500インプットトークン、400〜700アウトプットトークンを見込んでください。2026年後半のClaude Sonnet 4.x価格（インプット約$3/百万トークン、アウトプット約$15/百万トークン）では、スコアリング済みリードあたり約$0.01〜0.02です。
月間5,000件のインバウンドMQLを処理するチームは、Claudeトークンで月約$50〜100を支出します。月間50,000件のエンリッチメント済みアウトバウンドリードを処理するチームは月$500〜1,000を支出します——この規模ではバッチング、ルーブリックのプロンプトキャッシング、決定論的ステップによる事前フィルタリングが重要です。スキルはデフォルトでリードごとに単一の構造化プロンプト（6〜10の小さなプロンプトではなく）を使用し、トークン使用量を抑えています。
トークン以外のコストの方が大きいです。ルーブリックの構築は一度実施し四半期ごとに再実施する60分のワーキングセッションです。成立案件20件+失注案件20件によるキャリブレーションはさらに1時間かかります。ClayまたはHubSpotの統合を接続するのに半日かかります。その後は、ルーブリックがずれるまでスキルはハンズオフです。
成功指標
注目すべき指標はスコアから転換率の相関です：過去90日間にAにスコアリングされたリードのうち、商談に転換した割合はどれくらいか？Bにスコアリングされたリードは？Cは？曲線が単調であれば——AがBよりも高い転換率、BがCよりも高い転換率——ルーブリックは機能しています。CとBが同程度の転換率であれば、ルーブリックは適合と非適合を分離しておらず、再議論が必要です。
二次指標：Aティアリードへの最初のタッチまでのSDR時間。機能するスコアリングシステムはインバウンドの場合この時間を1時間未満に圧縮します。Aティアのリードが24時間キューで待機している場合、スコアリングではなくルーティングがボトルネックです。
代替手段との比較
vs HubSpot予測リードスコアリング。 HubSpotのビルトイン予測スコアは、過去の転換データでトレーニングされたブラックボックスです。十分な成立案件ボリュームがある場合に機能します（HubSpotは最低約500件の成立案件を推奨）。その閾値以下のチームには、モデルが学習するものがなく、スコアはノイズです。このスキルはルーブリックが手動で作成されるため初日から機能します。トレードオフ：HubSpotのモデルはルーブリック作成者が見逃すパターンをピックアップします。このスキルは書き留めたものしか知りません。ボリュームがある場合は両方実行してください——「何が驚きか」にHubSpotのスコアを使用し、「なぜこれがここにランキングされているか」にこのスキルの基準ごとの根拠を使用します。
vs Marketoの行動スコアリング。 Marketo（またはHubSpotの行動スコアリング）はエンゲージメントシグナル——メール開封、ページビュー、フォーム送信——を追跡してポイントを加算します。これはインテントスコアリングであり、適合スコアリングではなく、両者は異なる質問に答えます。メールを開封していない優良適合アカウントは依然として優良適合アカウントです。ブログを読みふけった低適合アカウントは依然として低適合アカウントです。このスキルに加えて行動スコアリングを使用してください。代替ではなく組み合わせとして：高適合+高インテント→AEダイレクト、高適合+低インテント→ナーチャリング、低適合+高インテント→SDRがAE接続前にフィットコールを実施。
vs 手動SDRレビュー。 週間50件未満のインバウンドリードの場合、SDRマネージャーによる手動レビューは本当に競争力があります——人間は「この会社がちょうど顧客を買収した、優先順位を上げよう」というニュアンスを捉えます。スキルが見逃すものです。週間約200件以上では、手動レビューがボトルネックになり一貫性が低下します。スキルはトークン予算に合わせてリニアにスケールしますが、人間はそうではありません。
注意点
- ルーブリックのずれ。 誰かがMarkdownのルーブリックを編集してリリースし、新しいスコアを読むSDRがdiffを見ない。6週間後、チームは従業員数の重みが誤って4から2に変更され、200件のストレッチティアのアカウントがサイレントにCに格下げされたことに気づきます。対策： スキルはすべてのアウトプットフッターにルーブリックのSHA-256を記録し、ハッシュが実行間で変化するたびに「ルーブリックが YYYY-MM-DD に更新されました」バナーを先頭に付加します。四半期ごとのカレンダーリマインダーが、編集がなくてもレビューを強制します。
- ソースバイアスの増幅。 成立案件セットから構築されたルーブリックは、すでに販売した先をエンコードします。それに対してスコアリングすると、隣接するICPに目が向かなくなり、パイプラインは時間の経過とともに昨年の顧客の類似企業に絞られます。対策： 四半期ごとに、スキルがCティアにスコアリングした20件のリードをサンプリングし、AEが実際に適合するかどうかを手動でレビューします。3件以上が誤分類されていた場合は、ルーブリックに「ストレッチICP」行を追加して再キャリブレーションしてください。
- 薄いデータへの誤った自信。 エンリッチメントが6基準中4基準で欠落している場合、7.4のスコアはほぼノイズですが権威があるように読めます。SDRはそれを自信のあるAティアとして扱い、コール準備をスキップします。対策： スキルは3つ以上の基準が欠落または推測データでスコアリングされた場合は常に
escalate: needs_human_reviewを設定し、欠落フィールドをリストした「Data gaps」セクションを追加します。SDRはヘッドラインナンバーより先にギャップセクションを読むよう訓練されています。 - 保護クラスのプロキシ。 良い意図があっても、「地域」に重みを付けたルーブリックは国籍に、「業界」は法務チームが喜ばない企業人口統計のプロキシに変わる可能性があります。対策： スキルは保護クラスのプロキシとして認識するフィールド（名前由来の性別、写真、年齢シグナル）を拒否します。ルーブリックを毎年、あまり明白でないプロキシを見分けられる人間と一緒にレビューしてください。
スタック
- Claude — スコアリングエンジンと根拠ジェネレーター。Sonnet 4.xはこのタスクのコスト対推論品質のスイートスポットです。HaikuはLLMステップで根拠品質が低下しますが、決定論的専用パスには機能します。
- Clay — アウトバウンドおよびコールドリストスコアリング用の優先リードソースおよびエンリッチメントレイヤー。AIカラムはすっきりした統合ポイントです。
- HubSpot — スコア、根拠、エスカレーションフラグ、ソース用のCRMデスティネーション。カスタムコードアクションはインバウンドMQLスコアリングの統合ポイントです。
- Markdownエディタとカレンダー — 地味な部品。ルーブリックはMarkdownに存在し、四半期レビューは誰かのカレンダーに存在し、モデル選択よりも両方が重要です。