Grok活用事例ダイジェスト

2026-09-21・仕様2 / 新機能2 / 実践2　※英語は日本語訳つき。公式ニュースは9/18以降新着がなく、未カバーの設定・チーム管理docsと公式ガイド（101／Engineering）、日本語のOps失敗・並列E2E実践を中心に拾っています。

仕様解説

docs.x.ai — Settings and notifications（Auto-review／Local Computer／Update≠Reset）en仕様

引用

Two settings in General deserve care. Execution on Local Computer controls whether Bots can run commands on the desktop in front of you; per-command approval is the default, and the setting applies to that desktop alone. Auto Review rules shape which actions stop for your approval. When your admin enforces Auto Review for the team, the same table also shows locked team rules with Required by your admin. You can't edit or delete this rule. You can add your own rules on top, but they only make behavior stricter; Ask first wins when rules conflict. … Turn on Route egress through this desktop to send your Grok Bot computer's web traffic through the current desktop. … Grok Bot Updates shows the installed version. … Under Grok Bot's Computer, Update installs the latest software on the cloud computer and keeps your files in place. Reset wipes the computer and rebuilds it from your last saved snapshot. … Turn on Notifications in a Bot's settings to receive an operating-system or mobile notification when that Bot finishes or needs input.

日本語訳

Generalの2項目には注意が必要です。Execution on Local Computerは目の前のデスクトップでBotがコマンドを実行できるかを決め、既定はコマンドごとの承認で、そのデスクトップだけに効きます。Auto Reviewルールは承認で止める行動を形作ります。管理者がチームでEnforceすると、同じ表に編集不可の必須ルールが表示されます。個人ルールは上乗せでき、厳格化のみです。衝突時はAsk firstが勝ちます。Route egress through this desktopをオンにすると、BotコンピュータのWeb通信が当該デスクトップ経由になります。Grok Bot Updatesはアプリ版です。ComputerのUpdateはクラウド側ソフトを更新してファイルを残し、Resetは直近スナップショットから再構築します。Bot設定のNotificationsをオンにすると、完了や入力待ちでOS／モバイル通知を受け取れます。

昨日号の共有コンピュータ契約に続く、「個人が触る制御面」の公式ページです。アプリ更新とComputer更新の分離、チーム必須ルールの上に個人は厳格化のみ、通知はフォーカス中は抑止されサイドバー／バッジは残る、といった運用上の細部がまとまっています。9/18のApprovals本体とは視点が異なり、設定UI側の契約として本号で初掲載します。

考察

伴走では「Local ComputerはNever寄りで始め、必要な端末だけAsk」「Resetは最終手段で、先にUpdate／Recover」をチェックリスト化すると説明しやすいです。モバイル通知はBot単位なので、Routineが多いBotだけオンにする、という切り方もできます。確信度: 公式docs。

Settings and notifications

docs.x.ai — Teams and enterprises（Firecracker隔離／Enterprise管理）en仕様

引用

The security model rests on four principles: Per-user isolation. Each user's work runs in a dedicated Firecracker microVM … No access by default. … Human approval gates. … Administrative control. … Within one user, the boundary is different: all of that user's Bots share one computer, and Bots isolate personalities and workspaces, not compute. Treat a login or file on the computer as available to every Bot that user runs … When a workload needs its own computer and credential set, give it its own Cursor user. … Enforce Auto-review … Available on the Enterprise plan. … Action Recording records Bot actions: connector (MCP) tool calls, shell commands, browser navigations, and computer use sessions. Events are sanitized … browser navigations keep each page as scheme://host/path with the title but strip query strings and credentials … For security-sensitive deployments: Configure Network Controls … Turn on Enforce Auto-review … Set Execution on Local Computer to Never allow unless Bots need to act on member machines … Keep public template sharing off unless members should publish Bot templates outside the team.

日本語訳

セキュリティモデルは4原則です。(1)利用者単位の隔離（専用Firecracker microVM）、(2)既定でアクセスなし、(3)人の承認ゲート、(4)管理制御。同一利用者の内側では境界が異なり、全Botが1台のコンピュータを共有し、人格と作業空間は分かれても計算資源は分かれません。ログインやファイルは全Botが使える前提で扱い、別の資格情報セットが必要なら別のCursorユーザーを用意します。Enforce Auto-reviewやAction RecordingなどはEnterprise向けです。Action RecordingはMCP・シェル・ナビ・computer-useを記録し、秘匿は除去され、ブラウザはクエリと資格情報を落としたpathとタイトルが残ります。セキュア展開の推奨としてNetwork Controls、Enforce Auto-review、Local ComputerをNever寄り、公開テンプレ共有オフなどが挙げられています。

