Grok Bot 創業者セールスガイド：Founder Mode でつなぐ初期顧客と製品フィードバック

Grok Bot の Founder Mode は、Simon Lackowski が創業者自ら行う初期セールスのために設計したワークスペース構成である。1 名のチーフオブスタッフと 8 つの専門 Bot で構成され、顧客リサーチ、アウトリーチ、商談資料の準備を行い、顧客からのフィードバックを製品改善やその後のコミュニケーションへとつなぎ合わせる。

専任セールスを初めて採用する前に、創業者は顧客がなぜ購入するのか、どのように価格を設定すべきか、そしていかにして再現可能な営業手法を確立するかを自ら学ぶ必要がある。Bot は関連する背景情報や下書きを事前に準備するが、送信、契約、価格設定、コードのマージには依然として人間の承認が不可欠である。

一、初期セットアップと 8+1 アーキテクチャ：創業者のために 24 時間待機する協働チームを配備する

AI を業務に取り入れようとする際、多くの人が陥りがちな最大の誤りは、すべての要求を 1 つのチャットウィンドウに詰め込み、コンテキストを収拾のつかない状態にしてしまうことである。Founder Mode の設計における中核原則は「1 つの Bot は 1 つの具体的な業務のみを担当する」ことであり、4 つの色分けされたフォルダ（Pipeline、Customers、Product、Marketing）によって分類・分離されている。

クラウド上の仮想マシンに常駐する Grok Bot は、ノート PC の画面を閉じている間も稼働し続ける。毎朝オフィスに入ると、夜間に準備されたタスクがすでに分類され、該当する ToDo トレイに整理されている。Bot には記憶機能が備わっており、過去のメール履歴を読み取ってアウトリーチのスタイルを把握し、ドラフト作成を担当するすべての Bot が準拠すべきトーン＆マナーのガイドラインを抽出する。

初期セットアップ：Founder Mode setup pack とツール連携

デプロイの最初のステップは Founder Mode setup pack のインストールである。これには 1 名のデジタルチーフオブスタッフ Bot、4 つのサイドバーフォルダ、8 つの専任 Bot、16 個の一時停止状態のルーティン（paused routines）、および 1 つの共有データフォルダが含まれている：

• 約 20 件の初期ヒアリング（Onboarding）：システムは企業の事業内容とピッチの要点、創業者のトーンサンプル、ICP（理想的な顧客プロファイル）、ターゲットアカウント、競合リスト、P0 レベルの問題の定義、コネクタの選択、およびどのルーティンを有効化するかの決定を求めてくる。
• スケジュール確認後に有効化：すべてのルーティンは初期状態で一時停止となっており、創業者が希望する実行スケジュール（preferred schedule）を明確に承認した後に初めて、該当する routine が正式に有効化される。
• ツール連携の進め方：すでに使用しているツールを優先して連携する——Gmail と Calendar（下書き作成と読み取り専用権限のみ付与）、商談追跡表（Deal Tracker）の CSV（スプレッドシートの許容量を超える規模になるまで）、LinkedIn と X（下書きと読み取り専用権限のみ付与し、投稿は手動を維持）、および通話記録・議事録ツール Granola。CRM（HubSpot や Attio など）、Product Bot がエンジニアリングと連携するための GitHub、キャッシュの照合に用いる Stripe や Mercury、そしてリアルタイム連携用の Zapier や Make などの Webhook は、後から必要に応じて連携できる。

創業者セールスにおける 6 つのステップをマッピング

このアーキテクチャは、スタートアップが最初の専任営業を採用する前に必ず経験する 6 つの重要な事業フェーズをそのまま反映している：

