Grok活用事例ダイジェスト

2026-11-08・速報3 / 仕様3 / 新機能1 / 実践6　※英語には日本語訳をつけています。対象は11/07朝〜11/08朝です。主ピックは、利用者のCSV集計で「1%あたりトークンが約半分」と数字が出た件、11/07 の更新後に増えたユーザーフォルダ外ファイルの読み込み拒否、運営側での箱の交換で中身が消えた報告、Auto-review のサイズ上限（約6.5万文字で承認カードが出ない）、コネクタ削除は英語1行で、という職員説明です。新機能は 0.79.3 の利用者報告（Bot 単位の Slack 参加など）です。実践は、巡回をスクリプトへ戻した使用量対策、Claude Code との分担と依頼文の3項目、別モデルでのファクトチェック、Update 後も Claude Code が残った例、3体で回す第二の脳、X データの集計を取り上げます。

速報

利用者 @Capital_EyeMotors さんが使用量CSVを集計し、「1%あたりのトークン量が前サイクルの約25.2Mから約12.9Mに減った」と数字で示しました。使用量ページに「プランの他アプリと共有」という新しい文言が出た点も指摘しています。職員回答はまだありません。別スレでは Colin さんが、11/06（UTC）の一部で使用量の集計処理が止まり、追いつき中だと説明していますen

公式フォーラム（177657 11/08 02:38 JST／177575 #10 Colin さん 11/07 18:43 JST／177646 #6 Colin さん 11/08 01:37 JST）

Cycle Tokens Weekly % shown Tokens per 1% / Oct 27 to Nov 3 ~2,218M 88.1% ~25.2M / Nov 3 to Nov 7 midday (partial) ~937M 72.8% ~12.9M … Our total token use actually fell about 26% week over week … The usage page also now says the weekly limit is “shared with the other apps on your plan.” That wording is new to us.

（177657 @Capital_EyeMotors さん、Ultra・0.79.3・macOS）サイクル別に、トークン合計／表示された週次％／1%あたりのトークンを並べると、10/27〜11/3 は約2,218M・88.1%・約25.2M、11/3〜11/7昼（途中）は約937M・72.8%・約12.9Mでした。……実際の使用トークンは前週比で約26%減っています。……使用量ページには、週次上限が「プランの他アプリと共有」と書かれるようになりました。この文言は初めて見ます。

Hi all, nothing is wrong with your accounts. An issue on our side interrupted usage processing for part of Nov 6 (UTC), which is why your chart drops off after Nov 5. Processing is running again and things should catch up soon.

（177575 #10 Colin さん）みなさんのアカウントに問題はありません。こちら側の問題で、11/06（UTC）の一部で使用量の処理が止まりました。グラフが 11/05 以降で途切れているのはそのためです。処理は再開しており、まもなく追いつくはずです。

177657 は、前日号の「約50%削減は意図的」というサポート転記を、利用者側の計測で裏づける形です。キャッシュなしトークンだけで見ても約44%減とのことです。投稿者は、100%到達時に「学習への利用を許可すると枠がリセットされる」案内がプレリリース版に出るという噂についても、対象データや取り消し可否の文書化を求めています。Cursor IDE の Agents ウィンドウで使用量が常に0%と出る件（177646）は、Colin さんによると表示する枠の取り違えで、3.30 で修正予定です。それまでは Settings の Plan & Usage で確認できます。

考察

ここからは意見です。数字は利用者1人の計測ですが、手法（CSV合計÷表示％）は事務所でも再現できます。朝晩の％メモに加えて、週1回CSVを書き出して「1%あたりトークン」を記録しておくと、次に配分が変わったときに根拠を持って判断できます。学習許可と引き換えのリセットは、顧問先の情報が混ざる以上、文書が出るまで選ばないのが無難です（確度：計測投稿と職員の集計停止説明の存在は高。枠の公式な数値は未公開です）。

177657／177575 #10／177646 #6／176909（使用量スレ）

11/07 のアップデート後、Windows や Linux で「ユーザーフォルダ外のファイルを Read できなくなった」という報告が急に増えています。D:・E:・G: ドライブや外付けドライブで「outside the allowed local-exec root」と出る、という内容です。Shell では読めるので、職員 Colin さんの 10/29 の回避策がそのまま使えますen

