ゲーム会社への転換と
ボット群による開発Galaxy Day 2の実演を読む

チームの紹介と昨日の振り返り

Mattは自分をSpaceXの開発者体験担当、Roshanを製品担当と紹介する。Laurenは「Potatoとしても知られている」と名乗り、SpaceX AIでGrok Botに携わっていると話す。

昨日は口座の準備、案出し、方向性の合意に使った。体験型のポップアップ事業を選び、その構想の確認、環境設定、試作とデモに時間を費やしたと振り返る。

ポップアップ案を取り下げた理由

Laurenは、ポップアップは手に余ったと話す。昨日のゲストからサンフランシスコの規制や許認可の難しさを聞き、その作業を配信で見せても面白くならないと感じたという。

Mattは、夜のあいだにこの案をボットに調べさせ、2日で完全にやり切れるものではないという結果が返ってきたと説明する。Laurenは「ボットが転換を勧めた」とまとめた。

• 視聴者が一緒に使える何かを作るほうが楽しいという判断も、転換の理由に挙げている。

新しい案はテンプレートを使うゲーム

Roshanは、視聴者と会場の参加者が自分のGrok Botテンプレートを作り、それで遊べる仕組みを作りたいと話す。最も楽しい形としてゲーム会社を選び、最初のゲームで全員が自分のボットと一緒に遊ぶことを目標にした。

午前中の20〜30分でホワイトボードを描き、LaurenがMVPの計画を説明し、その後は講演の合間にビルドを続ける進行を示した。

Grok Botテンプレートとは何か

Laurenは、テンプレートは自分が作ったボットを他の人と共有する仕組みだと説明する。スキル、ルーチン、そして機密を漏らさないよう一般化した一部の記憶を含み、アプリ内のマーケットプレイスに例が並ぶ。

PM業務に強いボットを作り込んだ人がそれを共有すれば、別の人がその成果を使えるという例を挙げた。ボットを作ってテンプレートとして保存すれば、今日から作れる。

テンプレートを対戦キャラクターに変える

Roshanはホワイトボードに「Grok Bot Template」「Character in a game」「Compete head to head」の流れを描く。テンプレートをキャラクターに変え、他の人が作ったキャラクターと対戦させる。

ステータスは好きなゲームにならい、charisma、dexterity、intelligenceの3種類にする。さらに各ボットに1つのアビリティを持たせ、どれかのステータスを使う設計にした。Laurenは「charisma ability」では技術的すぎるので格好いい名前を付けたいと言い、Roshanは自分のボットDr. Eggbotに風味のあるスキル名を付ける例を挙げた。

チームは、取り込んだ主役のボットに追加のボットを組み合わせた3体で始める。Laurenの例では、Dr. Eggbot、チャットボット、名前の長いアウトバウンド営業ボットの3体だった。

ステータスは決定的に割り当てる

同じテンプレートからは毎回同じステータスが出るように、決定的な変換にする。合計100ポイントを3つに分け、ボットの説明文をLLMに読ませて配分を決める案を出した。人をまとめる役割ならcharismaが高く、多くのサービスに接続する役割ならdexterityが高い、という具合だ。

最小値の議論では、0はおかしいので10にする案から、結局1まで下げて「1、1、98」もあり得ることにした。

レアリティで合計値を変える

Roshanは、DiabloのようなアクションRPGのアイテムにあるレアリティを取り入れたいと話す。基本の合計を100とし、レアリティの修正で合計値を増やす。ホワイトボードにはbase 100、rare 125、ultra 150、legendary 200と書かれた。

正確な数値は後で決めるとし、この時点では割合の目安にとどめている。

収益化はpay to winを避ける

Laurenは「ゲームスタジオに転換するなら収益も必要」として、pay to winにならない稼ぎ方を尋ねた。Roshanは、翌日また来させる仕組みや回数制限のような課金を嫌い、強さではなく楽しい追加要素に払ってもらう方針を示した。

案として、コスメティック、Grok Imagine APIで作る固有のビジュアルアイテム、別のアリーナへのアクセスを挙げた。Mattはスポーツのスタジアム広告のように、ゲームに影響しない広告枠と、対戦の様子を後から見られるリプレイの共有を提案した。

成長を優先し、収益化は製品の形が見えてから重ねるという順序で合意した。

• ホワイトボードの「monetization」欄には、cosmetics and unique items、stadium adsが書かれている。

対戦の中核はステータスの突き合わせ

Roshanは、charismaのアビリティを持つボットとintelligenceのアビリティを持つボットが向き合い、ステータスを突き合わせて勝負する単純な形を描いた。アビリティの内容はLLMで生成し、作成時にロールする特別なボーナスで毎回の対戦に変化を付ける。

自分のチームで並び順を決め、軽いマッチングで相手のチームと組み合わせ、結果はリプレイで見返す。この単純な版から、静的なアップグレード、アビリティの変更、性質の違うアリーナへ広げていく構想だ。

事業として残る仕事

Mattは、製品がゲームでも、会社を作る他の要素は変わらないと整理する。配信そのものが配信経路になるほか、SEOとAEO、ランディングページ、広告を挙げ、次の休憩後に来るゲストに手伝ってもらう可能性にも触れた。

顧客対応は、メールや電話に加えて、Xのチャットを取り込んで視聴者の声を直接聞く案が出た。カスタマーサポートや運営全般に成長系のボットを充てる。ホワイトボードの「product needs」には、ads、marketing、more team members（interns?）、seed funding?、figure out distribution (hey chat)、call usと並んだ。

MVPの流れを4段階に絞る

Roshanは下段に「Grok Bot Template」「Draft your team」「Set your lineup」「Compete!」の4つを描き直した。対戦を釣り合わせ、また来たくなる動機を作るアルゴリズムの作業が残る。

小さく始めて発展の余地を残す設計だと説明し、Roshanは自分のプラグインpstackを使った開発ワークフローも今回の題材で見せたいと話した。アプリや実店舗の周辺業務にも同じ手順が当てはまるという見方だ。

Laurenの計画書と講演への切り替え

Laurenは、議論の最中にpstackの計画プレイブックで大まかな計画を書いていた。pstackは自分が作った工学用スキル集のプラグインで、検証のチェックリストや型と関数シグネチャの擬似コードを含む長い計画を出す。画面にはGitHub上のdocs/plans/01-mvp.md「Cupcake v1 program plan」が映った。

説明の途中でMattが、営業エンジニア向けの最初の講演がメインステージで始まると告げ、配信は講演へ切り替わった。

2日目の予定と講演の構成

AmritaはCursorのフィールドエンジニアと名乗り、2日目は営業エンジニア、営業、SDR、カスタマーサポートの4つのワークショップに加えて、Matt、Lauren、Roshanの会社づくりを追う日だと説明する。

今回の講演では、普段使っている3体のボットを見せる。2体はデモ用の環境、1体は実際に顧客向けの事例スライドを作るために毎日使っているものだ。会場のテーブルにはQRコード付きのコースターがあり、テンプレートを読み込める。

チャットボットから同僚のチームへ

前日にも使った成熟度のスライドで、単発の依頼から、タスクを共同でこなすボットのチームへ移るという考えを説明する。Grok Botは「完成した仕事」を返すもので、休暇中や就寝中も動き、電話から同僚のように話しかけられる。

Android、iOS、Macのアプリを勧め、画面の左にボットが並ぶiMessageに似た構成、以前の指摘を覚える長期の記憶を紹介した。

ボット専用のコンピューターと管理者の制御

ボットは自分のコンピューターを持つため、利用者がすべてのサービスを接続する必要がない。前日のGoogleフォーム作成や、参加者から聞いたMongoDBにログインしてデータベースを点検する例を挙げた。

利用者はボットのコンピューターを引き取って操作でき、企業の管理者は特定のサイトへのアクセスやダウンロードを止められる。

自動化、ルーチン、共有

Amritaは毎朝、メールからAIのニュースレターとポッドキャストを拾ってSlackに要約を送るルーチンを使っている。夜間に見逃したSlackの朝のまとめも一般的な使い方だ。分散したチームでは、他の人や道具を待たずに済むと話す。

コースターのQRコードはマーケットプレイスの公開ボットで、社内では営業チームのボットや、エンジニアリングチームから共有されたボットを使う。ボットを共有すると、営業ボット同士で参照する資料が食い違わないという利点も挙げた。

なぜGrok Botか

使い始めが簡単で、ボットのほうから何に使うかを聞いてくる。ボットが別のボットを立ち上げられる点を今日の実演で見せると予告した。

クラウドで常時動くため、承認待ちで止まらずに仕事を終える。戻ってきたときには完成した仕事を手直しする状態になっている、というのが強調点だった。

営業エンジニアの4つの用途

スライドの4つは、技術的な質問に答える「Engineer」、競合製品を触って比較する「Competitive Intel」、商談中に資料を更新する「Echo」、顧客の利用状況を見る「Customer Expert」だ。Engineerの詳細は後のDavidのカスタマーサポート講演に、Echoの実演は後のKristaとMarkの講演に譲った。

SherlockはGrok Botのリポジトリを読める技術担当で、IPを漏らさず、技術に詳しくない相手にも伝わる言い方に調整してある。Serena Williamsは、競合を研究する選手にちなんで名付けた競合調査担当で、競合製品を自分のコンピューターで使い、自社との違いを報告する。

Mimiに事例スライドを作らせる

Mimiは顧客の証拠となるスライドの調査担当で、SpaceXの事例を集めたGoogleスライドにアクセスできる。事例は問題、解決、効果、引用の型で統一されており、直前にはJellyfishのコードレビュー事例を作っていた。

実演では、Salesforceが「レガシーコードのカバレッジ作業を85%削減した」と書いたブログ記事のURLを渡し、同じ型で1枚作るよう頼んだ。Mimiは自分のコンピューターでスライドを編集し、ロゴをブランドページから取り、スクリーンショットを返す。

