Grok Botの役割分担と
開発ワークフローGalaxy Day 1の実演を読む

配信の目的と3人の担当

Matt Palmerは開発者体験と教育、Roshanは製品づくり、LaurenはGrok Botの開発を担当している。3人は何を作るか決めるところから、会社づくりを視聴者に見せる。

作業の合間にはGrok Bot 101、エンジニアリング、営業や市場投入などの講習が入る。他の職種の使い方を見て、自分の仕事でも任せられることを探してほしいという狙いだ。

• 会場はサンフランシスコのDreamforce周辺のスタジオ。
• 技術職に加え、製品、営業、調査などの仕事も扱う。

視聴者向けのテンプレート企画

Grok Botを仕事にどう使ったかを紹介するGrok Bot Galaxyの企画を告知する。公式投稿を引用し、ボットの説明と共有テンプレートのリンクを投稿するよう案内した。賞品はStarship打ち上げ見学やSpaceX工場見学だという。

• 配信で案内された応募締切は9月29日。
• 参加手順と条件は公式Grok / Botアカウントの投稿に掲載される。

面倒な作業を任せて時間を空ける

表計算の調査、過去のメッセージ探し、資料やデザインの作成、開発時の手作業をAIに任せる例を挙げる。出演者が望んでいるのは、こうした仕事にかかる時間を減らし、自分が取り組みたい仕事に使うことだ。

Matt自身も、コンテンツ制作、開発、ドキュメント整備、利用者との対話を日々行っている。Grok Botを、その複数の仕事を手伝う助手として使っている。

• 「会社を作る」とは何をすることなのかも、この後に話し合う。

Xブックマークから動く技術デモを作る

Mattは、Xに保存したパッケージや技術をボットに探させ、Cursorのクラウドエージェントで試作し、プレビューを公開する自身の運用を紹介する。翌朝には紹介文と動くデモが届くため、気になった技術を試す時間を取りやすいという。

Roshanは、この配信なら顧客の声を調べるところから製品を考えられると話す。市場調査、顧客インタビュー、デザイン、マーケティングをボットに手伝わせる案を挙げる。

• 処理の順番は、ブックマーク収集、技術の選択、コード生成、プレビュー公開、朝の報告。
• Mattの既存の運用を口頭で紹介した場面で、全工程の実演はない。
• 顧客の声を踏まえて何を優先するかは、人が決める。

Laurenの運用：Xの自動応答と開発環境の整備

Laurenは、Xの特定の呼びかけに応答する遊びや、日々の性能改善、コード変更にGrok Botを使っている。PMやデザイナーも質を保って変更できるように、コードと作業手順を整えることにも時間を使っているという。

Slackに問題を書くとエージェントが修正を始める仕組みも紹介する。今回も普段の連絡や開発に使う道具へボットを参加させる予定だ。

• Grok Botの開発にGrok Botを使い、不便なところを見つけて直している。
• 今回の最初の調査では、Xと社内に寄せられた多数の回答を使う。

使ってもらい、代金を受け取れるものを作りたい

利用者が欲しがり、自分たちも日常的に使え、代金を受け取れるものを作りたいと話す。自分たちで使えば、不便な点を経験しながら直せる。

購入するのが人でも、その人に頼まれたエージェントでも、最終的に人の役に立つ必要がある。物販、コーヒー豆の配送、現地イベントなど、オンラインの操作で実物が届いたり、人が集まったりする事業も候補に挙がる。

• 何を売るかはまだ決まっていない。
• Linkを使ったボットの購入機能にも触れ、人とボットの両方が客になる案を考える。
• Dreamforceで多くの人が集まっている機会を生かしたいという思いもある。

Slackで連絡し、開発を自動化する

まずSlackで会話と問題報告を行い、必要になったら課題管理ツールを加える案を話し合う。問題をチケットに書く間に、エージェントへ頼んで修正を始められるかもしれないという。

Laurenは、自分の開発手順をまとめたオープンソースのPStackを紹介し、前月には多数のPRを本番へ反映したと話す。

データベース、決済、インフラも必要になるため、知人や関連企業に相談しながら用意する予定だ。

• Slackを人とボットの連絡窓口にする。
• 文書はNotionに残し、Linearなどの課題管理は必要に応じて加える候補だ。
• PStackの名称は音声に基づく表記。
• PRやmainへの直接反映については、冗談も交えた話し合いが続く。

空の組織から担当ボットを増やす

配信用にGrok Botチーム、まだボットのないアカウント、リポジトリのないGitHub組織を用意した。組織名はship by Thursdayで、今回の会社を既存の仕事と分けて始める。

候補を比較するため、簡単な試作品をいくつか作る案が出る。別のボットを作れる機能を使い、新しい担当に会社の方針を読ませることも考える。会社の情報をどこに置き、誰が更新するかはまだ決めていない。

• 新しい担当に会社の説明を渡してから、役割ごとの仕事を頼む予定だ。
• 創業エンジニア、インターン、調査担当などのボットを作る案がある。
• 会社の情報を置く場所としてNotionが候補に挙がる。

視聴者の提案を募り、Grok Bot 101へ

企画の相談、講習、ゲストとの対話、黙って作業する時間を交えて配信すると案内する。Xや配信チャットで視聴者の提案を受け取り、何を作るかを決める際にも参考にしたいという。

Grok Botをインストールすれば、紹介するプラグインやテンプレートを自分でも試せると案内し、RomanとAmritaの入門講習へ移る。

• 講習はこの無料配信の中で行う。
• 出演者が口頭で案内する配信時刻は現地時刻。このサイトの時刻は動画の先頭からの経過時間だ。

仕事の担当として使い続ける

RomanはAIの使い方を、質問に答えるチャット、作業を補助するコパイロット、仕事を任せるボット、職能を受け持つボットチームの順に説明する。Grok Botでは営業やメールなどの担当を作り、繰り返し頼む使い方を目指している。

スライドの表記は、Ask（Chatbots）、Do a task（Copilots）、Delegate outcome（Bot）、Staff function（Team of Bots）。

• 同じ担当を使い続けることで、好みや過去の仕事を覚えてもらうという考え方だ。

記憶、コンピューター、クラウドでの実行

Romanが挙げる特徴は三つある。仕事を繰り返し頼んで好みを覚えてもらうこと、APIやMCPだけでできない仕事をボットのコンピューターで行うこと、利用者のPCを閉じてもクラウドで作業を続けることだ。

開発者がエージェントに指示して実装を進めるような使い方を、他の仕事にも広げたいと話す。簡単な依頼から始め、少しずつ難しい仕事を任せて、どこまでできるかを試すよう勧める。

• 会話画面は同僚へのメッセージを意識している。
• コンピューター操作の例として、古い業務ソフト、動画、音声を挙げる。
• 複数の人が同じAIの担当者と働く仕組みは、今後取り組む機能として紹介する。
• スライドには、役割、メッセージ、記憶、各ツールへのログイン、定期実行、共有が並ぶ。

DataDanを作り、音声でGoogleフォームを頼む

AmritaがDataDanを新しく作る。ボットは名前から用途を提案するが、ここでは音声で、1日に飲むコーヒーの杯数とサンフランシスコの好きな店を尋ねるGoogleフォームを依頼した。

回答をDataDanが集め、Slide Sonyaがグラフと資料を作り、Email Ethanが関係者へメールを書く予定だ。Google Formsを選んだのは、画面操作が必要で、人には面倒なフォーム作成を見せるためだという。

用途のスライドでは、GTMに顧客状況の把握と営業開拓、開発に性能調査と不具合再現、マーケティングに人材候補探しと有料媒体、管理業務に補佐役と経費処理を挙げる。

• Slide SonyaとEmail Ethanは事前に作成済み。
• 実演した音声機能は文字入力だ。双方向の音声会話は社内で使っており、今後提供する予定だと説明する。
• Qualtricsなどのフォーム業務にも使えると紹介した。

Linux VMを開き、Teach a taskで操作を教える

画面右上からボットのコンピューターを開き、Googleのサービスを操作する様子を見る。プラグインやMCPの一覧も開き、直接の連携と画面操作を使い分ける方法を説明する。

AmritaはSlide SonyaのTeach a taskを使い、ボットの画面でアニメーションの付け方を見せる。対象を選び、アニメーションを設定し、再生してから記録を止めると、手順がスキルとして保存される。

• この操作をしているのはAmritaだ。
• 後で別の文字や画像に同じアニメーションを付けるとき、保存したスキルを使う。
• コンピューターや連携サービスの操作中には承認要求も出る。

送信の確認、資料の見た目、定期実行を指定する

メール送信は事前に確認し、スライド作成は確認なしで進める、といったルールを文章で設定できると説明する。

Slide Sonyaにはフォント、色、既存資料の編集方法、完成後のスクリーンショット送付を指定してある。毎朝9時に資料の変更と変更者を知らせる、週1回Email Ethanと協力して上司に報告する、という定期実行の例も挙げる。

この講習では、各ボットのコンピューターは分かれており、別々の操作を並行できると説明する。同じ資料を編集するときは、人とボットで担当するスライドを分ける例を示した。

• 共有資料の編集が衝突しないよう、作業箇所を分担している。
• 色やフォントに加え、完成後に何を見せてほしいかも伝える。
• 定期実行は設定例の紹介で、後日の実行結果はこの配信では確認していない。

Email Ethanが他の担当へ問い合わせる

メール担当には過去の自分の文章を読ませ、文体を覚えてもらう。コーヒーの調査をメールにするよう頼むと、Email EthanがDataDanへ問い合わせた。続いてSlide Sonyaにも101の説明内容を尋ねるよう指示し、やりとりを画面で確認する。

ボットは役割ごとにもプロジェクトごとにも分けられる。Chief of Staffを作り、そのボットから他の担当へ仕事を渡す方法も紹介する。

