第 8 章 スキルとルーティン：一度の成功を毎日の自動実行に変える

いきなり定期実行を設定してはいけません。人間の監視から外れるとスタックしやすく、深夜3時に誤実行されて空回りで1週間分のクォータを使い果たすこともあります。

操作をスキル（Skill）として蓄積し、ルーティン（Routine）として組み立てます：

1. タイムゾーンを合わせ、Webhook を標準化する。
2. Slack トリガーの範囲を制限する。
3. 仮想マシンの2段階チェックを追加する。

境界を適切に設定すれば、PCを閉じてもバックグラウンドで安定して成果を出せます。

スキルの蓄積と参照：標準作業手順（SOP）を定着させる

スキルとはアカウントに保存される操作指示であり、所有するすべての Bot から直接呼び出すことができます。

スキルを蓄積する方法

方法1：対話後のテキスト要約 タスクが完了してもすぐにセッションを閉じず、現在の Bot に要約・保存させます。プロンプトには入力元、例外処理、境界制限を明確に指定し、以下のテンプレートを直接送信します。

スキルを蓄積する方法

请把我们刚刚完成的这套流程保存为名为“每日工单异常审查”的技能。
技能内容必须包含以下要素：
1. 适用场景：工作日审查支持渠道中滞留超过 4 小时的工单。
2. 输入数据：从已连接的工单插件中读取状态为 Open 且优先级为 High 的列表。
3. 决策规则：若工单包含退款申请且金额大于 500 元，标记为一级风险；其余标记为二级跟进。
4. 交付格式：生成 Markdown 表格，列出工单编号、客户标识、滞留时长、风险等级与跟进建议。
5. 异常处理：若工单系统接口无响应或无符合条件的数据，输出明确说明，严禁使用历史缓存或伪造数据。
6. 安全边界：未经人工明确批准，严禁直接调用接口回复客户或变更工单状态。

方法2：実演して教える（Teach task） 画面操作が複雑な場合は、直接実演した方が簡単です。

1. チャットウィンドウ右側のコンピュータープレビューを開き、「タスクを教える」（Teach task）を選択します。
2. 目標を簡単に説明した後、クラウドPC上で操作します。システムは最大10分間の画面録画を行い、マイク音声は録音されません。パスワードなどの機密情報は絶対に入力せず、機密認証情報はセキュリティカードを使用してください。
3. 下書きが自動生成された後、必ず意思決定ルール、エラー処理、承認の境界を補完してください。そのまま本番運用してはいけません。入り口が見当たらない場合はまだ段階的ロールアウト中ですので、方法1に切り替えてください。

スキルの参照と管理方法

• 入力欄での参照：入力欄にスラッシュ / を入力すると、スキルを選択して読み込むことができます。
• 権限の有効化：リストに見当たらない場合は、デスクトップのサイドバーにある「接続済みアプリ」（Connected Apps）で接続数をクリックし、「プライベートスキル」内のスイッチをオンにします。

どのレベルまで設定すれば合格か

チェック項目	不合格な書き方	合格な書き方
入力元	「最近のデータを分析して」	プラグイン、API エンドポイント、ファイルパス、またはデータベースビューを明示的に指定
境界制御	「問題が起きたら適当に対処して」	データ欠損時は直ちに中断してエラーを報告し、データの捏造を厳禁とする
アクション権限	「レポートを顧客に送信して」	下書きを生成してチャットにとどめ、人間の許可を待ってから送信する
出力構造	自由記述の長文テキスト	固定フィールドリスト、Markdown テーブル、またはディスクへの保存パス

出典：『Grok Bot の使用』

ルーティンのコアメカニズム：設定、確認、テスト

ルーティンは Bot に紐づくワークフロートリガーであり、クラウド Linux の /workspace ディレクトリで実行されます。PCを閉じたりクライアントを終了したりしても、クラウド上のタスクはスケジュール通りに進められます。

仕様と制限

