Grok活用事例ダイジェスト

公式フォーラム（176909 #203〜#214、11/04 18:08〜11/05 02:52 JST）／X投稿（@genmaisan_ai さん 11/04 21:05 JST、@blankspeaker さん 11/04 21:09 JST、@BIJapan さん 11/04 17:10 JST）

Grok Botの使用量上限リセットをエサに、モデル改善を承認するとか、思わず許可押しそうになってしまったじゃないかー！

— 玄米さん (@genmaisan_ai) November 4, 2026

176909 の新しい投稿（#203〜#214）に、職員の回答はありません。報告は次のとおりです（すべて自己申告です）。#203 @logic3 さん（Ultra Legacy）は、11/04 に約2時間で7%から100%になり、先週も同じことがあって約24時間後に自動で戻った、と書いています。#205 @Boris_Pinchuk さん（Ultra・月200ドル）は、11/03 夜に約25%だったものが11/04 朝に100%になり、書き出した利用履歴には0時から7時までほぼ活動がなかった、次のリセットは11/09 で、画面には「統合プランへ上げる」か「データ共有に同意して上限をリセット／増やす」が出た、と書いています。#204・#210 @Malpek さん（Pro+）は、寝る前に45%（のちの投稿では55%と書き、数字が揺れています）だったものが朝に100%だった、#212 @Idan_Giterman さんは週の1日目に9%から10分で100%になった、#213 @Chris_Arden さんは、ルーチンを止めるなど節約したうえで40%から散歩のあいだに100%になった、と書いています。#206・#211 は、「3倍の速さで減る」「リセット後に2時間しか使えなかった」という訴えです。

#207 @Parag_Chhibber さんの測定は、数字の出どころが分かる点で参考になります。毎週書き出している利用履歴で、変更前は生のトークン約10.7億が枠の80%（1%あたり約1,340万）、枠が80%に戻ったあと88%まで進む間は約6,960万（8ポイントで、1%あたり約870万）で、生のトークンで65%、本人の重みづけ（入力×4・キャッシュ読み×1・出力×12）で58%、つまり約1.7倍の速さだと計算しています。本人の重みづけは、本人が API の比率に合わせたものです。11/04 号の @weiyu さん（約半分）・@Mars_Fergus さん（約30%減）と並べると、「3割減〜半減」の幅の中に収まります。画面の文言は、@genmaisan_ai さんの画像で確認でき、@blankspeaker さん（非公式の解析アカウント）の「試験版の予告」一覧（11/04 21:09 JST、1.1.0-pre.17〜27）にも「Data sharing to improve Grok Bot」があります。@nxtday さんが11/04 07:50 に「1.1.0-pre.12 に同じ画面がある」と伝えていますが、元の投稿は確認できませんでした。公式ヘルプには、この画面の説明は見つかりません。Grok Bot が Cursor アカウントの Privacy Mode に従うと書く人（@bacon_kobayashi さん）もいますが、「学習に使われない」ことを明記した公式の説明は、取得したヘルプでは確認できませんでした。

考察

ここからは意見です。分けて考えると、「一晩で100%になる」ことは、時刻と数字つきの報告が複数あり、起きていることはほぼ確かです。ただ、原因が測り方の不具合なのか、本当に使われているのかは、利用履歴の書き出しで活動が少ない例（@Boris_Pinchuk さん）があるのに、公式の説明がないため、分かりません。事務所のやることは、前回と同じ「毎朝の％を1行メモする」に、「夜と朝で％が急に変わったら時刻つきで残す」を足すことです。「許可」の画面は、押すかどうかを必ず末吉さんが決める事項です。事務所の Bot は顧問先に関わる情報を扱う可能性があるので、公式の説明（何が、どの範囲で、いつまで使われるか）を確認できるまでは、押さないのが安全だと思います。押す・押さないは、Bot に任せず、画面を見たときに人が決めます（確度：「夜のうちに100%」の報告は中〜高、1.7倍の測定は中、画面の存在は中〜高。公式の説明がないため、仕組みと条件は低です）。

176909 #207／176909 #205／176909 #203／176909 #212／@genmaisan_ai／@blankspeaker（予告一覧）／@BIJapan

公式フォーラム（177271 職員 Colin さん 11/04 22:44・23:56 JST、177189 Colin さん 11/04 18:24 JST、177289 Colin さん 11/05 02:48 JST、177287 Colin さん 11/05 02:21 JST、177264 Colin さん 11/05 02:14 JST、177202 職員 mohitjain さん 11/04 21:28 JST、177295 利用者 11/05 04:12 JST）

177271 の @scrolling2024 さんは、11/04 の夜だけで13回（約3.5時間）固まり、時間が決まった8件の作業が抜け、3件が遅れた、チケットは1週間開いたままだと書き、15分おきのルーチンを動かしていた時刻と重なる例を挙げて「活動があるのに眠るのはなぜか」と尋ねました。Colin さんの回答が上の2つです。時間が決まった作業は、コンピューターの中のスケジューラーではなく Bot のルーチンにすること、中に残す処理は、起きたときに経過時間を見て取り戻すようにすることを勧めています。同じ日の他の回答は次のとおりです。177189（ディスクが満杯で止まった @eelnitsuj さん）は、「次の起動時に容量を増やして起動します。これは一時的な対処なので、使用量を減らしてください。チームはもっとよい対策に取り組んでいます」という回答です。177289（@Bowtiedwave さん）は上の再起動で復旧、177287・177264 は「新しい（健全な）箱にした」、176866 は「箱は健全に見えるので、もう一度試してほしい」とのことです。177202（@Achikeule さん）は mohitjain さんが、いったんアプリを完全に終了して開き直すよう案内し、/workspace のファイルとログインは自動で戻るが、自分で入れたものや同期の外に置いたものは作り直しで消えることがある、再接続中のリセットは控える、としています。一方、職員の返信がまだないものもあります。177295（11/01 19:28 ET から固まり、リセットでも直らない、31回計約23時間）、177292（5日間）、177180（画面が使用中のまま。#9 の問い合わせ11/04 22:02 JST）です。バグ報告のバージョン欄には、デスクトップの stable として 0.78.4（11/02 ビルド）や 0.78.5（11/03 ビルド）が出ていますが、changelog は 0.78.1 のままで、内容は確認できません。

