AI見込み度スコアリングの仕組み｜AIは過去の受注を見ている

AIの見込み度スコアリングとは — ルール型と何が違うのか

見込み度スコアリングとは、資料請求や問い合わせで溜まったリードに点数を付け、どこから当たるかの順番を決める仕組みです。従来はこの配点を人が決めていました。資料をダウンロードしたら加点、価格ページを見たら加点、従業員数が一定以上なら加点、という形です。これがルール型で、配点の根拠は設計した担当者の経験則にあります。その経験則が実際の受注と合っているかは検証されないまま、何年も同じ配点で動き続けることが珍しくありません。担当者が異動すれば、なぜその点数なのかを説明できる人がいなくなります。

AI予測型はここが違います。過去の受注リードと失注リードのデータをAIが読み、どの項目が受注とどれだけ結びついていたかを自動で導きます。人は配点を決めません。人が決めるのは、何を受注とみなすかだけです。

ただし注意が必要なのは、「AIスコアリング」という言葉が二つの別物を指して使われている点です。ひとつは予測モデル型で、MAツールやCRMに搭載された予測リードスコア機能がこれにあたります。過去データを必要とし、点数は自動で出ます。もうひとつは生成AIによるルール設計支援で、対話型AIに「自社の商材ならどんな配点が妥当か」を相談するやり方です。過去データは要りませんが、出てくるのはルール型の配点案であって、予測ではありません。この二つは必要なデータも運用も別物です。

	ルール型	生成AIによるルール設計支援	AI予測モデル型
配点を決めるのは	人（担当者の経験則）	人（生成AIの案をもとに人が決定）	AI（過去データから自動導出）
必要なデータ	不要	商材・顧客像の情報	結果が出た過去リードの蓄積
自動更新	ありません（手で変えるまで固定）	ありません（相談のたびに作り直し）	あります（新しい結果を学び直します）
根拠の説明しやすさ	説明できますが、正しいかは別問題です	案の理由は聞けますが、自社実績の裏付けはありません	寄与項目を出せば説明できます

本記事が「仕組み」として扱うのは予測モデル型です。生成AIによる設計支援は補助として位置づけます。なお、リードをどう集めるか（フォーム設計やMA導入そのもの）は本記事の範囲外とします。

AIは「見込み度」を測っていない — 測っているのは過去の受注客との近さ

「AIで見込み度を測る」という言い方には、見込み度という値が相手の側にあらかじめ存在していて、それを人より正確に読み取るのがAIだ、という前提が隠れています。導入の検討がツールの比較表に終始しやすいのも、この前提があるからです。しかし、見込み度は顧客が持っている属性ではありません。同じ企業が、ある会社にとっては最優先の一件になり、別の会社にとっては当たっても決まらない一件になります。差を作っているのは相手ではなく、どんな課題を解ける商材を持ち、どんな当たり方で決めてきたかという自社の側です。

そう捉え直すと、スコアリングは測定の技術ではなく、自社の勝ち方を数式の形に要約する作業だと言えそうです。要約である以上、元になった勝ち方が偏っていれば、点数はその偏りも忠実に写します。精度が高いとは、正しさに近いことではなく、自社の過去に忠実であることかもしれません。

そして要約には、何を残して何を捨てるかという判断が必ず先に要ります。その判断だけは、計算の側に渡せません。この先で仕組みを分解していきますが、見どころは計算の中身よりも、人の判断がどこに残っているかのほうです。

AIスコアリングの説明でよく見かけるのは、「AIが精度高く自動で見込み度を判定してくれる」「属人的な勘に頼らなくて済む」という言い方です。しかし仕組みの側から見ると、この表現は実態を取り違えています。AI予測スコアが計算しているのは、見込み度という実体ではありません。計算しているのは、過去に自社が受注できた客と、そのリードがどれだけ似ているかという距離です。AIは未来を見ていません。見ているのは過去の自社の勝ちパターンです。

