← 一覧に戻る

Grok活用事例ダイジェスト

2026-10-21・速報1 / 仕様2 / 新機能2 / 実践4　※英語は日本語訳つき。対象は10/19朝〜10/20朝です。主ピックは、利用量メーターと Grok 4.7 Fast の不具合を職員が認めた件、グループチャットの利用量の数え方、Cursor Projects のローカル作業機の注意点、iPhone のアクションボタンから Bot と話せる新機能、利用量 CSV を Bot 自身に分析させる使い方、Grok Bot と Claude Code の役割分担です。公式 changelog は依然 0.70.2（10/11）のままです。

← 一覧に戻る

Grok活用事例ダイジェスト

2026-10-21・速報1 / 仕様2 / 新機能2 / 実践4　※英語は日本語訳つき。対象は10/20朝〜10/21朝です。主ピックは、公式 changelog にようやく 0.71.2 が載ったこと、Bot メールの受信遅延を職員が認めたこと、Bot が「最後に人に聞く」までの6段階の順番、シェル出力に秘密の値が出てしまう問題と回避策の穴、公式ブログの障害対応 Bot 事例（204件を約10分で処理）、スタックチャンに Bot を入れた AI 秘書です。

速報

公式 changelog に 0.71.2 が掲載、Bot メールの受信遅延は職員が「追跡中」と回答en

一次確認（x.ai/changelog/bot、取得 10/21 05:05 JST ごろ）

changelog の先頭が「Oct 14, 2026 v0.71.2 Smarter notifications and larger file attachments（0.71.0 と 0.71.1 を含む）」になりました。10/14 号から続いていた「安定版は 0.71.2 なのに公式 changelog は 0.70.2 のまま」というずれは、これで解消です。中身は新機能解説で紹介します。x.ai/news には 10/20 付で公式ブログ「Using Grok Bot to detect and respond to incidents」が載りました（実践事例で紹介します）。status.cursor.com は All Systems Operational でした。

公式フォーラム（職員 deanrie さん、10/20 13:22 JST）

There’s currently an issue with delays for incoming mail to Grok Bot addresses, and we’re tracking it. Emails may reach the bot noticeably later than when they were sent.
Grok Bot のアドレスに届くメールが遅れる問題が起きていて、追跡中です。送信から目立って遅れて Bot に届くことがあります。前日に送ったテストメールなら、差出人アドレスを添えてもう一度 Bot に検索させてください。すでに届いているかもしれません、という回答です。報告者の1人は 10/21 03:59 JST に「2時間遅れで届いた」と書いています。

同じ日のフォーラム（職員回答のあるもの）

Grok Bot のコンピューター上で Cursor CLI の agent -p が「Connection lost, reconnecting」で止まる件は、原因が判明しました。CLI がセッション前にマーケットプレイスのプラグインを GitHub から SSH で同期しようとし、外向きの SSH（22番ポート）がふさがれていると1件あたり約30秒待ってしまう、と職員 Colin さんが説明しています（既知の問題として追跡中）。報告者は git config --global url."https://github.com/cursor/".insteadOf で SSH の URL を HTTPS に置き換えて解決しました。また、単体の Cursor Pro（月20ドル）はレガシー扱いで新規には申し込めず、Upgrade を押すと The X Subscription に案内される、と職員 mohitjain さんが回答しています。

考察

ここからは意見です。メールの受信を合図に動くルーチンは、当面「数時間遅れることがある」前提で使うのが安全です。急ぎの問い合わせ転送には向かないので、急ぐものは別の通知経路を残しておきたいところです。CLI の件は、Bot のコンピューターでは SSH が通らないことがある、という点が大事です。git の取得は HTTPS を基本にしておくと、同じ詰まり方を避けられます。

公式 changelog／フォーラム：Bot メールの受信／フォーラム：CLI が止まる件／フォーラム：Cursor Pro $20

仕様解説

