MQL/SQL定義をAI×受注データで自動化｜世界的SaaS企業の事例と理論に基づく再現可能な実装法

こんにちは。アイマケラボです。

このメディアでは「Marketing × AI実装」をテーマに、事業成長から逆算した実践的な体系をお届けしています。AIを「丸投げ」するのではなく、戦略設計は人間が行い、効率化・品質向上にAIを活用する方法論を追求しています。

今回のテーマは「MQL/SQL定義」、つまり「マーケティングと営業の間で"リードの質"の共通言語を作り、商談化率・受注率を最大化する仕組み」です。

BtoBマーケティングにおいて、リード獲得は手段であり、目的ではありません。獲得したリードの中から「本当に受注できる案件」を見極め、営業リソースを集中投下すること。ここに、マーケティングと営業の連携の本質があります。本記事では、その連携の「設計図」であるMQL/SQL定義を、理論とAI活用の両面から解説します。

はじめに

「マーケから送られてくるリード、ほとんど商談にならないんだけど」

営業からこう言われた経験はないでしょうか。

以下のような状況に心当たりはないでしょうか。

• 月間100件のリードを営業に渡しているが、商談化するのは10件以下

• 営業との定例ミーティングが「リードの質が悪い」という責任の押し付け合いになっている

• MQLの定義が「資料ダウンロードした人」だけで、受注確度を反映していない

• チャネル別のリード品質を測定していないため、SEO・広告・ウェビナーのどれが有効か分からない

• スコアリングを導入したが、高スコアのリードが実際には受注しないケースが頻発する

• 経営陣から「もっとリードの質を上げろ」と言われるが、何から手をつければよいか分からない

これらは「リード数」の問題ではありません。マーケティングと営業が「質」の共通言語を持っていないという構造的な問題です。

本記事では、MQL/SQL定義を「理論」と「AI活用」の両面から解説します。

デマンドウォーターフォール、The Model、BANTといった理論に基づいた設計原則を理解した上で、AIを活用して過去の受注データから「勝ちパターン」を自動抽出し、営業が納得するMQL/SQL定義を効率的に構築する方法を提供します。また、マーケ組織の成長、営業との合意形成、経営陣への提案といった組織展開についても解説します。

無料部分（第1〜3章、約10,000字）だけでも、MQL/SQL定義がなぜ重要なのか、世界的SaaS企業がどのようにリード管理を設計しているのか、AI活用の全体像を理解できます。

アイマケラボでは、AIマーケティングの最新情報を発信しています。

• note: https://note.com/aimarkelabo

• X（旧Twitter）: @aimarkelabo

役に立ったと感じたら、ぜひ「スキ」や「コメント」で感想を教えてください。励みになります。

第1章: なぜ今、MQL/SQL定義が営業効率を左右するのか

この章で得られるもの

• MQL/SQL定義が曖昧なまま放置することで生じる営業効率の損失の実態

• CAC高騰・チャネル多様化時代に「質」の管理が不可欠になった背景

• 営業とマーケの対立を生む構造的な原因と、その解決の方向性

マーケティングの全体像における位置づけ

事業の売上は、大きく「流入（需要獲得）× 転換（CV）× 単価（ARPA）」に分解できます。MQL/SQL定義が担うのは、このうちの転換（CV）を最大化する役割です。

マーケティングが獲得したリード（見込み顧客）を、営業が商談化しやすい状態に選別・育成する。このプロセスの精度が、商談化率と受注率を決定します。つまり、同じリード数でも、MQL/SQL定義の精度次第で売上は大きく変わるのです。

「リードの質が悪い」の正体

営業部門から「リードの質が悪い」という声が上がるとき、その裏側では3つの構造的な問題が同時に起きています。

1つめは指標の不一致です。マーケティングはMQL数（リード獲得数）をKPIに置き、営業は受注数をKPIに置いている。マーケは「目標の100件を達成した」と報告し、営業は「100件のうち使えたのは10件だけだった」と嘆く。双方の主張は正しいのに、見ている指標がズレているために対立が生まれます。

