第20章信頼性の高い自動化：スケジュール、Webhook、イベントトリガー

Routine が1日に何十回も起動しては「本日は変更なし」とだけ返し、クォータはそのまま引かれていく。タスクに明確な仕様・規約がないと、サイレントエラーが極めて発生しやすくなります。

タイムゾーンのズレ（朝9時の実行予定が深夜3時に動く）
周期の誤認（デフォルトが平日のため週末がスキップされる）
フォールバックの欠如（エラー発生時に空データをもとに本番環境を誤編集する）

Linux の cron を組み合わせた2段階アーキテクチャにより、80%以上の空振りを削減できます。境界コントラクトとヒューマンインザループ（安全弁）を組み込み、ショートカットや X のイベントストリームと連携させてこそ、自動化は安定しコストを抑えられます。

信頼性の高い自動化：スケジュール、Webhook、イベントトリガー

トリガーの選定：定刻実行か、変化待ちか

まずは定刻に結果を出すのか、それとも新しいデータを待つのかを切り分けましょう。Bot は Grok や Cursor と週間クォータプールを共有しているため、高頻度なポーリングを行うと数日でクォータを使い果たしてしまいます。

サブスクリプションとクォータ制限

The X Subscription（2026-10-12時点）では Plus に Bot は含まれず、サポート対象プランは Premium（月額$30／年額$300、4倍）、Super（月額$100／年額$1000、15倍）、Ultra（月額$200／年額$2000、50倍）です。

1つの Bot につき Routine は最大50個、実行履歴は20回まで保持され、スケジュールの最小間隔は5分です。

トリガー方式と選定

スケジュール型 Routine：データの有無にかかわらず定刻に実行され課金対象となるため、定例の日報などに適しています。
Webhook：通常時は消費ゼロ、Bearer キーを付与した POST リクエスト限定です。
サードパーティイベント（GitHub、Slack など）：イベント発生時のみ起動しますが、トラフィックの多いチャンネルではクォータを急速に消費しやすいです。
X でのインタラクション（@bot への返信）：動画ポストは解析不可、また @grok と @bot の両方を同時にメンションした場合はトリガーされません。

新しいデータが来てから処理する場合は、一律 Webhook またはサードパーティイベントに切り替えてください。

Routine 設計テンプレート：肩書きではなく契約書を書く

プロンプトに肩書きだけを書くと破綻しやすいため、本番用の Routine には実行契約（Contract）を明記する必要があります。

出典：『4.3 トリガーと自動化：スケジュール、Webhook、X 上でのタスク割り当て』。データソース、出力フォーマット、欠損エラー時の対応、手動承認ポリシーを網羅した4要素を揃える必要があります。

契約書の作成と Routine の設定

入出力を制約する契約書を Bot に送信して記憶させます。共有 Bot の場合は「About」詳細の「Description」に記述します。

text

负责范围：监控指定数据源并生成标准化 Markdown 摘要。
允许读取的数据源：工作区目录下的 data/incoming/ 文件夹及指定公开 RSS 链接。
输出格式规范：必须输出包含“标题、核心要点（最多3条）、影响评估、原始链接”的 Markdown 结构，存入 docs/daily/ 目录。
数据异常策略：若数据源无更新或文件为空，仅在工作区追加一行日志“[时间戳] NO_NEW_DATA”，严禁编造或推测新闻内容，严禁在聊天窗口发送刷屏提示。
权限边界：只读外部内容与本地写入。禁止调用外部发帖、转账、发送邮件或删除文件操作。

チャット内でワークフローを自己検証ロジック付きの Skill として保存し、指示を直接送信してスケジュール型 Routine を作成します。

text

每个工作日上午 8:30，运行“晨间资讯归档”Skill。如果数据源没有更新，记录日志后保持沉默。

