Grok Botで複数AIエージェントのオートメーションを構築してみた

2026年9月19日

もともと、Codexを、5時間枠や7日枠の制限に達しないように注意していても、毎日実行されるオートメーションによって利用枠に到達してしまうということがあったので、Codexで設定しているオートメーションの一部でも、他のAIに任せることができないかを検討していた。候補はClaude Codeであったが、これまでに、MacOSの制限や外部SSDに対するアクセスの不安定さを感じたことがあったので、すぐにClaude Codeへの処理分散は行なっていなかった。そんなとき、Grok Botという存在を知ったので、この選択肢を検討してみることにした。

まず検討したのは、Grok Botで、複数のAIエージェント（Bot）を設定し、ニュースを収集し、重複を除去して、選択したニュースを配信するというオートメーションで、この構成案の提案をChatGPT-5,6 Solに頼んだ。結果的に、ニュース配信に関わる3つのBotのほか、各Botの状態を監視する「AI Agent Supervisor」と、Codexなどのオートメーションの状態を監視する「Automation Watchdog」を設定した。本記事は、ChatGPT-5.6 Solとの質疑応答に基づく記録である。

Grok Botのチャット画面で、左側には設定したAIエージェント（Bot）が並び、Botを選択することによって、そのBotとのチャット画面が表示される。Grok Botでは、Cloudで、1台のPCを借りる構成になっており、右側の画面にはそのPCのデスクトップ画面が表示されており、ブラウザ、ファイルマネージャー、Terminalのアイコンが並んでいる。このPCでソフトウェアのインストール、ディレクトリの作成、ファイル保存なども行える。また、Computer Useのような操作も行うことができる。また、画面の下部には、音声入力のためのボタン、音声チャットを行うためのアイコンが並んでいる。
音声チャットでは、AIエージェント（Bot）ごとに声を変えることができる。

注）本記事の内容は正確性を保証するものではありません。

今回設定した5つのBot（アシスタントBotを除く）

現在の構成では、1体の万能Botにすべてを任せるのではなく、それぞれに担当を決めている。

Bot	主な役割	処理内容
CarPlay / Android Auto Bot	車載関連情報の収集	CarPlay、Android Auto、対応アプリ、AI関連ニュースを収集
Home Assistant Bot	スマートホーム情報の収集	Home Assistant、ESPHome、Matterなどの情報を収集
Blog Idea Editor	記事候補の整理	集めたニュースを整理し、ブログ記事候補を作る
Automation Watchdog	自動処理の監視	CodexなどのAutomationが正常に動いたか確認
AI Agent Supervisor	全体監督	各Botや監視対象の状態をまとめる

役割を大きく分類すると、情報収集 → 情報整理 → 監視 → 全体監督という流れになる。

Botの設定要領

各Botの設定は、下図のように、Botに名前を設定し、各Botの「説明」欄に役割を入力して行う。
また、各Botの音声を28パターン（原稿執筆時点）から選択することができ、Bot毎に音声を変えることができる。
さらに、音声スピードを速くしたり、通知の有無を切り替えることができる。

共有領域の設定

Grok Botを使い始める前は、複数のBotを用意し、それぞれのAIが自律的にメッセージを交換して仕事を進める構成にしたいと考えていたが、今回は、ChatGPT-5.6 Solの提案に従って、そこまで自由な構成にはせず、基本的には所定の順序で、AIのメッセージが伝達されるように構成した。

また、仮想PCに

/workspace/agent-team/

という共有領域（共有フォルダ）を設け、ここに状態や処理結果を残す方式にした。

主な用途は次のとおりである。

共有フォルダ内に設けられたサブ領域	用途
status	現在の処理状態
reports	BotやAutomationの実行結果
history	過去の実行履歴
config	Botや監視処理の設定

また各Botの役割には、「この処理結果を次にどのBotへ渡すか」をあらかじめ記述している。

つまり、Bot A → 共有ファイル → Bot Bという比較的単純な構造である。

実際に運用してみると、この方式には大きな利点があった。AI同士が際限なく会話することがないため、処理の流れが追いやすく、トークン消費も予測しやすい。さらに、「どのBotが何をしたか」を後から確認しやすい。

将来的にはBot同士をもっと自由に会話させる構成も試してみたいが、まずはこの疎結合型の構成から始めることにした。