2つめはMQL定義の甘さです。「資料をダウンロードした人」「ウェビナーに参加した人」をすべてMQLとしている企業は少なくありません。しかし、資料ダウンロードの動機は「情報収集」から「導入検討」まで幅広く、一律にMQLとすれば当然、営業にとって「使えないリード」が大量に混ざります。

3つめはフィードバックの不在です。営業が「このリードは受注に至らなかった」と報告しても、その理由（予算不足なのか、ニーズがないのか、タイミングが合わないのか）がマーケティングに構造化された形で戻ってこない。結果、MQL定義は一度決めたら放置され、実態との乖離が広がり続けます。

この3つが組み合わさることで、営業は「マーケのリードは使えない」と感じ、マーケは「営業がちゃんとフォローしていない」と感じる。互いに正しいのに、互いに不満を抱く。これが多くのBtoB企業で繰り返されている「対立の構造」です。

なぜ今、MQL/SQL定義の再設計が急務なのか

3つの市場変化が、MQL/SQL定義の再設計を迫っています。

CAC（顧客獲得コスト）の高騰。デジタル広告の競争激化により、リード1件あたりの獲得コストは年々上昇しています。「リードをたくさん集めて営業に渡せばいい」という量の戦略は、もはやROIが合わなくなりつつあります。限られた予算で最大の成果を出すには、「質の高いリードに集中する」しかありません。

チャネルの多様化。SEO、リスティング広告、SNS広告、ウェビナー、LLMO（大規模言語モデル最適化）、ホワイトペーパー。リード獲得チャネルが増えたことで、チャネルごとのリード品質のバラつきが大きくなっています。SEO経由のリードとウェビナー経由のリードでは、温度感がまったく異なる。一律のMQL定義では、この違いを捉えられません。

AI活用の民主化。ChatGPTやClaudeの登場により、データ分析のハードルが劇的に下がりました。かつては専門のデータアナリストがいなければ実施できなかった「受注データの統計分析」「スコアリングモデルの構築」が、非エンジニアのマーケターでもAIの力で実現可能になっています。「スキルがないからできない」は、もはや言い訳になりません。

SQL化率の低さが引き起こす連鎖的な損失

SQL化率（MQL→SQLへの転換率）が低いまま放置すると、影響は営業の非効率にとどまりません。

営業チームが質の低いリードへの架電に時間を費やすと、本来受注できたはずの案件へのアプローチが遅れ、競合に先を越されます。受注率が下がればCAC回収期間が伸び、経営陣はマーケティング投資に対して慎重になる。結果としてマーケティング予算が削減され、リード獲得力が落ち、さらに営業から不満の声が上がる。負のスパイラルです。

逆に、SQL化率を改善すれば、営業が本当に受注可能な案件に集中でき、商談化率と受注率が同時に向上します。CACが下がり、LTV/CACが改善し、経営陣がマーケティング投資に前向きになる。この好循環を生み出す起点が、MQL/SQL定義の精緻化なのです。

第2章: 世界的SaaS企業のMQL/SQL設計と理論的フレームワーク

この章で得られるもの

• デマンドウォーターフォールからThe Modelまで、MQL/SQL定義を支える理論体系の全体像

• HubSpot、Salesforce、Slack、SmartHRの4社が実際にどのようにリード定義を設計しているか

• 4社の事例から導き出される、MQL/SQL定義の3つの共通原則

リード管理の理論は、なぜ20年かけて進化してきたのか

MQL/SQLという概念が生まれたのは2000年代初頭。デジタルマーケティングの発展により、マーケティング部門が「リード獲得」まで担うようになったことがきっかけです。

それ以前は、マーケティングは広告やPRで「認知」を獲得し、営業が「商談から受注」までを担う、シンプルな分業体制でした。ところが、Webサイトからの問い合わせ、ホワイトペーパーのダウンロード、セミナー参加といったデジタル接点が増えるにつれ、マーケティングが大量のリードを生成するようになりました。問題は、そのリードの「質」にバラつきがあったこと。営業が「商談にならないリード」の対応に追われ、本来受注できたはずの案件を逃すケースが頻発しました。

この課題を体系的に解決しようとしたのが、SiriusDecisions（現Forrester）が提唱したデマンドウォーターフォールです。

