Grok活用事例ダイジェスト

2026-09-20・仕様2 / 新機能2 / 実践2　※英語は日本語訳つき。日曜号は公式ニュース新着が薄く、未カバーのGrok Bot docs（共有コンピュータ／協働）とSupport公式ガイド、日本語のFactory・Memory設計記事を中心に拾っています。

仕様解説

docs.x.ai — Use the computer and apps（共有コンピュータ／takeover／Recover）en仕様

引用

Every Bot on your account uses the same computer: Browser cookies and signed-in sessions are shared. Files are visible to every Bot. Command-line credentials are shared. One Bot can continue from work another Bot saved. The computer is assigned to your user account, not an individual Bot. Do not place a credential or file on it if another Bot on your account should not be able to use it. Each Bot gets its own screen on the shared computer. Several Bots can therefore use browser and desktop tools in parallel, although one Bot can run only one computer-use task on its screen at a time. The screens are separate work surfaces, not separate security boundaries. … Open the computer, take control, complete only the blocked step, and tell the Bot to continue. Avoid pasting passwords or one-time codes into chat. … Update installs the latest software on the computer and keeps your files in place. Reset rebuilds the computer from your last saved snapshot; very recent changes may be lost.

日本語訳

アカウント上の全Botは同じコンピュータを使います。ブラウザのCookieとログインセッション、ファイル、CLIの資格情報は共有され、別Botが残した作業を続けられます。コンピュータはBot単位ではなく利用者アカウントに割り当てられます。別Botに使わせたくない資格情報やファイルは置かないでください。各Botは共有コンピュータ上で自分の画面を持ち、並行してブラウザ等を使えますが、1Botが同時に動かせるcomputer-useは画面ごとに1つです。画面は作業面の分離であり、セキュリティ境界ではありません。パスワード・パスキー・2FA・CAPTCHA・支払いなどは利用者がコンピュータを引き継いでその段だけ完了し、チャットへパスワードやOTPを貼らないでください。Updateはソフトを更新してファイルを残し、Resetは直近スナップショットから再構築するためごく新しい変更は失われ得ます。

昨日号の private-networks（外側の到達）やQiitaの観測経路に続く、「内側の共有モデル」の公式契約です。複数Botを並べても資格情報はアカウント共有である点と、画面の分離をセキュリティ境界と誤解しない点が要点です。Recoverはエラー状態からのみ、Resetは最終手段、という順序も明記されています。

考察

伴走では「役割Botを増やす前に、共有箱に何を置いてよいか」を先に決める説明が効きます。顧客向けの本番キーや個人の2FAはtakeoverに寄せ、読み取り専用の下書きBotと送信可能なBotを同じ箱で混ぜる場合は、チャットへの秘密貼り付け禁止をSkillに書いておくと事故が減ります。確信度: 公式docsどおり（運用ルールは事務所側の設計）。

Use the computer and apps

docs.x.ai — Message and collaborate（グループ／handoff／スレッド）en仕様

引用

Use a group when several Bots need one shared outcome and visible handoffs. … select two to six Bots. … Write normally to let the participating Bots decide who should respond. Type @ and select a Bot when one teammate owns the request. … Use @everyone sparingly for a group-wide update. Bots can post into the group and pass work among themselves. … Bot-to-group handoff messages are currently text-only, so a Bot should send an image directly to another Bot when that teammate must inspect it. A Bot can send an asynchronous message to another Bot. The receiving Bot wakes, handles the request, and can reply later. … Ask for a single owner at each stage. Too many parallel handoffs can create duplicate work and noisy updates. … Use reactions for lightweight acknowledgement. Use a written reply when the Bot needs a changed instruction; a reaction alone should not carry a safety-critical decision.

日本語訳