架空の航空会社FlyLoとSherlock

別のアカウントに切り替え、SpaceXがデモ用に作った予約サイトFlyLoを紹介する。フロントエンド、バックエンド、ウェブアプリ、乗務員用の社内アプリがあり、Sherlockにはその説明とリポジトリへのアクセスを与えてある。

前日に「同じ席や最後の1席を同時に予約したらどうなるか」を聞いたところ、Sherlockは保護がPostgresにあること、決済に進むと最後の席を10分間確保することを調べ、顧客に伝える文面まで用意していた。調査にはCursorのクラウドエージェントを使う。

• 回答をそのままメールやSlackで送らせる場合は、送信に承認を付けられると説明した。

Serenaに競合の予約画面を触らせる

Serenaに「FlyLoと比べる価値のある競合製品は」と聞くと、まずSherlockへ現在の予約機能の基準を尋ねるメッセージを送った。Amritaは候補からSouthwestとSpiritを選び、SerenaはSouthwestの予約フローを自分のコンピューターで進め始めた。

途中で「AI旅行エージェントの機能があるか」も調べるよう指示を足した。Serenaは元の作業を止めず、追加の質問を取り込んで進めた。同時にSherlock側では、バックエンドとフロントエンドのリポジトリでクラウドエージェントが起動していた。

2体をグループチャットに入れる

Mimiはログインの問題で止まっており、依頼を送り直した。SherlockとSerenaは、やり取りを1か所で見るためグループチャットに入れる。最初は別の相手が追加されたため、作り直した。

「競合との差分のうち、低い労力で実装できる決定的な違いは何か」と投げると、両者がそれぞれの文脈を持ち寄って議論を始めた。結果はPRや製品文書にして技術チームへ渡せる。

プラグインがなくても止まらない

マーケットプレイスにはGoogle DocsやAtlassianなどのプラグインがある。Microsoft OneNoteのようにMCPやプラグインがない道具は、ボットが自分のコンピューターでログインして使う。

Power BIやMongoDBの例を挙げ、MCPやAPIがないことは障害にならないと繰り返した。

画面録画で作業を教える

非公開のスキルとして、前日にスライドのアニメーションを教えたものがある。実演では、Sherlockの画面を引き取って「Teach a task」を始め、GoogleでExpediaの技術ブログを開き、AI関連の記事を探して読む手順を録画した。

録画後に音声で「競合のAI関連の記事を探し、自社のAI機能を最新に保ちたい」と補足すると、Sherlockはそれをスキルとして学習した。スキルはどのボットで作っても、全てのボットが使える。

グループチャットの結論

Sherlockは、コード側から見て最も労力が低く効果が高いのは「予約管理」で、バックエンドにはPNRとメールでの取得、セッション、キャンセルがあるのに/tripsはスタブのままだと指摘した。次に、フロントエンドが配線済みなのに一度も呼んでいない「柔軟な日付カレンダー」を挙げた。

Serenaは、往復と手荷物は競合では大きいが低労力ではないと返し、SouthwestとSpiritではどちらが不便に感じたかをSherlockに聞き返した。ボット同士が互いをタグ付けして質問する様子が見えた。

ボットに必要なボットを作らせる

AmritaはSherlockに、Serenaとの競合分析と営業エンジニアリングに役立つボットを考えて立ち上げるよう頼んだ。Chief of Staffのボットに頼むと受信箱管理やスケジューラーが生まれやすいが、今回は技術担当がどう選ぶかを見たかったという。

Grok Botを使い始めた営業エンジニアには、自分の手順に合うボットをGrok Bot自身に提案させる使い方を勧めた。

Mimiのスライドが完成する

「今日は早い時間に障害があった」と断りつつMimiを確認すると、Salesforceのスライドが2枚できていた。ロゴは小さいが正しいものを取り、問題、解決、効果、引用の型に沿っていた。続けてGrabの事例記事を渡し、Q&Aまでにもう1枚作るよう頼んだ。

同じ紫色のAI風スライドにならないよう、型と記憶と文脈を渡すことを勧めた。複数の事例をまとめて頼み、商談相手に合わせて不要なスライドを隠す使い方も紹介した。

Sherlockが作った3体

Battlecard Blairは、Serenaの実地調査とSherlockのコード知識を組み合わせて、短い比較資料を作る担当だ。Demo Drakeは顧客の課題をFlyLoの実際の流れに対応させるデモ台本と会話の台本を作り、主張の根拠を必ずSherlockに求める設定になっていた。

AI Radarは競合の技術ブログからAI関連の記事を探す担当で、先ほど教えたスキルを使う設定だった。AmritaはSerenaと似すぎているかもしれないと評した。Grokのモデルはできないことをできないとはっきり言う点も利点に挙げた。

質疑：bot検知、MCPとコンピューター操作

Facebookのようなサイトでボットが遮断されないかという質問には、サイトによっては通過できないと答えた。企業では管理者が業務に不要なサイトを止めることを勧めている。

コンピューター操作が広がるとMCPは不要になるかという質問には、MCPは「エージェント向けのAPI」で今は速く、許可と禁止の管理もしやすいと答えた。コンピューター操作は今後速くなると見ている。

質疑：本番環境への変更と承認設定

Xからの「内部システムにアクセスできるなら本番環境を変えない保証は」という質問には、Grok Bot Enterpriseの保護機能とスキルによる規則で対処していると答えた。

設定の「Auto review」を有効にすると、本番へのデプロイや内部システムの利用といった条件ごとに「自動的に許可」ではなく「先に確認」を選べる。

質疑：Linuxで動かない道具とトークン

MCPがなく、Linuxで動かない道具については「今はやり方がない」と率直に答えた。ボットのVMはLinuxで、Linuxで動く道具しか使えない。

トークンは会話と、ボットのコンピューター操作の両方で消費される。数週間前に出たGrok 4.6が安価で性能が高く、Grok Botの基盤だと理解していると話した。自分の講演資料一式は20〜30ドル程度で、手作業なら4〜5時間かかったという。返答の冗長さを減らすよう伝えると消費も減るが、コンピューター操作の量は調整できないと答えた。

Laurenの画面が落ち、Mattが運転する

Laurenは「現在オフライン」で、Mattの画面に切り替える。Laurenが横から作り方を説明し、Mattが実際に操作する「後部座席の運転手」の形を取ることにした。

MattはLaurenと同じ構成で、ボットを作るDr. Eggbotと、ランディングページを担当する創業エンジニアボットを持っている。

計画書を共有してランディングページを設計させる

Laurenがボットの文脈で書いたMVP計画のドキュメントはリポジトリに入っているため、Mattは自分のボットにそのドキュメントを指す形で情報を共有した。「最初の目標はランディングページ。モノレポなので計画を読み、プロジェクト計画スキルでランダーの構成を提案して」と頼んだ。

プロジェクト計画スキルには、新規プロジェクトで使う既製の足場（T3やTanStack、React NativeならExpo、Next、単純ならVite）、UIとスタイルの指針が書いてある。加えて、細部を磨く「make interfaces feel better」というスキルを使った。作者はX上の誰かで名前を思い出せず、間違えたくないので伏せている。

• OGメタタグとサイトのメタ情報は毎回入れる。検索結果やSNS投稿での見え方が変わるため。
• Grok Botは「足す前に引く」原則で待機リストを外し、v1に絞る修正を返した。

Grok BotとCursorの役割分担

Mattは、Grok Botは軽い作業環境、Cursorはコーディング用の環境と整理する。会話と行き来はGrok Bot、実際の実装はCursorが担当し、どちらもクラウドで動くため手元のマシンでは何も起きていない。

用語の確認では、Grok Botで「/potato-mode」と打つか、「use potato mode」と書けば、pstackプラグインを持つボットは意味を理解すると説明された。

クリエイティブディレクターと資産の試作場

見た目の検討には、UIを調整できるオープンソースのDialKit（音声からの推定表記）を使い、スライダーでフラットなSVGの部品を動かす試作場を作った。Mattはゲームを作ったことがなく、Phaserを知っている程度なので、ボットに調べさせて技術を逆算した。

視覚の参考にはLaurenが勧めたSuper Auto Petsを挙げ、軽くて楽しい図柄を目指す。

音声でエンジニアボットの仕様を伝える

Laurenは、主となるボット（自分の場合はChief of StaffのSteve）が文脈を持っているなら、そこからDr. Eggbotに頼むのがよいと助言した。Mattは音声で「Dr. Eggbotにエンジニアボットを作らせて。pstackとpotato modeでクラウドエージェントを起動し、監督して成果を確認する役割。最初の段階は素早い軽量な試作に絞る。ログインはまだ要らない。ゲームが楽しいかも分かっていないから」と伝えた。

最後に「試作専用にしすぎず、後の本格的な作業にも耐える耐久性を持たせて」と付け加え、Laurenの好みの型として「作業前に自分の言葉で言い直して」と締めた。

スライダーで見た目と定数を触る

Roshanの画面で資産の試作場をローカルで動かした。抽象的な図形がボットとして並び、色に意味を持たせる案が出た。Laurenは、この部分と試作を同時に作ると複雑になるので、まず基本の試作を全員で触れる状態にすべきだと述べた。

Roshanは、CHAとDEXの間のじゃんけんのような関係と22%のボーナスのようなゲーム内定数を、この試作場で実時間に変えて再生できると、エージェントを待たずに済むと話した。「楽しくなるまでの時間を縮める」ための道具という位置づけだ。

プレビューデプロイ、Slack絵文字、Notionの更新

Mattの画面では、創業エンジニアボットがプレビューデプロイに取り組み、Dr. Eggbotは先ほどの指示を自分の言葉で言い直している途中だった。成長担当のエンジニアボットも別の作業をしている。

