はじめに
Grok Botでは、自分でBotを作るだけでなく、他のユーザーが公開したBotを自分の環境へ追加して使えます。
2026年9月にはGrok Bot公式のBot Marketplaceも公開され、公開されているBotを探して追加できるようになりました。
一方で、公式Marketplace以外にも、Communityで公開されたBotをまとめているサイトがいくつかあります。
そこで今回は、Grok BotのTemplateは、結局どこで探すのがよいのか？を整理します。
その上で、公式MarketplaceとCommunityから実際にBotを追加し、開発フローの中でどこまで使えるのか試してみます。
そもそもGrok BotのTemplateとは
Grok Botでは、特定の役割を持つBotを作れます。
例えば、以下のように、仕事ごとにBotを分けて使えます。
- 採用候補者を探すBot
- Pull RequestをレビューするBot
- SaaSの利用状況を確認するBot
こうしたBotの中には、他のユーザーがそのまま追加して使える形で公開されているものがあります。
この記事では、公式MarketplaceやCommunityサイトから追加できるBotをまとめて「Template」と呼びます。
Templateを追加すると、Botの役割や公開されている設定をベースに使い始められます。
Templateによっては、SkillやRoutine、Integrationなども含まれています。
公式Bot Marketplace公開
Grok Botには公式のBot Marketplaceがあります。
Marketplaceでは、カテゴリやCreatorから公開Botを探し、Botの詳細を確認して自分のGrok Botへ追加できます。
例えばEngineeringカテゴリには、RepositoryやCloud Agentを扱うBotもあります。
Lingxi's Engineer Bot は、指定したRepositoryでCloud Agentを起動し、Pull Requestを定期的に確認するBotとして公開されています。
SpaceXAIが実際に使っているBotも公開されている
Marketplace公開時には、SpaceXAIが社内で使っている Haggle Bot もTemplateとして公開されました。
Haggle Botは調達を担当するBotです。
SpaceXAIは、Haggle BotにVendor Spend、Contract、Usage Dataを扱わせた結果、10万ドルを超える直接的なコスト削減を見つけたと紹介しています。
Haggle Botの説明には、Never spends, signs, or sends without you.と明記されています。
また、SpaceXAIが公開しているSystem プロンプトでは、PERMISSION LINESとして、Botが自動で行ってよいこと、人間の明示的な承認が必要なこと、行わないことが分けられています。
単に「調達について回答するBot」ではなく、何を調べるか、何を提案するか、どこから人間の判断が必要になるかまで含めて役割が設計されています。
公式Marketplace以外にもTemplateを探せる
公式Marketplaceだけでなく、Communityにも公開されたBotをまとめたサイトがあります。
主要なサイトを比べると、次のような違いがあります。
| サイト | 掲載内容 | 特徴 | ユースケース |
|---|---|---|---|
| Bot Marketplace | Grok Bot公式のPublic Bot | Grok Bot公式。カテゴリやCreatorからBotを探して追加できる | まず公式のTemplateを探したいとき |
| UseGrokBot | Xで共有されたBotや利用例 | 元のX投稿とあわせて、実際の利用例を見られる | 利用例を見ながらTemplateを探したいとき |
| grokbot.dev | Shareable Bot、Use Case、Plugin | Communityで共有されたShareable Botを幅広くまとめている | Communityの公開Botを幅広く探したいとき |
| Awesome Grok Bot | 公開されたx.ai/botのShare Template |
Share Templateに絞ったシンプルな一覧。日本語UIもある | 公開Templateだけを手早く一覧したいとき |
| Grok Bot Templates | Public Grok Bot Template | Botの説明に加えて、想定AccessやPermission Notesも整理されている | 追加前にBotの詳細まで確認したいとき |
| GrokMarket | Public Grok Bot Template | カテゴリ、Trending、Recently Addedなどから探せる | Marketplace感覚でCommunityのBotを眺めたいとき |
掲載内容は変化が速いため、以下は2026年9月5日時点で確認した内容
まず公式のTemplateを探すならBot Marketplaceが分かりやすいです。
一方、Communityまで範囲を広げると、公式Marketplaceに載っていないBotや、実際の利用例と一緒に紹介されているBotも見つけられます。
UseGrokBot
UseGrokBotは、X上で共有されたGrok Botの投稿や利用例をまとめています。
Bot単体の一覧ではなく、元のX投稿と一緒に見られるのが特徴です。
そのため、実際の利用例を見ながらTemplateを探したい場合に向いています。
grokbot.dev
grokbot.devは、Shareable Bot、Use Case、PluginなどをまとめたCommunity Directoryです。
Communityで公開されているBotを幅広く探せるため、今回はこちらからもTemplateを選びます。
Awesome Grok Bot
Awesome Grok Bot は、公開された x.ai/bot のShare Templateを一覧できるDirectoryです。
確認時は47件のTemplateが掲載されていました。
掲載対象がShare Templateに絞られているため、公開Botだけを手早く見たい場合に分かりやすいです。
日本語UIも用意されています。
Grok Bot Templates
Grok Bot Templates は、Public Grok Botを一覧できるIndependent Registryです。
Templateを追加する前に、どのようなAccessが想定されているのかまで確認したい場合に便利です。
GrokMarket
GrokMarket は、Marketplace形式のIndependent Directoryです。
カテゴリ、Trending、Recently AddedなどからTemplateを探せます。
Communityで公開されているBotを一覧から眺めて探したい場合に使いやすいです。
今回試すこと
ここからは、公開されているTemplateを実際の開発フローで試します。
今回使うのは次の3つです。
| Template | 入手先 | 役割 |
|---|---|---|
| loops | grokbot.dev | 要求をGoalへ整理し、Coding Agentを起動して進行を管理する |
| Lingxi's Engineer Bot | 公式Bot Marketplace | Cloud Agentを起動し、Pull Requestを監視する |
| PR Reviewer | grokbot.dev | Pull Requestを読み、RiskやTest不足をレビューする |
この記事では、この2つを同じ種類のOrchestratorとして比較します。
- 人間 → loops → Cursor Cloud Agent → Pull Request → PR Reviewer → 人間
- 人間 → Lingxi's Engineer Bot → Cursor Cloud Agent → Pull Request → PR Reviewer → 人間
さらに、作成されたPull Requestを PR Reviewer Bot にも渡します。
loops や Lingxi's Engineer Bot が行う確認に加えて、専用Reviewerを置くことで追加の価値があるのかも見ていきます。
検証環境について
比較では、同じような開発TaskをそれぞれのTemplateへ渡します。
実装対象には、Next.jsとTypeScriptをセットアップした小さな検証用Repositoryを使います。
この時点では大きな機能を入れず、Next.jsの初期画面が起動できる程度の状態にしておきます。
実際のコード変更にはCursor Cloud Agentを使います。
Cursor Cloud Agentは、クラウド上の開発環境でGitHub Repositoryを扱い、コードの変更、Build / Test、BranchへのPush、Pull Requestの作成などを行えるCoding Agentです。
今回はTemplateの検証が主題なので、GitHubとの接続やCursor Cloud AgentのEnvironment作成手順は省略します。
この記事では、Cursor Cloud Agentから検証用Repositoryを扱える状態から始めます。
環境構築の流れは、以下の記事で実際の画面とあわせて紹介しています。
Templateを追加する
実験の前に、3つのTemplateをGrok Botへ追加します。
loopsを追加する
loops は@mattypが公開しているShareable Botです。
grokbot.devの紹介ページからadd to Grok Botを選び、Grok Botへ追加します。
Add to Grok Botをクリックします。
追加すると、Contextに指示やメモリー、連携にGitHubとpstackが表示されます。
ボットを追加をクリックします。
以下のプラグインをインストールします。
- GitHub
- pstack
PR Reviewerを追加するとGitHub PluginのInstallを求められます。
GitHubとの接続にはPersonal Access Tokenが必要で、今回は対象Repositoryに限定できるFine-grained PATを使用します。
Botを追加したあとにSetupを依頼すると、自分の環境側にMemoryとSkillを作成し、Templateで利用するPluginの不足を確認する流れになっています。
こで作成されたMemoryは、Template作成者が過去のConversationから学習したMemoryそのものがコピーされたわけではありません。
Lingxi's Engineer Botを追加する
次に、公式Bot MarketplaceからLingxi's Engineer Botを追加します。
内容を確認してImport Botを実行します。
追加後は、自分のGrok BotにLingxi's Engineer Botが表示されます。
（Notionはインストール不要です）
Lingxi's Engineer Botは、今回のフローでは実装担当そのものではなく、実装をCloud Agentへ渡して進行を管理する役割として使います。
PR Reviewerを追加する
最後に、grokbot.devからPR Reviewerを追加します。
こちらもloops同様に設定します。
これで、3つのTemplateを使う準備ができました。
loopsに実装を任せる
TinyBoardのユーザーのフィードバック用の簡単なフィードバックフォームを追加してもらおうと思います。
保存先やValidation、Database Schemaなどは細かく指定せず、実装前に必要な変更と完了条件を整理するよう依頼しました。
トップページに簡単なフィードバックフォームを追加してください。
実装を始める前に、
必要な変更内容と完了条件を整理してください。
対象RepositoryはTinyBoardです。
loopsはすぐに実装を始めず、まずRepositoryの構成を確認して変更方針と完了条件を整理してもらいました。
フィードバックフォームの配置や送信後の挙動に加えて、既存構成に合わせてSupabaseへの保存、RLS、Server Action、zodを使う方針まで具体化していることがわかります。
内容に問題がなかったため、Cloud Agentへ実装を依頼します。
Pull Requestが作成されたことを確認します。
また、実際にCursor Cloud側で実行結果を確認することも可能です。
完了条件を記載し、ステータスが完了になっていることがわかります。
loopsは要求整理で終わらず、要求の具体化 → Coding Agentの起動 → Pull Request作成後の確認まで進めました。
Lingxi's Engineer Botにも同じ実装を任せる
次に、loopsの変更を含まない同じ状態のTinyBoardを用意し、Lingxi's Engineer Botに同じプロンプトを渡します。
トップページに簡単なフィードバックフォームを追加してください。
実装を始める前に、
必要な変更内容と完了条件を整理してください。
対象RepositoryはTinyBoardです。
loopsと同様にLingxi's Engineer BotもRepositoryを確認し、フィードバックフォームの配置、Supabaseへの保存、RLS、Server Action、Validationなどを含む実装方針を整理してもらいました。
内容に問題がなかったため、Cloud Agentへ実装を依頼します。
Approve & launchを選択すると、Cursor Cloud Agentが起動し、Pull Requestが作成されました。
その後、Lingxi's Engineer BotはPull Requestを30分ごとに監視する常設Automationを作成しようとしましたが、今回は不要なため、拒否し、続く確認でもSkip for nowを選択します。
差分やCIの状態を確認し、SupabaseのCredentialがないため実際のINSERTまでは検証できていないことも未確認事項として整理されています。
最後にMerge it、Keep watching、Request changesが提示され、Mergeするかどうかの判断は人間に戻されることがわかります。
loopsとLingxi's Engineer Botを比較する
同じプロンプトを渡した結果、実装内容には大きな差はありませんでした。
どちらもRepositoryを確認し、Supabaseへの保存、RLS、Server Action、Validationなどを含む実装方針を整理し、Cursor Cloud Agentへ実装を任せています。
違いが出たのは、Pull Request作成後の進め方です。
loopsは、最初に整理した完了条件とPull Requestの内容を照合して確認しました。
一方、Lingxi's Engineer BotはPull Requestを確認したあと、30分ごとの継続監視も提案し、最終的にMerge it、Keep watching、Request changesを提示して判断を人間へ戻しました。
今回の結果では、loopsは完了条件を基準に1つのTaskを最後まで進める役割が強く、Lingxi's Engineer BotはPull Requestの監視やMerge判断まで含めて開発全体を管理する役割が強く出ました。
PR ReviewerにPull Requestをレビューさせる
最後に、loopsが作成したPull RequestをPR Reviewerに渡します。
PR#4をレビューしてください。
特に以下を確認してください。
- 要求と実装が一致しているか
- 変更によるRegression Risk
- Error handling
- Test不足
- Merge前に確認すべき点
コードの変更やPRへのコメント投稿は行わず、レビュー結果だけをこのChatにまとめてください。
PR Reviewerは、要求と実装はおおむね一致していると判断した上で、Migrationの未適用やpnpm lint / pnpm buildの未確認、Error handlingやTest不足などを指摘しました。
（添付の画像は、Error handlingやTestが欠けておりますが、実際は指摘されています）
今回はPR Reviewerの結果をChatで確認するところまでにしましたが、Grok BotではBot同士でMessageを送り、Group ChatやThreadでContextを共有できます。
そのため実運用では、PR Reviewerの指摘をLingxi's Engineer Botへ引き継ぎ、必要に応じてCloud Agentへ修正を依頼するフローも組めます。
また、今回Lingxi's Engineer Botは30分ごとのPR監視を有効にすれば、人間が毎回Chatから確認を依頼せず、PRの状態変化を追わせることもできます。
まとめ
今回は、Grok Botの公式Bot MarketplaceとCommunityサイトを比較し、実際に3つのTemplateを開発フローの中で試しました。
loopsとLingxi's Engineer Botは、どちらもCursor Cloud Agentに実装を任せながら、その外側でTaskを進めるBotです。
同じプロンプトを渡したところ、実装方針には大きな差はありませんでしたが、Pull Request作成後の動きには違いがありました。
loopsは、最初に整理した完了条件とPull Requestの内容を照合して確認しました。
一方、Lingxi's Engineer BotはPull Requestを確認したあと、30分ごとの継続監視も提案し、最終的にMerge、継続監視、修正依頼の判断を人間へ戻しました。
また、PR Reviewerに同じPull Requestをレビューさせると、Migrationの未適用やError handling、Test不足など、loopsの完了条件チェックとは異なる観点の指摘も確認できました。
Grok BotではBot同士でMessageを送り、Taskを引き継ぐこともできます。
そのため、実運用ではPR Reviewerの結果を別のBotへ渡し、必要に応じてCloud Agentへ修正を依頼するといったフローも組めます。
一方、Templateを追加すればすぐにすべて使えるとは限りません。
今回も、loopsではGitHubとpstack、PR ReviewerではGitHub Pluginの設定が必要でした。
Lingxi's Engineer BotではOptionalなNotionも提示されました。
Templateを使うときは、Botの役割だけでなく、必要なPluginやPermission、どこまで自動でActionを実行するのかも確認しておく必要があります。
公式MarketplaceだけでなくCommunityにも多くのTemplateが公開されているので、ゼロからBotを作る前に、用途に近いTemplateがないか探してみるのが良いと思いました。
参考
- Bot Marketplace - Grok Bot
- Lingxi's Engineer Bot - Bot Marketplace
- Haggle Bot - Bot Marketplace
- Setting Grok Bot loose on procurement - SpaceXAI
- Grok Bot公式のMarketplace / Haggle Bot投稿
- Create and manage Bots - SpaceXAI Docs
- Message and collaborate - SpaceXAI Docs
- Skills and routines - SpaceXAI Docs
- UseGrokBot
- grokbot.dev
- loops - grokbot.dev
- PR Reviewer - grokbot.dev
- Awesome Grok Bot - Templates
- Grok Bot Templates
- GrokMarket