公式フォーラム（176555 #10–#21 11/07–11/08 JST、Colin さん #7 10/29）／177668／X（@getpat さん 11/07 21:08 JST）

On a connected computer, Read , CopyToBox and CopyFromBox only work inside your user folder ( C:\Users\ ), while Shell isn’t limited that way. Allowing local execution (even Always allow) doesn’t widen it, and there’s currently no setting to add other folders or drives. A junction inside your profile that points to D:\ is refused too, since the check follows links. … Ask the bot to use Shell for anything on D: … Asking it to remember this saves a failed Read each time.

（176555 #7 Colin さん、10/29）つないだコンピューターでは、Read・CopyToBox・CopyFromBox はユーザーフォルダ（C:\Users\<あなた>）の中でだけ動きます。Shell にはその制限はありません。ローカル実行を許可しても（常に許可でも）範囲は広がらず、ほかのフォルダやドライブを追加する設定も今はありません。プロフィール内に D:\ を指すジャンクションを作っても、リンク先まで確認するので拒否されます。……D: のものは Shell で扱うよう Bot に頼んでください。……それを覚えさせておけば、毎回 Read で失敗せずに済みます。

@bot @cursor_ai Grok Bot 0.79.3 on Windows refuses D: file reads: “Path is outside the allowed local-exec root and was refused.” Work is stalled. Is this a bug or an intentional restriction? Please publish an explanation and fix/ETA. #GrokBot #BugReport
— getpat (@getpat) November 7, 2026

（@getpat さん）Windows の Grok Bot 0.79.3 が D: のファイル読み込みを「許可されたローカル実行ルートの外」として拒否します。作業が止まっています。不具合ですか、意図的な制限ですか。説明と修正・見通しを公開してください。

176555 には 11/07 以降、Linux の / 直下マウント（#10）、自分で C:\Grok Bot Scripts\ に作ったスクリプトを読めない例（#12）、Google ドライブの仮想ドライブ G:（#21）などが合流しています。177668 は「昨夜の更新後、1週間読めていた外付けドライブが読めなくなった」という報告です。11/07 以降に職員の新しい説明はなく、仕様が変わったのか、前からの制限が表に出ただけなのかは分かっていません。

考察

ここからは意見です。事務所の PC で D: や NAS の資料を Bot に読ませている場合は、①ユーザーフォルダ内に作業用コピーを置く、②読むだけなら Shell（Get-Content など）を使うよう Bot に覚えさせる、の二つが今いちばん確実です。外付けドライブの直接参照を前提にしたルーチンは、しばらく避けた方が安全です（確度：職員の回避策と制限の説明は高。今回の更新で範囲が狭まったかどうかは低〜中です）。

176555／Colin さん #7／177668／@getpat

保存領域の復元が「store-larger-than-disk」で失敗したり、「saved credential」のエラーでブラウザが動かなかったりしたコンピューターについて、Colin さんが運営側で「新しい箱」に交換しました。動くようにはなりましたが、交換した利用者は「保存データ・ルール・記録がすべて消えて空のデスクトップになった」と報告していますen

公式フォーラム（177622 #9 Colin さん 11/08 01:59 JST・#11–#12 Royce_Lopez さん／177625 #5／177576 #8・#11）

Since Nov 7, 2026 at 00:08 UTC, my Grok Bot computer’s storage restore has failed with “store-larger-than-disk”: the store needs 128.9 GiB but the disk has 119.6 GiB free, and 0 of 98,476 files were restored. … Every browser tool and Screenshot fails with “The box could not confirm that no saved credential is being filled into its browser”. Reset Bot’s Computer fails with “Reset failed, partial state”

（177622 #1 @Royce_Lopez さん）11/07 00:08 UTC 以降、コンピューターの保存領域の復元が「store-larger-than-disk」で失敗しています。必要なのは128.9GiBで、空きは119.6GiB、98,476ファイルのうち0件しか戻っていません。……ブラウザ系ツールと Screenshot はすべて「保存済みの認証情報がブラウザに入力されていないことを確認できない」で失敗し、Reset Bot’s Computer も「Reset failed, partial state」で失敗します。