Details の「Routine」一覧で、スイッチを切り替えて Pause または Resume します。
パネルを開くと Instruction、When to run、Webhook を編集でき、下部で Pause/Resume、Test、Edit、および Delete routine（ゴミ箱アイコン）の操作が可能です。

本番稼働前のドライラン（事前検証）テスト

Routine はクラウド上の仮想マシンで実際の操作を実行しますが、すべての Bot はデフォルトで基盤となる実行環境を共有しており、サンドボックスによる隔離がありません。暴走すると実際のファイルが変更されてしまいます。有効化する前に、チャットで指示を出してドライラン検証を行ってください。

text

针对即将上线的例程“晨间资讯归档”，进行一次干跑验证：
1. 复述你理解的执行触发条件与完整业务流程。
2. 列出本次执行涉及读写操作的路径，以及可能产生风险的 3 个最高风险步骤。
3. 说明如果源文件损坏或格式错误，你的具体兜底动作。
现在不要执行任何实际写文件和网络请求操作，仅输出分析报告。

ヒューマンインザループ（安全弁）を確実にロックする

Settings の Custom Rules（または Auto-review）へ移動し、不可逆なアクションは強制的に手動承認に設定します。

遮断対象コマンド	アクション範囲
`send` / `post`	メッセージ、メール、SNS の外部送信
`buy` / `transfer`	決済および送金 API
`delete` / `permissions`	ファイルやデータベースの削除、権限変更

コマンドがトリガーされると、システムは承認カードをポップアップ表示して実行を一時停止し、人間の確認を待ち続けます。自動的に外部送信されることは決してありません。

Webhook 連携：モバイル端末と外部パイプラインの接続

出典：『Grok Bot Webhook + ショートカット：ナレッジ自動格納パイプラインの構築』

認証情報とステータス

Routine で「Webhook がトリガーされたとき」を選択した場合、Save をクリックしないとアドレス、シークレットキー、Header は生成されません。v0.68.1 でカード上に URL の全体が表示されない場合は、Bot にチャットへリンクを送信させてコピーしてください。シークレットキーを公開グループに送信してはいけません。

200 が返ってきたとしても、クラウド側で起動したことを示すだけであり、実行完了を意味するわけではありません。結果はチャット画面で確認してください。200 以外の場合は、Routine が Paused になっていないか、キーが正しいかを確認してください。

ショートカット

共有シートがある場合（ブラウザなど）：

「共有シートに表示」にチェックを入れ、リンクとテキストを受け取ります。
「URLの内容を取得」で POST リクエストを送信します。リクエストヘッダーに Authorization: Bearer <key> を指定し、JSON 本文に content を追加してショートカットの入力を設定します。

text

接收端 Bot 的配套 Instruction 模板：
收到 Webhook 传入的 JSON 数据后，提取 content 字段中的链接。
如果是普通网页，抓取正文，提炼核心结论与知识点。
整理完成后，以 Markdown 格式追加写入知识库目录下的 inbox.md，包含收录时间、原文链接、核心观点与分类标签。
处理完毕后在聊天中输出一句话确认回执。

共有シートがない場合（WeChat など）：

「テキストを要求」の後に「ショートカットを実行」を繋げて転送します。
iPhone 15 Pro のアクションボタンやホーム画面に割り当て、コピー後にポップアップから送信します。

大容量ファイルをリクエスト本文に直接含めることはできません。音声、動画、画像はあらかじめクラウドストレージにアップロードして公開 URL を取得してから Bot に送信してください。

差分判定による空振りの防止：2段階チェックアーキテクチャ

定期巡回（ポーリング）のたびに大規模言語モデルを実行していてはクォータの浪費になります。処理を2段階に分割しましょう。

Linux 標準の cron を使って機械的な巡回チェックを行う。
データに変更があった場合のみ、Webhook を呼び出して Bot を起動し処理させる。

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

1. デカップリングの原理：目覚まし時計と頭脳の役割分担

Grok Bot の背後では、常時稼働の Linux クラウド PC が動いています。