DataDanは新しいデータをまだ用意できていないと返答したため、Email Ethanは既存のサンプルデータを使うと応じた。

• 他のボットへ何を尋ね、どんな返答が来たかを人が確認できる。
• ここで使うのは参加者の新しい回答ではなく、サンプルデータだ。

メールの下書き、ボットの複製と共有

フォーム作成には時間がかかる。Amritaは、画面操作の速さはモデルやその改善状況に左右されると話す。メールでは設定した送信ルールによる承認画面と、宛先や文章を直せる下書き画面を見せる。

メール担当を複製し、経営層向け、一般利用者向け、社内向けに文体を変える例を紹介する。テンプレートを社内や公開マーケットプレイスへ配れば、資料で使うフォントや色なども揃えやすいという。

約63分でフォームができたと確認し、QRコードを作るよう依頼する。参加者の回答収集はこれからだ。

• メールの下書きはアプリ内で編集・削除でき、書き直しも頼める。
• 受け取ったテンプレートは、自分の用途に合わせて変更できる。
• 複製時の記憶の扱いは、後のQ&Aで答えている。

QRコードを配ったが、フォームを開けない

3体をグループチャットに入れると、担当間のやりとりを一か所で見られる。質問されたり作業が止まったりしたら、期待する動作を具体的に伝えて直していくと説明する。

参加者にQRコードを読み取ってもらうと、フォームにアクセスできないという声が出る。AmritaはDataDanに、リンクが公開されているかを確認するよう指示した。

• QRコードの生成後も、受け取った人がフォームを開けるかを確かめる必要があった。
• 修正時には、何が起きたかと、どう動いてほしいかを伝える。
• 修正や検証がうまくいったときも、そのことを伝えると以後の仕事に役立つという。

資料の完成を待ってメールを書く

フォームの公開に問題が残っているため、既存のコーヒーのテストデータでグラフを作り、最後のスライドへ追加するよう頼む。その後にメールを書くという指示に対し、Email Ethanは資料とスクリーンショットを待つと返答した。

さらにManagerを作り、3体の進捗を集めさせる。2時間ごとに作業の行き詰まりを調べ、フォームの公開で困っていることを他の担当へ知らせるような使い方を紹介する。

• データ、資料、メールの順に進める。
• Managerの2時間ごとの確認は、設定例として説明する。
• 新しい回答の集計や外部への送信が完了したかは、この区間では確認できない。

Q&A：承認の回数と、人を含むグループ

承認が必要かどうかは、危険度を評価するAuto Reviewと利用者の追加ルールで判断すると説明する。今回のフォーム作成では通常より確認が多かったという。質問者は、確認のたびに止まらず任せられるようにするにはどうすればよいかを尋ねた。

Amritaは、今後は確認不要と伝えるなど、任せる範囲を教えられると答える。また、複数人がSlackの同じスレッドでボットに指示を追加する例を紹介した。

• 利用者が明示した許可や好みを、以後の判断に使うという説明だ。
• Grok Botアプリ内で人とボットが一緒に参加するグループは、まだ開発中だった。

Q&A：社内ツール、操作の保存、1Password

社内ツールは、認証情報とアクセス環境を用意すれば使えると答え、MongoDBや1Passwordを例に挙げる。企業ごとのネットワーク接続は、この場では試していない。

Teach a taskは操作動画から対象や手順を読み取り、スキルとして保存するという。先ほどのアニメーションの手順を開き、後で同じ操作を頼めるように記録されていることを見せる。

1Passwordではアプリ内に認証用の入力画面が出る。Amritaによると、そこで入力した認証情報を安全に保管し、必要なサービスへのログインに使う。

• 社内限定のテンプレートと公開マーケットプレイスの両方を使える。
• ボットが作ったPDFやPowerPointなどは、自分のPCに保存できる。
• ボットのVMはクラウドで動くため、利用者のノートPCを閉じても作業を続けると説明する。

Q&A：記憶を直す、複製する、使い始める

記憶は保存され、忘れてほしいことや変更点を文章で伝えられるという。例えば担当ボットを削除したら、管理ボットにもその相手へ仕事を渡さないよう知らせる必要がある。複製した場合は役割や設定を引き継ぐ一方、会話から得た記憶は新しく始まると答えた。

使い始めるなら、毎日の面倒な仕事を一つ選んで任せてみるよう勧める。フォーム、営業メール、古い機能フラグの整理、顧客対応などを例に挙げた。

• 担当の削除など、外部で変わったことをボットが自動で把握するとは限らない。
• 最後のスライドで、MCPのない道具の操作、記憶と動画からの学習、人による承認を振り返る。
• Email Ethanの外部送信には承認が必要という例を再掲した。
• 参加者の新しい回答を集計し、メールを送るところまでの完了報告はなかった。

Peter Yangが参加し、作業環境を確認する

元PMでBehind the Craftなどを運営するPeter Yangがスタジオに加わる。Grok Botを一人で営む事業に使っているという。チームはSlackとNotionを用意したが、GitHub組織にはまだリポジトリがない。

方針や新しい担当向けの説明をNotionへ書く案に、Laurenは「変化が速いので文書もすぐ古くなる」と指摘する。必要な説明を残しながら、早く試作品も作りたいという意見だ。

• Xプラグインを接続した新しいボット環境で始める。
• 画面共有に不具合があり、設定を直しながら説明する。
• まず市場調査ボットを作り、顧客の声を探すことにする。

調査ボットを作り、使う人と困りごとを考える

視聴者の名前案を採用した市場調査ボットに、出演者の最近のX投稿への返信をまとめるよう頼む。Peterは、誰が客で、何に困っていて、何を提供できるかの順に考えるよう勧めた。

面白い技術を見せたい一方、会社づくりにはアカウント作成のような地味な作業もある。AIでの開発を知らない人にも、何をする会社か分かるものを作ろうと確認する。

• 仮の会社名はship by Thursday。
• まだ視聴者全体を客として考えており、具体的な対象は絞れていない。

Xの返信には地域の事業や消費者向けの案が集まる

調査ボットは、地域の事業、技術に詳しくない人向けのサービス、消費者が楽しめる体験、他人の事業づくりを助ける仕組みなどに提案を分ける。塗装、小さな店、書籍販促、造園、カード取引、夕食配送などが挙がった。

ボットには数分ごとの進捗報告を頼めるほか、作業中に質問や変更を送れると紹介する。Grok Botの形をした鍋のようなハードウェアの案も出る。

• ここで集めたのはXの返信で、広い市場を調べた統計ではない。
• ミームコインは作らないと話す。
• この段階では候補を広く出しており、作るものは決まっていない。

ゲームの思い出から、試作品で議論する話へ

好きだったゲームを話すうちに、ボットへ仕事を割り振る感覚は戦略ゲームに似ているという話になる。LaurenのX名の由来や、Final Fantasy XIV、Age of Empires、StarCraft、家庭用ゲームの思い出も語られた。

仕事の話に戻ると、いまは案をすぐ動く試作品にして見せられると話す。Laurenは、その日のうちに直したり試したりできないかを、いつも自分に問うているという。

• 仕様書も使いつつ、早く触れるものを作って議論したいという意見だ。

飲食店の仕事を調べ、ポップアップ案を考える

Roshanは、コードを作る費用が下がっても、利用者が何に困っているかを知る必要は変わらないと話す。飲食店なら朝の予約・メニュー変更の確認、オーナーならレビュー対応など、具体的な仕事をボットに考えさせる。

既存店の運営を助ける場合と、新しい店を短期のポップアップで試す場合では、必要な支援が違うと整理する。ボットの返答にハートを付けると、その反応を受けて次の案を出す様子も紹介した。

• 家事、業者の手配、ボランティア調整も候補に挙がる。
• 飲食では、ポップアップ支援、地元店との協業、体験型の夕食、チケット制イベントを検討する。
• まだまとまっていない考えを音声で伝え、返答を見て絞っていく。

料理人探しと試作を分担する

地元の店やシェフと組んで短期イベントを開き、運営に使うソフトウェアを作る案を検討する。イベント管理、申込み、決済、時間帯や席の予約が候補に挙がるが、開催形式はまだ決まっていない。

チームは試作と候補探しを分担することにする。料理を作る人、来場者、会場を探すには実際の人と連絡を取る必要があり、その準備をするボットも作る。

• Laurenは試作、Mattは候補探しや方針の文書化を進める。
• 予約席を用意するか、カウンターで販売するかは後でも話し合う。
• ボットの作成・調整に使う公開テンプレートとしてDr. Eggbotを紹介する。

Dr. Eggbotを入れ、簡単な紹介ページを頼む

塗装やピアノ調律などの案も出るが、3日間で試す難しさを考えて、いったんポップアップ支援を進める。LaurenはSteveに話しかけ、Dr. Eggbotと協力して小さな開発チームと試作品を作るよう音声で頼む。

最初はGoogle Sheetsなどを使い、本格的なDBなしで試せるかもしれないと話す。紹介ページを作って登録が集まるかを見る案だ。Mattは料理人や店を探す担当を作り、X、視聴者の紹介、電話、メール、応募ページのどれを使うか考える。

• まず簡単なページで、事業の説明に反応してもらえるかを試す。
• 来場者を集める前に、料理を提供する店や人を探す。
• Dr. Eggbotは公開マーケットプレイスから導入した。

Steveを管理役にし、試作担当を作る

Dr. Eggbotに、SteveをChief of Staff兼補佐役へ変えるよう頼む。Laurenは主にSteveへ話し、そこから専門の担当へ仕事を渡す予定だ。試作担当には簡単なHTML/CSSの案を複数作らせる。

GitHubにはpop-upという空のリポジトリを作った。配信中に意図しない情報を入れる可能性を考え、当面は非公開とする。ボットの名前、役割、仕事を渡す相手もチャットで変更できると紹介する。