My new computer does work but it did lose all my storage and rules and all the data that was saved on it. It said it’s an empty desktop now.

（同 #11）新しいコンピューターは動きますが、保存していたデータもルールも、全部なくなりました。空のデスクトップだと言われています。

Colin さんは 177625（10/23 から同じ saved credential エラー）でも「新しい箱になったはず」と返しています。177576 では、.bashrc／.profile の常駐行でシェルが固まる例を説明したうえで、Update が出ない利用者の箱を運営側で作り直しています（#11）。Royce_Lopez さんは Google ドライブのバックアップから戻せそうだとし、作業が失われた分の使用量クレジットを求めています。

考察

ここからは意見です。「職員に箱を替えてもらう」は最後の手段で、中身は戻らない前提で考えるべきです。事務所の運用でいえば、/workspace のダイジェスト作業や site/ のアーカイブは、Cloudflare Pages 側に公開済みのものとは別に、定期的に Drive へ退避しておく価値があります。保存領域が100GiBを超えるほど溜めないことも、復元失敗を避ける意味で大事です（確度：職員対応と利用者報告の存在は高。容量超過の原因と再発条件は未説明です）。

177622／177625／177576

仕様解説

Auto-review（安全チェック）には入力サイズの上限があり、約65,000文字をコマンドに丸ごと埋め込んだ保存処理は、承認カードを出す前に「classifying this action でエラー」として弾かれます。Colin さんの回避策は「3万文字未満に分けてファイルに書いてから適用する」ですen仕様

公式フォーラム（177615 #11 Colin さん 11/08 01:53 JST）

Hi @Evgeny_Kushnir , nothing ran, so your previous results are untouched, and you don’t need to turn off any security settings or reset your computer. The error comes from a size limit on the safety check. The save command your bot built carried the whole analysis inline (roughly 65,000 characters), and the check rejects anything that large before it can show you an approval card. That’s why retrying and updating gave the same result. I’ve passed this to the team, since a command like this should get an approval card instead. In the meantime, ask your bot to save the results in smaller pieces, for example: “Write the analysis to a file in several parts, each under 30,000 characters, then apply it.”

（177615 #11 Colin さん）何も実行されていないので、以前の結果はそのままです。セキュリティ設定を切ったり、コンピューターをリセットしたりする必要はありません。エラーの原因は安全チェックのサイズ上限です。Bot が作った保存コマンドに分析結果全体（約65,000文字）がそのまま入っていて、チェックはそこまで大きいものを、承認カードを出す前に拒否します。再試行や Update で結果が変わらなかったのはそのためです。本来は承認カードが出るべきなので、チームに伝えました。当面は、Bot に小分けで保存するよう頼んでください。たとえば「分析を3万文字未満の複数パートでファイルに書き、それから適用して」です。

投稿者は 0.79.3 に上げても直らなかったと書いています。エラー文の「Please review manually」は、手動で承認できるという意味ではなかったことになります。上限の正確な文字数は公開されていません（「3万文字未満」は Colin さんの例示です）。

考察

ここからは意見です。このダイジェストのように長いHTMLを生成して書き出す作業では、本文をコマンドに埋め込まず、スクリプトファイルを分けて書いてから実行する、という今のやり方が理にかなっています。Claude Code に渡す長い下書きも同じで、「ファイルに分けて書く」を依頼文の定型にしておくと止まりにくくなります（確度：高。職員の直接説明です）。

177615 #11

コネクタのアンインストールをチャットで頼むときは、「uninstall Google Sheets」のように、英語で、1行だけ、名前を引用符で囲まずに送る必要があります。削除依頼を確認する仕組みがスウェーデン語に対応しておらず、複数行や引用符つきの文も認識しない、と Colin さんが説明しましたen仕様

公式フォーラム（177601 #8 Colin さん 11/07 19:41 JST）

Hi @GrokUser59382714 , the quickest way to clear it is from chat. Send a message that contains only this one line, in English and without quotes: uninstall Google Sheets The check that confirms you asked for a removal doesn’t recognize Swedish yet. It also skips messages that span several lines or put the connector name in quotes, which is why your request was turned down. I’ve passed that to the team.