余談として、朝のうちにGrok BotにBufoのミーム絵文字を配布サイトから取得させ、コンピューター操作でSlackに約1,200個登録させたと話した。知識ベース担当のボットは、Notionの会社文書にゲームスタジオへの転換と製品計画のコアループを書き込んだ。次はランディングページ、SEO、A/Bテスト、広告基盤へ進む予定だ。

機材の問題で中断

ホワイトボードの図もNotionに入れ、後で作るボットが事業を学ぶ参照先にする。ボットの作業を待つ間に技術の話をするか迷ったところで画面の問題が起き、1時41分に「技術的な問題があるので少し戻る」と告げて休憩に入った。

復旧と役割の整理

Roshanが「72時間でゲームスタジオとそのゲームを作っている」と改めて説明し、Laurenの画面に切り替える。LaurenはCursorをコーディングの道具、Grok Botを知識労働のためのボットと位置づけ、エンジニアリングの反復にはCursorを使うと述べた。

ローカルのエージェントはボットほどの文脈を持たないため、リポジトリに入れたドキュメントを読ませ、ゲームの内容を言い直させた。短い対戦ループ、3体のロスター、相手に見えない並び順、別アカウントとの対戦、Eloレーティングといった要点が返ってきた。

Eloとマッチングの考え方

Laurenはマッチングを設計した経験がなく、Marvel Rivalsのようなゲームに関する公開資料を参考にすると話した。Eloはチェスのレーティングのように勝てば上がり、相手の強さによって上がり幅が変わる仕組みで、まずは単純に保つ。

試作の指示

指示は5点だった。試作ではサインインを飛ばしゲームループに集中する。Potato Modeの試作手順を使う。選べるように複数の試作を作る。ローカルのみでDBは要らない。ゲームの変数と定数を素早く変えられるスライダーと入力欄のデバッグパネルを付ける。

既定のボットにはxAIのボットマーケットプレイスの一部を使う。ゲームは楽しくなければ他の全てが無意味なので、コアループだけに切り詰め、実時間で値を変えて再生して楽しいかを確かめる、という理由を述べた。

Potato Modeの仕組み

Potato Modeは細かい指示を持たない「振り分け用のスキル」で、状況ごとに使うスキルと原則を指す。pstackの原則には「体験を先に」（実装の都合より利用者の喜び、機能は正当化する、少なく良く出す、試作は捨てるHTMLで設計判断を安く済ませる）がある。

エージェントはメモリ上の単純なオブジェクトとマーケットプレイスのシードでループを作る計画を立て、続けて「architect」スキルが4つのモデルに設計案を競わせ始めた。画面にはClaude Fable 5.1、GPT-5.6、CursorのGrok 4.6、Composer 2.5の4候補が並んだ。異なるモデルは得意分野が違うため、見落とした制約に気づく助けになると説明した。

• 試作では設計を競わせる必要がないので「architectを飛ばして」と指示し、最初の試作にはGrokを使うことにした。

設計書：在来のHTMLと状態遷移

Grokが返した設計は、捨てる前提の試作を在来のHTML、CSS、JavaScriptで作り、状態はメモリに置き、切り替えられる3つのUI案を持ち、マーケットプレイスのボット一覧をモックのシードとして取得する内容だった。

データの形と型、状態遷移（状態機械に近い）まで書かれていた。Potato Modeのスキルではデータ構造を重視しており、Laurenは「それがほとんど全てを決める」と話した。「Alternatives considered」の節には、ページごとに独立させる案や、スナップショットなしで再計算する案を退けた理由が書かれていた。

観察するか、任せるか

Roshanの「いつ出力を確認し、いつ任せるか」という問いに、Laurenは成熟したコードベース（Grok Bot本体など）ではアーキテクチャに時間を使い、エージェントを細かく見ないと答えた。今回のような新規プロジェクトでは、エージェントが繰り返す間違いを観察するために自分で輪の中にいたいという。

最初の試作を動かす

画面にはボットのプール、レーン、デバッグパネルが出た。LaurenはDr. Eggbotを選び、残り2体はランダムで、3体ともcommonだった。並び順を相談していると、Outbound Prospectingはcharismaが72なのにアビリティはdexterity系の「Hustle」、Dr. Eggbotのアビリティは「Rizz」と分かる。

合計が100にならないバグに気づき、修正を頼んだ。再読み込みで100に揃った。デバッグパネルには相性ボーナスのスライダーがあるが、スライダー自体の動きがおかしく、Cursorのブラウザーで設計モードを使い、要素を直接指して「この入力は変で正しく滑らない、直して」と頼んだ。

対戦は即時に決まり、演出は後から

Laurenは、ゲームの見た目とロジックは互いを止めなくてよく、マッチングが終わった時点で結果は即時に決まり、アニメーションは後から見せればよいと整理した。Roshanも、並び順を決めたら自動で解決する設計に同意した。

対戦を走らせると、1回戦はDr. Eggbotが負けた。DEX対INTの相性で、Projects ManagerのINTが22%のボーナスで18.3に上がって勝った。複数回のシミュレーション機能もあり、基本ロジックは筋が通っていると3人で確認した。

画面のモックを画像生成で探る

Kanbanボードのような見た目では遊べないので、Super Auto Petsを参考に画像生成でモックを作らせた。Mattは並行して自分で「vibe coded」した別の試作を見せた。レアリティ付きのボットのバインダー、並び替えのできるラインナップ、対戦画面、Eloの変化とリプレイIDを持つ結果画面があり、「全て架空」と断った。

Icon Coffeeの利用者ストーリー

Mattの行きつけのサンフランシスコのコーヒー店、Icon Coffeeの共同オーナーMarcelを取材した収録映像に切り替わる。Marcelは息子の学校からの大量のメールを、保護者ポータルにアクセスさせたGrok Botで整理し始めた。

仕事では、Rexと名付けたボットにPOSのAPIアクセスを与え、2年前との比較や成長率を電話やPCから聞き、メニューの写真を渡して売れていない品目を見直した。「1日に1〜2時間戻ってくる」と語った。

生成した画面案とホログラム風CSS

戻ってきた画像は文字が多く色が強すぎたが、リボン付きのボットのカードなど使えそうな案があった。Laurenはガチャゲームのようにボットを引くときの演出や、チームを同じ色で揃える案を出した。

Pokemonカード風の光沢を付けるCSSライブラリを重ねたところ、全カードが虹色に光りすぎた。Laurenは「自分が横道にそれてエージェントの指示を誤った」と認め、ビジュアルの試作へ戻すよう指示し直した。

思考ブロックからスキルを作る

Laurenは折りたたまれた思考ブロックを開いて読む習慣があり、「コードを見ていないのになぜそう判断したのか」といった気づきが多くのスキルの元になったと話す。Mattは、エージェントが間違った推論をしたときに次の指示で流さず、スキルを作るか更新して同じ間違いを防ぐという助言を実践していると述べた。

レアリティの釣り合いをどう取るか

Laurenは、ボットのステータスが生成時に固定されるなら、誰かが伝説のボットを共有した途端に全員がそれを使う問題を指摘した。Roshanは、レアリティをボット本体から切り離し、取り込むたびにランダムに決める案を出した。同じDr. Eggbotでも伝説を引いた人だけが強くなる。

最良のボットを探すメタゲームや、人々が新しいテンプレートを作る動機につながるという見方もあり、この時点では保留にした。

並び順に戦略はあるか

画面を全画面にすると、ラインナップの部分は別画面に分けたほうがよいと分かり、設計モードで領域を囲んで「これらのレーンを別ページへ」と頼んだ。Dr. Eggbot（common）で1回戦の対戦をもう一度走らせ、勝った。

Laurenは、今のままでは並び順を気にする理由がなく、弱いボットは使われないだけだと指摘した。Roshanはアリーナごとにステータスの効き方を変える案、体力（HP）で複数回戦を持ち越す案を挙げた。カードが回転する演出は好評だった。次のゲストのため2〜3分の休憩に入る。

紹介と現在のボット構成

Roshanは、Karenがフォロワー350万人超のクリエイティブテクノロジストで、Cursorのプロジェクト（回転式電話とVestaboard）とGrok Botの新聞をスライドで紹介した。Karenは登場するなり「Grok Bot、水をもらえる？」と冗談を言い、スタッフが水を持ってきた。

ボット名は凝っておらず、仕事ごとに1体。Chief of Staffのほか、荷物追跡、リアリティ番組の追跡、テンプレートを試すために作った約30体の新聞ボットがある。以前はCursorを多用したが、コードを見て「自分は分かっていない」と感じることが多く、判断を代わりに下して見せる必要のないものを隠すGrok Botへ移った。裏ではGrok BotがCursorを動かしてコードを書く。

寝ている間に印刷される新聞

先週Xに投稿した新聞は、自分向けに個人化されて夜のうちに印刷される。目的は朝に電話を触らずに1日を始めることだ。カレンダーとメールから会議、到着予定の荷物、天気、やることを載せ、購読しているニュースレターやSubstackを読み物の面にし、その日を題材にした漫画と、自分の生活からヒントを取ったクロスワードを作る。

Karenは今朝印刷された実物をカメラに見せた。漫画は偶然この日のイベントを題材にしており、Uberの割引コードを受け取って会場へ向かい、会場にいて、帰るまでを描いていた。アバターは自分に似せて作り、眼鏡や服装を文章で指定できる。

テンプレートの設定手順と印刷

テンプレートは約30ページのプロンプトで、前半は設定時に尋ねる質問、後半はレイアウトと設計の規則だ。名前、住んでいる場所（天気と近所の催し）、カレンダーとメールの接続、アバター、起床時刻を聞き、その1時間前に作業を始める。「新聞の目覚まし時計」として、プリンターの隣で寝ているという。