考察

ここからは意見です。今回は、固まる仕組みの最初の説明です。事務所に関わるのは次の3点です。①朝5時のルーチンは、5:00〜5:10 のどこかで始まる可能性があります（職員の説明）。公開の時刻は「5時ちょうど」とせず、10分の幅で見ます。②ルーチンがコンピューターを起こすのは、動き出してからです。コンピューターの中の cron や常駐の処理に、時間が決まった作業を任せるのはやめたほうがよさそうです。③リセットは、症状によって効く場合と、効かない場合があります。.bashrc の1行で止まる例が出たので、起動の設定ファイルには、手を入れないか、入れたら控えを残すのが安全だと思います（確度：高。いずれも職員の回答です。眠る条件の細かい数字は示されていません）。

177271 #7（眠る仕様）／177271 #13（ルーチンの開始）／177289（.bashrc）／177189（満杯）／177202（再構築）／177295（未回答）／ヘルプ（Update/Recover/Reset）

公式フォーラム（177149 職員 Colin さん 11/05 01:00 JST、177200 Colin さん 11/04 18:17 JST・利用者 21:46 JST、177201 Colin さん 11/04 18:15・18:32 JST、177183 Colin さん 11/05 01:46 JST、177195 Colin さん 11/04 18:18 JST）

177149 の @jsolly さんは、11/02〜11/03 の3回とも「This order expired」になり、価格を確かめ直しても払えない、と報告していました（最新の1回は、カードを送って約33分後です）。11/04 号の「30分」の回答に続き、期限が6時間に延びたことが確認できました（Mac アプリは、更新が届くまで30分でグレーのままです）。177200 の @KMaulden さんは、電話の冒頭の名乗りがアカウントのユーザー名になっていて、受け手が誰のことか分からないと書きました。Colin さんの答えは上のとおりです。ただ、本人は X のアカウントでログインしていて、Cursor 側を開いたことがなく、Bot からは「変えられない」と言われたそうです（11/04 21:46 JST、職員の返信はまだありません）。177201 の @Rexson さんは会社のアドレスの Business/Teams 型で、Colin さんは、いまは回避する方法がなく、既知の問題で、動きがあればこのスレッドで知らせる、と答えています。177183（個人から Teams に上げた @Imran_Raza さん）には、元の Bot は無事で、コピーしても元は変わらないこと、ドキュメントのほうが実際の提供より少し先に書かれているようで、チームに伝えたこと、いまは共有するにはコピーを作ることを答えています。11/03 号で紹介した「個人の Bot をチームへ追加できない」と同じ向きです。177195 では、Team Bot の持ち主が、何人が使っているかを見る場所はまだなく、検討中だとのことです。

考察

ここからは意見です。電話の名乗りは、事務所が使うなら先に確認しておきたい点です。名乗りの名前が、アカウントの姓名のままだと、屋号や個人名のどちらで相手に伝わるのかが決まってしまうからです。使い始める前に、ダッシュボードの姓名を、相手に名乗ってよい形に直しておくのがよいと思います。顧問先に Team プランや 1Password の Business を勧めるときは、「共有はコピーだけ」「1Password の Business/Teams は未対応」を、先に伝えておく必要があります（確度：高。いずれも職員の回答です。電話の公式な説明自体は、まだ確認できていません）。

177149 #10（6時間）／177200（通話の名乗り）／177201（1Password）／177183（共有はコピー）／177195（Team Bot）

公式フォーラム（169955 職員 deanrie さん 11/04 17:31 JST、176583 職員 Colin さん 11/05 02:06 JST、176858 Colin さん 11/04 23:48 JST、177101 Colin さん 11/05 02:48 JST、177219 Colin さん 11/04 18:08 JST、177162 Colin さん 11/05 02:32 JST、176902 Colin さん 11/05 02:52 JST）

