DocketのAQLはMQLと同じに扱うか｜営業に渡す前の基準

「サイトのAIが『有望』と判定したリードを、営業がそのまま追いかけていいのか」「フォームから来たMQLと、AIとの会話で上がってきたリードの数字が混ざって、会議で毎回揉める」——サイトにAIの会話の窓口を置き始めたBtoB企業のマーケ部門とインサイドセールスから、こうした声が出ています。揉める原因は、AIの判定の精度ではありません。本当は、同じ「リード」という言葉の中に、作られ方の違う2種類が混ざっていることにあります。米国の Docket は、AIが会話で見極めたリードを AQL と呼び、MQL とは別のものとして数えるよう呼びかけています。この記事では、1人の訪問者がサイトに来てから初回の商談に入るまでを追いながら、AQL を MQL と同じ基準で営業に渡してよいか、渡す条件と判定の条件を誰が決めるかを整理します。

Docket は、サイトの訪問者と会話して見込みを見極めるAIエージェント

Docket は、BtoB企業のサイトに置き、訪問者と会話して見込みを見極めるAIエージェントの製品です。2026年10月時点の公式サイトでは、自社を「BtoBの売上の部門のための、エージェント型のマーケティング基盤」と説明しています。中心にあるのは、サイトの訪問者と文字や音声で会話し、質問に答え、見込みを見極め、営業との商談の予約まで進めるエージェントです。

公式サイトが挙げる機能には、訪問者の会社の特定、聞き取り、CRMへの記録、文字と音声の会話、追いかけの連絡、商談の振り分け、40以上の言語への対応、有望な訪問者が来たときの即時の通知があります。Salesforce や HubSpot、Marketo、Demandbase などとつながり、会話の文脈をCRMに書き込むとされています。

もう1つの柱が、エージェントが答えるときに使う社内の知識の置き場です。提供元はこれをセールス・ナレッジ・レイクと呼び、CRMの記録、Gong の通話の録音、Slack、Google ドライブ、Notion、SharePoint、製品の資料など50以上の情報源を取り込めると説明しています。エージェントは承認された資料からだけ答え、答えられない質問は人に回す、というのが公式の説明です。

つまり Docket は、サイトの問い合わせフォームの代わりに、営業の知識を持った会話の窓口を置く製品です。フォームが「名前と会社名を書いてもらって、後で営業が電話する」形だとすれば、Docket は「その場で話を聞き、見込みを見極めてから営業に渡す」形を目指しています。

パロアルトの会社と、国内でまだ知られていない理由

Docket は、米国カリフォルニア州パロアルトに所在地を置く会社です（公式サイトの表記）。公式サイトの事例には、複数の地域で事業を行う技術系の会社や、世界規模の金融の会社が並んでいます。資金調達の額は第三者のデータベースにしか見当たらなかったため、この記事では触れません。

日本語で Docket を紹介した記事は、2026年10月時点でほぼ見当たりません。1つめの理由は、画面と発信がすべて英語であることです。公式ブログも事例も英語で、日本の拠点や日本語の窓口は確かめられませんでした。

2つめは、料金の形です。公式の説明では、席の数や会話の数ではなく、サイトの月間の訪問者数で段が上がる年払いの料金になっています。最も小さい段でも月の訪問者数が数万人の規模を想定しており、訪問者の少ないBtoBのサイトでは、費用に見合うだけの会話の件数が集まりにくいという事情があります。

3つめは、会話の言語です。公式サイトは40以上の言語に対応するとしていますが、事例の中には44以上という記載もあり、数字が揃っていません。日本語での会話の自然さや、日本語の資料から答える質は、公式の情報からは確かめられませんでした。国内のサイトで使う場合は、試用の段階で日本語の会話を必ず確かめる必要があります。

2026年に出たもの：AQL の呼び方、Frameless、Showroom

2026年5月26日、Docket は公式ブログで AQL（Agent Qualified Lead、エージェントが見極めたリード）の定義を出しました。同社は、この呼び名を同じ月に自社が作ったと説明しています。定義は「構造化された、AIが主導する会話から生まれたリード」で、閲覧や資料のダウンロードから推し量るのではなく、買い手が会話の中で自分の言葉で述べたことに基づくリードだとされています。