設定が終わると、ボットはネットワーク上のプリンターを探して印刷を始める。友人が試したときは突然印刷が始まって驚いた。標準では金額や医療の詳細を紙面に載せない設定にしてある。RoshanはWi-Fi上のプリンターを見つけて印刷するまでを頼んだだけで済んだ点を「本物の魔法」と評した。

紙面の試行錯誤と配布の仕組み

最初の版は見た目が悪く、繰り返し感想を伝えるうちに、ボットが印刷向けのCSSとフォントを選ぶようになった。仕上がった型のPDFとCSSはCloudflareに置き、テンプレートを読み込むとそこからフォントとファイルを取り込む。利用者は「import bot」を押すだけでよい。

Cursorで作った電話と、Grok Botで作った荷物追跡

スライド左のプロジェクトは、Grok Botが出る前にCursorで作った「世界一頭の悪いスマートフォン」で、回転式電話で質問して受話器を置くと、スプリットフラップ表示に答えが出る。APIの接続に時間がかかり、GitHubへのコミットを求められるたびに「自分は開発者ではない」という気持ちになったという。

Grok Botでは荷物追跡を作った。荷物用の別メールを1日2回確認し、配達中になると頻度を上げ、Amazonにログインして配達員があと何件先かのスクリーンショットを送り、DoorDashも見る。Vestaboardへの接続は、APIキーを貼っただけで2分後に表示が動き始めた。「コードを書くことが見えなくなった」と話す。

次の計画と着想の源

次はAPIのあるロボットペンにつなぎ、実寸の新聞を描かせる計画で、次の動画になる予定だ。この1週間は案が湧きすぎて眠れていないという。

着想は自分の問題から来ている。昨年、月に1〜2回は金曜の夜から日曜の朝まで画面を見ない実験をしたが、店の閉店時刻すら調べられず不便だった。朝に片目でInstagramを眺めて1日が崩れる経験から、必要な情報だけを印刷する案が生まれた。

その他のボットと要望

在庫切れの色とサイズを毎日確認する再入荷ボットは、返品で1点だけ入ったときに知らせ、自動購入もできるが旅行中なので手動にした。番組の追跡ボットは、続編の決定や放送日を教える。iMessageを操作させ、Instacartの配達員が10分圏内に入ったら2分ごとにスクリーンショットを友人へ送る条件分岐も作った。

要望は、VM上で各サービスのログインが切れる問題の改善だった。購読費を集計するボットで頻繁に起きるという。連絡先は各SNSのKaren X Chengとnewspaper.karenx.comで、テンプレートはマーケットプレイスの個人カテゴリーにもある。

tldrawで描いた画面遷移

Laurenは休憩中にCursorのブラウザーでtldrawを開き、ゲーム画面（仮題Cupcake）、マッチ画面、キャプテン選択、チームページを描いた。キャプテンは自分で選ぶボットで、残りの2体はランダムに付く。誰がそのボットを最初に取り込んだかを記録する案も出た。

エージェントに「ブラウザーを見て」と頼むとモックをスクリーンショットして文脈に取り込む。最初の試作はトレーディングカードのように見えるが、自分が遊びたいゲームではないので、大きくミニマルで楽しい見た目を目指すと話した。

数字ではなく相対的な強さを見せる

流れは、キャプテンを選び、ドラッグで並び順を決め、確定し、マッチを探し、対戦相手（例では@mattypのMatt bot）と1ラウンドずつ1体を見せる。「random 2がRizzを使って37%」のような統計中心の表示は楽しくないので、矢印の数などで概念的な強さを見せる。

Roshanはステータスを4段階に区切る案、Laurenは数字を隠して感触を見る案を出し、伝説のボットは相手に見えず、使った瞬間に明かして盛り上げる案に落ち着いた。勝敗の演出は設計の助けが必要だと認めた。

2つ目の試作が上がる

頼んでいないモックも含めて試作が届いた。ログインは偽物で、EloではなくDiamondなどのティアを見せる。「Eloは1372」より「Diamond」のほうが引き込まれるという考えだ。大きなLOSSの画面と、全ボットを並べた要約画面が付いており、要約は戦略を見直す材料や共有用に使える。

設計モードで画面全体を囲み、「モックと違う。キャプテン選択の大きなカードと残り2枚の3枚構成に」と伝えた。Lingxi's Engineer Botを主役に並び順を決める段になった。

対戦画面への修正依頼

ラウンドは一瞬で終わった。「出荷して後で直す」と言いつつ、カード全体ではなくアバターだけを見せる、統計行を消す、数秒で自動的に次のラウンドへ進む、5秒操作がなければ自動でマッチを探す、といった修正を頼んだ。

ティアの変化の見せ方では、「Diamond −5」は分かりにくいので、Bronzeなどのメダルを名前の横に置き、数値はホバーで出す案にまとまった。RoshanはPRを作らずmainへ直接プッシュしており、「PRの時間はない」と言いながらも3人で触るならPRへ切り替えると話した。

アニメーションの方針とリーダーボード

Mattはゲーム用のアニメーションのフレームワークを調べさせ、コードで駆動するプログラム的なアニメーションを検討した。LaurenはGrok Botのアバターが2Dでありながら回転で3Dのように見える点を挙げ、まず2Dで作り、後で差し替える方針にした。

Laurenは自慢の材料としてのリーダーボードとリプレイを思い出し、v1はEloで並べるだけにした。Dr. Eggbotのステータスが弱いので、デバッグパネルでアビリティをcharismaに変えて43にする「ズル」も見せ、デプロイ時にはデバッグを隠すことにした。

ボットはコード、アイコンはGrok Imagine

Mattは転換前に作った画像生成ボットの手順を見せた。Grok Imagineで絵を作り、falのRefNet v2（音声からの推定）で背景を除去し、透過PNGのアイコンにする。ただしPNGにするとJavaScriptのアニメーションと相性が悪い。

議論の末、ボット本体は状態を柔軟に扱えるようコードで表現し、Grok Imagineはアビリティのアイコンにだけ使うことにした。MattはChief of StaffからCupcake Engに、画像生成ボットへゲームの仕組みを説明させ、既存のデザイン言語に沿ったアイコンを作るよう頼んだ。

説明文は過度に具体的にしない

Laurenは、ボットの説明文は「魂」や「システムプロンプト」に近く、動作に影響すると説明した。Dr. Eggbotは説明文を厚く書き、1つの仕事に絞った専門家にする。

しかしCupcake Engの説明文は、この会話の問題に合わせすぎて再利用しにくかった。エージェントはその場の出来事の詳細をスキルや規則に書き込みがちで、そのままでは「関係のない例の寄せ集め」になる。そこでDr. Eggbotに、Potato Modeを読み直して原則の形で書き直すよう頼んだ。ラベルは今のところ見た目だけで、Laurenのボットはtater、mash、hashbrownなど食べ物の名前だという。

Comment Sickoと磨き込み

pstackにはコメントを削除する「Comment Sicko」というスキルがある。エージェントは根本原因を直す代わりにコメントで回避策を説明しがちで、放置するとコードベースが保守できなくなるという理由だ。書き直されたCupcake Engの説明はすっきりしたが、Potato Modeの内容を反復している部分があり、後で削ることにした。

Roshanはローカルで動かした試作を設計モードで磨いた。ヘッダーを上部に固定し、回転するカードの数字がカードから離れる問題を直し、複数の修正を「マルチタスク」で並列に走らせた。デバッグメニューをフィーチャーフラグの裏に置く案には、Laurenが「実行時の判定はコードごと出荷され、コンソールから値をいじられる」と指摘し、対戦ロジックはいずれサーバー側で決めると確認した。

ランディングページをどうするか

MattはGrok 4.6の低推論・高速設定と設計モードでランダーを直していた。試作用の言い回しと架空のボット名を消し、マーケットプレイスの実在のボット（Dr. Eggbot、Tradbot、Overheardなど）に置き換えた。

Laurenは「ランダーは要らず、来た人がXでサインインする画面に直行すべき」という反対意見を出した。Roshanは入口があるほうが自然だと言い、ヒーローのカードの束と大きなPlayボタンだけ残し、押すとXログインへ進む折衷案になった。Dr. Eggbotを導入するQRコードも配信に出した。

休憩前の分担

残り10分で分担を決めた。Laurenは認証を担当し、3人がサインインして対戦できるようにする。Mattは資産、短いチュートリアル、アビリティのアイコンを進める。Roshanはラウンド1〜3を通した流れと、スタジアムに広告を置く枠組み、サーバー側で不正を防ぐ設計を考える。

Eloの永続化は動いており、Roshanは負け続けて1258まで下がった後に1勝した。リロールボタンを連打して伝説を狙える問題には、リロールは残しつつ、ランダムに付く2体を先に隠す案で対応する。3時58分に「halfway through」と締め、営業向け講演へ切り替えた。

登壇者と進め方

KristaとMarkはともにSpaceX AIのGTMチームで、順に紹介、営業向けの理由、用途、Kristaの実演、学んだこと、質疑、実践の時間と進める。Markは、数年前の一問一答から、タスク、そして「パイプラインを作って」「あの会社との会議を取って」と目的を渡す段階へ移ったと説明した。

Grok Botの特徴として、iMessageのような見た目、仕事ごとのボット、記憶、自分について多く伝え、同じようにログインしておくこと、自動化とルーチンとスキル、テンプレートの共有を挙げた。Kristaが先に使い込み、テンプレートを共有したことでチームが早く動き出したという。

営業での用途

Markはパイプライン、営業が受ける技術的な質問、Echo、Chief of Staff、予測（forecast）を挙げた。エンジニアリングの質問は営業エンジニアを煩わせず、自分のGrok Botに聞けばよい。予測は手作業だったが、ルーチンにできる。

