Grok Bot Galaxy：3日間の実演とワークショップを読む

Grok Bot の開発チームは、AI エージェントと一緒に3日間で事業を立ち上げようとした。初日はポップアップ事業を検討し、2日目にゲーム制作へ転換。3日目にはゲームを公開し、利用者から届く不具合報告に対応しながら、集客や広告にも取り組んだ。

Grok Bot は、複数の AI エージェントに仕事を任せるための製品だ。その開発チームによる3日間の取り組みを公開したのが、2026年9月15〜17日の Grok Bot Galaxy である。配信には、企画を詰める会話、ボットへの仕事の割り振り、試作、動作確認、公開後の修正が収められている。営業、顧客対応、マーケティングなどの職種別ワークショップも入り、ゲーム制作と日常業務の両方で Grok Bot を使う様子が分かる。 公式案内、開催日の記録、Day 1 冒頭 00:00〜00:02

配信では、コードを書いたあとに誰が試すのか、利用者の報告をどう修正へつなぐのか、どの仕事に人間の確認を残すのかも話題になる。以下では、事業案からゲーム公開までの経過をたどり、各セッションの具体例と運用上の議論を整理する。

この要約は自動字幕に基づいている。映像・音声との照合は未実施で、本文の「実演」は字幕に記録された操作説明と応答を指す。詳しい確認方法は出典と確認範囲にまとめた。時刻付きのリンクは各日の公式録画を開く。

目次：

• 3日間で何を作ったのか／Grok Bot の仕組み
• Day 1：導入と事業検討／Day 2：ゲーム制作と営業・サポート／Day 3：公開後の改善とマーケティング
• 仕事の任せ方と運用／本番停止と最終日の振り返り
• セッションと元動画の一覧／後発の解説記事との関係／出典と確認範囲

3日間で何を作ったのか

初日に検討したのは、地域のポップアップ開催を支える事業だった。チームは会場、料理を提供する人、参加者をどう集めるかを話し合い、試作とボットの準備を進めた。まだ事業の範囲を絞っている段階で、開発や検証の手順も同時に整えていた。 Day 1 02:15〜02:19・04:47〜04:51

2日目には、残りの期間でポップアップを実行する難しさを理由に、ゲームへ方向転換する。作ったボットを共有するためのテンプレートを、ゲームのキャラクターへ変える。対戦ルール、画面、サーバーを作る方針だ。終了前にはログインとバックエンドの接続を報告する一方、キャラクターの取り込みやランキングには不具合が残っていた。 Day 2 00:10〜00:15・08:13〜08:17

3日目は、公開した Thursday Arena を遊び、利用者の報告を読みながら改修する。ボットが報告を分類し、別の担当が再現と修正を進める仕組みを作るが、マッチングや表示の問題は続く。終盤にはデータベースを操作する SQL の問題で本番が停止したと報告し、その後に復旧を伝えた。広告の入札も試したものの、収益については「理論上」という表現で締めくくっている。 Day 3 02:25〜02:32・05:21・07:50〜07:57

Grok Bot の仕組み

利用者は、名前と担当業務を決めてボットを作り、外部アプリの操作や成果物の作成を依頼する。ボットには Linux の仮想マシンがあり、そのブラウザで仕事を進める様子を人間が確認できる。 公式案内、Day 1 00:40〜00:46

ボットに担当業務を伝える設定と、仕事を実行するための接続・手順は、次のように分かれる。

この表はイベント当時の説明に基づく。配信に参加した Lauren が使う Pstack と、その中の potato mode や検証用スキルは、本人が用意したツール・設定として登場する。製品の標準機能と、登壇者が追加した設定は区別している。 Day 1 02:46〜02:49、Day 2 00:12〜00:14・03:34〜03:38、Day 3 00:13〜00:15

Day 1：導入、役割分担、開発と事業検討

Google Forms を作り、スライド操作を教える

Grok Bot 101 では、Data Dan というボットを作り、音声で Google Forms の質問作成を依頼する。ボットのコンピュータを開くと、ブラウザで作業する様子を確認できる。API や MCP の接続がないアプリも、この方法で操作するという説明だ。

途中でボットから承認を求められる場面があり、メールや外部顧客への Slack メッセージを送る前に、人間の承認を求める設定も紹介する。 Day 1 00:40〜00:44