• 試作担当は視聴者の案からGrok Potと名付けた。
• 店への連絡に使う会社名、ドメイン、メールアカウントも必要になる。
• Mattは、考えていることを話して整理し、優先順位を決めるためにもAIを使う。

参考デザインを集め、自分たちでも開催する案に合意する

Laurenは紹介ページの参考を探させ、いくつかの案を比べる。チームは、自分たちでもポップアップを開き、その経験からソフトウェアに必要な機能を考える案に合意した。

開催者にソフトウェアを紹介するページと、イベントに来る人へ案内するページは分けて考える。ただし料理も会場も未定なので、先に店や料理人へ連絡することはできる。

Laurenは長く音声で話した後、理解した内容を自分の言葉で言い直すようボットに頼む。これで目的や前提が正しく伝わったかを確かめる。

• フライドポテトは会話で出た候補で、売るものとして決定したわけではない。
• 複数人の発言が混ざった指示でも、要約を読めば食い違いを見つけやすい。
• デザインの参考を集めてから生成を頼む。

ページを増やす前に、会場と提供者が必要

Steveは、先に会場、運営者、料理を作る人を揃える必要があると返す。チームも、実際に開催を進めながら必要なソフトウェアを見つけようと考え直す。

予約席で食事を楽しむイベントと、カウンターで買う形式では、必要な予約機能も準備の量も違う。負担の小さい形式も検討する。画面の試作は3案ができたが、この時点ではGrok Bot内でHTML/CSSを表示しているだけで、まだ公開していない。

• 開催形式によって、時間帯や席の予約が必要かどうかも変わる。
• 会場と料理人の確保は、コードを書くだけでは解決しない。

Peterの助言：支払いを確かめ、報告を定期化する

Peterは、一人で事業を営むなら、自分が好きな仕事を増やせるように考えるとよいと話す。内輪の議論を続けるより、早く実際の客に見せ、お金を払ってもらえるかを確かめるよう勧めた。

配信の視聴者が飲食店経営者とは限らないため、ページを誰に見せるかも大切だという。また、ソフトウェアが作りやすくなった分、会場や料理人を見つけるような難しい仕事にこそ代金を払ってもらえるのではないかと話す。

自身の運用では、登録指標や見込み先をボットに調べさせ、金曜に番号付きで報告させている。項目ごとに返答すると、ボットが次の作業を進める。最後に、人間も同じボットの会話へ参加したいと要望を出して退席した。

• 好意的な感想だけでは、買ってもらえるかは分からない。
• 毎回聞きに行く手間を減らすため、必要な報告を定期的に送らせる。
• 番号付きの報告なら、どの項目への返答かを示しやすい。

試作はGrok Pot、実装はTaterへ

最初のデザインは無難すぎるとSteveへ伝え、Grok Potに別案を作らせる。同時に、技術構成や本格的な実装を考えるTaterを作った。Grok Potには、比較して捨てられる試作を素早く作る役を続けてもらう。

ここで、モデルと、それを動かして仕事を進める実行環境の違いを説明する。簡単なHTMLはGrok Bot内で作り、本格的なコード変更はCursorの開発用の環境へ任せる予定だ。

• 画面の試作と、業務に使える実装では求める完成度が違う。

技術の候補と会社の目的を決める

Taterに技術構成を考えさせ、VercelとPlanetScaleを有力な候補にする。細部の議論に時間をかけすぎず、作業を進めることにした。

MattはNotionに、サンフランシスコで食のポップアップを開き、その経験をもとに運営ソフトを作るという目的を書く。ゲストとボットへ何度も説明するため、現時点の合意を短く残しておく。

• 技術と製品の担当も仮に決める。役職名には冗談も交じる。
• この文書は、今後の話し合いに応じて変える予定だ。
• 誤った情報を大量に渡さず、正しい前提を簡潔に伝えたいと話す。

ピンクの案を選び、リポジトリへ入れる

複数の案を見て、ひとまずピンクを使うことにする。正式なデザインは後で見直し、まずページをGitHubへ入れて公開する。

Slackでリポジトリを共有し、Grok Botにランディングページを作ってpushするよう頼む。ドメイン名やブランド名は、マーケティング担当のボットに考えさせる案が出る。

• 共通リポジトリができれば、複数の人とボットが変更を加えられる。
• 役職札を作る雑談も挟みながら、各自の作業を進める。

Vercelへの招待とGitHub接続を進める

ボットがドメイン候補を出すが、名前はまだ決まらない。Notionの会社説明を他のボットへ渡しながら、Vercel組織への招待、GitHubとの接続、アカウント登録を進める。

最初にできたのは、スタイルを同じファイルへ書いた簡素なindex.htmlだった。人がメールで招待を確認する間は、配信の画面共有を切り替えている。

• コードのほかに、アカウントと公開先の権限も用意する。
• 設定や命名を分担するため、運営担当とCreative Directorも追加する予定だ。
• 画面共有には断続的な不具合が起きている。

初めて公開できたが、登録はまだ保存できない

Vercelで最初のデプロイができた。ページは表示されるものの、登録フォームのデータを送る先は未実装だ。最初はGoogle SheetsやNotionのDBを候補に挙げる。

Notionに保存するよう指示した後で、後日作り直す手間を避けるため、最初からPlanetScale Postgresを使うことに変える。決済は後回しにし、先に必要な機能を絞った。

• この時点ではページ表示までを確認しており、申込み保存の動作確認はまだできていない。
• Notionへの保存案は変更され、PlanetScaleへの接続準備を進めることになった。

DBの認証を待つ間に設計を進める

会社方針と見込み客探しの準備、HTMLページ、DB接続の三つが並行して進んでいると振り返る。予定のゲストが来られなくなり、その時間も制作に使う。

DBの認証情報を待つ間は、テーブル設計や依存関係の準備をするよう頼む。Taterには、今後の実装でCursor Cloud Agentsを使うよう伝えた。

• Grok Botで依頼や進捗を整理し、コード変更は開発向けエージェントに任せる。

Cloud Agentsで開発し、動作の様子を返してもらう

Cursor Cloud AgentsはVMを持ち、アプリの起動や操作、CPUトレースなどの検証もできると説明する。既存のリポジトリでも、起動に必要な環境を用意させられるという。

長い開発の経緯を残すため、Projectを作って追加の実装依頼を送る方法を試す。この方法を続けるかはまだ決めていない。DBの認証が揃うまではクラウド内で作業し、動画かスクリーンショットを返すよう頼む。

• CPUトレースなど、説明した機能のすべてをこの区間で試したわけではない。
• 公開を待つ間も動作確認を進め、その様子を見せてもらう。

会社用ドメインを取得し、レビュー担当も考える

会社用ドメインを取得したと報告する。会社紹介と製品のサイトは分ける案が出た。MattはDr. Eggbotに開発用のスキルや連携を入れさせ、会社紹介ページの制作も準備する。

Laurenは、作られたPRを見て、今回の短期実験では当面mainへ直接反映するよう指示する。その後、大きな差分を確認し、実装とは別にレビュー担当のボットを作ろうとする。ここで配信機材の調整のため一時中断した。

• mainへの直接反映は、この場で速く進めるために決めた手順だ。
• 約2,000行の差分に言及したが、レビュー完了の報告はない。

集客と販売を見るダッシュボード

事業の売買や成長支援に携わるゲストが、書籍発売に向けて使っているダッシュボードを見せる。Vercel上で参加者数、広告と自然流入、経路ごとの獲得費用と注文額などを見られるという。

Pulseという別のダッシュボードも紹介するが、接続直後の音声が一部欠けており、詳しい機能は確認できない。

• 資料には登録者数135,355と表示されている。
• 普段使っているものの紹介で、この場で新たに制作したものではない。

開催準備と、客が買うかを分けて考える

チームは飲食ポップアップを開き、その運営ソフトを他の人にも提供したいと話す。ゲストは、会場や手続きを用意することと、実際に人が来て席が埋まることを分けて尋ねる。

チームは運営を先に考えており、法務面はこれから相談する段階だ。ゲストは、事業を決め切る前にまず3人へ売れるかを試し、客を集める方法を考えるよう勧める。

• 許認可や法務の問題は、この時点では解決していない。

Xの投稿で知ってもらう

ゲストは、大勢が見ているこの配信には集客上の有利さがあると指摘する。その前提がない場合にどう客を集めるかを考え、議論を呼んだXの投稿やAIで作った動画の例を見せる。

• この後、投稿への反応が応募や登録にどう影響したかを話す。

投稿への反応を、応募や登録につなげる

ゲストは、AI生成の映像や、意見をはっきり示した投稿を紹介する。批判を含む反応もあったが、採用への応募や書籍の登録を得られたという。投稿前に、見た人に何をしてほしいかを決めておくよう勧める。

• 再生された後に、応募や登録が起きたかを見る。

まず自然投稿で試し、広告を加える

最初は客の特徴も、反応してもらえる表現も分からない。ゲストは、まず自然投稿を試し、どんな人がどんな言葉に反応したかを知ってから広告を加える方法を提案する。

よく反応された投稿をボットに見せ、目標を伝えて、その投稿がどんな順番で話を進めているかを学ばせる案も出る。

• 参考にするのは投稿の構成で、表現をそのまま写す意図ではない。

任せた後も結果を見て指示を直す

ゲストは、優秀な人を採用すれば後は任せればよい、という助言に異を唱える。人にもボットにも、期待する仕事を明確に伝え、結果を見て繰り返し直す必要があるという。マーケティングなら、実際の売上や顧客にもたらした成果で仕事を評価する例を挙げた。

• 評価に使う指標としてAOVやLTVに触れるが、ここで具体的な指標値を計算する実演はない。