（177601 #8 Colin さん）いちばん早いのはチャットから消す方法です。この1行だけを、英語で、引用符なしで送ってください：uninstall Google Sheets。削除を頼んだことを確認する仕組みは、まだスウェーデン語を認識しません。複数行にまたがるメッセージや、コネクタ名を引用符で囲んだメッセージも対象外なので、依頼が断られました。チームには伝えてあります。

元の投稿では、前日まで共有リンクの Google スプレッドシートをブラウザで開けていたのに、当日は「インストール済みのコネクタを使うべき」と言われ、そのコネクタは needsAuth で使えず、削除も拒否された、という流れでした。日本語について明言はありませんが、「まだ認識しない言語がある」以上、日本語での削除依頼も通らない可能性があります。

考察

ここからは意見です。事務所でコネクタを外したいときは、日本語で頼んで断られても慌てず、英語1行の「uninstall ＜コネクタ名＞」を試すのが早道です。逆に言えば、削除という破壊的な操作は「本人がはっきり頼んだか」を機械的に確かめる設計になっていて、その条件が厳しめだということです（確度：スウェーデン語・複数行・引用符の件は高。日本語の扱いは推測です）。

177601 #8

Linux 版 0.79.2 でもローカル実行は正式に使えます。ただし、手元PCを「接続中」に保つ通信は api2.cursor.sh に直接つながり、HTTPS_PROXY を無視します。プロキシ経由でしか外に出られない環境では接続できず、原因は ~/.grokbot/local-exec-daemon.log で分かりますen仕様

公式フォーラム（177582 #11 Colin さん 11/07 19:11 JST・#12 投稿者）

Hi @jnctech , local execution is supported on Linux in 0.79.2, so this isn’t a platform limit. No extra host is needed beyond api2.cursor.sh. The cursorvm.com hosts (and the tunnel timeout and wildcard tips above) are for the hosted computer, which already works for you. What I suspect is that the connection that keeps your own computer showing as connected goes straight to api2.cursor.sh and ignores HTTPS_PROXY, even with NODE_USE_ENV_PROXY=1. … The log you want is ~/.grokbot/local-exec-daemon.log.

（177582 #11 Colin さん）Linux の 0.79.2 でもローカル実行は使えるので、プラットフォームの制限ではありません。api2.cursor.sh 以外に必要なホストもありません。cursorvm.com 系のホスト（と上で出たトンネルのタイムアウトやワイルドカードの話）はクラウドのコンピューター用で、そちらはもう動いています。おそらく、あなたのPCを「接続中」に保つ通信が api2.cursor.sh へ直接つながり、NODE_USE_ENV_PROXY=1 を設定しても HTTPS_PROXY を無視しています。……見るべきログは ~/.grokbot/local-exec-daemon.log です。

投稿者は #12 で、ログに「watch stream failed: ConnectError (ENOTFOUND)」が出ていたと確認しました。/etc/hosts で api2.cursor.sh をローカルに向け、小さな中継サービスでプロキシに流す、という回避策で直したとのことです。DNS も直接の外部接続もない Proxmox の VM という、かなり特殊な構成です。

考察

ここからは意見です。顧問先の社内PCをプロキシ必須のネットワークでつなぐときは、「チャットは動くのに PC が disconnected」の典型原因として覚えておく価値があります。まずログの ENOTFOUND を見る、という切り分けの順番は Windows でも参考になります（確度：Linux 対応とログの場所は高。回避策は利用者の自作です）。

177582 #11／177582 #12

新機能解説

0.79.3 の配信が利用者側で始まっています。日本語の利用者からは「Bot ごとに Slack へエージェントとして参加できるようになった」「『ミーティングに参加』がなくなった」という報告があります。changelog の先頭は 0.78.1 のままで、公式の説明はまだありませんja新機能

X投稿（@aiuseful さん 11/07 13:40 JST・@kinopee_ai さん 11/07 09:39 JST）／フォーラム（177657 ほか 0.79.3 記載）

Grok Botのバージョンが0.79.3に。Bot単位でSlackにエージェントとして参加できるようになったので、取りまとめ役(Slackに出入りする)を廃止した。Grok Botって、Bot同士のおしゃべりが最も使用量を食うんよね。これは待ちに待ったアプデだったわ。毎回言ってるけど物販実践者はGrok Botを使うべき。
— 個人貿易商タク (@aiuseful) November 7, 2026