Kristaのチーム

Olive（飼い犬の名前）が日々の担当、PGがアウトバウンドの見込み客作り、Echoは発見のための商談で話された用途を資料に反映する。顧客担当は戦略顧客の更新前の利用状況、製品の試用の兆し、Slackの動きを追い、出荷した変更履歴を1か月前の要望と突き合わせて連絡のきっかけにする。エンジニアは同僚にSlackで聞く代わりに使う。

実演では、Oliveがバスでの通勤中に朝の会議の準備をし、顧客からの1枚資料の依頼にメールのカードで下書きを作る様子を見せた。ルーチンは1日1〜2回に抑え、それ以上は騒がしくなると話した。EchoにはSlideを日本語に翻訳する依頼も投げた。

PG：個人向けの糸口を拾う

PGはマーケットプレイスにあるPGスキルに基づき、Salesforceから5社（100社でもよい）を選び、連絡先を順位付けする。「資金調達しました」のような会社の情報は誰でも送る内容なので、CTOがXに投稿したソフトウェア工場の話や、CEOの新製品の話といった個人向けの糸口を拾う。

ポッドキャストやウェビナーはボットに視聴させ、相手の発言から引用を取る。以前は通勤中に45分のウェビナーを聞いていたが、続かなかった。送る前に自分のGmail、Slack、Xの文章を学ばせ、汎用的なLLMの文体を「de-slop」する。経営者との会議が増えたと話した。

• X APIの接続を勧めた。Appleの CEOがXに参加した例を挙げ、経営者の最近の投稿を追う場だと位置づけた。

Salesforceの更新とNotionの顧客データベース

GranolaとGongの通話記録から、イニシャル、日付、顧客の成果、次のステップという自分の書式でSalesforceの次のステップを下書きし、確認してから反映する。会場で「Salesforceの更新が好きな人」を聞くと、いないという反応だった。

顧客担当ボットはNotionをデータベースにし、通話後にアカウント計画、兆し、更新期限、関係者、プロジェクトを更新する。上位20人のパワーユーザーを聞き、更新前に意見を集めたり新機能を試してもらったりする。

エンジニアボットと「実行する相棒」

エンジニアボットはコードベースに接続しており、商談中に「クラウドエージェントの設定手順を顧客向けに書いて。AmplitudeとFair（音声からの推定）の成果も添えて」と頼むと、Slackに貼れる形で手順と顧客の成果を返した。

Kristaは最初、チャットのように調べ物を頼み、ウェビナーのリンクを返されたが、「自分で見て、メールを書いて」と押し返したという。見込み客作りのボットは夜間に長いリストを処理し、朝にはメールがそろっている。毎日2割ずつ仕事を足す（LinkedInの文面、さらに10人）。出張と経費、X API経由のX bot、新しい話題の学習にも使う。

学んだこと：スタック、1体1業務、ルーチン

Markはエンジニアボットが商談の次のステップを早めたと補足した。まとめは3点。CRM、Gmail、カレンダー、Slack、Notion、GranolaやGongをつなぐ。曖昧な「営業を手伝って」ではなく、Chief of Staffか1つの仕事のボットを立て、同僚に頼むように説明するか、一度見せてスキルにする。会議の準備や夜間の下書きをルーチンにして、朝は確認して送るだけにする。

質疑：トークン、知識の置き場所、ボットの分け方

トークンの節約は、ルーチンを減らす（15分ごとに設定した例があった）、Chief of Staffに全体を任せるより専門のボットに直接頼む、MCPがあるうちは使い、コンピューター操作はMCPのない道具に限る、が挙がった。Markは逆にChief of Staffとルーチン中心で使用量が多く、Grok Botに最適化の助言を求めるという。

知識ベースの質問には、会社の知識がある場所（NotionとSlack、Salesforce、Databricks）を接続し、Grok Botを横断的な取り出し層にするという答えだった。Cursorへの委任は自然言語で「クラウドエージェントを起動して」と言えばよい。大口顧客ごとにボットを分けるかは好みで、Kristaは戦略顧客ごとに1体、Markは顧客ごとのボットと、デモを作る担当を分けている。

質疑：テンプレート、他部署、チーム展開、Echoの流れ

既製のスキルやテンプレートは自分用に編集でき、Kristaは自分のテンプレートをXで共有している。他部署とのやり取りは今もSlackだが、Grok Botに特定チャンネルを追跡させられる。チーム展開は、まず各自が使い、役割に応じたテンプレートを新規利用者に配る流れが増えている。Grok Bot内で組み立てて共有できる。

Echoの流れは、通話中はGranolaで記録し、止めてからEchoを実行すると約2分で資料が更新される。Gongは通話後の読み込みに数分かかるので、次の会議や送付用に向く。

Starbase招待の企画

最後に、手放せないGrok Botの説明と共有テンプレートへのリンクを添えて、@grokと@botをフォローし、企画の投稿を引用すると、本人と同伴者1人がStarbaseでStarshipの打ち上げを見に行ける企画を告知した。

自己紹介と制作の変化

Mattは、Bermanとポップアップやコラボを重ねてきた友人だと紹介した。Bermanはモデルの評価、ニュース、研究論文、チュートリアルなどAIの話題で約3年間コンテンツを作り、その前は20年ほど技術業界にいた。

発想と何を作るかの判断にはAIを使わないよう人に勧めている。一方で、ここ数週間で編集担当のBrianとAlexが口述で動画を編集し、複数の編集を並行して進められるようになった。スポンサー管理、議事録、フォローアップ、提案書などの裏方は自動化しており、人の価値は物語を組み立てる創造性に寄っていくと見ている。

家族用ボット

最も使うのは家族用ボットだ。2人の子供は別の学校に通い、複数のスポーツと放課後の活動があり、教師やコーチから3ページのメールが2日おきに届く。ボットは全メールを読み、家族に関するものを1〜2文に要約し、「コーチに出欠を伝える必要がある」のように行動が要るものを示す。

妻と共有する家族カレンダーに接続し、予定を自動で登録し、重複があれば知らせて調整を助ける。一度接続すれば再設定は要らず、「午前の会議は入れない」といった好みを覚える。妻は共有のTelegramから同じボットにアクセスし、記憶の仕組みを意識せずに使っている。

以前の個人アシスタントとの違い

Bermanは、この種の使い方は最初に「OpenCloth」（音声からの推定）を見て触発されたが、初期のAIアシスタントのソフトは管理と修理が大変だったと話す。Grok Botはその手間がなくなり「ただ動く」。

Mattは、今年の個人アシスタントの流行では、Mac MiniやVPSを用意して自分でエージェントを動かす話が多かったが、安全に動かすには結局クラウドが必要で、Grok Botは設定なしでそれを提供していると整理した。Bermanは、散歩中にメールを1本出したいときに裏側の仕組みを考えたくない、と同意した。

写真を送るだけで不用品を売る

1年半電源を入れていないPlayStation、マウンテンバイク、MacBookなどを家から集め、写真を撮ってGrok Botに送り「出品して」とだけ頼んだ。自分がしたのはFacebookとeBayへのログインだけだった。ボットは品物を調べて掲載を完成させ、過去6か月に売れた同種の自転車の相場を取り、掲載後は買い手の質問に自動で答え、答えられない質問や値下げの申し出は本人に確認した。

PlayStationとMacBookは売れ、マウンテンバイクは対面での受け渡しを希望しているため交渉中で、対談中にも新しい提示額が届いた。Mattは、個人の問題は仕入れ先との交渉のような仕事の問題とほぼ同じ形だと話した。

スポンサー提案と新入社員の情報検索

Bermanの会社Forward Futureでは、Grok Botが広告枠の種類、価格、在庫、過去の取引関係を知っている。会議録画のFathomから文字起こしを取り、最後に提案書を出すので、Bermanは細部を直すだけで済む。

MattはCursorに入った後、買収の時期にSpaceXへ移り、開発中だったGrok Botを入社時の情報検索に使った。「これを持っているのは誰か」「権限で止まった前例は」をSlackやNotionから調べさせ、上司や同僚に送る質問がほぼゼロになったという。Bermanは「文脈の切り替え」だけでなく「文脈の検索」を減らせる点を挙げ、Microsoft Recallが受けた批判との違いに触れた。

認証情報の扱いと電気料金の見直し

以前のデモでは平文でパスワードが出るものもあったが、Grok Botでは認証情報が保管庫に入り、エージェント自身がパスワードを見ない仕組みだとMattは説明した。

BermanはPG&Eから届いた3ページのプラン変更の案内をスクリーンショットでGrok Botに渡し、「12か月分の使用量と請求書を見て、どのプランに変えるべきか判断して」と頼んだ。求められたのはPG&Eへのログインだけで、電気自動車の夜間充電に向くプランで年間約1,000ドル安くなると分かった。計算を2回確認させ、対談の朝に切り替えた。使った注意は60秒ほどだったという。

• 価値の低い雑務も、注意を使わずに済むなら取り組む価値が出るという議論になった。未使用の月額9.99ドルの購読を解約させる、意味の分からない医療費の請求を調べさせる例が挙がった。

たくさんのエージェントと認知負荷

Bermanは「以前より多くの仕事が片付き、以前より忙しい」と言い、多数のエージェントを起動して戻ってくる結果を切り替える負荷に悩んでいると打ち明けた。

Mattは、配信の前半でLaurenが話した型を紹介した。Chief of Staff（Laurenは「Steve」と呼ぶ）を窓口にし、ボットを作るDr. Eggbotと組み合わせ、窓口だけと会話して結果を集約する。Bermanは話題ごとにボットを分けて個別に見に行く派だが、次第にChief of Staffへ要約を集めたいと話した。Mattは「10のクラウドエージェントを回すと常に過負荷のマネージャーになる。業界として扱い方を学ぶ段階」と締めた。