客に知ってもらう方法と、実績の記録

ゲストは、製品を作りやすくなるほど、客に知ってもらう方法が重要になると話す。継続した入金と集客を重視し、制作過程を公開することも、その方法の一つだという。

顧客の好意的なコメント、動画の再生数、スクリーンショット、成長の記録をProof vaultとして集める案も出す。内容を確かめたものか、公開してよいものかを分けて保存する。

• 集めた記録を、製品や事業を説明するときに使うという提案だ。

ボットを作る前に、事業の目標を決める

マーケティング用のボットを作る話になると、ゲストは名前を決める前に目標を尋ねる。チームにはまだ予約や決済の仕組みがないため、まず見込み客のメールアドレスを集め、購入する意思があるかを確かめることにする。

• 約3:09の画面ではLead Captureというボット名が見える。
• この時点では、登録を集める仕組みや予約・決済の完成は確認できない。

成功事例を調べ、自分たちの案を直す

Imitate → Iterate → Innovateという言葉で、既存の事例から学び、直しながら自分たちの案を作る考え方を紹介する。サンフランシスコの有力な飲食事業者、よくできたWebサイトやポップアップのページ、直近6〜12か月の他都市の成功事例を調べる案だ。

ホストは別のボットを作れるボットへ、Operator Research Botの作成を頼む。Notionにある会社の説明も渡し、今回の事業に関係する点を調べさせる。

• 都市、件数、期間を指定して調査を頼んだ段階で、調査結果がすべて出たわけではない。

客が参加したくなる理由を書く

飲食ブランドの初期事例を参考に、短い見出しで参加したくなる理由を伝える案を出す。限定性、希少性、タイミング、その人との関わりを考えるという。

大きなロゴを見せたいという企業側の希望より、客が何を得られるかを考えるよう話す。自身の経験では、自然な会話や実際の事業現場を見せる広告が、企業らしく整えた広告より良い結果になったという。

• 広告の結果については、ゲスト自身の経験を紹介している。

小規模事業者には、どう売上が増えるかを伝える

従来型の小規模事業にAIを売るなら、その店や会社がどう収入を増やせるかを先に考えるよう助言する。導入後すぐに売上へ影響するかが見えないと、必要性を伝えにくいという見方だ。

• 利益率に関する数値らしき発言は聞き取りが不確かなため、ここでは記載していない。

メール登録のお礼に役立つものを渡す

ゲストは、見込み客に役立つ情報や診断・調査結果を用意し、メール登録のお礼に渡すLead magnetを提案する。自分たちの事業に近いテーマで複数の案を試し、登録後も役立つ情報を届ける考えだ。

• ゲスト自身の診断サービスの例では、Claude、Vercel、Replitを組み合わせたと話す。

対談をマーケティング計画へまとめる

ホストは対談の文字起こしをボットへ渡し、マーケティング計画を作らせたいと話す。ゲストは、良い製品を作ることに加えて、実際に客を集めて売ることまで考えるよう勧めた。約3:19:30から休憩に入る。

ポップアップと運営ソフトの両方を作りたい

午前の市場調査、視聴者の提案、ゲストとの対話を振り返る。サンフランシスコの飲食ポップアップで店と参加者を集め、その経験から他の人にも使える運営ソフトを作りたいという案だ。実際の開催方法はまだ決まっていない。

Taterが実装し、Hashbrownがレビューする

Laurenは、TaterのPRをHashbrownに確認させる方法を説明する。チーム全員が使えるようリポジトリにプラグインを置き、Slackに投稿されたPRを自動でレビューする仕組みを準備している。

まだ小さな事業なので、必要な手順から始めて、後で拡張できるようにしたいと話す。

• プラグイン名は文字起こしでP stackとされており、正式表記は未確認。
• 自動マージをどこまで行うかは、まだ決めていない。

ページ制作を分担し、エンジニア向け講習へ

別のホストがランディングページと見た目の設計を担当する。Grok Botで案を考え、Cursor Cloud Agentsで実装する方法を説明した後、エンジニア向け講習へ移る。

Lingxi Liが自身の開発手順を紹介

ソフトウェアエンジニアのLingxi Liは、約2か月間、自身の開発にGrok Botを使ってきたという。モバイル版を短期間で開発した経験を挙げ、普段の作業手順を紹介した。

補完、実装、自動起動、その先の監督

スライドでは、Autocomplete、Ask & Edit、Agentic Coding、Automations、Autonomous Codingという段階を示す。Cloud Agentで並行作業やイベントからの起動ができても、複数のエージェントを人が見続ける負担は残る。

Lingxiは、その監督をGrok Botに任せる。進捗を確認させ、追加指示や軌道修正を行い、必要なら作業を中断させる構成だ。

専用ツールでCloud Agentを起動・監督する

Lingxiによると、Grok Botは専用ツールでCursor Cloud Agentsを起動し、履歴や進捗を読める。作業を始めるたびに画面を操作する必要はない。

完了報告に画像や変更前後の性能比較が足りなければ、ボットがCloud Agentへ追加を求める。private workerやMacでの実行にも触れた。

• 紹介スライドの4項目は「Fully Autonomous AI Agents」「Connect to tools you use」「Manage Cursor Cloud Agents」「Memory & Routines」だった。

接続したツールを使い、以前の指示を次回も適用する

Vercelのビルド失敗を調べる、指定した時刻にデプロイする、といった使い方を紹介した。ボットが以前の注意や好みを覚え、次の依頼にも反映するという。

役割ごとにボットを分ける理由の一つは、それぞれに必要な情報を絞るためだ。関係の薄い仕事を同じボットへ詰め込みすぎないようにする。

• この区間は機能の紹介で、デプロイの実行結果は示されていない。

手元のPCを閉じても動かし、認証時は人が操作する

Lingxiは、ボット側のコンピューターで処理するため、手元のノートPCを起動し続ける必要がないと説明した。複数のOSやモバイル端末から利用できるという。

ログインや認証などで人の操作が必要になったら、ボットのコンピューターへ遠隔でアクセスする。人が作業を再開させられることも重視していた。

不在時のレビューと不具合対応

Slackの依頼やメンションを監視し、決めた基準に沿ってレビューする例を挙げた。画像と、動作を確かめられるテストを求め、人の承認が必要な場合はスマートフォンから確認する。

不具合の報告を受けたら、現在のmainでも再現するか調べ、再現すれば修正PRを作る。セキュリティの確認や適切なレビュー担当への連絡にも、ボット同士の会話を使う。

• Xの不具合報告にも触れるが、収集経路の説明にはSlack連携が混在しており、経路の詳細は不明だ。

製品方針と難しい設計は人が考える

製品の方針、細かな設計、難しい性能問題、次のアーキテクチャは、引き続き人が考える。ボットは要望を受け入れすぎることがあるため、実装しないことと、その理由も伝える。

認証で止まった作業を再開させるのも人の役割だ。任せる範囲と、人が判断する条件を決めておく。

夜間にコードを監査し、整理する

Lingxiは通常、午前3時に監査を始めるという。ほかの変更と衝突しにくい夜間に、コード品質、分割の不足、長すぎるコメント、セキュリティの問題を調べ、PRを作らせる。

自動で統合する場合も、あらかじめ決めた条件と、一連の動作を確認した証拠を求める。

• 後の実演では、テンプレートの通常の起動時刻を午前4時と説明している。自身の運用時刻とは異なる。

SlackのメンションからTestFlightへ登録する

メールアドレスでTestFlightにユーザーを追加する社内業務を例に挙げた。Slackでボットをメンションし、メールアドレスを渡すだけで登録を頼める構成だ。

この方法なら専用のダッシュボード、データベース、認証画面を作る手間を減らせる。ボットには、必要なTestFlightへのアクセスを与える。

• 実行の様子は示さず、普段の運用例として紹介した。

CIやデプロイの失敗に対応する

CI、デプロイ、統合テストの失敗を検知したら、ボットが調査用のCloud Agentを起動する。修正後は決めた条件に従って統合し、一定時間内に解決できなければ当番担当へ知らせる運用を紹介した。

• 当番担当へ通知するまでの時間として、10分を例に挙げた。

担当を分け、それぞれの記憶と手順を絞る

チームにはChief of Staff、UI担当のCraig、DevX担当のSteve、Infra担当のHogan、Ops担当がいる。同じモデルを使っていても、担当によって必要な情報や手順は異なる。ボットごとに記憶を蓄積し、コンテキストを使い切らないようにする。

人は主にChief of Staffと話し、専門のエンジニアボットへ依頼を振り分けさせる。Chief of Staffが個々の実装手順まで覚える負担も減る。

実演1：既存ボットが新しい監査担当に手順を教える

MarketplaceからNightly Audit Engineerを追加し、既存のエンジニアボットに仕事の進め方を教えさせた。Notionのボード、完了の定義、仕事の各段階をボット同士で確認する。

通常の起動時刻を待たず、その場で監査を始めさせる。結果を待つ間に、別の不具合調査へ進んだ。

• 新しい監査担当をSteve、既存の担当をCraigと名付ける。

実演2：予約済みの航空便を見られない問題を調べる

FlyLoで以前予約した便を確認できないという報告を調べた。ボットがブラウザーを操作し、約4:26に、ナビゲーションからリンクされている/tripsが未実装のstubであると報告する。

このようにMCPで扱えない作業にもコンピューター操作を使う。ただし「急いで」とだけ伝えると、ボットが手順を省略して推測する恐れがあるとLingxiは指摘した。

• この区間では修正の完了を確認していない。サイト名の綴りにも自動文字起こしの揺れがある。

実演3：Ops Botが共通手順書を管理する

Ops担当のボットを追加し、Notionのplaybookを管理させる。ほかのエンジニアボットは直接書き換えず、変更はOps Botを通してチームへ知らせる構成にした。

