営業の仕事をBot 10体に割る — x.aiのGrok Bot for GTMガイドを読む

x.ai が Grok Bot for GTM のガイドを公開している。書いたのは SpaceXAI で法人営業を率いている人で、社内 Notion に置いていた自分用のドキュメントをそのまま外に出した、という体裁になっている。2026年8月16日付。

読んで面白かったのは、個々のプロンプトではなく役割の割り方だった。ひとりの営業担当者が、10体の Bot に仕事を分けている。しかも戦略顧客については「1アカウントにつき1体」まで細かく割る。普通に考えれば管理コストのほうが高くつきそうなこの構成が、Grok Bot ではなぜ成立するのか。そこがこのガイドのいちばんの読みどころだった。

そもそも Grok Bot とは何か

まず前提から。Grok Bot は x.ai の新しいプロダクトで、チャットアシスタントではなく「AIの同僚」を名乗っている。公式ドキュメントが挙げる特徴のうち、他のAIツールと決定的に違うのは次の点だ。

Bot は自分のコンピュータを持つ。 各 Bot はブラウザ・ファイルシステム・ターミナルを備えた常時稼働のクラウドVM上で動く。API がきれいに用意されていないアプリやウェブサイトも、人間と同じように画面を操作して使う。だから成果物が「チャット欄の下書き」ではなく、実際のツールの中に残る。ノートPCを閉じていても動き続ける。

Bot は名前と職務を持ち、記憶が積み上がる。 タスクごとに真っさらな環境へ戻るのではなく、メモリ・ファイル・ブラウザのログインセッション・好みが持続する。

そして、このガイドを読み解く鍵になるのが次の一点だ。

All of your Bots use the same persistent cloud computer. They share files, browser sessions, and app logins, which makes handoffs possible without repeating setup.

コンピュータは Bot ごとではなく、アカウントごとに1台。 10体の Bot が同じマシンを共有し、ファイルもブラウザのログインも共有する。各 Bot は同じマシン上に自分の画面を持つので、並行して作業はできる。ただしセキュリティ境界は分かれていない。ドキュメントは「このコンピュータに置いたログインやファイルは、自分の全 Bot から使えるものとして扱え」と明言している。

ここが分かると、10体構成の理由が見えてくる。Salesforce に一度ログインすれば、営業準備Botもフォーキャス トBotも顧客担当Botも、そのセッションをそのまま使える。Bot を増やすコストが、ツール接続のやり直しにならない。 だから役割を細かく割れる。

ついでに: サインインが Cursor アカウントである理由

セットアップ手順を読むと、Grok Bot へのログインが「Sign In with Cursor」になっていて面食らう。対象プランも SuperGrok Plus / SuperGrok Heavy と並んで Cursor Pro+ / Cursor Ultra / Cursor Teams が挙がっている。

これは、イーロン・マスク側の陣営が Cursor を買収したためだ。xAI は2026年2月に SpaceX と統合しており（ガイドの著者が所属を「SpaceXAI」と書いているのはこのため）、その SpaceX が Cursor の開発元 Anysphere を約600億ドルで買収することで合意している。クロージングは2026年第3四半期の予定とされる。アカウント基盤の統合はすでに製品側に出てきている、というわけだ。

Quartz: SpaceX agrees to buy Cursor parent Anysphere for $60 billion / Techzine: SpaceX acquires Cursor for $60 billion

10体のBotは何を担当しているか

ガイドが挙げる構成をそのまま並べる。

一覧にすると、ある傾向が見える。10体のうち大半は「顧客に何かを送る」担当ではない。 送る前の準備、記録、分析、そして自分自身の訓練にあたる。著者の言葉を借りれば、以前は日中ずっと商談に出ていて、夜に何時間もかけて事務作業に追いついていた。そこを Bot に渡した結果、顧客の前にいる時間が増えた、という構図だ。

以下、いくつか役割を補足する。

Chief of Staff — 差配する役