機械的チェック：cron でスクリプトを実行してデータを比較します。この間は絶対に大規模言語モデルを呼び出さないでください。数秒で終了し、利用枠を消費しません。
差分時のみ起動：変更があった場合のみ、ローカルの Webhook へ POST を送信して Bot を起動し、分析・要約を行わせます。

6つの Routine のうち変化待ちのものを改修するのに約23分かかりましたが、週間で8〜10回の空振りが削減され、遅延も1日から30分以内に短縮されました。

2. 仮想マシンでの導入・設定手順

Bot に「差分処理センター」Routine を追加し、トリガーとして Webhook を選択して、Webhook URL と Bearer キーを確実に保存します。
ターミナルを開き、ワークスペースにスクリプト check_update.sh を作成します：

2. 仮想マシンでの導入・設定手順

bash

   #!/bin/bash
   # 监测目标 API 或页面是否有增量变化，纯机械对比，严禁调用 LLM

   TARGET_URL="https://api.example.com/v1/feed"
   STATE_FILE="/home/user/workspace/last_state.hash"
   WEBHOOK_URL="https://your-bot-webhook-url.com/api/v1/run"
   WEBHOOK_KEY="Bearer YOUR_SECRET_KEY"

   # 获取最新数据的哈希值或时间戳
   CURRENT_HASH=$(curl -s "$TARGET_URL" | md5sum | awk '{print $1}')

   if [ ! -f "$STATE_FILE" ]; then
       echo "$CURRENT_HASH" > "$STATE_FILE"
       exit 0
   fi

   OLD_HASH=$(cat "$STATE_FILE")

   # 比对是否有变化
   if [ "$CURRENT_HASH" != "$OLD_HASH" ]; then
       echo "检测到数据更新，正在唤醒 Bot..."
       echo "$CURRENT_HASH" > "$STATE_FILE"
       
       # 叫醒 Bot 进行智能分析
       curl -X POST "$WEBHOOK_URL" \
            -H "Authorization: $WEBHOOK_KEY" \
            -H "Content-Type: application/json" \
            -d '{"event": "data_changed", "source": "feed_monitor"}'
   else
       # 无变化，保持沉默，零额度消耗
       echo "无新变化，退出。"
   fi

ターミナルで cron サービスをインストールして起動します：

bash

   sudo apt-get update && sudo apt-get install -y cron
   sudo service cron start

crontab -e を実行してスケジュールを設定します（平日の朝9時から夜7時まで、30分ごとにチェック）：

cron

   */30 9-19 * * 1-5 /bin/bash /home/user/workspace/check_update.sh >> /home/user/workspace/cron_check.log 2>&1

クライアントで「コンピューターを更新」（Update computer）をクリックするとシステムがリセットされます：ワークスペースのスクリプトは残りますが、apt-get でインストールした cron は消去されるため、更新後は再インストールと起動を再度行う必要があります。
スクリプト内で大規模言語モデルの API を呼び出さないこと：軽量なチェックのみにとどめてください。判断をモデルに任せてしまってはコスト削減にならず、費用が API の課金へスライドするだけです。

サードパーティイベントおよび X プラットフォームとの連携

Slack トリガー

Slack トリガーは Routine 体系に含まれており、利用前にアカウントで Slack を連携する必要があります。『Routines ヘルプ』を参照してください。

公開チャンネルで「任意のメッセージを受信」をトリガーに設定することは絶対に避けてください。日常会話だけで1週間分のクォータが1日で枯渇します。
#alerts-p0 や #deploy-status などの専用通知チャンネルのみを監視するようにします。
!bot review や @bot summary などのトリガープレフィックスを必須とします。
設定以降に生成された新しいメッセージにのみ応答し、過去の履歴は遡りません。

X プラットフォーム連携の境界

v0.70.2 以降、個人アカウントを連携しなくてもポスト（ツイート）の検索が可能になりました。