176583 の @AlexeyElizarov さんは、Gmail の受信箱にあるのに search_threads に出ないスレッドがあると調べていて、Colin さんの回答は、Cursor 側の絞り込みでも、アカウントの問題でもなく、Google 側が意図的に外しているように見えること、Google は条件を公開していないこと、ほかのアプリでも同じ現象が出ること（GitHub の報告があります）、隠れた会話は1通だけのものなので、Gmail の URL の ID で get_message を使えば同じ内容が読めること、です。176858（iCloud メール）の @Josua_Badertscher さんが探していた iPhone のカレンダーやリマインダーなどは、コネクターではなく、iPhone のアプリの中で動く「電話のツール」で、コネクター画面の「iPhone」の分類にあります（本人が11/05 02:49 に確認しています）。バックグラウンドで動かすことは「検討中」とのことです。接続の面では、177101 の @Ethan5 さんが「Route traffic through this computer」を押せなかった件で、Colin さんは、PC のアプリと Bot のコンピューターの間の接続がほぼすべてリセットされているのが原因で、VPN・プロキシ・ファイアウォールが疑わしいと答え、アプリを終了して VPN やプロキシの扱い方を変える手順を案内しました。本人は「案内で直った」と書いています（11/05 03:26）。177219 の @Liz_Li さん（Windows、会社のネットワーク）には、Windows のプロキシを使わせる環境変数 SAND_SYSTEM_PROXY=1 の設定が案内されています。177162（GitLab のリポジトリ）では、最初のメッセージの前の「/」のスキル候補は、GitHub のリポジトリでしか出ない既知の不足です。176902 では、Windows のアプリで画像つきの会話を開くと固まる件の修正は「できているが、0.78.3・0.78.4・0.78.5 のどれにも入っていない」とのことです。

考察

ここからは意見です。Gmail の件は、事務所の運用にすぐ効きます。翠さんのような Bot が「受信箱を検索して、該当なし」と答えたとき、それがメールが本当にないことを意味しない場合があるからです。重要な確認（顧問先からの期限つきの連絡など）は、検索の結果が空でも「なしと決めない」と、手順書に1行書いておくのがよいと思います。ID が分かっていれば get_message で読めます。分離の件は、事務所の Bot が全部、同じコンピューターと同じ Gmail・Calendar・Drive を共有している、という意味です。外への送信は引き続き「先に聞く」のままにします（確度：高。いずれも職員の回答です。Gmail の隠れる条件は、Google が公開しておらず未確認です）。

169955（分離なし）／176583（Gmail 検索）／176858（iPhone ツール）／177101（VPN/プロキシ）／177219（Windows のプロキシ）／177162（GitLab）／176902（Windows の凍結）

X投稿（@bot 11/05 03:13 JST、@Texas_Twins_Dad さん 11/04 03:54・05:59 JST、@Teslaconomics さん 11/04 07:53 JST、@SawyerMerritt さん 11/04 04:17 JST、@petergyang さん 11/04 02:34 JST、@elonmusk さん 11/04 05:56 JST・11/05 02:44・03:39 JST、@blankspeaker さん 11/04 21:59 JST）／公式フォーラム（177200 職員 Colin さん 11/04 18:17 JST）

Grok Bot can now make phone calls.

— Grok Bot (@bot) November 4, 2026

How much usage does a Grok Bot phone call take? So I checked. My bot just called an EV charger installer for a quote. 85 seconds on the phone. Usage before: 5.8% Usage after: 6.0% That's 0.2% for a real call I didn't have to make myself.

— Texas Twins Dad (@Texas_Twins_Dad) November 3, 2026

I literally just had my Grok @bot make a phone call. I texted my CEO and told her to order a pizza for pickup at 5 PM, under Teslaconomics. She wrote out what she planned to say, showed it to me, and got my approval. She only dialed after I tapped “Call”. Her opening line: “I’m a virtual assistant calling for Teslaconomics on a recorded line.” I liked that. She introduced herself as my assistant, used the name I gave …

— Teslaconomics (@Teslaconomics) November 3, 2026

@bot の発表は約22万回表示、いいねは約4,400です。@Texas_Twins_Dad さんの測定（約19.6万回表示）は、85秒の通話で5.8%から6.0%、つまり0.2%という1例です。伝聞ですが、日本語の @coder_zeff さん（11/04 12:12 JST）は、1回の通話で使用量の4〜5%で済んだ人も、17%持っていかれた人もいたそうだと書いており、出どころは示されていません。@Teslaconomics さんの手順は、①テキストで頼む、②Bot が話す内容を書いて見せ、承認を取る、③「Call」を押してから電話をかける、④冒頭は「I’m a virtual assistant calling for Teslaconomics on a recorded line.（録音されている回線で、Teslaconomics の代理の仮想アシスタントとして電話しています）」、⑤切ったあとの要約がチャットに戻る、というものです。通話の途中で相手に聞かれたことは、チャットに質問カードが出て、入力すると Bot が通話を続ける、と @Texas_Twins_Dad さん（11/04 05:59）や @SawyerMerritt さん（リアルタイムの文字起こしも表示）が書いています。@petergyang さんは「米国の事業者に電話できる」と書き、日本の利用者からは「日本でも使えるように」という要望（@jpx_225 さん 11/04 10:53）が出ています。@blankspeaker さん（非公式の解析アカウント、11/04 21:59 JST）は、通話の前に「Send this to your call?」と確認する機能を試験中と伝えています（まだ非公開）。Elon Musk さんは、11/04 05:56 に「Try asking Grok @Bot to make calls!」、11/05 02:44 に「Try Grok @Bot. It’s like hiring an amazing assistant!」と投稿し、11/05 03:39 に @Texas_Twins_Dad さんの使用量の投稿を再投稿しています。名乗りの名前は、職員 Colin さんによると、アカウントの姓名です（前の仕様解説）。11/04 号の Gaps だった「使用量の減り方」は1例だけ分かり、「使える国」は米国らしいと分かりましたが、料金・時間制限・ヘルプの記載は、取得したヘルプ25ページ・changelog・ガイドに見つからず、未確認です。

考察