次はスライドを担当する Slide Sonia に、アニメーションの設定手順を教える。ここでは人間がボットのコンピュータを操作する。話者はその点を明示したうえで、教えた手順をスキルにして再利用できると説明する。 Day 1 00:44〜00:46

事業案を詰め、担当のボットを用意する

スタジオで検討するのは、地域のポップアップ開催を支える事業である。 Lauren は、既定のボットを Steve と名づける。次に、ボットの設定を作る Dr. Eggbot に、Steve を全体の調整役である chief of staff / executive assistant にするよう依頼する。 同時に、使い捨ての試作を作る担当を別に設ける。 本人の説明では、役割を分けることで、それぞれのボットが担当領域の文脈を持てるようにする。 Day 1 02:05〜02:07

まだまとまっていないアイデアを音声で伝え、最後にボット自身の言葉で言い直させる。 返答では、ランディングページをいくつも作る前に、会場、料理を提供する人、参加者へつながる最初の流れを作る必要がある、と整理される。 チームは、席の予約が必要な体験型イベントなのか、より簡単な店頭販売なのかもまだ検討している。 事業の要件を、試作を見ながら絞っている段階だ。 Day 1 02:15〜02:19

実装では、Grok Bot が Cursor Cloud Agent に仕事を依頼する構成を採る。 Lauren は、Grok Bot を調整・自動化に使い、コーディング用の環境で実装と実行確認を行う、と説明する。 長く続く技術的な文脈を Project に持たせる案も述べるが、この時点の発言には、採用を試している途中という留保がある。 Day 1 02:46〜02:49

Engineers：不具合報告から修正、レビュー、保守へ

03:54頃からのエンジニア向けワークショップでは、実装、レビュー、動作確認、保守をボットで分担する方法を紹介する。変更の確認には、スクリーンショット、テスト結果、性能の記録を求める。夜間のコード整理や、コードの自動検査を行う CI が失敗したときの対応も対象になる。 Day 1 03:54〜04:39、特に04:00〜04:16・04:26〜04:37

具体的には、Slack の不具合報告から再現可否を調べ、有効な問題なら修正 PR を返す運用が紹介される。 夜間の cleanup では、monorepo を調べ、品質、モジュール化、コメント、セキュリティなどを扱う。 CI が失敗したときは、ボットが原因を調べて Cloud Agent を起動し、解消できなければ on-call の担当へ回す構成を説明する。 これらは発表者が運用方法として説明した内容で、配信中に全パターンの試験を行った記録ではない。 Day 1 04:08〜04:09・04:11〜04:16

この直前のスタジオでも、同じ責務分担を設定している。 Tater が実装を担当し、Hashbrown が Tater の PR をレビューする構成である。 PR を Slack に通知し、レビューを始める連携も準備する。変更をコードへ取り込むマージまで自動化するかは、この時点では未定だ。 Day 1 03:50〜03:53

ボットが自分で動作確認できるようにする

04:47頃、Lauren は、動作確認が毎回人間の仕事になってしまう問題を挙げる。ボットがアプリを起動して調べられなければ、人間に実行とクリックを頼み、その結果を待つことになる。

そこで用意するのが verification skill だ。アプリを起動し、動作の記録であるトレースや、状態を残すスナップショットを取得して、不具合を調べる方法をボットに教える。 Day 1 04:47:02〜04:47:50

検証用スキルには二つの要素を挙げる。 一つは、アプリを決まった方法で扱う CLI やスクリプト。 毎回各ボットが別の検証スクリプトを書くと、トークンを使い、再現性も下がるため、共通の道具を用意したいと述べる。 もう一つは、機能の所在や操作方法、キーボードショートカットなどを記す feature map である。この時点ではまだアプリの機能が少なく、今後必要になるものとして説明している。 Day 1 04:49:42〜04:51:35

Product Managers：利用データから仕様と実装へ

PM 向けセッションでは、デモ用の航空予約サービス Flylo を使い、利用者の行動をデータから調べ、改善案を仕様にし、実装担当へ渡す。 データ担当の Ashley がデータウェアハウスを問い合わせ、グラフを作成する。 06:14頃、登壇者は、モバイルの利用者が座席選択で離脱していると読む。Ashley は、離脱が多いのは検索から運賃選択へ進む段階だと訂正し、PM 担当の Pete へ仕様作成を引き継ぐ。 Day 1 05:54〜06:41、特に06:14〜06:19

