0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@agent-dev-notes

Grok Bot の始め方 — Slack と GitHub をつなぎ、役割ごとの Bot に任せる

0
Last updated at Posted at 2026-10-18

はじめに

Grok Bot（名前と役割を持たせた AI のチームメイトを常駐させる製品。Bot はみな、ブラウザやターミナルの付いたクラウド上の 1 台のコンピュータを共有して作業します）を、私は仕事で毎日使っています。公式の Overview にあるとおり、Bot どうしでメッセージを送り合い、仕事を受け渡すこともできます。

使い始めるときの助言として、Grok Bot の開発に携わる lauren さん（@poteto）の X の投稿 が参考になります。初めて使うなら、まず普段使っているアプリ（カレンダー、Slack、課題管理、CRM、Google Drive など）をつなぐと、Bot が仕事の文脈と必要な道具を得られる、という内容です。

この記事では、私がそれに加えて決めていることを、3 つに分けて書きます。アプリをつなぐこと、Bot を役割ごとに分けて窓口の Bot 1 つから頼むこと、外に出す操作は自分ですることです。

Slack と GitHub をつなぐ

私がつないでいるアプリは Slack と GitHub だけです。どちらもまず読むことから始めました。Slack では自分あての依頼やメンションを Bot にまとめさせ、GitHub では PR やコードを読ませています。

アプリは公式の Use the computer and apps の手順どおり、Connect apps からコネクタとして足します。つないだコネクタはアカウント全体で使えるので、どの Bot も同じ Slack と GitHub を読めます。

X はつないでいません。同じページの「Search and read X」 によると、Bot は X の公開の内容を、X のアカウントをつながずに検索して読めます。読むだけで、本人としてログインはしません。DM やブックマーク、ホームのタイムラインを読ませたいときは、Connect apps から X のプラグインを足して、X でサインインする必要があります。

役割ごとに Bot を分ける

初めは 1 つの Bot に何でも頼んでいましたが、いまは仕事ごとに Bot を分けています。公式の Create and manage Bots も、目的、使う道具、承認が要る範囲などが違う仕事には、別の Bot を作るよう勧めています。

Bot 受け持つ仕事
開発 issue を受けて要件と設計の案を出し、承認されたら実装して Draft PR（まだレビューやマージに出していない下書きの PR）を作る
QA 開発の Bot の PR を別の目で検証する。ほかの人から頼まれた PR のレビューの下準備もする
Slack 依頼やメンションを一覧にまとめ、返信の案を作る
リサーチ 毎朝、X なども見て前日の技術ニュースを選び、Slack に投稿する
コード調査 リポジトリやコードを読んで調べ、根拠を付けて依頼元の Bot に返す

ほかにも、Bot の設計を受け持つ Bot などがいます。

担当の Bot の説明文には受け持つ仕事のほかに「やらないこと」も書いています。たとえば QA の Bot は Approve もマージもせず、Slack の Bot は返信の案を作るだけで、私が確かめるまで投稿しません。報告することがないときは何も送らない、とも書いています。

窓口の Bot 1 つから頼む

私が頼むのは窓口の Bot（名前は Grok Bot のままです）1 つだけです。窓口が担当の Bot に振り分け、結果を取りまとめて返します。どの仕事をどの Bot に回すかの決まりは、Bot どうしが読む共有のメモに書いています。たとえば「いま私が聞きたいことは窓口の Bot、放っておいても回ってほしい Slack まわりの作業は Slack の Bot」という使い分けです。

開発の流れは次のとおりです。

開発の Bot は、設計が承認されるまで実装を始めず、作るのは Draft PR までです。QA の Bot は PR を検証して判定と指摘を返しますが、Approve もマージもしません。ほかの人の PR のレビューは読み取りだけで行います。なお、いま開発の Bot に任せているのは、影響範囲の狭い修正だけです。大きな変更や複雑な開発は、Grok Bot には任せず、私が Claude Code などを使って進めています。

図には Bot どうしと私のあいだの受け渡しだけを描いています。QA の指摘は開発の Bot に戻り、同じ PR で直します。マージの前には Codex と Cursor（どちらも AI のコーディングツール）による最終レビューがあり、実機での試験が必要そうな変更なら、その後に試験します。マージの前に試せる機能は AI が試験して私が要所を確かめ、AI でできない部分だけを私が試します。マージしないと試せない機能は、マージの後に試験します。