• 各 Bot で作成できるルーティンは最大50個で、システムは直近20回分の実行ログを保持します。
• スケジュールルーティンの最短トリガー間隔は5分で、秒単位のスケジューリングには対応していません。
• ルーティンの削除は元に戻せません。以降の実行は完全に停止します。Bot を削除すると、関連するすべてのルーティンも一括で削除されます。

出典：『4.3 トリガーと自動化：定期実行、Webhook、Xでのタスク割り当て』。

ルーティンの作成と管理

デスクトップ版ではチャット欄に指示を送信して直接作成します：

每个工作日上午 8:30，调用“每日工单异常审查”技能，在此对话中输出审查清单。如果未检索到高风险工单，只发一行“今日无高风险工单”即可，不要刷屏。

デスクトップ版での管理：

1. チャットウィンドウ上部の Bot 名をクリックして Details に入り、ルーティン（Routines）リストで実行時刻や Paused を確認できます。右側のスイッチでいつでも一時停止（Pause）または再開（Resume）が可能です。
2. 個別のルーティンをクリックすると、3つの属性を確認できます：Instruction（実行プロンプト）、When to run（スケジュール説明）、Webhook（専用 URL、秘密鍵、リクエストヘッダー）。
3. 下部ツールバーには Test、Edit、赤いゴミ箱アイコン（Delete routine）が用意されています。Edit をクリックするとチャット欄に "Edit your routine: [例程名]" が自動入力されるので、変更内容を追記して送信すれば更新できます。

モバイル版での管理：

1. Bot のプロフィールページを開いてルーティンを見つけ、Add routine をタップすると "Set up a routine to " が事前入力されるので、指示を入力して送信すれば作成できます。
2. 既存のルーティンをタップすると Schedule、Next run、Instruction を確認でき、Active スイッチや実行履歴（Run history）も確認できます。
3. Active スイッチをオフにすると一時停止でき、行を左にスワイプすると直接削除できます。 ステータスはデスクトップ版と双方向でリアルタイム同期されます。

出典：『ルーティン』。

スケジュール設定とタイムゾーン構成

タイムゾーンの確認手順：Settings -> Bot -> Timezone。

モード	動作メカニズム	注意事項
Auto-detect	現在のPCのタイムゾーンに自動追従	固定した場所での利用向き。海外出張時などに実行時刻がズレやすい
手動指定タイムゾーン	ドロップダウンから対応するタイムゾーンを手動選択	特定の地域（北京時間 UTC+8 や米国東部時間 EST など）を対象とする場合は手動指定を推奨

• 定期ルーティンを新規作成しても即座には初回実行されず、次の予定時刻を待つ必要があります。例えば午前 8:05 に「毎日 8:00 実行」と設定した場合、初回実行は翌朝の 8:00 になります。
• 週末も継続して巡回・監視が必要な場合は、指示の中で「週末を含め毎日実行」と明示的に強調する必要があります。 特段の指定がない場合、Bot はデフォルトで月曜日〜金曜日のみ実行します。

出典：『ルーティン』、『4.3 トリガーと自動化：定期実行、Webhook、Xでのタスク割り当て』。

ルーティンのテスト

デスクトップ版の詳細画面の下部にある Test ボタンをクリックすると手動でトリガーでき、ボタンの表示が Running… に変わり、実行結果のフィードバックが直接チャットウィンドウに出力されます。

テスト実行は実際のアクションを伴います。クラウドPCのブラウザが起動し、ワークスペースのファイルが書き換えられ、通常通りクォータが消費されます。削除や変更を伴う場合は、事前にサンドボックスデータでテストしてください。Couldn't start a test run と表示された場合は、クラウドPCの接続状態や、前のタスクがブロックしていないか確認してください。

出典：『ルーティン』。

Webhook と Slack トリガー：ポーリングからパッシブ起動へ

