Vercel に学ぶ ROI32倍の AI SDR エージェントの作り方 - どのようにしてインサイドセールスの体制を10人から1人に変えたか

インサイドセールスの人数を10人から1人に。年間コストわずか6万ドルに対し200万ドル超の効果を生み、ROI は約32倍。 Vercel の「 Lead Agent 」が報じた数字は、一見すると「 AI が SDR の仕事を奪った」話に見える。

だが、本記事が読み解くのはその表面ではない。トップセールスに張り付いて業務を言語化し、再現性のあるワークフローに分解した設計。過去データでの検証、 Slack を中心とした HITL 、社内の合意形成に要した5週間。商談化率を落とさずに体制を組み替えた背景に何が起きていたのか、自社で本当に再現できるのか、具体的にどう進めればよいのか、そこまで掘り下げる。

Vercel における AI SDR エージェントの役割とは？

AI SDR エージェントとは、インバウンドのリード対応のうち、調査、クオリフィケーション、初回メールの下書きといったパターンのあるワークフローを担う AI のことだ。人は最後にレビューして承認するだけで、残りは自動化されるというものだ。

ここでいう SDR は、問い合わせフォームなどから来たリードに最初に対応し、商談化させる価値があるかを見極める役割を指す。本記事では、 Vercel が自社で開発し公開した「 Lead Agent 」を題材に、業務の選び方からワークフロー、社内への組み込み方まで分解し、インサイドセールスのマネージャーが「自社で何をどう設計し直すか」を読み取れる形に整理する。

なお本記事は、Vercel の AI ネイティブ GTM 戦略 をメインの記事とする一連の解説の一つだ。全体像を先に押さえたい場合はそちらから読むことをお勧めしたい。

インバウンド対応の何が問題だったのか？

Vercel が AI を当てた最初の対象は、「遅くて、雑で、退屈な」インバウンド対応だった。

Lead Agent を率いた Vercel の GTM エンジニアリングの責任者であるドリュー・ブレッドヴィックによれば、問い合わせフォームは公開されているためスパムが大量に混じり、対応までに24〜48時間かかることもあった。リードは時間の空いた担当者へ機械的にアサインされ、相手のタイムゾーンや、誰が今対応できるか、誰がそのリードに最適かは考慮されていなかった。

担当者側の負担も大きい。1件のリードを調べるのに15〜20分かかる。 LinkedIn でリードの情報を確認し、会社の情報を調べ、 ChatGPT に要約させ、 CRM でプロダクトの利用状況を見る。6つ以上のサービスをタブで開き、最後は0からメールを書く。

ドリューの言葉を借りれば

「 AI が生成した内容を編集することは、0から書くよりも速い」

つまり、人が時間を使うべきは書くことではなく判断のはずだった。

参考:

• Building Vercel's First GTM Agent | Drew Bredvick
• I Replaced 100 Sales Jobs Using This AI App | Human in the Loop

お問い合わせ対応のコストと、 AI エージェント自動化による ROI はどの程度か？

たとえば月間120件のお問い合わせ受けているとする。1件あたり、調査20分、メール作成5分、修正・送信2分、合計27分かかるとすると、年間648時間がこの退屈な作業に消える。月間件数が増えるほど、各ステップの時間が積み上がり、マニュアル対応の年間にかかる時間はどんどん膨らむ。下の図はマニュアル時の内訳だ。

AI がリサーチから下書きまで済ませ、人が2分で承認・送信する設計に変えれば、同じ120件でも年間48時間程度まで落ちる。削減率は約93%だ。

ここまでを1件あたりの対応コストに換算してみる。年間の1人あたり人件費を800万円、稼働を1,920時間と仮定すると、1分あたり約69円になる。マニュアル対応は27分/件なので、1件あたり約1,860円かかる。 AI 導入後は人の作業が2分/件に圧縮でき、人件費は約140円。 AI エージェントの利用コストを1件150円程度だとし足すと、合計約290円になる。1件あたりの対応コストだけ見ても、マニュアル比で6倍以上の差が出る。