続いて、製品要件をまとめた Notion の PRD をもとに、実装とデザインを別の担当へ渡す。 デザインの2案から人間が一つを選び、試作を更新する。 調整役が仕事を分解し、Cloud Agent に実装を依頼して検証する流れも説明される。 調査結果を要件へ、要件をデザインと実装へ渡し、担当ごとの成果物をつないでいる。 Day 1 06:20〜06:27

Founders：商談準備、変更把握、フィードバック

創業者向けセッションでは、商談相手を調べ、会話の記録を次の商談準備に反映する使い方を紹介する。 また、PR や issue の一覧だけで変更を把握するのではなく、製品を実際に操作した確認や利用指標と結びつける例がある。 Day 1 07:33〜07:38・07:41〜07:44

07:48頃には、フィードバックから試作、PR、デプロイへ進める流れを説明する。 その後の運用上の話では、ブラウザ操作の反復と、頻繁すぎるルーティンの費用が取り上げられる。 顧客や製品の状態の把握と、日々の実行頻度までを扱う。 Day 1 07:48〜07:50・07:55〜07:59

Day 2：ゲームへの転換、営業とサポート

スタジオ：ポップアップ事業からゲームへ

冒頭で、前日のポップアップ案から方向転換したことが説明される。 チームは、サンフランシスコでの開催に必要な制約や許認可、残り2日で実行する難しさを理由に挙げる。 許認可の話は配信者が方向転換の理由として挙げたもので、本稿で法的要件を調査した結論ではない。 視聴者も一緒に使えるものを作るため、ゲームを選ぶ。 Day 2 00:10〜00:12

初期案は、Grok Bot のテンプレートをキャラクターに変換し、対戦させるゲームである。 この時点でのキャラクターの能力値や相性、チーム編成は、後の完成形ではなく、試作で検討する対象である。 Day 2 00:12〜00:15

Sales Engineers：顧客向けの技術業務

00:30頃からの営業技術者向けセッションは、技術調査と、顧客へ説明するための準備を結び付ける。 Sherlock はリポジトリの技術的な内容を調べ、顧客向けの回答へ変換する担当として紹介される。 その際、内部の知的財産を外へ出さないよう指示する。 Serena はボット自身のコンピュータで競合製品を試し、違いを調べる担当である。 Mimi はブログや会話のメモから、課題、解決策、効果、顧客の言葉を含む事例スライドを作る例に使われる。 Day 2 00:38〜00:44

00:46頃には、フロントエンドとバックエンドを調べる担当を使い、二重予約につながる race condition を対象コードから調査する例がある。 PostgreSQL 側の保護についての調査結果を、顧客向けの説明へつなぐ。 顧客からの質問を、ソースコードを調べる担当へ渡して回答する例だ。 Day 2 00:30〜01:24、特に00:46〜00:51

最初の試作を遊び、計算と操作を確かめる

初期案は、ボットの能力値と相性で対戦結果を決める。以下の試作では、その計算と操作を確かめる。

02:01頃に最初のプレイ可能な試作を試すと、能力値の合計が想定した100になっていないことに気づく。 スライダーの操作も不自然で、Cursor の Design Mode から該当する入力を指定して修正を依頼する。 生成された画面で、計算結果と入力操作をそれぞれ確かめている。 Day 2 02:01〜02:05

対戦の結果を決める計算と、結果を見せるアニメーションは分離できる、という議論が続く。 マッチング後に計算を終え、演出は後から表示する構成を検討する。 試作では複数の試合をシミュレーションし、相性によるボーナスが結果にどう影響するかを確認する。 この場面の確認対象は、初期ルールの計算と操作である。ゲーム全体の面白さや公平性の検証は、この確認だけでは完了していない。 Day 2 02:05〜02:09

ボットの設定を、個別の失敗に過剰適合させない

03:34頃には、Dr. Eggbot が作った CupcakeEng の description を確認する。 役割や話し方を定める一方、設定には細かすぎる内容が増えていた。 Lauren は、一つの PR や出来事にだけ当てはまる指示を残すと、後に関係のない例が蓄積すると説明する。 そこで、個別の問題を列挙する代わりに、CupcakeEng が従う原則へ書き直すよう依頼する。 Day 2 03:34〜03:38

この会話は、後発の記事にある「原則を書き、物語を削る」という要約に対応する。配信で行ったのは、設定画面を見て、具体的すぎる description を作成担当へ書き直させることだった。

