Jason LemkinとAmeliaが語るAI SDR導入: SaaStrセッションから残る実装原則

“

この記事は SaaStr AI London 2025 の session video と、SaaStr の公開記事 10 Things to Know Before You Deploy Your First AI SDR: The Very Latest with SaaStr’s Jason and Amelia をもとに、時点依存の強い数値を抑えて再構成しています。

SaaStr の AI SDR セッションは、派手な成果数字だけを追うと読み違えやすい題材です。ロンドンのセッションでは、複数 agent の運用、数万件規模の outbound、イベント売上への寄与など印象的な実例が語られました。一方、後続の SaaStr 記事では vendor 構成や運用量、daily rotation の話がさらに更新されています。

そこで本記事は、その時点の SaaStr の数字 を一般化するのではなく、今も比較的再利用しやすい AI SDR の実装原則だけを interview recap として残します。

この記事でわかること

1. SaaStr の話をどう読むべきか: KPI 自慢ではなく deployment recap として読む視点
2. 導入前に必要な準備: human playbook、segment、context、handoff 条件
3. 運用体制の作り方: zero-headcount 幻想を捨てる考え方
4. multimodal 展開の順番: text を先に安定させ、voice / video は後段に置く理由
5. 自社導入に持ち帰れること: 日本の SaaS チームでも試しやすい小さな rollout 手順

3行でわかる要点

1. SaaStr の durable な学びは数値より運用原則: human playbook が先、agent は後
2. AI SDR は放置できない: segment 更新、context 補充、出力 review を毎日回す必要がある
3. text から始める方が安全: voice / video avatar は魅力があっても guardrail と運用負荷が重い

基本情報

---

1. まず整理したいこと: これは「最新の正解」ではなく SaaStr の運用スナップショット

このテーマでいちばん危ないのは、SaaStr が公開した数字や vendor lineup をそのまま自社の正解として持ち帰ることです。後続の SaaStr 記事では、4 つの vendor を daily rotation で使っている話、1 つの website で大きな inbound volume を処理している話、100 近い segment を回している話などが出てきます。

ここから言えるのは、運用量も vendor 構成もかなり動く ということです。したがって、今残りやすい論点は「返信率が何%だったか」よりも、次のような運用原則です。

この読み替えをしておくと、記事の寿命がかなり伸びます。

---

2. 原則1: human playbook が動いてから agent を載せる

SaaStr が一貫して強調しているのは、AI SDR を「営業の代わり」ではなく「すでに勝っている motion の複製装置」として使う という考え方です。

つまり、先に必要なのは次の 4 点です。

1. 誰に送ると反応が返るのか
2. どの件名や文面が実際に変換しているのか
3. 何回の follow-up が妥当か
4. 返答後に人間へ handoff する条件は何か

この下地がないまま agent に新しい copy を発明させようとすると、SaaStr の文脈でも失敗パターンになりやすいと整理されています。follow-up article でも、founder-led sales や人間 SDR の勝ち筋を先に把握してから agent に渡す順番が繰り返し説明されています。

持ち帰りやすい学び

• AI SDR の最初の役目は 新規 GTM 戦略の発見 ではなく 既存の勝ち筋の再現 と考える
• founder-led sales や人間 SDR の成果が薄い段階では、先に message-market fit を詰める
• AI SDR を cold test の近道 として扱わない

---

3. 原則2: 1つの campaign brain で全部を処理しようとしない

SaaStr の後続記事で特に強く出てくるのが、segment を容赦なく切る という話です。inbound をひとまとめに「web 流入」と扱うのではなく、新規訪問者、広告経由、元顧客、既存顧客、pricing 再訪問者のように context を分けて扱う必要があるとされています。

この考え方は、どの vendor を選ぶかより重要です。

なぜ segment が効くのか

AI SDR は「大量送信すること」自体には向いていても、誰に何を言うべきかの前提 が雑だと一気に精度が落ちます。SaaStr の話を保守的に読むなら、勝ち筋は agent の賢さではなく次の組み合わせにあります。

• segment 定義
• その segment 専用の context
• すでに効いている copy
• 毎日の見直し

最低限そろえたい context

ここを詰めずに「1 つの campaign に lead を足し続ける」運用をすると、AI SDR の印象はすぐ悪くなります。

---

4. 原則3: AI SDR は zero-headcount ではない

元記事で stale になりやすかったのは、「2人の人間が必須」「この肩書きの人が必要」といった断定でした。一次情報を保守的に読むと、ここで持ち帰るべき論点はもっと単純です。

AI SDR には継続運用の owner が要る ということです。

SaaStr の後続記事では、少なくとも 1 人、理想的には 2 人で deployment を見た方がよいと整理されています。理由は明快で、segment の補充、context の更新、出力 review を止めると agent がすぐ idle になるからです。

運用で外せない 3 つ

1. 最初の 30 日は output をかなり細かく読む
2. daily で context と segment を更新する
3. 属人化を避けるために backup owner を持つ

「設定したら回る」は誤解

SaaStr の公開記事では、導入初期に古い event date、古い pricing、表記ゆれのような credibility issue を出力 review で拾っていたと説明されています。これは freshness remediation の観点でも重要です。agent は古い公開情報や雑な internal doc をそのまま増幅します。

つまり、AI SDR の本質は automation というより 運用ソフトウェア化された営業活動 です。

---

5. 原則4: ramp time と deliverability を見込んで text から始める

元記事では「すぐに実装すべき」「まだ手動でやっているなら遅い」といった言い切りが多く、ここが stale risk になっていました。一次情報ベースで残る学びは、むしろ逆です。

何も instant ではない ということです。