Bot は「人に聞く」を最後に回す。手持ちの知識 → コネクタ → Web → ブラウザ → コンピューター → 本人、の6段階en仕様

X投稿（@GrokBotRadar、ファンアカウント、10/21 02:46 JST）

Grok Bot は、あなたに聞くのを最後に回すように作られています。聞くのは6段階の6番目です。Grok Bot チームの leerob さんが Stanford の授業で、Bot が試す順番を説明しました。安くて確実なものから順に、(1) すでに知っていること、(2) コネクタか API、(3) Web 検索、(4) 自分のブラウザ、(5) コンピューター全体、(6) あなたに聞く、です。下に行くほど遅く、高く、危なくなります。だから毎日使うアプリはつないでおけば、Bot は2段目にとどまり、ブラウザでクリックして回らずに済みます。彼のルールは「コネクタが壊れたら、ブラウザでこっそり回り込まず、止まって伝える」です。

コメント

出典はファンアカウントによる授業動画の紹介で、授業そのものの一次資料は今回確認できていません。ただ、投稿の順番と「壊れたコネクタをブラウザで回り込まない」というルールは、当事務所の Bot の日々の動き（まずコネクタを探し、ない場合だけブラウザを使い、コネクタの不具合は回り込まずに報告する）とも合っています。投稿は、Bot に「ブラウザでやっている定例作業のうち、コネクタのほうが速いものを、つなぐべきアプリ名つきで挙げて」と聞いてみることも勧めています。

考察

ここからは意見です。顧問先から「Bot が遅い、利用量が多い」と相談されたときは、まずブラウザ操作で回している仕事がないかを見るのが近道だと思います。会計や予約などコネクタのあるサービスは、つなぐだけで速さと利用量の両方が改善しやすいです。逆に、コネクタの認証が切れたまま気づかないと、Bot が止まって報告してくる回数が増えるので、月1回の接続確認を習慣にするとよいと思います。

@GrokBotRadar

シェルの出力に秘密の値がそのまま出てしまう。利用者の回避策と、その抜け穴en仕様

公式フォーラム（機能要望、Capital_EyeMotors さん、10/20 10:29 JST〜）

one bot ran a command that listed the box environment, and two of our saved secrets came out in plain text in a tool output file, while the others were masked. … could the platform mask secret values everywhere by default (env listings, tool output files, logs)
ある Bot が環境変数を一覧するコマンドを実行したところ、保存していた秘密の値のうち2つがツール出力ファイルに平文で出てしまいました（ほかは伏せ字でした）。気づいてファイルを消し、秘密を作り直しました。環境変数の一覧、ツールの出力ファイル、ログのすべてで、秘密の値を初期設定で伏せてほしい、という要望です。秘密ごとの「絶対に表示しない」設定も提案しています。

コメント

投稿者はまず ~/.bashrc で env と printenv を伏せ字版に差し替えましたが、ほかの参加者から抜け穴が次々に指摘されました。env TEST=1 のように引数をつけると素通りすること、command env やフルパスの /usr/bin/env で関数を飛ばせること、Bot のシェルは非対話の bash -c なら .bashrc をそもそも読まないこと、/proc/self/environ や export -p でも見えることです。投稿者は最終的に、伏せ字版を PATH の先頭に置き、環境変数をまるごと出さないチームルールを作り、秘密は常時の環境変数から外して、必要なスクリプトだけが読む鍵つきファイルに移した、と書いています。職員の回答はまだありません。

考察

ここからは意見です。シェル側の工夫は「うっかり」を減らす程度で、確実な対策にはならないと受け止めるのが妥当です。このダイジェストも Cloudflare のトークンを作業フォルダの .env に置き、デプロイスクリプトだけが読む形にしています。Bot のコンピューターは同じアカウントの Bot 全員で共有なので、秘密は「必要な1か所だけが読む」「出力を他人に見せる前に値が混ざっていないか見る」の2点を、顧問先にも最初に伝えたいところです。

フォーラム：mask secret values in bot shell output

新機能解説