デマンドウォーターフォールの3世代

デマンドウォーターフォールは、2006年の初版から3回の大きな改訂を経て進化しています。

初版（2006年）では、リードを「Inquiry → MQL → SAL → SQL → Close」の5段階に分類しました。マーケティングが生成したリード（Inquiry）から、一定の基準を満たしたものをMQL（Marketing Qualified Lead: マーケティング適格リード）とし、営業が受け入れたものをSAL（Sales Accepted Lead: 営業受入リード）、営業が商談化可能と判断したものをSQL（Sales Qualified Lead: 営業適格リード）とする。このシンプルなファネル構造が、BtoBマーケティングの共通言語として急速に普及しました。

Rearchitected Demand Waterfall（2012年）では、大きな変更が加えられました。Inquiryの前に「Target Demand（ターゲット需要）」を追加し、ICP（Ideal Customer Profile: 理想的な顧客像）に合致するかどうかを最初に判定する設計に変わりました。これによりICP外のリードを早期に除外できるようになり、ファネル全体の効率が向上しました。

Demand Unit Waterfall（2017年）は、さらに根本的な転換でした。従来の「個人（リード）」単位から、「Demand Unit（購買グループ）」単位での管理に移行したのです。BtoBの購買は通常、1人では完結しません。決裁者、利用者、IT部門、調達部門など、複数の関係者が意思決定に関与します。1人のMQLを追うのではなく、購買に関わるグループ全体をスコアリングし、グループ単位でSQL判定を行う。この考え方は、特にエンタープライズ向けSaaS企業で大きな効果を発揮しています。

The Modelとリードの分業設計

デマンドウォーターフォールと並んで、MQL/SQL定義に大きな影響を与えたのが、アーロン・ロスが著書「Predictable Revenue」で提唱したThe Modelです。

The Modelの核心は、「マーケティング → インサイドセールス → フィールドセールス → カスタマーサクセス」という4段階の分業体制にあります。この分業体制において、各部門が「共通のリード定義」を持つことが不可欠です。

特に重要なのは、マーケティングとフィールドセールスの間にインサイドセールスが入る設計です。インサイドセールスは、マーケティングから渡されたMQLに対して架電やメールを行い、BANT（Budget: 予算、Authority: 決裁権、Needs: ニーズ、Timing: 導入時期）を確認します。BANTの確認ができたリードはSALとしてフィールドセールスに引き渡され、フィールドセールスが初回商談を実施した段階でSQLに昇格する。

この「人間によるフィルタリング工程」をマーケと営業の間に挟むことで、営業が対応するのは本当に受注可能な案件のみになります。The Modelが日本国内でも急速に普及した背景には、この「合理的な分業」の説得力がありました。

BANTの限界とMEDDICの台頭

MQL/SQL定義の判定基準として最も広く使われてきたのがBANTフレームワークです。IBMが1960年代に提唱したこのフレームワークは、Budget（予算）、Authority（決裁権）、Needs（ニーズ）、Timing（導入時期）の4要素でリードを評価します。

BANTは長らくSQL判定の標準的な基準として機能してきましたが、現代のBtoB購買プロセスには限界も見えています。

最大の限界は、購買プロセスの初期段階で「予算」と「決裁権」を確認するのが現実的ではないことです。SaaS製品の場合、現場の担当者がまず無料トライアルや資料ダウンロードから検討を始め、社内で評価を重ねた後に初めて予算化される。検討初期にはBudgetもAuthorityも定まっていないことが多いのです。BANTの4要素すべてが揃うのを待っていると、その時点ではすでに競合にも声をかけている可能性が高い。

この限界を補完するフレームワークとして注目されているのがMEDDICです。MEDDICは、Metrics（定量的な成果指標）、Economic Buyer（経済的意思決定者）、Decision Criteria（意思決定基準）、Decision Process（意思決定プロセス）、Identify Pain（課題の特定）、Champion（社内推進者）の6要素で構成されます。BANTが「4要素の有無」を判定するのに対し、MEDDICは「購買プロセスの構造」を理解することに重点を置いています。

