Grok Botのユースケース56件｜中小企業が任せられる仕事

「Grok Botって、結局うちの会社では何に使えるんだろう」「AIの社員が24時間働くと言われても、任せる仕事が思いつかない」——新しいAIエージェントの話題を追いかけていると、必ずこの壁に当たります。

結論から言うと、Grok Botが得意なのは「APIが用意されていない仕事」です。xAIが公式サイトで公開しているユースケースを全56件数えて分類したところ、営業とマーケティングだけで41%を占め、エンジニアリングは9%しかありませんでした。この偏りには理由があります。

株式会社Fyveは、AIエージェントを無人で動かす仕組みを自社の運用で組み続けてきました。本記事では公式カタログ56件を一次情報として実測し、中小企業やひとり社長が実際に任せられる仕事はどれなのかを整理します。

Grok Botとは何か——ユースケースを見る前に最低限だけ

Grok Botは、xAIが2026年8月11日に発表したAIエージェントです。公式は「AI teammates you can give real work to（本当の仕事を渡せるAIの同僚）」と表現しています。

従来のAIチャットとの決定的な違いは、Bot専用のクラウドPCが1台割り当てられる点です。そのPC上でブラウザを開き、サービスにログインし、人間と同じように画面を操作します。手元のノートPCを閉じても、クラウド側の作業は止まりません。

公式ドキュメントはこう書いています。「Bots can sign in and use apps and websites just like you do on a persistent cloud computer（Botは永続的なクラウドPC上で、あなたと同じようにアプリやサイトにログインして使える）」。

対応プラットフォームは、macOS（Apple Silicon・Intel両対応）、Windows（x64・Arm64）、iPhone（iOS 18以降）です。Linuxデスクトップ・Android・iPadは初期リリース時点では非対応と公式FAQに明記されています。

権限をどこまで渡すか、止まったときにどちらへ倒れるかという設計の話は、別記事で詳しく扱っています。本記事は「何を任せるか」に絞ります。

AI業務効率化Grok Botとは｜常時稼働AIエージェントに渡す権限の決め方

公式カタログ56件を全部数えてみた

xAIは専用のユースケースページを公開しています。ここには「Grok Botに渡せる仕事」がカード形式で並んでいます。

この56件を全件、カテゴリ別に数えました。集計結果が次の表です。

営業・マーケが41%、エンジニアリングは9%しかない

営業とマーケティングを足すと23件、全体の41%です。一方でエンジニアリングは5件、9%にとどまります。

これは意外に思える数字です。というのも、Grok Botのダウンロードリンクも法人問い合わせ窓口も、Cursor（開発者向けのコーディングツール）のドメインを経由しているからです。配布経路は開発ツールなのに、カタログの中身は営業事務とマーケティング業務で埋まっている。

この「ねじれ」は、Grok Botが誰に向けた製品なのかを示しています。コードを書く人ではなく、画面をひたすら操作している人に向けた製品です。

カテゴリ名から見える想定読者

興味深いのは「Life & Leverage（私生活）」というカテゴリが4件あることです。中身は物件探し、旅行の手配、サブスクリプションの棚卸し、個人サイトの構築でした。

仕事のカテゴリに私生活が混ざっているのは、Grok Botが「会社が導入するシステム」ではなく「個人が自分の裁量で使い始める道具」として設計されているからです。ひとり社長や小規模事業者にとっては、この設計思想は追い風になります。稟議を通す必要がありません。

56件を貫く共通項は「APIが無い仕事」

56件を並べて眺めていると、業種も部門もバラバラなのに、ひとつの共通項が浮かび上がります。どれも「システム同士が自動で繋がっていない仕事」だということです。

公式が自分でそう書いている

推測ではありません。公式ドキュメントに明記されています。

「Prefer a connector when one is available: it is often more reliable than clicking through a website. Use the browser for services without a connector（コネクタがあるならそちらを優先せよ。サイトをクリックして回るより信頼性が高い。ブラウザを使うのはコネクタが無いサービスのため）」

つまり、ブラウザで画面を操作する機能は「APIやコネクタが無いとき用の最後の手段」だと、開発元自身が位置づけているのです。逆に言えば、Grok Botの価値が最も出るのは、そこにしか手段が無い仕事ということになります。

