Grok Bot SDRガイド：Cursorでリサーチと下書き、Botで重複確認と未送信トリアージ

Grok BotのSDRガイドは、2つのツールが連携するアウトバウンドフローを提示している。営業開発担当者（SDR）のStefan Markarian氏は、CursorのクラウドAgentを使ってHex、Salesforce、Gongからアカウントリサーチと初回メールを準備させ、続いてGrok Botにシステム横断のステータス確認、レコード作成、未送信シーケンスへの配置、スプレッドシートのメンテナンスを実行させている。

リードのステータスが明確な場合は準備を続行し、一時停止、初期ステージの商談、あるいは身元に関する疑問点がある場合はFLAGに送り、営業担当者の判断に委ねる。メールは人間がレビューして送信し、メッセージなしのLinkedInつながり申請は専任のJohn Ford Botが上限に従って処理する。

デュアルエンジンの役割分担：CursorとGrok Botをどう組み合わせるか

多くのチームが大規模言語モデル（LLM）で営業プロセスを変革しようとする際、最も陥りがちな過ちは「何でも1つに抱え込ませる」ことだ。極めて長大なプロンプトを書き、1つのAIアシスタントに情報収集から文面作成、さらにはシステム内でのボタンクリックによる送信まで行わせようとする。その結果、途中のステップでAIがハルシネーションを起こして処理が中断するか、フォーマットの崩れたスパムメールが重要顧客に直接誤爆されるかのどちらかになりがちだ。

Stefan氏のアプローチの核心は、「高度な認知・テキスト合成」と「システムをまたぐブラウザ上の泥臭い作業」を完全に切り離し、それぞれに最も適したツールへ委ねる点にある。

┌────────────────────────────────────────────────────────┐
│              夜間バックグラウンド：Cursor 深層合成エンジン               │
│      Hex (フットプリント) + Salesforce (商談) + Gong (録音)      │
│                           ↓                            │
│           出力：アカウント調査パケット (Research Packet)          │
│                + 個人のトーンを反映した初回アプローチ下書き      │
└──────────────────────────┬─────────────────────────────┘
                           │ データパケット引き渡し
┌──────────────────────────▼─────────────────────────────┐
│          早朝常駐：Grok Bot 専任エージェントトリアージマトリクス          │
│                                                        │
│  ┌────────────────┐  トリアージ ┌───────────────────┐  │
│  │   Josh Allen   │ ─────────► │ CLEAR：確認済み仮配置 │  │
│  │ (チーフオブスタッフ)│システム間重複確認│ FLAG ：人間判断プール │  │
│  └───────┬────────┘            └───────────────────┘  │
│          │ 並行振り分け                                │
│   ┌──────┴──────────────┐                              │
│   ▼                     ▼                              │
│ Contact Man (シート番人) John Ford (LinkedIn開拓)       │
└──────────────────────────┬─────────────────────────────┘
                           │ 集約・サマリー
┌──────────────────────────▼─────────────────────────────┐
│              早朝出社：人間のSDRが最終コンソールを掌握              │
│  1. 懸念点のない 1 件の CLEAR メールを素早く確認して送信をクリック │
│  2. 34 件の FLAG 複雑エッジケースの判断に集中                 │
│  3. メールは人間が送信。LinkedIn白紙申請はJohn Fordがルールに沿って処理│
└────────────────────────────────────────────────────────┘

1. Cursor：詳細な読み込みとパーソナライズ下書きを担う「オフラインの頭脳」

• 担当領域：リサーチ（Research）、プロスペクト選定（Prospect）、ドラフト作成（Draft）。
• 主な強み：ローカルまたはクラウドのコードエディタ級のワークフローをベースに、Cursorは極めて強力な長文コンテキスト統合能力を備えている。営業リサーチに特化したスキル（Skills）を通じて、Hexから製品のテレメトリ利用実績を直接抽出し、Salesforceの過去の失注（Closed-lost）記録を調べ、Gongの通話ポイントを要約して、構造化された「アカウント調査パケット（Research Packet）」を合成する。そして早朝までに、担当者本人の自然な語り口で最初のアプローチメール（First-touch）を下書きとして書き上げる。
• 成果物：直接送信されるメールではなく、明確な事実の根拠を伴う高品質な半完成品ドラフトである。