Grok Botでは、複数のAIエージェント（Bot）を設定し、それぞれのBotにまず基本的な役割を設定して、それらのBot間でも情報交換が自動的に発生するような構成にするのが一番の醍醐味と思っていたが、ChatGPT5.6 Solは、それでも共有ファイルを設けた方がよいと提案してきたので、今回はその構成を採用することにした。結果的には、各Botの役割の記述に、出力をどのBotに引き継ぐかを指定しているので、Bot間での自由なメッセージ交換は発生しないかもしれない。自由なメッセージ交換を許容する構成は、トークン使用量が激増するかもしれないが別の機会に試したい。

Routineを使って定期実行する

Grok BotにはRoutineがあり、決めたスケジュールでBotを起動できる。

今回のニュース関連処理では、例えば次のような流れを設定した。

時刻の例	Bot	処理
6:30	CarPlay / Android Auto Bot	車載関連ニュースを確認
6:45	Home Assistant Bot	Home Assistant関連情報を確認
7:00	Automation Watchdog	夜間・早朝の処理結果を確認
7:15	AI Agent Supervisor	全体状態を確認

ただし、実際に使ってみて分かったことがある。

Routineは、指定した時刻どおりに必ず実行されるとは限らなかった。

数分程度ではなく、かなり遅れて実行されたこともあった。

したがって、「7時ちょうどに必ず結果が必要」という用途と、「朝のうちにニュースが集まっていればよい」という用途では、扱いを分けた方がよさそうだ。

今回のニュース収集では多少遅れても大きな問題にはならないが、正確な時刻が要求される処理では注意が必要である。

本記事執筆時点では、設定した時刻からかなり遅れて実行されることがあった。数分どころの遅れではない。この状況はバージョンが進むにつれて徐々に改善されていくのかもしれないが、処理実行時刻を決める上で考慮すべき課題となっている。

「クラウドだけで完結する処理」と「Macを使う処理」は分けて考える

ニュース収集のようにWeb上の情報だけで完結するRoutineであれば、Mac側のファイルや権限をあまり意識する必要はない。

一方、

外部SSDを読む
Obsidianを書き換える
Mac内のファイルを処理する
Home Assistant関連ファイルを変更する

といった処理では話が変わる。MacOSのTCC権限やボリュームのマウント状態など、AIそのものとは別の問題が発生するからである。

このため現在は、「クラウドで完結する監視・情報収集」と「Macで実際に作業する処理」を分離するという方向で構成を整理している。役割分担の例を下表に示す。

処理	Grok Bot	Codex
Webニュース収集	◎	△
定期的な情報監視	◎	○
Bot全体の監視	◎	△
Mac内ファイル操作	△	◎
Obsidian更新	△	◎
Home Assistant関連作業	△	◎
ブログファイル処理	△	◎
スクリプト作成・修正	○	◎
自動処理結果の監視	◎	○

簡単に言えば、

Grok Bot＝「見る・集める・監視する」

Codex＝「Macで実際に作業する」

という役割分担です。

これによって、ニュースを探すだけの処理にCodexの利用枠を大量に使ったり、反対にGrok BotへMac内部の複雑な作業を任せたりすることを避けるようにするという考え方である。

Automation Watchdogを作った理由

今回の構成で、実際にかなり役に立っているのがAutomation Watchdogである。

自動処理で怖いのは、「失敗した」という通知が来ることだけではない。

もっと困るのは、本来動くはずの処理が、何も言わずに動いていないことである。

そこでAutomation Watchdogには、各Automationの結果を確認させている。

当初は、

success
failed
missed

の3状態を中心に考えていた。

その後、実際に外部SSDなどを監視していく中で、もう一つ状態を分けた方がよいことが分かった。

それが、

ACCESS

である。

例えば、

外部SSDがマウントされていない
MacOSのTCC権限でアクセスできない
Operation not permittedが発生した

という場合は、処理そのものが失敗したとは限らない。

そのため現在は、

状態	意味
success	正常終了
failed	処理そのものが失敗
missed	実行されるべき処理が確認できない
ACCESS	権限・マウントなど実行環境側の問題

というように分けて考えている。

これは、自動化システムを作るうえで思った以上に重要だった。

Watchdogは実際に異常を見つけた

この仕組みが本当に機能するのかは、構築時には分からなかった。

しかし実際に使ってみると、Automation Watchdogは異常を検出した。

例えば、

launchd-env-wbgt-65042

という処理が動作していないことを指摘したことがある。ただし、これは既知の課題で修復を予定しているオートメーションだった。

さらに、Codex Automationが利用制限（7日枠）に達し、開始後約7秒で失敗したケースも検出した。

そのときには、単に「失敗しました」で終わらず、どう対応するかの選択肢が提案された。

そこで「自然回復を待つ」と回答したところ、その判断を記録し、監視を継続しつつ判断待ち状態を解除する処理まで行われ、さらに、Slackに通知され、Automation Watchdogとその情報が共有された。

