Personio CROが語るAI powered go-to-market 5つの教訓

このページは、SaaStr Podcast で Philip Lacor が語った営業組織の AI 導入パターンを読み解くための講演メモです。Personio の会社紹介や足元の事業状況を追う記事ではなく、営業組織が AI を入れるときに何を設計し、どこで失敗しやすいかを整理することに主眼を置きます。

固有の数値やツール名は、番組で共有されたケースとして扱います。自社に移すときは、そのまま模倣するのではなく、データ基盤、社内ルール、運用責任の置き方を別途確認してください。

---

この記事で拾う論点

1. AI powered go-to-market をツール紹介ではなく組織設計の話として読む視点
2. Philip Lacor が強調した 5 つの教訓
3. 講演内の実例を、自社の営業 workflow に移すときの確認ポイント

基本情報

---

この講演をどう読むか

この対談で価値が高いのは、どの AI ツールを買ったかという製品カタログではありません。Lacor が繰り返し話しているのは、営業組織の中で AI を動かす責任をどこに置くか、どの workflow から着手するか、そして日々の改善を誰が回すかという運用の骨格です。

もうひとつ重要なのは、導入事例を「派手な成果の再現レシピ」として読むのではなく、意思決定の順番として読むことです。先に workflow の詰まりを見つけ、その後にデータとツールを重ね、最後に文化として定着させる。講演全体はその順序で組み立てられています。

そのため、本記事でも company profile や市場の細かな位置づけは脇に置きます。再利用しやすいのは、営業現場のボトルネックをどう切り分け、どこまでを自動化し、どこからを人間の判断として残すかという視点だからです。

---

AI導入の5つの教訓

教訓1: ボトムアップとトップダウンを同時に回す

Lacor は、AI 導入を現場の実験だけに任せても、経営の号令だけで進めても失敗しやすいと語ります。現場には試す余地を与えつつ、予算、権限、優先順位は leadership が明確に持つ。この二層構造がないと、アイデアだけが増えて実装に進みません。

営業組織では特に、現場の工夫と運用ルールがぶつかりやすくなります。だからこそ「誰でも試してよい」状態と、「どの案を正式導入に上げるかを決める場」を切り分ける必要があります。

教訓2: AI 専任チームではなく cross-functional team を置く

講演では、AI 活用を RevOps だけの仕事に閉じず、データ、システム、営業現場が同じ table に座る体制が強調されます。理由は単純で、営業 workflow の問題は、ツールの設定だけではなく、入力データ、現場の行動、評価指標が絡み合っているからです。

この考え方は、多人数の専任組織を作るべきだという話ではありません。重要なのは、業務文脈を理解する人、実装を回せる人、成果責任を持つ人が同じ backlog を見ることです。

教訓3: Jobs to be done で workflow を分解する

Lacor は、AI 導入初期にアイデアが散らばりやすい問題に触れています。これを整理するために使っているのが、各ロールが「何を達成するために雇われているか」を分解する見方です。

ポイントは、ロール名ではなく仕事の単位で捉えることです。SDR、AE、CS といった肩書きだけを見ると抽象度が高すぎますが、情報収集、優先順位付け、提案準備、応答判断と分解すると、AI に渡せる部分と人間が持つべき部分が見えてきます。

教訓4: 文化づくりは導入後ではなく導入中に進める

講演で繰り返されるのが、AI は入れただけでは使われないという話です。Lacor は、リーダーが自分で使うこと、チームが事例を共有すること、改善した人を称えることを、文化づくりの中核に置いています。

これは啓発の話ではなく、運用設計の話です。営業メンバーが「使ったほうが得だ」と感じるまで、レビューの場、共有の場、評価の場で AI 活用が見えるようにしなければ、現場はすぐ元のやり方に戻ります。

教訓5: 新しいツールを増やすより、既存スタックに文脈を重ねる

この対談で一貫しているのは、新しい AI プロダクトを次々に増やすことより、既存の CRM、会話データ、社内資料に LLM をどう重ねるかを先に考える姿勢です。Lacor が重視しているのは、モデルそのものよりも、営業組織の文脈がどこに蓄積されているかです。

営業組織の AI は、単に文章を書かせる用途よりも、既存システムの断片を一つの判断材料にまとめる用途で効きやすい。講演の各事例もその前提で揃っています。

---

講演内で紹介された4つの実例