象徴的な2件

カタログの中でこれを最も端的に表しているのが次の2件です。

• Vendor Portal Operator：説明文に「portals with no clean API（まともなAPIが無いポータル）」と書かれています。取引先や仕入先のポータルで、更新・席数管理・調達を毎週同じ手順でこなす仕事です
• Security Questionnaire Filler：取引先のセキュリティ審査サイトにログインし、自社の回答集から該当する答えを引いて埋めていく仕事です

どちらも「毎回まったく同じ画面を、同じ順番で踏む」という性質を持っています。人間がやると退屈で、しかもミスが出る。かといってシステム連携を組もうにも、相手側にAPIが存在しない。この隙間が、Grok Botの主戦場です。

中小企業ほど「APIが無い仕事」だらけ

ここが日本の中小企業にとって重要な点です。

大企業向けのSaaSは、たいてい外部連携の口が用意されています。しかし中小企業が日常的に触っている画面は、そうとは限りません。

• 取引先ごとに指定される発注ポータル（相手の都合で仕様が決まる）
• 業界特化型の管理システム（利用社数が少なく、連携機能の開発が後回しになりやすい）
• 行政・自治体の申請サイト（そもそも自動連携を想定していない）
• 古くから使っている社内システム（作った会社と連絡が取れないこともある）

これらは「デジタル化されているのに、自動化はされていない」領域です。画面は存在するが、繋ぐ口が無い。中小企業の事務作業が減らない理由の相当部分は、ここに滞留しています。

どの業務から切り出すかという考え方そのものは、ツールが変わっても共通します。

Codexで定型業務を自動化する設計法｜業務の切り出し方

ただしカタログは「任せるな」と書いてある

ここまで読むと期待が膨らみますが、同じ公式資料をもう一段深く読むと、まったく違う顔が出てきます。

公式スターター文8本すべてが禁止句で終わる

公式ドキュメントには、代表的な8つの役割について「最初にこう指示してください」という例文が載っています。その8本すべての末尾を並べたのが次の表です。

8本中8本が、禁止の指示で終わっています。

「本当の仕事を渡せるAIの同僚」と宣伝している製品の公式スターター文が、例外なく「ただし実際には何も実行するな」で締められている。この落差は、製品を評価するうえで見逃せません。

公式は冒頭でその方針をはっきり述べています。「Start with read-and-prepare work, review the result, then add approved actions（読んで準備する仕事から始め、結果を確認し、それから承認済みのアクションを足せ）」。

カタログの39%が承認待ちを前提にしている

同じ傾向は56件のカタログ本体にも表れます。各カードの説明文を承認・レビューに関する語（approve / review / confirm / drafts only など）で機械的に判定したところ、56件中22件、全体の39%が「人間の承認を待つ」動作を説明文の中に明記していました。

具体的な言い回しはこうです。

• Sales Outbound：「あなたが承認するためのレビューリストを残す」
• Paid Media：「調整を加える前にあなたの承認で止まる」
• Ticket Triage Specialist：「返信を下書きするだけで、静かにしている」
• Travel Coordinator：「予約する前に確認を取る」

残りの61%が勝手に実行するという意味ではありません。説明文に書かれていないだけで、実際の挙動は設定と操作の危険度に依存します。ここで押さえるべきは、公式が推す使い方の既定値が「下書きまで」だという事実です。

承認は提案を止めるだけで、終わった作業は戻せない

そして、公式ドキュメントの中で私が最も重要だと考える一文がこれです。

「An approval controls the proposed action. It does not reverse work already completed（承認が制御するのは提案されたアクションだけである。すでに完了した作業を巻き戻すわけではない）」

承認ダイアログは関所であって、取り消しボタンではありません。止められるのは、これから起きることだけです。手前で終わってしまった10手をまとめて戻す機能ではない。

関連して、テスト実行についても明確な警告があります。「A test run performs real work. It can navigate websites, change files, and call connected tools（テスト実行は実際の作業を行う。サイトを操作し、ファイルを変更し、連携ツールを呼び出しうる）」。お試し実行という安全な砂場は用意されていません。