実演4：P0では5分ごとに進捗を確認する

緊急対応のP0では、ボットが5分ごとにCloud Agentの進捗を調べるよう指示した。目的から外れていないか、不必要に長く待っていないかを確かめ、必要なら途中で指示を出し直す。

このルールをCraigからOps Botへ伝え、playbookに追加して他のエンジニアボットにも知らせた。

• sleep 300で長く待つ例を挙げた。テストの完了を待つ際の無駄を減らすための監督で、テストを省く指示ではない。

実演5：PRに画像や性能の計測値を添付する

UI変更にはスクリーンショット、性能改善には計測値を添えるルールを追加した。PRを受け取った人が結果を確認できるようにし、証拠の追加を毎回頼む手間を減らす。

夜間監査ボットからコード整理のPRが返ってきた。一方、別の作業はまだ進行中だった。

• 一部のPRは用意されたが、すべてが統合されたわけではない。

タスク台帳を参照して並行作業を管理する

一つのボットへ何度も割り込むと、仕事が増えてコンテキストを保てなくなることがある。Lingxiは、Marketplaceのエンジニアボットに付くNotionのタスクDBへ作業と段階を残し、次に何をするか決めるときに参照させている。

レビューにはBugbotやセキュリティの確認も使う。登壇前から動かしていたCloud Agentの結果には画像が添付され、レビューに使えると説明した。

• タスク台帳は、ボットが全作業の状態をコンテキストに置き続けずに済むようにするためのものだ。

講演のまとめ：教えた手順を使い回し、結果を確かめる

社内の事情をまだ知らない有能なインターンに教えるように、目的と求める品質を伝える。同じ指示を繰り返しているなら、手順書に残すか、ボット同士で必要な連絡をさせる。

作業を続けるか、PRを統合するかを判断するには、成功と失敗を確かめる方法が要る。Webでは画面を操作して確認し、ハードウェアでは計測信号を見るなど、対象に合った検証方法を用意する。

Slackへの投稿をきっかけにPRをレビューする

レビュー用のSlackチャンネルにPRのリンクを投稿すると、Cursor Automationsが正しさ、リスク、足りないテストを確認する。現時点では単純なプロンプトで、これから調整すると説明した。

不具合報告のチャンネルも用意する。将来はXなどの意見を集め、調査して修正PRを作るところまで自動化したいという。この時点ではアプリも小さく、運用を作り始めた段階だ。

• 画面共有が切り替わらず、固まる場面があり、一部は口頭で説明した。

事業の目標と各ボットの担当を確認する

サンフランシスコでポップアップの参加者と運営者を集め、その準備に使うソフトウェアを製品にしたいと説明した。3日目までに収益を得ることも目指すが、実現できるかは分からない。

GitHubの組織とリポジトリを接続し、ランディングページのデザインを進める。Operator Research Botは対談で助言された類似事業や店を調べ、Dr. Eggbotは他のボットを作る。

• GitHubの認証とリポジトリの権限設定には、人の操作が必要だった。

ボット自身が動作確認できる道具を作る

アプリを起動してクリックする確認を毎回人に頼むと、その間は作業が止まる。そこで、起動、トレース取得、スナップショット、不具合調査をボット自身が行える検証スキルを作ろうとする。

検証スキルには、アプリを安定して操作する共通CLI・スクリプトと、機能への移動方法やショートカットを記すfeature mapを用意する。同じ道具を使えば、ボットごとにスクリプトを書き直すトークンを減らし、検証を再現しやすくなる。

• Cloud Agentにcreate verification skillを依頼したが、この時点では完了していない。
• プラグイン名の自動文字起こしはPStack/Peace stackなどに揺れ、正式な綴りは不明だ。

LPと参加希望者の登録フォームを試作する

LPのデザインを簡潔にし、参加希望者のメール登録を主な入口にする。店や協力者の連絡先も別に受け付ける案だ。フォームはデータベースにつながっているというが、集める情報は考え直している。

登録内容をPlanetScaleで確認する方法や、Resendなどでメールを送る準備を話す。ただし今のフォームは使い捨ての試作なので、まだ送信しないよう視聴者に呼びかけた。

• 4:52:28にドメイン公開への言及がある。その後もUI、フォーム、認証の修正は続く。

機能を挙げるうちに、作業範囲が広がる

イベント名、日時、会場、スタッフ、招待、参加者管理、所有者・ホスト・参加者の権限を挙げる。会場の地図や調査まで含めると、それぞれが一つの製品になりそうなほど範囲が広がる。

そこで、自分たちで開催の準備を進め、困った仕事を楽にする道具から作ることにした。スキルを書くときも、まず手動で仕事をしてから自動化するとLaurenは話す。

• 必要最小限の機能や予約枠の方式は、まだ決まっていない。

店や協力者の連絡先を調べる

店、ケータリング会社、会場の候補をボットで調べ、人が連絡する案を考える。過去に音声エージェントと連携した話も出るが、ここで自動電話が行われたわけではない。

連絡するときの基準として候補日を10月15日に仮置きし、Notionへ記録する。サンフランシスコとベイエリアで候補を調べ始めるが、日程は後で許認可の都合から再検討する。

• ドメイン、DNS、メールの設定も並行して進める。
• GitHubリポジトリにアクセスできず、接続先やCLIで解決できないか検討した。

会場を探して連絡できるツールを試作する

Laurenは、地図で会場を見て、場所や料理の種類で検索できる内部ツールを依頼した。必要に応じて店の担当者も調べ、すぐに連絡できるものを考える。まずは実際の会場探しと電話に使えることを優先する。

長い音声プロンプトを送った後、実行前に依頼内容をボット自身の言葉で言い直させた。地図にはGoogle MapsとOpenStreetMapを挙げ、実装に必要なキーの入手方法を考える。

• 会場のディレクトリや、開催後の評価を蓄積する機能も案に出たが、まだ実装していない。

内部用の試作を自分たちだけに公開する

会場探索の管理画面を、自分たちだけが見られるようにしたいと話す。GitHubやGoogleのログイン、Clerk、WorkOSを検討し、最初の試作ではVercelのdeployment protectionを使うことにした。

APIキーの作成や接続設定には人の手がかかる。配信の裏でも、こうした手動の準備が多いと話していた。

Notionに重要な情報を集める担当を作る

検証用のPRができ、人が読み始める。同時に、他のボットの活動から重要な情報をNotionへ集めるKnowledge Base Managerを作る。

最初は依頼されたときだけ動き、情報を追加する前に人へ確認するよう指示した。その後、会話で出た大事な情報が抜けていると気付き、5分ごとに活動中のボットへ聞き、必要な情報だけを記録する案に変えた。

• 細かな情報まで追加してNotionが読みにくくならないよう、記録する内容を絞ろうとしている。

コード品質の制約をいつ入れるか

lintなどの厳しい制約を最初に入れるか、事業の案が変わる可能性を考えて後で整えるかを議論する。Laurenは、コードの構造や技術スタックの制約がエージェントの書くコードにも影響し、記憶のように働くと説明した。

RustやGoも話題になったが、最終的にはTypeScriptを続けると発言する。作るものを確かめながら、必要な制約や整理を加える考えだ。

• 5:30:00には、実際の試作が素のHTML/JavaScriptであることに気付く。技術スタックの移行が完了したという話ではない。

チラシに何を書けば参加したくなるか

チラシの見出しを考えながら、何を売り、なぜ参加してもらえるのかを問い直す。新しい体験、限定性、物販、対面のゲームや交流、良い料理といった案が出た。

通行の多い場所の候補、チラシ、マーケティング計画をボットに作らせるが、最初のデザインには満足していない。サイトのコードを参照し、チラシにも同じデザインを使う案が出る。

• 広告の掲示、物販、集客の結果はまだ確認していない。

PRに動画がなく、添付するルールを追加する

会場探索ツールが動く動画を求めたが、PRには入っていなかった。レビュー時に操作の様子を見られるよう、検証スキルを常に適用し、UIを変えたPRには画像・動画を添えるルールを追加する。

バックエンドの変更についても、動作を確認するよう求めた。

• Cloud Agentsが動画を作れることと、今回のPRに動画が付いていることは別だ。実際には追加を頼む必要があった。

接続と認証に時間がかかる

Resendのドメイン検証は進んだが、GitHub CLIの認証や接続の問題は続く。LPと会場探索ツールは、まず動くところまで進め、その後で直すことにした。

• 5:26:22〜5:26:24には、作業を切り替えるうちに、どのAPIキーを設定していたか分からなくなるという発言もある。

人数、費用、許認可から会場条件を考える

規模を仮に約100人とし、会場の環境や参加者の体験を調整できる場所を探す。知っている良い会場を例に挙げ、似た場所を探すようボットへ伝えた。

費用、飲食や酒類、行政手続き、申請期間を調べると、1か月後の開催では間に合わない可能性も出てくる。必要な許可を持つ業者や会場を探す案も話した。

• 許認可は調査の途中で、法的な要件を確定したものではない。
• 候補日、人数、会場はいずれも仮置きだ。

アート展示も候補に入る

メニューを考えるうちに、飲食イベントではシェフ、スタッフ、会場、許認可の準備が複雑だと改めて気付く。アート作品を募り、会場とオンラインの両方で楽しむ展示の案が出た。

5:40台以降、アートポップアップへの変更をボットに伝え、広い倉庫のような会場を優先する。支払い方や運営方法はまだ議論している。

• 作品の制作やイベントの実施に進んだ段階ではない。
• PM講演に出演するホストが、約5:42に席を外す。

会場探索ツールに何を足すか

地図検索は既存サービスを使い、会場の規模など、既存の検索では扱いにくい条件を加える案を考える。電話で聞いた情報をCRMのように保存すれば、次の検索にも使える。