2. Grok Bot：複数システム間の作業と受け入れトリアージを担う「常駐の実働部隊」

• 担当領域：システム受け入れ（Intake）、マルチプラットフォームでの重複確認、ステータス同期、ツール横断の実行。
• 主な強み：常駐して動作し、ノートPCを閉じてスリープさせている間も稼働し続ける。Cursorが生成したデータを受け取り、人間の代わりにNooks、Amplemarket、Salesforce、LinkedInを行き来しながら検証を行う。
• 成果物：リードを「検証済み・未送信シーケンスに仮配置可能（Unsent）」と「疑問点あり・人間が裁定（FLAG）」の2つにトリアージし、各システムのステータスを同期する。

SDR 5ステップの業務ループ：断片的なデータから送信確認まで

実際のアウトバウンドの現場において、このシステムは標準的なSDRの5つの段階的プロセスに厳密に組み込まれている：

ステップ1：リサーチ（Research）——実際のフットプリントからアカウントの全体像を描き出す

ネット上で適当に検索したありきたりなニュースでアプローチすることは決してしない。Cursorのクラウドエージェントは3つの実データソースを取得する：

1. Hexのデータフットプリント：顧客企業では現在、何名のエンジニアが実際に製品を試用しているか？アクティブシート数は増加しているか、それとも停滞しているか？
2. Salesforce CRMの履歴：過去にやり取りがあったか？直近の失注（Closed-lost）は予算不足か、タイミングの問題か、あるいは重要な機能の不足が原因だったのか？
3. Gongの通話録音：過去の会議メモを呼び出し、相手が当時実際に語っていたビジネス上のボトルネックや特定の技術選定を抽出する。

ステップ2：プロスペクト選定（Prospect）——「役職よりもフットプリント重視」のルール

多くのアウトバウンド担当者は、最初からVPやディレクター（Director）を検索しがちだ。しかしこの体系では厳格な階層ルールを適用する：

• 既存の知人を最優先：以前Gongで話した担当者がまだ社内に在籍している場合、優先して再接触（Reconnect）を図る。
• コールドアウトリーチは利用実績の浸透度を見る：システムは製品のシート数とソフトウェアエンジニアリング組織の規模を比較する。製品のフットプリントが十分に強固な場合は、Golden Listに基づいて職責が合致するディレクター以上（Director+）のアプローチ対象を選定する。フットプリントがまだ浅い場合は、マネージャー以上（Manager and above）へとアプローチする。

ステップ3：ドラフト作成（Draft）——ビジネス上のシグナルを単刀直入に示す

Cursorは書き手のスタイルスキル（Writing Skills）を厳格に遵守し、「良い月曜日をお過ごしのことと存じます」といった定型的な決まり文句の流用を排除する。メール冒頭の1文目は、アカウントの具体的な事実を必ず引用しなければならない。例えば「インフラチームによるHexでのテレメトリ呼び出しが最近大幅に増加しているのを拝見し……」や、「以前のGongでのやり取りを見返したところ、当時コンピューティングノードを新クラスタへ移行するご計画を進めておられましたが……」といった具合だ。

ステップ4：受け入れトリアージ（Intake）——CLEARとFLAGのコアファネル

これこそがシステム全体で最も精巧な仕組みだ。リード発掘リスト、Cursorの早朝パケット、あるいはChatGTMの受信トレイから渡されたすべてのリードは、Grok Botによる全方位的なシステム精査を受けなければならない：

• CLEAR（受け入れ許可）：検証の結果、対象リードがNooksのアクティブなシーケンスに含まれておらず、Amplemarketで一時停止中（Paused）でもなく、SalesforceのStage 0初期商談にも紐付いていない状態。チェックを通過すると、Botは下書きをNooksに入力してシーケンスへ仮配置し、ステータスはUnsent（準備完了・未送信）のまま保持される。これはあくまで事前配置の仮置きであり、リスクゼロを保証するものではない。
• FLAG（判定待ち）：疑わしい状況を遮断し、人間の判断を待つ。例えば、Amplemarketで一時停止中になっている、SalesforceでStage 0初期商談に紐付いている、ほぼ同一のメールアドレスが2つ存在するといったエッジケースは、すべて人間のToDoリストへ送られる。