2026年8月13日には、サイトの窓口を画面の隅の小窓ではなく、ページそのものに組み込む形の Frameless を公式ブログで発表しました。発表では自社のサイトに置いたアバターのエージェントが例として使われ、AIであることを明示し、訪問者が自分から話しかけたときにだけ会話を始め、音声をやめて文字に切り替えたり会話を終えたりできる作りだと説明されています。

ただし、2026年10月時点の公式サイトのよくある質問では、Frameless はまず自社のホームページで試し、顧客への提供は順次広げる段階とされ、各社向けに作り込む形で追加の費用がかかると書かれています。誰でもすぐ使える機能として扱わないよう注意が要ります。

2026年9月16日には、会話の中で実際の製品の画面を開いて見せる Showroom を発表しました。録画した説明ではなく、訪問者の質問に合わせてエージェントが製品の画面を操作して見せる、という機能です。発表の時点では自社のサイトのエージェントが最初に動かしているとされ、一般の提供の時期や料金は書かれていません。Frameless と Showroom は、2026年10月時点ではどちらも広く出回った機能ではないと押さえておきます。

AQL と MQL は「推し量る」と「本人が言った」の違い

提供元の説明を一言でまとめると、MQL は推し量ったもので、AQL は本人が述べたものです。MQL は、ページの閲覧、資料のダウンロード、メールの開封といった行動に点数を付け、一定の点を超えたら有望とみなします。AQL は、会話の中で買い手が用途を語り、制約を挙げ、懸念を口にし、次の一歩を求めたかどうかで決まります。

比べる軸	MQL（行動から推し量る）	AQL（会話で本人が述べる）
何から決まるか	閲覧・ダウンロード・開封などの行動の点数	会話の中で述べた用途・制約・懸念・次の一歩
判定の条件を書く人	マーケと営業が合意した点数の規則	導入企業が書く見極めの枠組みと、提供元が示す4つの条件
営業が受け取るもの	連絡先と行動の履歴	用途・制約・懸念・次の一歩をまとめた記録
間違えやすいところ	関心はあるが買う立場にない人も点が上がる	答えた資料が古い、条件の書き方が甘いと、整った形の外れが渡る
数える列	MQLの列	MQLとは別の列（混ぜない）

表の4行目が、この記事でいちばん大事なところです。提供元自身が、AQL は「エージェントの知識と条件と同じだけの質しかない」と書き、条件を誤れば「書式が整っただけのMQL」になると注意しています。会話から作られたリードだから確かだ、とは言えないということです。

MQLとSQLの定義そのものや、属性と行動で点を付ける設計については、別の記事で整理しています。ここでは、AQL という新しい種類のリードが入ってきたとき、それを既存の MQL の基準と同じに扱うかどうかに絞って、1人の訪問者の動きを追います。

シナリオの前提：料金ページに来た1人の訪問者を追う

ここからは、架空の1人の訪問者を追います。BtoBの業務ソフトを売る会社のサイトに、ある製造業の情報システムの担当者が、検索から料金ページに来たとします。サイトには Docket のエージェントが置かれ、問い合わせフォームも残っています。

追う段は6つです。会話が始まる、質問に答える、製品を見せる、見極める、営業に渡る、初回の商談に入る。各段で、エージェントが見ているもの、エージェントが使う条件を誰が書いたか、営業に渡る前に人が確かめることの3つを見ていきます。

このシナリオは、公式ブログと公式サイトで確かめた機能の範囲で組み立てています。各社の設定によって実際の動きは変わりますし、Showroom のように提供の範囲が限られる機能も含みます。製品の操作の手順ではなく、どの段で人の判断が要るかを見るための道筋として読んでください。

なお、サイトに来た訪問者に話しかけるAIの窓口をどこまで任せるかという接客の範囲の話は、別の製品を例にした記事で扱っています。ここでは接客の範囲ではなく、会話の結果を営業に渡す基準に絞ります。

段1　会話が始まる：AIが見ているものと、名乗る作法

訪問者が料金ページを開くと、エージェントが待っています。Frameless の発表では、エージェントは自分から話し出さず、訪問者が話しかけたときにだけ会話が始まる作りだと説明されていました。公式サイトの機能の一覧には、訪問者の会社を特定する機能も挙がっています。