1. ICP の明確化（Define your ICP）：誰が製品から真の価値を得られるのか、どこに存在するのかを明確にし、誰が財布の紐を握る経済的バイヤー（economic buyer）で、誰が日々の現場で痛みを抱えている当事者（who feels the pain）であるかを明確に区別する。
2. デザインパートナーの開拓（Find design partners）：ICP をもとに精緻なターゲット顧客のショートリストを作成し、人的ネットワークや過去のやり取りの中から友好的なアプローチ経路（warm paths in）を探し出す。
3. 初回商談の準備（Prep for first meetings）：ターゲットアカウントの背景を事前に徹底調査し、対話のリハーサルを行い、重要なニーズ探索（discovery）のフレームワークを設計する。
4. 最初のセールスプレイブックの確立（Build your first playbook）：初期の対面コミュニケーションを、再現可能で、最終的には新しいセールス担当者に引き継げる標準化された仕組みへと磨き上げる。
5. パイプラインの推進と予測（Run pipeline and forecasting）：案件の進捗を継続的に管理し、実際にどの要因が収益成長を牽引しているのかを見極める。
6. 製品の継続的な改善（Make your product better）：最前線で収集した顧客や製品へのフィードバックを、新機能開発の優先順位を決める直接的な根拠へと昇華させる。

アーキテクチャ全体は、1 名のチーフオブスタッフと 8 名の専任エキスパートで構成されている：

1. 統括コントロールセンター：Founder Mode（チーフオブスタッフ Bot）

これは創業者が日常的に直接やり取りする唯一の Bot である。全体の統括を担当する：

• 毎朝 8:00：他の 8 つの Bot が夜間に生成したすべての仕掛品を統合し、単一の「デイリーアクションリスト（Daily Action List）」を作成する。
• 毎週月曜日：実際に入金された収益（incoming revenue）と突き合わせて照合を行う。
• 毎週金曜日：1 週間のパイプラインの進捗と成約／失注分析の要約（Win/Loss Digest）を出力する。
• 毎月 1 回：投資家向け月次レターの下書きを作成し（創業者の承認が必要）、市場のフィードバックを踏まえた ICP（理想的な顧客プロファイル）の調整案を提示する。
• 全体のサーキットブレーカー（即時遮断機構）：システムが検知した P0 レベルの深刻な顧客クレームや緊急のバグは、バッチ処理をバイパスして即座にここに報告される。

2. Pipeline フォルダ：商談推進チーム

• Sell Bot（商談・面談およびフォローアップ）：現在進行中の実際の案件に特化する。商談前にはカレンダー、Granola の通話録音、ステークホルダーマップから要点を抽出して 1 ページの「事前ブリーフィング」を作成。商談終了から数分以内に、下書きトレイに議事録、個別最適化されたフォローアップメールを自動起草し、創業者に対して CRM のステージ（Stage）変更案を提示する。絶対的なレッドライン：提案書の見積もり、価格の変更、契約条件を勝手に判断することは厳禁。
• Outreach Bot（アウトリーチ・アプローチ）：毎朝 7:00 にその日のアウトリーチのバッチをステージング（下書き保存）する。これにはコールドメール、原著者が述べる「5〜6 日のフォローアップ・ケイデンス」のスケジュール（合計約 8 回のアプローチで終了。原文には各回の詳細な間隔表は記載なし）、および潜在顧客ごとにペアで起草された LinkedIn メッセージが含まれる。実行前にまず商談追跡表（Deal Tracker）を読み込み、進行中の商談相手や連絡不可（Do Not Contact）とマークされた対象を自動的に除外する。ウォームリードは Social Bot から引き渡される。下書きのバッチ全体はすべて創業者の承認待ちとなり、決して自動送信されることはない。

3. Customers フォルダ：顧客・インサイトチーム