クライアントとサーバーの責務

03:43頃、デバッグメニューの表示を feature flag で切り替えて隠す案に対し、実行時の判定ではコードがクライアントに残る、と指摘が入る。 対戦ゲームでは、利用者がコンソールから能力値などを変更できる構成を避け、マッチングや対戦の決定をサーバー側に置く必要がある、という議論になる。 この場面は設計上の指摘であり、その時点ですべての改修が完了した証拠ではない。 Day 2 03:42〜03:44

チームを何度でも引き直せる問題

03:57頃には、チームを引き直すボタンを何度でも使えば、希少なキャラクターだけを集められる問題が指摘される。 引き直しをなくす案と、自分で選んでいないキャラクターを隠す案が話し合われる。 見た目の不具合に加え、ルールを繰り返し利用したときの問題も、実際に遊ぶ過程で見つかっている。 Day 2 03:57〜03:58

Sales：顧客調査、商談準備、CRM の更新

04:00頃からの Sales では、顧客調査から商談準備、CRM の更新までを紹介する。CRM は顧客や商談の情報を管理する仕組みである。 Olive は朝の会議準備、受信箱の確認、顧客向けの短い資料の下書きを行う chief of staff として紹介される。 PG は、企業ニュースだけでなく、相手の発信、新製品など個別の接点を調べ、見込み顧客へ送る outbound メッセージの下書きを作る。 また、Salesforce に商談の次の行動を決めた形式で記録し、Notion の account plan に会話後の情報、利用データ、契約更新に関する情報をまとめる例がある。 Day 2 04:07〜04:14

ゲストの事例：応募書類を作り、文章を点検する

05:22頃のゲストとの対話では、求人を調べる担当、応募用の cover letter を生成する担当、文章を批評する担当をつなぐ例が紹介される。 応募先の仕事内容と本人の経験を合わせ、PDF を生成するリポジトリを利用する。 文体や内容が本人に合うかを批評し、見つけた問題をスキルへ戻すという説明である。 これは公式 Sales セッションとは別の、就職活動での利用例である。 Day 2 05:22〜05:29

SDRs：顧客像、情報補完、連絡の準備

06:00頃からの SDRs は、見込み顧客を選び、最初の接点を作る営業活動のセッションである。顧客の情報を継続して集め、連絡の準備に使う。 CRM の成立案件や返答から ICP、すなわち狙う顧客像を検討し、求人や資金調達などの情報を見込み顧客の選定へ使う。 候補を並べた CSV と、営業担当との会話や Gong の記録を使い、連絡を重ねる sequence を作る例もある。 文章の調整では、送信済みメールのうち肯定的な返信があったもの、特に最近の実績を重く扱うよう説明する。 Day 2 06:06〜06:14

終了前には、ボットが増え、役割が重複して混乱した経験にも触れる。 話者は、新しい担当を作る前に、既存のボットやルーティンで扱えないかを考えるよう勧める。 Day 2 06:32〜06:34

サーバーと画面を分け、検証担当を増やす

06:41頃には、試作を Next.js / React のアプリにし、今後作るサーバー側のための仮の接続部分を置いたと説明する。 クライアントとサーバーを別アプリにして、それぞれを変更できる構成を検討している。 サーバーの状態と API の契約を共通にすれば、異なる見た目のクライアントを試作できるという狙いも述べる。 異なる見た目の試作を比較するための分離で、複数クライアントをすべて公開する計画までは述べていない。 Day 2 06:41〜06:43

07:20頃、Lauren は Cursor Project を長く動く調整役として説明し、複数の Cloud Agent を動かす構成を紹介する。 実装担当に加えて、アプリを動かす検証担当を用意し、操作して壊れる箇所を探す作業も含める。 配信での「fuzz」は、利用者のように画面を操作し、境界条件を試す意味でも使われている。 一般にいう入力生成型のファジングだけを指す用語ではない。 Day 2 07:20〜07:24、Day 3 02:30〜02:31

Customer Support：回答と改善をつなぐ

07:30頃からの Customer Support では、問い合わせをボットに任せる範囲を段階的に広げる方法を説明する。最初はチケットを読み、次に要約と下書き、チケット内へのメモ、実際の返信へと進める。評価用の eval と実行の記録である trace を使って確認するという。 6か月以上利用している顧客が解約を示唆した問い合わせを分類し、Slack に通知する例もある。 Day 2 07:35〜07:37