この段でエージェントが見ているのは、どのページから来たか、どの会社からの訪問か、何を最初に聞いてきたかです。会話が始まる前から、会社の特定の結果は手に入ることになります。ここで部門が決めておくのは、会話を始めていない訪問者の会社の情報を、営業がどこまで使ってよいかです。会話の前の情報は、本人が述べたものではありません。AQL の考え方から言えば、ここはまだ推し量りの領域です。

もう1つは名乗りの作法です。提供元はAIであることを明示すると説明していますが、会話の記録をCRMに残すこと、その記録を営業が見ることを、訪問者にどう伝えるかは各社が決めることです。訪問者への告知と同意の扱いは、公式ブログでは触れられていなかったため、自社のプライバシーポリシーと照らして、法務と一緒に決めておきます。

段2　質問に答える：答えの元になる資料の棚を誰が決めたか

訪問者は「うちの既存の基幹システムとつながるか」「導入にどのくらいかかるか」と聞いてきます。エージェントは、セールス・ナレッジ・レイクに取り込んだ資料から答えます。公式の説明では、承認された資料からだけ答え、確信を持って答えられないときはそう伝えて人につなぐとされています。

ここで効いてくるのが、資料の棚を誰が決めたかです。取り込める情報源には、CRMの記録、通話の録音、Slack のやりとり、共有ドライブの資料が含まれます。社内向けの資料や、特定の顧客との通話の内容まで棚に入っていれば、それが訪問者への答えに混ざる危険があります。外に出してよい資料の棚を、取り込む前に決めておく必要があります。

棚の決め方の目安は、公開している製品の資料、公開している事例、営業が社外に出してよいと承認した説明資料までを答えの元にし、個別の顧客の情報、値引きの条件、開発中の機能の話は外すことです。棚の持ち主はマーケの責任者が担い、製品の資料が更新されたときに古い版を外す役も決めておきます。

答えの質は、そのまま AQL の質に跳ね返ります。古い料金や終わった機能をもとに会話が進めば、訪問者が述べた「用途」や「制約」も、間違った前提の上に乗ったものになるからです。

段3　製品を見せる：Showroom で見せてよい画面

訪問者が「実際の画面を見たい」と言えば、Showroom を使っている場合、エージェントが会話の中で製品の画面を開いて操作して見せます。公式ブログでは、録画した説明ではなく、必要に応じてその場で設定を変えながら見せる、と説明されています。

ここで決めることは2つあります。1つは、見せてよい画面の範囲です。デモ用の環境で見せるのか、どの機能まで見せるのか。開発中の機能や、特定の顧客向けに作った設定が見えてしまわないよう、見せる環境を分けておく必要があります。

もう1つは、見せたことが約束にならないようにすることです。訪問者の業務に合わせて設定を変えて見せると、訪問者は「この設定でこう動く」と受け取ります。デモで見せた動きと、契約で提供する範囲がずれていないかは、人が事前に確かめておく必要があります。2026年10月時点では Showroom の提供の範囲は限られているため、使う会社はまだ多くないはずですが、同じ形の機能はほかの製品にも広がると考えられます。

段4　見極める：4つの条件と、判定の条件を書いた人

会話が進むと、エージェントは訪問者が AQL にあたるかを見極めます。提供元が示す条件は4つで、用途がはっきりしたか、予算や時期や承認の流れといった制約が出たか、懸念が口にされたか、次の一歩が決まったか、です。

注意したいのは、提供元の発信の中でも、この条件の数え方が揺れていることです。2026年5月の定義の記事では「4つのうち3つ以上が満たされ、買い手が次の一歩を明示的に求めた」ときとされ、2026年10月8日の比較の記事のよくある質問では「4つのうち4つ」と書かれています。判定の条件は製品の既定値として受け取らず、自社で書いて固定する必要があるということです。

提供元も、何を「見極めた」とするかは導入する会社が決めるもので、予算・決裁者・必要性・時期を聞く既存の枠組みでも、独自の枠組みでもよいとしています。ここで書くのは、マーケだけでも、営業だけでもいけません。判定の条件は、営業が受け取ったときに追いかける価値があると認める基準だからです。判定の条件の持ち主は、マーケと営業の責任者の2人にするのが筋です。

もう1つ、例外の扱いも決めます。大口の既存顧客の担当者が来た、競合の会社からの訪問だった、学生や求職者だった、といった場面で、条件を満たしても AQL にしない、あるいは条件を満たさなくても営業に知らせる、という例外です。例外をエージェントの判断に任せず、一覧にして人が持ちます。

