← 一覧に戻る
Grok活用事例ダイジェスト
2026-09-25・仕様2 / 新機能2 / 実践2 ※英語は日本語訳つき。本日は未カバーのApprovals/Files仕様、昨日DeferredのDesigningガイド、未紹介のGTMガイド、ofoxのResponses暗号化reasoning、日本語のアイドリ比較を組み合わせています。公式ニュースの9/23以降新着はありません。Xスクショは取得不可です。
仕様解説
docs.x.ai — Approvals, security, and privacy（境界・承認・共有PC）en仕様
引用
Tell the Bot which actions it can take and where it must stop: … Prefer explicit boundaries for: Sending messages … Publishing … Purchases … Deleting or overwriting … Changing permissions … Production changes … Accepting legal terms. An approval controls the proposed action. It does not reverse work already completed. … Ask first rules always stop matching actions … If both kinds of rule match, Ask first wins. … For passwords, passkeys, two-factor codes, CAPTCHAs, and payment confirmations, the Bot should hand you control of the computer. … Do not send a password or one-time code in ordinary chat. … The default is Ask every time. Use Never allow unless a Bot has a specific reason to work on your local files. … Do not use separate Bots as a security boundary. … Deleting a Bot does not remove shared-computer files or browser sessions.
日本語訳
Botに「何をしてよく、どこで止めるか」を明示します。送信・公開・購入・削除／上書き・権限変更・本番変更・法的同意は境界の候補です。承認は提案された操作だけを対象にし、すでに終わった作業は取り消しません。Ask firstルールは常に止め、Always AllowとぶつかったときはAsk firstが勝ちます。パスワード・Passkey・2FA・CAPTCHA・決済確認はAgent Computerを開いて人が操作し、普通のチャットにワンタイムコードを書かないでください。ローカル実行の既定は毎回確認で、特別な理由がなければNever allowを推奨します。Botを分けてもセキュリティ境界にはなりません。Bot削除では共有コンピュータ上のファイルやブラウザセッションは消えません。
コメント
考察
伴走ではDescriptionに恒久の承認境界を書き、送信系はAsk first、ローカルはNever allowから始めるチェックリスト1枚にすると説明が安定します。確信度: 公式docs。
Approvals, security, and privacy
docs.x.ai — Files and results（添付・レビュー可能な成果物）en仕様
引用
The desktop composer accepts up to six attachments at a time. Documents, images, and audio can be up to 25 MB each; videos can be up to 200 MB. … Tell the Bot what each attachment is and how it should use it. … For consequential work, ask the Bot to separate: 1. Facts found in source systems 2. Assumptions or inferences 3. Actions already completed 4. Actions waiting for approval 5. Unresolved questions. … A strong result should be independently reviewable. … Direct source links … Screenshots … Timestamps and time zones … Input and output file names … A concise action log … An explicit list of anything the Bot could not verify. … Bots can read files other Bots save in /workspace. … the conversation should still contain the final result or a clear link to it.
日本語訳
デスクトップの添付は一度に最大6件。文書・画像・音声は各25MB、動画は最大200MBです。添付ごとに「何の資料で、どう使うか」を書いて渡します。重要な仕事では、(1)ソースで確認した事実 (2)仮定・推論 (3)すでに完了した操作 (4)承認待ち (5)未解決、を分けて返させます。強い成果物は第三者が検証でき、ソースリンク・スクショ・タイムゾーン付き時刻・入出力ファイル名・短い行動ログ・検証できなかった一覧が揃います。他Botが/workspaceに置いたファイルは共有で読めますが、会話側にも最終成果か明確なリンクを残します。
コメント
考察
初回タスクは「下書き＋根拠リンク、送信なし」に限定し、スクショだけに頼らないようソースURLを必須にするとレビューが早くなります。確信度: 公式docs。
Files and results
新規機能解説
x.ai/bot/guides — Designing Grok Bot with Grok Bot（Figma Bro / Motion God）en新機能
引用
I've been using Grok Bot to design Grok Bot. … Figma Bro handles repetitive production work in Figma. Motion God helps me prototype as I describe how interactions should feel. Experiments is where I send ideas that I want to make tangible before I know exactly what they should become. Devbot answers engineering questions … I don't need to decide that an idea is sensible, feasible, or destined for the roadmap before making it real enough to judge. … I wanted it working with the same asset that already lived and moved in the product. So I had Motion God build a playground on localhost around the actual animation spec file. … Through the Figma MCP, it can inspect the actual file and use exact x and y positions, width, height, spacing, typography, fills, strokes, and component structure. … Grok Bot doesn't replace that judgment. It gives me more opportunities to use it.
日本語訳
Grok Bot自身のデザインにGrok Botを使っている、と述べています。席はFigma Bro（量産）、Motion God（インタラクション感の試作）、Experiments（まだ形が決まらないアイデアの具体化）、Devbot（実装の問い）。ロードマップに載せる前に判断できる粒度まで作ってよい、というExperimentsの立ち位置です。Motion Godにはスクショ近似ではなく本番のアニメーション仕様ファイルでlocalhost playgroundを組ませ、Figma BroはMCP経由で座標・余白・タイポ・コンポーネント構造を正確に使います。判断を置き換えるのではなく、判断の回数を増やす、が結論です。
コメント
考察
中小のデザイン伴走ではExperiments＋1つの制作席から始め、ブランドガイドラインとマスターコンポーネントを先に渡す縮小版が現実的です。確信度: 公式ガイド（著者の社内実践）。
Designing with Grok Bot
x.ai/bot/guides — Grok Bot for GTM（CoS・週次rundown・Slidesライブ）en新機能
引用
My Chief of Staff owns meeting prep, inbox and post-call drafts, orchestrates the rest of the team. … Prospecting bot … I like to run this overnight … Customer expert … One agent per strategic account … Weekly media rundown … Keep a state file of everything already covered … If nothing new, send a single line saying so. … My favorite skill is to auto-update slides while I'm on a customer call, based on the Granola transcript. Stop the Granola recording 5 or 10 minutes before the call ends and run it live … Onboard Grok Bot like a new teammate. … Feed it your writing. … I create skills (ie: I have an anti-slop skill) … Ask your Chief of Staff to take a look at all your bots/tasks and if there's anything you can further automate.
日本語訳
Chief of Staffが会議準備・受信箱・通話後下書きと他席の司令を持ちます。Prospectingは夜間に走らせ、Customer expertは戦略アカウントごとにSlack・通話・週次メディアrundownを担当します。rundownは既出をstate fileで除外し、新規が無ければ一行だけ返す、と指示します。お気に入りは通話中にGranola書き起こしからSlidesをライブ更新することで、終了5〜10分前に録音を止めて走らせます。新人同僚のようにオンボードし、文体を送りメールから学ばせ、anti-slopなどのSkillを育て、CoSに席とタスクの整理を定期で見させる、という運用です。
コメント
考察
中小ではCoS＋顧客1席＋下書き席の3つから始め、外部送信は承認必須、state fileは/workspaceに固定パス、が安全です。確信度: 公式ガイド（数値・ROIは著者ケース）。
Grok Bot for GTM
実践事例
ofox — Grok 4.7 API：Responsesで暗号化reasoningを保持するen実践
引用
Responses returns encrypted reasoning items that should remain intact when you send the conversation history back. … Do not reduce first.output to the visible answer before storing the next-turn history. … Keep the reasoning items unchanged; do not try to decode or rewrite the encrypted field. … The encrypted Responses behavior does not mean you should insert Responses output objects into a Chat Completions messages array. … A higher setting is not a promise of a lower completed-task bill. … These are diagnostic categories, not reproduced error messages. … The examples illustrate request construction; they are not a report of a paid production test or a performance benchmark.
日本語訳
Responsesは暗号化されたreasoning項目を返し、次ターンの履歴にそのまま戻す必要があります。表示用の答えだけに縮めてから履歴へ保存しないでください。暗号化フィールドを復号・書き換えしない、とあります。Responsesの出力オブジェクトをChat Completionsのmessagesに流し込んではいけません。effortを上げても完了タスクの請求が下がる保証にはなりません。障害表は診断カテゴリであり再現ログではありません。本記事の例はリクエスト組み立ての説明で、有料本番試験やベンチの報告ではない、と著者は明記しています。
コメント
考察
移行時はモデル変更とエンドポイント変更を分け、frameworkがoutput全体を保持するか先にログ確認、が失敗切り分けに効きます。確信度: 二次整理（公式準拠・著者実測ではない）。
ofox記事
note — アイドリ：Grok Bot徹底解説と他エージェント比較ja実践
引用
本記事は、xAI（現在はSpaceXAI名義）が2026年8月11日に公開したGrok Botを、公式サイトと公式ドキュメントだけを一次情報として読み解きます。… アカウント上のすべてのBotが同じコンピュータを使い、ブラウザのCookieとサインイン済みセッション、ファイル、コマンドラインの資格情報を共有する。… セキュリティ境界としてBotを分けて使わない…。… 手を動かせる人が少なく、業務システムにきれいなAPIがなく、それでも早く自動化したい組織にとっては、現時点でかなり強い選択肢。逆に、権限分離を厳密に設計したい組織や、データを自社管理したい組織には、共有コンピュータとプライバシーモード非対応の2点が重い制約になります。… 対象プランの記述が公式内で揺れている…。Grok Botの使用量はGrokやCursorのプランとは別枠…。Grok Botはデータ保存を必須とし、Legacy Privacy Modeをサポートしません。… Botを削除すると…ファイルやログインは残ることがある。
コメント
考察
伴走では「共有1台PCを受け入れるか」「Privacy Mode必須か」を最初の分岐にし、開発中心なら既存のClaude Code/Codex継続、業務横断の自動化ならGrok Bot試行、と説明を分岐させると迷いが減ります。確信度: 二次整理（公式準拠・導入判断は著者意見）。
note記事
収集: 2026-09-25 約05:02–05:25 JST。英語ソースは翻訳付き。公式ニュースに9/23以降の新着はなし。仕様は未カバーのApprovalsとFiles。新機能はDeferredのDesigningと未紹介のGTM。実践はofoxのResponses暗号化reasoningとアイドリ比較。X（@bot等）はjinaブロックのためスクショ・embed未取得。OverviewのLinux/Android表記とFAQの差、Identity and access、Troubleshooting、TomoyaのGmail→PR実測は次号候補。数値・ROIは公式発表値または著者ケースとして扱い、一般化していません。事実と意見を分け、確信度を各カードに記載しています。