0.71.2 の公式 changelog：プラスつきアドレスごとのルーチン、入力済みフォーム、Bot 同士のやり取りを管理者が止める設定などen新機能

X投稿（@ericzakariasson eric zakariasson さん、10/20 06:46 JST）

Grok Bot 0.71.2 が出ました。通知が賢くなり、ファイルは250MBまで（動画は1GB）、1メッセージに20個まで添付でき、フォームは入力済みで届きます。ほかにもたくさんあります。

公式 changelog（New から抜粋・訳）

・Bot は name+shop@ のようなタグつきの自分のアドレスから送信でき、そのタグに設定したルーチンはそのタグ宛てのメールでだけ動きます。
・Bot が入力を頼むフォームは、わかっている項目が埋まった状態で届き、送信前に直せます。
・チーム管理者はダッシュボードの Bot capabilities で Messaging between Bots をオフにでき、メンバーの Bot 同士でメッセージや仕事の引き継ぎをできなくできます（Teams）。
・Enterprise の管理者は、メンバーの Grok Bot コンピューターを作り直し・停止・削除できます（Enterprise）。
・Bot のコンピューターのディスクが残り少ないと、Bot が一度だけ知らせ、大きいファイルを挙げ、同意したときだけ消します。

コメント

Improved には、Mac や Windows で Grok Bot を使っている間は通知をスマホではなくその PC に出すこと、音声通話が切れても同じ会話のまま再接続すること、プラグイン由来のスキルを24個から200個まで使えるようになったこと、日付やいいね数の条件つき X 検索が拒否されず結果を返すようになったことなどが並びます。Fixed には「オフラインの自分の PC 向けの作業を、黙って別の PC で実行せず知らせる」も入っています。Fixed の一覧は非常に長く、今回は主な項目だけ拾っています。

考察

ここからは意見です。事務所で効きそうなのは2つです。1つは、タグつきアドレスで「請求書用」「問い合わせ用」のようにメールの入口を分け、入口ごとに別のルーチンを動かせることです（ただし速報のとおり、受信の遅延は解消待ちです）。もう1つは、ディスク不足のときに勝手に消さず同意を取る動きで、このダイジェストのように画像や原稿がたまる作業でも安心材料になります。

公式 changelog／@ericzakariasson

X で @bot をタグして「新しい Bot を作り、5日間毎日まとめて」と頼む。開発チームの紹介動画も公開en新機能

X投稿（@GeoffreyHuntley geoff さん、10/21 00:40 JST）

@bot このスレッドへの返信を確認して、アニメ・ドラマ・映画の視聴リスト用の新しい Bot（名前は ask dr egg bot）にすべて追加して。ドラマと映画に分け、さらにアクション・コメディ・アニメのようなジャンル別に並べて。これを今後5日間、1日1回やって。各作品に IMDb のリンクをつけて。

X投稿（@mattyp matt palmer さん、10/20 23:23 JST）

mattyp さんの紹介動画のサムネイル。Grok Bot What's new Oct 18, 2026、3x faster、Computer tasks now finish 3x sooner on average と表示
Grok Bot の新機能紹介（約4分半）。新しいチャットカード、速度、下書きの編集、メールの別名、X の DM、@bot のタグ付け、コネクタ、音声通話、通知、招待と Android アシスタント、アクセスリスト・未読・ルーチン・サインイン、の順に紹介しています。

コメント

SpaceXAI の poteto さんはこの geoff さんの投稿を引用して「Grok @bot のいちばんクールな機能の1つは X でタグ付けできること」と書いています。geoff さんの頼み方は、取り込む元（スレッドの返信）、置き場所（新しい Bot）、整理の仕方、頻度と期限（1日1回・5日間）、添える情報（IMDb リンク）が1文に入っていて、ルーチンの指示としてそのまま通じる形です。動画は 10/18 時点の改善のまとめで、内容は 10/17 号で紹介した改善スレッドとほぼ重なります。

考察