この辺りは、構築前に想像していたよりも実用的だった。

単なる「エラー通知Bot」ではなく、

「自動処理の結果を確認し、対応方針まで管理するBot」

として動作し始めている。これは、Botの役割の詳細を決めたChatGPT-5.6 Solの提案の成果とも言える。

Grok Botを使ってみて分かったこと

今回、複数のAIエージェントをまともに使ったのは初めてだったが、使ってみると、Grok Botには想定外の利点があった。

Grok Botの画面では、左側にBotが並び、それぞれに最新回答の一部が表示される。また、新しい回答があるBotには未読を示す表示が付くため、「どの担当から新しい報告が来ているか」が分かりやすい。

もう一つ良かったのが、質問先が明確になることである。Home Assistantについて確認したければHome Assistant Botへ、CarPlayについて確認したければCarPlay / Android Auto Botへ質問する。万能AIとの長い会話では、「これまでの経緯をもう一度説明する」ということが発生しがちだが、担当を分けると、「毎回総合受付に説明する」のではなく担当者に直接聞くことに近い。

利用枠は思ったより重要だった

一方、複数Botを増やせばよいというものでもない。

今回の構成を作った際には、Grok Bot側の週間利用枠の約17％を構築時に消費した。

その後、ニュース配信用Routineを1回動かした時点で23％となり、さらにBotへいくつか質問した時点では30％となった。

今回の実測では、ニュース配信用Routineを1回実行した前後で約6ポイント増えたことになる。ただし、この数値はあくまで今回の構成での実測値である。

検索するニュース量、Bot数、回答量、モデルや処理内容などで変わるため、「Routineは必ず6％使う」という意味ではない。それでも分かったことがある。Botを設計するときには、「何ができるか」だけではなく「それを毎日動かしたときに、週間利用枠をどれだけ使うか」まで考える必要がある。

特に定期処理は、一度の消費量が小さく見えても毎日積み重なる。

Grok BotとCodexは競わせるのではなく役割を分ける

今回の構成では、

Grok Bot＝見る・集める・監視する

Codex＝Mac上で実際に作業する

という大まかな分担にしている。

これは、「Grok Botの方が優れている」「Codexの方が優れている」という話ではない。同じAIでも、得意な実行環境や利用枠、アクセスできる対象が違う。

そのため、処理内容によってAIを使い分けるという考え方が必要になる。

ただし、このテーマを掘り下げると今回の記事とは別の記事になる。

Grok Bot、Codex、Claude Code、Cursor Automations、My Machines、Grok Bot Routineなどを、

Web調査
コーディング
ローカルファイル
外部SSD
Home Assistant
Obsidian
定期実行
監視
バックアップ

といった処理ごとにどう使い分けるかについては、別途、検討することにした。

今後変更したい部分

現在の構成が完成形というわけではない。

例えばmacOS側には、

launchd-env-wbgt-65042

のようなローカル自動処理が残っている。

macOSの権限やOS側の変更による影響を受けやすいため、この部分についてはCodex Automation側へ移すことも検討している。

また、現在はBot同士を自由に会話させる方式ではなく、共有ファイルと明示的な引き継ぎを中心にしている。

将来的には、

Bot間の直接連携を増やす
Claude Codeもバックアップ要員として組み込む
Codexが動かなかったときに別AIが補完する
監視結果をさらに統一形式で記録する

といった拡張も考えられる。

ただし、AIエージェントを増やすほど利用量と構成の複雑さも増える。

今のところは、「必要な役割だけを分け、共有ファイルで状態を残す」という現在の方式が扱いやすいと感じている。

複数のAIエージェント構成をまともに使ったのは今回が初めてであり下記のことが分かった。

・Grok Botの操作画面では、左側に複数のBotが並び、各Botに、「最新の回答」の一部が1行で表示され、回答が更新されたBotには、未読を示す丸印がつくので、どのBotから新しい回答が来ているのかが分かりやすい。

・Botの役割が分かれているので、この質問はどのBotに対して行うべきかが分かりやすく、直接、担当者に質問できるので、話が早いというか、余計な前提を指示に含める必要がなく、効率的である。

・「Automation Watchdog」もちゃんと仕事をしており、「launchd-env-wbgt-65042」というオートメーションが動作していないことを指摘してくれたり、Codexのオートメーションが「Codex の usage limit 超過で約7秒で失敗したこと」を報告し、どうするかの選択肢を表示してくれたりしている。これには「自然回復を待つ」という回答をしたところ、「自然回復待ちと記録しました。監視は継続するが判断待ちフラグは下ろしました。Slack スレッドと Automation Watchdog にも同じ内容を共有済みです」という回答が帰ってきた。ChatGPT-5.6 Solが提案した役割記述の内容によるものと思われるが、結構まともに動いているという印象を持った。

