← 一覧に戻る

Grok活用事例ダイジェスト

2026-11-03・速報1 / 仕様2 / 新機能2 / 実践6　※英語には日本語訳をつけています。対象は11/02朝〜11/03朝です。主ピックは使用量の続報です。11/02 の夕方から跳ね上がった数字は多くの人で元に戻りましたが、Elon Musk さんの「提供コストが高すぎた」という発言と、「1%あたりの量が半分になった」という利用者の測定が並んでいます。仕様では、Mac の画面操作や古いメッセージへの返信についての職員回答と、アカウント統合のあとコンピューターが起動しない件の対処をまとめました。新機能では公式ニュースの Data Bot と、使用量の見える化の道具を取り上げます。実践事例は、使用量を抑える工夫と、情報集めを1体に任せる運用が中心です。

速報

使用量の続報です。11/02 の夕方（JST）から、跳ね上がった週の使用量が多くの人で元の数字に戻りました。ただ、その前に Elon Musk さんが「Grok Bot の提供コストは売上に比べて高すぎた」と書いており、戻ったあとも「1%あたりに使えるトークンが約半分になった」という測定が続いていますen

X投稿（@elonmusk さん 11/02 05:34・06:37 JST、@tankazunori0914 さん 11/02 17:40 JST、@XFreeze さん 11/02 18:06 JST）／公式フォーラム（176909 #143〜#189、11/02 17:00〜11/03 01:55 JST）／状況ページ（status.x.ai の履歴）

（@elonmusk さん。「今週は使用量がすぐ尽きたという人が多い。リセットはないのか」という @DogecoinNorway さんの問いへの返信）Grok Bot を提供するコストは、売上に比べて持続できないほど高くなっていました。
Since the reset … 12:05 AM → 3:32 AM Nov 2: 8.5% → 16.3% (7.8 points) for about 30.6M tokens, or about 3.9M per 1%. … That’s roughly 0.45–0.53× the old rate: about 2× the cost per token, effectively a halved weekly limit.
（フォーラム #172 @hyk さん、Pro+）リセット後……11月2日 0:05〜3:32（米国太平洋時間）に約3,060万トークンで 8.5%→16.3%（7.8ポイント）、1%あたり約390万トークンでした。……以前（1%あたり約730万トークン）の0.45〜0.53倍で、トークンあたりのコストが約2倍、実質的に週の上限が半分になった計算です。

事実として確認できたことを並べます。状況ページの履歴には「Billing and Usage Dashboard（請求・使用量の画面）の不具合」が 11/01 14:38〜19:53（JST）に出て、解決済みになっています。11/02 の17時前後から、フォーラムでは「直った」「100%から元の数字に戻った」という報告が続き、@XFreeze さんは 93%→47%、@tankazunori0914 さんは 50%→24% と書いています。@Gak_Chen さん（#189）は、使用量の書き出しから「約20ポイント返ってきたが、返ったあとの減り方は新しい速さのまま。巻き戻しではなく、取りすぎ分の一度きりの返金に見える」と分析しています。@Daniel15 さん（#109）も先週 1%あたり約1,680万トークン、今週約810万トークンと、ほぼ半分の数字を出しています。一方、職員は 11/02 05時以降このトピックに投稿しておらず、料金や枠の変更についての公式の説明はまだありません。Elon さんは、週の上限に達した利用者に「もっと上のプランにするのは値上がりが大きすぎる？」とも返しています（11/02 06:37 JST）。X の @grok の返信には「枠が調整された」と書くものがありますが、これは AI の推測で、公式の発表ではありません。

考察