いちばん頻繁に使う Bot で、サイドバーにピン留めしている。会議準備・受信箱・商談後の下書きを自分で持ちつつ、他の Bot を呼び出す。たとえば資料が要る場面では Slides Bot を呼ぶ。新しい Bot を立ち上げさせることもできるし、Bot 群の整理もさせる。

ガイドの後半には、この Bot の使い方としてこんな一文がある。自分の Bot とタスクを全部見せて、さらに自動化・並列化・整理できるところがないか棚卸しさせる。不要になったルーティンの掃除も頼む。Bot の管理者を Bot にやらせている。

Customer Expert — 1社に1体

10体構成のなかで、いちばん思い切っているのがこれだ。戦略顧客ごとに専任 Bot を置く（有力見込み客にも使える）。その顧客の Slack チャンネルを見張り、商談・メール・スレッドを消化し、商談中に出た機能要望を拾い、サポートチケットの状況を知らせ、その顧客に関係する自社の新機能を見つけてくる。

さらに週に一度、その顧客に関するメディアの棚卸しを回す。ガイド中で唯一プロンプト全文が載っているのがこれなので、引用する。

Weekly media rundown for [account]. Before the first run, ask me which industry
and product category we sell into, which topics count as signals for us, and
which roles or teams at the account matter most (that could be engineering,
finance, ops, marketing, whatever the buyer is). Save the answers and use them
on every run.

Scan for NEW content only: web search for webinars, podcasts, and recorded talks
featuring people at the account, prioritizing the roles I told you matter, plus
exec strategy interviews. Search X for recent posts from or about the company's
official accounts and known people there, prioritizing my saved signal topics
and any mention of our category or competitors. Keep a state file of everything
already covered and compare against it so you only report genuinely new items.

For each new item, actually consume the content. Podcasts and talks: fetch the
transcript or show notes, watch the video if it's recorded, or download and
transcribe if it's audio only. Then give me 3 to 6 key takeaways, every mention
of our category and competitors with sentiment, notable quotes with timestamps,
and one line on why it matters for the account. For X posts: author, date, the
text, a link, and why it matters. Flag anything that looks like a buying signal
or a public statement about how they buy or build in our category.

Send one weekly roundup. If nothing new, send a single line saying so. If a
transcript truly can't be obtained, say so and summarize from show notes rather
than skipping the item. Update the state file after every run.

このプロンプトは、指示の書き方の見本として読める価値がある。効いている仕掛けが4つある。

第一に、初回に質問させている。業界・製品カテゴリ、何がシグナルになるか、先方のどの職種が重要か。答えを保存させ、以後の全実行で使わせる。初期設定を人間が書き下すのではなく、Bot に聞かせる形にしている。

第二に、状態ファイルを持たせている。既出のものを記録し、毎回突き合わせる。だから週次で回しても同じ話が繰り返されない。定期実行の設計で最初に効くのがここだ。

第三に、「実際に中身を消費しろ」と念を押している。文字起こしを取れ、録画があれば見ろ、音声しかなければ落として書き起こせ。要約の要約で済ませない。

第四に、取れなかったときの振る舞いを決めている。文字起こしがどうしても取れないなら、黙って飛ばすのではなく「取れなかった」と言ったうえでショーノートから要約しろ。欠落を沈黙で処理させない。

10x Engineer — 商談中に技術を聞ける相手

コードベースに接続した Bot に「10x engineer」と名前を付けている。顧客が商談中に技術的な質問をしてきたとき、この Bot に聞くと顧客に向けてそのまま言える答えが返ってくる。エンジニアを捕まえたり、Slack や Notion を掘ったりしなくて済む。リポジトリへのアクセスがなければ、Glean のような社内ナレッジツールを情報源にする。

Slides — 商談中にスライドを作り替える

Figma で顧客向け資料を持たせる。ブランドシステムとマスターデッキを Bot が維持し、顧客ごとにコピーを作って中身を差し替える。他言語への翻訳もやらせる。