実務上の使い分けとしては、MQL→SALの段階ではBANTのNeedsとTimingを中心に判定し、SAL→SQLの段階ではMEDDICのChampionとDecision Processを確認するという二段階の設計が効果的です。

事例1: HubSpot（米国・マーケティングオートメーションSaaS）

ここからは、実際にMQL/SQL定義を高度に設計している4社の事例を見ていきます。

HubSpotのリード管理設計は、スコアリングと人間による確認を巧みに組み合わせたハイブリッドモデルです。

HubSpotでは、MQLを「ホワイトペーパーダウンロード、ウェビナー参加、14日間トライアル開始のいずれかを実施し、かつニーズが確認できたリード」と定義しています。SQLは「BANTの4要素すべてが確認でき、営業が初回商談を実施したリード」です。

この設計の凄み

1つめは段階的な育成設計です。HubSpotでは、MQLを営業にいきなり渡すのではなく、インサイドセールスが架電してBANTを確認し、SALに昇格させます。SALのうち、フィールドセールスが初回商談を実施したものがSQLになる。この「MQL → SAL → SQL」の3段階を踏むことで、フィールドセールスが対応するのは本当に受注可能な案件のみになります。多くの企業がMQLをいきなり営業に渡して失敗する中、HubSpotはこの中間ステップを設計に組み込んでいるのです。

2つめはスコアリングとBANTの併用です。HubSpotのリードスコアリングは「属性スコア」と「行動スコア」の2軸で構成されています。属性スコアは企業規模、業種、役職など、行動スコアは資料ダウンロード、ウェビナー参加、価格ページの閲覧回数などを点数化する。スコアが閾値を超えたリードをインサイドセールスが架電対象とし、最終的にはインサイドセールスが電話でBANTを確認します。AIスコアリングで「量」を絞り、人間の判断で「質」を担保する。この設計思想は、自社のMQL/SQL定義を設計する際のお手本になります。

3つめはチャネル別のMQL定義の使い分けです。SEO経由のリードは「ホワイトペーパーダウンロード」をMQL基準とし、広告経由のリードは「デモ申込」をMQL基準としている。広告経由は獲得コストが高い分、より確度の高いアクションをMQL条件にしているのです。チャネルごとにリードの温度感が異なることを前提にした、合理的な定義です。

HubSpotから学ぶべき視点

• MQLとSQLの間にSAL（インサイドセールスによるBANT確認）を挟むことで、営業リソースを本当に受注可能な案件に集中させる

• スコアリングは「優先順位付け」のツールであり、SQL判定の最終決定は人間が行う

• チャネルごとにMQL基準を変え、リードの温度感に応じた柔軟な定義にする

事例2: Salesforce（米国・CRM SaaS）

SalesforceはThe Modelの実践企業であり、その分業設計は世界中のBtoB SaaS企業のお手本になっています。

特筆すべきは、インバウンドリード対応のインサイドセールスと、アウトバウンド開拓のBDR（Business Development Representative）を完全に分離している点です。インサイドセールスは「マーケが送ってきたMQLの温度感を高める」ことに集中し、BDRは「新規市場開拓」に集中する。役割を明確に分けることで、各チームの専門性が高まります。

この設計の凄み

1つめはインサイドセールスとBDRの分離による専門性の確保です。多くの企業では、インサイドセールスが「マーケからのMQL対応」と「アウトバウンド開拓」を兼任しています。結果として、どちらも中途半端になる。Salesforceはこの2つを完全に分け、それぞれに専用のKPIを設定しています。インサイドセールスのKPIは「SAL数」（MQLからSALへの転換数）、BDRのKPIは「新規商談数」。この明確な分業が、高い転換率を支えています。

2つめはAIを活用した予測スコアリングです。Salesforceの製品であるEinstein Lead Scoringは、過去の受注データを機械学習で分析し、「このリードが受注する確率」を自動で予測します。重要なのは、このスコアが「ブラックボックス」ではなく、スコアに影響した要因（企業規模、業種、直近の行動パターン等）を説明できる点です。営業がスコアを信頼するには、「なぜ高スコアなのか」の理由が見えなければなりません。