ここからは意見です。「表示の不具合は直った」「1%の重さは変わったかもしれない」の2つを分けて考えるのがよいと思います。前者はほぼ確かで、後者は利用者の測定がそろっているものの、公式には何も言われていません。事務所の毎朝のルーチンも同じ枠を使うので、今週は末吉さんの画面で「1日にどれくらい減るか」を2〜3日続けて見ておき、先週と比べるのが確実です。顧問先に Grok Bot を勧める場合も、「週の枠は運営側の判断で変わりうる」ことを前提に、止まっても業務が回る範囲から任せるよう伝えておきたいところです（確度：表示の復旧は高、1%あたりの量が半分になった件は中。後者は利用者の測定で、公式の確認がありません）。

@elonmusk（コスト）／@elonmusk（上位プラン）／@tankazunori0914／@XFreeze／176909 #172／176909 #189／status.x.ai

仕様解説

職員の回答で、いまの Grok Bot に「できないこと」と「既知の不具合」がいくつか分かりました。Bot が自分の Mac の画面を見て操作する機能はまだ提供されておらず、長い会話の古いメッセージへの「返信」は、元の文脈が Bot に届かないことがありますen仕様

公式フォーラム（177041 職員 mohitjain さん 11/03 00:15 JST、177057 職員 Colin さん 11/03 00:10 JST、177069 職員 Colin さん 11/03 01:30 JST）

Letting a Bot see and click in your Mac’s apps isn’t available in Grok Bot right now, so there’s nothing we can turn on for one machine and no opt-in. What worked in October was most likely the Bot running terminal commands on your Mac, not screen control.
（177041 職員 mohitjain さん）Bot があなたの Mac のアプリを見てクリックする機能は、いまの Grok Bot にはありません。なので、1台だけ有効にすることも、申し込んで使えるようにすることもできません。10月に動いていたのは、たぶん Bot が Mac でターミナルのコマンドを実行していたもので、画面の操作ではありません。
This is a known issue … In longer chats, a Reply to an older message can lose its link before it reaches the bot. … Until it’s fixed, a workaround is to include the context directly in your message.
（177057 職員 Colin さん）既知の問題です。……長い会話で古いメッセージに「返信」すると、その結びつきが Bot に届く前に失われることがあります。……直るまでは、参照したい内容をメッセージに直接書くか、画像を添付し直してください。

質問者は、Mac に「Grok Bot Computer Use.app」が入っていて、設定ファイルでは機能が切られている、と細かく報告していましたが、職員は「いまは提供していない」と答えました。代わりに、Bot のコンピューターで一度サインインし、パスワードや2段階認証のところだけ「Take control（操作を代わる）」で人が入れば、ログインはたいてい保たれると案内しています。サイトに弾かれる場合は「Route traffic through this computer」を使う方法も示しました。もう1件、Bot のコンピューターと自分のパソコンの間でコピー＆ペーストしたいという要望（177069）には、Colin さんが「操作を代わっている間なら、文字は両方向にコピーできるはず」と答えています。

考察

ここからは意見です。この事務所でも、Bot のコンピューターのブラウザで作業する場面が多いので、3つとも実務に関わります。古いメッセージに「これを直して」と返信しても伝わらないことがあるので、末吉さんから指示するときは、対象のファイル名や URL を本文に書いてもらうほうが確実です。ログインが必要なサイトは「最初の1回だけ人が操作を代わる」のが職員の勧める形なので、顧問先に説明するときもこの手順で伝えるのがよいと思います（確度：高。いずれも職員の回答です）。

177041（Mac の画面操作）／177057（返信の文脈）／177069（クリップボード）

X Subscription のアカウント統合のあと、Bot のコンピューターが起動しなくなった件で、職員が「更新・復旧・リセットでは直らない。空のコンピューターに替える」と答えました。原因は .profile か .bashrc の1行だったそうですen仕様

公式フォーラム（177045、利用者 11/02 23:06 JST、職員 mohitjain さん 11/03 00:05 JST、別の利用者 11/03 03:14 JST）