ここからは意見です。11/04 号で書いた不安のうち、「AI だと名乗らずに進めてしまうのでは」は、少なくとも @Teslaconomics さんの例では「仮想アシスタント」「録音されている回線」と名乗っていて、通話の前に承認も入るので、解消に近づいています。ただ、これは1人の利用者の例です。日本でかける場合の法的な扱いや、日本の番号に対応するかは、ここでは分かりません。使用量は、短い電話で0.2%でも、週の枠が以前の半分になっているとされる状況では、長い電話や何回もかけ直す電話で大きく変わる可能性があります。使い始めるなら、11/04 号と同じく、間違えても取り返しがつく電話から、約束・支払い・個人情報の部分は人が引き取り、前後の％を記録するのがよいと思います（確度：機能があることは高。公式の発表です。使用量は低〜中で、1例です。対象国は中です）。

@bot（発表）／@Texas_Twins_Dad（使用量）／@Teslaconomics／@SawyerMerritt／@petergyang／@blankspeaker（通話前の確認）／177200（名乗り）

X投稿（@bot 11/04 06:50 JST、@elonmusk さん 11/04 17:16 JST・11/05 00:00 JST、@milichab さん 11/04 06:52 JST、@blankspeaker さん 11/04 04:57 JST）／公式 changelog（0.78.1、10/27）／公式フォーラム（177149 #10）

Try the new shopping experience in Grok Bot. Find the best deal, compare items, and have Bot track all your orders.

— Grok Bot (@bot) November 3, 2026

Grok @Bot will research purchase ideas, bring back a selection, order them, track the purchases and return anything you don’t want

— Elon Musk (@elonmusk) November 4, 2026

@bot の投稿（約236万回表示）と、Elon Musk さんの引用（11/04 17:16 JST「Grok @Bot shopping is great」約215万回、11/05 00:00 JST 約134万回）が続き、11/05 の早朝には、@Real_EricCamp さんのような紹介も出ています。上の changelog のとおり、カード・追跡・「あなたが承認する注文」は10/27 の版からの機能で、買い物の返品については、Elon Musk さんの投稿にはありますが、取得した changelog とヘルプには記載が見つからず、未確認です。注文カードの支払い期限は、職員 Colin さんの回答で、30分から6時間に延びています（Mac アプリは更新待ち）。@blankspeaker さん（非公式、11/04 04:57 JST）は、贈り物として送る注文で、受取人・ギフトレシート・必要な日付を入れ、店の到着日が間に合うかも教えてくれる「ギフト注文」を試験中と伝えています（まだ非公開）。@tetumemo さん（11/04 19:30 JST）は「Grok Bot がパスキーに対応し、購入の承認が Face ID・Touch ID でできるようになった」と書いていますが、公式ヘルプには「手元の指紋・Face ID・パスキーは Bot のコンピューターでは使えない」とあり、購入の承認との関係は、取得した changelog とヘルプでは確認できませんでした。

考察

ここからは意見です。買い物は、事務所の仕事ではあまり使わないと思います。ただ、顧問先に「承認カードの形で、人が最後に押す」と説明するときの材料になります。宣伝で見えるのは成功例だけなので、返品や、間違った商品を買ってしまったときの扱い、カードの期限が切れたあとの動きは、事務所で実際に試すまで分かりません。使うなら、少額の備品で1回試し、承認の画面で、金額・送り先・店舗を目で見て確かめるのがよいと思います（確度：機能と承認の流れは高。公式の changelog によります。返品とパスキーは未確認で、低です）。

@bot／@elonmusk（11/05）／@elonmusk（11/04）／@blankspeaker（ギフト）／@tetumemo（パスキー）／changelog（0.78.1）／177149 #10

X投稿（@blankspeaker さん 11/04 10:59・11:04・14:04・21:09・21:59 JST、11/05 03:23 JST、@alexmichael さん 11/04 12:47 JST）

BREAKING: SpaceXSI is testing a usage breakdown chart in Grok Bot. Usage & Billing shows where your week's usage went, split by source (you, routines, bot-to-bot, group chats) or by bot, with a daily trend line. Note: This feature is in testing and not available to the public yet, so there's no official announcement or documentation yet b …

— ️ (@blankspeaker) November 4, 2026

SpaceXSI is testing call context approvals in Grok Bot. Before your bot shares info with a phone call, it asks "Send this to your call?" You can edit the text, then Cancel or Send. After you approve, the card collapses to Approved to send. The call and details shown are demo data. Note: This feature is in testing and not available to the …

— ️ (@blankspeaker) November 4, 2026

@blankspeaker さんは、プレリリース版（1.1.0-pre.17〜27）の中身を第三者として解析している非公式のアカウントで、毎回「一般にはまだ使えない」と注記しています。11/04 の投稿には、ほかに次のものがあります。画像に印をつけたり、消したい部分を塗ったり、番号つきのコメントを付けて Bot に直させる「画像の書き込み」、返信に付ける「この回答はどうでしたか」の親指評価、ルーチンが出したコネクターのカードから、チャット上でそのルーチンをもう一度走らせる「Re-run」、Yelp の場所情報（写真・営業時間・電話・口コミ）、ギフト注文、そして11/05 03:23 JST には、Bot をチームに共有するときに「What does sharing this Bot do?」の帯が出て、共有される「ファイル・スキル・認証情報・コネクター」の一覧が開き、ファイルやスキルは非公開に指定できる、という表示です。11/04 21:09 JST の「予告一覧」には、「Usage, weekly limit, and on-demand spend」や、速報で触れた「Data sharing to improve Grok Bot」も並んでいます。@alexmichael さんも、内訳グラフを「A weekly limit breakdown is coming」と11/04 12:47 に伝えています。