• Inbox Bot（サポート受信箱・顧客ケア）：サポート宛ての受信箱を毎日 2 回スキャンし、P0 から P4 まで優先度を評価して、創業者のトーンで返信の下書きを作成し、すべての内容を共有フィードバックログに追記する。書籍『ザ・ママ・テスト』（The Mom Test）の原則を取り入れ、顧客の「お世辞の賞賛」と「過去の実際の行動」を厳密に区別して記録する。P0 レベルの問題やバグは即座に Founder Mode へエスカレーション報告される。新機能がリリースされた際には、その要望を出していたすべての顧客に対して個別のフォローアップ通知を下書きする。
• Insights Bot（ニーズ分析・クラスタリング）：フィードバックログ、外部シグナル、商談議事録に対して週に 1 回クラスタリング分析を実施する。出現頻度、影響を受けるアカウント数、影響を受けるパイプライン規模（frequency, accounts and pipeline affected）に基づいてテーマを順位付けし、ICP の変更案を提示する。総合順位が最も高く、あらかじめ設定した閾値を超えたテーマのみが Product Bot へと渡される。

4. Product フォルダ：プロダクト・エンジニアリングチーム

• Product Bot（要求仕様・開発ドラフト）：上位にランクされたテーマを受け取り、簡潔な技術仕様書（Spec）へと変換して GitHub 上に Issue を作成し、クラウド上のコーディング Agent を呼び出して Draft PR（ドラフトプルリクエスト）を作成させる。絶対的なレッドライン：コードを自動でマージすることは決してない（Never merges）。マージ前には必ず人間によるレビューと承認が必要である。コードがマージされた後、更新履歴（Changelog）を下書きし、顧客への完了通知を行うために Inbox Bot へ引き渡す。
• Stalk Bot（競合レーダー）：競合の動向を監視するために専用の独立したテスト用メールアドレスを使用し、創業者の本物のメールアドレスは決して使用しない。スキャンのたびに競合がどのような変更を行ったかをまとめるだけでなく、末尾に必ず 2 つの成果物を出力する：Sell Bot に渡す対抗ポジショニングの話法（Counterpositioning Move）1 件と、Content Bot に渡すコンテンツの切り口 1 件である。公に投稿することは決してなく、誰かにダイレクトメッセージを送ることも決してない。

5. Marketing フォルダ：マーケティング・発信チーム

• Content Bot（コンテンツマーケティング・ソーシャル資産）：創業者のトーンで長文のソーシャル投稿、機密情報を除去した匿名事例集（Case Studies）、週次コンテンツカレンダーを下書きする。抽出された実際の顧客事例・論拠（Proof Points）は、現場のセールスの武器としてフィードバックされる。すべてのコンテンツは創業者が手動で公開をクリックする。
• Social Bot（ソーシャル課題レーダー）：毎営業日の朝にトレンド、自社ソーシャルアカウント、ターゲットアカウントをスキャンして返信を下書きし、エンゲージメントのあったユーザーをウォームリードとして Outreach Bot に引き渡す。また Insights Bot も、直近の商談、ヘビーユーザーの機能利用状況、顧客プロファイルの変化を組み合わせて、さらにヒアリングすべき候補者を提案する。

二、インタラクティブサンドボックス：2 つの閉ループ循環とレッドライン防御

これら 9 つの Bot がオーケストラのようにいかにシームレスに協働しているかを直感的に理解できるよう、以下のインタラクティブサンドボックスでは、システムが稼働する2 本のメインループ、9 つの Bot の詳細な責務と絶対的レッドライン、そして 1 件のリードがシステムに入った後の3 分岐トリアージロジックを視覚化している：

三、連動する 2 つのループ：SNS 上の不満がいかにして本番コードへと進化するか

この仕組みにおいて真の威力を発揮するのは、個々の Bot の能力ではなく、Bot 間をデータが循環することで構築される2 つの閉ループである：

ループ 1：案件獲得ループ

1. Social Bot が課題を公開投稿している潜在ユーザーをスキャンし、ウォームリードおよび Insights Bot が特定した高価値な方向性を Outreach Bot へ渡す。
2. Outreach Bot は Deal Tracker とクロスチェックして商談中や連絡不可の対象を除外した上で、人的ネットワーク内のアプローチ経路を探し、メールと LinkedIn メッセージのドラフトをペアで作成する。
3. Founder Mode がデイリーアクションリストとして提示し、創業者が手動で確認した後に送信される。
4. 顧客から返信が得られると、Sell Bot が商談前にブリーフィングを自動生成し、商談直後には議事録、フォローアップメール、ステージ更新案を起草する。