SaaStr の後続記事では、dedicated email address や IP warming、CRM 連携、copy 調整、segment 準備まで含めると、導入には最低でも一定の ramp time が必要だとされています。具体的な日数は vendor と deliverability 状況で動くので、ここでは固定値より順序を重視した方が安全です。

推奨される順番

1. text outbound / text chat を安定させる
2. review loop と handoff 条件を固める
3. 必要なら voice を試す
4. brand risk と guardrail を管理できるなら video avatar を追加する

なぜ text 先行がよいのか

SaaStr の follow-up article では、multimodal agent を持っていても大半は text interaction だと説明されています。割合自体は今後変わり得ますが、順序の学びは durable です。voice / video は魅力的でも、off-topic 質問、persona 依存、brand risk が増えます。text で quality bar を超えてから広げる方が失敗しにくいです。

---

6. 原則5: person-dependent deployment は運用と権利の両面で考える

SaaStr は Amelia AI や Jason AI のように、特定人物の話し方や likeness に寄せた agent を運用しています。この構成は trust を作りやすい半面、再利用時には 2 つの論点を分けて考える必要があります。

1. 運用リスク

• その人物しか agent の中身を理解していない
• 退職、異動、役割変更で maintenance が止まる
• 一人の営業メンバーに knowledge が閉じる

2. ブランドと権利のリスク

• どこまで実名・顔・声を使うのか
• 社外向け表現として何を約束してよいか
• employment agreement や社内ポリシー上の扱いをどうするか

法的整理は国や契約で変わるため、本記事では一般論として断定しません。ただし、実在の人に似せた AI は普通の chat bot より review 範囲が広い とは言えます。

---

7. 原則6: data fundamentals が弱いと AI SDR は古い情報を増幅する

SaaStr の follow-up article では、agent が大量の context を前提に動いていること、そしてその context を継続的に更新していることが繰り返し説明されています。

ここで持ち帰るべき論点は、件数そのものより knowledge refresh loop を持てるか です。

点検したい項目

inbound / outbound の見方

SaaStr は inbound agent に一定の traffic volume が要ると示唆していますが、これは universal rule ではありません。保守的には次のように読むのが安全です。

• 十分な web traffic があるなら inbound agent を試しやすい
• traffic が小さいなら outbound や既存顧客対応から始める方が現実的
• 人間がまったく返していない inbound があるなら、低 traffic でも agent の価値が出ることはある

重要なのは、volume の閾値を暗記することではなく、自社の response gap を特定することです。

---

8. 日本の SaaS チームで試すなら、まずはこの 5 ステップ

SaaStr と同じ規模や vendor 構成を前提にする必要はありません。再利用しやすい rollout は、もっと小さく始められます。

1. 1つの motion だけ選ぶ
   例: 休眠 lead 掘り起こし、イベント follow-up、資料請求後の一次返信

2. 勝っている copy を固定する
   新規 message 生成より、既存の成約パターンを整備する

3. owner と backup owner を決める
   RevOps、growth、sales ops、marketing ops のいずれでもよいが、運用責任は明確にする

4. 2週間ぶんの review plan を作る
   毎日どの output を読むか、何を修正したら prompt / context に戻すかを決める

5. text で quality bar を超えてから surface を増やす
   voice / video は後段でよい

この順番なら、派手な demo に引っ張られずに済みます。

---

よくある質問（FAQ）

Q1. AI SDR を導入するなら、最初から複数 vendor を比較すべきですか？

必須ではありません。SaaStr 自身は複数 vendor を使っていますが、後続記事では大半の会社は 1 vendor、必要でも inbound / outbound の 2 系統程度で十分と整理しています。最初は比較の幅より、使う motion の定義を優先した方が成果につながりやすいです。

Q2. AI SDR は新しい営業 copy を勝手に見つけてくれますか？

そこを主目的にすると失敗しやすいです。SaaStr の一次情報では、すでに人間が成果を出している copy と cadence を agent に移植する考え方が中心でした。新規実験は人間が先、増幅は agent が後の順が安全です。

Q3. 社内に「GTM エンジニア」と呼べる人がいなくても始められますか？

肩書きそのものは必須ではありません。ただし、CRM、segment、prompt / context、handoff ルールをまたいで動ける owner は必要です。marketing ops、sales ops、RevOps のいずれかが継続運用を持てるかが重要です。

Q4. voice / video avatar は最初から入れるべきですか？

基本的には後回しでよいです。SaaStr の公開記事でも text の比重は大きく、voice / video はより多くの guardrail が必要だと整理されています。まず text で response quality と escalation quality を安定させる方が安全です。

Q5. 成功指標は返信率だけ見れば十分ですか？

十分ではありません。少なくとも次を分けて見た方がよいです。

• segment ごとの返信率
• human handoff 後の転換率
• response latency
• context の更新頻度
• lead list の補充速度

返信率だけだと、quality の悪い meeting や誤案内を見逃します。

---

まとめ: SaaStr の話は「派手な数字」より operating system に価値がある

SaaStr の AI SDR 運用で本当に持ち帰る価値があるのは、20 以上の agent を回していること自体ではありません。再利用しやすいのは次の 5 点です。

1. human playbook が先
2. segment と context を細かく作る
3. owner を置き、daily で review する
4. text を先に安定させる
5. person-dependent deployment を属人化させない

AI SDR は「放置で売上が出る魔法」ではなく、既存の営業運用を software-like に再設計する作業 に近いです。この見方で読むと、SaaStr のセッションは今でも十分参考になります。

---

関連記事

参考リソース

• SaaStr AI London 2025 - How We Deploy 20+ AI Agents
• 10 Things to Know Before You Deploy Your First AI SDR: The Very Latest with SaaStr’s Jason and Amelia
• SaaStr AI

本記事はネクサフローのAI研究シリーズの一部です。