公開ドキュメントと社内手順を Slack から問い合わせる例や、過去のチケットと trace から改善候補を探す例が続く。 Build、Reply、Alert、Tune の4ボットを紹介するが、最初から4体を用意する必要はなく、一つのボットと一つの業務から始めるよう勧める。 Day 2 07:37〜07:40

ここで紹介したサポート業務と、翌日のスタジオで作るゲームのフィードバック処理は、別の事例である。

2日目の終わりに残った不具合

終了前のアプリ紹介では、ボットを追加できない、ランキングに利用者が出ない、といった問題が残っていると説明される。 ログインとバックエンドの接続はできたが、ボットを取り込んで遊ぶまでの操作には修正が必要だった。 継続的に遊んで不具合を探す playtester bot を作り、ボット群の仕事にどこで人間が割り込んでいるかを Dr. Eggbot に調べさせる話もある。 Day 2 08:13〜08:17

Day 3：公開後の改善、顧客対応とマーケティング

公開に向けて、小さな変更と検証を並行する

冒頭の振り返りでは、前日の1対1の相性勝負を実際に遊び、あまり面白くなかったため、別のゲームの仕組みを参考に改めたと説明する。 計画を小さな段階と PR に分け、実装担当、実行確認担当、操作して問題を探す担当を動かしたという。 PR の CI が通ったことをきっかけに、別のボットがゲームを最初から操作する構成も紹介される。 Day 3 00:12〜00:18

Marketing Operations：データを社内業務へつなぐ

Marketing Operations では、複数の受信箱から仕事を取り出し、担当のボットへ渡す構成を紹介する。全体を調整する chief of staff、受信箱の担当、PM、エンジニアで分担し、作った下書きは人間が最終的に確定する。 Day 3 00:38〜00:44

00:46頃の例では、営業担当者が見込み顧客を確認する社内アプリを作るため、PM bot に目的を伝える。 候補を確認して却下した理由などを CRM に戻す仕組みを検討する。 要件を詰める際には CRM 上の情報の意味、オンライン以外の行動、どこで人間の確認を求めるかといった点を質問させ、実装へ渡す流れが紹介される。 Day 3 00:44〜00:52

不具合の調査を先に依頼する

02:07頃、対戦相手が AI ばかりになることと、Elo の変化に不整合があるように見えることが話題になる。 担当者は、不具合の原因をまだ確定せず、Cloud Agent で調査し、PR はまだ作らずに結果を報告するよう依頼する。 観察した現象と、修正すべき原因を分けて扱っている。 Day 3 02:07〜02:08

同じ時間帯に、ゲームのフィードバックフォームから Slack へ報告を送る仕組みが紹介される。 話者は、認証、送信頻度の制限、不適切な内容への対応、入力の処理を説明する。Lauren は、報告の文章に紛れた指示で AI の行動を変えようとする prompt injection にも注意を促す。ここで扱うのは配信中に説明された対策で、防御効果の実証までは確認していない。 Day 3 02:08〜02:12

報告を分類し、再現してから修正する

02:25頃、利用者の報告を読む担当と、ゲームを操作する担当を連携させる。 前者がフィードバックを分類し、後者が不具合を再現し、確認できたものを Notion に起票する構成である。 修正を進める際には、報告を分類して修正対象を選ぶ triage 自体が利用者の意図を正しく理解したか、別の担当にも確認させる案が加わる。 Day 3 02:25〜02:29

Lauren は、修正前に問題を再現できることが、エージェントが問題を理解していると判断する条件になると述べる。 その上で、別の VM でゲームを起動し、画面操作や境界条件の確認をする検証用エージェント群を説明する。 人間も引き続き遊び、問題を探すとしている。 Day 3 02:29〜02:32

Post Sales：顧客ごとの記録と、会議後の作業

03:57頃から、Blake が導入後の顧客対応を紹介する。 朝に顧客情報の一覧を確認し、会議の15〜20分前に準備する。会議後にはフォローアップと顧客別の作業へ進む。 会議のメモからフォローアップの下書きを作り、人間が送信を判断する運用を説明する。 複数のボットで顧客情報や資料を分担する使い方が扱われる。 Day 3 03:57〜04:10