ステップ5：最終決定・送信（Finalize）——人間によるレビューと送信

SDRが朝PCを開くと、整理されたモーニングレポートが表示される：

• CLEARとマークされた案件については、人間がNooks上でKEEP（維持）の判断を下し、手動で送信する。
• メッセージなしのLinkedInつながり申請は、専任Bot（John Ford）が個別に送信する。これが自動実行における唯一の例外となる。
• 人間はFLAGリストにあるエッジケースの処理に集中し、1件ずつ裁定を下す。

専任エージェントチーム：なぜ「1 Bot 1 職務」でなければならないのか？

このアーキテクチャにおいて、Stefan氏は万能のスーパーBotを1つ作るのではなく、職責が明確に定義された5つの専任エージェントに細分化した：

マルチエージェント自律協調の境界

これらのBot同士は人間が仲介することなく直接連携できる。例えばJosh Allenが一連のリードについてCLEARの選別を終えると、同一バッチ内でContact Manにスプレッドシートの更新を指示し、同時にJohn FordへLinkedInつながり申請の処理を通知できる。

この受け入れフローでは、CLEARは事前配置の仮置きを進め、FLAGは人間の判断を待つ。すでにアクティブな接触があるリードは現状維持とし、重複アプローチを防ぐ。CRMのエラー修正やシーケンスの修復は、各ロールの責務に応じて個別に処理される。

ある早朝のトリアージ実例：41件の処理サンプル

元記事では、筆者の直近のある朝における実際のバッチを事例として挙げている（このバッチは合計41名で、6 + 34 + 1 のサンプル集計値であり、公式発表の総数や一般的な通過率を示すものではない）：

早朝バッチ処理内訳（本事例の合計）：

• 本事例の対象リード合計：41名
• 他のツールで接触中（現状維持・処理スキップ）：6名
• エッジケースに該当しFLAG判定待ちへ移行：34名
• 条件を完全に満たし仮配置（CLEAR）：1名（筆者が確認のうえ送信、John FordがLinkedIn白紙申請を処理）

このフローでは、状態ごとに異なる処理ステップが割り当てられる：

1. 重複アプローチの防止：6名がすでに他のツールでアクティブな接触中であると特定され、Botは現状維持として不要な重複連絡を防止する。
2. エッジケースは人間の判断に委ねる：FLAGと判定された34名は、Amplemarketで一時停止中、Salesforceで初期ステージの商談に紐付いている、ほぼ同一のメールアドレスが重複しているなど、すべてエッジケースに該当する。システムがこれらを集約して人間の裁定に委ねるため、人間がシステム間を1つずつ精査する手間が省ける。
3. シーケンス設定の一括修正：例えば以前、24名のメールが誤ったシーケンスに配置されていた際、Josh Allenが一括で引き継いで既存ステップを完了させ、エンジニアの役職に応じて「メールのみ」または「電話のみ」の設定に再分類し、初回の架電を翌日の午後にスケジューリングした。人間がドラフトと最終承認をコントロールすることで、フォローアップの漏れを防ぐ。

健全な営業活動を維持するための5つの鉄則

このシステムを日常の標準作業手順（SOP）として定着させる過程で、チームは決して破ってはならない5つのルールを導き出した：

1. 決して自動送信しない（Never auto-send） エージェントはデータの調査、ドラフト作成、オブジェクト生成、Nooksでのシーケンス配置まで実行できるが、最後の「送信」ボタンは人間の営業担当者が自らの手でクリックしなければならない。人間の目は、AIのハルシネーションによってブランドの信頼が毀損されるのを防ぐ最後の砦である。
2. 定型文よりも過去の接点を優先する（Warm history beats a cold template） Gongの通話記録に過去のやり取りがたとえ1度でも残っていれば、初回のメールはその通話で交わされた具体的な事実を切り口にしなければならない。標準的な製品提案テンプレートを使って、すでに面識のある相手を初対面のリードのように扱うことは固く禁じられる。
3. 役職よりも製品のフットプリントを重視する（Footprint beats title） Hex上の利用量とシートの浸透度が、SDRが工数を割いてディレクターやVPへ接触する価値があるかを決定づける。いくら華々しい役職であっても、現場の技術チームが誰も製品を試用していない状態でいきなり上位役職者に突撃しても、反感を買うだけだ。
4. LinkedInのつながり申請は常にメッセージなし（LinkedIn requests stay blank） 筆者はLinkedInのつながり申請をメッセージ添付なしで設定している（元記事ではメッセージ有無による承諾率の比較は行われていない）。John Fordは純粋なつながり申請のみを送信する。さらに、プロフィールURLに少しでも曖昧さがあれば、無理に推測せずFLAGとして保留し、大規模言語モデルの確率に頼ってターゲットかどうかを「当てずっぽうで判断する」ことは絶対に避ける。
5. 同じフィードバックが2度続いたら即座にスキルルール化する（Repeated feedback becomes a rule） 人間が下書きをレビューする際、AIの作成した文章が冗長であることや、特定の役職者を架電リストに含めるべきではないといった問題が2度連続して確認された場合、そのメールを手作業で修正して終わらせてはならない。直ちにその制約をCursorやGrok Botの恒久的なPrompt/Skillルールファイルに書き込む必要がある。