段5　営業に渡る：渡す前に人が確かめること

AQL と判定されると、CRMに文脈の記録が書き込まれ、営業に渡ります。公式ブログによれば、記録には訪問者自身の言葉での用途、満たした条件とその中身、予算・時期・技術の要件・承認の流れといった制約、出された懸念、会話の要約、決まった次の一歩が入ります。会話の全文ではなく、主なやりとりの要約だとされています。

この段で、営業に渡す前に人が確かめるかどうかを決めます。提供元は、会話の後に人が記録を読んで判定したものは AQL ではないとしています。しかし、それは呼び名の話です。導入の初めの数か月は、インサイドセールスが記録を読んでから営業に回す段を置くほうが、判定の条件の甘さに早く気づけます。

• 判定の条件を満たした根拠が、訪問者自身の言葉として記録に残っている
• 答えに使った資料が、外に出してよい棚の中の最新の版だった
• 会話の中で、価格・値引き・納期・機能の約束にあたる答えをしていない
• 訪問者が自社の既存顧客・競合・求職者などの例外にあたらない
• 次の一歩が、訪問者が自分から求めたものとして記録されている
• 記録の要約と、会話の主なやりとりの間に食い違いがない

このチェックは「AQL を営業に渡す条件」として、インサイドセールスの手順に入れておきます。確かめた結果、外したものは理由を付けて記録し、判定の条件を見直す材料にします。

段6　初回の商談：営業が受け取る記録と、受け取らない約束

営業は、文脈の記録を読んでから初回の商談に入ります。提供元は「最初の電話は、この記録から始まる。ゼロからではない」と書いています。用途や制約がすでに分かっているので、聞き取りを繰り返さずに提案の話に入れる、というのが AQL の売りです。

ここで起きやすいのは、エージェントが会話の中で言ったことを、訪問者が約束として受け取っているずれです。「その連携はできます」「導入は1か月ほどです」といった答えが、営業の知らないところで期待として残っています。営業は、記録の要約だけでなく、エージェントが答えた内容のうち、約束と受け取られうるものを商談の冒頭で確かめ直します。

価格や契約の条件、個別の値引き、納期の約束は、エージェントに答えさせない範囲として最初から外しておきます。答えさせない範囲は、段2の資料の棚の決め方とつながっています。棚に値引きの条件を入れなければ、エージェントは値引きを約束できないので、答えの範囲は棚で絞るのが確実です。

商談の後の連絡や、商談のために共有する資料をAIに任せる話は、別の製品を例にした記事で扱っています。ここでは、商談に入る時点で AQL の記録をどう扱うかまでにとどめます。

MQLと同じ列に混ぜない：会議で揉めない数え方

冒頭の「数字が混ざって会議で揉める」の答えは、数え方を分けることです。AQL と MQL は作られ方が違うので、同じ列で足し算すると、どちらの経路が効いているのかが見えなくなります。提供元も、両方の経路を並べて比べるやり方を勧めています。

この並べ方は、提供元の勧めをもとにしたもので、提供元に有利な結果が出ると決まっているわけではありません。公式ブログも、AQL の経路の成約の数字そのものは示していません。自社で測った数字で判断することが、AQL を MQL と同じに扱うかどうかの答えになります。

AIに任せる工程と、人が決める工程

ここまでの6つの段を、任せる工程と人が決める工程に分けて整理します。AIに任せてよいのは、会話そのもの、承認した資料からの回答、見極めの下書き、CRMへの記録の書き込み、商談の予約の提案です。人が決めるのは、営業に渡す基準、答えに使う資料の棚、価格や条件の約束、判定の例外、そして AQL を MQL と同じに扱うかどうかの判断です。

任せる工程の中でも、やってはいけない使い方があります。

• 提供元の示す条件の数をそのまま既定値として使い、自社の営業と判定の条件を合意しない
• 社内のやりとりや個別の顧客との通話の記録まで、答えの元の棚に入れる
• AQL の件数を、MQL の件数と同じ列で足して、マーケの成果として報告する
• エージェントの判定を、インサイドセールスの担当者個人の評価の数字に直接つなげる
• 価格や値引き、納期の質問にエージェントが答えられる状態のまま公開する

