Grok活用事例ダイジェスト
仕様解説
cursor.com/help — Grok Bot computer（Update／Recover／Reset・Disk Saver・Hidden Bots）en仕様
引用
The Grok Bot computer is shared by your bots. Files, logins, installed apps, and the browser live there. Chats are stored separately, so a computer problem does not delete conversation history by itself. … Update: Moves the computer to the latest version. … Computer update: Bots, files, and logins [kept]. … installed apps and packages [removed]. Recover: Saves what it can, then builds a new computer … Reset: Builds a new computer … from your last saved data. … Which should I try first? 1. Wait, then choose Retry … Do not Reset during this. 2. Fully quit Grok Bot and reopen it. 3. Update … 4. Recover … 5. Reset only after those steps. … Why does Update say Backup not ready? The computer's data is not safely backed up yet. … Do not Reset to force the update. … A disk warning is not data loss. … Disk Saver … asks before it deletes anything … Hide from sidebar removes a Bot from the list only. Hidden Bots stay active and keep their history.
日本語訳
Grok BotのコンピュータはBot間で共有され、ファイル・ログイン・インストール済みアプリ・ブラウザがそこにあります。チャットは別保存なので、コンピュータ障害だけで会話履歴は消えません。Updateは最新版への移行で、ソフトウェア更新ならアプリも残り、コンピュータ丸ごとの更新ではアプリ／パッケージが消えます（Bot・ファイル・ログインは残る）。RecoverとResetは保存済みデータから新しいコンピュータを組み直し、到達できないとごく直近の変更が失われることがあります。試す順はRetry → 完全終了して再起動 → Update → Recover → 最後にResetです。Backup not readyのときにResetで無理押ししないでください。ディスク警告はデータ消失ではなく、Disk Saverが提案し確認なしでは削除しません。サイドバーから隠したBotは動き続け、履歴も残ります。
コメント
伴走で多い「Botが消えた／チャットが空」は、まずHidden Botsと別端末の同一アカウント確認です。9/28のManage computers（Recreate／Terminate）とは別Helpで、こちらは日常の再接続と復旧手順に寄せています。
考察
復旧カードを渡すときは「Resetは最後／Backup not readyでは触らない／チャットはコンピュータの外」の三行で足りることが多いです。確信度: 公式help。
cursor.com/help — Approvals（会話中は待つ／Routine・他Bot経由は約10分で期限切れ）en仕様
引用
An approval card means the Bot stopped and is waiting. The action does not run until you choose. … Allow once … Always allow … Deny … An approval from a chat you are in waits for you. An approval from work that started without you, like a routine, a trigger, or a message from another Bot, expires after about 10 minutes. The card then shows Expired, and the action doesn't run. … Turn on Notifications for Bots that run routines. … Choose Always allow for actions you trust … Ask the Bot to try the task again after an approval expires. … Where do pending approvals show up? In the chat. … In the sidebar. … As a notification.
日本語訳
承認カードはBotが止まって待っている合図で、選ぶまでその操作は走りません。Allow once・Always allow・Denyがあります。今開いている会話からの承認は待ち続けますが、Routine・トリガ・他Botからの依頼など、自分がその場にいない仕事の承認は約10分でExpiredになり、実行されません。Routineを回すBotはNotificationsをオンにし、信頼できる操作はAlways allow、期限切れ後は再実行を依頼します。待ちカードはチャット・サイドバー・通知に出ます。
コメント
「朝起きたらRoutineが止まっていた」は、期限切れの典型です。Take over（9/29）のSSO手順とは別で、夜間バッチやBot間引き継ぎの設計に効きます。送信・カレンダー書き込みはAlways allowにしない運用が安全です。
考察
パイロットでは「読み取り系はAlways allow可／送信・購入・削除は毎回Ask」とルールを二行書いてからRoutineをEnableにします。確信度: 公式help。
新規機能解説
Lingxi Li — Grok Bot for Engineering（専任5体＋Jenny／Cloud agents／Notion PR DB）en新機能
引用
I have five engineer bots, each specializing in a different area: Baltata … iOS … Shaoruru … Desktop … Hogan … infrastructure … Craig … Android … Quill … harness … Every bot can create Cursor cloud agents, read transcripts, review proofs attached to PRs, and send follow-ups … To help my bots stay on top of work beyond the context limit … each engineer bot manage a shared Notion database. Every 30 minutes, they review … Bugbot comments … Failing CI … Merge conflicts. … If the review is highly confident and the blast radius is low, the PR is merged automatically. … That's all Jenny's job, my head of operations … Every morning at 5 a.m., Jenny meets 1:1 with every bot … Nightly audits … Every night at 3 a.m. … P0 urgency process … checks the transcript every five minutes … Please note that this can burn tokens much faster than you think … Before Grok Bot, I could manually manage 15 cloud agents at a time. Now my fleet manages more than 200 simultaneously …
日本語訳
領域専任のエンジニアBotを五体（iOS／Desktop／インフラ／Android／harness）持ち、いずれもCursor cloud agentsの起動・ログ確認・PRの証明レビュー・フォローが可能です。コンテキストを超える仕事は共有NotionのPR DBを30分ごとに見て、Bugbot・CI失敗・コンフリクトを処理し、自信が高く影響が小さいものは自動マージします。コードを書かないopsのJennyが毎朝1:1とポストモーテム、オンボーディングを担います。夜間監査（3時）や、P0指定で5分ごとに舵取りする緊急手順もあります（トークン消費に注意）。人手では15体だったcloud agentsが、艦隊では200超との記述です。
コメント
昨日のMarketing六体と同系統の「役割艦隊」ですが、ここはcloud agentsの監督と視覚フィードバック（スクショ検証）が核です。中小では五体そろえず、実装一体＋レビュー一体＋夜の軽い掃除Routineからが現実的です。
考察
デモは「云 agentsを起動→スクショで差分確認→人がマージ」までにして、自動マージとP0は接続しないまま見せると境界が伝わります。確信度: 公式Guides（数値は著者環境）。
Kevin Niparko — Grok Bot for PMs（attention list／CoS・EM・IC×5）en新機能
引用
Rather than creating a "priority list" … I've started to have Grok Bot follow my attention across Slack, email, and meetings / Granola to create something different: an "attention list." … Agents can apply the attention list as a filter. … You can compare stated priorities and goals vs. what I'm actually focused on. … To set this up: "Create an attention list: every hour, review email, Slack, Granola, and calendar and create a succinct set of projects I'm focused on and their current state, what needs to happen next." … Chief of Staff: calendar, Slack, inbox. … Eng mgr (Emily): does not code. Breaks work down, delegates to IC eng agents … Eng (×5) … Data analyst (Ashley) … PM Pete … I still keep final review for any external email sends, purchasing anything, or destructive actions like deletes. … Agents shouldn't be noisy. … Ask them to stay quiet unless something needs your attention.
日本語訳
古くなりやすい優先リストの代わりに、Slack・メール・会議メモからattention list（いま実際に注意が向いている仕事の一覧）を毎時更新させます。エージェントのフィルタにも使え、宣言した目標とのズレも見えます。チームはChief of Staff（受信・予定）、Eng mgr（コードは書かず分解と委譲）、ICエンジニア×5、Data analyst、PM Pete（RFC・調査）など。外部メール送信・購入・削除は人が最終確認。ノイズを減らすため、必要なとき以外は黙るよう指示します。
コメント
診断士・行政書士の伴走でも「今日の論点一覧」は需要があります。優先表を人手でメンテするより、会話と受信箱から浮かび上がるリストの方が現場に近いです。最初はCoS一体と読み取り中心で足りることが多いです。
考察
セットアップ文は公式の毎時プロンプトをそのまま試し、送信権限は切ったまま「リスト更新とアーカイブ案」だけにすると安全です。確信度: 公式Guides。
実践事例
Ei-chan — YouTube新着の商品リマインダー（RSS＋Jev＋決定論リンク）ja実践
引用
毎晩21時（週末含む）に、「ユニクロGU無印 YouTube新着」というルーティンを実行するようにしています。… 動画の新着チェックには、YouTubeの公開Atom RSSフィードを使っています。… 1. 両チャンネルのRSSを取得する 2. 既知のvideoIdと照合し、新しいものだけ次に進める。両方既知なら黙って終わる 3. タイトルと概要をJevに渡して判定してもらう 4. 判定とリンク抽出の両方が条件を満たしたら通知。どちらか欠けても既知リストに足して黙る … 拾うのは、muji.com、uniqlo.com、gu-global.comのような公式ドメインと、Amazon、楽天、Qoo10などのショッピングサイトです。… このBotがやっているのは、予約や決済、購入ではありません。… RSSで新着を拾い、安い確率判定で絞り、リンク抽出は決定論で固める。
コメント
9/22公開の個人実践です。チャンネルごとにBotを増やさず一本にまとめ、通知は「買える紹介＋リンクあり」だけに絞っています。AIに全部任せない三段構成（取得→確率判定→URLルール）が、コストと説明責任の両面で伴走しやすいです。
考察
中小の情報収集Botでも同じ型が使えます。公式RSSや公開フィードで拾い、判定だけモデル、抽出はコード、実行（送信・発注）は人が持つ、と分けると事故が減ります。確信度: JA一次（著者環境）。
Josh Kim — Grok Bot for Work（Inbox／Calendar EA／Intel Scout／Bot Boss）en実践
引用
Four bots that changed my output: Inbox Manager, Calendar EA, Intel Scout, and Bot Boss as the single front door. … Inbox Manager … I've set mine to read-only. Its job is to find the actual fires … drafts 0 to 5 each labeled draft and never send or reply or react without me typing "send" … Calendar EA … draft moves and invites only after I confirm, never invent an attendee, never write to the calendar silently … Intel Scout … Every day, at 8am and 5pm, it tells me three things: what happened … open follow-ups … what I need for upcoming meetings … Bot Boss … route my asks and the specialists' reports through one stream … draft then wait for my approval on any send or calendar write; … clocks stay Disabled until I hit Enable …
日本語訳
成果を変えた四体です。Inbox Managerは読取専用で火種だけ上げ、下書きは送らず「send」と書いたときだけ。Calendar EAは確定後にだけ移動・招待案を出し、出席者の捏造や黙った書き込みはしません。Intel Scoutは平日8時と17時に、自分に効く動き・未フォロー・次の会議の三点を短く返します。Bot Bossが窓口一本化して専門家の報告をまとめ、送信・カレンダー書き込みは下書き承認、時計はEnableするまでDisabledです。
コメント
昨日のMarketing六体が職能艦隊なら、こちらは個人の司令塔型です。中小の一人事務所では、まずInboxの読取＋Bot Bossの一本化だけでも「三つの通知に追われる」状態を防げます。
考察
導入はCreate Disabledのままプロンプトを試し、動作確認後にEnable、送信系は最後、の順が公式プロンプトの意図に沿います。確信度: 公式Guides。
収集: 2026-10-03 約05:05–05:25 JST。英語ソースは翻訳付き。公式Product新着は Team Bots（9/28）以降なし。仕様は Computer recovery と Approvals（約10分）。新機能は Engineering と PMs。実践は Ei-chan（9/22）と Work 四体。X（@bot等）は本号もスクショ・embed未取得。1Password vault共有とFinanceの公式手順ページは未確認です。Designing／GTM／mobile app development／Link SuperGrokは次候補。事実と意見を分け、確信度を各カードに記載しています。