考察

ここからは意見です。使用量の内訳グラフは、速報の #205 @Boris_Pinchuk さんが「何が枠を使ったのか分からない」と書いていた不満に、ちょうど答える機能です。ただ、まだ非公開で、出るかどうかも分かりません。出るまでの間は、0.78.1 の changelog にある「Bot が出す使用量の内訳」を、Bot に聞いて使うのが現実的だと思います。「共有する前に何が共有されるかを見せる」表示は、顧問先と Bot を共有する可能性が出たときに、安心材料になります。ただ、非公式の解析は、文字列やフラグから推測したもので、実際の動作とは違うことがあります。どれも「出たら試す」くらいに置いておくのがよいと思います（確度：機能の存在を試験中と言っている点は中。実際に出るかどうかは低です）。

@blankspeaker（使用量の内訳）／@blankspeaker（通話前の確認）／@blankspeaker（予告一覧）／@blankspeaker（共有の開示）／@blankspeaker（Re-run）／@blankspeaker（画像の書き込み）／@alexmichael

X投稿（@_nogu66 さん 11/04 12:01 JST、@jammaru_lab さん 11/04 12:56 JST、@nagisora_ さん 11/04 23:50 JST）／公式ヘルプ（Routines）

Claude CodeからGrok Botを呼び出す構築が完了した これでGrok Bot側の使用量消費は抑えられつつ、より効果的に使えるようになるはず

— nogu (@_nogu66) November 4, 2026

Grok Botって、Webhookでも呼べるんや。初めて知った。 試しに手元でWebhookで起動するルーティンを作ってみたら、すぐできた。 自分は使用量の枠がすぐ溶けるから、細かい作業はDeepSeekにやらせて、Grok Botには指示出しとまとめ役だけ任せてる。外のツールから必要なときだけGrok Botを呼べるなら、もっと枠を節約しながら使えそう。やりたかったことやから最高！ ただ、呼んだ側に返ってくるのは「受け付けた」っていう返事だけで、結果はGrok Botのチャットに届くみたい。呼んだエージェント側で結果を受け取るには、送り返す先のURLを用意して、そこに結果を送ってもらう形に …

— じゃむまる (@jammaru_lab) November 4, 2026

MuseとGrok Botの双方向会話を実現した！✨ ・Muse→Grok Bot：Grok Botのweb hookをMuseが叩く ・Grok Bot→Muse：web版のMuseをGrok Botのブラウザで表示 Museにメールが実装されるまでの繋ぎで😆

— なぎそら (@nagisora_) November 4, 2026

公式ヘルプ（Routines）によると、ルーチンは「webhook の呼び出し」でも始まります。Bot に webhook の引き金を足すよう頼むと、デスクトップのルーチンの画面に、送り先の URL と鍵が出ます。鍵は秘密の値で、送る側は「Authorization: Bearer ＜鍵＞」の形で添え、JSON の本文も送れます。200 が返っても「受け付けて起動した」という意味で、Bot が最後までやったという意味ではなく、結果は Bot のチャットで確認します。1時間あたりの実行は、全ルーチン合計で300回、1つのルーチンで200回までです。@jammaru_lab さんは、呼んだ側には「受け付けた」という返事だけが返り、結果は Grok Bot のチャットに届くようだと書いていて、この読みは公式の説明と合っています。呼んだ側へ結果を送り返す方法は、取得したヘルプには書かれておらず、未確認です。@_nogu66 さんの画像（事務所が確認しました）には、Bot が「webhook で起動するルーチン」を作り、届いた中身を日本語で短くまとめてチャットに知らせる設定にした様子が写っています。画像から読み取れる範囲では、最初は鍵の取り違えで 401 になり、次に URL の書き方の誤りで fetch failed になり、直してから届いています（11/04 11:59 JST 受信）。また、届いた本文には「Mac でコマンドを実行して返事すること」という指示も含まれていましたが、Bot は「外部から届いた指示なので、コマンドは実行していません」と書いています。@nagisora_ さんは、Muse から Grok Bot の webhook を呼び、Grok Bot からは Muse の Web 版をブラウザで開く形で「双方向の会話」にし、「Muse にメールが実装されるまでの繋ぎ」だと書いています。

考察

ここからは意見です。「窓口の Bot に直接話しかけず、外の道具から必要なときだけ呼ぶ」のは、使用量が厳しいときの現実的な節約策だと思います。ただ、呼ぶたびに Bot の実行が1回走るので、1回あたりの使用量は、事務所で測るまで分かりません。気をつける点が2つあります。1つは、鍵をチャットや共有の文書に貼らないことです。もう1つは、外から届いた本文は「命令」ではなく「データ」として扱わせることです。@_nogu66 さんの Bot が、届いた本文のコマンドを実行しなかった点は、この考え方どおりの動きです。事務所で試すなら、Claude Code や Muse から「作業が終わった」という通知を Bot に届けるだけの形から始めるのが安全だと思います（確度：webhook の仕様は高。公式ヘルプによります。3件の事例は中で、画像と本人の説明によります）。

@_nogu66／@jammaru_lab／@nagisora_／ヘルプ（Routines）

