最近話したあるfounderは、2つ目の製品を立ち上げようとしています。買い手も競合も新しく、ICPも、本業が何年も売り込んできたものとは異なります。そのためのgo-to-marketチームは2人です。account executiveが1人と、go-to-market engineerが1人。SDRもfield marketingもなく、ブースに立つ人もいません。そして最初にテーブルに上がった問いは「どうやってpipelineを作るか」ではなく、「そもそもSDRは必要なのか、それとも単にAI agentをこれに向ければいいのか」でした。正しい直感が、間違った最初の問いにくっついています。
この問いは今年、もっともな理由で至るところにあります。cadenceベースのsales developmentの経済性がひっくり返りました。SaaStrは今や大半のSDRは2026年以降AI SDRになると論じており、最もよく引用される版は、Jason Lemkinがおよそ10人のsalesチームを20のAI agentに置き換え、それをほぼ1人で管理している、というものです。founderとしてこれを見れば、誘惑は明白です。SDRの採用をまるごと飛ばし、代わりにagentを買う。
しかしSaaStr自身の助言には、見出しより重要な一文があります。AI SDRは、彼らが言うには、すでに機能するmotionのforce multiplierであって、機能しないものを直す手段ではない、と。この一つの区別こそ、新製品の立ち上げにおける問題のすべてであり、「AI SDR対human SDR」が出発点として間違っている理由です。
outbound engineと言うとき、私は4つのものを指していて、そのいずれも人ではありません。1つ目は、この製品の本物のICPに基づくターゲットリストで、それを作った会社から受け継いだものではありません。2つ目は、今まさに連絡する理由です。trigger event、導入済みの技術、採用のパターンなど、タイミングを正当化する何かです。3つ目は、返信する価値のあるsequenceとofferで、前提にするのではなく書いてテストしたものです。4つ目は、その下のデータ基盤です。CRMオブジェクトモデル、enrichment、routing、reportingで、最初の送信からmotionを測定可能にします。
それがengineです。SDRは、人であれAIであれ、それを回す労働力です。労働力はengineではありません。そしてここがfounderが飛ばす部分です。engineがなければ、労働力を自動化しても何も自動化されません。仮説を送る、より速い方法を買っただけです。
AI SDRは本当にforce multiplierです。outboundがすでに人で機能しているなら、agentはそれをより安く、より速く、より一貫させ、導入の論拠は強い。問題は「すでに」という語です。機能するmotionとは、定義されたリストが、本物のsignalに合わせて、テスト済みのsequenceを通り、返信を生みmeetingを取る、というものです。それが存在するなら、増幅は賢い選択です。
製品が先月立ち上がったばかりで、誰一人sequenceを1本も回していないなら、増幅すべきmotionはありません。増幅装置をゼロに向けているのです。agentは、誰も検証していないICPの上に作られ、誰も守っていないリストに対して、誰もテストしていないofferを載せた1,000通のメールを律儀に送り、しかも誤りを見えにくくする規模でそれを行います。「新製品にAI SDRを買うべきか」の正直な版は「いいえ。増幅すべき対象をまだ持っていないからです」です。
もう半分はgo-to-market engineerであり、私はこの役割を正当に扱いたい。実在し、有用だからです。現代のoutbound engineのexecution層は、今や本当にengineeringです。Clay、enrichment waterfall、Apollo、Claudeでスクリプト可能なツール群、stack全体。誰かがそれを作って回さなければなりません。それがGTM engineerであり、1人は欲しいところです。
私がしないのは、その人をengineを設計する人と取り違えることです。GTM engineerを名乗る多くのオペレーターはClay認定で、いくつかsequenceを作ってきたが、本物のsales cycleの中に座ったことはありません。それはexecutionのスキルであって、strategyのスキルではありません。ICP、signal、offerを決める人は、dealの勝ち負けを見てきた必要があります。engineはそれらの判断の良し悪しを超えないからです。作ることと設計することの区別であり、lean teamは両方を必要とします。たとえそれが4つの帽子をかぶった2人であっても。
最近まさにこれを、本業と並行して2つ目の製品ラインを立ち上げているデータインフラ企業と一緒に整理しました。そのfounderは、自社の採用sourcing機能をすでに自動化し、給与台帳にsourcerは1人も残っておらず、ではなぜsales developmentは違うのかと、もっともな問いを投げました。正当な問いで、答えは示唆に富みます。
sourcingが自動化できたのは、先に機能するmotionがあったからです。定義された候補者プロフィール、返信を生むチャネル、callを取るsequence。彼らはすでに機能していたものを自動化しました。新製品にはそのどれもありませんでした。書かれたICPもなく、ターゲットリストもなく、outreachのタイミングを合わせるsignalもなく、誰かがテストしたsequenceもありません。そこでSDR機能を自動化しても、motionを自動化したことにはなりません。それが本当かどうかを誰かが確かめる前に、仮説を、量で、自動化することになります。
- 新製品のICPとbuying personaを書く。新しい製品、新しい買い手。deckに同じロゴが載っているからといって、親会社のプロフィールを受け継いではいけません。
- 守れるターゲットリストを1つ作る。本物のsignalに基づくこと。trigger event、導入済みの技術、fundingや採用のパターン。今まさに連絡する理由のないリストは、ただのデータベースです。
- sequenceとofferを手で書いてテストする。1件でも自動送信する前に、本物の返信を10件得てください。安く、反証可能で、engineに少しでも推進力があるかを教えてくれます。
- データ基盤を立てる。CRMオブジェクトモデル、enrichment、routing、reporting。motionを後から再構築するのではなく、初日から計測できるようにします。
- そのときにはじめて労働力を決める。engineを作り小さな規模で証明できれば、1人のオペレーターと自動化がかつてチームを要した仕事を回し、AI SDRはようやく、仮説を拡大する高価な手段ではなく、売り文句どおりのforce multiplierになります。
おそらく2年前に採用していたよりも少ないSDRに落ち着くでしょう。その予測の部分は正しく、私もそれに反対はしません。ただしそこに至るのは、まずengineを作り、すでに機能するmotionを自動化することによってであって、agentを買い、その後ろにmotionが現れるのを願うことによってではありません。新製品のoutboundを立ち上げ、労働力を決める前にengineにもう一組の手が欲しいなら、それはまさに私たちがprogrammatic outboundとGTM戦略で行う仕事です。何を立ち上げようとしているか、お聞かせください。
- SaaStr.「Dear SaaStr: Should I Use an AI SDR Before I Have a Working Human SDR Motion?」2026年. saastr.com
- SaaStr.「Why Most SDRs Will Be AI SDRs In 2026+.」2026年. saastr.com
- Lenny’s Newsletter.「We Replaced Our Sales Team With 20 AI Agents, Here’s What Happened Next.」2026年1月. lennysnewsletter.com