対談・インタビュー
AI SDRの数字は古びても、順番は残る。SaaStrの実装原則を読み解く
AI SDRの返信率や売上寄与の数字は、次にSaaStrが記事を出す頃にはもう更新されている。それなのに、なぜ「人間の勝ち筋を先に固め、対象を細かく区切り、毎日直す」という運用の順番だけは古びずに残るのか。これが本記事の駆動的な問いである。
私はAI SDRを、営業という仕事の代替ではなく、すでに人間が勝っている手順を複製する装置として読むべきだと考えている。誰に、何を、何回送り、どの条件で人へ返すか。この4点を文章にできない段階の会社は、日本でも導入を見送った方がよい。ただし、この判断はSaaStrの公開セッションと記事の読解、そして当ブログでGTMの型の移植可能性を扱ってきた立場から来るものであり、AI SDRを自社で大規模に運用した一次経験に基づくものではない。
私がこのセッションを読み込んだ動機も、同じところにある。以前別の記事では、OpenAIのMaggie Hottが語った採用・報酬設計・パイロット運用の型を、「需要が供給を上回る局面でしか成立しない型か」という軸で切り分けた。強い主張ほど、それが局面に依存せず再現できる設計なのか、単に有利な局面の産物なのかを分けて読む必要があると考えたからだ。同じ問いは、AI SDRの一次情報にもそのまま当てはまると私は見ている。20以上のエージェントを日次でローテーションする運用密度や、複数ベンダーを併走させる規模感は、SaaStrという媒体の規模だからこそ成立している局面依存の部分かもしれない。だからこそ本記事では、その規模や密度そのものではなく、規模に依存せず日本のB2Bへ移植できそうな運用の順番だけを取り出して読みたいと考えている。
本記事の前提
本文中の返信率、開封率、ベンダー数、運用量、流入量は、SaaStrの運用スナップショットであり、一般的なベンチマークではない。AI SDRの成果はメールの到達率、CRMの整備、セグメントの質、レビュー体制に強く依存するため、導入前には各ベンダーの最新のドキュメントと商用条件を必ず確認してほしい。
前提: 2つの言葉を先に固定する
議論を進める前に、2つの言葉を自分の定義で固定する。
運用スナップショットとは、特定の時点における一社の運用の記録を指す。返信率、開封率、稼働させているエージェントの数、ベンダーの組み合わせのような数字はこれに当たる。固定的なベンチマークではなく、次にSaaStrが記事を出せば書き換わる一時点の観測だと考えた方が安全である。実際、セッション動画では複数エージェントの並行運用と大量のアウトバウンドが語られ、後続の公開記事ではベンダー構成やセグメント数がさらに更新されている。
人間プレイブックとは、誰に送ると反応が返るのか、どの文面が実際に転換しているのか、何回のフォローアップが妥当か、返答後にどの条件で人間へ引き継ぐか、という4点が文章になった営業手順を指す。この4点を文章にできているかどうかは、外から見ても判定できる。反証可能な定義にしてあるのは、以降の主張を「言われてみればそう」で終わらせないためである。
SaaStrというメディア自体の読み方や、AIを制作・配信のワークフローへ組み込む一般的な見方は、以前別の記事で整理した。本記事はその各論として、AI SDR導入の順番だけを掘り下げる。
全体像: 何が古びて、何が残るか
後続のSaaStr記事では、4つのベンダーをローテーションで使っている話、100近いセグメントを回している話、1つのウェブサイトで大きな流入を捌いている話などが更新され続けている。ここから言えるのは、運用量もベンダー構成もかなり動くということだ。
以降の4つの節は、次の表の右列にある4つの原則に、それぞれ1つずつ対応している。
| 運用スナップショット（変わりやすい） | 人間プレイブックの原則（今も残る） |
|---|---|
| 特定時点の返信率・開封率・売上寄与 | 人間プレイブックが先という順番 |
| その時点のベンダー名と組み合わせ | 対象をセグメントへ細かく区切る重要性 |
| 稼働中のエージェント数 | 継続運用のオーナーと毎日の見直しが要るという事実 |
| テキスト・音声・動画それぞれの出来不出来 | テキストから始めて安全策を増やす順序 |
1. 人間プレイブックが先に動いている
SaaStrが一貫して語っているのは、AI SDRを新しい営業手法の発明装置ではなく、すでに人間が勝っている手順を複製する装置として使うという考え方である（SaaStr AI London 2025セッション動画）。これは出典付きの事実として引用できる主張だ。
一方、ここから先は私の読みになる。人間プレイブックがまだ文章になっていない段階でエージェントに新しい文面を発明させようとすると、SaaStrの文脈でも失敗パターンにはまりやすいといえそうである。後続の公開記事でも、創業者主導の営業や人間のSDRがすでに挙げている成果を先に把握し、それをエージェントへ渡すという順番が繰り返し説明されている。
つまりAI SDRの最初の役目は、新しいGTM戦略を発見することではなく、既存の勝ち筋を再現することにある。人間の営業やマーケティングでの反応がまだ薄い段階なら、先に詰めるべきはメッセージと市場の反応の一致であって、AI SDRを実験の近道として使うことではない。
2. 対象をセグメントへ細かく区切る
SaaStrの後続記事で特に強く出てくるのが、対象を容赦なくセグメントへ分けるという話である。ウェブからの流入をひとまとめに「流入」と扱うのではなく、新規訪問者、広告経由、休眠顧客、既存顧客、価格ページの再訪問者のように分けて扱う必要があるとされている。
この扱い方は、どのベンダーを選ぶかより重要だと私は見ている。AI SDRは大量に送信すること自体には向いていても、誰に何を言うべきかという前提が雑だと精度が一気に落ちるからだ。SaaStrの記述を保守的に読むなら、勝ち筋はエージェントの賢さではなく、セグメントの定義、そのセグメント専用の文脈情報、すでに効いている文面、そして毎日の見直しの組み合わせにある。
最低限そろえたいのは次の4点である。
| 論点 | 具体的に何を指すか |
|---|---|
| 相手の属性 | 新規、既存、休眠、過去イベント参加者、現行顧客のどれか |
| 伝える価値 | なぜ今連絡するのか、前回と何が違うのか |
| 禁止事項 | 古い価格、古い日付、約束できない機能、誇大表現 |
| 引き継ぎ条件 | 高額商談、複雑な質問、法務・セキュリティに関わる質問 |
ここを詰めずに1つのキャンペーンへリードを足し続ける運用をすると、AI SDRの印象はすぐ悪くなる。
3. 継続運用のオーナーと毎日の見直し
AI SDRには、継続運用のオーナーが要る。これがこの節で持ち帰るべき論点である。
SaaStrの後続記事では、少なくとも1人、理想的には2人でエージェントの運用を見た方がよいと整理されている。理由は明快だ。セグメントの補充、文脈情報の更新、出力のレビューを止めると、エージェントはすぐに古い情報を出し始める。実際、SaaStrの公開記事では、導入初期に古いイベントの日付や古い価格、表記のゆれのような信頼を損なう問題を、出力レビューで拾っていたと説明されている。エージェントは、古い公開情報や整理されていない社内文書をそのまま増幅するからだ。
運用で外せないのは、最初の30日間は出力をかなり細かく読むこと、文脈情報とセグメントを毎日更新すること、そして属人化を避けるためにバックアップのオーナーを持つこと、の3つである。毎日の見直しで実際に点検すべきなのは、現行の価格と例外条件が最新か、古い日付が紛れ込んでいないか、CRMの属性がセグメントに必要な分だけ揃っているか、顧客が実際に聞く質問まで反映されているか、そしてどの条件で人間へ引き継ぐかが定義されているか、である。
この「オーナーが要る」という論点は、もう一段深く考える必要がある場面もある。SaaStrはAmelia AIやJason AIのように、特定人物の話し方や見た目に寄せたエージェントを運用している。この構成は信頼を作りやすい半面、再利用するときには運用面と権利面を分けて考える必要がある。
運用面では、その人物しかエージェントの中身を理解していない、退職や異動で保守が止まる、一人の営業メンバーに知識が閉じる、という問題が起こりうる。権利面では、どこまで実名・顔・声を使うのか、社外向けにどこまで約束してよいか、雇用契約や社内ポリシー上どう扱うか、という論点が残る。法的な整理は国や契約によって変わるため、本記事では一般論として断定しない。ただし、実在の人に似せたエージェントは、普通のチャットボットよりレビューする範囲が広いとは言える。
4. テキストから始める順序
SaaStrの後続記事では、専用のメールアドレスやIP warming、CRM連携、文面調整、セグメント準備まで含めると、導入には一定の立ち上げ期間が必要だとされている。具体的な日数はベンダーとメールの到達率状況で変わるため、ここでは固定の日数より順序を重視した方が安全だ。
推奨される順番は明快である。まずテキストでのやり取りを安定させ、次にレビューの仕組みと引き継ぎ条件を固め、必要であれば音声を試し、ブランドへのリスクと安全策を管理できる場合に限って動画アバターを加える。
SaaStrの後続記事では、複数の形式でエージェントを運用していても、そのやり取りの大半はテキストだと説明されている。この割合自体は今後変わりうるが、順序についての学びは今も残ると私は見ている。音声や動画は魅力的でも、本題から外れた質問、特定人物への依存、ブランドへのリスクが増える。テキストで品質基準を超えてから広げる方が失敗しにくい。
十分なウェブトラフィックがあるならインバウンド運用も試しやすいが、トラフィックが小さいならアウトバウンドや既存顧客対応から始める方が現実的である。重要なのは流入量の閾値を覚えることではなく、自社の対応漏れがどこにあるかを特定することだ。
導入可否を判断するチェック
ここまでの材料を、原則の再掲としてではなく、自社で導入するかどうかを判断するチェックとして並べ替える。
- 人間プレイブックの4点を文章にできているか。 誰に・何を・何回・どの条件で人へ返すか、のどれか1つでも曖昧なら、まだ導入のタイミングではない。
- 対象をセグメントへ区切り、セグメントごとの文脈情報と禁止事項を用意できるか。
- 継続運用のオーナーを置けるか。 できればバックアップも。置けないなら、放置される運用が確定する。
- 毎日、出力のレビューと文脈情報の更新にどれだけ時間を割けるか。 ゼロ分なら導入すべきではない。
- まずテキストから始め、レビューの仕組みを固めてから音声・動画に広げる順番を守れるか。
- 十分なウェブトラフィックがあるか。 小さいなら、まずはアウトバウンドか既存顧客対応から試す方が現実的である。
- ベンダー数は絞れているか。 最初から複数ベンダーを比較する必要はない。SaaStr自身は複数ベンダーを使っているが、後続記事では大半の会社は1ベンダー、必要でもインバウンド・アウトバウンドの2系統程度で足りると整理されている。
- 肩書きより、動ける人がいるか。 「GTMエンジニア」のような肩書きは必須ではない。CRM、セグメント、プロンプトや文脈情報、引き継ぎルールをまたいで動けるオーナーがいるかどうかが重要である。
このうち1つでも「文章にできない」「置けない」という答えが返ってくるなら、私はその会社にAI SDR導入を今すぐ勧めない。
おわりに
私はAI SDRを、営業の代替ではなく複製装置として読むべきだと考えている。そして上のチェックのどれか1つでも文章にできない段階の会社には、日本でも導入を見送るよう勧める。これはSaaStrの公開情報の読解と、当ブログでGTMの型を扱ってきた立場からの判断であり、AI SDRを自社で大規模運用した一次経験に基づくものではない。
では、私が日本のSaaSチームの立場だったら、どのmotionから、何を確認してから始めるか。上のチェックに従うなら、着手順はこうなると考えている。まず1つの動線だけを選ぶ。候補は休眠リードの掘り起こしか、イベントのフォローアップだろう。この2つは、多くの会社ですでに人間プレイブックの4点（誰に・何を・何回・どの条件で人へ返すか）が最も文章化しやすい領域だからだ。次に確認すべきは、ベンダーの機能比較ではなく、その動線に紐づくCRMの担当者が決まっているかどうかだと私は見ている。セグメントを定義しても、CRMの属性を誰が更新するかが曖昧なままでは、AI SDRは古い情報をそのまま増幅する側に回ってしまう。この順序は、営業の仕組みを継続的に設計する役割を整理した別の記事で、データ基盤の担当者を先に決めるべきだと述べたことと同じ考え方である。動線を1つに絞り、担当者を固定し、人間プレイブックを文章にする。この3つが揃うまでは、ベンダー選定に時間を使うべきではないと私は考えている。
この読み方は、以前OpenAIの営業組織の型を「需要超過の産物かどうか」で切り分けた別の記事と同じレンズの延長にある。SaaStrという公開情報の発信源を疑いながら読み、移植できる部分とできない部分を切り分けるという態度は、対象がAI SDRであっても変わらない。「営業の仕組みを継続的に設計する役割が要る」という論点は、GTMエンジニアという役割の整理とも重なる。次にSaaStrが新しいAI SDRの数字を出したときも、この記事の定義とチェックに立ち返って読み直したいと思う。
参考リソース
- 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研究シリーズの一部です。