Grok Bot 0.79.3、バージョン番号からして不具合修正版かな？と思って見ていたら、「ミーティングに参加」の機能がなくなった。そして、「非表示」ボタンをクリックしたら「おすすめ」欄がなくなってしまった😂
— Kinopee (@kinopee_ai) November 7, 2026

@aiuseful さんは、Slack に出入りする「取りまとめ役」の Bot を廃止し、各 Bot を直接 Slack に参加させたそうです。Bot 同士のやり取りが使用量をいちばん食う、という実感も添えています。@kinopee_ai さんは「ミーティングに参加」の消失と、「非表示」を押すと「おすすめ」欄が消えた点を報告しています。フォーラムでも 0.79.3 を使っている投稿（177615・177657）が出ています。

考察

ここからは意見です。Slack 連携が Bot 単位になったのなら、事務所では「翠さん経由で各担当へ」という窓口の考え方と、Slack 側の通知設計を揃え直す余地があります。ただ、公式の変更点がないまま運用を変えるのは早いので、changelog かヘルプの更新を待ってから判断するのがよさそうです。ミーティング参加機能の消失も、意図的な撤去か一時的なものかは分かりません（確度：低〜中。利用者の自己申告のみで、公式説明はありません）。

@aiuseful／@kinopee_ai／changelog（0.78.1）

実践事例

案件探し→提案書→応募を Grok Bot の「AI社員」に移したら、週の使用量が1日で14%→68%に増えたそうです。原因は媒体を1件ずつ見に行かせていたことで、新着集めは Claude Code が書いたスクリプトに戻し、Grok Bot はふるい分け・提案・相談だけに絞りましたja実践

X投稿（@takayu_29 さん 11/07 18:07 JST）

Grok BotでAI社員の組織づくり、途中経過！【新規営業編】もともとClaude Codeで自動化していた、クライアントワークの案件応募（案件探し→提案書→応募）。これをAI社員どうしで回る自立ループにしたくて、いまGrok Botに移している最中でして。（Macを閉じていても、クラウドで毎日回る形ってことね。）で、作っている途中で気づいた。 Grok Botの週の使用量が、1日で14%→68%。原因は、AI社員に媒体を1件ずつ「見に行かせてた」こと。考える仕事じゃないのに、ページを読むだけでトークンを食っていました。なるほどな、と。これは学び。なので、トークン消費の観点から途中で変更。・新着集め → Claude Code（が書いたスクリプト）に戻す。Grok Botトークンほぼゼロ・ふるい・提案・相談 → Grok BotのAI社員・自分 → 出す案件を番号で選ぶだけこれ、めっちゃおもろいわ。
— たかゆ (@takayu_29) November 7, 2026

人は「出す案件を番号で選ぶだけ」にしている点もポイントです。巡回のような「考えない作業」はスクリプトへ、判断が要る部分だけ Bot へ、という分け方です。

考察

ここからは意見です。このダイジェストの収集も、フォーラムJSONやXの検索は機械的に取り、選定と考察に Bot を使う形にすると、使用量の減り方がかなり違うはずです。翠さんの claude-handoff の方針（重い作業は Claude Code へ）とも同じ方向の実例です（確度：中〜高。本人の数値で、再現性は作業内容しだいです）。

@takayu_29

Grok Bot と Claude Code の役割分担を「手順と優先順位は Grok Bot、実装は Claude Code」と決め、依頼文には必ず「成果物」「触っていい範囲」「人に戻す条件」の3つを書く、という型ですja実践

X投稿（@nakai_kento_ai さん 11/07 08:30 JST）

Grok BotをClaude Codeの代わりだと思ってる人、うちは役割を分けてる手順と優先順位はGrok Bot 実装はClaude Code 曖昧なまま渡すと止まるので、依頼文に「成果物」「触っていい範囲」「人に戻す条件」の3つを必ず書く
— なかいけんと｜経営 × Claude Code (@nakai_kento_ai) November 6, 2026

短い投稿ですが、「曖昧なまま渡すと止まる」という失敗の理由と、その対策がそろっています。

考察