This needs a fix on our side, because Update, Recover and Reset all bring back the same stuck startup file. The quickest fix is for us to give your bots a fresh, empty computer. That removes everything saved on the computer itself, including files, browser logins and installed apps. Your bots and chats stay. … When you copy your backup back, leave out .profile and .bashrc, since a line in one of those is what got stuck.
（職員 mohitjain さん）これはこちら側の修正が必要です。Update・Recover・Reset のどれを使っても、同じ詰まった起動用のファイルが戻ってくるためです。いちばん早いのは、Bot たちに新しい空のコンピューターを用意することです。コンピューターに保存されたもの、つまりファイル・ブラウザのログイン・入れたアプリはすべて消えます。Bot と会話は残ります。……バックアップを戻すときは、.profile と .bashrc を除いてください。そのどちらかの1行が詰まりの原因です。

報告者は、11/01 にアカウントを2つ統合した直後から、約60体の Bot が共有するコンピューターでどのコマンドも始まらず14分で時間切れになる、と書いています。サポートに言われて Reset と Recover は使わずに待っていたところ、職員が引き取りました。ファイルを残したまま直す方法も検討できるが、時期は約束できない、とのことです。同じトピックには、10/28 から5日以上「起動中」のままという別の利用者も加わりました。フォーラムでは、ほかにもコンピューターが固まったままのトピック（176036・176595・176386 など）が11/03 の未明まで更新されています。

考察

ここからは意見です。この事務所のコンピューターも、ダイジェストの作業フォルダや公開用の設定、ブラウザのログインを抱えています。「空のコンピューターに替える」と言われたときに困らないよう、作業フォルダは定期的に Drive などに写しておき、ログインし直しが必要なサイトの一覧を README に残しておくと安心です。.bashrc や .profile に手を入れるときは、起動を止める書き方（待ち続けるコマンドなど）を避けるのがよいと思います。アカウント統合は、急ぎでなければ様子を見てからでもよさそうです（確度：高。職員の回答です。統合と不具合の因果は、この1件では確定していません）。

177045（統合後に起動しない）／176036／176595

新機能解説

公式ニュースに、社内のデータ分析チームが育てた共有 Bot「Data Bot」の事例が出ました。チームで手入れするスキルと共有の記憶を持ち、記憶に足す内容は管理者が承認してから全員に広がる仕組みですen新機能

公式ニュース（x.ai/news/data-bot「Giving every team a data scientist with Grok Bot」、Sally Xu さん、11/02 付）

Data Bot is a Shared Bot in Grok Bot that the data science team teaches, so every team can query the warehouse, run analyses, and get answers the way a data scientist would. … As the Team Bot’s managers, we can review these proposed additions to its memory and approve or reject them before Data Bot shares that knowledge with everyone who uses it. … Last week alone, we estimate it handled about 70 hours of work that would otherwise have landed on the data science team.
Data Bot は、データサイエンスのチームが教え込んだ Grok Bot の共有 Bot です。どのチームでもデータ倉庫に問い合わせ、分析し、データサイエンティストと同じやり方で答えを得られます。……Team Bot の管理者として、私たちは記憶に足されそうな内容を見直し、承認か却下をしてから、使う人全員に共有します。……先週だけで、本来データチームに来ていたはずの約70時間分の仕事をこなしたと見積もっています。

記事によると、スキルは「指標と分析（売上や利用者数の定義、急な増減を地域や祝日から確かめる手順）」「A/B テスト」「グラフとダッシュボード（Databricks や Hex に作る）」「データ基盤（dbt の書き方など）」の4つに分けて書かれています。Slack のチャンネルに入れて、決まった指標を毎週報告させることもでき、営業やマーケティングの担当者が、メール配信のキャンペーン ID を渡して「受け取った人がその後どうしたか」を調べさせている例も紹介されています。複雑で判断が要る分析は、今もチームが自分で担当していると書かれています。

考察