窓口を通らない受け渡しもあります。Slack の Bot はコードを調べる必要がある依頼を コード調査の Bot に頼み、根拠付きの結果を返信の案に使います。公式の Message and collaborate にあるとおり、Bot は別の Bot にメッセージを送って仕事を渡せます。

投稿・Approve・マージは自分でする

Slack の返信、GitHub のコメント、Approve、マージは私がします。Bot が作るのは案（Draft PR を含む）までで、私が確かめてから送ったり、反映したりします。Bot が案を作って私が Slack に送るときは、Grok Bot が作った文だとわかる一言を添えています。公式の Approvals, security, and privacy も、メッセージの送信や公開のような操作は、依頼の中で止める所を決めておくよう勧めています。同じページには Bot を分けてもセキュリティの境界にはならないとも書かれています。すべての Bot が 1 台のコンピュータと、そこにあるログインを共有するためです。私の環境でも、どの Bot も技術的にはマージや投稿ができてしまうので、各 Bot の説明文と、共有のメモで止めています。

説明文とメモでお願いするだけではありません。主なリポジトリでは、もともと main ブランチへの直接の push を GitHub のルールセット（ブランチを守る設定）で禁止しています。このルールには管理者も含めて例外を作っていないので、私のアカウントで動く Bot もその制限を受け、機械でも止まります。なお、ルールセットも従来のブランチ保護も、無料プラン（GitHub Free）では公開リポジトリなら使えますが、非公開リポジトリでは使えません。非公開リポジトリで使うには、GitHub Pro や GitHub Team などのプランが要ります（GitHub Docs の About rulesets と About protected branches）。

米国の NIST・NSA・CISA が 2026 年 10 月 16 日に公開した Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation にも、近い考え方が書かれています。これは主に、最先端のエージェントを学習・評価する組織に向けた任意の指針です（そうしたエージェントを導入する側にも当てはまりうる、とも書かれています）。この指針は、エージェントへの指示で作業の範囲と制限をはっきりさせるように書いています。そのうえで、エージェントが設定の不備や弱点をよく見つけて使う前提で、セキュリティの仕組みを組むようにとも書いています。この2点は、私の運用にも当てはまると考えています。

もう一つ、Bot を自分のログインで動かすと、自分にできることは、技術的には Bot にもできてしまいます。そのため、Bot が GitHub を触るときの権限は、普段のものとは分けておくのが安全です。具体的には、Bot の GitHub の作業を、使えるリポジトリと権限を絞った専用のトークン（GitHub の fine-grained personal access token など。GitHub Docs の Managing your personal access tokens）に分け、普段の GitHub のログイン（ブラウザやコマンドライン）は、Bot が使える共有のコンピュータに残さないことです。Bot 専用の GitHub アカウントを作るのも一つの方法です。公式の Approvals, security, and privacy も、使えるサービスでは範囲を絞ったサービス用のアカウントを使うよう勧めています。

コネクタで GitHub をつなぐ場合も、考え方は同じです。共有のコンピュータにあるログインと同じく、つないだコネクタの権限もどの Bot も使えます。Bot が触れる範囲は、共有のコンピュータに残したログインと、つないだコネクタに許した権限を合わせたものです。トークンを絞っても、それより広い権限のコネクタをつないだままだと、Bot はその範囲まで触れます。同じ公式のページは、コネクタは仕事に必要なものだけをつなぎ、定期的に見直し、要らなくなったら削除するか、元のサービスの側で許可を取り消すよう勧めています。

投稿を私がするという決まりの例外は、リサーチの Bot だけです。この Bot には Slack のプライベートチャンネルに確認なしで投稿させています。リスクが低いと判断したためです。この Bot は前日の技術ニュースを選ぶとき、X で話題になっているものも含め、X から拾った項目には印を付けます。反響の数は実際に取れたものだけを書かせています。

始めるときは、まずアプリをつなぎ、仕事ごとに Bot を分け、外に出す操作の前で止まるように決めておくことをおすすめします。

dots との違いと、Grok Bot を使っている理由

OpenAI の dots も dot ごとのクラウドのコンピュータで作業を続ける常駐型のエージェントです。2026年10月時点の dots の発表とヘルプの Getting started with your dot、dots のドキュメント、Grok Bot の料金のページと Grok Bot for Teams and Enterprise をもとに、Grok Bot と違う点を表にしました。dots は出たばかりなので、この表の内容は今後変わるかもしれません。