ここからは意見です。「人に戻す条件」を最初から書いておくのは、事務所の「最終判断は末吉さん」という原則を依頼文に落とし込む方法として使えます。Claude Code への指示テンプレートに3項目を固定で入れておくとよさそうです（確度：中。運用の型の紹介で、効果の数値はありません）。

@nakai_kento_ai

Grok Bot のコンピューターのブラウザで別サービス（Muse）に手動でログインしておき、Grok Bot にその画面を操作させて「別モデルでのファクトチェック」に使う、という工夫ですja実践

X投稿（@c0tanpoTesh1ta さん 11/07 18:52 JST）

1. Grok Botのコンピュータ上でブラウザを開く 2. Museにログインする（手動） 3. Grok Botに操作を頼むこれで、別モデルでのファクトチェックとかができて安心な気がしてる。。
— コタのアナログAI紀行 (@c0tanpoTesh1ta) November 7, 2026

同じ日には「Grok で調べて」と頼んだら Grok Bot の PC で Grok の認証を求められた、という投稿（@nisizaki さん）もあり、Bot のブラウザに何がログイン済みかで動きが変わることがうかがえます。

考察

ここからは意見です。一つのモデルの答えを別モデルで確かめるのは、事実と意見を分ける作業に役立ちます。ただ、他社サービスにログインしたブラウザを Bot に操作させると、そのアカウントの利用規約や、ログを誰が見られるかの確認が必要です。顧問先の情報を扱う業務には持ち込まない方が無難です（確度：中。個人の工夫で、手順の詳細は図だけです）。

@c0tanpoTesh1ta／@nisizaki

コンピューターの Update（VMアップデート）をしても、Grok Bot の中に入れていた Claude Code は再インストールされたような形で、そのまま使えたそうですja実践

X投稿（@kashioka さん 11/07 16:15 JST）

Grok botのVMアップデートしたも、Grok bot内でインストールしてたclaude codeは再度インストールされたっぽいけどそのまま使えました。
— 柏岡秀男|小さな会社のスクラム実践講座|有限会社アリウープ代表取締役 (@kashioka) November 7, 2026

1行だけの報告ですが、「Update で箱の中の道具が消えるのでは」という不安に対する実例になります。速報の「箱の交換（中身が消える）」とは別の操作です。

考察

ここからは意見です。Update と、職員による箱の交換・Reset では、残るものが違うと考えた方がよさそうです。事務所の作業ディレクトリや認証設定は、Update では残っても交換では消えるので、退避先を決めておくことが大事です（確度：低〜中。1件の報告です）。

@kashioka

Karpathy さんの「第二の脳」の考え方を、3体の Bot で回す例です。読み手は資料を集めるだけで書き換えず、司書が wiki を書き直し、点検役が毎晩のルーチンで矛盾や古い記述を探します。各ページには「主張・出典・最終確認日」を必ず書かせますen実践

X投稿（@Argona0x さん 11/08 00:16 JST）

holy sh*t. Karpathy's second brain pattern runs on Grok Bot now: stop explaining your life to AI from zero every chat, keep a wiki that writes itself three bots in one group chat, each with its own memory: the reader takes every link, PDF and voice note you drop and never edits it the librarian rewrites every wiki page that source touches, usually 10 to 15 of them the checker wakes up on a nightly routine and hunts c …
— Argona (@Argona0x) November 7, 2026

（要旨）3体の Bot を1つのグループチャットに入れ、それぞれ別の記憶を持たせます。読み手は、投げたリンク・PDF・音声メモを受け取り、手を加えません。司書は、その資料に関係する wiki のページ（たいてい10〜15ページ）を書き直します。点検役は毎晩のルーチンで起き、矛盾・古い主張・どこからもリンクされないページを探します。質問への答えはページとして保存され、使うほど育ちます。新しい資料が古いページと矛盾したら、黙って上書きせずに人へ知らせます。30日新しい出典がないページは「未確認」にします。貼り付け用プロンプトは「生の資料は raw/ にそのまま置き、wiki/ は自分で管理し、良い答えはページとして戻し、毎晩矛盾を点検して。まず構成を見せて、確認するまで何も作らないで」です。

「第二の脳は、間違ったことを自信ありげに覚えていることがある」という前提から、出典と確認日を必須にしているのが要点です。