ここから三つの帰結が出ます。

第一に、過去に取れていない層は、永久に低スコアで出続けます。新しい業種や新しい規模帯に広げたいときにAIスコアを判断基準にすると、AIは「今までの客に似ていない」という理由でその層を下位に落とします。AIスコアリングは既存市場の刈り取りには効きますが、市場を広げる場面では逆に働きます。

第二に、過去の受注がたまたま取れたものであれば、AIはそのたまたまを再生産します。営業の当たり方が偏っていれば、その偏りごと学習します。そもそも架電しなかった層は、失注データですらなく、データとして存在しません。存在しないものをAIは評価できません。

第三に、だからこそAIに何を正解として渡すかが仕組みの起点になります。受注を正解にすれば、取りやすく単価の低い層が上位に来ます。受注金額で重み付けすれば大型案件寄りになりますが、学習に使える件数は減ります。この選択を人がやらない限り、AIは何も決めてくれません。

AI見込み度スコアリングの仕組み — 学習・予測・更新の3工程

多くの解説は、この仕組みを「機械学習が過去データから受注確度を予測します」の一文で通過します。それでは、自社で回せるかどうかの判断ができません。ここでは、人が触れる場所がどこにあるかという視点で、仕組みを学習・予測・更新の三工程に分解します。この三つのうち、AIが肩代わりしてくれるのは真ん中の予測だけです。最初の学習では人が正解を定義し、最後の更新では人が結果を入力します。仕組みが動かないときは、たいていAIではなくこの前後の工程が欠けています。

学習：「見込み度が高い」の正解を人が決める

AIに渡すのは二つの組です。ひとつは正解ラベル、つまりそのリードが受注したか失注したかという結果です。もうひとつは特徴量、つまりそのリードの属性や行動の記録です。この対を大量に読ませることで、AIは受注に結びつく条件を導きます。

正解ラベルの候補はひとつではありません。受注、商談化、一定金額以上の受注、契約後の継続利用。どれを正解に選ぶかで、出てくるスコアの意味はまったく変わります。期間の切り方も設計項目です。受注まで半年かかる商材で直近数か月だけを学習させると、まだ結果が出ていないリードがすべて失注として扱われ、実際には有望な層をAIが低く見積もります。失注理由が予算や時期であった案件を失注に含めるかどうかも、判断が要ります。ここを決めないまま導入すると、出てきた点数の意味を誰も説明できなくなります。

予測：AIが項目ごとの効き方を出し、新しいリードに確率を付ける

学習が終わると、AIは正解ラベルと特徴量の対応関係から、項目ごとの効き方、いわば重みを自動で導きます。ルール型と決定的に違うのは、この重みを人が振らない点です。担当者が「資料ダウンロードは何点にしよう」と悩む工程が、まるごと過去データの集計に置き換わります。

特徴量は大きく三系統に分かれます。それぞれ、効きやすい商材の型が異なります。

系統	具体例	効きやすい商材の型
属性	業種、従業員数、地域、担当者の役職	対象が業種や規模で絞られる商材に効きます
行動	資料ダウンロード、価格ページ閲覧、メール開封、サイト再訪	検討期間が長く、比較検討がWeb上で進む商材に効きます
タイミング	初回接触からの経過期間、行動の密度、直近の再訪	導入時期が予算期や更新期に縛られる商材に効きます

出力される値も、本質は点数ではありません。このリードが受注に至る確率が本体で、それを扱いやすくするために百点満点の点数やランクに変換して表示しています。点数は順位を付けるための表示形式である、と捉えておくと、後の検証がやりやすくなります。

更新：結果を戻して学び直す — ここがルール型との決定的な違い

新しい受注と失注が積み上がるたびに、モデルは学び直します。ルール型は誰かが手で配点を変えない限り、何年前に決めた配点でも同じまま動き続けます。予測型は、商材が変わっても、狙う市場が変わっても、新しい結果が入ってくれば自動で追随します。ここが両者の最も大きな差です。

