ドキュメントに戻るコアコンセプト

オートメーション

ワークフローを自動で実行するトリガー — スケジュール、メール、GitHub、カレンダー、Notion、Webhook。

最終更新日: 2026年7月31日 · 2 min read

オートメーションとは、ワークフロー(スキル)に取り付けたトリガーです。ワークフローが何をするかを決め、オートメーションがいつするかを決めます。この2つが揃うと、かつて手で打っていた依頼が、あなたの手を離れて動く仕事になります。

カレンダーのリマインダーは「やってね」と促します。オートメーションは仕事を済ませてから「終わったよ」と知らせてくれます。

オートメーションは必ず3つを指定します。

  1. 実行するワークフロー
  2. それを実行するエージェント — 語り口、モデル、使えるコネクタを決めます
  3. トリガー — スケジュール、ツール上のイベント、または受信Webhook

各実行で何が起きるか

起動のたびにフレッシュなチャットが始まります。チャットはツールから最新のコンテキストを読み直し、必要なコネクタを呼び、結果を生成します。

これには2つの意味があります。

  • 蓄積された状態がない。 先週月曜の実行が今週月曜の実行に漏れません。手順は同じ、データは最新です。
  • 各実行はリプレイ可能。 オートメーションの実行履歴を開けば、直近の実行が何をしたか、どこでクレジットを使ったか、何を生成したかが正確に分かります。

実行が失敗した場合(ネットワーク不調、トークン期限切れ、入力の曖昧さ)、Zeroは原因とともに失敗を記録し、黙って落とさず通知します。

トリガーの種類

スケジュール

最も一般的なファミリーです。毎日・毎週・毎時、カスタムcron式、固定間隔、あるいは指定した一度きりの時刻でオートメーションが動きます。

トリガー発火するタイミング
cron指定したタイムゾーンでのcron式 — 0 8 * * 1-5
once設定した日時に一度だけ
loop固定間隔ごと — 15m1h90s

タイミングの指定方法は4通り。 cronを書く必要はありません。

  • 自然言語。 「平日8時、ロサンゼルス時刻」 — Zeroが解釈します。タイムゾーン、平日、「月初」「隔週金曜」なども動きます。ほとんどのチームはこれを選びます。
  • Cron式。 0 8 * * 1-5。細かい制御が必要なときに。IANAタイムゾーン(Asia/TokyoAmerica/Los_Angeles)を併せて指定します。
  • 間隔。 15m1h90sごと — loopです。壁時計に揃える必要のないヘルスチェックやポーラー向け。
  • 一度きり。 設定した日時に1回だけ発火するonce。ローンチ、エンバーゴ、締め切りに紐づくリマインダーに便利です。

タイムゾーンを指定しないスケジュールはUTCで動きます。 読み手にとっての「9時」とは通常一致しないので、必ずゾーンを指定してください。

頭の中にある「やらなきゃ……」のうち、繰り返し発生するものはほぼ候補になります。毎平日8時のモーニングブリーフ、毎週月曜の週次メトリクスダイジェスト、毎晩の受信箱クリーンアップ、30分ごとの本番ヘルスチェック、第3月25日の四半期末取締役会準備など。

時計ではなくイベントから始めるべき仕事(メールの着信、PRの承認、ページの公開など)は、以下のトリガーのほうが適しており、ポーリングで実行を無駄にしません。

メール

トリガー発火するタイミング
gmail-new-message新しいメッセージが届いたとき
gmail-label-applied指定したラベルがメッセージに付いたとき

どちらもFrom、To、Cc、件名、本文へのテキストルールで絞り込めます。それぞれ含む含まないが使えます。ルールなしのGmailオートメーションは受信するすべてのメッセージにマッチするので、狭いところから始めてください。

受信箱を見張らずにサポートメールをトリアージする:from-contains: @customer-domain.comで絞ったgmail-new-messageが、レビュー用の下書きを用意するcustomer-reply-draftワークフローを実行します。

GitHub

トリガー発火するタイミング
github-label-appliedIssueまたはPRにラベルが付いたとき — ラベル、リポジトリ、Issue/PR/両方、実行者が自分か誰でもかで絞り込み
github-workflow-run-completedActionsの実行が終わったとき — リポジトリ、ワークフロー、結論、ブランチ、トリガーイベント、実行者で絞り込み
github-workflow-job-completed単一ジョブが終わったとき — さらにジョブ名、ランナーラベル、ランナーグループで絞り込み
github-pull-request-review-submittedレビューが提出されたとき — レビュー状態(承認、変更要求、コメント)、baseとheadブランチ、信頼できる作成者で絞り込み
github-deployment-status-createdデプロイの状態が変わったとき — 環境、状態、ref、作成者、アプリ、本番のみで絞り込み
github-issue-comment-createdコメントが付いたとき — リポジトリ、Issue/PR/両方、実行者、必要なコメント接頭辞で絞り込み

GitHubトリガーにはワークスペースへのGitHub Appのインストールが必要です。フィルタはカンマ区切りの値を受け付けます。省略すればすべてにマッチします。