人件費が上がるほど、1件あたりのお問い合わせ対応自動化の ROI は高くなる。 AI のトークン料金が件数単位で固定だからだ。ただ、いずれにせよ400万〜1,000万円のレンジでは4倍以上を維持しており、単価だけ見ても十分に高い。

もちろん、ここまで見てきたのはあくまで「1件を処理するのにいくらかかるか」という切り口だ。それだけに限っても、4倍以上の差は小さい数字ではない。インパクトの面では、件数や人員規模が大きいほど効果は膨らむとはいえ、規模がまだ小さい段階でも、やっておくに越したことはない。

もっといえば、浮いた時間をアウトバウンドや既存顧客とのコミュニケーション等、もっと価値の高い活動に充てられるなら、全体の ROI はさらに大きくなる。浮いた人員を別の仕事に再編成できる規模になれば、削減効果は1件単価の掛け算では収まらない。 Vercel では、この積み上がりの先で専任10人体制を1人に再編でき、年間コスト約6万ドルに対し200万ドル超の効果が報告され、ROI は約32倍に達した。

Vercel はどのようにしてインサイドセールスの体制を10人から1人に再編成したのか？

簡潔に言えば、トップセールスのやり方を観察して言語化し、それを AI を含めたワークフローに起こすことで実現した。

Business Insider の報道によれば、この取り組みは2025年6月にセールスチームの社内プロジェクトとして始まった。 COO のジーン・グロッサーが3人のエンジニアを集め、10人いたインサイドセールスのうち最もパフォーマンスの高い1人に張り付き、その仕事の手順を一つずつドキュメントに起こした。そのうえで、その手順を再現する AI エージェントを作った。

グロッサーはこう言う。

「業務フローをドキュメントに起こせるなら、それを AI エージェントにやらせるのは、もう難しくない」

結果、一部エリアでのインサイドセールスは10人から1人の体制に移り、全体のチームへの展開の後は20人から2人になった。残ったメンバーはアウトバウンドへ再編成された。重要なのは、これが思いつきではないことだ。グロッサーは、リードから商談への転換率、商談化までに必要な顧客接触回数、転換までの時間といった KPI を前々からトラッキングしており、10人時の体制と同じ転換率を1人の体制でも維持できると確認したうえで人を動かしている。むしろ顧客対応が速くなった分、商談化までの接触回数は減った。

誤解しやすいので補っておく。 Vercel の CTO マルテ・ウブルは、 Business Insider の報道に対し「これは事実だが、我々は人員を削減していない。関連した職種を含めセールスチームはむしろ増えている」と明言している。起きているのは人件費の削減ではないということだ。

参考:

• Vercel trained an AI agent on its best salesperson. Then it cut the 10-person team down to 1. | Business Insider
• What world-class GTM looks like in 2026 | Jeanne DeWitt Grosser (Vercel, Stripe, Google)
• Malte Ubl （ Vercel CTO ）の LinkedIn 投稿

自動化する業務をどう見極めるのか？

前節の再編成は、いきなり AI を書き始めることから始まったわけではない。最初に手をつけるべきは退屈で認知負荷が低く反復のある業務であり、その見極めはトップセールスの観察から始まる。

トップセールスのシャドーイング

何を自動化するかは、本人の「言うこと」ではなく「やっていること」から探す。

ドリューは、コードを書く前にトップセールスに1週間張り付いた。どんなシグナルでリードに前のめりになるか、どんな条件で即座にジャッジするか、どう会社を調べ、返信のどこに反応が集まるか。これは、実際の行動に表れる癖を拾う作業だ。「 LinkedIn を見に行く」という当たり前の手順すら、シャドーして初めて分かった、とドリューは言う。

タイプ１とタイプ２

AI が最も得意とするのは、退屈で、認知負荷が低く、反復が多い作業だ。リードのクオリフィケーションは、その3条件をすべて満たす。

ドリューは、 GTM （マーケ、セールス、サクセスを通じて売上を作る仕組み全体）で作れる AI エージェントを2種類に分ける。