Google Meet へ参加する操作の例もあるが、その場では時間がかかるためログインを進めず、会議への参加完了は確認できない。 続く会議後の資料やフォローアップは、実際の会議をその場で聞いて作り終えた成果としては扱えない。 04:10以降は、会議後の作業一式、ROI のフォーム、顧客に関する調整、複数ボットとの打ち合わせなどを説明する。 Day 3 04:08〜04:21

04:23頃には、ボットの下書きと人間が実際に送った文章を比較し、編集された差分を次の文章のルールへ反映する話がある。 改善提案が多すぎたため、週1回の提案に制限したという説明もある。 04:31頃には、紹介した構成をそのまま大量に作る必要はなく、「45 bots」は不要だと述べる。 紹介した数のボットを、そのまま用意するよう勧めてはいない。 Day 3 04:23〜04:29・04:31:33〜04:31:45

モバイルで遊び、問題をそれぞれの担当へ渡す

05:00頃には、ブラウザのモバイル表示でゲームを試す。 この段階のゲームは、攻撃力、HP、能力を持つボット3体を並べ、対戦の進行を見守る auto battler として説明される。 ゴールドで購入し、次のラウンドに残すカードを選ぶ仕組みもある。 初期試作の能力値や相性勝負から、ルールが変わったことが分かる。 Day 3 05:00〜05:03

プレイ中には、編成中のボットの能力が読めない問題、画面下で情報を流す ticker がボタンを覆う問題が挙がる。 能力表示の修正、勝利画面の共有機能、スポンサー用フォームの配置、ticker の修正を、別々の Cloud Agent へ依頼する。 ticker の修正では、コードを書く前にアプリを開き、問題の挙動を確認するよう指定する。 Day 3 05:03〜05:09

05:19頃の確認では、ticker の修正担当がブラウザを操作し、変更をテストしていると説明される。 一度アプリの検証方法を教え、以後も更新できるスキルとして使うことが、ここでも話題になる。 05:27頃には、能力表示の修正を確認し、PR のレビューとマージへ進む話がある。 この場面で修正完了として扱われるのは能力表示で、依頼した全機能の完成までは確認できない。 Day 3 05:19〜05:20・05:27〜05:29

Marketing：調査、訴求、素材、効果の確認

06:00頃から、Josh Kim がマーケティングでの利用を紹介する。 市場調査の担当が Web サイトや競合を調べ、product marketer へ引き継いで Google Docs に製品の位置づけをまとめる positioning brief を作る。 人間がその文書へコメントして改稿し、ランディングページの構成、コピーの案、広告キャンペーンの枠組みへつなぐ流れである。 Web サイト担当には、リポジトリに接続してページ変更の PR とスクリーンショットを作るよう依頼する。 文書や素材を作る作業と、実際にキャンペーンを実行する判断が含まれている。 Day 3 06:00〜06:43、特に06:10〜06:17

ただし、06:22頃に新しいキャンペーンを開始しようとする例では、予算やカードに関する判断が必要になる。 そのため、すでに実施していたキャンペーンのデータを API から取り出し、広告費、クリック率を表す CTR、コンバージョン率を表す CVR を分析する例へ切り替える。 この場で新しい広告キャンペーンを本番配信した、という要約はできない。 Day 3 06:22〜06:23

仕事の任せ方と運用

依頼を理解したか、変更が動くかを確かめる

Day 1 02:16頃と Day 2 01:33頃には、長い音声入力をボット自身の言葉で言い直させ、理解が合っているか確かめる話がある。 依頼を正しく理解したかを、実行前に確かめる方法だ。変更の工程では、修正前に問題を再現し、修正後に画面や動作を確認する。そのために検証用スキルを使う。 Day 1 02:15〜02:16・04:47〜04:51、Day 2 01:32〜01:33、Day 3 05:08〜05:09

再利用する手順と、その場だけの事情

検証用 CLI を共通にする説明と、細かすぎる description を書き直す説明は、それぞれ異なる対象を扱う。 前者は、複数の担当が同じ方法でアプリを検証するための道具である。 後者は、一度だけの失敗を汎用の指示へ残し続けないための設定修正である。 共通の道具を用意する作業と、残す指示を選び直す作業として紹介される。 Day 1 04:50〜04:51、Day 2 03:35〜03:38

外部への送信と、承認の境界