ここからは意見です。「期限つきで毎日やって」と最初から頼むのは、終わらないルーチンを残さない意味でよい習慣です。セミナーや X の募集投稿に集まった返信を、期間限定で毎日まとめさせる使い方は、事務所の情報収集でもすぐ真似できます。

@GeoffreyHuntley／@poteto／@mattyp

実践事例

スタックチャンに Grok Bot を入れて AI 秘書に。朝7:30に予定・メール・天気を読み上げ、Chatwork の下書きは送信前に確認ja実践

X投稿（@minervacosmetic テラさん、10/20 23:05 JST）

GitHub の README（stackchan-sutachan）から

市販のスタックチャン（M5Stack CoreS3 の小型ロボット）と、オープンソースの Groki Bot（JosssphZhou/groki-bot）に、小さなパッチと設定を足したものです。ウェイクワード「すたちゃん」で起動し、毎朝7:30に声をかけて「うん」と答えると今日の予定・大事なメール・天気を読み上げます。店の売上確認はエージェント経由で、Chatwork のスタッフ宛て下書きは「送信前に必ず確認」と書かれています。朝の声かけは Mac 側の cron で動かしています。Groki Bot は第三者のプロジェクトで、公式製品ではありません。

関連（同じ日の日本語圏）

@2024Ren さんは、Grok Bot に artifact（会話の横で動く小さな画面）のような機能がないので、Bot 自身に作らせたと投稿しています（作製3分）。Bot のコンピューターに表示させた画面を、Tailscale（自分の機器同士をつなぐ VPN サービス）経由で隣のブラウザから見る方法です。

考察

ここからは意見です。美容業界の経営者が、画面を見ずに声で朝の確認を済ませる形は、店舗や現場の多い顧問先に響きやすいと思います。ただ、自作のパッチや第三者のゲートウェイを通すので、メールや売上の情報がどこを通るかは導入前に確かめる必要があります。まずは公式のアクションボタン音声会話（10/20 号）で同じ朝の確認を試し、物理ロボットは「楽しさ」を足したい人向けの次の段階と考えるのが無難です。

@minervacosmetic／stackchan-sutachan（GitHub）／@2024Ren

相方の予定を毎朝9時に要約してもらう。Bot に名前をつけて1件1役ja実践

X投稿（@MASATOMAN_ZAKI マサトマンさん、10/20 23:40 JST）

投稿画像。takeuchiスケジュールという名前の Bot が、平日の朝9時ごろ（日本時間、前後15分）に竹内さんのその日の予定を知らせるルーチンを作成した画面

コメント

画像では、Bot の名前を「takeuchiスケジュール」に変え、「平日の朝9時ごろ（日本時間、前後15分）」に相方のその日の予定を知らせるルーチンを作っています。「毎朝」と頼んでも、Bot 側は平日に絞って設定しているのが読み取れます。同じ日には、資格試験の問題を作らせ、間違えた問題を記録して対策資料にし、正解すると具体的にほめてもらう、という学習用の使い方（@Tech_Pochi さん）も出ていました。

考察

ここからは意見です。共有カレンダーを毎朝人が見に行く仕事は、小さな会社ほど誰かの「ついで」になっています。Bot を1件1役で作り、名前で役割がわかるようにしておくと、あとで止めたり直したりするときも迷いません。週末も必要なら「土日も」と明示して頼むのがよさそうです。

@MASATOMAN_ZAKI／@Tech_Pochi

公式ブログ：問い合わせの急増で障害を検知する Bot と、障害後の204件を約10分で片づける Boten実践

x.ai/news（Chris Bowie さん・Isaac Hopkinson さん、10/20 付）「Using Grok Bot to detect and respond to incidents」

During one incident on September 18, our Bot, IncidentSweep, cleared 204 tickets in about 10 minutes with a support engineer reviewing and approving the batch.
9月18日のある障害では、IncidentSweep という Bot が、サポート担当者が一括分を確認・承認したうえで、204件のチケットを約10分で片づけました。以前なら何時間もかけて1件ずつ返信するか、誰に届くかをあまり制御できない一括マクロを使うしかありませんでした。