外部 Web ページの定期ポーリングはクォータを著しく消費し、高頻度の空回りは1週間分の計算リソースをあっという間に使い果たします。イベント駆動型に切り替えて Bot を起動させ、普段は完全に休止させておき、外部に変更があった時のみ受動的にトリガーするようにします。

2026-10-12 より、Grok Bot は The X Subscription 体系に組み込まれ、Grok や Cursor とクォータプールを共有します：

サブスクリプションプラン	料金	利用可能倍率	Bot サポート状況
Premium	月額 $30 または年額 $300	基本利用枠の4倍	Bot を含む
Super	月額 $100 または年額 $1000	15倍の利用枠	Bot を含む
Ultra	月額 $200 または年額 $2000	50倍の利用枠	Bot を含む
Plus	-	-	Bot は含まれない

Webhook の設定と非同期検証

チャットウィンドウで指示を送信することで、Bot に Webhook トリガーを作成させることができます。

为当前 Bot 创建一个 Webhook 触发的例程，命名为“外部知识接收端”。
指令内容：读取请求体中的 JSON 数据，提取 url 和 note 字段，将其抓取整理为 Markdown 存入 /workspace/notes 目录。

デスクトップ版でルーティンの詳細を開き、Webhook を展開して主要フィールドを確認します：

1. POST to：外部リクエストを受信する一意のパブリック URL。
2. key：認証用の秘密鍵。呼び出し時にはリクエストヘッダーに Authorization: Bearer <key> を含める必要があります。
3. header：整形済みの完全なリクエストヘッダーテキスト。クリックで直接コピーできます。

設定は「Save」をクリックして保存して初めてゲートウェイに反映され、秘密鍵が生成されます。 詳細ページがフリーズして開けない場合は、Bot にダイレクトリンクを送信させてください。

『4.3 トリガーと自動化：定期実行、Webhook、Xでのタスク割り当て』

外部システムは POST リクエストを通じてデータをプッシュし、JSON リクエストボディを直接添付します。

{
  "url": "https://example.com/article/1024",
  "source": "ios_share",
  "note": "精读核心论点并归档"
}

Bot は JSON をコンテキスト変数として扱い、事前に設定された Instruction とともにモデルに渡します。『ルーティン』

• HTTP 200 はゲートウェイがリクエストを正常に受信して実行を開始したことのみを示し、タスクの実行成功を意味するものではありません。 処理の成否はチャットウィンドウまたはワークスペースに出力されたファイルで確認する必要があります。
• 200 以外が返された場合はタスクが生成されていないことを意味し、通常はルーティンが一時停止（Paused）状態にあるか、秘密鍵が無効になっていることが原因です。『ルーティン』

Slack トリガーとクォータ超過防止

Slack プラグインは対話に伴ってリアルタイムに呼び出される読み書きツールです。一方、Slack トリガーはルーティンの起動条件であり、使用前に Cursor アカウント連携で認証を完了しておく必要があります。

自然言語で指示を送信するだけで、リスナーを設定できます。

创建一个 Slack 触发例程：当 #incident-response 频道中有人发消息提及 @bot 且包含短语 "needs repro" 时，在云电脑上拉取报错日志并尝试复现。不要监听其他频道，也不要在没有该短语时响应。

リスナータイプは4種類をサポートしています：Bot へのメンション、特定フレーズの一致、リアクション絵文字の追加、または任意のメッセージの受信。

• パブリックチャンネルで「任意のメッセージを受信」を設定することは厳禁です。雑談や勤怠連絡などですべてマッチしてしまい、1週間分のクォータが1日で燃え尽きてしまいます。
• 必ず単一の専用チャンネルに紐づけ、「ワークスペース全体」を選択してはいけません。
• フィルタリング条件はできるだけ厳しく絞り込んでください（特定のプレフィックスやチケットリンクへの限定など）。
• トリガーは作成後の新しいメッセージにのみ有効で、過去のメッセージには遡及しません。『ルーティン』

自動化実践事例：3つの典型的なパイプライン