ただし追随するのは、入力されたデータの範囲だけです。受注や失注の結果がCRMに入っていなければ、モデルは学び直す材料を得られません。案件がクローズしたのに商談ステータスが放置されていれば、その案件は学習に使われないか、最悪の場合は失注として扱われます。世に言う「AIスコアリングの精度」の正体は、その大半が、営業が受注と失注をきちんと入力しているかどうかです。アルゴリズムの優劣より先に、この入力運用が精度を決めます。

その点数の根拠は何か — AIが見た項目を確認する

AIスコアリングで現場が最初につまずくのは、精度ではなく説明のしづらさです。ルール型なら「価格ページを見たので加点しました」と言えました。予測型では配点を人が振っていないため、同じ説明ができません。説明できない点数は、営業が一度外した時点で信用を失い、二度と見られなくなります。この章では、点数の根拠をどう確認し、どこまで確認できたら運用に載せてよいかを扱います。ここは多くの解説記事が触れていない部分ですが、導入の成否を分けるのはむしろこちらです。

寄与度（何が点を押し上げたか）を出させる

主要なMAツールやCRMの予測スコア機能には、そのスコアに影響した項目を表示する機能があります。呼び名は製品によって寄与項目、重要な要因などさまざまですが、役割は同じです。まず、自社の環境でこれが表示される設定になっているかを確認します。

表示できるなら、上位スコアのリードをいくつか開いて、寄与項目を並べます。ここで価格ページの再訪や、想定顧客像に合う従業員規模といった、納得できる項目が並べば、その仕組みは運用に載せられます。逆に、メール開封回数だけが強く効いているなら注意が必要です。それは見込み度ではなく、配信頻度の差を学習している可能性があります。よく配信したセグメントほど開封が増え、開封が多い層に受注が多かった、というだけの関係を、AIが素直に拾っているわけです。

寄与項目	納得できるケース	疑うべきケース
メール開封回数	他の項目と並んで効いています	これだけが突出しています（配信頻度の差を学習している疑い）
資料ダウンロード	ダウンロード後の再訪や閲覧深度も併せて効いています	ダウンロード有無だけが効いています（競合や学生の混入の疑い）
業種・従業員数	想定顧客像と一致しています	想定と無関係な区分が効いています（母数の偏りの疑い）
特定ページの閲覧	価格・導入事例など検討段階を示すページです	採用情報など購買と無関係なページです

根拠を説明できないスコアは運用に載せない

営業に渡すのは点数ではありません。点数と、そう出た理由を一行添えたものです。「価格ページを繰り返し見ています」「想定顧客像に近い規模です」という一行があるだけで、架電の切り口が決まり、点数が業務の道具になります。理由が出せない仕組みは、外れたときに現場が疑う先を持てず、そのまま放置されます。

ツール側が寄与度を出せない場合は、自分で確かめる方法があります。上位群と下位群を一定件数ずつ抜き出し、業種構成、閲覧されたページ、流入経路、接触からの経過期間といった項目の分布を並べて比べます。何が効いているかは、機能に頼らなくても目視で相当つかめます。ここで両群の分布に差が見えないなら、そのスコアは順位を付けているだけで、内容を持っていません。運用に載せる前に、この確認を通しておきます。

スコアと受注がズレたときの読み方

導入後に必ず起きるのが、高スコアなのに失注した、低スコアなのに受注した、という食い違いです。多くの解説はここを「精度を検証し改善しましょう」で終えます。しかし現場が知りたいのは、何と何を比べれば検証したことになるのか、そしてズレを見つけたとき、どこを直せばよいのかです。この章では、測り方をひとつ、ズレの型を二方向から扱います。前章で述べたとおり、AIは過去の勝ちパターンとの近さを測っています。ズレは、その過去に無かった型が出てきた合図でもあります。