人が調べた候補とツールが出す結果を比べ、実際に会場探しに役立つかを確かめようとする。

• 電話で得た情報を蓄積する機能は、まだ構想の段階だ。

試作のPRが増え、レビューが追いつかない

複数の試作を頼んだため、PRが並行して作られ、レビュー待ちが増えている。実装担当とレビュー担当は動いているが、画像や動画がなく、何ができたか分からないPRもある。Steveに確認できるところまで進めるよう頼む。

登録後の確認メールを送り、登録内容をデータベースへ保存する作業も続く。ユーザーが使える状態かどうかは、まだ確認できていない。

• PR番号の音声が一部不明瞭なため、番号ごとの完了状況は特定できない。

テンプレート投稿企画を案内し、PM講演へ移る

Grok Botのテンプレート投稿企画と、選出者のStarbase訪問を案内した。PRの状態を確認しつつ、プロダクトマネージャー向けの講演へ切り替える。

• 企画の条件と賞品は配信当日の案内による。

誰のために、何を優先して作るか

Kevin Niparkoらは、Grok Botを使ってGrok Botを開発する製品チームの経験を紹介した。DHHの言葉を引き、何を、誰に、どのように作るか、どう見せ、何を優先するかは、製品を作る全員が考える課題だと述べた。

Slackや業務ツールで働ける同僚を作りたい

コード以外の仕事もエージェントへ任せるようになると、チャット欄だけでは使いづらくなったという。Slackで連絡でき、チケットやNotionも読める同僚のような存在が欲しい。この社内の要望からGrok Botの設計が始まったと説明した。

同僚の働き方から考えた4つの性質

複数のツールを使って働くこと、業務の背景を時間をかけて覚えること、必要な権限と環境を持って独立して進めることを挙げた。ボットにも長期記憶と作業用のコンピューターを用意し、同じように働いてもらう設計だという。

4点目は、作業の途中でも指示や補足を送り、続けてやりとりできることだ。同僚へメッセージを送るように、進行中の仕事にも指示を加える。

時間の使い方、調査、製品の出荷を支援する

返答を待つ間にも割り込んで指示を変えたり、別のスレッドへ移ったりできる。組織の事情を覚え、自分で仕事を進めて結果を返す同僚を目指すと説明した。

PM向けには、時間の使い方と優先順位を比べる、顧客や利用状況を調べる、製品の変更を届ける、という三つの用途を挙げた。社内では、マージ済みPRの二桁の割合にGrok Botが関わっているという。

• Attention listでは、何に時間を使ったかを振り返り、本来の優先事項に取り組めているかを確かめる。

データ、製品、設計、開発の担当を分ける

CoraはChief of Staffとして、メール、カレンダー、SlackからPMの仕事を把握する。Emilyは5体の開発担当を管理し、大きな依頼を分けて検証まで調整する。AshleyはSQL、データ探索、図表、分析を担当し、PM Peteは顧客の声と仕様を整理する。

デザインはPixel、採用はRaeが担当する。専門ごとに分けると覚える情報を絞れ、人も誰に頼めばよいか分かりやすい。複数のボットへ同時に頼んだり、担当の重なる仕事を相談させたりできる。

• ここではチーム全体を紹介するが、全担当の仕事を実演したわけではない。

Flylo Airlinesの購入データを調べる

Notion、Slack、Figma、Gmailなどを接続したデモ環境を紹介した。開発者のグループ、Engineering・Product・Designのグループ、障害対応のグループなど、仕事に合わせて会話を分けている。

Ashleyに前日の購入をWebとモバイルで比べるよう頼むと、接続先へクエリを送り、結果を返した。デモの数字では購入は約1,400枚で、Webが約58%、モバイルが約42%だった。続いて、家族利用などの分類を図表にするよう頼んだ。

• Flyloと数字はデモ用で、実在する航空会社の業績ではない。
• DatabricksとSnowflakeは接続先の例として挙げており、このデモの接続先を特定したものではない。

集計を定期的に受け取り、グラフの読み違いを直す

毎朝ダッシュボードを巡回する作業を、ボットから集計が届く形に変える例を紹介した。発売直後なら、もっと短い周期で見ることもある。実演では家族客の割合を示すグラフを作り、毎朝6時に報告するよう指示した。

モバイル購入のグラフを見た人は、座席選択で大きく離脱していると考えた。しかしAshleyは、問題は検索から運賃選択までの段階だと訂正した。人の読み違いを確認したうえで、改善案へ進む。

• 定期報告の頻度は用途に応じて決める。後のFounders講演では、実行回数を増やしすぎたときの費用も話題になる。

仕様からデザインと試作を同時に頼む

Ashleyが分析結果をPM Peteへ伝え、PeteがNotionにP0/P1/P2の要求をまとめた。何を優先して実装するか判断でき、そのまま試作に着手できる仕様を目指す。

運賃比較や表示の改善案には、人の知識を加えたり、Notionのコメントで直したりする必要があると説明した。今回はデモなので早く進め、Emilyに試作、Pixelにデザインを並行して頼む。

複雑な操作を録画して教えるTeach a taskも紹介した。繰り返し使いながら手順を直し、仕事を覚えさせる方法だ。

• このデモでは一度で先へ進めたが、実際の仕事では確認や修正を繰り返す。
• NotionやGoogle Docsのコメントでも修正を依頼できる。

人が選んだA案をEmilyへ渡す

PixelにはFigma上のデザインシステム、色、フォント、避けるUI配置を教えてある。依頼のたびに一から説明せず、会社の基準に沿って案を作らせる。

Pixelが二つのモックを作り、会場の拍手でA案を選んだ。その選択を、すでに試作を進めているEmilyへ伝えて更新を頼む。作業の途中にも、人が決めたことを追加で渡せる。

Emilyが実装を分け、確認まで調整する

Emilyは仕事を担当ごとに分け、目的と必要な情報を渡す。実装担当はリポジトリのコピーを持つCloud Agentを起動し、コードを変更して実行・テスト環境を準備する。NovaがPRを作ることへの確認を受け、クラウドで作業を始める様子を説明した。

実装後は担当ボットがレビューし、QAやマネージャーが追加で確認する構成にもできる。変更の重要度によって人の関与を変え、必要なら動く試作品やデモを見て判断する。

• この時点では開発がバックグラウンドで進んでいる。
• エージェント自身が検証できる環境と、人が結果を見られる証拠を用意する。
• 同じ担当分けを、複数のリポジトリや複雑な依頼の管理にも使えると紹介した。

仕事を教え、必要なときだけ通知させる

ボットを使い始めたら、スキル、業務の情報、操作のしかたを教える期間が要る。長く担当させ、使いながら修正する方法を勧めた。

定期実行で重要な変化がなければ通知せず、ボットが解決できる仕事は処理させる。メールも緊急・重要なものだけを知らせる例を挙げた。最後に、管理役の下に担当ボットと開発エージェントを置く構成を振り返る。

• テンプレートのコンテストを案内した後、会場の質問に答えた。

Q&A：個別の記憶と共有メモリープール

担当の重なるボットが情報をどう管理するかという質問に、各ボットの記憶に加え、チームで使う共有メモリープールがあると回答した。どちらへ記録するかは、ボットの判断と内部の指示で調整するという。

開発と設計を一つのボットに任せることもできるが、複雑な仕事では担当を分けると扱いやすいと説明した。利用者がコンテキストの量や圧縮を常に気にせず、仕事を頼めるようにしたいという。

• ここでの共有メモリーと、Founders講演の共有ファイルは別の説明だ。配信だけでは関係を確定できない。
• 6:33:16から約8分間の休憩に入る。

何を作るか、まだ決まらない

PM講習から戻ったチームは、最終的に何を作るか、どんなソフトウェアが必要か、まだ合意できていないと認める。Karat FinancialのEricが参加し、誰のどの問題を解くのかを聞き直した。

ポップアップには、人と直接会え、その期間だけの体験や商品を楽しめる良さがあると話す。Ericも、配達アプリやオンラインで多くの店に埋もれず、自分たちのブランドを知ってもらう方法として評価した。

• 社名のKaratは、音声のCarrotから推定した綴りで、正式表記は未確認だ。

初開催の人と、既存店の販促を分けて考える

Ericは、開催経験のない自分たちと、すでに店や商品を持つ事業者では必要な支援が違うと指摘した。まずは技術ブランドが人を集める、自分たちと同じケースに絞る案を出す。

誰にでも使えるページを先に作ると、具体的な困りごとを取りこぼしかねない。Grok Botのグッズを売る催しなら、商品、参加登録、会場を先に整えればよく、飲食で考えていた細かな時間帯予約の優先度は下がる。

• 友人の参加が分かるようにするなど、参加登録を促す案も出た。
• この方針も暫定的なもので、終盤には再び考え直す。

担当を分け、tldrawで画面の案を描く

Mattは成長担当、創業エンジニア、画像生成、Creative Director、Chief of Staffなど、必要な役割ごとにボットを作っている。幅の広い仕事は職能で分け、文書更新のような独立した作業には専用担当を置く。

Laurenはブラウザーを操作させ、tldrawに簡単な画面案を描かせていた。参加登録、商品、会場の選び方を図で見ながら考える。グッズを売ることが、人の集まる理由になるという話も出た。

• 商品には、帽子、質のよいパーカー、愛着の湧くぬいぐるみなどを挙げた。

使いたい物と、面白くて欲しくなる物

Mattは、自分が使いたいと思う質のよい帽子やパーカーが好きだと話す。友人にもらったカビゴンのぬいぐるみは、子供の頃の思い出がよみがえって嬉しかったという。商品を考える基準として、実用性と新しさが挙がった。