最後に、Cursor Proのプランの利用料金と、AIが利用できる利用枠について調査を行ったので紹介する。

Cursor Proを使って初めて分かった「3つのAI利用枠」の仕組み

Cursor Proを使い始めた当初、私は「月額料金を払っているのだから、その中に1つのAI利用枠がある」と単純に考えていたが、Grok Botを使い始めると、そう単純ではないことが分かってきた。

Cursorの「設定」画面の「Spending」というページには、

Cursor Models
Other Models
Grok Bot

という異なる利用量を示す項目があり、しかも、Cursor ModelsとOther Modelsは月単位、Grok Botは週単位でリセットされるということだった。さらに、ある枠を使い切ったあとに別の枠へ移るケースもあれば、まったく別枠のまま止まるケースもあることが分かった。

ここが非常に分かりにくかったので、ChatGPT-5.6 Solと何度か質疑応答を行いながら整理してみたので紹介する。

まずCursorの料金プランを確認する

2026年9月現在、個人向けの主な料金プランは次のようになっている。

プラン	月額	特徴
Hobby	無料	利用制限あり
Pro	$20	Cursor Models、Other Models、Grok Botなどを利用可能
Pro+	$60	ProよりAgent利用枠が大きく、Grok Bot枠も増加
Ultra	$200	Agent利用枠が大幅に増え、Grok Botも最大の週間枠

Cursor自身は、日常的にAgentを使うユーザーにはPro+、大量に利用するユーザーにはUltraを位置付けている。Pro+はProのAgent利用上限の3倍、UltraはProの20倍という案内になっている。(Cursor)

ただし、ここで注意したい。

月額$20のProを契約したからといって、すべてのAIが1つの共通枠を使うわけではない。

現在のCursorには複数の利用枠があることが分かった。

Cursor Proには実質的に3種類の利用枠がある

私が最初につまずいたのが次の3つである。

利用枠	主な対象	リセット
Cursor Models	Cursor Grok 4.6、Grok 4.5、Composer 2.5など	月単位
Other Models	Claude、GPT、Geminiなどの外部モデル	月単位
Grok Bot	Grok Botのチャット、Routine、Computer Useなど	週単位

Cursorの公式ドキュメントでも、Cursor ModelsとOther Modelsは別々の月間プールとして管理されている。Cursor ModelsにはCursor Grok 4.6、Grok 4.5、Composer 2.5が入り、OpenAI、Anthropic、Googleなどの第三者モデルはOther Modelsから消費される。(Cursor)

そしてGrok Botは、この2つとはさらに別である。

Grok Botには独立したWeekly usage（週間利用枠）があり、毎週リセットされる。(Cursor)

Cursor Modelsとは何か

Cursor自身が提供するモデル用の枠である。

現在は主に、

Cursor Grok 4.6
Cursor Grok 4.5
Composer 2.5

などがここから消費される。(Cursor)

ここで興味深いのは、単純に「何回質問したか」で減っているわけではないことである。モデルごとにトークン単価が違うため、重いモデルや長い処理を使えば、それだけ早く利用量を消費する。

例えばCursor Grok 4.6の標準モードは、現在の公表料金では100万トークン当たり入力$2、キャッシュ入力$0.50、出力$6相当で計算される。(Cursor)

つまり、100回使ったから100回分減るという昔ながらの回数制限ではない。

「どれだけ計算資源を使ったか」に近い仕組みになっている。

Other Modelsとは何か

Claude、GPT、GeminiなどCursor以外の企業が提供するモデルを直接選択すると、基本的にはこちらを使用する。

例えば現在のCursorでは、

Claude Sonnet 5
Claude Opus 5
GPT-5.6 Sol
GPT-5.6 Luna
Gemini 3.1 Pro

などがOther Modelsとして掲載されている。(Cursor)

ここでも、モデルによって消費速度が違う。安価なモデルを何度も使う場合と、高価な推論モデルで長時間のAgent処理を行う場合では、同じ1回でも利用枠への影響はまったく違う。これは「あと何回使えるか」という感覚とは少し違う。

回数ではなく、モデル価格を基準にした利用予算を使っているわけである。

では、どの利用枠から先に減るのか

ここが今回、一番分かりにくかった部分である。

モデルによって順序が違う。