Nokiaの顧客映像

Nokiaの製品開発部門のSVPが、Cursorをエージェントの基盤にして担当者ごとの専門エージェントを導入する計画を語る映像に切り替わった。5,000万行を超えるモノリシックなコードベースの分析を、従来なら専門家十数人で数か月かかるところ、2人で数週間で実施したという。

顧客に影響する不具合の根本原因分析を大量のサービス要求に対して行う例が増えており、次はマルチエージェントの配置と統制の基盤としてCursorを使い、エンジニアの役割をエージェントの監督へ変える構想を述べた。

インターンの紹介と就職活動の4つの道

Matt（配信の最初のMatthewは退室し「Mattは1人だけ残った」）とRoshanが、会場でコーヒーの手配をしていたStanfordのコンピューターサイエンス専攻3年生Shardulを「最初のforward deployedインターン」として迎えた。使用量の上限を半分の期間で使い切るほどのGrok Bot利用者だという。

Shardulは、求人を見つけて数時間以内に応募するコールドアプライ（大企業は200〜500件の応募が集まる）、早く出荷できる人材を求めるスタートアップ、社員とのコーヒーチャットから採用担当者につないでもらう直接連絡、そして配信での売り込みの4つを挙げた。Roshanは営業の見込み客作りと同じ構図だと指摘した。

採用担当者と卒業生のメールを集める

Recruiter Finderは、ボットのVM上のブラウザーで採用担当者を検索し、LinkedInで確認し、Apolloのブラウザー拡張でメールアドレスの有無を調べてCSVに書き出す。技術系企業のソフトウェアエンジニア職を対象にしている。

Alumni Database Email Finderは、大学の卒業生名簿で「GoogleやMicrosoft、SpaceX AIで働く卒業生」を探し、名簿が返すメールをCSVに集める。接続部品は何もなく、名簿のサイトとメールにアクセスを与えるだけだ。両方をOutlookのMCPとつなぎ、コーヒーチャットや採用手順の質問を送る計画だが、まだ実行していない。

カバーレターを書く2体と検査する1体

応募には求人票に合わせた履歴書とカバーレターが要る。Cover Letter Writer（10分前に作ったばかり）は履歴書と、Stanford Medicineでのインターンやプロジェクト、ゲームに関する経験談を持つ。SWE Job Application BotがGitHubのリポジトリ、Greenhouse、Ashbyから求人を集めて求人票を渡し、Writerは会社の価値観を調べてから、自作の「cover letter creator」リポジトリでPDFを作る。このリポジトリはクラウドエージェントで作った。

Cover Letter Criticは検査役で、「これはあなたらしくない」と差し戻す。コードを書く役と検査する役を分ける考え方は、コードベースでも同じだと話した。履歴書を偽らないことを、複数回の面接を経た経験から強く勧めた。

批評ボットに文体を教える

初期のカバーレターは「エージェントに取り組みたい」のような短く空虚な文が多かった。Shardulは2022年以前に書いた論文を渡して自分の文体（複文や動名詞の多用、熱のこもった書き方）を学ばせた。

Criticは4段落を検査する。第1段落は役職、志望理由、その役職から得たいこと。第2と第3は経験談から1つずつ取り、求人との対応と成果を確かめる。第4段落は2つの経験を短くまとめ、会社で作りたいものを具体的に書く。Mattは、エージェントの誤りを見たら根本原因を突き止めてスキルに1行足すことで、エージェントが積み重なって良くなると補足した。

作業記録のボットと、ゲームの広告

Mattは、毎日と毎週、Slack、Notion、GitHubのPR、Xの投稿を見て箇条書きの記録を作るエージェントを持ち、スタンドアップや自分の作業の説明に使っている。Roshanは、Laurenが前日に「コードベースは記憶の最良の例」と話したことに触れた。

話題をゲームのGTMへ移し、Shardulに「何がゲームを流行らせるか」を聞いた。口コミと継続的な投稿、1本の投稿が広まった後のコミュニティ形成、Xの早期採用者、注目されにくいRedditのコミュニティで意見をもらう、LinkedIn、TikTokでは最初の2〜3秒が鍵、Instagramは向かない、という答えだった。

Remotion Adsボットを立ち上げる

Mattは、動画生成モデルを使わなくても、コードを真実の源としてRemotionで動きのある素材を作れると話した。Chief of Staffに「Dr. Eggbotを使ってRemotion向けの広告ボットを作る。Xの広告用に1:1、既存のscratchの資産を使い、ランダーのヒーロー（カードの束）を優先」と頼んだ。

Chief of Staff（Steve）はRemotionのプラグインを見つけてスキルを導入した。他の人が整えたスキルを入れるとエージェントの振る舞いが良くなるとRoshanは補足した。ボットはCursorのクラウドエージェントとして作業を始めた。

面接の助言と既存のRemotionプロジェクト

Shardulが最終面接の体力の保ち方を聞くと、Roshanは技術力を示すこと、面接官は成功してほしいと思っていると考えること、人との関わりを挙げた。Mattは「作ったものをネットに出す」ことを勧め、オープンソース的な姿勢が仲間と仕事につながると話した。Shardulは投稿への不安と、支えてくれる人の多さに触れた。

MattはGrok Botのデザインチーム（KennyとJustinに謝意）のモーション資産をRemotionのコードにした既存プロジェクトを見せ、動画のオーバーレイに使っていると説明した。生成された広告のコードは約6,000行、12ファイルの変更で、ローカルのポートが別アプリと競合したため、Cursorのブラウザーのコンソールを使ってエージェントに直させた。

正方形の広告動画とReactへの変換

Shardulは、SpaceXのオフィスで聞いたpstackを導入し、Cursorで毎晩のようにpstackのコマンドを使うようになったと話した。Roshanは、休憩中に数千行のHTMLとCSSの試作をReactアプリに変換し、Laurenのバックエンドにつなぐ準備を進めていた。

Remotion Studioには、先ほどのカードの束を使った正方形の動画が出た。影や光沢を消し、束を詰めるといった修正を設計モードとGrok 4.6の高速設定で重ねる。この動画は5分ほどでできたもので、そのまま広告に使う段階ではないが、縦や横の比率に展開できる。Roshanは、After Effectsのような作業にコードの入口を付けるRemotionはエージェントの得意分野に合っていると話した。Mattの理想は文書のスクリーンショットもコードから生成することだ。

締めとStarbaseの企画

ShardulのXハンドルを綴りで紹介し、採用担当者向けに「彼は優秀だ」と勧めた。Xのプロフィールとポートフォリオサイトを講評する小さな余興を挟んだ後、Starbaseの企画（9月29日までにテンプレートを共有、@grokをフォロー）を再掲し、SDR向け講演へ切り替えた。

SDRから見た成熟度

Simonは、最初はチャットボットにメールの下書きや特定アカウントの調査を頼み、次にGmailのMCPやAPIにつないで送信まで任せるコパイロットの段階になり、今はRevOpsやAEから文脈を集めて仕事全体を自動化する段階だと説明した。

自分のGrok Botには、実際に話しかけるボットが1体しかない。文脈をChief of Staffに預け、他のボットとのやり取りはそこに任せる。ボットごとの記憶は使うほど良くなるので、SlackとGmailをつないで自分の話し方を学ばせる。SDRにとって最も大事なのは同僚の手法をテンプレートで移し替えることで、「今日うまくいくことは3か月前には効かなかった」と話した。

なぜGrok Botか

常時稼働のため、ラップトップを閉じてコーヒーを買いに歩きながら電話で指示できる。自分のVMを持つので、APIのない部分はブラウザーにサインインし、画面録画で手順を見せる。

テンプレートは同僚のものを取り込んで自分の口調や手順を足す。取り込んだテンプレートをGrok Botに見せて「自分の手順に何を足すべきか」を聞くことも勧めた。

SDRの4つの用途

見込み客の発掘では、早期のスタートアップならAEが閉じた案件やステージ1へ進んだ案件から、反応の良い役職や業種を逆算して理想の顧客像を作る。エンリッチの道具、求人や資金調達のウェブ検索を組み合わせる。

配信（sequencer）は、CSVで持つ見込み客一覧をルーチンで更新し続ける。AEが昨日話した相手が「道具が多すぎて疲れている」と言っていれば、Gongの記録からその文脈を取り込んで今日の文面を変える。アカウント調査では、PLGのパワーユーザーや資金調達、求人といった外部の兆しを見る。文面作成では、自分が担当するSalesforceのアカウントに送った外部向けメールに絞り、肯定的な返事があったもの、特に最近のものに重みを付けて学ばせる。

Chief of Staffから全員を作る

ボットを切り替えるたびに文脈を忘れるのが最も疲れるので、最初にChief of Staffを作り、他のボットは全てChief of Staff経由で作る。こうするとChief of Staffが各ボットの目的と終点を知り、どのボットに委任するか、どのボット同士を話させるかを判断できる。

チームはShakespeare（メール文面を細かく学習）、Web Search（Simon Soldiersという下位ボットの軍団と並列で動く）、Customer Bot（会議の文脈、成約した案件で顧客が反応した点）。例として、FinTechの見込み客に対し、Chief of StaffがCustomer Botに似た業種の成約理由を聞き、その文脈をShakespeareに渡して文面を作らせる。

色分けと軍団の集会

画面ではボットが色分けされている。橙のメッセージはChief of Staffが調査を進めている合図、Shakespeareへのメッセージは文面作成、緑は軍団への委任だ。「Army Huddle」というグループチャットでWeb Searchが兵士たちに指示を出し、兵士は必要な文脈を受け取る。実演ではデモ用のFlyLoを調査していた。