Ericはタングステンの塊の重さが面白いと話し、Grok Botの形なら欲しいという話へ広がる。その場で価格を調べると、想定していた販売価格では難しそうだ。少数の特別品や抽選の景品にする案も出た。

• 80ドルなら欲しいという声があった一方、調べた球形の商品は500ドルだった。製造見積りを取った段階ではない。

チャットQ&A：共有テンプレートと担当範囲

他人のボットを使うと過去の学習も引き継ぐか、後から直せるかという質問が来た。共有テンプレートには役割、指示、一部の情報、連携が入り、それを基に自分用のボットを作るという。個人のチャットや秘密情報は引き継がないと説明した。

任せすぎているかは、返答が目的に合っているか、出力の質が落ちていないかで判断する。必要なら担当範囲を狭めたり、コンテキストを整理したりするよう勧めた。

• パスワードには専用の入力画面を使うとの説明もあった。
• 101で説明したボットの複製と、ここでの共有テンプレートでは、引き継ぐ情報の説明が異なる。

チケットを記念品にし、ボットを形にする

Laurenはカードの光沢を参考に、最初のGrok Botイベントのチケットを集めたくなる物にする案を出した。グッズにはストレスボール、帽子、各ボットのキャラクターのぬいぐるみを挙げる。

参加者が自分のボットをデザインし、その物体に機能を付ける案も出た。売上の節目で光る、ニュースを知らせるといったものだ。視聴者からはBuild a Bearのような体験にする提案もあった。

• 量産方法や価格はまだ調べていない。
• パートナーの位置情報を使う案も雑談で出たが、実装や実行はしていない。
• チケット、グッズ、会場は、それぞれ別のボットに検討させる構想だ。

自分たちの開催を先に進める

汎用プラットフォームを作り続けるのかという問いに、まず自分たちの催しに必要な道具を作り、他の人向けに広げることは追加目標にしようと話す。先に商品、催しの内容、会場を整える。

戻ってきたRoshanへ、商品、会場、チケットの三つと、それまでの案を説明した。会話を音声でボットにも渡し、文書を更新して全員が同じ情報を見られるようにする。

• この時点では物販型の催しに力を入れようとしている。
• 商品は、日常で使いたくなる品質と、新しさや楽しさで選ぶ。
• 普段使うGrok Botのキャラクターを、ぬいぐるみなどにする案がある。

仕入先を調べ、作れる商品に絞る

Grok Imagineでグッズの案を生成したが、ロゴや目の形が違い、修正が必要だった。仕入先が作れる物を調べ、よく作られた2〜3点に絞ろうと話す。

登録画面で好きな商品を選ぶ、3Dで見る、会場で記念チケットと交換するといった案も出た。印刷会社と会場を調べる必要があり、会場の一覧をNotionとSlackで共有する。

• 会場の一覧はできたが、予約は確認できていない。
• Alibabaなどで仕入先を調べ、見積りを交渉する案が出た。調達の完了には至っていない。

最初の顧客に合わせて作り、後から広げる

Ericは自社について、最初はクリエイターの事業向けに銀行・信用の仕組みを作り、共通する部分を他の事業者にも広げていると説明した。クリエイター同士が集まる催しなど、顧客の仕事を助ける活動も行っている。

ポップアップのソフトウェアも、自分たちのために使い始め、共通する機能を後から他の開催者へ広げられるかもしれない。技術に詳しい人に限らず、多くの小規模事業者にAIを使ってもらいたいと話した。

• 金融サービスはEricの自社紹介で、今回のイベント用製品に追加する機能ではない。

結果を確認できる仕事から任せる

創作の良し悪しは評価が難しいが、ブランド提携の仕事なら手順と結果を確かめやすいとEricは話す。候補探し、連絡、条件交渉、企画案の作成を担当ごとに分ける例を挙げた。

自分の業務から、結果を見れば成否を確かめられる一連の仕事を選び、ボットへ任せるよう勧めた。対話を終え、Founders講演へ切り替わる。

• ここで挙げたブランドへの連絡や交渉は、配信中には行っていない。

必要な作業を任せ、製品の判断に時間を使う

Shubは、同じ担当に長く仕事を任せ、経験を蓄積させる使い方を紹介した。さらに、職能ごとに分けたボットでチームを作ることを提案する。

創業者は多くの連絡に対応しながら、制作を進めて判断を続けなければならない。必須だが自分が最優先で取り組む必要はない仕事をボットに任せ、確認する情報を減らす。

定期実行、Webhook、イベントをきっかけに処理を始める仕組みを使えば、最初の顧客に行う手厚い個別対応も繰り返し任せられると話した。

• 創業者に加え、部門の責任者にも応用できる使い方として紹介した。
• 主な用途は顧客獲得、製品の変更確認、競合調査、顧客の要望への対応だ。

Close Bot：面談相手と利用状況を調べる

Close Botは、面談する相手の会社や製品、これまでの利用状況を調べ、話す内容を準備する。顧客の機密情報を出さないよう、デモにはNorthwindという架空の会社を使った。

無料利用や試用中の顧客なら、どんな人が何を使っているかを短時間で知りたい。カレンダーから面談予定を読み、事前調査を済ませておけば、直前に概要を読んで相手に合った話を始められるという。

• 過去の利用指標や面談情報をボットへ渡しておく。

サイトを確認し、面談で分かったことを次回へ残す

面談の準備資料はHTMLにまとめられていた。相手のWebサイトの画像、利用の推移、質問候補、リスクが並ぶ。送信ボタンにCookieの表示が重なっているなど、サイトの具体的な不具合を見つけて伝えると、相手にも役立つ会話を始められるという。

面談後はGranolaの文字起こしを読み、相手が何に反応したかを記録する。関心を示さなかった機能を次回も同じように勧める、といったことを避ける。

• 資料中の数字と利用状況はデモ用だ。
• 自分が面談前に読む短い内部資料なので、見栄えを作り込む必要はないと話していた。

問い合わせ対応と利用開始の支援も任せる

既存顧客のサポートもClose Botに任せる。Shubは、問い合わせを最後まで処理するには、データや請求に関する情報へアクセスできる必要があると説明した。任せる仕事に応じて権限を渡す。

デモでは、チームへテンプレートを共有する操作を検知したら、クレジットを付けてメールで知らせる例を紹介した。契約、見込み客の整理、日程調整も同じ担当に任せる。

• 1,000ドルのクレジットは、意図的に大きくした架空のデモ例だ。
• Shub自身が顧客と深く話したい場合は、その対応を自分に戻しているという。

Prod Bot：公開されている製品を実際に使う

Shubは、すでに削除された機能をデモ中に紹介してしまった経験を挙げた。変更が増えると、創業者自身も何が公開されているか把握しきれない。そこでProd Botに、公開・取り下げ・見直すべき細部をまとめさせる。

PRやLinearを読み、製品にログインして操作し、画像と動画を返させる。Flyloのデモでは、開発履歴と利用者が触る画面の両方を確認した。利用指標も渡せば、変更後に何が起きたかを日々の報告へ加えられるという。

• 画像や動画があれば、人が操作の結果をすぐに確認できる。

Stalk Bot：競合に登録し、製品の変化を調べる

Stalk Botは競合のサイト、変更履歴、Xの投稿、採用情報を調べる。実際に登録し、使い始めの手順や主な機能も確かめる。架空のメモ製品の競合としてCraftとNotionを選び、結果をHTMLと操作動画にまとめた。

数日ごとに変化を確認し、重要なものだけを知らせる。顧客が他社へ移ったと分かる場合は、その理由をメールで尋ねる案も紹介した。集めた情報を基に、自社が他社と何を変えるかを考える。

• 講演の最後にStalk Botのテンプレートを共有した。
• 個々の採用情報などは、配信時の調査結果だ。

Proto Bot：顧客の要望から試作とPRを作る

Proto Botには、別アカウントのGrok Botを操作できる環境を与えてある。現在の画面と動作を確かめたうえで、試作やQAを行わせる。Xやサポート窓口の声を集め、修正PRを作る運用を紹介した。

実演では、テンプレート共有ボタンをもっと目立たせてほしいというデモの要望を渡す。Cloud Agentが作業を始める間、Shubは、どの要望を採用するかを決めるのは創業者の仕事だと話した。

• 講演中は実装が進行中で、完成や本番への反映は確認できていない。

Yap Botは文体を学び、Misc Botは雑多な依頼を受ける

Yap Botはメール、Slack、iMessageから利用者の文体を学ぶ。他のボットが外部向けに書く文章も手伝う。慎重に扱いたいメールは下書きで止め、人が実際に送った文面との差を次の文章に反映するという。

Misc Botは音楽の発売など、雑多な質問を受ける。仕事に関係する発見があれば、必要な担当へ伝えさせる。顧客の声をClose BotからProto Botへ、製品の変更をProd BotからClose Botへ渡す例も紹介した。

• ここでのYap Botは、利用者らしい文章を書く担当だ。音声合成のデモではない。
• 専門のボットへ関係の薄い質問を持ち込まずに済むよう、雑多な依頼先を分けている。

1〜2時間かけて、任せたい仕事を書き出す

必要な道具と情報を渡し、期待とずれたら修正しながら同じボットを使うことを勧めた。仕事のしかたを教え、繰り返し使って改善する。

その準備として、1〜2時間かけて自分の仕事を書き出し、何を任せるか決めるよう提案した。完成してほしいものと手順が明確なら、同じ仕事を繰り返し頼みやすい。

• 「もっと良く」とだけ伝えるような曖昧な依頼では、期待した結果を得にくいと話した。

費用を抑えるため、操作と起動回数を見直す

直接の連携がない仕事でも、画面操作なら進められる。ただし同じ操作を繰り返すと、時間とトークンを使う。Shubは、使えるAPIや連携を優先すること、一度の操作から再利用できる処理を作ることを勧めた。ネットワーク要求を調べ、そこで使われるAPIへ直接アクセスする案も挙げる。