事例 1：スマートフォンからワンタップでナレッジベースに保存（iOS ショートカット + Webhook）

コミュニティ作者の铁柱（@cgnot996）は、アーカイブフローを構築しました。スマートフォンで技術記事や動画を見ているときにシステムの「共有」をタップすると、Grok Bot が全文を自動取得して要点をまとめ、Markdown 形式に整理して /workspace/knowledge/inbox.md に書き込みます。

次の手順で設定します。

1. クラウド側ルーティンの新規作成：Grok Bot 側で「スマートフォンナレッジ保存」ルーティンを新規作成し、トリガー条件に Webhook を選択して、専用の POST URL と Authorization ヘッダーを取得します。
2. 処理指示（Instruction）の記述：渡された URL を受け取り、クラウドPCのブラウザで開くように指示を設定します。動画の場合はスクリプト/文字起こしを抽出し、解析後にフォーマットに従ってタイトルとタグを抽出し、要点と関連リンクをまとめて /workspace/knowledge/inbox.md に追記します。
3. スマートフォン側ショートカットの作成：iPhone で「ショートカット」アプリを開いて新規作成し、「共有シートに表示」を有効にして、受け取る入力タイプとして「Web ページとテキスト」にチェックを入れます。
4. リクエストアクションの追加：「URL の内容を取得」アクションを追加し、方法を POST に設定、URL に Webhook の送信先アドレスを入力します。ヘッダーに Authorization を追加して値を Bearer [你的私钥] とし、リクエスト本文を JSON にして url を「ショートカットの入力」に紐づけます。
5. 共有制限の回避：一部のアプリ（WeChat 公式アカウント記事など）ではショートカットを含む共有パネルを直接呼び出せません。別途「入力欄中継」ショートカットを作成してアクションボタン（Action Button）に割り当て、ポップアップを開いてリンクを貼り付け、Webhook に転送するようにします。

スマートフォン側では軽量なパラメータ取得と HTTP 送信のみを行い、負荷の高いコンテンツスクレイピングやレイアウト整形はすべてクラウド上で非同期に処理します。 これによりスマートフォンのバッテリーを消費せず、待つ必要もなく、数秒で画面を閉じることができます。

出典：『Grok Bot Webhook + ショートカット：ナレッジ自動保存パイプラインの構築』、『4.3 トリガーと自動化：定期実行、Webhook、Xでのタスク割り当て』。

事例 2：仮想マシンの2段階チェックとクォータの極限最適化

コミュニティ作者の铁柱（@cgnot996）は、「マーケティングディレクター」Bot の6つの定期タスクを最適化しました。xAI の返信監視と毎日の PR レビューという、変更をひたすら待つだけの2つの巡回タスクを軽量な比較処理に変更し、実質的な進展があったときのみモデルを呼び起こすようにすることで、毎週8〜10回の無駄な空回りを削減しました。

タスクは2つのタイプに分かれます。

タスクタイプ	代表例	スケジュール戦略と実行特性
時間通りに成果物を提出する必要があるもの	SEO 日報、ウェイト月報	定刻に完全なレポートを生成して閲覧に供するため、ネイティブの定期スケジュールを維持
定刻に単に変更を待つだけのもの	ページ更新監視、新規 PR チェック	定期実行の空回りはクォータを消費するため、軽量な検知処理に変更が必要

導入は以下の4ステップで進めます。

1. ローカル監視役の配置：Grok Bot が動作している Linux 仮想マシンのローカルに、Python または Bash で極めてシンプルなスクリプトを作成します。大規模モデルは一切呼び出しません。
2. 定期比較の設定：Linux 標準の cron スケジューラを使用してスクリプトを実行し、平日の30分ごとにチェックします。スクリプトは Web ページのハッシュ値を比較するか、GitHub API を叩いて PR 数を確認するだけで、所要時間は数秒であり、Grok のサブスクリプションクォータを消費しません。
3. 差分検知による起動：比較により実質的な変更が検出された場合にのみ、スクリプトが curl を実行して Webhook 宛てに POST 呼び出しを行います。
4. モデルの介入と処理：Bot が起動した後、PR コードや返信内容を読み込み、意思決定の提案を整理して通知をプッシュします。