• タイプ１（効率化をする AI エージェント）: すでにやっている業務を、人が速くこなせるようにする。 Lead Agent はこれにあたる。
• タイプ２（やるべきだったのに、手が回っていなかったことをやる AI エージェント）: 「やるべきだったのに、手が回っていなかった」業務を新たに動かす。失注分析、反論の抽出とプロダクトへのフィードバック、チャーンした顧客への再アプローチなどだ。

ドリューの忘れがたい一言がこれだ。「 GTM で『〜すべき』という言葉を聞いたら、一段深く考えよ。そこがおそらく絶好のポイントだ」と。 Vercel の公式情報においても、データ入力、リサーチ、クオリフィケーション、トリアージといった「動的すぎて従来の自動化では向かないが、 AI なら確実に処理できる程度に予測可能」な業務が狙い目だとされている。グロッサーは、強いユースケースの条件を「再現可能で、決定的（同じインプットに対して同じアウトプットを返す）」と表現する。

同時並列でのテストで検証する

作ったエージェントは、いきなり本番で動かさず、過去データと並列運用で検証する。

ドリューはまず、使い捨ての UI を作り、過去3か月分のリードに対してプロンプトを何度も回した。 AI の判断が現場の判断と一致するまで、これを繰り返す（金融のバックテストと同じ発想で、 AI の世界では eval とも呼ばれる）。十分に手応えが出たら本番環境に入れるが、最初は何のアクションも取らずに動かす。本番のライブデータを浴びせながらダッシュボードでデータをモニタリングし、テストの結果が現実でも再現されるかを確かめる。実は、開発そのものより、この検証と社内合意に時間がかかる。

参考:

• Building Vercel's First GTM Agent | Drew Bredvick
• What we learned building agents at Vercel
• I Replaced 100 Sales Jobs Using This AI App | Human in the Loop

Vercel の AI SDR エージェントはどのように動くのか？

Vercel が開発した AI SDR エージェント、つまり、 Lead Agent は、お問い合わせフォームからメール送信までを3つのステップに分解して動く。全体像は次の図のとおりだ。

人がやっていた「調査し、判別し、メールを書き、送信する」作業が、「結果をレビューして送信ボタンを押す」だけに変わる。

1. フォーム送信を受け取り、 AI エージェントがリサーチ

フォーム送信をトリガーに、 AI エージェントが判断に必要なコンテキストを自律的にリサーチする。人が15〜20分かけていた調査が、このステップに集約される。

フォームから届いたリード情報（多くの場合はメールアドレスのみ入力されるケースが多い）を起点に、 AI エージェントがツールを自律的に使用しながらコンテキストを集める。 CRM やエンリッチメントサービス、 web 検索、ナレッジベースに対しての検索等を自律的に活用し、リードの氏名、所属、プロダクトの利用状況が分かるまでリサーチを続ける。

Vercel は、 Anthropic のマルチエージェント・リサーチ・システムから着想を得て、このリサーチエージェントを実装した。 AI が使うツールの例は次のとおりだ。

• web search: AI 向けの検索エンジン Exa, Tavily, Firecrawl 等で企業、人物の公開情報を調べる
• CRM search: Salesforce からアカウントの利用状況や過去の接点を引き出す
• tech stack analysis: 相手がどんな技術基盤を使っているかを把握する
• query knowledge: アカウント単位のナレッジベース（過去の通話、メール、 Slack のやり取り）を RAG で検索する
• etc...

目的は「まずリードの質を判別する前に、できるだけ多くのコンテキストを作ること」だ。このリサーチによる結果は、次のステップで AI がリードを分類するための材料になると同時に、後で人がその判断を検証するためのデータにもなる。

弊社では、 AI に渡すツールは web search と web fetch の2つだけだ。 CRM やナレッジベースはつないでいない。スタートアップでインバウンドの量も限られている現状では、公開情報だけで十分な情報が取れる。2026年時点のモデルと検索ツールの性能を前提にすれば、これだけでもリードの所属や会社の状況はかなりの精度で把握できる。

使うツールは企業によって変わる。 Vercel のように Salesforce に大量の接点データが蓄積されている組織なら、 CRM search やナレッジベースの RAG が効く。データ基盤が薄い段階なら、まず web search と fetch から始めてもよい。必要になったタイミングで足していけばいい。