ここからは意見です。11/02 に紹介した「記憶は運営側に保存され、裏で足されたり消されたりする」という職員の説明と比べると、Team Bot では「記憶に足す前に管理者が承認する」流れが用意されていることになります。事務所に置き換えると、補助金の要件の読み方や申請書の書き方を「スキル」として末吉さんが手入れし、顧問先や職員が同じ Bot に質問する、という形が近いと思います。1人の詳しい人が詰まりどころになっている会社には、そのまま説明に使える事例です（確度：高。公式の記事です。70時間は社内の見積もりです）。

公式ニュース（Data Bot）／ヘルプ（Shared Bots）

使用量を「どの Bot が食っているか」見える化する道具が、利用者の手で次々に出ています。3D のオフィスに Bot を並べるダッシュボードは約66万回表示され、外部の記憶ツールで Bot の読む量が約58%減ったという検証もありましたen新機能

X投稿（@0xCodila さん 11/02 03:27 JST、@devdosomething さん 11/02 15:26 JST、@AskTolik さん 11/03 02:19 JST）

（@0xCodila さん）Grok Bot のチーム向けの、初めてのライブのダッシュボードです。プロンプト1つ・2分・使用量1%未満で、チームごとに3D のオフィスの階が分かれ、どの Bot が使用量を食っているか、動いているか止まっているかが一目で分かります。……Bot は無料の通知サービス ntfy に自分専用のチャンネルを作り、全 Bot の共有の記憶に「始めたとき・終わったとき・詰まったときに1行送る」という決まりを書き込みます。ルーチンが Bot ごとの使用量を定期的に送り直します。
（@devdosomething さん）同じ10問を2回、自分の Grok Bot に聞きました。記憶なしでは Slack や会話の履歴を15回調べ、約6.6万字を読みました。外部の記憶ツール sibyl を使うと12回・約2.8万字で、正解数はどちらも10問でした。同じ仕事で読む量が約58%減ったことになります。……ただし、記憶が新しく保たれている場合だけです。古い記憶が1件あったせいで、古い答えが返ってきました。

@AskTolik さんのまとめ（11/03）には、@0x_kaize さんの「Saver Bot」も出ています。Bot・ルーチン・日ごとに使用量を分けて直し方を提案する Bot で、最初の点検で「ニュースのまとめのルーチン1本が週の28%を使っていた」と分かったそうです。どれも利用者が作ったもので、公式の機能ではありません。0xCodila さんのダッシュボードは外部の通知サービスに Bot の状況を送るので、送る内容は自分で確かめる必要があります。

考察

ここからは意見です。使用量の数え方が変わったかもしれない今週は、こうした見える化の価値が上がっています。ただ、全 Bot の共有の記憶に決まりを書き込む方式は、11/02 に職員が説明した「記憶は裏で足されたり消されたりする」性質とぶつかるおそれがあります。事務所では、まず秘書に「Bot・ルーチン別の今週の使用量」を週1回まとめてもらう程度から始め、外部サービスにつなぐのは中身を確かめてからにしたいところです。Saver Bot の「ニュースのまとめが28%」という例は、このダイジェストのルーチンも重い部類だと考えて、収集の手順を見直す材料にします（確度：中。いずれも投稿者の自己申告です）。

@0xCodila／@devdosomething／@AskTolik

実践事例

使用量がきつくなったという声を受けて、日本語でも節約の工夫が具体的に共有されました。「重い作業は Cursor のクラウドエージェントへ」「Bot どうしの伝言は終わったときの1通だけ」「大きいファイルは丸ごと読まない」などですja実践

X投稿（@take_pla さん 11/02 13:10 JST、@takamasa045 さん 11/02 11:16 JST、@tukiyomiiori さん 11/02 17:35 JST）