実践アセット：そのままカスタマイズ可能なプロンプト＆ルールテンプレート

上記のアプローチを自社の業務環境に落とし込むにあたり、全く同一のツールスタックを揃える必要はない（例えば、Hexは自社のデータウェアハウスやユーザー行動分析システム、SalesforceはFxiaokeやXiaoshouyi、GongはLark MinutesやDingTalk Flash Notes、Nooksは自社導入のコールシステムやメール配信基盤などに置き換えられる）。

本質はプロンプトに組み込む判定ロジックと境界条件の制約にある。以下は元記事のワークフローをベースに作成した2つの設定例である（元記事ではこれら完全なプロンプト自体は公開されていない。4〜5文といった長さの指定は調整可能な編集上の推奨値であり、SKIPは「現状維持・処理スキップ」を示すための解説用ラベルである）。

アセット1：Cursor リサーチ＆初回メール作成仕様（Markdown形式・Skillルールとして利用可能）

# ロールと目標
あなたはエンタープライズ向け技術プロダクトを担当するシニアSDRリサーチアシスタントです。あなたの任務は、顧客の製品利用フットプリント、CRMの履歴、過去の通話録音を統合し、構造化されたアカウント背景パケットを出力するとともに、SDR向けに高い反応率が見込める初回アプローチメールの下書きを作成することです。

# 入力データの制約
以下の3つのファクトソースを必ず読み込み参照すること。裏付けのないデータの捏造は固く禁じます：
1. [利用フットプリント]：対象顧客の実際のアクティブシート数と浸透傾向を分析する。
2. [CRM履歴]：過去の失注（Closed-lost）の理由、離職した連絡先、競合に関する議論の有無を確認する。
3. [通話アーカイブ]：過去の通話で相手が明確に言及した技術的課題、組織変更、または障害となった懸念事項を抽出する。

# アプローチ階層の判定ルール (Footprint vs. Title)
- 製品の利用シート数とソフトウェアエンジニアリング組織の規模を比較する（[チームで確認済みの利用量と組織比率] に基づいて判定）：
- 製品のフットプリントが浅い場合（基準値未満）：
  * アプローチ対象をマネージャー以上（Manager and above）に限定する。
  * ディレクター級へのコールドアプローチは実際の職責とフットプリント条件を別途確認し、役職だけで引き上げてはならない。
- 製品のフットプリントが十分に強固な場合：
  * Golden Listの中から職責が合致するディレクター以上（Director+）を抽出してアプローチ対象とする。
  * メールの訴求点：開発効率の向上や商用化の安全性の観点からアプローチする。

# 初回メール作成ルール
1. 冒頭の無駄な挨拶を排除：「ご清栄のこととお慶び申し上げます」「突然のご連絡失礼いたします」などの定型句は使用禁止。
2. 1文目は必ず客観的事実に基づいたトリガーであること（Gongで残されていた前回の課題や利用量の急増など）。
3. 全文を4〜5文以内に収め、専門的かつ率直、抑制の効いたトーンで、エンジニア仲間としての議論の姿勢を保つ。
4. コールトゥアクション（CTA）：具体的な機能の使い勝手を尋ねるなど、相手にとって負担の少ない具体的な意見交換を提案し、無理にデモを売り込まない。