また、渡すツールだけでなく、リサーチエージェントのプロンプトも重要だ。どのリソースから、何を調べたいのかをきちんとガイドラインとして書く必要がある。 Vercel の紹介はツールの列挙にとどまっているが、弊社では例えば次のようなプロンプトを使っている。

あなたは、与えられたリードの限られた情報から、できるだけ多くのリードに関する情報をリサーチして結果を整理して出力するリサーチエージェントです。

リサーチの結果は、そのリードに対してこちら側から送るメール文の下書きを生成するために活用されます。
そのため、そのリードに関する情報として重要なものは以下になります。

- 個人について
  - どの会社に所属しているか
  - どの職種として働いているか
  - 役職はあるか
  - どのような経歴、経験を持っているのか
  - LinkedIn, 会社のブログ、インタビュー記事、コミュニティでの活動などの公開情報等から調べられると良い
  - 情報がない場合は、素直に「わからない」と出力すること
- 所属している会社、あるいは部署について
  - 法人の名前、業態、業種、規模、従業員数、所在地
  - 法人の商品やサービス、ターゲット顧客について
  - 法人が今、目指していること、最近の活動等のインテントとなるシグナルについて
  - 情報がない場合は、素直に「わからない」と出力すること
  - 法人の公式サイト、PRTimes 等の公開情報から調べられると良い

使えるTools:
- fetchUrl: 指定された URL の内容を取得する
- search: 指定されたクエリで Web 検索を行う

Tool利用のガイドライン:
- search を利用するときは、日本語でクエリーをかけること。

// ...

後段のクオリフィケーションやメールの下書き生成で何が必要かを先に書いておくと、エージェントは関係のない情報を集めに行かなくなる。「わからない」と出力させるルールを入れておくのも、ハルシネーションを防ぐうえで効く。是非、参考にしてほしい。

2. クオリフィケーション

リサーチの結果をもとに、 LLM がリードを分類する。ここで商談化する対象かどうかを決める。

Lead Agent は、リードを、商談化に値するか、フォローアップが適切か、サポートに関するお問い合わせなのか、あるいはスパムなのか等に分類し、その判断理由も含めて生成する。スパムや営業対象外と判断されたリードは、ここで処理を止める。メールでフォローアップすべきと判定されたリードだけを次のステップに進ませる。

ここでドリューが強調するのが、プロンプトの設計だ。 LLM は放っておくと、担当者に喜んでもらうためにリードを過大評価しがちになる。「ドリューはリードが欲しいんだろうから、良いリードだと言ってあげよう」という具合にだ。 Vercel のような高ボリュームのインバウンドでは、プロンプトの大半を「これは悪いリードだ」と判断させるガイドラインにする必要がある、と彼は説いている。

ただ、実際に運用で使えるプロンプトは、もっと具体的である必要がある。分類ラベルの定義、自社の事業フェーズや受け入れ基準、出力形式まで明示しないと、モデルは一貫した判断をしにくい。弊社（ターニント AI ）では、自社サイトのお問い合わせフォームに届いたリードを同様のワークフローで処理しており、クオリフィケーションでは次のようなプロンプトを使っている。

役割:
あなたは、お問い合わせフォームから来たリード情報と、それに基づいてリサーチされた結果に基づいて、
このリードを QUALIFIED / FOLLOW_UP / SPAM / OTHER のいずれかに判別するのが仕事です。

判別の基準:
- QUALIFIED:
  - 商談化しそう、あるいは、こちら側がアプローチすべきと判断されるリード。
  - パートナーシップ、アライアンス、インタビュー、イベント等、コラボレーションの可能性がある場合も QUALIFIED と判別する。
- FOLLOW_UP:
  - 商談化しそうではないが、こちら側がアプローチすべきと判断されるリード
  - 温度感が低い、情報が少ない、が、将来的に両者にとってプラスになる可能性がある場合は、FOLLOW_UP と判別する。
- SPAM:
  - フォーム営業等はスパムと判別する。
- OTHER:
  - 上記のいずれにも当てはまらない場合は OTHER と判別する。