Salesforceから学ぶべき視点

• インバウンドとアウトバウンドの担当を分けることで、MQL対応の質が向上する

• AI予測スコアは「スコアの根拠」を説明できる設計にしないと、営業に使ってもらえない

• インサイドセールスとBDRそれぞれに固有のKPIを設定し、成果を可視化する

事例3: Slack（米国・ビジネスチャットSaaS）

Slackの事例は、プロダクトレッドグロース（PLG: Product-Led Growth）を採用する企業特有のMQL/SQL設計を示しています。

従来型のBtoB SaaS企業では、「資料ダウンロード」「ウェビナー参加」といったマーケティング施策の行動をMQL基準にします。Slackは違います。MQLを「無料プランで10名以上がアクティブに利用しているチーム」と定義しています。SQLは「10名以上のチームのうち、有料プランへのアップグレード意向を示し、かつ決裁権者が特定できているチーム」です。

この設計の凄み

1つめはプロダクト利用データをスコアリングの中心に据えている点です。資料ダウンロードは「関心がある」ことの指標に過ぎませんが、10名以上でアクティブに利用しているチームは「すでにSlackの価値を実感している」ことを意味します。受注確度が圧倒的に高い。PLG企業では、マーケティングの行動データよりも、プロダクトの利用データが最も信頼できるスコアリング指標になるのです。

2つめはセルフサーブとハイタッチの使い分けです。10名未満の小規模チームには営業は介入せず、完全にセルフサーブ（自動課金）で運営します。10名以上のチームにのみ、営業が積極的に介入してアップグレードを提案する。この切り分けにより、営業リソースを大口案件に集中させつつ、セルフサーブでも売上を積み上げる。リソース効率が最大化される設計です。

Slackから学ぶべき視点

• PLG企業では、プロダクト利用データ（ユーザー数、利用頻度）を最優先のMQL基準にすべき

• チーム規模に応じて営業介入の有無を分けることで、リソース配分を最適化する

• 無料プランの利用状況が「最強のリード情報」になる

事例4: SmartHR（日本・人事労務SaaS）

SmartHRは、国内のBtoB SaaS企業として、MQL/SQL定義の改善で劇的な成果を上げた事例です。

SmartHRでは、MQLを「資料ダウンロード、ウェビナー参加、デモ申込のいずれかを実施し、かつ従業員数30名以上の企業」と定義しています。SQLは「初回商談を実施し、かつ導入時期が3ヶ月以内に決まっている案件」です。

この設計の凄み

1つめはICPによる厳格な足切りです。SmartHRは、従業員数30名以上をICP（理想的な顧客）と定義し、30名未満のリードはMQLにすら含めません。人事労務SaaSの場合、従業員数が一定以上でなければプロダクトの価値を十分に感じてもらえず、チャーン（解約）リスクが高い。ICP外のリードに営業リソースを費やすのは、ROIの観点で合理的ではない。この冷徹な判断が、営業効率を大きく高めています。

2つめはMQL定義の厳格化によるSQL化率の劇的改善です。SmartHRは過去、「ウェビナー参加者」もMQLに含めていました。しかし、ウェビナー参加者の多くは「情報収集段階」であり、商談化しにくい。そこでMQL基準を「デモ申込」または「個別相談申込」に変更しました。MQL数は減りましたが、SQL化率が大幅に改善したのです。「量より質」への転換を、定義の厳格化で実現した好例です。

SmartHRから学ぶべき視点

• ICPを明確に定義し、ICP外のリードは早期に除外することで営業効率が大幅に向上する

• MQL定義を厳しくすることで、MQL数は減ってもSQL化率は改善する

• ウェビナー参加だけではMQLにしない、など「何をMQLにしないか」を決めることが重要

リードの3類型と最適アプローチ

4社の事例を踏まえると、リードは以下の3つのタイプに分類できます。この類型化を行うことで、各リードに対する最適なアプローチが明確になります。

今すぐ客（Hot Lead）