4つめは見落とされがちです。AQL が増えるとインサイドセールスの仕事は確かめの側に移りますが、エージェントが作ったリードの数で人を評価すると、判定の条件を甘くする動機が生まれます。条件の持ち主と、件数で評価される人を分けておく必要があります。

情シス向けの細かな管理の話には入りませんが、エージェントが CRM に書き込む権限の範囲も、マーケと情報システムの担当で一度確かめておきます。書き込めるのは新しいリードと記録までにし、既存の案件の金額や段階を書き換えられないようにするのが安全です。

何が外に出るか、費用の増え方、止め方

何が外に出るかについて、2026年10月時点の公式の説明では、訪問者との会話は提供元のモデルの学習に使わず、会話はCRMに導入企業のデータとして同期されるとされています。また、SOC 2（タイプ2）と ISO 27001 の取得、欧州の一般データ保護規則への準拠をうたい、通信と保存の暗号化、すべての会話の監査の記録を挙げています。契約が終わると顧客のデータを消すという記載もあります。

一方で、会話のデータを保存する地域、使っている大規模言語モデルの提供元、訪問者の個人情報の扱いの細目は、確かめた範囲の公式の情報には書かれていませんでした。国内の訪問者の会話が海外で処理されることになるため、自社のプライバシーポリシーの記載と、海外への移転の扱いを、導入前に法務と確かめます。

費用は、サイトの月間訪問者数の段で決まる年払いで、席の数や会話の数では増えないとされています。つまり、訪問者が増えて段が上がったときに費用が上がる形です。広告で一時的に訪問者を増やす施策を打つと、段の境目を越えることがあるので、広告の計画と合わせて見ておきます。Frameless のように各社向けに作り込む形は、別の費用がかかるとされています。

止め方も先に決めます。エージェントが誤った答えを続けた、資料の棚に入れてはいけないものが入っていた、と分かったときに、サイトからエージェントを外し、フォームだけに戻す手順と、その判断をする人を決めておきます。フォームを残しておくことは、比べるためだけでなく、止めたときの戻り先としても意味があるのです。

判定の条件を見直す場と、その持ち主

AQL の判定の条件は、一度書いたら終わりではありません。製品が変わり、価格が変わり、狙う顧客の層が変わるたびに、どの用途や制約を「見込みあり」とするかも変わります。見直しの場を、四半期に一度、マーケと営業とインサイドセールスの3者で持ちます。

見直しの材料は、段5で外したリードの理由、段6で営業が確かめ直した約束のずれ、STEPで並べた5つの数字です。営業が受け入れなかった AQL の理由を並べると、判定の条件のどこが甘いかが見えてきます。資料の棚の更新の漏れも、ここで見つかることが多いはずです。

見直しの結果は、判定の条件の版として残します。いつ、誰が、どの条件をどう変えたか。版が残っていれば、AQL の数字が急に増えたり減ったりしたときに、市場の変化なのか条件の変更なのかを分けられます。リードの点数の付け方そのものを見直す話は、リードスコアリングの記事でも扱っています。

最後に、AQL を MQL と同じに扱うかの答えを整理します。少なくとも自社で並べて測るまでは、同じに扱わないのが安全です。別の列で数え、確かめの段を置き、数字がそろってから渡す基準を決め直す。その判断をするのは、条件を書いたマーケと営業の責任者です。

まとめ

Docket は、サイトの訪問者とAIが会話して見極めたリードを AQL と呼び、行動から推し量る MQL と区別するよう打ち出している米国の製品です。2026年8月の Frameless と9月の Showroom で、ページに組み込む会話の窓口と、その場で製品を見せる機能を加えましたが、どちらも2026年10月時点では提供の範囲が限られています。AQL の確かさは、判定の条件と答えに使う資料の棚で決まり、どちらも導入する側が書くものです。条件はマーケと営業の責任者が書いて固定し、外に出してよい資料の棚を先に決め、初めの数か月は営業に渡す前に人が記録を確かめる。AQL と MQL は別の列で数え、自社で並べて測った数字で、渡す基準を決め直してください。

• 製品の機能と提供状況は、Docket の公式サイトと公式ブログを2026年10月22日に確かめた範囲に基づきます
• 保存の地域、使っている大規模言語モデルの提供元、訪問者への告知の扱い、日本語での会話の質は公式の情報で確かめられなかったため、導入の前に提供元に直接確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。