ループ 2：製品の自己進化ループ

1. 商談議事録とカスタマーサポートメールが共有フィードバックログに集約される。
2. Insights Bot が毎週、出現頻度、影響を受けるアカウント数、影響を受けるパイプライン規模に基づいてクラスタリングと順位付けを行い、ICP の調整案を抽出する。
3. 高優先度のテーマが設定した閾値を超えると Product Bot へ送られ、クラウド Agent が仕様書を作成し、GitHub Issue の起票と Draft PR の作成を行う。
4. コードのマージ前には必ず人間による厳格なレビューを実施。マージ完了後、Product Bot が更新履歴（Changelog）を作成する。
5. Inbox Bot がかつてその要望を出したすべての顧客に向けて個別通知を下書きしてループを閉じ、Content Bot が実際の事例を抽出して現場セールスの武器として還元する。

これら 2 つの閉ループでは、すべてのノードが下流へとバトンを渡していくが、すべての出口は安全境界によって厳重にロックされている：

1. インプット段階のバッティング防止フィルタ：Outreach Bot は実行前にまず Deal Tracker を照合し、進行中の商談相手や連絡不可の顧客に誤ってアプローチすることを防ぐ。
2. 処理段階の信憑性ラベリング：Inbox Bot は『ザ・ママ・テスト』の原則を取り入れ、表面的なお世辞と過去に実際に発生した行動を厳密に区別する。未払いのフィードバックを一律に偽のニーズと切り捨てるのではなく、社交辞令に製品開発が惑わされるのを防ぐ。
3. アウトプット段階の人間による承認：送信メール、ソーシャル投稿、コードのマージ、投資家向けレターの下書き、CRM レコードの書き込み、請求書の最終確認はすべて、創業者が自ら確認して承認する必要がある。

原著者が示した 1 週間：8 組のドラフトから金曜の振り返りまで

月曜日のリストでは、Outreach Bot が 8 組のメールと LinkedIn メッセージの下書きを用意する。プロファイルに合致し、実際のシグナルとアプローチ経路があるものは KEEP へ。合致するものの「なぜ今なのか」が欠けているものは HOLD へ。すでに商談中、既存顧客、または連絡不可のものは DQ となり、アプローチの下書きは作成されない。週の半ばには商談前資料が事前に準備され、商談終了から数分以内に振り返りとフォローアップの下書きが完成する。セキュリティ関連の質問に対する回答の中で未検証の主張（UNVERIFIED）がある場合は明確にマークされる。金曜日には影響を受けるアカウントやパイプライン、停滞している次のアクション、来週のコミットメントがまとめられる。この「8 組」は著者が示したサンプルのバッチサイズであり、デフォルトの固定日次ノルマではない。

四、中核プロンプトの解説：月曜朝 7 時の「デザインパートナー開拓」ルーティン

Founder Mode のプリセットパッケージには、毎週月曜の朝 7:00 に自動実行される「デザインパートナーおよびリード探索」プロンプトが用意されている。これは、自身の Agent やワークフローにそのまま応用できる標準テンプレートである。

各自の事業に合わせてカスタマイズしやすいよう、その要点を忠実に日本語訳し、設定されている主要な制約事項を詳細に解説する：

毎週月曜日の私の現地時間午前 7:00 に、私の ICP（理想的な顧客プロファイル）に合致し、かつ今週中に [具体的な課題・ペイン] について公に議論している、または [特定の職種の求人] を出している企業を探索してください。

初回の実行前に、まず私に質問して私の ICP の詳細（業界、チーム規模、成長フェーズ、対象地域）、実際に財布の紐を握る経済的意思決定者（Economic Buyer）、日々の課題に直面している実際の利用者、どのような業務シグナルを有効とするか、絶対にアプローチしてはならないブラックリスト企業を確認してください。これらの回答を保存・定着させ、以降のすべてのタスクで厳格に遵守してください。