項目 dots Grok Bot
エージェントの数 いまは主になる dot が 1 体。dot を増やす機能は今後の予定 役割ごとに Bot を作れる
コンピュータ dot ごとに専用のクラウドのコンピュータとブラウザ すべての Bot で 1 台を共有
コーディング用のエージェントへの依頼 Codex のクラウドの環境にタスクを作れる Cursor の Cloud Agent に任せられる
X の公開の投稿を読む クラウドのブラウザはあるが、X 専用の機能の記載は公式の資料に見当たらない X のアカウントをつながなくても、公開の投稿を検索して読める
使えるプラン ChatGPT の Pro と Business Premium に、1 体目が追加料金なしで含まれる 従来の Cursor の有料プランや X Subscription の Premium 以上などに含まれる

コンピュータの持ち方は、どちらにも良い点と注意点があります。専用のコンピュータなら、作業の場所が dot ごとに分かれます。そのかわり、ブラウザのログインやファイルは、その dot のコンピュータの中に別に持つことになります。共有の Grok Bot では、ある Bot がログインしたサイトや作ったファイルを、ほかの Bot もそのまま使えるので、受け渡しのたびに準備をやり直さずに済みます（公式の Overview）。注意点は、前の節に書いたとおり、Bot を分けても権限は分かれないことです。

今（2026年10月時点）比べると、いちばん大きい違いは、役割ごとに Bot を分けられるかどうかです。この記事の使い方は今の dots ではできません。ただし dots も、将来は dot を増やせるようになる予定です。

私が Grok Bot を使い続けている主な理由は、次の5つです。

  1. 役割ごとに Bot を分けられる

    いちばん大きい理由で、上に書いた dots との違いと同じです。

  2. 普段使っているコーディングの道具を Grok Bot から呼び出せる

    Grok Bot は必要に応じて、Cursor の Cloud Agent にコーディングを任せられます（チームの管理者向けのページですが、Grok Bot for Teams and Enterprise に書かれています）。Cloud Agent は、クラウドの仮想マシンで動くコーディング用のエージェントです（Cursor Docs の Cloud Agents）。私のプランでも使えていて、開発と QA の Bot は、普段は実装や検証を Cloud Agent に任せています。

    また、Bot が共有するコンピュータではコマンドラインも使えます（公式の Use the computer and apps）。私はそのコンピュータに Claude Code と Codex を入れて、ログインしています。私が指定したときは、Bot がそれらを使います。このログインもすべての Bot で共有されるので、指定したときだけ使うというのは決まりで、仕組みで止めているわけではありません。私は普段から Cursor、Claude Code、Codex を使い分けているので、それらを Grok Bot からそのまま呼べるのが合っています。

  3. X の公開の投稿を、アカウントをつながずに検索して読める

    これも大きな理由の一つです。公式の「Search and read X」によると、Bot は X のアカウントをつながなくても、X の公開の投稿を検索して読めます。読むだけで、私としてログインするわけではありません。リサーチの Bot が X で話題になっている技術ニュースも拾えるのは、この機能のおかげです。dots にも調べものに使えるクラウドのブラウザはありますが、X を検索して読む専用の機能は、2026年10月時点の公式の資料（発表、ヘルプ、ドキュメント）には見当たりませんでした。

  4. 使うモデルが広がった

    2026年10月7日、Elon Musk 氏が X の投稿で、Grok Bot について次のことを伝えました。SpaceX は今後、タスクごとにいちばん良いバックエンドのモデルを使い、その中には Claude Opus 5.5 などほかの会社のモデルも含まれる、という内容です。同じ日に、この投稿への反応に lauren さんが、Opus はすでに展開が始まっていると答えています。公式の Grok Bot の Security のページとヘルプの Which AI models power Grok Bot? によると、モデルは Grok Bot が選び、利用者は選べません。タスクごとにいちばん良い結果が見込めるモデルを使い、xAI のモデルか、ほかの提供元のモデルが使われ、依頼ごとに変わることもあります。ただし、どのタスクでどのモデルが使われるかは、公式には書かれていません。

  5. 利用枠が別にある

    私は従来の Cursor の有料プランで使っていて、Grok Bot の発表のとおり、Bot 自身の利用分は Cursor や Grok のプランの利用分とは別に数えられます。ただしプランによって扱いが違い、料金のページによると、X Subscription のプランでは Cursor や Grok のアプリと同じ週ごとの枠から使います。

そして、もともと Grok Bot を使っていて、dots に移る理由がなかったこともあります。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?