我々について:
- ターニントAIは Agentic AI SDR Platform を提供しているスタートアップである。
- プロダクト以外にも受託・AI顧問等のサービスも提供している。

// ...

弊社の場合、こうした判別のガイドラインを明確に書くことが肝になる。シードフェーズのスタートアップではインバウンドを広く受け入れたいので、フォーム営業の自動化によるお問い合わせだけを SPAM として弾き、それ以外は QUALIFIED か FOLLOW_UP に振り分ける設計にしている。 Vercel のように「悪いリードを見つける」プロンプトにするのではなく、自社のフェーズに合わせて、何を弾き、何を通すかを決める必要がある。

判別だけのタスクに見えても、モデルの賢さは効いてくる。フロンティアに近いモデル以上であれば十分だ。賢いモデルを使えば、例外的なケースをプロンプトで補う手間が減り、チューニングコストは下がる。同じガイドラインでも、判断の質はモデルによって変わる。出力はカテゴリと理由のみの少ないトークン消費に収まるので、コスト面の負担もそこまで大きくない。

このステップは、運用しながら継続的に調整が必要な箇所でもある。実際に弾かれたリードや通り抜けたリードを見返し、ガイドラインやカテゴリ定義を直していく。一度書いて終わりではない。

3. メールの下書き生成とフィードバックループ

質が良いと判断されたリードに対して、 LLM がパーソナライズした初回メール文の下書きを作り、 Slack で担当者の承認を待つ。人がやるのは出来上がった下書きの確認して、ボタンを押すかフィードバックをするかだけだ。

AI によるリサーチの結果、判断理由、メールの下書きが同時に Slack に通知される。担当者は、0から調べ直すのではなく、内容を見て判断することができる。

Slack 上では、担当者が AI が生成したメールの下書きをポチポチしてどうするかを決める。

• 承認: 「承認して送る」を押すと、その内容でメールが送られる
• フィードバック: 生成された内容に対してフィードバックを送り、 LLM が下書きを書き直す。納得いくまでこのループを回せば良い。
• 拒否: 対応を見送り、フローは終了する

弊社でも同じ構成だ。たとえば、お問い合わせフォームに「デモを試してみたいです。」というメッセージが届くと、 Slack に Turnint AI Bot から通知が飛ぶ。親メッセージには、お問い合わせ内容、判別結果（ QUALIFIED とその理由）、メールの下書き、承認ボタンが載る。リサーチ結果は長くなりがちなので、弊社ではスレッド内のメッセージに追記する形にしている。必要なときだけスレッドを開いて確認すればよい。

担当者は、判断理由と下書きの件名・本文を確認し、詳しく見たければスレッドのリサーチ結果を読んだうえで、「承認して送信」「作り直す」「送らない」のいずれかを選ぶだけだ。0 から調べ直したり、メールを一から書いたりする必要はない。

もちろん、生成されたメールの下書きがそのまま送れるほど完璧というわけではない。リサーチやクオリフィケーションと同様、プロンプトのチューニングが必要なステップでもある。それでも、白紙の状態から調べて文面を組み立てるより、下書きを手直しするほうが圧倒的に速い。承認ボタンを押して終わることもあれば、「作り直す」で数回フィードバックを回すこともある。いずれにせよ、1件あたりの対応にかかる労力は低くなっている。ある程度の規模の組織でこれが回り始めれば、記事冒頭で触れた Vercel の ROI の高さも、数字以上に納得できるだろう。

参考:

• Lead Agent Repository
• How we built our multi-agent research system

なぜ HITL （ヒューマンインザループ） を Slack 中心に設計するのか？

理由はシンプル。人によるフィードバックループを、チームが普段利用している場所に差し込むのが、 Vercel にとっては Slack が現実的だったからだ。もちろん、これは会社による。 Teams でも Chatwork でもメールでも、独自の社内ツールでも何でもよい。注意したいのは、 Slack はあくまでチームにとって最も摩擦が少ないインターフェースとして Vercel にとって最適だっただけにすぎない。