考察

ここからは意見です。制度改正や補助金の公募要領を追う事務所の調べもの帳として、この「集める・書く・疑う」の分担はそのまま使えます。ただ、毎晩の点検ルーチンと10〜15ページの書き直しは使用量を食うので、対象を1テーマに絞る、という本人の注意書きは守った方がよいです（確度：中。構成の紹介で、使用量の実測はありません）。

@Argona0x

クリエイター273人の X の数字（フォロワー・表示・いいね・返信）を Grok Bot に集めさせ、Claude Code が作ったAPIで自社DBに流し込んでいる例です。Grok Bot が API の仕様を書き、Claude Code が実装した、という分担ですen実践

X投稿（@LoganTGott さん 11/08 00:01 JST）

how I actually use Grok Bot to run a creator platform and a content engine: - let it handle the X data your other tools can't touch. Grok Bot reads X natively, so it pulls follower counts, impressions, likes, and replies for all 273 creators on our platform, no X API key or developer setup needed - let Claude Code build, let Grok Bot feed it. Grok Bot wrote the API spec, Claude built the routes into our app, and now …
— Logan Gott (@LoganTGott) November 7, 2026

（要旨）①ほかの道具では扱えない X のデータは Grok Bot に任せる。X をそのまま読めるので、273人分の数字を X API キーなしで取れる。②Claude Code が作り、Grok Bot が材料を渡す。Grok Bot が API 仕様を書き、Claude がアプリにルートを作り、数字がDBとクリエイターページに入る。③Bot は1体1役。④自分の過去投稿から口調を学ばせ、言ったことだけで下書きさせる。⑤書く前に分野の優れたローンチスレッドを調べ、裏づけのない主張には印をつけさせる。⑥自分と Bot をグループチャットに入れ、気に入った投稿を口調を合わせて書き直させる。⑦API キーは安全な保管欄に入れ、チャットに出さない。

「X を読めることが Grok Bot の強み」という位置づけと、Claude Code との分担がはっきりしています。数字の正確さや取得範囲の検証方法には触れていません。

考察

ここからは意見です。このダイジェストでも X の検索と埋め込みは Grok Bot 側の強みで、HTML生成や加工は Claude Code に寄せられます。顧問先向けには、SNS運用の数値集計を「Bot が集める→表計算に入れる」で始めるのが現実的です（確度：中。本人の運用紹介です）。

@LoganTGott

収集: 2026-11-08 約05:05–05:40 JST。対象は前回号（11/07）以降、おおむね11/07朝〜11/08朝です。英語ソースは翻訳つきです（一部は要約です）。x.ai/changelog/bot の先頭は 0.78.1（10/27 付）のままです。利用者報告では 0.79.3 が配信されていますが、changelog に内容はなく未確認です。x.ai/news に Grok Bot の新しい発表は見当たりませんでした。ヘルプ（cursor.com/help/grok-bot）の目次25項目は 11/07 取得分と差分なしです。status.x.ai は取得時点で進行中のインシデントなしでした（過去分の一覧は今回取得できていません）。フォーラムは latest と職員 Colin さんの 11/07 回答（177615・177601・177582・177575・177646・177622・177625・177576・177624・177638 など）を原文確認しました。176909 は最高 #252 で、職員の新しい投稿はありません。177657 にも職員回答はありません。X は日英キーワードと公式アカウントを 11/06 15:00 UTC 以降で取得し、実在する ID だけを埋め込みに使っています。見送り: Muse との比較感想、GitHub リポジトリ一覧の煽り投稿、仮想通貨トレード、ほかサービスへの乗り換え宣言、@bot の定型返信、職員とされる人物の動画紹介（原動画を未確認のため）。参考: Project の音声通話から作業が渡らない件（177624）は、Colin さんが「入力欄のマイクで音声入力すれば同じ経路で送れる」と案内しています。cursor.directory のプラグイン審査が全件失敗している件（177638）は運営側の問題で、再提出は控えるよう案内されています。Gaps: 週次枠の公式な数値と「他アプリと共有」の対象、学習許可でリセットされる案内の真偽、ファイル読み込み制限が今回の更新で狭まったのか、0.79.3 の公式変更点、箱交換時のデータ救出手段です。