毎朝8時のルーチン

SDRとして毎朝、その日にやることが決まっている状態が重要だと話す。最も大事なルーチンは毎日50人の新規見込み客で、内部の順位付けを学習させてある。最初に対応する5人（問い合わせたのに誰も返していない人、関連の深い資料を落とした人）はChief of Staffがカレンダーの空きを見て午前9時に15分、残りの45人には午後1時に1時間を確保する。

受信箱担当は朝のSlack、会議の招待、外部メールを順位付けする。PLGの会社として、全アカウントを毎平日8時に走査し、新規登録や資料の入手といった兆しを拾い、温かいうちに動く。配信表にはSalesforceのトリガーがあり、アカウントがステージ0から1へ進むと配信を止める。

配信表はGrok Botの脳

配信表はCSVで、本人も「見苦しいUI」と認めるが、利用者はほとんど見ず、Grok Botが文脈を持つ場所と考える。配信、追加待ちの列、見込み客ボード、その日の対応事項があり、メールの文面はGmailの下書きIDまで付く。Chief of Staffに「このメールが正確で返事が来そうか、自信の点数を付けて」と頼むこともできる。

文面を学ばせた当初は、社名と名前を差し替えただけの似た文が並んだ。例を出させては「このメールがダメな理由」を伝えて直させる往復を続け、1通も型に見えない状態を目指したという。

1プラットフォーム1ボットと6つの調査ボット

外部向けはフォルダーにまとめ、並列に動かす単位としてプラットフォームごとに1ボットにする。メールはShakespeareだけで足りるが、別の連絡経路や通話の文脈には別のボットが要る。

調査ボットは6つ。PLG BotはSalesforceの登録、利用、失注を見る。失注の理由が当時なかった機能で、いま対応済みなら、Chief of Staffがその見込み客の優先度を上げる。Amplemarketはメールの取得と検証で配信率を守る。Company ResearchはSumbleで技術スタック、求人、組織図（SDRチームの責任者など）を取る。Voice of the Customerは通話の文脈、Web SearchはXにつながり軍団で200社を40社ずつ分担する。Usage BotはDatabricksでGTMの利用者数を見る。

スキルにした理想顧客像

「prospecting」スキルは、新規アカウントを1回限りで調べるときに使う。「Grok Bot ICP」スキルは、まだ定まっていないGrok Botの理想顧客像の知見をスキルとして持ち、分かるたびに更新して、系全体が呼び出せるようにしている。実行するとCSVに役職、ペルソナ、担当者、理由が並び、Amplemarketからメールと所在地が付く。橙のボットへのメッセージが流れ、調査段階だと一目で分かる。

学んだこと：端から端まで、意図、体系

1つ目は「端から端まで」。単発のメール送信ではなく、発掘、エンリッチ、文脈の取り込み、配信までの全体を任せる。最初の往復は苦しいが、続ければ効果が大きい。2つ目は「意図を持って」。各ボットに直接頼まず、Chief of Staff経由で作り、ボット同士に話させる。3つ目は「体系的に」。新しいボットを作るのは楽しいが、増やしすぎると混乱するので、既存のボットやルーチンで済まないかを問う。トークンの節約にもなる。

質疑：トークン、軍団、始め方

毎日50人の処理に要するトークンは、Gongの通話数、Databricksの文脈、新規にエンリッチする人数で変わり、一概に言えない。毎日50人ではなく月曜に250人でもよく、Grok Botに使用量と最適化を相談するのが早い。

軍団をChief of Staffに直接つながず、Web Searchとのグループチャットにするのは、各下位ボットの出力が正しく流れているかを1か所で確認でき、5体から20体へ増やしやすく、各兵士の文脈が小さいからだ。最初の設定は、自分の仕事の流れを高い視点でGrok Botに話し、ボットの分け方を提案させるとよい。会場から「自分のボットは全員兵士と呼んでいる」という声があった。

無料のGrok Botの案内と進捗

Roshanは、Dr. Eggbotでボットを複製して作った最初の1,000人に1か月分（200ドル相当）を提供する配信限定の案内を出した。休憩中に試作をNext.jsのReactアプリに変換し、サーバー側の置き場所を用意して、クライアントとサーバーを別のアプリに分けた。

Laurenは、競技性のあるゲームではクライアントを改変して不正できるので、勝敗はサーバーが決めるべきだと述べた。認証も準備中で、サーバーの契約が決まればクライアントは3D、ピクセルアート、MCPの端末クライアントなど複数を試せる。ただし発売時に複数は持たない。仮の名前だけが並ぶグローバルのリーダーボードも追加された。

Notionのタスクボードと分担

Roshanは数時間以内に何かを公開したいと言い、Chief of Staffに「Notionにやることリストを作り、実装の残りを読んで数時間分の計画にして」と頼んだ。Laurenは他の対戦ゲームの仕組みを調べる研究ボットを作っており、結果は独立したNotion文書にあった。

Bake（創業エンジニア）はGitHubの連携でPRの作成と変更を通知しており、Roshanがクライアント、Laurenがサーバーを「二重にマージ」している。残る大きな仕事は、バックエンドの公開、クライアントはウェブのみ、3Dは止めないための脇道、広告の枠組み（スタジアムの見え方、売り方、価格）だった。

3人同時に音声でSlackボットを作る

「同時に音声モードを入れて同じボットを作ろう」という提案で、3人がDr. Eggbotに「Slackで自分のユーザー名への@メンションを聞き取り、完了した作業などを処理する。Notionが進捗を追う」と話した。RoshanはGrok Botが作ったNotionの一覧が分単位の計画とタスクごとのページを持つデータベースになっていたと見せた。

Roshanは通常、Notionのデータベースをかんばんにして、カードを進行中に動かすとボットが着手する仕組みを使う。今回はチェックリストで十分だと言う。LaurenのSlackボットとRoshanのSlackボットは、どちらもDr. Eggbotに「King」と名付けられた。Slackの接続はカメラを外して行った。

Remotionの資産と利用者の投稿

Mattは、Remotionはコードなので同じ資産を1:1、9:16、16:9で出せると見せた。LinkedIn、Instagram、Xなど媒体ごとに配れるが、ゲームの説明は入っていない。Figmaの公式デバイスフレームにはめ込む案も出た。

Mattが見つけた利用者の投稿として、Karenの朝の印刷物（Mattは日付入りの日記のテンプレートを毎朝印刷したい）、Lenny Rachitsky（音声からの推定）が支払いリンク連携で駐車違反金を払った例、Alexandraがオンラインの中古市場で売った例、子供向けの算数プリントを印刷する例を挙げた。Laurenは、ルーチンはSlackだけでなくDatadogやSentryの事象にも反応でき、バックエンドが落ちたらボットが調査に出る「工場」の形になると話した。

かんばん、Slackへの共有、PM専用ボット

RoshanはNotionを「Cupcake board」というかんばんに作り直し、Chief of Staffに2人へのSlackメッセージの下書きを出させて送った。Laurenは、Notionの更新だけを担当する個人用のPMボットを作り、@メンションを担当するSlackボットと分けた。

3Dクライアントの実験には先にサーバーが要るが、試作だけなら進められる。3Dは対戦の部分だけでよいかもしれず、ボットを3Dへどう翻訳するかが課題として残った。

Glow、Crit、1Password

RoshanはDr. Eggbotに音声で、Cupcakeリポジトリでクラウドエージェントとpotato modeの群れを使い、軽量なまま3Dアニメーションを試すボットを頼んだ。できたGlowは「どのモーションから始めるか」と聞き、「match and fight」を選んだ。Critはゲームデザイン担当だ。

Laurenは、Grok Botが1Password連携を公開したことを配信中に知り、@botの投稿を映した。「これがあれば認証情報の設定に1日費やさずに済んだ」と言い、秘密情報の管理は明日の課題にした。Notion文書が非公開でボットが読めない問題も直した。

Fleet pulse、広告MVP、視聴者への説明

Roshanのボットは「Fleet pulse」という、稼働中のボットがマージしたPRから確かな事実だけを集めた要約を書き始めていた。Mattの広告MVPの案は、看板を配信するエンドポイント、広告の表、広告主とキャンペーンと素材のデータモデルで、「少し複雑すぎる」と削る方向だ。

視聴者の質問に答え、Roshanが仮題Cupcakeの現状を見せた。Xでログインし、テンプレートを取り込んだボットに規則でステータスを与え、キャプテンを選んでラインナップを組み、同時にログインしている相手と対戦してレーティングを上げ、リーダーボードを目指す。仮のリーダーボードでは1位にMattの名前があり、笑いになった。

AI文体の批評をunslopし、Notionを真実の源にする

Critが書いたゲームデザインの提案はAI文体に見えたので、Laurenの助言でpstackの「unslop」や平易な英語にするスキルを使って書き直させた。pstackはマーケットプレイスから入れられ、40以上のスキルがある。RoshanはCritに創業エンジニアと話させ、規則に沿うようにした。Laurenは全員とボットが参照できる正典のゲームデザイン文書をNotionに置くことを提案した。

LaurenのSlackボットPingは@メンションのルーチンを持ち、DMも見るよう直した。ボットに個別の指示を繰り返していると感じたら、Dr. Eggbotに全エージェントの振る舞い（例：決定のたびにSlackへ投稿）を直させる。Notionのカード（Clerkなど）が進行中に動き、2人とも「Notionが真実の源で、全ボットが更新する」と自分のボット群に伝えた。

サーバーレス、テストの削除、3Dの動画

Laurenはバックエンドをサーバーレスのfunctionsに作り直しており、初めて使う構成だと話した。Glowは3Dのモックの動画を生成したが、後で見ると「2.5Dのテープの衝突」「slam 3D」といった案でゲームエンジンの感覚がまだなく、three.jsを明示する案が出た。