# 出力フォーマット
- 【アカウント診断】：(利用状況の概要 / 過去の経緯 / アプローチの切り口)
- 【推奨ターゲット】：(氏名 / 役職 / 選定理由)
- 【メールドラフト】：(件名 + 本文)

アセット2：Grok Bot / チーフオブスタッフ システム横断受け入れ＆トリアージルール（CLEAR vs FLAG）

# ロール：朝のアウトバウンド受け入れ審査官 (Chief of Staff Agent)
あなたはアウトバウンドシステムの整合性とブランドの信頼性を守る責務を担っています。上流から渡されたリードリストを受け取り、各システム間で厳格な照合を行い、各リードをCLEARまたはFLAGに分類してください。

# 判定フロー
リスト内の各リードに対して、以下の2つのルールグループに従ってチェックを実施してください：

1. [システム精査]：
   - リードがすでにNooksでアクティブな状態にあるか確認。すでに接触中の場合は【SKIP】に分類（現状維持とし、重複してアプローチしない）。
   - リードがAmplemarketで一時停止（Paused）になっているか確認。一時停止中の場合は【FLAG】に分類（一時停止状態は人間の判断を待つ必要があり、SKIPに分類したり自動で無視したりすることは固く禁じます）。
   - Salesforce上で該当リードがStage 0の初期商談に紐付いているか確認。紐付きがある場合は【FLAG】に分類（人間の判断に委ねる）。
   - ほぼ同一のメールアドレスが2つ存在するなど、疑わしいエッジケースの有無を確認。存在する場合は【FLAG】に分類。

2. [LinkedIn申請のコンプライアンス]：
   - 当日の申請送信数が上限（Daily Cap）に达していないか確認。
   - 承認待ち（Pending）の申請数を確認。
   - LinkedInのプロフィールURLを検証。検証できない場合は【FLAG】に分類（推測せず、直ちに遮断して確認待ちとする）。

# 実行アクション
- 【CLEAR】の場合：
  * チェック通過後に仮配置可能であることを示すのみであり、リスクゼロを保証するものではない。
  * ドラフトをNooksに入力してシーケンスへ仮配置し、ステータスは厳格に「Unsent（未送信）」を維持する。
  * シート保守Botがシートを更新してステージング済みステータスを記録し、重複処理を防止する。
  * John Fordが上限の範囲内で検証を行った後、メッセージなしのLinkedInつながり申請を送信する。
- 【FLAG】の場合：
  * いかなる疑問点や一時停止状態であっても直ちに後続アクションを停止し、自動送信は厳禁とする。リード情報および具体的な状況をSDRの朝のToDoとして記録する。

エージェントを実際の業務に落とし込むための示唆

このSDRの実践は、実際のビジネス現場でエージェントを導入しようとするチームに対して、極めて実践的で明快なパラダイムを提示している：

• 自動化の目的は人間の意思決定の代替ではなく、人間を「雑務」から「重要な判断」のポジションへと引き上げることにある：営業担当者はシステム間を往復する単調な作業から解放され、過去に接触履歴のある顧客に対してどのような切り口で再び関係を構築すべきかといった、本質的な判断に集中できるようになる。
• 「立ち止まる権利」をエージェントに持たせる：真に実用的なエンタープライズ級エージェントシステムの評価基準は、どれほど速く動いたか、何通メールを送ったかではない。異常なデータや商談重複のリスク、曖昧な情報に直面した際に、鋭敏に立ち止まってフラグ（FLAG）を掲げ、人間の確認を仰ぐことができるかどうかである。

夜間にモデルが複数ソースのデータを統合して文面を下書きし、バックグラウンドの常駐エージェントがシステム間の検証とデータ受け渡しを担い、最後に人間が最終送信と重要判断を下す——これこそが、複雑な業務シナリオにおける人とAIの現実的な協調分担のあり方である。

元記事で提供されているテンプレートリンク

• Add Josh Allen to Grok Bot
• Add Contact Man to Grok Bot
• Add John Ford to Grok Bot
• SFDC Create
• Sequencer
• GTM Account Researcher to Grok Bot

上記は元記事で提示されているリンクです。導入後、自身のアカウント、データ、ツールとの連携が別途必要となります。今回の検証ではインストールやログイン後のテンプレート状態の確認までは行っていません。