ポストの下で @bot にリプライすると、スター付きメイン Bot に通知されて処理が振り分けられます。『4.3 トリガーと自動化：スケジュール、Webhook、X 上でのタスク割り当て』を参照してください。

制限事項：動画付きポストは解析できません。また、リプライに @grok と @bot の両方が含まれていると競合してトリガーされません。
インジェクション対策：メイン Bot は要約、分類、データ格納のみが許可され、自動での投稿、いいね、またはクラウド PC の変更は厳禁です。すべての外部向けアクションは、デスクトップクライアントに戻して人間による確認を行う必要があります。

失敗時のフォールバックとフォールトトレランス戦略

失败兜底与容错策略

API のタイムアウトや空データの返却時にハルシネーション（勝手な補完）が起きやすいため、Instruction には必ず例外遮断宣言を含める必要があります：

text

前置校验步骤：
1. 检查抓取到的内容体积。如果内容为空、包含 HTTP 错误码（如 403、404、500）或少于 50 个字符，判定为源不可用。
2. 源不可用时，立刻终止后续分析流程。
3. 在 workspace/logs/routine_errors.log 中追加一行错误记录，格式：[ISO时间戳] [任务名] SOURCE_UNAVAILABLE [原因]。
4. 不得在公开聊天窗口发送报警消息，不得使用过往缓存伪造新数据，直接以退出状态结束本次 run。

Webhook のトラブルシューティング：

401：Header の Authorization: Bearer <key> を確認し、余分な空白や改行が入っていないか、古い Key を使っていないかをチェックします。
404：URL が完全かどうかを照合し、デスクトップ側での誤削除や登録解除がないか確認します。
429：同時実行数の上限超過です。リトライキューと指数バックオフの追加が必須です。
未実行：Paused になっていないか、またはモバイル端末側の Active スイッチがオフになっていないか確認します。

ログをディスクに記録して通知の氾濫を防止：承認・遮断時のみカード通知をポップアップさせます。要約は docs/reports/YYYY-MM-DD.md に書き込み、1行ログは workspace/run.log に追記します。

監視と日常のメンテナンス

デスクトップでは Details、モバイル端末では設定ファイル内で Routine を確認でき、Failed をクリックするとエラースタックトレースを確認できます。

毎週 Usage & Billing を確認してください（v0.70.2 で利用量の表示が修正されました）。消費が急増している場合、空振りやリトライを繰り返している Routine があることを示しています。

毎週金曜日に15分間を確保して Routine を整理しましょう。

workspace/run.log を確認し、実際の成果物をチェックします。
7日間連続で更新（差分）がない Routine は、まず Pause にします。
停止後2週間経過して依存関係がなければ Delete routine を実行します。削除は取り消せず、Webhook も同時に無効化されます。

陥りやすい落とし穴

平日の判定仕様：「毎日8時」と設定しても平日扱いされることがよくあります。常時稼働タスクの場合、プロンプトに「土曜日と日曜日を含む」と明記する必要があります。
タイムゾーンのズレ：Routine 作成前にまず Settings -> Bot -> Timezone でタイムゾーンを確認してください。クラウドのデフォルトは UTC のため、9時と設定すると深夜に実行されてしまいます。
プラスボタンによる Bot 作成の不具合：サイドバーの（+）からの新規作成はフリーズしやすいため、動かない場合は既存の安定した Bot との会話から新しい Bot を派生させてください。
認証情報の未保存：Webhook の設定時は必ず下部の Save をクリックして発行してください。保存せずにページを離れるとシークレットキーが生成されません。
システム更新によるリセット：「コンピューターを更新」（Update computer）を行うとイメージが初期化され、apt-get でインストールした cron が消失します。更新後はターミナルで cron を確認してください。
キーの漏洩：Webhook のシークレットキーを通常のチャットに貼り付けてはいけません。誤送信した場合は直ちにメッセージを削除し、Routine で再発行（リセット）してください。
Test による実実行：Test をクリックすると利用枠が消費され、ファイルも変更されます。本番データ上でテストすることは厳禁です。