測り方：スコア帯ごとの受注率を並べる

検証の基本形はひとつです。スコアを帯に分け、帯ごとの商談化率と受注率を並べます。帯の区切りは、上位帯、中位帯、下位帯といった粗さで構いません。上の帯ほど率が高く、下の帯ほど低いという並びになっていれば、その仕組みは動いています。帯の間で率が逆転していたり、どの帯もほぼ同じ率なら、そのスコアはリードを並べ替えているだけで、受注とは結びついていません。

集計に必要な列は次のとおりです。

列	その列が示すもの
スコア帯	上位・中位・下位などの区切りです
件数	その帯に入ったリードの総数です
接触数	そのうち実際に営業が接触した数です
商談化率	接触数に対する商談化の割合です
受注率	接触数に対する受注の割合です

ここで落とし穴になるのが接触数です。上位帯にしか営業が接触しなければ、下位帯の受注率はそもそも測れず、検証が成立しません。スコアが低いから接触しない、接触しないから実績が出ない、実績が出ないからスコアが低いままになる、という循環が起きます。下位帯からも毎月一定数を必ず接触対象に残し、検証枠として扱います。

高スコアなのに失注する — 3つの型

高スコア失注が続くときは、疑う場所が三つあります。

ひとつめは情報収集層の混入です。資料ダウンロードやページ閲覧が多いのは、検討熱の高さとは限りません。競合企業の調査、学生の情報収集、社内の情報収集部門といった層は、行動量だけなら有望層と見分けが付きません。役職や企業実在性の確認を特徴量に足すか、該当する層を学習対象から除きます。

ふたつめはタイミングのズレです。属性も行動も想定顧客像と合っているのに、予算期や契約更新期がまだ先というケースです。今期の受注を正解ラベルにしている限り、AIはこの層を当てられません。時期を特徴量に入れるか、この層はナーチャリングに回す、という運用側の判断が要ります。

みっつめは過去の勝ちパターンの変質です。商材や価格帯、提供形態を変えたのに、古い期間のデータで学習を続けている場合、AIは今は取れない層を上位に出し続けます。学習期間を切り直します。

低スコアなのに受注する — 正解ラベルか材料の抜け

低スコアのまま受注したリードは、失敗例ではありません。モデルにとって未知の型であり、最も情報量が多いサンプルです。まとめて洗い出し、共通点を探します。

多いのは三つです。ひとつは紹介や既存顧客経由の案件で、Web上の行動がほとんど発生しないため、行動系の特徴量が積まれません。この場合は流入経路を特徴量に足します。ふたつめは新しいセグメントで、過去に取れていない層は低く出るという、前章で述べた性質そのものです。みっつめは正解ラベルの取りこぼしで、受注が受注としてCRMに記録されていないケースです。

切り分けの基準はこうです。低スコア受注が散発的なら個別事情ですが、一定の割合を超えて続くなら、直すべきはモデルではありません。正解ラベルの定義か、渡している材料のどちらかが抜けています。

症状	疑う場所	打ち手
高スコアで失注が続きます	特徴量（行動の質）	役職・企業実在性を足し、情報収集層を学習対象から外します
属性は合うのに決まりません	学習期間・正解ラベル	時期を特徴量に入れるか、ナーチャリング対象として分けます
上位の顔ぶれが現状と噛み合いません	学習期間	商材変更後の期間で学習し直します
低スコア受注が紹介経由に偏ります	特徴量（経路）	流入経路を材料に足します
低スコア受注が新しい業種に偏ります	正解ラベル・運用	AIスコアの適用範囲を既存市場に限定します
帯ごとの受注率に差が出ません	データ入力	受注・失注の入力状況と名寄せを点検します

どれくらいデータが必要か — 足りないときにやること