そしてもう一つ、 HITL は品質担保だけの仕組み以上の理由がある。担当者が下書きを承認、却下、フィードバックした記録自体は、そのまま AI エージェントを改善していくためのトレーニングデータになるということだ。 Vercel のマルテ・ウブルとエリック・ドッズによる解説でも、成功している事例にはすべて HITL が組み込まれ、誤りの検出と推奨内容の検証に使われている。複雑なケースは人間のレビューを残す、という線引きも共通している。

参考:

• Lead Agent （リード処理エージェント テンプレート） | Vercel
• What we learned building agents at Vercel

SDR の役割はどう変わるのか？

AI が退屈な部分を引き取ることで、人は顧客と向き合う時間に集中できるようになる。労働時間は変わらず、中身が入れ替わる。

ドリューの試算では、1リードあたりに必要な手作業は8回から4回へ半減した。別の言い方をすれば、「4時間の退屈な準備 + 2時間の価値ある仕事 ＝ 1日1件の成約」だったのが、退屈な部分を AI エージェントが担うことで「6時間全てを価値ある仕事に使えて、1日3件の成約」へと変わりうる。同じ時間で、中身が変わる。

これは業界全体の長年の課題解決に直結する。グロッサーによれば、セールスが実際に顧客と向き合う時間は、過去20年ずっと全体の時間の3〜4割に留まってきた。残りの時間はリサーチやフォローアップといった作業だ。その業務を AI が引き取れば、顧客と向き合う時間を7割まで引き上げられる、とグロッサーは見る。

ただし、 AI に任せる範囲には注意が要る。 Vercel の SVP Sales トマー・チャーニアは、自動化すべきは「ただ時間を吸い取るだけの作業」、例えば、マニュアルでのデータ入力や、会社の情報を Google で検索する作業、であって、「相手に響くメッセージを作る」部分は人がやるべきだと言う。メッセージの冒頭で「経歴に触れただけ」のような薄いパーソナライズは効かない。

そしてもう一つ、見落とされがちな限界がある。グロッサーは、 Lead Agent が「経験2年のトップセールス」を手本に作られているため、20年の経験を持つ自分なら送らないメールも出てくることがある、と率直に語る。 AI エージェントの質は、手本にした人間の質に縛られる。だからこそ、これを設計する GTM エンジニアにはセールスの素養が要る、という話につながる。

参考:

• Building Vercel's First GTM Agent | Drew Bredvick
• What world-class GTM looks like in 2026 | Jeanne DeWitt Grosser (Vercel, Stripe, Google)
• Using psychology to scale GTM to $100M with Tomer Chernia, SVP Sales at Vercel

自前で作るか、 SaaS を契約するか、導入インパクトの目安は？

コストが同等なら、 Vercel は自社で作るほうを選ぶ。理由は、自前で作ったほうが自社の状況に合わせてカスタマイズが効くからだ。

ドリューは「特にコストが同じなら、オーダーメイドのほうが常に優れている」と言い切る。提供されている AI エージェントのサービスも、結局は同じ LLM モデルを内部で使っていることが多く、しかも自社データとのインテグレーションは結局こちら側でやる必要がある。グロッサーも、 AI エージェントの能力をより引き出すのは「自社固有のコンテキスト、コンテンツ、ワークフロー」であり、 SaaS を契約することも良いとする一方で、自前で試す価値があると述べている。

組織全体の ROI （約32倍）は前半の試算で触れた。 Vercel 固有の内訳だけ補足すると、エージェントの実行コスト自体は年1,000ドル程度で、10人いた SDR の人件費（100万ドル超）に対して90%以上の削減になったという。開発に要したのは実質1週間ほどだが、本番投入までにさらに5週間の社内合意形成が必要だった。

ただし、この数字はあくまで該当事例の範囲であって、全社の ROI とは分けて読む必要がある。そして Vercel 自身が最も強く言っているのは、次のことだ。

「 Lead Agent をそのままコピーしないこと。自社にとって最もレバレッジの効く箇所に AI を当てること。」

10倍のリターンが見込めるレバレッジに集中する。10〜20%の小さな改善に気を取られないこと。というのがドリューの主張だ。 Lead Agent はあくまで一例であって、テンプレートを入れて放置すれば成果が出る、という話ではない。