全部のBotが1台のPCを共有する

もうひとつ、業務で使う前に知っておくべき構造があります。

「All of your Bots share one cloud computer assigned to your user account（あなたのすべてのBotは、あなたのユーザーアカウントに割り当てられた1台のクラウドPCを共有する）」——ファイル、ブラウザのログインセッション、コマンドラインの認証情報は、Bot全体で共有されます。

公式は続けてこう釘を刺します。「Do not use separate Bots as a security boundary（Botを分けることをセキュリティの境界として使うな）」。

「経理用のBot」と「営業用のBot」を分けても、それは担当を分けただけで、金庫を分けたことにはならないということです。経理Botのために銀行サイトへログインすれば、そのセッションは営業Botからも見えます。

さらに「Deleting a Bot does not remove shared-computer files or browser sessions（Botを削除しても、共有PC上のファイルやブラウザセッションは消えない）」とも書かれています。使い終わったBotを消しても、ログイン状態は残ったままです。片付けは別作業になります。

画面を踏む自動化には宿命がある

ここからは、私自身が同じ問題に何度もぶつかった経験から書きます。Grok Botそのものを業務で使った経験ではありません（後述のとおり、利用には月200〜300ドル規模の上位プラン契約が必要です）。私が積んだのは「APIが無いサービスを自動化しようとして苦労した」側の経験です。

私は画面を踏む方式を一度作って、捨てた

私は自社の情報発信を自動化する過程で、記事投稿サービスにブラウザで自動ログインし、エディタ画面を操作して本文を流し込む仕組みを組んだことがあります。まさにGrok Botがやろうとしていることの、手作りの縮小版です。

これは動きました。しかし、運用に乗せると次から次へと問題が起きます。エディタが特定の貼り付け方法しか受け付けない、画面の構造が少し変わるだけで要素を見失う、ログインセッションが切れる——そのたびに手当てが必要でした。

最終的に私はこの方式を退役させました。今もリポジトリの「_legacy（退役置き場）」フォルダにそのスクリプトが残っています。

なぜ裏側のAPIに切り替えたか

代わりに採った方法は、画面を踏むのをやめて、画面の裏で動いている通信を観測し、そのAPIを直接叩くというものです。

発想はシンプルです。画面が動いている以上、裏では必ず何らかの通信が飛んでいます。自分のブラウザで一度その操作を実行し、そのとき飛んだリクエストを記録すれば、以後はブラウザを一切起動せずに同じことができます。

実際にこの方法で、ある配信サービスの予約公開機能のエンドポイントを割り出し、ブラウザ不要のスクリプトに置き換えました。動作は速くなり、画面変更で壊れる頻度は大きく下がりました。

Grok Botは、私が捨てた方をあえて全面採用している

ここで誤解してほしくないのですが、これはGrok Botの欠陥ではありません。設計上の選択です。

裏側のAPIを叩く方法には、決定的な弱点があります。調べる手間がかかることです。1つのサービスにつき、観測して、割り出して、検証する工数がかかります。非エンジニアには現実的ではありませんし、エンジニアでも「年に数回しか使わない画面」のために調べる気にはなりません。

Grok Botはその工数をゼロにします。調べなくていい。人間と同じように見て、押す。だからこそ、対象を選ばずどんなサイトにも当てられる。汎用性という点では、明らかにこちらが上です。

ただし、私が経験した壊れやすさは消えません。壊れやすさは実装の未熟さではなく、画面という不安定なものに依存する方式そのものの性質だからです。公式も対策を指示しています。「Re-test after a website, connector, or source format changes（サイト・コネクタ・元データの形式が変わったら再テストせよ）」。

本当に怖いのは「止まること」ではなく「間違ったまま動き続けること」

画面操作の自動化で最も警戒すべきは、エラーで止まるパターンではありません。止まれば気づけます。

怖いのは、画面が少し変わったのにそれらしく動き続け、間違った場所に間違った値を入れ続けるパターンです。とくにGrok Botのように24時間動き続ける仕組みでは、気づくまでの間に作業が積み上がります。そして先ほどのとおり、承認は完了した作業を巻き戻してくれません。