機械的な判定はローカルスクリプトに任せ、思考が必要な場面でのみ大規模言語モデルを起こします。これにより、「本日は特に異常なし」という一言のためだけに大規模言語モデルのコンテキストを無駄に消費することがなくなります。

出典：『Grok Bot クォータをさらに節約：定期タスクの極限最適化』。

事例 3：日次の顧客解約リスク監視

公式チームと、29個の Bot を運用する作者 melvindvivas は、この方式を採用して顧客の変動を監視しています。毎朝、利用量やサポートチケットの指標を自動取得し、アラート監視リストを生成して、全工程を厳格に制御下に置いています。

導入は以下の4ステップで進めます。

1. 職務規定（契約）の確立：専用の Account Risk Bot を作成し、ルールの契約を対話内で送信して記憶させ（共有 Bot の場合は詳細の About に記述）、リスクのしきい値を設定します。例えば API 呼び出し量が3日連続で40%以上減少し、かつ未解決の P1 チケットが存在する場合などです。
2. 定期取得タスクの設定：平日の毎朝 8:00 に実行されるルーティンを設定し、ソースシステムから定期的にメトリクスを取得します。
3. 障害サーキットブレーカーの設定：データウェアハウスの接続タイムアウトやデータの準備ができていない場合は、直接データの欠損と失敗理由を報告させ、前日のスナップショットからの推測や、未確認データの出力は厳禁とします。
4. 安全承認ゲートの設定：Settings の Custom Rules で、メール送信、CRM フィールドの変更、リストの配布をすべて「確認する」（Ask first）に設定します。Bot がまとめたリストはチャットウィンドウ内に静かに表示されるにとどまり、アカウントマネージャーが確認した上で手動で承認カードをクリックするのを待ちます。

高付加価値な自動化では、モデルに権限を委譲するだけでなく、実行能力を与えるとともに境界契約と人間のチェックゲートを必ず設けなければなりません。

出典：『Grok Bot の使用』、『4.3 トリガーと自動化：定期実行、Webhook、Xでのタスク割り当て』。

ルーティンのトラブルシューティングガイド

予定時間になったが、Bot がまったく反応しない

• デスクトップ版の Details で Paused になっていないか確認し、モバイル版で Active がオンになっていることを確認します。長期間ログインせず、Bot への確認応答がタイムアウトした場合、タスクは自動的に一時停止されます。
• When to run のタイムゾーンと週末の設定を再確認してください。新規作成したスケジュールは次の自然な周期まで待機するため、まずは Test をクリックして導通テストを行ってください。
• モバイル版で「実行履歴」を確認し、No runs yet と表示されている場合はシグナルがゲートウェイに到達していません。Failed と表示されている場合はタップして詳細なエラー内容を確認できます。

出典：『ルーティン』

外部 Webhook からプッシュしたのに、ルーティンが起動しない

• API を呼び出した際は、まずレスポンスコードを確認してください。200 以外の場合はリクエストがゲートウェイで遮断されています。
• リクエストヘッダー Authorization の Bearer 秘密鍵を確認してください。再生成すると古い秘密鍵は即座に無効化されます。
• 新しいトリガーを作成した後は、必ず右下の Save をクリックしてください。エンドポイントと秘密鍵は保存されて初めてゲートウェイで有効になります。

出典：『ルーティン』

Slack トリガーが反応しない

• トリガーは作成・有効化後の新規メッセージにのみ反応します。過去のメッセージを編集してもトリガーされません。
• 投稿先チャンネルが間違っていないか確認してください。アカウントが対象チャンネルの閲覧権限を持っている必要があり、キーワードは完全一致している必要があります。

出典：『ルーティン』

タスクが途中で突然フリーズして中断した