コメント

記事によると、IncidentWatch は5分ごとに直近15分のチケットを見て、同じ問題の急増を探します。既知の障害に当てはまらなければ、当番の担当者に「推定される問題・件数・例」を知らせ、判断は人がします。障害が確定すると、顧客対応用の Support Bot が保留していたチケットに返信します。障害後の IncidentSweep は、担当者が「対象・除外・送る文面」を指定し、Bot が1件ずつ確かめて自信のないものは外し、送る前に対象一覧と文面を見せて承認を待ちます。承認後に対象を増やすことはせず、少しずつ送って記録し、失敗したら止めて報告します。記事の結びは「Give Bots jobs, not tasks（Bot には作業ではなく仕事を任せる）」です。

考察

ここからは意見です。「見つけるのは Bot、障害かどうか決めるのは人」「一括送信は承認後に範囲を広げない」という線の引き方は、中小企業のクレーム対応やお詫びメールの一斉送信にもそのまま使えます。顧問先には、件数より先に「承認画面で何を見せるか」（対象一覧・除外理由・最終文面）を決めるよう勧めたいと思います。

公式ブログ：Using Grok Bot to detect and respond to incidents

ホスティング会社のライブチャットに Bot が自分で問い合わせて解決。changelog の更新を見張る Bot もen実践

X投稿（@DJQuad さん、10/20 08:59 JST）

今日、ホスティング会社が私の Grok Bot の自動ルーチンをブロックしてしまう問題がありました。すると Grok Bot が私のアカウントにログインし、向こうのライブサポートとチャットを始め、10分ほどやり取りして解決しました。

X投稿（@jessenowlin Jesse Nowlin さん、10/20 10:17 JST）

大型アップデートです。こんなに詳しい changelog を出してくれた @bot チームに感謝します。changelog が更新されるたびに全文を知らせてくれる私の Bot はこちらです。ほかの changelog も見張るよう、自分で設定を変えられます。

コメント

DJQuad さんの投稿には、Bot がどのログイン情報を使ったか、チャットの中身を本人が事前に確認したかは書かれていません。jessenowlin さんは Bot をテンプレートとして共有していて、リンク先は x.ai/bot のテンプレートページです（中身は今回確認していません）。

考察

ここからは意見です。サポート窓口とのやり取りまで任せられるのは便利ですが、相手から見れば本人名義の発言です。顧問先に勧めるなら「問い合わせ文は Bot が下書き、送るのは本人」から始め、任せるのは定型の確認だけにするのが安全だと思います。changelog を見張る Bot は、このダイジェストの一次確認と同じ発想で、使っている SaaS が多い会社ほど効果があります。

@DJQuad／@jessenowlin

収集: 2026-10-21 約05:03–05:20 JST。対象は10/20朝〜10/21朝。英語ソースは翻訳つき。x.ai/changelog/bot は 0.71.2（10/14 付）を掲載、x.ai/news の最新は 10/20（incident-sweep）。status.cursor.com は All Systems Operational。フォーラムの職員投稿は forum.cursor.com で原文を確認しました。画像 x01–x02 は投稿添付メディアを取得したものです。見送り: iPhone アクションボタン関連の再掲・ニュース転載（10/20 号で紹介済み）、Bot アイコンを作らせた投稿（具体的な業務利用なし）、Grok Bot と Claude Code の連携をまとめた紹介投稿（10/20 号の内容と重複）。未回答のまま: フォーラムの「Bot が1体ずつ消える」報告（10/21 04:39 JST、職員回答なし）。Gaps: leerob さんの Stanford 授業の一次資料、Bot メール受信遅延の解消時刻、シェル出力の秘密マスクに対する職員回答、jessenowlin さんのテンプレート中身、mattyp さん動画の内容確認（タイトル一覧のみ）。