@take_pla さんは、自分の使い方では Bot の会話1回ごとに約11万トークンの文脈を読み直していたと書き、4つの対策を挙げています。①調査・実装・CI の修正・長いログ読みは Cursor のクラウドエージェントに回し、指示書は1通で渡します。②Bot どうしの「受けました」や途中報告はやめ、終わったときの1通だけにします。③ログや大きいファイルは開かず、決まりのファイルも rg で要る行だけ引きます。④CI が2回続けて落ちたら止めて報告します。ただし①は、Cursor と Grok Bot の枠が分かれている旧プランでないと効果がないかもしれない、と断っています。@takamasa045 さんは、Super プランで約2分の MV を画像・動画とも Grok で作ったら、それだけで週の上限の約20%を使ったと報告しました。逆に @tukiyomiiori さんは「残り2日で22%しか使っていない」とし、使い切る人はコーディングや画面操作をさせすぎているのでは、と書いています。

考察

ここからは意見です。4つとも、この事務所の運用にそのまま当てはまります。特に②は、秘書と各 Bot の間の「了解しました」のやりとりを減らすだけで効きそうです。③は、このダイジェストの作業でも、前日のファイルを丸ごと読まずに必要な部分だけ引く形にすると軽くなります。画像や動画の生成は1回で大きく減るので、顧問先向けの資料づくりでは「画像は最後に、枚数を決めてから」にするのがよいと思います（確度：中。いずれも個人の経験で、減り方は使い方やプランで変わります）。

@take_pla／@takamasa045／@tukiyomiiori

「権限」の設定で Bot が動く前に承認を挟み、決まりは短い英文で1文ずつ書くと止まってくれる、という使い方が紹介されました。使用量のダッシュボードを作らせる、そのまま貼れる長いプロンプトも共有されていますja実践

X投稿（@Shachi_Pratibha さん 11/02 16:09 JST、@buddypia さん 11/02 15:12 JST）

@Shachi_Pratibha さんは、X の検索のように使用量が増えやすい操作の前で承認を求めるルールを、「when doing an X search」のような短い英文で入れていると、設定画面の写真つきで説明しています。@buddypia さんのプロンプトは、Page（Canvas）に週の上限のゲージ（80%に警告線）、Bot 別の使用量を「Bot 間の会話・ルーチン・直接の会話」の3色で積み上げたグラフ、消費の多いルーチン上位5件、削減案の上位3つを並べさせるものです。「既存のボット設定やアカウント設定は一切変更しないでください」「実データが取れない場合はサンプルで作る」と書いてあり、毎朝更新するルーチンも提案させています。

考察

ここからは意見です。承認のルールを「使用量のブレーキ」として使う発想は、この事務所にも合います。秘書以外の Bot が X 検索やブラウザ操作を始める前に一度止まるようにすれば、思わぬ消費に早く気づけます。@buddypia さんのプロンプトは便利ですが、「実データが取れなければサンプルで作る」と書いてあるので、出てきた数字が本物かどうかを必ず確かめる必要があります。顧問先で使うなら、この1行は「取れない指標は空欄にする」に書き換えておくのが安全だと思います（確度：中。個人の工夫で、ルールの効き方は Bot によって差があります）。

@Shachi_Pratibha／@buddypia

120体の Bot を動かしている人が、「Grok Bot についての情報集めは1体だけに任せ、ほかの Bot はそのまとめを読むだけ」にしている、と仕組みを公開しましたja実践

X投稿（@shin_chan_ai さん 11/02 21:51 JST、@AkioT315 さん 11/02 20:00 JST）

@shin_chan_ai さんのフォルダは「新着（日付順）」「機能ごとの説明」「使い方の工夫」「目を通した出典のリスト」の4つに分かれています。記事や投稿の下書きを書く Bot は、自分で調べる前にまずそこを読み、足りないときだけ情報集めの係に聞きます。一度見た出典はリストに残して同じ話を二度ためず、古い情報には印をつけ、公式で確かめたものとネットだけの話を分けて書くそうです。同じ日に @AkioT315 さんは、アフィリエイトブログの作業はほぼ自動で回るようになったが、最後の確認は人がやる線引きは変えない、と書いています。

考察