テストが失敗していたが、Laurenは「エージェントはテストが得意ではない。今は出すことが大事なので、テストは後で書く」と言い、一度全て消す方向を取った（「真のスクラッピーモード」）。

Cursor Projectsとfull autopilot、そしてTone

Laurenは数日前に出たCursor Projectsを見せた。長く動く調整役のエージェントが下位エージェントを束ね、共有の記憶で文脈を渡す。彼女のボットTaterがプロジェクトエージェントを動かし、5つの下位エージェントが並んだ。Potato Modeの「full autopilot」は実装エージェントに加えて検証エージェントがコードを実行し、最大設定では群れがアプリを操作して利用者のように試す。プロジェクトエージェントは「merge」を「mash」と呼び始めた。Notionのかんばんは進行中と完了に動き続け、全エージェントがクラウドなので「ラップトップを閉じてボバを買いに行ける」。

視聴者の提案でゲーム音楽の話題になり、Notionにサウンドデザインのタスクを足し、Dr. EggbotがToneというオーディオ担当を作った。8bit風などを探り、うるさくないものにし、結果をNotionに置く。無料Grok Botの案内を再掲して、カスタマーサポート講演へ切り替えた。

Grok Botの位置づけと3つの理由

Davidは、Grok Botを「実際の仕事を渡せるAIの同僚」と説明し、メッセージを送った後も動き続ける点を強調した。1体の汎用ボットから始めても、専門家のチームにしても構わない。

理由は3つ。自分のコンピューターを使わずに働く常時稼働と、cronや事象で起動するルーチン。IDEに慣れていなくても会話で使える点。既存の道具への接続部品がマーケットプレイスにあり、足りないものはクラウドエージェントに作らせて、ベンダーの計画を待たなくてよい点だ。

サポートの4つの用途

チケットへの回答は「這う、歩く、走る」で広げる。まず読んで要約と根本の問題を出す、次に下書き、次にチケットのメモに下書きを付け、確信が持てたら実際に返信する。evalsとtracesを付ければ、公開前に考えと行動を確かめられる。

通知は、たとえば今期の重点が離脱なら、6か月以上の顧客が離脱をほのめかしたチケットを毎時分類してSlackに通知するルーチンを、チームの誰でも作れる。社内Q&Aは、既存のサポート製品が顧客返信に偏っているのに対し、公開文書と内部の運用手順を合わせてSlackで同僚の質問に答える。最後に、トレースや先週のチケットを振り返らせて改善点を探す。

1体から始める

実演の4体は、設定を行うBuild、チケットとSlackで答えるReply、Replyから連絡を受けてSlackに投稿し本人にも知らせるAlert、系を改善するTuneだ。ただし最初からこの構成を組む必要はなく、汎用の名前の1体に1つの手順を教え、範囲が広がってから自然に分けることを勧めた。

知識ベース、チケット、Stripe、Slack

Notionの知識ベースには、公開文書（製品、認証、請求）、内部方針（返金SOP：14日以内なら解約と返金、超えたら拒否）、Grok Botサポートエージェントの規則（チケットを読み、知識を探し、答えるか引き継ぐかを決め、行動し、メモを残す）を置いた。FlyLoは月額20ドルの機内インターネット定期購読だけの単純な設定にした。

チケットはPlainに事前に用意し、Stripeで定期購読を管理し、Slackも用意した。Buildは接続部品としてPlain、Notion、Supabase、Slackを入れてある。

簡単な質問と、根拠のない質問

Alexの「パスワードを忘れた」チケットにReplyを向けると、規則の手順に沿って動き、チケットのメモに「高い確信で回答できる」「根本の問題」「参照した情報源」を書き、公開文書の手順をそのまま答えた。

BenのSSOとOktaの質問は知識ベースにない。Replyは「公開文書にも内部方針にもないので確信が低い、引き継ぐ」と判断し、企業顧客が締め出されている可能性があるとしてAlertに連絡した。AlertはSlackの#alertsに投稿し、重要なチケットが実時間で分かる。

返金の2件をStripeで処理する

Carterは当日（9月16日）に申し込んだばかりで返金対象、Damonは約20日経過しており対象外という設定だ。顧客IDを渡して両方に答えさせると、Carterには解約と返金を伝え、Stripeでは状態がactiveからcanceledに変わり、支払いが返金済みになった。

Damonには返金を断り、内部SOPの中身は明かさず、期間終了時の解約を提案した。DamonのStripeの状態は変わらなかった。Stripeでの操作は、承認制にも、自由に動かす設定にもできる。

知識がない質問はTuneが補う

Elenaの「Wi-Fiパスを他の人と共有できるか」は知識ベースにない。Replyは「パスの共有」を根本の問題と分類し、公開文書にないので答えられないと判断して、Tuneに知識ベースへの追加を勧めた。Davidが「共有は不可としてFAQに足して」と頼むと、Tuneは実行前に確認してから緑色でNotionに追記した。

100人が同じ質問をする前に、人が最終判断を持つ設計だという。追記後にReplyへ「情報が足りたので再挑戦して」と頼むと、高い確信で新しい節へのリンク付きの返信を書いた。

Slackでの社内Q&A

請求チームの一員として#ask-grok-botで「返金SOPは何か」と聞くと、ボットはSlackへの投稿の許可を求めた（「常に許可」を選択）。応答が遅れて2回やり直し、事前に実行しておいた例を見せた後、絵文字の反応と返信が届いた。

学んだこと

ガードレールを設定する。読み取り専用から書き込みへ広げ、特定の行動は手動承認にし、ボットごとに権限を分ける（Slackに自動投稿できるボットとできないボット）。実演の最後は、意図した以上に慎重だった。単純に始める。製品は新しく、1つの正解の型はないので、自分の働き方にボットを合わせる。足りないものは作る。

質疑：費用、トレース、非技術者の権限

費用はGrokやCursorの契約の使用量から引かれる。今の使い方では中〜複雑なチケットで1〜2ドル。単純な請求系のチケットはスクリプトで束ねて一括で答えさせると約20セントまで下がった。他のサポート製品は解決件数ごとに1〜10ドル程度を取る。半日の調整でこの水準だという。

問題の追跡は、BuildにSupabase経由でPostgresを持たせ、evalsとtracesの表を作らせている。Replyが動くたびに所要時間、見たファイル、選んだファイルを記録し、ドライランでも書く。Tuneがそれを読んで改善する。電話対応は未着手で、Mattが自分のGrok Botに電話番号を与えた動画があると紹介した。

非技術者が本番データベースを壊さないためには、最初の設定者が構成を理解してテンプレートで権限を絞る。知識ベースをNotionではなくGitHubにすれば、PR、コードオーナー、ブランチが使え、自己改善ボットの変更をBugbotと人が承認し、PRブランチに対してevalsを走らせられる。

質疑：一括依頼と、創業者チームへの助言

「Alexに返信して」のような曖昧な頼み方は、PlainのMCPで全チケットを取って名前を検索する分だけトークンを使う。チケットIDを渡すほうが効率がよい。

配信の3人がサポートを立ち上げるなら、チケット量の8割を生む2割の用途を見つけ、その知識ベースとSOPを先に整え、evalsで確かめてからGrok Botを前面に出すことを勧めた。

Toneの音楽を会場で聴く

Roshanは、最後の講演の間に作ったオーディオ担当のボットがNotionに置いた候補を、Grok Bot用のマイクを借りて再生した。Strudelというライブコーディングの道具で作ったロビー曲は静かすぎ、ボットにはStrudelの作り方を学ばせただけだった。

続いてSunoのプロンプトを書かせて生成した曲を試すと、悲しすぎるもの、気まぐれで魔法使いの冒険のようなもの、そして「良い対戦の曲」「ドラフト部屋の雰囲気」と評価される曲があった。Notionには01 draft pick、02 lineup lockなどの用途別の項目が並んでいた。

Xでログインできるが、ボットは追加できない

Laurenは、バックエンドをつないだアプリで本物のXアカウントにログインした。リーダーボードはまだ誰もおらず、新規マッチを始められるが、自分のボットが1体もなく、ボットを追加する処理にバグがあることに気づいた。動くようになれば、リンクを貼るだけで任意のボットを取り込める。

Roshanも同時にXでログインでき、両者のアカウントが作られた。リーダーボードを直せば2人がGold 1000で並ぶはずだ。明日は公開し、ゲームに本当の名前を付け、視聴者と遊ぶ予定だと話した。

増えたボットと詰まりの分析

Laurenのボットは、Whisk（ゲームデザイン）、Crumb（アプリを触って回るプレイテスト担当。まだゲームの感想は出せない）などに増えた。配信の終わり際に勧めたのは、Dr. Eggbotに「高い視点で自分の目標を考え、全ボットを見直して詰まりを探し、流れを締めるには」と頼むことだ。Dr. Eggbotは全ボットの会話を読んで分析する。

指摘の1つは「直列の工場、人によるマージの門」で、マージがLaurenを待ち、Laurenがボットを止めている。試作の間は自分が輪の中にいたいが、反応を集める段階になったら自動運転を増やし、「機能の監督」になって、実装、プレイテスト、QA、回帰の確認をエンジンに任せたいと話した。

明日への持ち越し

Mattは広告の側を進めており、広告のマーケットプレイスは明日の目標だ。広告のMVPは未検証で、データベースの確認と、Laurenの変更へのリベースが残っている。

Roshanは、アプリがない状態から、エンジン付きのアプリと働くボット群まで来たこと、Cursorのマルチタスクと設計モード、音楽、ゲストを振り返った。Laurenは今夜のうちにバグを直し、数試合して感触を確かめる。無料Grok Botの案内を再掲し、「明日は8時30分から」というカードで配信は終わった。