導入の承認設定、顧客へ送る文章、広告予算、公開投稿など、外部への影響がある作業では、異なる確認の場面が現れる。 Day 3 07:15頃には、試作のスクリーンショットなどを自動で X に投稿する提案に対し、本人の関与なしで投稿されることには慎重だ、という応答がある。 Day 1 00:43〜00:44、Day 3 06:22〜06:23・07:15

Day 1 の質問では、モデルの判断に外側から決定的なポリシーを適用できるか、という問いが出る。 回答では、モデル自身は決定的に振る舞わないと認め、コードや判断のフローを用意して呼ばせる方法を説明する。 これは話者が提案した方法の説明であり、モデルへの文章による指示と、ツール側で強制されるアクセス制御を同じものとして保証した発言ではない。 この回答だけでは、その制御で安全性を保証できるかまでは確認できない。 Day 1 08:03〜08:04

ルーティンの頻度と、ブラウザ操作の反復

Founders の後半では、ブラウザ操作を何度も繰り返すと費用がかかるため、利用できる API を使う方法が説明される。 一度の作業でネットワーク要求を調べ、その後は直接呼べるかを検討する、という話者の提案も含まれる。 これはすべてのサービスで自由に利用できることを確認した説明ではなく、配信中に紹介された最適化の考え方である。 Day 1 07:55〜07:57

続いて、15分ごとのルーティンは約100回／日になると述べ、必要以上に頻繁な実行を見直すよう説明する。 厳密には24時間で96回であり、発言の100回は概数である。 必要な入力が来たときに動かす webhook などの方法も挙げる。 ただし、個々の業務に何回が適切かを、この発言だけで一律に定めてはいない。 Day 1 07:57:07〜07:57:58

本番停止と最終日の振り返り

自動マージの説明と、本番停止の報告

Day 3 07:31頃、フィードバックの重複をまとめ、再現に関する情報や進行中の仕事を整理し、Cloud Agent に修正させる流れを紹介する。 その担当者は、本人の表現で「YOLO」、つまり変更を自動でマージする状態にしていると述べる。 これは配信中の運用設定の説明であり、すべての変更が十分に検証されたことの証拠ではない。 Day 3 07:30:55〜07:32:04

07:51頃、チームは、開発作業を自動化した仕組み（配信でいう software factory）で、不適切な SQL query によって本番を停止させたと報告する。 別の話者は、新規登録を再開するまで待つことになると応じる。 07:55頃には本番が戻ったと報告される。 本稿では、停止と復旧が配信者によって報告されたことまでを扱う。 正確な SQL、変更者、影響範囲、復旧手順、どの検証で見逃したのかは、この発言だけでは確定できない。 それ以前の自動マージ設定との因果関係を、詳細な障害調査が済んだようには記述できない。 Day 3 07:51:06〜07:51:25・07:55:39〜07:55:47

PR の数と、収益の報告

配信中には、多数の PR、試合数、登録者数、ページ閲覧についての発言がある。 ただし、PR については開いたもの、閉じたもの、番号などの会話が混ざり、自動字幕にも数値の不整合がある。 06:56頃の「433」に相当する字幕を、検証済みのマージ総数としては採用しない。 また、PR 数から自動化率や変更の成功率は計算できない。 Day 3 00:15・06:55〜06:57・07:50〜07:51

収益については、終盤にスポンサー広告の入札を試すものの、投稿された内容を審査する moderation が壊れていると述べる。 締めくくりも「理論上のスポンサー収益（theoretical sponsorship dollars）」という表現になっている。 この録画の要約から、広告収益を実際に獲得したと確定することはできない。 Day 3 07:55〜07:57

視聴者がいたことと、機能を絞ったこと

07:42頃、チームは、配信の視聴者がいたため、製品を試してもらう導線をすでに持っていたと述べる。 配信なしでも人々がこのゲームを遊んだか、という問いには否定的な応答をしている。 イベント中の利用数は、この集客条件のもとで得られたものだ。配信から独立した事業の需要まで確認できたとは言えない。 Day 3 07:41〜07:43

同じ振り返りでは、人間が問題を見つけ、解き方が分かった仕事をボットの手順にすること、初回公開後も改善を続けることが語られる。 また、実装できる機能が増えるほど、何を削るかを判断する必要があると述べる。 当初の複雑な能力値や戦場などの案を絞り、ゲームの中心となる流れへ集中したことを、公開できた理由として挙げている。 ここで述べているのは、チームが公開までに行った判断と、その後も改善を続ける必要性である。全自動で事業が成立したという報告まではしていない。 Day 3 07:43〜07:47