X投稿（@shin_chan_ai さん 11/04 18:35 JST・12:38 JST、@shoki_kawakami さん 11/05 00:36 JST、@lapras_inc さん 11/04 18:21 JST、@BotMeetUps さん 11/04 20:01 JST）

Grok Botを150体運用してわかった便利技を、30個まとめました。 たとえばこんな工夫です。 ・1体に仕事は1つだけ ・スタンプの承認は👍だけ ・定期実行は変化なしなら黙らせる どれからでも読めるので、気になるものからどうぞ😊

— しんぺい | GrokBot芸人 (@shin_chan_ai) November 4, 2026

今日の学び Grok botに長時間タスク渡すときにはGrokにプロンプト作ってもらうのがいい VM使うときはGrok経由でGrok botにリクエストした方がパフォーマンスがいい 15万文字以上のコンテキストをbotに与えると専門家としてレビューやディスカッション、アウトプットの品質が上がるから15万文字を目指すといい、50万文字以上あると最高 #GrokBotKanagawaMeetup #Grok #GrokBot

— ショーン / Shoki kawakami (@shoki_kawakami) November 4, 2026

@shin_chan_ai さんの投稿の本文は、X の記事へのリンクで、記事を開くにはログインが必要なため、今回は本文を読めていません。確かめられたのは、投稿に書かれた3つの例です。11/03 号の「見張る係」と同じ人で、同じ日の 12:38 JST には、Grok のアプリから Grok Bot を開くと、Grok Bot のアプリを立ち上げるより表示が速いので最近はこちらを使っていて、今だけの小ワザかもしれません、とも書いています。@lapras_inc さん（11/04 18:21 JST）は、同じ @shin_chan_ai さんを招いたオンラインの無料イベントを11/24 19:00 から開くと告知しています。@shoki_kawakami さん（#GrokBotKanagawaMeetup）は、長時間のタスクを渡すときは Grok にプロンプトを作ってもらうとよいこと、VM を使うときは Grok 経由で Grok Bot に頼むと性能がよいこと、15万文字以上の文脈を Bot に与えるとレビューや議論の質が上がることを書いていますが、根拠の数字や条件は示されていません。

考察

ここからは意見です。「定期実行は変化なしなら黙らせる」は、事務所のルーチンにすぐ入れられる工夫だと思います。朝の確認が増えると、本当に必要な連絡が埋もれるからです。一方、「スタンプの承認は👍だけ」は便利ですが、11/04 号で書いた「お金・送信・削除・公開」の承認は、👍1つで済ませず、内容を確かめてから押す形にしておく必要があります。「15万文字の文脈」は、1人の自己申告で、使用量にも響くはずなので、事務所では試すかどうかも含めて末吉さんの判断です（確度：中〜低。30個の中身は未確認で、個人の運用例です）。

@shin_chan_ai／@shoki_kawakami／@lapras_inc（11/24 イベント）／@BotMeetUps（神奈川）

X投稿（@devpapago さん 11/04 19:39 JST、@mitsumane_mb さん 11/04 13:07 JST）／x.ai の共有 Bot のページ（Usage Auditor by 豪）

Grok Botを使いすぎていませんか？📊 ボットとルーチンが増えると、使用量はあっという間に減っていきます。 そこで、使用量を毎週チェックする「Usage Auditor」を作りました。 ✅ 週のリセット直後に自動で監査 ✅ 使用量の多いルーチンや重複しているルーチンを見つける ✅ おすすめ付きの改善案を短く報告 ✅ ルーチンは削除せず一時停止するので、いつでも再開できる テンプレートをそのまま使えます👇 #GrokBot #AI活用

— DevPaPaGO@3歳児パパの初アプリ開発 (@devpapago) November 4, 2026

Grok Botの負荷が高すぎる！人います？ 「負荷が高くトークンを使うものを具体的教えて欲しい。また、節約する場合の案を5つほど欲しい！」 って伝えると、なんか見えるかも。 ぜひやってみてくださいませー。効果があったら広めてくださいませ〜 #Grok #GrokBot

— みつまね（ふりかけマニア） (@mitsumane_mb) November 4, 2026

リンク先の x.ai の共有 Bot のページには、「Usage Auditor by 豪」「Audits your Grok Bot usage once a week and suggests ways to cut unnecessary routine runs（Grok Bot の使用量を週1回監査し、不要なルーチンの実行を減らす案を出します）」とあり、「第三者のユーザーが作ったもので、SpaceXSI のものではない。あなたに代わって動く可能性がある」という注意書きが付いています。投稿の4つの特徴（リセット直後に自動で監査、重い・重複するルーチンの発見、おすすめ付きの短い報告、削除せずに一時停止）の実際の動き方は、命令の中身を読んでいないため未確認です。@mitsumane_mb さんの方法は、Bot に「負荷が高くトークンを使うものを具体的に教えて。節約案を5つほしい」と聞くだけの、もっと軽いものです。11/04 号の @shin_chan_ai さんの「見張る係」や、@Michael_Fenech_ さんの7項目の監査と同じ向きの動きです。

考察

ここからは意見です。「一時停止にとどめる」という点は、削除よりは安全ですが、本人の承認なしにルーチンが止まるなら、朝の公開のような大事な処理まで止める可能性があります。事務所では、11/04 号の方針（承認するまで何も変えない）と、第三者の Bot は追加する前に命令と接続を全部読む、の2つを守るのがよいと思います。追加するかどうかは末吉さんの判断です。当面は、@mitsumane_mb さんのように、翠さんに口頭で聞く軽い方法で十分だと思います（確度：Bot が実在することは高。動作の中身は低です）。