組織導入向けの公式ページです。昨日の「画面はセキュリティ境界ではない」を組織単位で言い直すと、「利用者同士はVMで隔離、利用者内のBot同士は隔離されない」になります。Teamsでは既定オンでオフスイッチがなく、Enterpriseだけ組織ワイドの有効化やNetwork／録音などが出る、という差も重要です。Approvalsの操作モデルは9/18号済みのため、本号は管理アーキテクチャに絞っています。

考察

宮崎の中小伴走では、まず「別会社・別部門の資格情報を同じCursorユーザーに載せない」説明が先です。監査が要る先にはEnterpriseのAction Recording＋OpenTelemetry Exportの有無を確認し、数値効果の約束より隔離境界の図を渡す方が安全です。確信度: 公式docs（プラン差分はダッシュボード実機で再確認推奨）。

Grok Bot for teams and enterprises

新規機能解説

x.ai/bot/guides — Grok Bot 101（outer loop／Arnold／共有コンピュータ）en新機能

引用

Grok Bot is an agent with a computer. … Behind the scenes, settings are three fields: Name … Title … Description … Be as specific as you can. … If you log into Amazon on a computer the agent can use, it can technically buy whatever it wants … Bots are kept in check by permissions, a reviewer, and allow/block lists. … One more thing: if you log into a site with one bot, every other bot can reach that site too. … My outer loop agent gathers context from Slack, Notion, GitHub, and docs, then hands a clean prompt to a Cursor cloud agent for the inner loop that actually builds software. … An important distinction: Grok Bot is not writing the code. It is creating the same prompts I would, then sending them to a specialized coding harness that lives inside Cursor. … I moved [a strength training app] into chat. Arnold is my strength and hypertrophy programming coach. … If you can decompose an app into inputs, logic, and a datastore, you can probably turn it into a bot.

日本語訳

Grok Botはコンピュータを持つエージェントです。設定の核はName／Title／Descriptionの3欄で、できるだけ具体的に書きます。エージェントが使えるコンピュータでAmazonにログインすれば、技術的には何でも買えてしまうため、権限・レビューア・許可／拒否リストで抑えます。1体でログインしたサイトは他のBotからも届きます。outer loopエージェントがSlack・Notion・GitHub・docsから文脈を集め、きれいなプロンプトをCursorクラウド（inner loop）へ渡して実装させます。重要な区別として、Grok Bot自身がコードを書くのではなく、自分が書くのと同じプロンプトを専用のコーディング基盤へ送っています。筋トレアプリをチャットのArnoldに移した例では、入力・ロジック・データストアに分解できればBot化できる、と述べています。

日付は2026-09-11、著者はDevRelのMatt Palmer氏の公式ガイドです。昨日のSupport職種別ガイドとは別軸で、「立て方・チェーン・日常ワーク」の入門に相当します。共有コンピュータ警告はdocsと一致し、outer／innerの役割分離は後述のEngineering実践・Zenn E2Eと対になります。

考察

伴走の最初の15分は、Descriptionに「成果・禁止・承認点」を3行書くだけで十分です。コーディング案件では「調査と発注はBot、実装はCloud Agent」と役割を分け、汚い文脈を実装側に持ち込まない、という言い方が伝わりやすいです。確信度: 公式ガイド（個人ワークフロー例）。

Grok Bot 101

x.ai/bot/guides — Grok Bot for Engineering（5工程师＋Jenny／証跡ループ）en新機能

引用

I have five engineer bots … Baltata … Shaoruru … Hogan … Craig … Quill … Every bot can create Cursor cloud agents, read transcripts, review proofs attached to PRs, and send follow-ups by queueing a message or interrupting the run. … Every 30 minutes, they review the [Notion] database and check each PR for Bugbot comments … Failing CI … Merge conflicts. … If the review is highly confident and the blast radius is low, the PR is merged automatically. … Before Grok Bot, I could manually manage 15 cloud agents at a time. Now my fleet manages more than 200 simultaneously … That’s all Jenny’s job, my head of operations … Every morning at 5 a.m., Jenny meets 1:1 with every bot … When a bot makes a mistake … I tell it to find Jenny for root-cause analysis and a postmortem. … Every night at 3 a.m., my engineer bots … cleaning up the codebase … Whenever I say a task is P0, they start a temporary routine that checks the transcript every five minutes … Please note that this can burn tokens much faster than you think.

日本語訳