CIのループを閉じる:mainconclusion: failureに対するgithub-workflow-run-completedが、ログを読んで失敗ステップを特定し、Slackに診断を投稿するワークフローを実行します。

カレンダー

トリガー発火するタイミング
google-calendar-event-created新しい予定が追加されたとき
google-calendar-event-updated予定が変更されたとき
google-calendar-event-cancelled予定がキャンセルされたとき

いずれも1つのカレンダーを監視します。既定ではプライマリカレンダーです。

会議に丸腰で臨まない:google-calendar-event-createdが、社外参加者とその企業を調査して会議前ブリーフを送るワークフローを実行します。

Notion

トリガー発火するタイミング
notion-child-page-created指定した親ページの下にページが追加されたとき
notion-database-item-created指定したデータベースに行が追加されたとき
notion-page-content-updatedページの内容が変わったとき。ページ単位でもデータベース単位でも監視可能

CMS

トリガー発火するタイミング
strapi-entry-publishedエントリが公開されたとき — 特定のコンテンツタイプとロケールに絞ることも可能

Webhookとチャット

トリガー発火するタイミング
webhook外部システムが署名付きWebhook URLを呼んだとき。署名シークレットは作成時に一度だけ表示されるので、その場でコピーしてください。TeamとEnterpriseで利用可能。
chat-run-finished指定したチャットスレッドで実行が完了したとき — 完了ステータス(完了、失敗、キャンセル)と、実行の最終メッセージに対するワイルドカードパターンで絞り込み可能

chat-run-finishedは仕事を連鎖させる方法です。あるオートメーションの出力が、次のオートメーションの号砲になります。

オートメーションを作成する

動いているチャットから作る。 まずはワンオフでタスクを実行します。望みどおりの結果が出たら、こう言います。

「これを平日8時(ロサンゼルス時刻)に実行して、結果をDMで送って。」

Zeroがワークフロー、頻度、送信先を確認し、ワークフローがまだなければ保存して、オートメーションを取り付けます。

明示的に作る。 ワークスペースでワークフローを開き、トリガーの種類とフィルタを選んでオートメーションを追加します。形が事前に分かっていて、ドライランをしなくてよい場合に便利です。

オートメーションは削除せずに個別で有効化・無効化できます。休暇前や、うるさいトリガーをデバッグする間に使ってください。

送信先

オートメーションは結果の送信先を知る必要があります。ワークフローの指示文に書いてください。

  • SlackのチャンネルまたはDM — 最も一般的。チャンネルにメッセージかスレッドとして届きます
  • FeishuまたはMicrosoft Teams — そこで仕事をしているチーム向けに同じ考え方で
  • Telegramまたはテキストメッセージ — 個人向け、モバイル優先の通知に
  • NotionページまたはDB — ブロードキャストではなくアーカイブしたい場合
  • Google DocまたはSheet — 追記もしくは上書き
  • GitHub IssueまたはPRコメント — エンジニアリングワークフロー向け
  • Gmailの下書き — あなたのアカウントに用意され、確認して送信できます
  • ホスティングされたページ — 公開URLとして共有したい成果物に
  • ワークスペース内ファイル — 動画、画像、ダウンロード可能な成果物の場合

#engineeringに投稿して」「DMで送って」のほうが「どこかに送って」より明確です。

運用のコツ

本番でオートメーションを動かして学んだことです。

  • 最初の3回を観察する。 オートメーションはセットアップは簡単ですが、自分の環境でZeroが実際に何を出すかを見てから磨くと、さらにしっかりします。
  • 各タスクを小さく保つ。 長くて多段のオートメーションは脆くなりがちです。1つで5つのシステムを更新する必要があるなら、2つに分割を検討しましょう。
  • 送信先を固定する。 チャンネルはリネームされ、人は離れます。送信先をワークフローの指示文に名前で書いておくと、次回見つからない場合にZeroが警告します。
  • 長時間クエリは時間を区切る。 「過去30日」のような窓は毎回再記述すると、ウィンドウが新鮮に保たれます。
  • タイムゾーンに注意する。 タイムゾーンを指定しないスケジュールはUTCで動きます。
  • 休暇前は一時停止する。 特にDMを送るオートメーションは、戻ってきて14個のブリーフDMがあっても役に立ちません。無効化しておき、戻ったら再開します。ワークフローはそのまま残ります。

コスト

各実行はクレジットを消費し、実行はそれを走らせたエージェントに紐づけられます。実行履歴には各実行のクレジットコストが表示されるので、高コストのものを見つけられます。モーニングブリーフは通常安価で数百クレジット、週次のマルチツールコンテンツバンドルは1〜2千クレジット程度。ドル換算はクレジットと請求を参照してください。

短いloop間隔はすぐに膨らみます。15分ごとなら1日96回です。

イベントトリガーは想像以上に賑やかになることがあります。フィルタなしのGmailオートメーションや、活発なモノレポ全体を対象にしたGitHubオートメーションは、予想よりはるかに頻繁に発火します。まず狭く絞り、それから広げてください。

次に進むには