定期実行の間隔を短くしすぎないよう注意した。Webhookなどで変化を受け取れるなら、その入力から起動する方法もある。別のボットに実行頻度や繰り返す失敗を調べさせ、他のボットの手順を直す案も出した。

追加の工夫として、文体を覚える担当、ログインを維持するCookie、専門ごとの担当分け、よいスキルを紹介した。

• CookieやAPIを使えるかは、接続先の認証とアクセス条件による。
• Stalk Botを共有するQRコードを提示した。

Q&A：担当の分け方と複数コンピューター

まず業務を書き出し、財務、顧客対応、マーケティングなどの専門でまとめる。Chief of Staffを窓口にする方法もあるが、Shub自身は専門のボットと直接やりとりするほうが好みだという。どこまで自分で確認したいかによって選べる。

複数のコンピューターを使うとボットが混乱することがある、という質問も出た。Shubは改善中で、最近はよくなっているはずだと答え、動かなければ相談してほしいと話した。

• 複数コンピューターでの問題が、すべて解消したという回答ではない。

Q&A：決めた規則を必ず守らせられるか

企業で使う際に、モデルの外に必ず守る規則を置けるかと質問された。Shubはモデルの判断は決定的ではないと認め、規則をコードや決定木に書き、その判断では毎回関数を呼ぶよう指示する案を出した。

別のボットへ承認を求める方法や、フローチャートを参照させる方法も挙げた。ただし、モデルがいつ規則を呼ぶかは指示に従わせる運用であり、すべての動作をモデルの外から強制する仕組みは示していない。

• Shub自身も、完全に決定的な動作にはならないと述べている。

Q&A：他ツールからの移行と認証でのつまずき

MCP、API、スキル、認証の設定を一か所にまとめる方法を話した。共通の情報源、1Password、ブラウザーのセッションを使う例を挙げ、移行を手伝うボットも準備中だと答えた。

認証が通らないサービスや、ボットの利用を認めたくないサービスもあり、接続にはまだ課題があるという。Shubは、必要な文字起こしを取り出しやすいことを理由にGranolaを選んだ。使う道具を固定せず、必要な結果を得られる接続先を探す方法を勧めた。

• 会場の質問が聞き取れず、「まだない」という回答だけが残る箇所がある。質問の対象は特定できない。

Q&A：画面操作の速度、会話量、モデル、不要な記憶

UI操作をAPI並みに速くできるかという質問には、ヘッドレスブラウザーやDOM操作で画像を見て判断する回数を減らす方法を挙げた。モデルの改善も進めているが、処理が増える分、APIより速いと約束するのは難しいという。

グループに多くのボットを入れると、全員が積極的に応答して費用が増える。共同作業に使うか、一度だけ別のボットを呼べば足りるかを考えるよう勧めた。

開発向けCloud Agentではモデルを指定できる。また、不要な情報を何度も参照するボットには、その情報を忘れるよう伝えられるという。

• 101ではグループ会話の見やすさを実演した。ここでは費用と会話量にも触れている。
• モデルを選ぶ説明は、主にCursorやGrok Buildの開発エージェントについてだ。

Q&A：テンプレート審査、別アカウント、ローカル実行、記憶

マーケットプレイスに載せるボットは、人とボットで審査していると説明した。使う前に、何をどのように行うかを聞き、自分の用途に合うか確かめるよう勧める。別の人や別アカウントのボットとの直接会話は、現時点ではできず検討中だと答えた。

設定でローカル実行を有効にすると、自分のブラウザーや端末を操作できる。ただし作業中の画面を使われたり、計算資源を消費したりするため、クラウドでの実行を重視しているという。

記憶の共有については、各ボットのコンテキストと記憶は別で、ファイルを共有できると答えた。「1台のVMに複数のインスタンスやデスクトップがある」と説明している。一方、101では別ボットのコンピューターにアクセスできないと話しており、配信だけではどこまで分離されているか確定できない。

• 同じ利用者のボット同士の連携と、別の人・アカウントとの連携は別の機能だ。
• 101のコンピューターの分離、PMの共有メモリープール、Foundersの共有ファイルについて、説明の関係は確認できていない。

Q&A：Cloud Agentsにどの仕事を任せるか

Grok BotからCloud Agentへ必要な情報を渡し、実装の結果を受け取る。対象の環境へアクセスできれば、QAやPRの確認も行えると説明した。複雑な実装や本番に反映する変更、モデルを調整したい作業には、開発向けのCloud Agentを使うよう勧める。

何度か実際に頼んでみれば、Grok Bot内で済む軽い作業と、Cloud Agentへ渡す仕事の違いが分かってくるという。一度担当を明示し、その後も適切に委任させる。最後にコンテストを再び案内し、講演を終えた。

22体のボットで複数の事業を運営する

Jennyは育児をしながら、VC、メディア、不動産などの事業でGrok Botを使っていると話した。経営者の発信を支援するメディア代理店を作り、22体のボットを利用しているという。

Master Chiefを管理役に置き、受信箱を監視するBoxy、会議の記録を取り込んで仕事を配る担当、領収書と帳簿を扱う財務担当などを動かす。複数の担当にまたがる仕事では、グループで協力させている。

• Shubは専門のボットと直接話すほうを好むと述べたが、JennyはChief of Staffに管理を任せている。

会場の一覧はあるが、連絡も条件決めもこれから

Jennyが進捗を尋ねると、チームは会場の候補を挙げただけで、問い合わせや運営の検討はまだ進んでいないと答えた。100人程度か、それより多い人数が入る、開放的な倉庫やギャラリーのような場所を考えている。

Jennyは時期、酒の有無、食事の形式を聞く。チームの回答は、翌月かもう少し後、準備を簡単にするため酒はなし、温かい食事を出したい、という暫定的なものだった。会場を検索する前に、こうした条件をボットへ伝える必要がある。

• 事業づくりは72時間の目標だが、イベントをその期間内に開催すると決めたわけではない。
• 必要な許認可は、まだ調べていない。

開催時間、厨房、指定の業者を確認する

夜に開くか、会場の厨房を使うか、外部のケータリングを頼むかで、選べる会場が変わる。飲食業者が指定されている会場もあるため、よい空間を選び、その条件に料理を合わせる方法も考える。

Jennyは、全体をまとめるイベント企画ボットの下に、会場探しや調整の担当を置く構成を提案した。人のイベント制作チームと同じように、仕事を分ける考え方だ。

• 担当へ条件を渡し、適合する会場と空き状況を調べさせる。

予算を決めてから見積りと交渉を頼む

会場へメールし、見積りや空き状況を調べる仕事をボットへ任せる案を出した。予算と交渉できる範囲を伝えれば、条件のやりとりも頼めるという。Jenny自身は、衣服の再販売で交渉のルールを与えていると話した。

チームは予算をまだ決めていない。まず相場と制作費を調べるため、100〜200人のポップアップを企画する経験豊富な担当者として、予算案を作るようボットに依頼した。会場、飲食、スタッフの費用を含め、受付や警備には人手も必要だと確認する。

• マーケティング費用は会社全体の予算にもイベントの予算にも入れられるが、今回は別扱いにした。
• 会場へ見積り依頼を送ったことは確認できていない。

マイクとスピーカー、許認可の調査を加える

DJや大きな舞台までは要らなくても、参加者へ話すマイクとスピーカーは必要だと話す。会場に設備やスタッフが含まれていれば、別の業者を探す手間を減らせる。

追加する担当として、開催に必要な許認可や規則を調べるボットを提案した。都市によって条件が違うため、場所と開催形式に合わせて調べる。

• 基本的なAV設備として、マイクとスピーカーを予算に入れる。
• ここでは調査を依頼した段階で、実際の法的要件は確定していない。

契約を最初に読ませ、経験者が確認する

Jennyは、契約や規則をAIに読ませれば最初の整理に役立つが、地域や業界の慣行まで分かるとは限らないと話した。契約は経験のある人にも確認してもらうよう勧める。

人がその仕事をするときの役割と手順を理解し、それを基にボットの担当を決める。今回も、イベント経験のあるJennyの質問から、調べるべき条件が分かってきた。

夜間に調べて下書きし、翌朝に送るか決める

夜の間に候補を調べ、問い合わせメールを下書きさせる。翌朝、人が宛先と文面を見て送る運用をJennyは勧めた。

招待候補を探す例として、開催都市にいるフォロワーを調べる方法を挙げる。チームは配信を見ているXの利用者にも呼びかけられそうだと話した。開催を楽しみにするやりとりで対話を終えたが、運営方法はまだ決まっていない。

• その都市にいるフォロワーから、フォロワー数の多い上位50アカウントを探す例を挙げた。
• 問い合わせや招待の送信、参加の確定は確認していない。候補者の居住地を正しく調べられたかも、この場では実演していない。

残りの期間で作るものを絞る

初日は何度も案を変え、まだ変わるかもしれないと振り返った。ゲストの助言から多くを学べたが、残りの期間で必ず形にするものを、一つか二つに絞る必要がある。

ポップアップを事業にするか、再び考える

Slack、ボットによるNotionの更新、GitHub、Vercelの接続は進み、ランディングページとダッシュボードも作り始めた。ところが運営の条件を聞くと、ポップアップという難しい事業を本当に選ぶべきか、という疑問が出た。

夜にも考えを整理し、翌日に改めて何を作るか決めようと話す。会場の決定や売上、事業の成立を知らせる発表はなかった。

コンテストを案内して配信を終える

視聴者向けのボットテンプレート企画を再び案内し、翌日の再開を告げた。最後に映像の不調へ短く触れ、音楽に切り替わって配信を終える。

• この記事で扱うのは初日までで、2日目以降の結果は含まない。