BANTの4要素がすべて揃っており、導入時期が3ヶ月以内に決まっているリードです。営業が即座に対応すべき最優先リード。フィールドセールスが直接アプローチし、商談から受注までを最短で進めます。全リードの中で占める割合は小さい（一般的に5〜15%程度）ですが、受注率が圧倒的に高いため、ここに営業リソースを集中させることが最重要です。

そのうち客（Warm Lead）

ニーズはあるものの、予算や導入時期が未定のリードです。ウェビナー参加者や情報収集目的の資料ダウンロードがこのカテゴリに該当します。インサイドセールスが定期的にフォローアップし、BANTの条件が揃った時点でSALに昇格させます。ナーチャリング（育成）の主な対象であり、メール配信やセミナー案内を通じて温度感を高める施策が有効です。

まだまだ客（Cold Lead）

情報収集段階であり、ニーズが明確でないリードです。ブログ記事の閲覧者やSNS経由の問い合わせなどが該当します。営業が個別にフォローするROIが合わないため、コンテンツ配信やメルマガによる自動的な育成に留めます。ただし、Coldのまま放置するのではなく、行動スコアの変化（価格ページの閲覧、事例ページの複数回閲覧など）をトリガーにして、Warmカテゴリへの昇格を自動検知する仕組みが必要です。

4社の事例から導き出される3つの共通原則

ここまで、HubSpot、Salesforce、Slack、SmartHRの4社を見てきました。業種もビジネスモデルも異なる4社ですが、MQL/SQL定義において共通する設計原則が浮かび上がります。

原則1: MQLとSQLの間に「人間による確認プロセス」を必ず挟む

HubSpotはインサイドセールスがBANT確認を行い、Salesforceはインサイドセールスが架電してSAL化し、Slackは決裁権者の特定を条件に含め、SmartHRは初回商談の実施をSQLの条件としている。AIスコアリングは「優先順位をつける」ためのツールであり、SQL判定の最終決定は人間が行うという思想が、4社に共通しています。

スコアリングだけでSQLを判定する企業がしばしば陥るのが、「スコアは高いのに受注しない」問題です。これはスコアリングが捉えきれない要素（社内の政治力学、競合の存在、予算枠の変動）があるためで、人間による最終確認がこのギャップを埋めます。

原則2: ICPを明確に定義し、ICP外のリードは早期に除外する

SmartHRは従業員数30名未満を対象外とし、Salesforceはエンタープライズ企業に集中しています。すべてのリードを平等に扱うのではなく、自社にとっての理想的な顧客像に合致しないリードを早期に「切る」判断が、ファネル全体の効率を大きく高めます。

ここで重要なのは、ICP外のリードを「捨てる」のではなく「後回しにする」という考え方です。ICP外のリードはMQLにはカウントせず、コンテンツ配信による自動育成に回し、将来的にICPに合致した場合（企業規模の拡大など）に再評価します。

原則3: チャネル別にMQL定義を最適化する

HubSpotがSEO経由と広告経由でMQL基準を変え、Slackがプロダクト利用データを活用し、SmartHRがウェビナー参加をMQLから除外した。チャネルごとにリードの温度感は異なるため、一律のMQL定義ではなく、チャネル特性を反映した定義にすることが必要です。

特にチャネル別の設計で見落とされがちなのは、同じ「資料ダウンロード」でも流入チャネルによって意味が変わるという点です。SEOからの自然流入で資料をダウンロードした人は、自ら課題を認識して検索し、能動的に情報を取りに来ています。一方、ディスプレイ広告経由で資料をダウンロードした人は、たまたま目に入った広告に反応しただけかもしれない。この差を定義に反映させるかどうかで、SQL化率は大きく変わります。

ここまでで、MQL/SQL定義の理論的背景と、世界的SaaS企業や国内成長企業の設計事例を見てきました。次の第3章では、これらの理論と事例を踏まえ、AIを活用してMQL/SQL定義をどのように効率的に設計・実装するかの全体像を解説します。

第3章: AIを活用したMQL/SQL定義の設計アプローチ

この章で得られるもの

• AI活用の3つの深度レベル（基礎・中級・上級）と、自分に合ったレベルの選び方

• 受注データの分析からスコアリングモデルの構築まで、AIで何がどこまで自動化できるかの全体像