完了後の検証・検収手順

デスクトップで When to run 内の英語スケジュール（例：「Every day at 8:00 AM CST」など）を確認し、ローカルのタイムゾーンや週末の設定と合致しているか確認します。
新規 Routine は次の周期まで実行されないため、Next run の時刻が正確か確認します。
データソースの名前を変更するか空にして Test を1回実行し、「データソース異常」のログを出力して正常に停止すること（適当な情報を捏造しないこと）を確認します。
メールの送信、投稿、ディレクトリ削除などの指示を注入し、操作が遮断されてカードがポップアップすること（外部へ直接リクエストが飛ばないこと）を確認します。
ターミナルから curl を使って Webhook に POST リクエストを送信します：

bash

   curl -i -X POST "你的_WEBHOOK_URL" \
        -H "Authorization: Bearer 你的_KEY" \
        -H "Content-Type: application/json" \
        -d '{"test": "ping"}'

1秒以内にステータスコード 200 を受信すること、および30秒以内にクライアント上で Bot が Running に変わり、受領通知と構造化された結果を出力することを確認します。

関連章：第 8 章技能与例程：把一次成功变成每天自动跑
関連章：第 10 章额度与成本：让一周用量撑满一周
公式ドキュメント：《Cursor Help: Routines》
コミュニティ原文：《4.3 触发器与自动化：定时、Webhook、在 X 上派活》
コミュニティ原文：《Grok Bot Webhook + 快捷指令：知识自动入库流水线搭建》
コミュニティ原文：《Grok Bot 额度再省一点：定时任务极限优化》

第20章 信頼性の高い自動化：スケジュール、Webhook、イベントトリガー ​

トリガーの選定：定刻実行か、変化待ちか ​

サブスクリプションとクォータ制限 ​

トリガー方式と選定 ​

Routine 設計テンプレート：肩書きではなく契約書を書く ​

契約書の作成と Routine の設定 ​

本番稼働前のドライラン（事前検証）テスト ​

ヒューマンインザループ（安全弁）を確実にロックする ​

Webhook 連携：モバイル端末と外部パイプラインの接続 ​

認証情報とステータス ​

ショートカット ​

差分判定による空振りの防止：2段階チェックアーキテクチャ ​

1. デカップリングの原理：目覚まし時計と頭脳の役割分担 ​

2. 仮想マシンでの導入・設定手順 ​

サードパーティイベントおよび X プラットフォームとの連携 ​

Slack トリガー ​

X プラットフォーム連携の境界 ​

失敗時のフォールバックとフォールトトレランス戦略 ​

監視と日常のメンテナンス ​

陥りやすい落とし穴 ​

完了後の検証・検収手順 ​

関連記事 ​

第20章信頼性の高い自動化：スケジュール、Webhook、イベントトリガー

トリガーの選定：定刻実行か、変化待ちか

サブスクリプションとクォータ制限

トリガー方式と選定

Routine 設計テンプレート：肩書きではなく契約書を書く

契約書の作成と Routine の設定

本番稼働前のドライラン（事前検証）テスト

ヒューマンインザループ（安全弁）を確実にロックする

Webhook 連携：モバイル端末と外部パイプラインの接続

認証情報とステータス

ショートカット

差分判定による空振りの防止：2段階チェックアーキテクチャ

1. デカップリングの原理：目覚まし時計と頭脳の役割分担

2. 仮想マシンでの導入・設定手順

サードパーティイベントおよび X プラットフォームとの連携

Slack トリガー

X プラットフォーム連携の境界

失敗時のフォールバックとフォールトトレランス戦略

監視と日常のメンテナンス

陥りやすい落とし穴

完了後の検証・検収手順

関連記事