著者が「お気に入りのスキル」と呼んでいるのは、商談中の使い方だ。議事録の録音を終了5〜10分前に止めて、その場でスライド生成を走らせる。 直前のヒアリングで顧客が話した内容から作ったスライドで商談を締められる。あるいはそれを次回のフォローアップや冒頭資料に回す。

Skill と Routine を分ける

Grok Bot には、繰り返し作業を固定するための部品が2つある。

• Skill — やり方を書いた再利用可能な指示。全 Bot から使える
• Routine — その仕事を「いつ」走らせるか。スケジュール実行、または対応していればイベント起点

ドキュメントの推奨順序が実務的だ。まず単発のタスクとしてやる。安定させる。やり方を Skill として保存する。それから初めて自動化する。 いきなりルーティン化しない。

Skill の作り方には、教えて覚えさせる経路もある。Bot にコンピュータの画面を見せながら作業を1回やってみせると、それを Skill として保存する。ガイドの著者は「X で関係者をリサーチするやり方を見せた」と書いている。記録は画面操作のみで、マイク音声は録らない。上限は10分。

使う側の作法

ガイド末尾のコツも、そのまま運用のチェックリストになる。

• 新入社員としてオンボードする。 最初の1回は一緒にやり、記録させて Skill に変える
• 自分の文章を食わせる。 送信済みメールをスキャンさせて文体プロファイルを作らせてから書かせる。自信のあるアウトリーチを数本見せる
• フィードバックを返し、気に入らない出力にはルールを作る。 著者は「anti-slop skill」を作って育てていて、Bot を修正するたびにその Skill に書き足している
• 並列で走らせる。 複数のクラウドエージェントを立てさせる。それ自体を Skill にする
• グループチャットに複数の Bot を入れる。 Bot 同士が仕事を渡し合う

安全側の設計もドキュメントに繰り返し出てくる。実行より前に準備を自動化する。まず下書き・照合・推奨をさせる。送信・購入・削除・公開・本番変更には承認を要求する。データが無いとき、古いときの扱いを決めておく。 商談メモの自動更新まで任せる構成である以上、この線引きは飾りではない。

実際に動かすときの前提条件

最後に、手を動かして確認した前提を書いておく。ガイドには書かれていないが、これを知らないと着手できない。

• デスクトップアプリが要る。 Grok Bot はブラウザ版ではなく、macOS / Windows / Linux のアプリとして配布されている。モバイル（iOS 18以降 / Android 9以降）は同じ Bot・ルーティン・共有クラウドPCに繋がるが、ルーティンのスケジュール編集や実行履歴の確認、教えて覚えさせる操作はデスクトップ側でしかできない
• 対象プランが要る。 SuperGrok Plus、SuperGrok Heavy、Cursor Pro+、Cursor Ultra、Cursor Teams の Standard か Premium。ログインは Cursor アカウント
• 上限がある。 1アカウントあたり Bot とグループチャットは合計50まで。1体の Bot が持てるルーティンは50まで、各ルーティンの実行履歴は直近20件まで
• Bot の作成手順そのものは軽い。 サイドバーの New（Ctrl/Cmd+N）から Create new agent を選ぶと「New Agent」ができるので、Bot actions → Edit Profile で名前・肩書き・説明を入れる。ワークフロービルダーのようなものは無い

ドキュメントは、説明文の書き方についてこう区別している。会話にはそのときのタスクを書く。説明文には、ずっと真であってほしいルールを書く。 例として挙がっているのが「承認なしに外部へメッセージを送らない」で、これは説明文に置くもの。「この12社のフォローアップを書いて」は会話に置くもの。役割を10体に割るとき、この分離が効いてくる。

読み終えてみると、このガイドが実際に配っているのはプロンプト集ではない。仕事を「誰に渡すか」で割る単位の見本だった。1社1体の担当を置けるのは、Bot を増やしても接続コストが増えないからで、それは全 Bot が1台のマシンを共有しているという設計から来ている。役割分担の粒度は、道具の構造で決まる。