セッションと元動画の一覧

公式ページには10の職種別セッションが並ぶ。Day 1 には Grok Bot 101 の導入もある。セッションの間には、スタジオ実演、ゲストとの対話、休憩が入る。

表の「日」は Day 1〜3。時刻は字幕から探した目安で、公式のチャプター境界ではない。リンク先のプレイヤーで該当時刻を指定すると、その場面へ戻れる。 公式セッション一覧

後発の解説記事との関係

Galaxy の後には、配信内容を実務用のルールやプロンプトへ再編集した記事が出ている。 その一つが、@unicodef1wn の Set Up Your Grok Bot Like the Team Does と、対応する grokbot-field-notes である。 記事には、プロンプトは投稿者自身の表現であり、独自に選んだ内容には印を付ける、と明記されている。

そこで提示される「5原則」や貼り付け用のプロンプトは、公式のセッション一覧や、登壇者全員が発表した共通フォーマットとしては扱わない。 たとえば、細かすぎるボット設定を原則へ書き直す会話は Day 2 にあるが、それを簡潔な標語や貼り付け用プロンプトにする工程は、後発の編集である。 本稿は、そのプロンプト集の翻訳や再録を目的にしていない。

一方、非公式の transcript アーカイブも、文字起こし以外に独自の要約や評価を含む。 閲覧ガイドの順位、推奨構成、ボット一覧の分類を、そのまま登壇者の発言には置き換えない。 本文で時刻を挙げた説明は、ガイドから位置を探した後、対応する文字起こしの内容に戻って整理している。

出典と確認範囲

要約の作り方

この記事は、公式案内と非公式の自動文字起こしをもとに、AI が日本語で整理した。主に Faster-Whisper small.en の時刻付き字幕を参照し、取り上げた箇所を large-v3 の文字起こしでも照合している。

映像・音声との逐語照合は行っていない。本文の「実演」は、字幕に記録された操作の説明と、その場の応答の要約である。画面上の結果、バックエンドの状態、権限制御の有効性は独立に監査しておらず、全25時間を視聴して確認した記録でもない。

アーカイブの録画尺は Day 1 が8時間45分12秒、Day 2 が8時間23分18秒、Day 3 が7時間58分22秒で、合計25時間6分52秒。配信中の「72時間」は3日間の取り組みを表す言い方として扱い、72時間の連続映像とは解釈していない。 録画情報

本文の時刻は各日の録画先頭からの経過時間で、自動認識によるずれや誤りがあり得る。時刻のリンクは公式録画を開くが、その位置まで自動で移動するものではない。

公式の入口

• Grok Bot Galaxy 公式ページ：イベントの位置づけ、職種別セッション一覧、各日の録画。
• Day 1 公式録画：Grok Bot Galaxy Livestream。
• Day 2 公式録画：Grok Bot builds a Game Studio LIVE。
• Day 3 公式録画：Building a company in 3 days。

自動文字起こし

本文の時刻の基準は peterdays のアーカイブである。 下記は参照時点の commit に固定している。 同 repo は small.en による自動文字起こしが人間による校正を受けていないと明記している。 人名、製品名、数値の誤認識、音声がない箇所での不自然な反復があり得る。

• peterdays：README と生成方法
• Day 1 transcript
• Day 2 transcript
• Day 3 transcript

比較に用いた weichselbaum のアーカイブは large-v3 の出力を公開している。 同じ配信を別のモデルで処理した資料であり、独立した現場取材や、人間による内容保証ではない。 両方の文字起こしが一致しても、それだけで発言の正確さや、話者が述べた結果の真偽まで証明されるわけではない。

• weichselbaum：README
• Day 1 JSON
• Day 2 JSON
• Day 3 JSON

この要約の範囲

対象は、職種別セッションと、事業案の変更、ゲームの試作、検証用の仕組み、公開後の修正、終盤の報告である。 休憩、雑談、すべてのゲスト対話、配信中に行われた個々のコード変更を網羅してはいない。 映像・音声の確認を要する正確な引用や数値は断定せず、発言の要旨を自分の言葉で記した。 長い原文、プロンプト全文、文字起こし全文の翻訳は掲載していない。 製品の現在の仕様、実演環境の安全性、事業としての継続的な成果は、本稿の確認対象外である。