ここからは、番組内で触れられた例を「何が再利用可能か」という観点で読み直します。数値は会話の中で紹介されたケースとして扱い、一般化しすぎないことが前提です。

1. Win/Loss 分析を営業会話から引き上げる

Lacor は、商談の勝敗理由を営業担当の手入力だけに頼ると、粒度が荒くなり、競合カードも stale になりやすいと説明します。そこで会話データ、メール、CRM をまとめて読み、LLM で勝因・敗因を要約する流れを作ったと語ります。

この例の本質は、battle card の自動更新そのものではありません。製品フィードバックや競合理解を、営業の主観ではなく会話ログから引き上げる導線を作ったことにあります。自社に移すなら、まず「どのデータが同じ場所で読めるか」を点検するのが先です。

2. Expansion SDR のリサーチを圧縮する

講演では、既存顧客向け営業が複数システムを横断しながら情報収集していた workflow が紹介されます。Lacor は、この仕事を Salesforce 上の検索アシスタントに寄せた結果、リサーチ時間が 1 日 2 時間から 15 分まで縮んだと説明します。

ここで真似すべきなのは、劇的な削減率ではなく、検索対象と出力形式を固定した点です。営業担当が欲しいのは汎用チャットではなく、「このアカウントで次に何を見るべきか」を即答する補助線です。AI の価値は、検索窓を増やすことではなく、判断前の迷いを減らすことにあります。

3. Account Score に Intent Score を重ねる

もうひとつの例として、静的な企業属性だけではなく、行動シグナルを重ねて優先順位を変える仕組みが語られます。Web 訪問、レビュー、転職情報のような signal を使い、営業が今日どこに当たるべきかを見やすくする考え方です。

この話で大事なのは、精密な scoring model よりも、営業が既に見る画面の中に signal を埋め込んだことです。別ダッシュボードに閉じると使われず、既存 workflow の中に置くと初めて行動が変わります。

4. AI Chat は公開後の訓練が本番

講演では、Web チャットの AI 活用も紹介されます。短期間で多くの商談機会を生み出した一方で、不適切な応答や複数質問の取り扱いに失敗した例も率直に共有されます。そのため、専任オーナーが毎日ログを読み、修正を回す体制が必要だと語られます。

この例は、agent を公開した瞬間に運用が終わるわけではないことをよく示しています。営業 front door に AI を置くなら、生成品質の監視、禁止領域の定義、失注につながる分岐のレビューを daily operation に組み込む必要があります。

---

この事例を自社へ移すときのチェックリスト

1. Workflow 単位で詰まりを特定したか

「営業を AI 化する」では広すぎます。まずは account research、win/loss review、inbound qualification のように、ひとつの仕事へ落としてください。Lacor の話も、抽象論ではなく workflow 単位の改善として整理すると理解しやすくなります。

2. 文脈データの置き場が決まっているか

LLM の性能より先に、CRM、会話ログ、社内資料、運用ルールがどこにあるかを揃える必要があります。AI が賢く見える組織ほど、裏では「必要な文脈が取れる場所」を整えています。

3. AI のオーナーを決めたか

導入時だけ盛り上がっても、日々の改善責任が曖昧だと定着しません。誰が prompts を直すか、誰がログを見て止めるか、誰が成果指標を見るかを分けておくと、AI の失敗を放置しにくくなります。

4. 成果指標を一つに絞りすぎていないか

講演では ROI を単一指標で語りすぎない姿勢も印象的です。リサーチ時間、商談速度、提案の質、顧客対応の滑らかさなど、複数の変化が同時に起きるためです。短期の数字だけで切るより、workflow が以前より進みやすくなったかを観察するほうが実務では役立ちます。

---

まとめ

Personio の事例を読むうえで重要なのは、「AI に何をさせたか」よりも「営業組織のどこに判断コストが溜まっていたか」を見抜くことです。Lacor の話は、AI 導入をツール選定の話ではなく operating model の更新として捉える材料になります。

営業組織で AI を進めるなら、最初に確認すべき順番はほぼ同じです。workflow を分解する。文脈データの置き場を作る。cross-functional team で実装責任を持つ。リーダーが使い、改善を日次運用に乗せる。この流れがあるなら、ツール名が変わっても学びは残ります。

---

参考リソース

• 元動画（SaaStr Podcast）
• SaaStr解説記事: How Personio's CRO Built an AI-Powered GTM in 6 Months
• Personio公式サイト