MQL→SQL転換率をAIで上げる｜点数より「当てる理由」を付けて渡す【2026年版】
目次
月曜の定例で、マーケの担当者が「先月はMQLを100件渡しました」と報告する。インサイドセールスの責任者が「中身を見ると、すぐ当てられるのは10件くらいです」と返す。そこから先は、毎月同じ会話になります。マーケは「営業が追いかけていない」と思い、営業は「マーケは数だけ持ってくる」と思う。
MQL（マーケが「営業に渡してよい」と判断した見込み客）からSQL（営業が「商談として追う」と判断した見込み客）への転換率は、この押し付け合いがそのまま数字になったものです。そして多くの会社が、ここで最初に「スコアリングの精度を上げる」に手を付けます。
この記事では、点数を磨く前にやるべきこと、つまり渡すときに「なぜ今この会社に当てるのか」を付けることを、AIでどう回すかを整理します。支援先で動いた数字と、当社自身がつまずいた記録を使います。
この記事の要点
- MQL→SQL転換率が低いとき、詰まっているのは選別の精度より渡し方。点数は温度しか伝えず、営業が知りたい「何から聞けばいいか」が抜けている
- AIに寄せるのは、リード獲得直後の自動リサーチ／温度別のメール配信／毎朝の数字集めの3つ。どのリードを商談として追うかの最終判断は人に残す
- 渡す前に付けるのは「誰が・なぜ今・何から聞くか」の3行。これがあると、ISは1件目の電話から仮説を持って話せる
- SQLの定義は会議室で決めない。営業からの差し戻し理由を4週間集めて、そこから決め直す
- メールの開封はSQLの根拠にしない。当社では実際の送信より87秒前に「開封」が記録されたことがある
転換率が低いとき、詰まっているのは「選別」ではなく「渡し方」
結論から書くと、MQLの数が多すぎるのでも、営業が怠けているのでもないことがほとんどです。渡された情報だけでは、営業が最初の1本をかけられない。これが転換率を下げている実体です。
分業型の営業組織の弱点として、マーケと営業の間で「MQLの質」をめぐる押し付け合いが起きやすいことは国内でも指摘されています（URUTEQ）。ただ、現場で話を聞くと、争っているのは「質」という抽象的なものではありません。
営業が受け取るMQLは、たいてい次のような1行です。
| 渡されるもの | 営業がそこから考えること |
|---|---|
| 会社名・担当者名・役職 | どんな会社か調べないと電話できない |
| 資料ダウンロード（○○ガイド） | 興味があるのか、情報収集なのか分からない |
| スコア 72点 | 72点だと何を聞けばいいのか分からない |
| フォームの自由記入欄（空欄） | 困りごとが分からないので、汎用トークで当てるしかない |
この状態で当てた電話は、汎用トークになります。汎用トークで当てた見込み客は「今は情報収集中です」で終わり、営業の記録には「SQLにならず」と残る。マーケから見ると「渡したのに追ってもらえなかった」になります。転換率が低いのは、選別のせいではなく、選別した理由が営業に届いていないからです。
点数を付けても転換率が上がらない理由
リードスコアリングは、温度を1つの数字にまとめる仕組みです。資料を3つ読んだら+10点、料金ページを見たら+20点、という形です。これは「誰から当てるか」の順番を決めるのには役立ちます。
ただ、点数はなぜ温度が高いのかを運びません。料金ページを見た72点の会社と、採用ページを見た72点の会社は、同じ72点でも当て方がまったく違います。
私が人材系のスタートアップで営業をしていた頃、求人サイトに新しく出た求人を毎日集めて「採用に困っているサイン」として検知し、CRMが「次に電話すべき会社」を出す仕組みを作りました。これで営業が「次どこに電話しようか」と悩む時間が消え、インサイドセールスは1日120〜150件をかけられる体制になりました。
効いたのは点数ではなく、「この会社は昨日、営業職の求人を出した」という当てる理由でした。電話の1本目から「求人を拝見してお電話しました」と言える。理由があると、相手も聞く姿勢になります。
逆の経験もあります。SFAの会社にいた頃は、IT製品の比較サイト経由のリードを担当していました。比較サイトから来るのは、まだ情報収集段階の温度の低い見込み客が中心です。それでも、商談から受注までの率は15%で、社内平均の8%を上回っていました。温度が低いことは、捨てる理由にはならない。必要なのは点数で切ることではなく、どこから話を始めるかの手がかりです。
AIに寄せる作業と、人に残す判断
2026年のやり方は、マーケ担当がAIに1件ずつ質問することではありません。フォーム送信をきっかけにリサーチが自動で走り、営業の手元には仮説付きの下書きが届いている。人は中身を見て、出すかどうかを決めるだけです。
| 作業 | 誰がやるか | やり方 |
|---|---|---|
| リード獲得直後のリサーチ | AI | フォームの内容と企業情報から、温度と課題の仮説を付ける |
| 温度別のメール配信 | AI | すぐ商談にならなかった見込み客へ、温度に合わせたメールを自動で送る。返信が来たら人へ |
| 流入元・キーワード・AI検索の数字集め | AI | 毎朝1枚にまとめ、止める施策の候補まで出す |
| 記事・資料の制作 | AIが下書き、人が一次情報を入れる | 実測やお客様の言葉は人しか持っていない |
| どのリードを商談として追うか | 人 | AIの仮説を見て、ISが判断する |
| どの施策に予算を寄せるか | 人 | マーケの責任者が決める |
ここで大事なのは、選別そのものをAIに丸投げしないことです。AIがやるのは並べ替えと理由付けまで。「この会社は商談として追う」と決めるのは、その会社に電話をかける人です。決める人と電話する人が同じなら、SQLにならなかったときに「マーケのせい」と言う理由がなくなります。
この配線は、マーケとISの境目だけで終わりません。IS側でどこから触るかはインサイドセールスのAI化に、見込み客が入ってくる前の「気づく」側はリード獲得のAI自動化にまとめています。
渡す前に付ける3行｜誰が・なぜ今・何から聞くか
AIが付ける仮説は、長いレポートにしないほうが使われます。営業が電話の前に読むのは、せいぜい3行です。
| 行 | 中身 | 例 |
|---|---|---|
| 誰が | 役職と、その立場で困りそうなこと | 営業部長。商談数より受注率に責任を持つ立場 |
| なぜ今 | 直近の出来事（求人・資金調達・新拠点・フォームの記入内容） | 先週、インサイドセールスの求人を2件出している |
| 何から聞くか | 最初の質問を1つ | 「IS立ち上げで、最初に詰まっているのは人ですか、リストですか」 |
3行目が特に効きます。最初の質問が決まっていると、ISは汎用トークを使わずに済みます。相手から見ても「うちのことを調べてから電話してきた」と伝わる。これが、点数を何十項目に増やすよりも転換率に直接効きます。
当社が支援した上場企業の営業組織では、リード獲得時の自動リサーチから個別化したISメールを送る流れを作り、マーケ側ではリード数が1.5倍、ステップメール経由の商談化率が1.3倍になりました。HPのAIチャットから、商談なしで決まる受注も月10件出ています。ただし、数字が動くまでには3か月かかっています。
SQLの定義は「差し戻し」から決め直す
MQLとSQLの定義を会議室で決めると、たいてい「予算あり・決裁者あり・導入時期3か月以内」のような教科書どおりの条件になります。そしてその条件は、現場では誰も確かめられません。
おすすめは逆の順番です。営業がSQLにしなかった見込み客について、その理由を4週間記録する。
| 差し戻し理由 | 直す場所 |
|---|---|
| 調べても何の会社か分からなかった | 自動リサーチの対象項目 |
| 担当者に決める権限がなかった | 「誰が」の行の付け方 |
| 困りごとが合っていなかった | 「なぜ今」の根拠にした出来事 |
| 連絡がつかなかった | 渡してから初回接触までの時間 |
4週間分を並べると、どの行が外れているかが見えてきます。SQLの定義はその結果に合わせて書き直す。こうすると定義が「マーケと営業が合意した紙」ではなく、差し戻しが減るかどうかで確かめられるものになります。
ちなみに、HubSpotのような主要なCRMは、人の温度（MQL・SQLといった段階）と、案件の進み具合を別々の項目として持つ考え方を取っています（Blend B2B）。SQLにならなかった見込み客を「失注」にせず、温度の段階だけ戻して追い続けられる、という意味です。差し戻しを記録する場所も、この「温度」の側に置くと集計が崩れません。
反論：「AIで選別したら、取りこぼしが増えるのでは」
ここで必ず出る反論に先に答えます。「AIに選ばせたら、本当は脈のある会社を落とすのではないか」。
この心配は半分正しいです。AIの仮説は外れます。だからAIには「落とす」権限を持たせないのがこの設計の前提です。AIがやるのは、すぐ当てる側と、温度別のメールで追い続ける側に並べ替えることだけ。後ろに回した見込み客も、メールへの返信や提案ページの閲覧があれば、その時点で営業の手元に戻ります。
むしろ取りこぼしが多いのは、人が手で選別している今のほうです。忙しい週は、スコアの高い順に上から10件だけ当てて、残りは翌週に回る。翌週には新しいリードが来て、先週の分は誰も見なくなる。AIに寄せたいのは判断ではなく、この「誰も見なくなる」の部分です。
開封はSQLの根拠にしない｜当社がつまずいた点
当社でも、案件メールの開封を計測する仕組みを作っています。メールに小さな画像を入れ、読み込まれたら記録する一般的な方式です。
この仕組みで、実際にメールを送る87秒前に「開封」が1件記録されたことがありました。記録元はGmailの画像中継サーバーで、送信前の下書きの段階で画像が読み込まれたとみられます。送信時刻より前の記録は捨てる仕掛けを入れていたので案件の記録には混ざりませんでしたが、仕掛けがなければ「送った直後に開いてくれた、温度が高い」と判断していたところです。
調べると、開封の記録には構造的な限界があります。Gmailは画像を中継するので誰の端末か分からない。Apple Mailは受信した直後に画像を先読みする。法人のOutlookは画像を止めていることが多いので、記録が無いことが「読んでいない」を意味しない。
ここから読者が使える教訓は1つです。開封とクリックは、点数に足さない。当社では開封を「弱いシグナル」として案件の経緯に1行出すだけにし、営業の優先度や通知には使わないと決めました。SQLの根拠にするのは、返信と、提案ページを実際に読んだ記録のように、本人が手を動かした行動だけです。
30日で確かめる進め方
最後に、最小の始め方を置きます。
- 1週目：直近のMQLから20件を選び、AIに「誰が・なぜ今・何から聞くか」の3行を付けさせる。ISはそれを見てから当てる
- 2週目：同じ期間に、3行なしで当てたMQLを別に記録しておく。比べる相手がないと、何が効いたか説明できない
- 3〜4週目：SQLにしなかった理由を、上の表の4分類で記録する。3行のどの行が外れていたかを見る
最初に社内へ出す数字は、転換率ではなく差し戻し理由の内訳です。転換率は母数が少ないうちは上下にぶれます。「担当者に権限がなかった、が半分を占めていた」のような事実のほうが、マーケと営業の会話を押し付け合いから仕組みの話に変えてくれます。
浮いた時間の使い道まで決めておかないと、AIで速くなったぶんが「もっと件数を当てる」に戻ってしまう点にも注意してください（AIで時間は浮いたのに数字が動かないで詳しく書きました）。
よくある質問
Q. MQLとSQLの違いは何ですか？
MQLは、マーケが「営業に渡してよい」と判断した見込み客です。SQLは、営業が「商談として追う」と判断した見込み客です。違いは判断する人にあります。転換率が低い会社では、MQLの条件はマーケだけで、SQLの条件は営業だけで決められていて、両者がつながっていないことが多いです。
Q. MQL→SQL転換率は何%くらいが目安ですか？
業種、流入元、MQLの条件の置き方で大きく変わるので、他社の数字と比べることはおすすめしません。比較サイト経由とお問い合わせフォーム経由では温度がまったく違います。自社の中で、流入元ごと・3行の仮説ありなしごとに分けて、先月の自分と比べるほうが打ち手につながります。
Q. リードスコアリングのツールは不要ですか？
不要ではありません。誰から当てるかの順番を決めるには役立ちます。ただ、点数だけを渡しても営業は最初の質問を決められないので、点数に「なぜ今か」の理由を添えて渡してください。ツールを入れ替える前に、渡し方を変えるほうが早く効きます。
Q. 中小企業で、マーケとインサイドセールスが同じ人の場合はどうすればいいですか？
むしろ始めやすい形です。選別する人と電話する人が同じなので、押し付け合いが起きません。リード獲得直後に3行の仮説が届くところだけを自動化し、差し戻し理由の代わりに「当ててみて外れた理由」を自分で記録してください。
Q. AIで選別を自動化できますか？
できます。ただし、最初の20件は人が3行を見てから当て、外れ方を確かめてから範囲を広げるほうが失敗しません。自動化するのは並べ替えと理由付けまでにして、「この会社は追わない」と決める権限はAIに持たせないことをおすすめします。
---
執筆・監修：佐々木 優希（上場企業 営業統括 兼 AI責任者）