スキャンで合致した各対象について：
1. 合致度順に並べ替え、そのシグナルの情報源となる具体的なウェブリンクを添えて理由を説明してください。
2. 私の商談追跡表（Deal Tracker）、仕事用メール、カレンダーと照合し、既存顧客や現在進行中の商談相手を新規リードとして提示することは厳禁とします。
3. 私の過去の人脈ネットワークから活用できる友好的なアプローチ経路（Warm Path）を探し出し、その仲介者の名前を直接明記してください。
4. 私のトーン＆マナーで、簡潔な初回アプローチ用のダイレクトメッセージまたはメールの下書きを作成してください。冒頭の 1 文目は相手が抱える具体的なシグナルやペインに直接切り込むものとし、最初から自社製品を売り込むことは厳禁とします。

すべてのスクリーニング結果を厳格に 3 つのカテゴリに分類し、判定理由を 1 文で説明してください：
- KEEP（プロファイル合致、シグナル明確、アプローチ経路あり、下書きを作成）
- HOLD（プロファイルには合致するが重要な「なぜ今なのか」というタイミングのシグナルが不足、保留して経過観察）
- DQ（除外：すでに商談パイプライン内、既存顧客、または連絡不可リストに該当）
すでにリサーチ済みの企業リストを記録し、毎回新規の増分リードのみを報告してください。今週条件に合う新規リードがない場合は、1 行の簡潔な報告のみを送信してください。

生成されたメールの下書きはすべて Gmail の Drafts（下書きトレイ）に保存してください。送信（send）API を直接呼び出すことは厳禁とし、連絡先を自動化シーケンスに勝手に追加することや、私の明確な許可なく CRM データを勝手に変更することは厳禁とします。

このプロンプトに組み込まれた 5 つのエンジニアリング視点の防衛線：

1. 自己適応型のコールドスタートと記憶の永続化： 初回の実行前に、まず私に質問して...これらの回答を保存・定着させ。これによりプロンプトが固定のハードコードにならず、起動時の対話を通じて創業者の頭の中にある非構造化されたビジネス知見を引き出し、長期的な基準線を確立させることができる。
2. 行動シグナルに基づくアプローチ理由の特定： やみくもなアウトリーチでは役職名だけで判断しがちである。このプロンプトでは、アプローチの根拠を企業が公開の場で発信している課題や具体的な求人シグナルに厳密に限定している。役職そのものではなく、タイミングシグナルこそがメッセージを読まれる価値あるものにする。
3. マルチソースのクロス重複排除によるバッティング事故の防止： 私の商談追跡表、仕事用メール、カレンダーと照合し。創業期のスタートアップにとって最も避けたい事態は、自社の自動化ツールが現在重要な商談を行っているキーパーソンに陳腐なコールドメールを誤送信してしまうことである。複数チャネルによるデータの照合は、Agent を実務に投入するための必須前提条件となる。
4. KEEP / HOLD / DQ による厳格な 3 分岐トリアージ： Agent がユーザーに忖度して関連しそうなリードをすべて ToDo に詰め込むのを防ぐ。「今動くべき理由」が明確でないものは HOLD へ回し、すでに接触履歴のあるものは即座に DQ とする。
5. 人間の承認（Human-in-the-Loop）が必要なアクションの明文化： プロンプト末尾の自動送信の厳禁、自動シーケンスへの勝手な追加禁止、無許可での CRM 変更禁止が、運用の安全なレッドラインを構成している。Bot はリサーチ、下書き、ステージングのみを担当し、外部への送信、マージ前のコードレビュー、投資家向けレターの下書き、CRM レコードの書き込み、請求書の最終確認はすべて創業者自らが管理しなければならない。

💡 ツール移行のアドバイス： 原文は海外で広く使われている Gmail、Granola、GitHub、CSV スプレッドシートを前提としている。自社の業務環境に導入する際は、実際の連携機能に応じて代替を試みることができる：