工程师Botを5体（領域別）運用し、いずれもCursorクラウドの起動・トランスクリプト読取・PR証跡レビュー・キュー／割り込みのフォローアップができます。30分ごとに共有NotionのPR板を見て、Bugbot・失敗CI・コンフリクトを確認し、確信度が高く影響が小さければ自動マージします。以前は手で15体までだったクラウド管理が、フリートで同時200超まで伸びた、と述べています。コードを書かないOps役Jennyが朝5時に全Botと1:1し、失敗時はポストモーテムでプレイブックを更新します。夜3時の夜間監査や、P0指定で5分ごとの追い込みルーチンもあります。P0はトークン消費が速いので真の緊急時だけ、と注意があります。

日付は2026-09-10、著者はLingxi Li氏の公式ガイドです。Galaxy週のエンジニアリング文脈のあとに残る「社内での回し方」プレイブックで、本号初掲載です。2000+ PRsや200 agentsなどの数字はSpaceXAI社内の事例であり、中小の再現目標にはしません。フィードバックループ（スクショ検証・割り込み）とOps Bot（Jenny）の設計が中核です。

考察

伴走では「5体＋自動マージ」をそのまま真似せず、Conductor1＋実装Cloud＋検証Bot1から始め、Notion板はステータス3列だけ、自動マージはオフ、が現実的です。P0ルーチンは従量コストの説明材料にもなります。確信度: 公式ガイド（スケール数値は社内事例）。

Grok Bot for Engineering

実践事例

Zenn — Grok Botで暗号取引チームを組んだが失敗した（Ops振り返り）ja実践

引用

本稿は投資助言ではありません。… 結果ははっきりしている。約定ゼロ、実現損益 ¥0… 約2週間でチームは解散した。… 発注は preview_order → ユーザー確認必須（ブラインド自動発注なし）。… 安全な待機ルールは正しく働き、正しく働きすぎて KPI 期限に間に合うエントリー機会を自分で消した。… KPI と待機を両立させるなら、KPI の定義を変える: 例）実現PnLだけでなく「preview 回数」… プロセスKPIを並置する。… 制約の積集合を先にシミュレーションする。… 取引外の継続成果: 週次の Gmail → Drive サブスクリプション経費トラッカーは、取引チーム解散後も稼働を継続している。

2026-09-18公開です。投資の勝敗ではなく、役割分担・bitbank MCP・preview→confirm・ルール積集合と期限付きKPIの矛盾を記録したOps失敗談です。成功事例が続きがちななかで、終了条件を先に書き、口座破壊に至らない失敗の形を残している点が実務的です。本ダイジェストは投資助言ではなく、エージェント運用の学びとして扱います。

考察

伴走では「安全装置が強すぎて学習ループが回らない」パターンの説明に使えます。送信・発注・公開は承認必須のまま、プロセスKPI（preview回数・誤操作ゼロ日数）を並置し、本体が死んでも周辺Routineが残る設計は、補助金申請や定期レポにも転用できます。確信度: 約2週間の一次Ops記録（相場再現は非推奨）。

Zenn記事

Zenn — Cursorで直してGrok Botで洗う。並列E2Eで常時3案件ja実践

引用

実装（Cursorクラウド）と検証（Grok Bot側の専門Bot）を分ける。検証は画面スクショだけでは足りない。実際のブラウザに加え、Chromeの Console と Network を必須にして、空表示とAPI失敗・未実行を切り分ける。FAILのときは想像で直させず、証拠付きで同じクラウドに戻す。だいたい 3案件並列を、受入条件の型で常時回す。… 判定不能は PASS にしません。「空＝成功」にしないのが、ループを腐らせないコツです。… パスワード・トークン・パスキー秘密をチャットに貼る… スクショだけで PASS にする（Console / Network を見ない）— やらないことリスト。

2026-09-06公開です。日付は少し遡りますが過去号未掲載で、上記Engineering公式ガイドの「縮小版」実録として対になります。Conductor統括＋E2E専門Bot、受入条件の型、スマホ2アプリでの承認、という運用が具体的です。体感の数字（常時3案件など）は厳密計測ではないと著者自身が書いています。

考察

中小の改修案件では、まず1案件で「対象URL／直ったはず／PASS条件／証拠（スクショ＋Console＋Network）」の型だけ決めるのが最短です。パスキー待ちがボトルネックになる点は、人間の承認枠をカレンダーに先に取る運用とセットで説明すると現実的です。確信度: 運用体感の一次記録。

Zenn記事

収集: 2026-09-21 JST。英語ソースは翻訳付き。公式ニュースは9/18のTranscribe 2.0以降に新着がなく、月曜は未カバーdocs（設定／チーム管理）と公式ガイド（101／Engineering）、日本語のOps失敗・並列E2Eで構成しています。X（@bot等）はjinaのAbuseAlleviationおよびfxtwitter timeline欠落により本収集時点で新規取得不可のため、スクショ・embedは無し。事実と意見を分け、確信度を各カードに記載しています。