複数Botが一つの成果と見える引き継ぎを共有するときはグループを使います。2〜6体を選びます。通常の書き込みでは参加Botが応答者を決め、@で担当を固定し、@everyoneはグループ全体への更新に限定します。Bot同士はグループへ投稿して仕事を渡せます。現状、Botからグループへの引き継ぎはテキストのみなので、画像が必要な相手には直接送る必要があります。非同期のBot間メッセージで受け手が起きて処理し、後から返信できます。各段階で単一の所有者を求め、並列handoffの過多は重複とノイズを増やします。リアクションは軽い確認向けで、安全に関わる指示変更は文章の返信で行います。

9/18号のSkills／Approvalsのあとに読むと、「誰が次の一手を持つか」をUI契約として固定するページです。後述のSoftware Factory実践で出てくる役割分離・引き継ぎと対になります。画像の受け渡し制約は、レビューBotにスクショを渡す設計で落とし穴になります。

考察

宮崎の少人数伴走でも、調査Botと下書きBotをグループに入れ、@Reviewerだけに承認前チェックを渡す型は説明しやすいです。送信・公開は人が書く返信で止める、という線引きは公式の「リアクションだけでは安全決定にしない」と一致します。確信度: 公式docs。

Message and collaborate

新規機能解説

x.ai/bot/guides — Grok Bot for Support（5職＋Routine化）en新機能

引用

How we use Grok Bot to work a support queue: connectors, five jobs, and routines that keep going after you close the laptop. … Numbers and details are illustrative. … 1) Release tracking and feedback monitoring … 2) Bug reproduction … record a video of the bad state and write up reproduction steps. … 3) Churn analysis … cluster the root reasons … 4) Refunds … grant or deny each one with your approval … 5) Custom reporting … The biggest unlock has been the ability to take a workflow you created with Grok Bot and easily turn it into a Routine (aka Automation) that repeats every day or hour. Then you can review the results on your own schedule, from the Grok Bot Mobile App.

日本語訳

サポートキューをGrok Botで回す方法として、コネクタ・5つの仕事・ノートPCを閉じたあとも続くRoutineを紹介しています。数値や詳細は例示です。(1)リリース追跡と初期フィードバック監視、(2)不具合再現（悪い状態の動画と再現手順）、(3)解約予兆のクラスタ分析、(4)返金ポリシー照合（承認付きで許可／拒否）、(5)役割別のカスタム報告。最大の解放は、うまくいった流れを日次・時間次のRoutineに変え、結果をモバイルで後から確認できる点だと述べています。

日付は2026-09-09、著者はDavid Gan氏の公式ガイドです。Galaxyの職種別セッション（Support枠はDay2）のあとに残る「自社での回し方」プレイブックとして、本号で初掲載します。チケット数や削減額は illustrative と明記されているため、効果数値としては扱いません。

考察

中小の問い合わせ窓口では、(2)再現と(4)返金を「下書きまで自動・送信は承認」に切るのが現実的です。解約分析は個人情報の取り扱いと閲覧権限を先に決めてから試す必要があります。確信度: 公式ガイド（数値は例示）。

Grok Bot for Support

oflight — Bot Marketplaceの作り方と公開手順（秘密は手動削除）ja新機能

引用

2026年9月9日時点で、公式サイトには69 Bots・43 creators・9カテゴリが掲載されている。… テンプレートとして渡るのはプロフィール・説明・スキル・ルーティン・アイデンティティであり、会話履歴や学習済みのメモリは引き継がれない。… 公開前にはAPIキー・内部URL・顧客データなどを手動で削除する必要がある。これらは自動では除去されない、と公式Docsは明記している。… 「One job（1つの仕事）」を1文で定義し、「Anti-jobs（やらないこと）」を明記して役割の暴走を防ぐ。… 送信・支払い・署名は「明示的なGo」なしに絶対に行わない、というガードレールを冒頭に置く。

株式会社オブライトの2026-09-09コラムです。作成→Skill／Routine→Share as template→秘密削除→公開→Importで独立コピー、という流れを公式Docsと突合しています。Haggle本体やMarketplace存在自体は過去号・他記事でも触れていますが、「何が引き継がれ／引き継がれないか」「秘密の自動除去は無い」を一枚にまとめた公開契約として本号で扱います。Marketplaceへの自動掲載か審査かは、著者も公式未明記として留保しています。