• メールとカレンダー -> Feishu、DingTalk、または WeCom（企業微信）；
• Deal Tracker -> Notion データベース、Feishu 多次元テーブル、またはローカルの Excel；
• 通話議事録ツール Granola -> Feishu Miaoji、Tongyi Tingwu、またはローカルの Whisper 音声文字起こしパイプライン；
• コードリポジトリ GitHub -> GitLab、Gitee、または社内コードプラットフォーム。 本構成における役割分担、シグナル駆動、下書きのステージング、および人間による承認を取り入れつつ、選択したプラットフォームが対応する連携とアクションをサポートしているかを確認するとよい。

五、創業者がセールスを行うための 5 つの生存法則

このワークフローの最後に、原著者は最前線のセールスからスタートアップの経営までを経験した実感に基づき、極めて質素ながらも決定的な 5 つの経験則を提示している。これらのアドバイスはツールそのものを超え、初期セールスの成否を直接左右する：

1. 決して自動送信しない（Never auto-send）

Bot の責務はリサーチ、下書き、そしてステージング（research, draft, and stage）である。承認なしにコンテンツを送信・公開することは決してなく、コードを自動でマージすることも決してない。CRM レコードの書き込みや請求書の最終確認も同様に承認が必要である。顧客が目にするすべてのメッセージは、創業者が事前に自ら目を通さなければならない。

2. 温かみのある紹介は洗練されたコールドメールに勝る（Warm intro over a cold template）

Social Bot が関連するエンゲージメントの経路を発見した際、Outreach Bot はそれを起点としてアプローチを展開する。冷え切った売り込みテンプレートをそのまま当てはめるのではなく、実際のやり取りのコンテキストに沿って切り込む。

3. 行動シグナルは役職名に勝る（Signal beats title）

アプローチを行う理由は、そのアカウントが現在何をしているのか、どのような課題に直面している可能性があるのかであるべきであり、誰かがバイスプレジデント（VP）の肩書を持っているからではない。実際のビジネス上の行動シグナルこそが、メッセージを読まれる価値あるものにする鍵である。

4. 2 回修正した誤りは、即座にシステムルールとして定着させる（Feedback I give twice becomes a saved instruction）

Agent が起草した内容をレビューする際、同じ箇所（専門用語の言い回し、避けるべき表現、あるいは競合の位置づけなど）を 2 回続けて修正していることに気づいたら、それはシステムの基盤ルールにその基準が欠けていることを意味する。その際は下書きを直すだけでなく、チーフオブスタッフ Bot にその修正をシステムの Skill または Settings のルールとして保存させ、同じ誤りを繰り返さないようにする。

5. 創業者が自ら抱え続けるべきものを理解する（Know what to keep）

初期の顧客開拓（Discovery）、価格設定と条件交渉、そして最初のデザインパートナーが「Yes」と決断する命運を分ける商談は、創業者が自ら行わなければならず、創業者にしかできない。

これらの困難な対面の対話こそが、「自社製品が誰にどのような価値をもたらし、どのように売るべきか」を創業者が言語化するための唯一の一次情報源となる。

最初のフルタイム営業担当者（First Sales Hire）を採用すべきベストなタイミングはいつか？ それは営業活動を負担に感じたときではなく、Sell Bot と Insights Bot によって磨き上げられたセールスプレイブックが極めて成熟し、高い再現性を持ち、創業者自身のカレンダーが商談で埋め尽くされて会社全体の案件推進における唯一の物理的ボトルネックになったときである——その瞬間こそが、専任のセールスチームにステアリングを委ねるべき時である。

原文で提供されているテンプレートへのリンク

• Founder Mode setup pack

上記は原文で提供されているリンクである。インストール後は自身のアカウント、データ、ツールとの連携が必要となる。今回の検証ではインストールやログイン後のテンプレート状態の確認は実施していない。