Cursorスタッフによる説明では、Cursor GrokやComposerなどのCursor Modelsは、まずCursor Models枠を使い、それを使い切ると、残っているOther Models枠へ移ることがある。(Cursor – Community Forum)

一方、GPTやClaudeなどの名前を指定した第三者モデルは、Other Modelsから消費される。

整理すると次のようになる。

使用するもの	最初に使う枠	次に使う枠	その後
Cursor Grok / Composer	Cursor Models	Other Modelsの残量	On-Demand
Claude / GPT / Gemini	Other Models	―	On-Demand
Grok Bot	Grok Bot週間枠	プロモ等があればそれ	On-Demand
Grok Botから起動したCursor Cloud Agent	通常のCursor側利用枠	状況に応じ次のCursor枠	On-Demand

ただし、実際にどのモデルへルーティングされたかによってCursor ModelsまたはOther Modelsを使用するため、単純に一方だけとは言えない場合もある。(Cursor)

Grok Botを使ってもCursorの月間枠は減らないのか

通常のGrok Bot処理については、基本的には減らない。Cursorスタッフの2026年9月の説明では、Grok Bot自身が行う、

通常チャット、Routine、Automation、Browser / Computer Use、Bot側マシンでのShell実行、サブエージェント、MCP呼び出しなどはGrok Bot週間枠から消費される。(Cursor – Community Forum)

CodexやCursorの通常利用枠をニュース収集などで消費する代わりに、Grok Botの別枠へ処理を移すことができる。

ただし例外がある。Grok BotがCursor Cloud Agentへ仕事を引き渡した場合である。

Cloud Agentとして実行された部分はGrok Bot週間枠ではなく、通常のCursor側の利用量として計算される。(Cursor – Community Forum)

Grok Botの「30％」は何を意味しているのか

Grok Botを使い始めた直後、使用量表示を確認すると、

構築時：約17％
Routineを1回実行後：約23％
その後いくつか質問：約30％

という変化があった。

最初は、「30％ということは、トークン数の30％を使ったのだろうか」と思った。

しかし、そうではなかった。

Cursorスタッフの説明では、Grok Botの週間パーセンテージはコストベースで計算される。モデル呼び出しの入力、出力、キャッシュなどを各モデルの料金に換算し、週間利用枠に対する割合として表示される。(Cursor – Community Forum)

したがって、同じ1回のRoutineでも毎回6％消費するとは限らない。

会話履歴が長い、複数のモデルを使う、処理が複雑、といった条件で変化する。

前の記事では「今回の実測では1回で約6ポイント増加」としたが、これは一般的な固定値ではなく、その時点の処理内容での実測である。

Grok Botが100％になったらどうなるのか

これも気になっていた。

結論はOn-Demandの設定によって違う。Grok Botは、まず週間利用枠を使用する。

それを使い切ると、On-Demandが有効なら追加利用へ移行する。Grok BotのOn-DemandはCursor経由で請求され、Cursor側の月間支出上限と連動する。(Cursor)

一方、On-DemandをOFFにしていれば、週間枠が100％になった時点でGrok Botが止まる。

次の週間リセットまで待つ必要があるが、Cursorアプリ側の通常利用まで止まるわけではない。(Cursor – Community Forum)

この設定なら、

Included Usage
      ↓
100％到達
      ↓
処理停止
      ↓
枠のリセットを待つ

となり、勝手に従量課金へ入ることはない。

今回、一番大きかったのは、「どのAIが一番賢いか」だけではAIを選べないと分かったことである。

例えばニュース収集を毎日行うだけなら、それを毎回高価なモデルやCodexへ依頼する必要はない。

Grok Botには別の週間枠がある。

Cursor GrokにはCursor Models枠がある。

ClaudeやGPTにはOther Models枠がある。

そして私は別途ChatGPTやClaude Codeのサブスクリプションも利用している。

つまり、処理内容だけでなく、「どの利用枠に余裕があるか」も考えながら処理を振り分けるという運用が必要になり、情報収集、コーディング、ローカルファイル処理、監視、Automationなどを、それぞれ利用枠も含めて適切なAIへ振り分けるという考え方が必要になるということである。

1回の「Routine」で6％の消費なので1週間あたり42％の消費であるが、Botに質問を行ったり、配信する記事数が増えると、他の用途のBotを増やす余裕があるかという話になってくる。現在契約しているサブスク（Cursor pro）では、構築したシステムと同じ規模のオートメーションをもう1組構築することは難しいので、あと数体Botを設けるというのが現実的なところだと思われ、それ以上の規模のAIシステムを構築しようとすると、より上位の契約が必要であることが分かった。