ここであわせて押さえておきたいのは、これが Vercel という1社の事例にすぎないことだ。 Vercel は開発者向け SaaS を提供する企業で、組織全体がかなりテクニカルな人材に偏っている。 GTM エンジニアが自社でコードを書けるのはもちろん、 Next.js 、 AI SDK 、 Workflow SDK といった自社プラットフォームの上で AI エージェントを低コストで組める立場にもある。開発が1週間で済んだという数字も、そうした環境があるからこそ、と読む必要がある。だから、この記事で触れた「自前で作る」という選択が、他社でも現実的に検討できるかどうかは、別の議論になる。

参考:

• GTM Engineering — Why now? | Drew Bredvick
• What world-class GTM looks like in 2026 | Jeanne DeWitt Grosser (Vercel, Stripe, Google)
• Building Vercel's First GTM Agent | Drew Bredvick

社内で AI を業務フローに組み込むには？

Lead Agent のように見える成功例の裏側で効いているのは、個別のフレームワークや SaaS ではなく、既存の業務フローに AI を組み込むための社内の進め方だ。

GTM エンジニアリングの責任者であるドリューは、コードを書く前にトップセールスに1週間張り付いた。エージェントの質は手本にした人間の質に縛られる。 Lead Agent を設計できるのは、 CRM と LLM だけではなく、営業の判断基準を言語化できる人がいるからだ。

ドリューが繰り返す "crap in, crap out"。つまり、インプットが雑ならアウトプットも雑になる。ナレッジベースや CRM 連携は一度作って終わりではなく、通話、メール、 Slack の蓄積と更新を続けないと検索の品質は担保できない。 Vercel はプロンプトもソースコードと同様にバージョン管理し、どのバージョンによってどのようなアウトプットが出たかを記録している。

HITL は Slack のような人が日常的に仕事で利用しているインターフェースに組み込むことで、導入の摩擦、運用の摩擦を減らしている。

AI エージェントはいきなり本番では動かさない。 Vercel では開発が約1週間でも、本番投入の合意にさらに5週間かかった。KPI を維持できると現場が納得するまでの検証と合意に時間をかけること。小さく初めていき、チームの懸念を一つずつ潰していく作業が大事だ。

AI エージェントは「モデル + プロンプト + ツール + ワークフロー」によって構成される。技術的にはシンプルな組み合わせだが、 CRM 連携やツール呼び出しの調整など、自社データに合わせ込む作業、プロンプトの調整、メンテナンス、堅牢なワークフロー等、考慮することは多い。 Vercel の GTM エンジニアの求人の要件に 4年以上のフルスタック開発経験を求めているのも、そういう理由からだ。「1週間で作れた」というナラティブに惑わされてはいけない。

さらに、日本国内においては、 HubSpot ないしは Salesforce 等のフォームをお問い合わせフォームとして活用しているところが一般的で、既に職種を跨いだ社内のワークフローが出来上がっている。既にできあがったワークフローを変えることのハードルは、 AI エージェントの実装より遥かに高く付く。マーケ、セールスがそれぞれ CRM 上の役割分担とマニュアルを持っており、それぞれが別の目的で動いている。 AI を「新しいツール」として足すのではなく、そこに差し込む前提でまずは考える。「 AI で効率化しよう」と言って簡単に進められる類の話ではない。

ハードルは高い。だが、ゼロから Vercel を再現する必要はない。自社の CRM やフォーム、マーケとセールスの役割分担のなかで、それぞれにとって最適なやり方を探せばよい。世の中にまだ事例も少なく、正解の型はこれからできていく段階だ。だからこそ、小さく試して、現場で使える成果を一つずつ作っていく。Vercel の AI ネイティブ GTM 戦略 でも触れたように、社内調整にも時間をかけながら、中長期的に進めていくのが現実的だ。

参考:

• I Replaced 100 Sales Jobs Using This AI App | Human in the Loop
• What we learned building agents at Vercel

まとめ

AI SDR エージェントの本質は、人を置き換えることではなく、業務を設計し直すことにある。 Vercel はインバウンド対応を「リサーチ → クオリフィケーション → メール文の下書きと人によるフィードバックループ」の3ステップに分解し、退屈で反復的な部分を AI に、判断と顧客対応に人に振り分けた。10人を1人に再編成しても商談化率は落ちず、人はより価値の高い仕事に移った。