考察

伴走先がテンプレを社内共有するときは、公開前チェックリスト（キー・内部URL・顧客名）をSkill化すると安全です。Import側はメモリが来ない前提で、初回セットアップ質問（FIRST RUN）を自分の環境向けに書き直すのが実務的です。確信度: 二次整理＋公式Docs照合（掲載プロセスの詳細は未確定）。

oflight記事／ Bot Marketplace

実践事例

Zenn — 一つのbug対応を伸ばしたら、Software Factoryになったja実践

引用

最初の目的は、日々のbug対応でもう少し長い範囲をAgentへ任せることだった。Software Factoryや仮想の開発組織は、後からついてきた。… Agentの稼働時間に合わせて、人間の注意力まで増やせる前提で設計していた。その前提が失敗だった。… Agentは24時間動ける。しかしHuman Attentionは、24時間利用できる資源ではない。… すべてのAgentの出力を人間が確認する構造から、自動検証で解決できなかったものだけを人間へ上げる構造へ移す必要がある。… Human-on-the-Loopは、まだ設計仮説の段階にある。… ちょうどそのタイミングで Cursor Projectsが発表された。… 今の比較は非対称である。

2026-09-12公開です。Grok BotをBug Investigatorに置き、調査→実装→独立レビュー→QAと工程を伸ばす約3日の記録です。昨日のfastdoctor（Slackイベント駆動）とは別著者で、ボトルネックがVerification Throughputと人間の注意力へ移る過程が具体的です。Cursor Projectsとの比較は「未試用」と明記し、事実と仮説を分けています。

考察

伴走では「Botを増やしたあとに、人間がqueueになっていないか」を週次で見る指標になります。E2Eや静的解析など既存のSE基盤が、Agent時代でもVerification Gapの切り分けに効く、という整理は中小の説明にも使いやすいです。確信度: 一次体験（約3日）＋設計仮説。

Zenn記事

Zenn — Grok BuildのMemoryから考える、AI Agentの記憶の失効設計ja実践

引用

これはGrok BuildのMemoryで紹介された例だ。便利なのは確かだ。ただし、この時点でメモは単なる記録ではなくなる。次のコマンドを選ぶ権限を持ち始めるからだ。… Agentの記憶は「事実の保管庫」というより、過去にうまくいった判断を再利用するキャッシュに近い。キャッシュなら、保存方法だけでなく無効化条件が要る。… 優先順位は「新しい情報と衝突したとき」の規則であり、情報そのものがまだ有効かは判定しない。必要なのは、priorityだけではなくvalidityだ。… sourceとrecheck_if… 記憶の信頼度より、間違えたときの副作用で確認方法を変える。

2026-09-17公開です。9/18号で扱った「Memory in Grok Build」公式発表の運用設計側で、公式機能の再掲ではありません。just test例を起点に、workspace／global、現在指示の優先、／dream圧縮時に残したい履歴、／memoryの可視性を整理しています。著者は実機の誤記憶率は評価していないと明記しています。

考察

事務所のBot memoryでも、「コマンド選択につながるnote」だけに出典と再確認条件を足す、という最小契約はすぐ試せます。文体の好みと本番変更の根拠を同じ強さで自動適用しない、という線引きはApprovals設計とも相性が良いです。確信度: 公開仕様からの設計論（精度検証は未実施）。

Zenn記事／ Memory in Grok Build（参考・9/18号で本体掲載）

収集: 2026-09-20 JST。英語ソースは翻訳付き。公式ニュースは9/18のTranscribe 2.0以降に新着がなく、日曜はdocs／公式ガイド／日本語実践で構成しています。X（@bot等）はjinaのAbuseAlleviationにより本収集時点で匿名取得不可のため、スクショ・embedは無し。事実と意見を分け、確信度を各カードに記載しています。