ここからは意見です。これは、このダイジェストの作り方とほぼ同じ形で、逆に学べる点があります。いまは日ごとの調査メモ（research.md）が積み上がっていますが、「機能ごとの説明」と「出典リスト」を1つずつ別のファイルにまとめて更新していけば、毎朝前日の分を読み直す量が減り、重複の確認も速くなります。各 Bot が同じことをばらばらに調べると使用量が何倍にもなるので、事務所でも「調べる係は1体」を決めておく価値があると思います（確度：中。個人の運用例です）。

@shin_chan_ai／@AkioT315

Ultra プランでも足りなくなった人が、Grok Bot を「上流」に置き、中流を Hermes、下流を Codex と Claude Code にする3段の分担に組み替えたところ、消費の速さがかなり落ちたと報告していますja実践

X投稿（@Golf_swing_tech さん 11/02 13:26 JST、@nsxdavid さん 11/02 12:30 JST）

So I had Grok Bot move some of this technical work off onto Cursor, which draws from that sub instead. That’ll help... but unless they reverse course, I am going to just have to rewire so much of what I had GrokBot doing for me.
（@nsxdavid さん）そこで、技術的な作業の一部を Grok Bot に Cursor 側へ移させました。そちらは別の契約の枠から引かれます。少しは助かりますが、方針が戻らない限り、Grok Bot に任せていたことの多くを組み直すことになりそうです。

@nsxdavid さんは、承認後に開発ブランチへ統合し、テスト環境に出す工程を Grok Bot に任せていたところ、1日で使用量が30%を超えたと書いています。契約をまとめずに Cursor の契約を別に残していたので、技術的な作業をそちらに逃がせた、とのことです。どちらの投稿も、Grok Bot には指示と判断を残し、手を動かす作業を別の枠や別の道具に回すという方向で一致しています。

考察

ここからは意見です。事務所でも、重い作業は共通 PC の Claude Code に任せる形をとっているので、方向は同じです。ただ、段を増やすほど伝言の手間とずれが増えることは 11/02 の @yuya_takeyama さんの報告でも出ていました。顧問先には、まず「Grok Bot は受付と監督、作業は別の道具」の2段から始め、3段目は必要になってから足すよう勧めたいと思います。アカウント統合をしないで契約を分けておくと逃がし先になる、という点は、上の統合トラブルと合わせて覚えておきたいところです（確度：中。個人の経験談です）。

@Golf_swing_tech／@nsxdavid

英語圏では「毎日くり返す作業は、Bot に一度スクリプトを書かせ、ルーチンにはそのスクリプトを動かさせる」という助言が約4.2万回表示されました。仮想マシンで見張り、大事なことが起きたときだけ Webhook で Bot を起こして使用量を20分の1にした、という人もいますen実践

X投稿（@nima_owji さん 11/02 16:10 JST、@_jsolly さん 11/02 18:59 JST）

（@nima_owji さん）Grok Bot の小技です。毎日くり返す作業があるなら、毎回ゼロから Bot にやらせないでください。一度 Python のスクリプトを書かせて、ルーチンにはそのスクリプトを動かさせます。結果は同じで、使用量はずっと少なくなります。
I used a persistent VM in the cloud that does the hard work and wakes Grok Bot via web hook when something significant happens. … If you have a routine that often no-ops, you should probably rewrite it as an algorithm + wake criteria.
（@_jsolly さん、Cursor の60ドルのプラン）重い作業はクラウドの常時動く仮想マシンにやらせ、大事なことが起きたときだけ Webhook で Grok Bot を起こしました。……何もせずに終わることが多いルーチンがあるなら、決まった処理と「起こす条件」に書き直すべきです。

@_jsolly さんは、この形で Bot のトークン使用量を20分の1にしたと書いていますが、具体的な数字の内訳は出していません。@nima_owji さんの方法は、この事務所のダイジェストでもすでに一部やっている形（取得や変換は Python のスクリプト、判断と文章は Bot）です。

考察