• Claude Code（Cowork）とClaude in Chromeの使い分けの判断基準

非エンジニアでもデータ分析ができる時代

第2章で見た4社の事例には、共通する前提がありました。いずれの企業も、受注データの分析やスコアリングモデルの構築に、社内のデータアナリストやエンジニアのリソースを投入しています。

ではデータアナリストがいない企業は、MQL/SQL定義を精緻化できないのか。答えはNoです。AIの進化が、その前提を根底から覆しました。

かつてはPythonのスクリプトを書き、統計的な手法（ロジスティック回帰や決定木）を使ってスコアリングモデルを構築するには、データサイエンスの専門知識が必要でした。しかし現在では、CSVファイルを渡して「受注しやすい企業の特徴を抽出してください」と指示するだけで、AIがデータクレンジングから統計分析、モデル構築までを一気に実行してくれます。マーケターに求められるのは、統計の知識ではなく、正しい問いを立て、AIの出力を事業判断につなげる力です。

ここでは、AI活用の3つの深度レベルを紹介します。自社のリソースやスキルに応じて、最適なレベルを選んでください。

レベル1（基礎）: チャット型AIで受注パターンを探る

最も手軽なアプローチは、ChatGPTやClaudeなどのチャット型AIに受注データを直接コピペして分析を依頼する方法です。

※なお、実務で使える詳細なプロンプトや、より回答精度を高めるためのプロンプトは、第4章で提供しています。

過去6ヶ月の受注データ（企業規模、業種、流入チャネル、行動履歴、受注の有無など）をExcelやスプレッドシートからコピーし、チャットに貼り付けます。「この中から受注しやすい企業の共通パターンを5つ抽出してください」と依頼すれば、AIが傾向を分析し、MQL/SQL定義のたたき台を提案してくれます。

このアプローチの強みは、準備がほぼ不要で、今日から始められることです。CRMからデータをエクスポートし、そのままチャットに貼り付けるだけ。特別なツールもスキルも必要ありません。

一方で限界もあります。チャット型AIにコピペできるデータ量には上限があり、数百行を超える大規模データの分析には向きません。また、複数のデータソース（CRM、GA4、広告管理画面など）を横断的に分析することも難しい。レベル1は「まずやってみる」ための入口であり、本格的な分析にはレベル2以上が必要です。

レベル2（中級）: Claude in Chromeで画面を見ながら分析する

Claude in Chromeを使えば、CRMやMAツールの画面を開いたまま、ブラウザ上でAIに分析を依頼できます。データをコピペする手間が省けるだけでなく、画面に表示されている情報をAIが直接読み取って分析してくれます。

※なお、実務で使える詳細なプロンプトや、より回答精度を高めるためのプロンプトは、第4章で提供しています。

シナリオ1: CRM画面のリード一覧をリアルタイム分析

Salesforce、HubSpot、またはkintoneなどのCRMでリード一覧画面を開き、Claude in Chromeに分析を依頼します。入力項目としては、画面に表示されているリード情報（企業名、業種、従業員数、流入チャネル、行動履歴など）を基に、受注確度が高いリードの共通属性を抽出し、MQL基準の案を提案してもらいます。

このアプローチのメリットは、CRMにログインした状態でそのまま分析できるため、データエクスポートの手間がないことです。営業との定例ミーティング中に「今月のリード一覧を見ながら、受注確度の高い案件の特徴を抽出しよう」といった使い方ができます。

ただし、Claude in Chromeが読み取れるのはブラウザ画面に表示されている情報に限定されます。画面外のデータ（過去数ヶ月分のデータなど）を横断的に分析するには、レベル3のClaude Code（Cowork）が必要です。

レベル3（上級）: Claude Code（Cowork）で統合分析からスコアリングモデル構築まで

Claude Code（Cowork）は、ローカルのCSVファイルを直接読み込み、Pythonスクリプトを自動生成・実行して、高度なデータ分析を行えるツールです。MQL/SQL定義の設計においては、これが最も強力なアプローチになります。

※なお、実務で使える詳細なプロンプトや、より回答精度を高めるためのプロンプトは、第4章で提供しています。