だから、任せる仕事を選ぶときの判断軸は「AIが上手にできそうか」ではなく「間違っていたときに、こちらが気づけるか」に置くべきです。毎朝ざっと目を通せば異常が分かる仕事は渡せます。半年後の監査で初めて発覚する仕事は渡せません。

ブラウザを使う自動化と、他の手段の使い分けについては、こちらでも整理しています。

Claude CodeClaude Codeの内蔵ブラウザとは｜使い方と自動化ツールの使い分け

中小企業が最初に任せるならこの3つ

56件から、社員数の少ない会社で効果が出やすく、かつ失敗しても被害が小さいものを3つに絞りました。いずれも結果が目に見えて、間違いに気づけるという条件を満たしています。

1. 情報を集めて要約する仕事

カタログでいうChief of Staff、Daily Briefing Writer、Competitive Intelligence Analystにあたるものです。

複数の場所に散らばった情報を毎朝1本にまとめさせる仕事です。メール、予定表、チャット、取引先サイトの更新などを見て回り、「昨日から何が変わったか」「今日決めなければならないことは何か」を出させます。

この仕事が最初の1つ目に向いている理由は明確です。読むだけで、何も書き換えないから。間違っていても実害が出ず、しかも毎朝あなたが読むので、精度が低ければ即座に分かります。

2. 下書きを作る仕事

Sales Outbound、Newsletter Writer、Ticket Triage Specialistの系統です。

返信、提案文、案内文などを下書きまで作らせ、送信は必ず人間が行います。公式のスターター文がすべて「送るな」で終わっているのは、まさにこの使い方を想定しているからです。

小規模な会社ほど、文章を書く時間が経営者に集中しがちです。ゼロから書く時間と、直す時間では負担がまるで違います。ここは費用対効果が出やすい領域です。

3. 画面を踏んで転記する仕事

Vendor Portal Operator、Invoice Coordinator、Security Questionnaire Fillerの系統で、本記事の主題である「APIが無い仕事」の本丸です。

取引先ポータルへのログインと確認、請求書の突き合わせ、審査シートの記入といった、毎回同じ画面を同じ順に踏む作業を任せます。

ただしこれは3つの中で最も危険度が高い領域です。最初は「見て報告するだけ」に限定してください。「今週の未処理は3件、うち1件は金額が発注書と違います」と報告させるところまでで止める。転記や送信を任せるのは、報告が数週間安定してからです。

逆に、最初に渡してはいけないもの

公式が「明示的な境界を設定せよ」と名指ししている操作は、そのまま「最初に渡してはいけないもの」のリストとして使えます。

• メッセージや招待の送信
• コンテンツの公開
• 購入・送金
• データの削除・上書き
• 権限の変更
• 本番環境の変更
• 契約条件への同意

共通しているのは、相手がいる操作か、元に戻せない操作だという点です。送ったメールは戻せません。消したデータも戻せません。承認が巻き戻してくれないのは、まさにこの領域です。

なお、パスワード・二段階認証コード・CAPTCHA・決済確認については、公式が「人間が代わって操作する」手順を用意しています。チャット欄にパスワードを貼ってはいけません。

始める前に決めること——公式が示す7段の手順

公式ドキュメントには、ひとつの仕事を定着させるまでの手順が7段階で示されています。中小企業でも、この順番はそのまま使えます。

1. 仕事の内容、使うシステム、出力の形式、守るべき境界をBotの説明欄に書く
2. 安全な範囲で、実際の仕事を1件だけやらせる
3. 結果が確認できる水準になるまで直す
4. うまくいった手順をスキルとして保存する
5. 別の入力でもう一度試す
6. 失敗時の扱いを決めてから、はじめて定期実行にする
7. 影響の大きい操作は承認の後ろに置いたままにする

私が実務上いちばん重要だと考えるのは5番です。1件うまくいった時点で「動いた」と判断してしまう失敗が非常に多いのですが、1件目は偶然かもしれません。2件目の、少し条件の違う入力で試して初めて、再現性があるかが分かります。

また、定期実行を作る際は「元データが取得できなかったとき、古いデータで進めるのではなく失敗として報告する」というルールを必ず入れてください。黙って古い数字でレポートを作られるのが、最も気づきにくい壊れ方です。