予測モデルの成否を決めるのは、リードの総数ではなく、結果が出たリードの件数です。受注がごく少数しかない状態でAIに学習させても、AIは「たまたま取れたその数件に似ているか」しか学べません。似ている順に並べることはできますが、その順番に意味があるとは限らず、検証しようにも比べる母数がありません。目安としては、受注と失注がそれぞれ相応の件数、少なくとも数十件の規模で蓄積されていることが出発点になります。必要な件数は商材の性質やツールによって変わるため、導入前に提供元へ確認しておくのが確実です。

足りないときの現実解は三段あります。第一に、ルール型で始め、配点の根拠を記録に残します。後でAIに切り替えたとき、何が効いていたのかを比べる材料になります。第二に、生成AIをルール設計の相談相手として使います。ただし出てきた配点は仮説であり、前章の検証にかける前提で扱います。第三に、受注・失注と失注理由をCRMに入力する運用を先に作ります。学習データは待っていても増えません。入力の運用がなければ、一年経っても件数はゼロのままです。

導入しない方がよい場面も、あらかじめはっきりさせておきます。リード数が少なく全件に接触できる場合、順番を決める必要がありません。商材が新しく受注実績が数件しかない場合、学ぶ材料がありません。商材が業種や規模を問わず広く刺さる場合、項目に差が出ないため順位が付きません。この三つに当てはまるなら、先に取り組むべきはスコアリングではなく、データが溜まる状態を作ることです。

何点から追うのか — 閾値を決めないとスコアは使われない

点数は出た、しかし営業は自分のやりやすい会社から架けている。導入後に最も多く起きるのがこの状態です。原因を精度に求めて、モデルの作り直しやツールの入れ替えを検討する会社は少なくありません。しかし多くの場合、原因は精度ではなく、線が引かれていないことにあります。序列だけを渡されても、現場は何点から動けばよいかを知りません。判断が個人に戻された結果、点数は参考情報として画面の隅に残ります。

必要なのは、点数と行動を結びつける取り決めです。上位帯はその日のうちにインサイドセールスが架電する、中位帯はナーチャリング配信の対象にとどめる、下位帯は当面追わない。何点で何をするかが決まって初めて、スコアは業務になります。

閾値は理想から決めません。今の体制で一週間に何件接触できるかから逆算します。週に架けられる件数が決まっているなら、その件数が上位に収まる点数が閾値です。帯ごとの受注率を測ってあれば、率が明確に落ちる境目を線にします。

渡し方も重要です。全件の序列を配るのではなく、今週着手する分のリストという形で渡します。前章で述べた理由の一行を添えます。そして現場から「この順番はおかしい」と声が上がったら、それは反発ではなく、軸の抜けを示すバグ報告として扱い、検証の工程に戻します。押し切れば、スコアは死にます。

データ品質と個人情報 — 導入前に固めておくこと

精度の前提は入力です。受注・失注がCRMに入っていない、失注理由が空欄のまま放置されている、同一企業の複数リードが名寄せされていない。この三つが残っている限り、どのツールを使っても精度は出ません。導入前のチェック項目として、この三点と、退職や異動で古くなった接触履歴の扱いを決めておきます。

個人情報の面では、スコアリングに使う行動履歴について、取得と利用目的を明示しているかを確認します。外部ツールへ提供する場合の扱いも同様です。生成AIに顧客データを投入する場合は、入力内容が学習に使われない設定・契約になっているかを先に確認します。

• MAツールを入れていなくてもできますか。予測モデル型は行動履歴の蓄積を前提とするため、CRMの受注・失注データだけで始める場合は属性中心のモデルになります。
• スコアはどのくらいの頻度で更新されますか。ツールによりますが、行動に応じた再計算とモデル自体の学習し直しは別の周期で動きます。両方の周期を確認してください。
• 途中でルール型に戻せますか。戻せます。並行運用して帯ごとの実績を比べれば、どちらが自社に合うかを判断できます。

あわせて読みたい

• クラウドの受注管理システムでできること｜機能表の先を読む──クラウドの利点、定着する運用、つないで効く一元化