AI エージェントは「モデル + プロンプト + ツール + ワークフロー」と、構造としてはシンプルだ。だが、それを過小評価しないこと。 Vercel では開発が1週間で済んだと言われるが、 CRM 連携、プロンプトの調整、堅牢なワークフローの設計など、技術的な手間は軽くない。難しいのは技術だけでも、組織だけでもない。どの業務を選ぶか、どこに HITL を差し込むか、既存フローにどう組み込み、社内合意をどう取るかの両方にある。 ROI の32倍や「1週間で作れた」という話が、全体の難しさを見えにくくしている。 Vercel 自身が「 Lead Agent をコピーするな」と言い続けるのも、このためだ。

国内企業にとっても、ゼロから Vercel を再現する必要はない。ハードルは高いが、正解の型はこれからできていく。小さく試して現場の成果を積み上げ、マーケとセールスを巻き込みながら中長期で進める。それが現実的な道だ。

どの業務から始めるか。誰が担うか。どの KPI で測るか。 まずはこの3つを、検証可能な形で決めることから始めたい。

よくある質問

AI SDR エージェントとは何か？

AI SDR エージェントは、 SDR が担う業務を支援・代行する AI エージェントのこと。業界に単一の定義はない。

本記事で扱う Vercel における AI SDR エージェント（ Lead Agent ）は、インバウンドのリード対応に限定し、リサーチ → クオリフィケーション → 初回メールの下書きを AI が担い、人が Slack でレビューして承認する3ステップに分解した設計だ。この設計によりインバウンド担当を10人から1人に再編成しても商談化率は維持された。

SDR と AE は何が違うか？

SDR（ Sales Development Representative 、インサイドセールスとも言う）は、リードに最初に対応し、商談に進める価値があるかを見極めてパイプラインを作る役割。AE（ Account Executive 、アカウントエグゼクティブ）は、その先で商談をクロージングまで持っていく役割を指す。本記事の AI SDR エージェントは、主に SDR が担っていたインバウンド対応の前段を自動化するものだ。

HITL （ human-in-the-loop ）とは？

HITL（ Human In The Loop 、人間参加型。 human-in-the-loop とも表記）とは、 AI や自動化のフローのなかに、人の判断・確認・修正を組み込む設計のこと。 Lead Agent では、 AI が作った下書きメールを Slack で人がレビューして送信する。人の承認・却下・編集は、品質担保であると同時に、 AI エージェントを改善するトレーニングデータにもなる。

データエンリッチメントとは？

データエンリッチメント（ enrichment ）とは、限られたリード情報に、外部・社内のデータを突き合わせて文脈を補うこと。 Lead Agent では、フォームから届いたメールアドレスしか分からないリードに、 Clearbit や ZoomInfo 、 CRM の情報を足して、氏名・所属・利用状況などを補っている。

クオリフィケーションとは？

クオリフィケーション（ qualification ）とは、リードが商談に値するかを見極め、分類すること。

RAG とは？

RAG（ Retrieval-Augmented Generation 、検索拡張生成）とは、 AI が回答を作る前に、関連するドキュメントなどを検索して取り込み、その情報をもとに出力させる仕組み。 Lead Agent では、アカウント単位のナレッジベースを検索し、判断の文脈に使っている。

Lead Agent をそのまま導入すれば成果が出るか？

Vercel 自身が「 Lead Agent をそのままコピーするな」と述べている。テンプレートはオープンソースで公開されているが、成果を生むのは自社のデータ・知識ベースの質と、自社で最も大きい成長課題に AI を当てる選択だ。まずはどの業務から・誰が・どの KPI でを決め、社内でどう組み込むかを小さく検証することから始めるのが現実的だ。

どこから自動化を始めるべきか？

効果測定がしやすい業務から始めるのがよい。インバウンドのリード対応はその典型だ。進め方としては、トップセールスのやり方を観察して言語化し、過去のデータで検証してから、本番で並走させて確かめる流れが手堅い。