• バックグラウンドで無人実行される承認カードの待機時間は約10分のみです。タイムアウトして Expired になると処理が中断・失敗します。
• 通知を有効にするか、Settings > Bot > Auto-review モードの「カスタムルール」で信頼できるアクションの自動実行を許可してください。
• エラーが発生した場合は、フキダシを右クリックして Copy request ID を選択し、エラーテキストと一緒に公式サポートに問い合わせてログを調査してもらってください。

出典：『Grok Bot 操作ガイド』

クラウドPCのアップデート後、ローカルスクリプトとスケジューラが消えた

アップデートタイプ	環境の保持状況
ソフトウェアアップデート	クラウドPCの環境およびファイルには影響しません
コンピューターの更新（「設定」>「コンピューター」>「Bot のコンピューターを更新」）	イメージを再構築します。/workspace とブラウザのログイン状態は保持されますが、apt のグローバルパッケージ（cron など）はクリアされます

出典：『Grok Bot 操作ガイド』、『Grok Bot クォータをさらに節約：定期タスクの極限最適化』

よくある落とし穴

1. Test をクリックすると実際に実行される：ツールが呼び出されてファイルが削除される可能性があるため、テスト前にプロンプトに承認ブレークポイントを設けておきましょう。『ルーティン』。

2. ポーリングとスケジュールの仕組み：5分ごとのポーリングは1週間分のクォータを使い果たします。軽量スクリプトで比較し、変更があったときだけモデルを起こすようにしましょう。「毎日9時」はデフォルトで平日実行となるため、「週末を含む」と明記し、Settings でタイムゾーンを固定してください。

   『4.3 トリガーと自動化：定期実行、Webhook、Xでのタスク割り当て』。

3. チャット欄に Webhook の秘密鍵を貼り付けないこと：クラウドの履歴に記録されてしまいます。認証情報は安全な機密情報リクエストカードで入力する必要があり、誤って貼り付けた場合は直ちに削除してください。

   『Grok Bot クォータをさらに節約：定期タスクの極限最適化』。

4. 承認インターセプトによるサイレント失敗の防止：インターセプトを設定する場合はモバイル通知をオンにしておく必要があります。承認カードが表示されてから10分間応答がないとタイムアウトして無効になります。『Grok Bot 操作ガイド』。

5. Bot の共有環境：/workspace/temp のファイルを削除すると他の Bot に影響します。ファイルを書き込む際はプロジェクトごとに独立したサブディレクトリを指定してください。

   『Grok Bot の使用』。

完了後の検証方法

以下の4つのステップを順に確認し、すべてクリアして初めて無人運用に移行できます：

1. 時刻の照合：詳細画面で Next run のタイムスタンプとローカルタイムゾーンが完全に一致していることを確認します。
2. データ欠損テスト：ネットワークを切断するか空ファイルを渡して Test をクリックし、ルーティンがエラーで停止することを確認します。内容を捏造してはいけません。
3. 承認インターセプトのテスト：削除や外部送信の指示をあえて送信し、カードが表示されずに直接実行された場合は脆弱性があるため、Settings で補完する必要があります。
4. ログとファイル出力の確認：通常通り1回実行し、/workspace にドキュメントが書き込まれていること、およびチャットウィンドウが連投で埋め尽くされていないことを確認します。

出典：『4.3 トリガーと自動化：定期実行、Webhook、Xでのタスク割り当て』。

発展学習

関連章

• 第 20 章 可靠的自动化：定时、Webhook 与事件触发

公式ドキュメント

• 『Grok Bot の使用』
• 『ルーティン』
• 『Grok Bot 操作ガイド』

コミュニティの実践

• 『4.3 トリガーと自動化：定期実行、Webhook、Xでのタスク割り当て』
• 『Grok Bot クォータをさらに節約：定期タスクの極限最適化』
• 『Grok Bot Webhook + ショートカット：ナレッジ自動保存パイプラインの構築』