なお、手順を教える機能として、実際の操作を1回見せて覚えさせる方法も用意されています（記録は最大10分・マイク音声は記録されません）。ただし公式は、そうして作られたスキルはあくまで下書きであり、判断ルールや失敗時の処理は人間が後から書き足す必要があると明記しています。1回見せただけで例外処理まで伝わることはありません。

なお仕様上の上限として、1つのBotが持てる定期実行は50件まで、実行履歴は定期実行1件につき直近20回分までが保存されます。定期実行の削除は即時で、取り消しはできません。

AIエージェントに仕事を渡す最初の一歩そのものに不安がある場合は、こちらも参考になります。

非エンジニアのCodex入門｜最初の一歩は何から

料金と入り口——なぜCursorを経由するのか

導入を検討するうえで避けて通れないのが、入り口の分かりにくさです。

Grok Botを使えるのは、SuperGrok Heavy、Cursor Ultra、Cursor Teams Premiumのいずれかを契約しているアカウントです。

報じられている価格は、SuperGrok Heavyが月額300ドル、Cursor Ultraが月額200ドル、Cursor Teams Premiumが1席あたり月額120ドル。個人向けAIツールとしてはかなり高い水準で、法人向けの提供は順番待ちの段階です。

公式FAQによれば、契約には週単位の利用枠が含まれ、対象アカウントは追加利用分を従量で足せる形になっています。実際の条件は変動するため、契約前に必ず最新の料金ページで確認してください。

Cursorが窓口になっている理由

xAIの製品なのにダウンロードもサインインもCursor経由という構造には、背景があります。

2026年8月、SpaceXによるCursorの買収が完了しました。Cursorの公式アカウントは同月14日に「Cursor is now part of @SpaceX」と告知し、SpaceXAIチームに合流してGrok Build、Grok Bot、Grok APIなどの開発に加わると述べています。

この投稿は900万回以上表示され、買収完了はTechCrunchなど複数の媒体でも報じられました（取引規模は約600億ドルと報じられています）。

x.aiのサイト自体も現在は「SpaceXAI」の表記に切り替わっています。つまりCursorは外部パートナーではなく、同じ組織の一部です。認証もアカウント管理もCursor側に寄っているのは、この統合の結果です。

実務上、これは1つ注意点を生みます。プライバシー・データの取り扱い・学習への利用可否といった設定は、いずれもCursor側のアカウント設定に従います。また公式は「Grok Botはクラウドへのデータ保存を必要とするため、Legacy Privacy Modeには対応しない」と明記しています。顧客情報や機密性の高い書類を扱わせる前に、この点は必ず社内で確認してください。

まとめ

公式カタログ56件を実測して見えたことを、要点だけ並べます。

• 営業・マーケが41%、エンジニアリングは9%。Cursor経由で配られているが、中身は開発ツールではない
• 56件を貫く共通項は「APIが無い仕事」。公式自身が「ブラウザ操作はコネクタが無いとき用」と位置づけている
• 中小企業ほどこの領域は広い。取引先ポータル、業界特化システム、行政サイトなど「デジタル化されているが自動化されていない」画面が滞留している
• ただし公式スターター文8本すべてが禁止句で終わり、カタログの39%が承認待ちを前提にしている。既定値は「下書きまで」
• 承認は提案を止めるだけで、終わった作業は戻せない。テスト実行も実作業になる
• 全Botが1台のクラウドPCを共有する。Botを分けてもセキュリティの境界にはならない

最初に任せるなら、①情報を集めて要約する仕事、②下書きを作る仕事、③画面を踏んで転記する仕事（まずは報告のみ）の順です。選ぶ基準は「AIが上手にできそうか」ではなく、「間違っていたときに気づけるか」に置いてください。

画面を踏む自動化は、対象を選ばない代わりに、画面が変われば壊れます。これは製品の未熟さではなく方式の性質です。私たちが自社の運用で最終的に重視するようになったのも、壊れない仕組みを作ることではなく、壊れたときに黙って動き続けない仕組みを作ることでした。24時間動くものを迎え入れるなら、この一点だけは先に決めておくことをおすすめします。