シナリオ2: 受注データの統合分析とスコアリングモデルの自動構築

CRMからエクスポートした受注データ（CSV）、GA4のチャネル別データ（CSV）、広告管理画面のデータ（CSV）を用意します。Claude Code（Cowork）にこれらのファイルを参照させ、受注企業と非受注企業の属性差をPythonで統計的に分析し、属性スコアと行動スコアを組み合わせたスコアリングモデルを自動構築してもらいます。

具体的には、以下のような一連の処理が自動で実行されます。

1. データクレンジング（欠損値の処理、重複の除去、フォーマットの統一）

2. 受注企業と非受注企業の属性比較（企業規模、業種、チャネル別の受注率）

3. ロジスティック回帰や決定木によるスコアリングモデルの構築

4. 各属性の重要度（どの要素が受注確率に最も影響するか）の可視化

5. MQL/SQL閾値の提案（何点以上をMQL、何点以上をSQLとすべきか）

6. Googleスプレッドシート形式でのスコアリングシートの出力

シナリオ3: チャネル別リード品質の可視化レポート

GA4とCRMのデータを突合させ、チャネル別（SEO、リスティング広告、SNS広告、ウェビナー等）のSQL化率、商談化率、受注率、LTV、CACを算出し、レポートとして出力します。これにより、「どのチャネルのリードが最も質が高いか」が一目で分かり、予算配分の意思決定に使えます。

Claude Code（Cowork）の圧倒的な強みは、データクレンジングから統計分析、モデル構築、レポート出力までを一気通貫で処理できる点です。
レベル1やレベル2では「分析結果のテキスト」が出力されますが、レベル3では「実際に動くPythonスクリプト」と「すぐに使えるスプレッドシート」が生成されます。分析の再現性が格段に高く、データが更新されたら同じスクリプトを再実行するだけで最新の分析結果が得られます。

ツールの使い分け

AI活用のツール選択で迷った場合は、以下の基準で判断してください。

1. Claude Code（Cowork）: 万能型AI。ブラウザ操作、ローカルファイル分析、コード実行など、あらゆる高度なタスクに対応。（最優先推奨）

2. Claude in Chrome: 閲覧型AI。ブラウザで見ているページに対する即時のフィードバックや改善案出しに使用。

判断の目安は「処理の重さ」です。複数のCSVファイルを横断分析する、スコアリングモデルを構築する、レポートを自動生成するといった「重い処理」にはClaude Code（Cowork）を使います。CRM画面を見ながらリードの傾向を把握する、競合のリード獲得施策をサッと確認するといった「軽い処理」にはClaude in Chromeが適しています。

重要なのは、どのレベルでも「AIに丸投げ」しないことです。AIは過去データの統計的な傾向を分析するツールであり、「このリードが受注するかどうか」の最終判断は人間が行います。第2章で見たHubSpotやSalesforceの事例も、すべて「AIスコアリング + 人間による最終確認」のハイブリッド設計でした。AIの出力を鵜呑みにせず、営業の肌感覚やマーケターの事業理解と掛け合わせることで、精度の高いMQL/SQL定義が生まれます。

ここから先は有料部分です

第4章以降では、MQL/SQL定義の具体的な実装手順を解説します。

第4章: 実装手順

• 過去の受注データ分析とICPの抽出（AIプロンプト例付き）

• MQL/SQL定義シートの作成（テンプレート付き）

• スコアリングモデルの設計と実装（Googleスプレッドシート形式）

• チャネル別リード品質の可視化とROI最適化

第5章: 運用・改善

• 営業との合意形成プロセス（ROI試算シート、定例ミーティングアジェンダ）

• 定例ミーティングとフィードバックループの設計

• ROI計算と経営陣への提案

• リスク管理（営業との対立、データ品質問題）

第6章: まとめ・次のステップ

• 優先アクション（時系列）

• 特典資料案内（MQL/SQL定義シート、ROI試算シート、AIプロンプト集等）

有料部分では、コピペで使えるAIプロンプト例10種以上、Googleスプレッドシート形式のテンプレート、営業部門長説得用のROI試算シート等を提供します。

第4章: MQL/SQL定義の実装手順