ここからは意見です。ルーチンが毎回「調べて、何もなければ終わる」形になっていると、何もない日にも文脈の読み込み分を使います。たとえば顧問先の補助金の公募ページを見張るなら、ページの変化はスクリプトで確かめ、変わったときだけ Bot に要約させるほうが、はるかに軽くなります。Webhook で起こす形は、Bot 専用のメールアドレスに通知を送る形でも代わりになるので、11/02 の「転送でルーチンを起こす」使い方と組み合わせやすいと思います（確度：中〜高。仕組みは公式の機能の組み合わせで、削減の幅は投稿者の申告です）。

@nima_owji／@_jsolly

コードを書かない人が「Grok Bot をどう毎日使っているか」をまとめた投稿が約6,600回表示されました。最上位に「Chief of Staff（秘書役）」を置き、Notion を共有の記憶にして Bot たちを束ねる形ですen実践

X投稿（@ahboyash さん 11/02 15:56 JST、@chadarimura さん 11/03 02:36 JST）

（@ahboyash さん）Grok Bot とは何か、毎日どう使っているかです。私は技術者ではなく、情報系の出身でもありませんが、@bot と専門の Bot たちのおかげで、ものを作り、仕事を自動化できています。……リサーチでは、ガバナンスのフォーラムと GitHub のリポジトリの見張りと、「Scout（探す係）・書く係・編集係」のコンテンツ部屋を使っています。Chief of Staff（秘書役）が上に立ち、Notion の「第二の脳」（記憶の置き場）を通して全員をまとめます。Grok Bot のグループチャットで Bot どうしに議論させるのもおすすめです。……技術者でないなら、まず Bot 1体と dr eggbot から始め、本当に仕事ができたときに増やしてください。

同じ投稿の中で、使用量がすぐ尽きることを欠点に挙げています。@chadarimura さんは「Grok Bot 100日」の10日目として、集まりの直前に歌詞カードを用意し忘れたことに気づき、3曲を Bot に送って歌詞のスライドを作らせた、と動画つきで書いています。

考察

ここからは意見です。「秘書役を1体置き、ほかの Bot は専門の仕事だけ」という形は、この事務所の翠さんを中心にした運用と同じです。共有の記憶を Notion のような外部の置き場にする点は、運営側の記憶が裏で変わることへの備えにもなります。顧問先には、@ahboyash さんの最後の一文「まず1体、仕事ができたら増やす」をそのまま伝えるのがよいと思います（確度：中。個人の使い方の紹介です）。

@ahboyash／@chadarimura

収集: 2026-11-03 約05:07–05:45 JST。対象は11/02朝〜11/03朝です。英語ソースは翻訳つき（一部は要約です）。x.ai/changelog/bot の先頭は 0.78.1（10/27 付）のままで、x.ai/bot/guides とマーケットプレイスにも大きな変化はありませんでした。x.ai/news には 11/02 付で Data Bot の記事が加わりました。ヘルプは cursor.com/help/grok-bot の25ページを取得して 11/02 の写しと比べ、変更はありませんでした。状況ページの履歴は RSS で取得でき、11/01 14:38〜19:53（JST）の請求・使用量画面の不具合のほか、11/02 18:09〜19:24（JST）に Cursor と Grok Bot の GitHub などソース管理との連携の不具合（解決済み）が出ていました。フォーラムの職員投稿は原文で確認しました。176909 には 11/02 05時以降、職員の投稿はありません。今日は画像の保存はせず、X の公式埋め込みとリンクで示しています。見送り: 招待リンクの宣伝、@bot の自動返信、他社の新しいエージェントの紹介、「21個の GitHub プロジェクト」型のまとめ、Bot だけで会社を作る無料講座とされる投稿（元の記事を確認できなかったため）、怒りや解約の表明だけの投稿、有料 note・勉強会の告知です。Gaps: 1%あたりの使用量が変わったかどうかの公式説明、跳ね上がりの原因、従量課金に流れた分の扱い、アカウント統合の不具合の修正時期、Mac の画面操作の提供予定です。