GrokBotの11の活用法：エージェント業務システムを構築する
Agent Nativeの原文の11項目に沿って、状況監視、開発委任、汎用エントリーポイント、エージェント協調、プロジェクトBot、X、Slack、プラグイン、複数メールボックス、Notion、問いかけ式日記を解説します。
- 原文の11のテクニックは、それぞれ独立して使える11のワークフローに対応しています。本文では01〜11の順に解説し、冒頭で全体像を示します。
- 監視型・トリガー型Botの共通ルールは、対象を短く、判定条件を明確にし、変化がないときは沈黙することです。専用Botでは出力・根拠・承認範囲を明確に記述します。
- 外部連携では、まず正しい身元と読み取り専用の結果を確認してから書き込みを許可します。送信・キャンセル・マージ・デプロイ・公開は承認待ちとし、Notionへの書き込み後は必ず読み返します。
Agent Native の作者は、GrokBot を SpaceXAI の汎用エージェントプラットフォームと呼んでいます。このプラットフォームを使うと、複数のBotを作成し、それぞれに独立した役割、コンテキスト、プラグイン、実行ルーチンを割り当てて、それらを連携させることができます。作者とチームは長期間使用した後、最も有用なワークフローを11個にまとめました。
この11項目は、最初から最後まで順番に従うセットアップ手順ではありません。それぞれが、監視、開発の委任、汎用エントリーポイント、エージェント間の連携、プロジェクト管理、Xのリサーチ、Slackトリガー、プラグイン権限、複数メールボックス、Notionへの書き戻し、深い思考に対応しています。元の順序で見ていくと、どのワークフローが自分のシステムに価値をもたらすかを、一つずつ判断できます。
- 「状況監視」Botを作成する：プロジェクト、取引、期限、または決定に実質的な変化があった時のみ通知します。
- 開発BotにCursorを使用させる：長時間かかる開発タスクをコーディング環境に任せ、レビュー可能な成果物を持ち帰らせます。
- 汎用Botを一つ保持する：まだ所属先が決まっていないアイデア、質問、タスクのための共通の入り口を用意します。
- Bot同士で通信させる：完了項目、決定、障害、次のステップを集約し、手動でのコンテキスト転記を減らします。
- 重要なプロジェクト用に専用Botを作成する：プロジェクトの目標、担当者、ファイル、決定、未完了事項を保存します。
- BotをXに接続する：投稿、ブックマーク、インタラクションデータを、リサーチとコンテンツのアイデアに整理します。
- イベント駆動型ルーチンでSlackを監視する：指定されたメッセージが表示された時のみ起動し、影響の大きいアクションは承認待ちにします。
- 本当に役立つプラグインのみをインストールする：実際のワークフローにコンテキストとアクション機能を追加し、権限を制御します。
- 複数のメールボックスを接続する：複数のアカウントにわたって情報を検索し、送信元の名義とキャンセル権限を混同しないようにします。
- GrokBot を Notion に接続する：リサーチを既存のページに書き戻し、配置とフォーマットを読み戻して確認します。
- 「問いを重ねる日記」Botを作成する：継続的な質問を通して、曖昧な考えを判断と行動に変えます。
01｜「状況監視」Botを作成する
作者はこれを最も役立つBotだと言っています。定期的なレポートを生成するのではなく、進展待ちのプロジェクト、取引、締め切り、決定などを並べた短い「アクティブな状況」リストを維持します。各項目は一行です。BotはSlack、メール、カレンダーに接続し、平日の業務時間中は五分ごとにチェックします。実質的な変化がない場合は、沈黙を守ります。
変化を検知すると、リマインダーは常に四つのことを伝えます。どの状況が変わったのか、何が起こったのか、なぜ注目に値するのか、次にユーザーが取るべきアクションは何か、です。リマインダーの最後には完全なリストが添付されます。リストは監視Bot内で管理する必要はなく、ユーザーは任意の会話で現在のBotに項目の追加や削除を依頼できます。
「五分ごと」は作者が採用した頻度であり、すべての人にとってのデフォルト値ではありません。このワークフローがノイズを抑えて機能するかどうかは、監視対象が十分に少ないか、「実質的な変化」の定義が明確か、そして変化がなかった場合に本当にメッセージを送らないか、にかかっています。
三つの起動方法、共通の低ノイズルール
平日5分ごと
短いリスト：プロジェクト、取引、期限、決定
実質的な変化がなければ沈黙指定したSlackチャンネルまたはメッセージ条件
取引、請求書、ブロック、リクエスト
条件に一致しなければ無視重要な返信を定期的にチェック
結果が届いたら通知
解決したらルーチンを削除条件一致時：何が起きたか・なぜ重要か・関連資料・次のステップ
送信、更新、公開は引き続き承認を待つ
作者のオリジナル画像：平日5分ごとのチェックとアクティブな状況リスト。
02｜開発BotにCursorを使用させる
GrokBotは目標や組織のコンテキストを受け取るのに適しており、時間のかかる開発作業はコーディング環境に任せるのが適切です。作者の開発Botは、リポジトリ、実装すべき結果、ビジュアルの方向性、変更できない制約をCursorに渡し、新しいブランチでアプリケーションをビルド、実行、テストさせます。
「完了」の定義は「コードが生成された」だけではありません。Botはデスクトップとモバイルのスクリーンショット、プルリクエスト、そして簡潔な変更説明を持ち帰り、ユーザーがコードを確認する前に結果を見られるようにします。マージとデプロイは、引き続き手動による承認の前で停止します。これにより、ユーザーがスマートフォンからタスクを開始した場合でも、検証できない完了宣言ではなく、レビュー可能な開発の引き継ぎを受け取ることができます。
専用Botの役割を検収契約として定義する
開発Botは一例です。任意の専用Botは、まず以下のタスク契約を記入できます。ここにはコードブロックを残す必要があります。これらのフィールドは、コピーして書き換えることのできる設定であり、通常のテキストリストではないからです。
job: 这只 Bot 唯一负责什么
scope: 可以查看哪些项目、账户、频道或文件
inputs: 开始前必须拿到哪些上下文
trigger: 什么时候运行
ignore_when: 哪些情况保持沉默
output: 返回哪些固定字段或产物
evidence: 用链接、截图、测试、PR 或读回证明什么
approval: 哪些发送、写入、取消、合并或发布动作要等人批准
read_back: 写入外部系统后怎样重新读取并确认结果
役割は作業範囲を定義し、起動条件と沈黙条件はノイズを制御し、出力と根拠は検収方法を決定し、承認と読み戻しは外部アクションを制限します。これらの要素のいずれかが欠けていると、Botは「完了したように見える」かもしれませんが、結果が正しく反映されたことを証明できません。
03｜汎用Botを一つ保持する
作者は、専門分野がほとんどないBotを一つ保持し、それを一番上に固定することを推奨しています。音声メモ、簡単な質問、過去の会話の検索、戦略的な議論、そして一時的にどのBotに任せるべきか分からないタスクは、すべてこの共通の入り口に入ります。ユーザーは話し始める前に毎回、分類体系を設計する必要がありません。
同じ種類の作業が繰り返し発生するようになったり、専用ツール、長期的なコンテキスト、固定ルーチンが必要になった場合にのみ、専用Botに分割します。この基準により、名前は違っても役割が大きく重複するBotばかりが増え、結局ユーザーが質問先を毎回選ばなければならない、という負担を避けられます。
一つの入口から始まる Botの業務システム
アイデア、音声、質問、検索、未分類のタスクはまずここに入る
繰り返し作業 · 独立したコンテキスト · 専用ツール · 固定ルーチン · プロジェクト責任者
明確な役割、長期的なコンテキスト、ツール、完了条件を得る
作業資料を読み、時間またはイベントで実行する
結果、ブロック、未解決事項は入口に戻り、影響の大きいアクションは人の確認を待つ
汎用Botは能力の低い一時的な入り口ではありません。その役割は、受け取り、検索、振り分けです。専用Botは安定したプロセスを担当し、プラグインは外部のコンテキストとアクションを提供し、ルーチンは自動実行のタイミングを決定し、結果に影響を及ぼす決定は人間に戻されます。元記事の後半にある8つのヒントは、基本的にこの役割分担に具体的な要素を追加しています。
04｜Bot同士で通信させる
複数のBotが役割を分担した後、ユーザーがそれらの間でコピー＆ペーストを行う伝書係になる必要はありません。作者は汎用Botを軽量なスタッフのように扱います。参照できる専用Botに積極的に問い合わせ、過去七日間に完了した作業、下された決定、現在の障害、未解決の項目や期限、そして次にユーザーの参加が必要なアクションを収集します。
返ってくるのは、各会話の単なる連結ではなく、圧縮されたブリーフィングです。最も注目すべき三つの項目が、その理由と担当Botとともにリストアップされます。永続的な事実、最近の変化、責任の所在、注意の優先順位が、これにより一つの入り口に集約されます。
専用Botは詳細を保持し、入口が集約と優先順位付けを担当
- 完了項目
- 重要な決定
- 現在のブロック
- 未解決事項と期限
永続的な事実を保持し、最近の変化を圧縮し、会話全体を貼り付けない
- 最優先で注意すべき3項目
- 注意が必要な理由
- 次のステップを担当するBot
グループチャットは同一プロジェクトのリアルタイム調整に使う
作者のオリジナル画像：入口が複数のBotからコンテキストを収集し、集約を準備している。
複数のBotが同じプロジェクトをリアルタイムで調整する必要がある場合は、別のグループチャットを開くことができます。グループチャットはその場での議論と引き継ぎに使用され、定期的な要約は結果をユーザーに報告するために使用されます。この二つは、それぞれコラボレーションプロセスと管理の可視性という問題を解決します。
05｜重要なプロジェクト用に専用Botを作成する
すべてのタスクが新しいBotを作成する価値があるわけではありません。作者の基準は、プロジェクトが十分に長く続くか、十分に繰り返されるか、あるいはコンテキスト、担当者、ルーチンを独立して保存する必要があるほど重要かどうかです。そうでない場合は、汎用Botで処理するのが適切です。
新しいプロジェクトBotは、空白から始めるべきではありません。プロジェクトを既に理解しているBotに、一度で目標と完了の定義、主要な担当者、既存の決定、ファイルとリンク、変更不可能な制約、承認の境界、未解決のタスクと締め切りを引き継がせます。新しいBotは、明確な主な役割を一つだけ保持し、安定した定期的な作業がある場合にのみ、ルーチンを追加します。
プロジェクトが終了したら、作者はBotを削除するのではなく非表示にします。コンテキストはCommand Kで引き続き検索でき、メイン画面が終了済みのプロジェクトで混み合うこともありません。残すのはプロジェクトの記憶であり、終わったルーチンを動かし続けることではありません。
06｜BotをXに接続する
作者はXを動画企画やリサーチの手がかりとして使っています。メインアカウントと動向を把握したいブランドアカウントを接続すると、Botは形式、トピック、表示回数、反応に基づいて最近の投稿を分析し、各結果に元の投稿への直接リンクを残せます。非公開のインタラクションデータは、どのトピックが狙った読者に響くかを見る助けにもなります。これは作者自身の使い方であり、すべてのアカウントで同じ機能が使えるという保証ではありません。
ブックマークのワークフローはさらに具体的です。毎週水曜日と日曜日に、過去七日間のブックマークを確認し、指定されたトピックに関係するものだけを残します。各項目について、一文の要点、二、三文の意味、考えられる使い道、元の投稿へのリンクを出力し、似た内容をさらに調べる価値のある三つのテーマにまとめます。
リンクは、このワークフローを検証するための証拠です。元の投稿へのリンクがなければ、要約はすぐに確かめようのない二次的な判断の集まりになります。リンクがあれば、文脈、作者、元データを確認できます。
07｜イベント駆動型ルーチンでSlackを監視する
定時ルーチンは特定の時間に起動し、イベント駆動型ルーチンは特定のイベントが発生したときに起動します。Slack Watchはまず、監視する特定のチャンネルやメッセージ条件をバインドし、取引、請求書、障害、リクエストなど、何が重要かを明確に定義する必要があります。通常のチャットが条件に一致しない場合、Botは沈黙を守ります。
トリガーされると、まず何が起こったのか、なぜ注意が必要なのかを要約し、関連するリンクやドキュメントを取得し、返信や次のアクションの下書きを作成します。通知と下書きは自動化できますが、メッセージの送信、データベースの更新、コンテンツの公開、外部の状態を変更する可能性のあるプロセスへのタスクの引き渡しは、引き続き承認待ちとなります。
元記事には、実用的な区別も暗に含まれています。継続的な状態は定時チェックに、即時メッセージはイベントトリガーに、一度きりの待機は一時的なルーチンに適しています。例えば、重要なメールの返信を待つ場合、一時的に定期的にチェックし、返信が届いたらユーザーに通知し、問題が解決したらルーチンを削除します。
08｜本当に役立つプラグインのみをインストールする
プラグインにより、Botは作業が実際に行われている場所を読み取ることができ、そこでアクションを実行することも可能になります。作者は、毎日使用しているDrive、Calendar、Notion、Slack、X、Linear、ClickUpなどから始めることを推奨しています。接続する理由は、実際のワークフローをサポートするためでなければならず、「この統合が存在するから」ではありません。
接続後、まず読み取りをテストします。アカウントまたはワークスペースが正しいか、Botが期待どおりのドキュメント、レコード、ページを見つけられるかを確認します。読み取りが安定したら、下書き、更新、送信、公開を段階的に開放します。権限はタスクを完了するために必要な最小限の範囲にのみ付与し、実際の用途がなくなった接続は削除する必要があります。
外部接続：本人確認 → 読み取り → アクション
| 接続 | 読み取り対象 | 許可アクション | 制約 | 完了の証拠 |
|---|---|---|---|---|
| Cursor | コードリポジトリと制約 | ブランチ内でのビルドとテスト | マージ禁止 · デプロイ禁止 | デスクトップ／モバイル画像 + PR |
| X | 投稿 · ブックマーク · 反応 | フィルタリング、分類、要約 | 各項目に元リンクを保持 | 直近7日間の調査リスト |
| 複数メール | 個人、業務、協業アカウント | 検索、監査、下書き作成 | 送信元を固定 · 直接キャンセルしない | アカウント · 金額 · 日付 · 管理リンク |
| Notion | 正しいページと構造 | 指定場所にのみ追記 | 削除しない、並べ替えない | 書き込み後の再読み取り |
| 汎用プラグイン | アカウント、ドキュメント、記録 | 必要最小限のアクション | 読み取り後に書き込み · 最小権限 | 正しいアカウントと記録 |
権限の階段：読み取り専用で検証 → 下書きを作成してレビュー → 承認後に書き込み、読み戻して確認
作者のオリジナル画像：プラグインはコンテキストとアクションの両方をもたらす。
作者が提案するプラグイン監査には五つの項目があります。接続されているアカウントまたはワークスペース、提供されるコンテキスト、実行を許可するアクション、どのBotまたはワークフローが使用するか、不要または過度に広い権限が存在するかどうか。監査はまずリストを返し、権限を変更したり接続を切断したりしません。
09｜複数のメールボックスを接続する
複数の個人用・業務用メールボックスを一つの検索対象にまとめ、サブスクリプション、領収書、税務書類、古い添付ファイル、保存場所を忘れた会話を探せます。各アカウントには、個人、業務、共同利用、その他といった種別を明示します。メール送信を担当するBotには既定の送信アカウントも指定し、どの名義を使うかを推測させないようにします。
作者のサブスクリプション監査は、過去三ヶ月の重複請求を検索し、会社名、金額、請求サイクル、メールボックス、最終請求日、アカウント管理リンクをリストアップし、重複の可能性がある項目をまとめ、未使用と思われるサブスクリプションをフラグ付けします。これはレビュー用のリストを提供するものであり、直接サービスをキャンセルするものではありません。
重要な返信を待つ場合も、一時的なルーチンに任せることができます。指定されたメールボックスを定期的にチェックし、メールが届いたらユーザーに通知し、状況が解決したらルーチンを削除します。これにより、複数メールボックスにわたる検索の利便性を得ながら、送信、キャンセル、長期的な監視権限を混在させることを避けられます。
10｜GrokBot を Notion に接続する
Notion接続の価値は、「ページを作成できる」ということだけではありません。リサーチ、会議録、プロジェクトのステータスを、ユーザーが既に作業している知識構造に書き戻します。開始する前に、正しいワークスペース、データベース、ページ階層を確認し、どこにどのような形式で書き込むことを許可するかを明確にする必要があります。
作者のAdd Contextアプローチは抑制的です。指定されたページを読み取り、元の内容を書き換えたり、削除したり、並べ替えたりしません。ページ下部に「Additional Context」というカルアウトを追記し、詳しいリサーチを折りたたみ領域に収め、出典リンクを添えるだけです。追加資料でページ本文を埋もれさせません。
書き込み後、Botはページを再取得して読み返し、追加内容の位置と形式を確認します。APIが成功を返しても、証明できるのはリクエストが受け付けられたことだけです。読み戻して初めて、ユーザーが実際に見るページが合意どおりだと確認できます。データベース更新、会議録、プロジェクト状況でも、対象の場所、フィールド、読み戻し方法を事前に決めておきます。
11｜「問いを重ねる日記」Botを作成する
Grill Me Journal Botは、標準的な答えがないアイデアを処理するために設計されています。これはプライベートなBotで、多くの場合、スマートフォンでの音声メモや乱雑な表現から始まります。Botはまず関連するコンテキストを取得し、次に一度に一つの難しい質問だけをします。曖昧な主張、暗黙の仮定、論理の欠陥に挑戦します。作者は通常、これを七〜八ラウンド続けます。
一度に一つの難問を問い、行動可能な見解になるまで続ける
曖昧な主張、隠れた前提、論理の欠陥を問い直す
作者の例：7〜8回Botのコンピュータまたはノートシステムに書き込む
作者のオリジナル画像：問いかけが終わったら日記をワークスペースファイルに保存する。
終了時には四つの成果物を渡します。ユーザーが実際に信じていることの短い要約、最も鋭い未解決の問い、次の三つの行動、そして保存できる整理済みの日記です。成果物はBotのコンピューターまたはユーザーが選んだノートシステムに書き出され、この思考を後から検索して使い続けられるファイルにします。
七〜八ラウンドは作者のリズムの一例です。より適切な停止条件は、判断が行動に移せる状態になったかどうかです。主張が明確になり、重要な仮定が明らかになり、未解決の問題を正確に命名でき、次のステップが単なる「もっと考える」ではなくなった時です。
この11項目は、どれから始めても構いません。一週間の最小構成に絞るなら、状況監視Botを作って変化待ちの項目を二つだけ入れ、汎用Botを画面上部に固定します。今週初めて繰り返した作業から一つを選び、タスク契約を埋めます。外部システムは一つだけ接続し、まず読み取りを検証します。週末に汎用Botへ、完了項目、決定、障害、未解決事項を一度まとめさせます。各段階で確認できる成果が得られてから、新しいBot、コネクタ、ルーチンを追加します。