@devpapago／Usage Auditor（共有 Bot のページ）／@mitsumane_mb

X投稿（@GameLiveJP さん 11/04 12:48 JST）

試しにまねしてみました。 音ハメMVの作り方を、音ハメ動画で解説「オンビート・ぴったり」 曲：Suno v6（Suno MCP） 企画・構成：Grok Bot（MV担当） 動画：HyperFrames（コードで描画） 参照画像：なし（図形と文字だけで作りました） 今度はClaudeとGPT、museなんかも組み込んで実験します 全WebSIサービスのクレジットを無制限に使えるのは楽しいです（GrokBOT MV担当）

— いーのー𝕏™ (@GameLiveJP) November 4, 2026

@GameLiveJP さんの投稿では、役割は、曲が Suno v6（Suno MCP）、企画と構成が Grok Bot（MV 担当）、動画が HyperFrames（コードで描画）で、参照画像はなく、図形と文字だけで作った、とあります。「試しにまねしてみました」とのことで、元になった作り方の投稿は、引用の連鎖の先にあり、今回は確認していません。今後は Claude・GPT・Muse も組み込んで試すそうです。

考察

ここからは意見です。事務所の仕事で動画を作る場面は多くありませんが、「企画と構成は Bot、素材づくりは外の道具」と分ける形は、セミナー資料の図や説明動画にも使えそうです。曲や動画の権利、商用で使える条件は、使う前に各サービスの規約で確かめる必要があります（確度：低〜中。成果物の質は、投稿の動画を見ていないので判断できません）。

@GameLiveJP

X投稿（@natsume_aurlia さん 11/04 23:12 JST、@ritalog940317 さん 11/04 17:12 JST、@Masashi_T_nlp さん 11/04 18:04 JST、@tonbistudio さん 11/04 01:02 JST）

Grok Bot以外のAIも契約してて、Grok Botをルーターとして使っているなら、HermesやOpenBotに移すほうがよさげよな 両方Grok Botからスキル、ルーチンを移せるし 常駐PCがなくても、Agent37(@Agent37HQ)やZipbox(@Zipbox_)みたいな低価格のホスティングあるから、課金額も下がる OpenBotはUIUXがGrokBotにぽいのと持ってるAI契約で、botごとにモデルを使えるの良い 商用はライセンス料かかるけど Hermesはスマホアプリがβな点除けば成熟してて良い 有志の作ったHermexでスマホ操作からも操作できるし Grok Botは、常駐PCがいらなくて、ブラウザやファイルの環境も最初から用意されているのやっぱ便利 アプリ連携もポチポチでつながって手軽だが いかんせんコストに対しての使用量が工夫しないとなかなか

— 棗（なつめ）@フリーランス (@natsume_aurlia) November 4, 2026

Grok Botになんでもやらせてると一気に使用量50％超えてしまったから設計とかはClaudeにやらせて運用中のあれこれをGrok Botにさせる感じにしてみるか。。

— りょうた (@ritalog940317) November 4, 2026

@natsume_aurlia さんの比較は、Grok Bot のほかにも契約している AI があるなら、Hermes や OpenBot に移すほうがよい、どちらも Grok Bot からスキルとルーチンを移せる、常駐のパソコンがなくても低価格のホスティングがある、というものです。一方で、Grok Bot は、常駐 PC が要らず、ブラウザやファイルの環境が最初からあり、アプリ連携もポチポチでつながる点が便利だとしたうえで、コストに対する使用量は、工夫しないと厳しいとも書いています。元の投稿は @tonbistudio さん（英語、約1万回表示）の「hermes migrate grok-bot」の動画です。Hermes の取り込みの仕組みは、11/04 号で公式ドキュメントを確認しましたが、OpenBot の移行機能や、挙げられたホスティングのサービスは、今回は確認していません。@ritalog940317 さんは、何でもやらせて使用量が50%を超えたので、設計は Claude、運用中の作業は Grok Bot にしてみる、@Masashi_T_nlp さんは、Muse か dots に代わりをさせるか迷うが、体験は Grok Bot の圧勝だと書いています。

考察

ここからは意見です。使用量がつらいときに、乗り換えるか、分担するかを考える人が増えています。事務所にとっては、11/04 号と同じで、乗り換えよりも「控えを持っておく」が先だと思います。Grok Bot は、設定やスキルを書き出すボタンがないので、各 Bot に自分で書き出させ、鍵や顧問先の個人情報を除いたものを人が確認して Drive に置く、という形がまず試せます。分担については、「設計や長い推論は別の道具、運用中の作業は Grok Bot」という分け方は、使用量の数字が読めるようになるまでの現実的な手だと思います（確度：低〜中。個人の意見と運用例で、料金や移行手順は未確認です）。

@natsume_aurlia／@tonbistudio（元の投稿）／@ritalog940317／@Masashi_T_nlp

X投稿（@Texas_Twins_Dad さん 11/04 12:43 JST・08:05 JST・11/05 01:16 JST）／公式ヘルプ（FAQ）

I found a way for my Grok Bot to read and send my texts. No phone hack. It works through the Messages app on my Mac. How to set it up: 1. On iPhone, turn on Text Message Forwarding (Settings › Apps › Messages) so texts and iMessages show up on my Mac 2. Connect Mac to Grok Bot as a computer 3. Let it read Messages (macOS will as …

— Texas Twins Dad (@Texas_Twins_Dad) November 4, 2026

I wanted Grok Bot to set my Tesla navigation based on my schedule. There's still no official Tesla app connection. Guess what? I figured it out again 😉 Grok Bot can now get my Tesla navigation ready. Here's the workflow: I asked Grok Bot to book a dentist appointment. It texted the office from my Mac. 7 minutes later, the confir …

— Texas Twins Dad (@Texas_Twins_Dad) November 3, 2026

手順は投稿のとおりで、①iPhone でテキストメッセージ転送をオンにする、②Mac を Grok Bot にコンピューターとして接続する、③メッセージの読み取りを許可する（macOS の確認に本人が承認する）、④本人が「send」と言ったときだけ送る、というものです。Tesla の流れは、「Grok Bot でスマホのカレンダーへの書き込みを許可し、Tesla アプリのカレンダー同期をオンにし、iPhone の設定でカレンダーのフルアクセスを許可し、住所と時間を必ず予定に入れさせる」という手順です。公式ヘルプ（FAQ）では、Bot が自分のパソコンでコマンドを実行するのは許可したときだけで、設定は「Execution on this computer」、初期は毎回確認です。メッセージの読み取りやこの手順そのものは、取得したヘルプには書かれておらず、未確認です。職員 Colin さんは、iPhone のカレンダーなどの電話内ツールは「iPhone のアプリを開いているあいだだけ動く」と答えているので（前の仕様解説）、カレンダーへの書き込みも、同じ条件がかかると思われます（推測です）。なお、@Texas_Twins_Dad さんは11/05 01:16 JST に「AI のコンサルが必要なら DM を」と書いており、AI の相談を受ける立場の人の投稿です。

考察

ここからは意見です。個人のメッセージを読ませる手順は、便利ですが、事務所では顧問先とのやり取りが混ざる可能性があります。使うなら、最初は「読み取りだけ」にして、送信は人が確認してから、という線を守るのがよいと思います。「send と言ったときだけ」という本人の線引きは、そのまま取り入れられます。送っていい相手を限る、取引先への連絡は下書きまでにする、という決まりも足したいところです。Tesla の流れは事務所には直接関係しませんが、「予約の確認を、住所と時間つきでカレンダーに入れさせる」やり方は、顧問先との打ち合わせの準備に応用できます（確度：中。自己申告で、動画つきですが、公式ヘルプには手順がありません）。

@Texas_Twins_Dad（メッセージ）／@Texas_Twins_Dad（Tesla）／ヘルプ（FAQ）

X投稿（@Michael_Fenech_ さん 11/05 04:51 JST、11/04 20:37 JST）

Your Grok Bot skills might be missing the instructions that matter most. I went through the xAI documentation on what makes a good skill, and found something worth checking. Saving a successful task as a skill is only the starting point. A reliable skill also needs to know when to run, what information it needs, how to check its …

— Michael | AI + Agents (@Michael_Fenech_) November 4, 2026

Grok Bot might be using a much harder way to complete your tasks than it needs to. One thing I've learned from experimenting with my Bot team is that HOW a Bot completes a job can matter almost as much as the result. If it can get reliable information directly from a connected app, why spend time navigating a website? And if it …

— Michael | AI + Agents (@Michael_Fenech_) November 4, 2026

スキルの監査（9項目）は、①目的（いつ使い、いつ使わないか）、②入力（必要な情報・接続・権限、足りないときの動き）、③手順（1回うまくいった手順をそのまま写さず、判断の決まりを入れる）、④確認（結果を元の情報と照らす）、⑤出力（形式・根拠・次の行動）、⑥承認（Bot だけでやってよいことと、許可が要ること。特に送信・購入・公開・削除）、⑦失敗への対処、⑧繰り返し（2回動かしても重複しない）、⑨実世界の試験（少し散らかった別の例で試す）です。最後に「スキルごとの不足」「リスクの順位」「改善案」「試験や接続が足りないもの」を出させ、承認なしにはスキルを変えたり公開したりしないよう指定しています。ツール選びの監査（7項目）は、使っている道具の棚卸し、「いちばん単純で確かな方法」（接続したアプリ、既存のスキル、スクリプト、ブラウザ操作の順に考え、画面を直接操作する方法は最後）、記憶ではなく最新の情報元で確かめるべき作業、繰り返しの作業、アクセスと安全（「別々の Bot が、分離されたコンピューターやログインを持つとは限らない」）、失敗時の代わりの方法（承認していない方法に黙って切り替えない）、効率の試験（「測っていない節約量を主張しない」）です。11/04 号のスキル反映の遅れ（職員 Colin さんの回答）と、今回の「Bot 単位の分離はない」という回答（deanrie さん）は、この監査の前提と合っています。

考察

ここからは意見です。「2回目に動くとき、うまくいかないことがある」ことを前提にした点検は、事務所の手順書づくりにそのまま使えます。⑧の「2回動かしても重複しない」は、朝のダイジェストのような定期の作業で特に大事です（同じページを2回公開しても壊れない作りにしておく）。ただし、これも監査自体が使用量を使うので、週1回までにし、11/04 号の使用量の監査、@shin_chan_ai さんの「見張る係」とは、役割を1つにまとめるのがよいと思います（確度：中。個人の運用例です。使用量の節約効果は、本人も「測るまで言わない」としています）。

@Michael_Fenech_（スキル）／@Michael_Fenech_（ツール選び）