トリガー

トリガーは、スケジュール、Webhook、アプリイベント、またはモニターによってセッションを開始します。

トリガーは、人がいない状態でセッションを開始します。トリガーを使うと、定期的な作業やイベント駆動型の作業を自動化できます。

1つのセッションのタスクを後で確認する場合（「明日、返信があったか確認する」など）は、代わりにリマインダーを使います。リマインダーは、そのセッションに限定されたトリガーです。beeuni.yamlではなく、データベースに保存されます。

トリガーの種類

Beeuniは4種類のトリガーに対応しています。

• cron — 設定したスケジュールで実行します。
• webhook — 外部サービスがプロジェクトのWebhook URLに署名付きリクエストを送信すると実行します。
• event — 接続済みアプリで新しいプルリクエストやメールの受信などが発生すると実行します。アプリイベントトリガーを参照してください。
• monitor — リポジトリのコマンドを24時間365日実行します。コマンドがstdoutに出力する各行でトリガーが発火します。試験運用中です。モニターを参照してください。

トリガーはプロジェクトマニフェストbeeuni.yamlで定義します。各トリガーには、発火したセッションの最初のメッセージとして表示されるプロンプトがあります。最終発火時刻やステータスなどの実行時の状態は、マニフェストではなくデータベースに保存されます。トリガーが発火してもコミットは作成されません。

ダッシュボードからトリガーを作成、更新、削除すると、デフォルトブランチに直接書き込まれます。変更リクエスト（CR）は経由しません。セッション内でbeeuni.yamlを編集してbeeuni shipを実行する場合は、通常どおりブランチとCRのフローに従います。

cronトリガーを設定する

beeuni triggers add daily-digest --type cron \
  --cron "0 0 9 * * 1-5" --timezone America/Los_Angeles \
  --prompt "Summarize yesterday's activity and save it as a daily note."

beeuni ship

beeuni triggers ls

Webhookトリガーを設定する

Webhookトリガーにはシークレットが必要です。Beeuniはこれを使って、受信リクエストごとに署名を検証します。

beeuni secrets set WEBHOOK_SECRET=<a-random-value>

beeuni triggers add new-lead --type webhook \
  --secret-env WEBHOOK_SECRET \
  --prompt "A new lead arrived: {{ body.name }} ({{ body.email }}). Add it to the CRM."

beeuni ship

POST /v1/webhooks/projects/<project-id>/<slug>

デフォルトでは、発火するたびに新しいブランチで新しいセッションが開始されます。トリガーでは、セッションを再利用または固定することもできます。また、Webhookトリガーでは、どのペイロードでセッションを開始するかをフィルタリングできます。以下のセッション戦略とペイロードテンプレートを参照してください。

アプリイベントトリガー

イベントトリガーは、プルリクエストが開かれたとき、メールが届いたとき、課題の状態が変わったときなど、アプリイベントが発生するとエージェントを実行します。Webhook、シークレット、署名を設定する必要はありません。Beeuniが代わりにイベントを購読するため、署名を手動で行う必要はありません。

イベントはイベントソース（アプリのイベントを配信するアダプター）から届きます。GITHUB_PULL_REQUEST_CREATEDなどのイベントIDは、そのソースが対応するイベントを識別します。イベントカタログからコネクターに対応するイベントを選択してください。

Webアプリで設定する

1. プロジェクトを開き、Triggers、New triggerの順に選択します。
2. App eventを選択します。
3. アプリを選びます。その下でコネクターと共有アカウントを1つ選ぶか、別のアカウントを接続します。別のアカウントを選ばない場合は、Defaultと表示されたアカウントが使われます。
4. イベントを選びます。リポジトリなど、そのイベントの設定フォームが下に表示されます。
5. プロンプトを入力して保存します。

バッジがLiveになると、トリガーは有効です。それ以外のバッジは、Activating、Needs connection、Errorです。これらは、以下のpending、needs_connection、errorのステータスに対応します。

すべてのアプリイベントトリガーを表示する

WebアプリでTriggersを開き、App eventsを選択します。フィルター行には、件数とともにAll、Schedules、App events、Webhooksが表示されます。選択内容は?type=eventとしてアドレスに保存されるため、リンクで共有できます。行はアプリごとにグループ化されます。その下のApps with eventsには、エージェントを起動できるすべてのアプリが表示され、プロジェクトで使用中のアプリが先に並びます。アプリを選ぶと、そのアプリを選択した状態で新しいトリガーのフォームが開きます。

コネクターのウィンドウにはTriggersタブがあり、そのコネクターで利用できるアプリイベントが表示されます。このタブはイベントがあるアプリにのみ表示されます。

CLIを使う場合:

beeuni triggers ls --type event                 # every app event trigger, grouped by app
beeuni triggers ls --connector github-work      # the app events on one connector
beeuni triggers ls --type event --json          # the same list as JSON

--typeではcron、webhook、monitorも指定できます。--connectorと--typeは組み合わせて使えます。

CLIで設定する

エージェントまたは人が、以下の手順を順番に実行します。各手順は、次の手順に必要な情報を出力します。

beeuni triggers events --apps
beeuni triggers events --app github
beeuni connectors add github --provider composio --app github --apply
beeuni connectors connect github --owner project
beeuni triggers events --connector github
beeuni triggers events --connector github --event GITHUB_PULL_REQUEST_CREATED
beeuni triggers add pr-review --type event \
  --connector github --event GITHUB_PULL_REQUEST_CREATED \
  --config repo=hekmat/api \
  --prompt "Review {{ event.data.html_url }}" --apply
beeuni triggers info pr-review

1. triggers events --appsはイベントをトリガーできるアプリの一覧を表示します。アプリはイベントソースごとにグループ化されます（source: composio）。各アプリにはコネクター（プロファイル）と共有アカウントが表示されます。STATE列にはconnectedまたはneeds accountと表示され、コネクターのないアプリはNo connector yetの下に表示されます。
2. connectors addは、アプリにコネクターがない場合に追加します。CONNECTORが設定されている場合は、この手順を省略します。
3. connectors connect <slug> --owner projectはリンクを出力します。人がリンクを開いて共有アカウントを接続します。メンバーの個人アカウントは対象になりません。2つ目の共有アカウントを追加するには、もう一度実行してからconnectors rename <id> <label>でラベルを付けます。
4. triggers events --connector <slug>はイベントの一覧を表示します。イベントの設定と{{ event.data.* }}変数を確認するには、--event <TYPE>を追加します。各設定の説明を確認してください。repo: hekmat/apiのように、1つの設定に完全な名前を指定するイベントもあり、同じ値をownerとrepoに分けて指定すると拒否されます。
5. triggers add --applyはトリガーをすぐに作成し、ステータスと次の手順を表示します。設定がない場合や無効な場合は、終了コード2で終了し、すべての問題を一覧表示します。--applyを指定しない場合、CLIはブロックをローカルのbeeuni.yamlに書き込みます。反映するにはbeeuni shipを実行します。
6. triggers info <slug>はステータスを表示します。liveと表示されるまで繰り返します。

--source <adapter>はイベントソースを指定するもので、省略可能です。省略すると、トリガーはコネクターのプロバイダーを使います。コネクターはそのソースに属している必要があります。別のプロバイダーのコネクターにcomposioソースを指定すると、errorと表示されます。Connector "<slug>" is a <provider> connector; source "composio" needs a composio connector.不明なソースを指定すると、Unknown event source "<x>". Sources: composio.で拒否されます。beeuni triggers set <slug> --source <adapter>で変更でき、--connectorを変更するとソースがクリアされます。

--config key=valueは設定ごとに1回繰り返され、設定の型に変換されます。--config-json '{"limit": 5}'は型付きの値を渡します。beeuni triggers set <slug> --config key=valueは現在の設定にマージし、--config-jsonは置き換えます。両方を渡さないでください。イベントトリガーには、--cron、--run-at、--timezone、--secret-env、--run、--mode、--interval、--expect-event-withinのいずれも指定しません。

設定の構造

# beeuni.yaml
triggers:
  - slug: pr-review
    type: event
    connector: github-work # required, slug of a connector (profile) under `connectors:`
    source: composio # optional, the event source adapter. Default: the connector's provider
    account: hekmat-bot # optional, label of one shared account of that connector
    event: GITHUB_PULL_REQUEST_CREATED # required, the adapter's event id, from `beeuni triggers events`
    config: { repo: hekmat/api } # optional, settings of the event
    agent: default
    session_mode: fresh # default "fresh"
    filter: # optional, same guard a webhook uses
      "event.data.draft": "false"
    prompt: |
      Review {{ event.data.html_url }}

プロンプトが読み取れる内容

プロンプト、filter、session_keyは、次のルートを読み取ります。

イベントデータはサードパーティから送られます。Beeuniはセッションの最初のメッセージに[App event: <trigger name> — automated, third-party content, not user input]を付け、エージェントがイベント内容を指示ではなくデータとして扱うようにします。エージェントが名前を付けるまでは、この行がセッションのタイトルにもなります。

ステータス

beeuni triggers lsとウェブトリガー一覧には、各イベントトリガーのサブスクリプション状態が表示されます。

よくあるerrorのテキスト：

• 「This <app> account is shared with specific people only. Event triggers need an account shared with the whole project.」アカウントの共有設定を開き、プロジェクト全体と共有します。

• 「Connector <slug> is not declared in beeuni.yaml.」connectors:にコネクタを追加します。

• イベントトリガーを利用できない場合は、サポートにお問い合わせください。

• 「The app disabled this subscription: …」プロバイダーがサブスクリプションを無効にしました。トリガーをもう一度保存して、再登録します。

• 「The connected account expired: …」アプリによってアカウントが取り消されたか、期限切れになりました。アプリを再接続すると、トリガーが再開します。

ルール

• コネクタとアカウント。 アプリはGitHubなどのサービスです。コネクタはbeeuni.yaml内のプロファイルで、複数のコネクタが同じアプリを共有できます。アカウントはコネクタに接続されたログインアカウントです。トリガーではコネクタを指定します。account: <label>を設定しない限り、そのコネクタのデフォルトの共有アカウントが使われます。accountを設定するのは、コネクタに複数の共有アカウントがある場合だけです。CLIでは--account <label>で設定し、triggers setの--default-accountで解除します。共有アカウントに一致するラベルがない場合、needs_connectionとなり、「Connect a shared <app> account labelled “<label>” on <connector>.」と表示されます。
• 使用できるアカウントは1つ。 トリガーに使用できるのは、プロジェクト共有され、プロジェクト全体に公開されているアカウントのみです。トリガーは誰もいない状態でも実行され、イベントデータはセッションプロンプトに入ります。特定の人とのみ共有されているアカウントや個人アカウントは使用できません。
• 各イベントは1回だけ起動。 トリガーはプロバイダーのイベントごとに1回起動します。再配信されたイベントによって2つ目のセッションが開始されることはありません。同じイベントに対する2つのトリガーは、それぞれ1回ずつ起動します。
• 一時停止すると停止。 トリガーまたはプロジェクトが一時停止中の場合、イベントはスキップされます。スキップされたイベントはキューに入りません。
• 編集すると再登録。 connector、source、account、event、configを変更すると、サブスクリプションが置き換えられます。トリガーを削除すると、サブスクリプションも削除されます。

モニター

試験運用中。 モニターはmonitors機能フラグが有効な場合にのみ実行されます。このフラグはデフォルトでオフです。オフの間、プラットフォームはモニターボックスをプロビジョニングせず、モニターイベントも発生させません。

モニターは、Webhookで通知できず、スケジュールにも適さない対象（ライブログ、キューの深さ、変化するページ、価格など）を監視します。Beeuniはプロジェクトのモニターボックスでコマンドを24時間365日実行します。モニターボックスはプロジェクトごとに1つの永続的なmicroVMで、セッションのサンドボックスと同じ隔離境界とプロジェクトシークレットを使用します。監視は決定論的なコードが行い、コマンドが行を出力したときだけエージェントが起動します。

次の4つのルールで仕様が定まります。

• イベントになるのは標準出力の行のみです。 標準エラー出力は診断情報で、モニターのログには表示されますが、トリガーは起動しません。
• 各行はWebhookと同じ経路で、トリガーをちょうど1回起動します。filter → プロンプトテンプレート → session_mode。
• モニターが気付かれずに失敗することはありません。 プロセスの終了、再起動回数の上限到達、expect_event_withinを超える無出力はそれぞれ、プラットフォームが記述したライフサイクルイベントを同じストリーム内で発生させます。
• モニターではsession_modeのデフォルトはreuseであり、freshではありません。モニターは設計上、繰り返しイベントを発生させるため、freshではイベントごとにセッションが1つ作られてしまいます。

beeuni triggers add checkout-errors --type monitor \
  --run "./monitors/checkout-errors.ts" \
  --mode poll --interval 60s --expect-event-within 24h \
  --prompt "Checkout monitor emitted: {{ line }}"

beeuni ship

beeuni triggers ls
beeuni triggers info checkout-errors

モニターの制限

以下の上限はすべてプラットフォームによって適用されます。

モニターボックスには、永続的なサンドボックスをサポートするプロバイダーが必要です。プロジェクトのプロバイダーが永続的なサンドボックスに対応していない場合、monitorsフラグは利用不可と報告します。

設定の構造

# beeuni.yaml
triggers:
  - slug: daily-digest # required, lowercase + dashes, unique per project
    name: Daily digest # optional, defaults to slug
    type: cron # "cron" | "webhook" | "event" | "monitor", required
    agent: beeuni # optional, defaults to "default"
    model: anthropic/claude-sonnet-4-5 # optional, resolves at fire time if unset
    enabled: true # optional, default true
    cron: "0 0 9 * * 1-5" # 6-field expression, mutually exclusive with run_at
    timezone: America/Los_Angeles # IANA name, default UTC
    session_mode: reuse # "fresh" | "reuse" | "pinned" | "keyed", default "fresh"
    filter: # optional, webhook payload guard
      "body.data.direction": "inbound"
    prompt: "Summarize {{ body.text }}" # required, template string

モニターでは、スケジュールのフィールドをコマンドと形式に置き換えます。

# beeuni.yaml
triggers:
  - slug: checkout-errors
    type: monitor
    run: ./monitors/checkout-errors.ts # required, repo-relative command
    mode: poll # "poll" | "stream", required
    interval: 60s # required on poll, invalid on stream
    expect_event_within: 24h # optional silence watchdog
    agent: oncall
    session_mode: reuse # the monitor default
    filter: # optional, same guard a webhook uses
      "line.severity": "error"
    prompt: "Checkout monitor emitted: {{ line }}"

イベントトリガーでは、スケジュールのフィールドを監視対象のアプリとイベントに置き換えます。アプリのイベントトリガーを参照してください。

従来のbeeuni.tomlでは、異なるコンテナ内で同じフィールドを使用します。従来のTOMLを参照してください。

フィールド

cronトリガーではcronまたはrun_atが必要です。両方は指定できません。secret_envのないWebhookトリガーは拒否されます — 認証なしのWebhookはありません。モニターではrunとmodeが必要です。また、cron、run_at、timezone、secret_envは無条件で拒否されます — モニターランナーが読み取らないスケジュールを記載したマニフェストは虚偽です。

Webhookトリガーを作成または更新する前に、署名シークレットを設定してください。

beeuni secrets set WEBHOOK_SECRET=-
beeuni secrets delivery WEBHOOK_SECRET broker --consumer connector

値は最初のコマンドに標準入力で渡してください。シークレットで以前sandbox配信を使っていた場合は、配信方式を変更した後にローテーションしてください。既存のsandboxに以前の値が残っている可能性があります。

セッション戦略

session_modeは、発火時にどのセッションへ再プロンプトするかを制御します。Beeuniは以下のモードを順に試し、各段階で失敗すると次に進みます。

1. pinned — 指定されたsession_idに再プロンプトします。そのセッションが存在しないか、失敗した場合は次に進みます。
2. keyed — ペイロードに対してsession_keyをレンダリングし、その完全一致キーが以前スタンプされた、直近の失敗していないセッションを検索します。キーが空になるか、一致するセッションがない場合は、新しいセッションに進みます。別のキーのセッションに切り替わることはありません。
3. reuse — このトリガーが以前作成した、直近の失敗していないセッションに再プロンプトします。固定セッションを指定したトリガーも、さらに先へ進む前にここへフォールバックします。
4. fresh — 新しいsandboxとブランチを作成します。これがデフォルトであり、すべてのモードにおける最終フォールバックです。新しいセッションは、今後のreuseおよびkeyedの発火に使う、このトリガーのセッションになります。

reuseまたはkeyedセッションの履歴が、自動圧縮後もモデルの上限に収まらない場合、そのセッションは終了扱いになります。次回の発火時に新しいセッションが開始されます。それ以外の失敗では、次回の発火に備えてセッションが保持されます。

頻繁に発火するcronトリガーで、増え続ける履歴を毎回送り直したくない場合は、暦の区切りでセッションを切り替えられます。session_key: "merge-{{ cron.scheduled_date }}"はUTC日ごとに1つのシリアル化されたセッションを保持し、{{ cron.scheduled_hour }}はUTC時間ごとに1つ保持します。

実行の失敗

トリガーが開始した実行がエラーで終了すると、Beeuniはトリガーにその失敗を記録します。

• last_statusがfailedになり、last_errorに理由が記録されます。例：Out of credits: Payment Required: Insufficient credits.
• Scheduleページではトリガーに「前回の実行は完了しませんでした」と表示され、パネルに理由が表示されます。
• 最初の実行が失敗すると、アカウント所有者にモバイルプッシュ通知が1回送信されます。その後の実行が失敗しても、理由が更新されるだけで、追加の通知は送信されません。
• 発火し続ける限り、トリガーはfailedのままです。新たに発火したからといって、その実行が正常に動作したことにはなりません。

次の実行が完了すると、失敗状態は解除されます。自分で停止した実行、サブエージェント、再試行されたモデル呼び出しは、実行結果には含まれません。セッションを作成できないなど、実行開始前に発火が失敗した場合は、次に発火が成功した時点で失敗状態が解除されます。

セッションへのアクセス

トリガーが作成するセッションには、デフォルトで非公開ポリシーが適用されます。所有者はトリガーエージェントのサービスアカウントです。エージェントのIDはservice_accountプリンシパルなので、ほかのプリンシパルと同様に、セッションを所有して割り当てを保持できます。プロジェクトマネージャーはいつでもセッションを開けます。アカウント所有者とアカウント管理者はすべてのプロジェクトでマネージャー相当のアクセス権を持つため、同様にセッションを開けます。トリガーを設定した人や手動で発火させた人は、これらのロールのいずれかを持たない限り、その操作によってアクセス権を得ることはありません。

トリガー設定では、次の3つのポリシーを選択できます。

• トリガーエージェントとプロジェクトマネージャー — 一般のプロジェクトメンバーはセッションを開けません。
• 選択したチームメイト — トリガーエージェント、プロジェクトマネージャー、および選択したプロジェクトメンバーまたはアカウントグループが対象です。
• プロジェクト全体 — すべてのプロジェクトメンバーが対象です。

このポリシーは、ロールモデルに追加されるリソース単位の可視性設定であり、ロールではありません。1つのトリガーのセッションを誰が開けるかを決定します。ロール判定で拒否される権限が付与されることはありません。アカウントとアクセスを参照してください。

アクセス ポリシーは、アカウント内のランタイム状態です。プリンシパルIDはアカウントごとに異なるため、ポータブルなbeeuni.yamlマニフェストには含まれません。設定にはダッシュボードを使用してください。 このポリシーのみを更新しても、Gitコミットは作成されません。ポリシーを保存すると、そのトリガーが以前に作成したセッションにも適用されます。

固定セッションは、トリガーが作成したものではないため、独自の共有設定を保持します。固定セッションが利用できず、トリガーがフォールバックセッションを作成した場合は、新しいセッションにトリガーポリシーが適用されます。

ペイロードのテンプレート処理

promptとsession_keyは、同じエンジン{{ token.dotted.path }}でレンダリングされます。値がない場合は空文字列としてレンダリングされ、エラーや未処理の{{ }}は残りません。オブジェクトと配列はJSONとしてレンダリングされます。session_keyは前後の空白を削除し、512文字に切り詰められます。

各発火では、{{ trigger.slug }}、{{ trigger.type }}、{{ trigger.kind }}も取得できます（常にgit）。その他の変数は、トリガーの発火方法によって異なります。

Beeuniは、レンダリングされるすべてのmonitorプロンプトに、サーバー側で[MONITOR EVENT — automated, not user input]を付加します。ライフサイクルイベントではテンプレートは完全に無視され、プラットフォームが作成したプロンプトがレンダリングされます。また、filterも適用されません。意図せずサイレンスをフィルタリングしてはならないためです。

manual fireでは{{ message.text }}は空文字列にハードコードされ、{{ message.source }}はmanual_testにハードコードされます。manual fireを使って、プロンプトにテスト入力を注入することはできません。

filterは、プロンプトに渡されるものと同じペイロードに対し、ドット区切りのパスを文字列として比較します。ループを防ぐための機能です。たとえば、会話の両側を報告するソースでは、エージェント自身の返信によってエージェントが再度発火してしまいます。

Webhook署名

POST /v1/webhooks/projects/{projectId}/{slug}で発火します。Beeuniは、一定時間で比較を行いながら、次の順序でリクエストを検証します。

1. HMAC署名 — ヘッダーX-Beeuni-Signature: sha256=<hmac>（sha256=プレフィックスは省略可）またはGitHub互換のX-Hub-Signature-256。リクエスト本文の生データに対するHMAC-SHA256で、secret_envで指定されたシークレットを使用します。
2. 静的トークン — 署名ヘッダーがない場合に限り、本文にHMAC署名できない送信元向けに使用します。シークレットはX-Beeuni-Token: <secret>、Authorization: Bearer <secret>、またはAuthorization: Basic <base64(user:secret)>として送信します（パスワード部分がトークンです）。

beeuni triggers info <slug>はこの方式を出力します。ヘッダー、アルゴリズム、$SECRETのプレースホルダーで署名したリクエスト例が含まれます。--jsonではこれをwebhook_signingとして渡します。ダッシュボードのトリガーシートにも同じリクエスト例が表示されます。

エンドポイント

一時停止と再開

プロジェクトレベルのスイッチを使うと、各トリガー固有のenabledフィールドに関係なく、プロジェクト内のすべてのトリガーを一度に停止できます。一時停止中はスケジューラがプロジェクトをスキップし、受信したwebhookは{ status: "skipped" }を伴う200を返します。セッションは発火しません。手動での発火は引き続き可能です。同じリポジトリを2つのコントロールプレーン（たとえば開発環境と本番環境）で実行し、cronが二重に発火しないようにする場合に使います。CLI: beeuni triggers pauseおよびbeeuni triggers resume。コマンドグループbeeuni triggersの全容についてはCLIを参照してください。

制限と信頼性

• スケジューラは約1秒ごとにポーリングします（デフォルトは1,000 ms。BEEUNI_TRIGGER_SCHEDULER_INTERVAL_MSで設定可能）。cronの実行はスケジュール上の時刻ちょうどには開始されません。トリガーごとに最大で周期の4分の1、最長30分の固定オフセットが設定されるため、同じ分に設定された多数のトリガーが一斉に開始することはありません。トリガーの詳細とGET /triggers（next_fire_at）に、次回の実行開始時刻が表示されます。
• 発火に失敗すると、エラーとともにトリガーの最終ステータスがfailedに設定されます。cron、manual、webhook、app event、monitorのすべてのソースが対象です。次回の発火が成功すると、失敗ステータスはクリアされます。失敗した実行は、失敗した実行の説明に従ってクリアされます。
• デフォルトでは、各プロジェクトで同時にプロビジョニングできるトリガー経由のセッションは3つまでです。上限を超えた発火は失敗せずにqueued（202）を返し、いずれかのプロビジョニングが完了すると実行されます。同時に実行できるセッション数に上限はありません。
• manualまたはwebhookによる発火のタイムアウトは45秒です。マニフェストの読み込みは30秒でタイムアウトします。
• cronによる発火は、実行予定のスケジュールスロットをキーにします。そのため、タイムアウトしたものの実際には到達していた発火が、再試行時に重複することはありません。
• webhookの配信はイベントごとに1回だけ実行されます。BeeuniはイベントIDをX-Beeuni-Delivery-Id、X-GitHub-Delivery、X-Gitlab-Event-UUID、Linear-Delivery、webhook-id、svix-idの順に読み取ります。同じIDで再試行すると202 { status: "deduped" }が返され、何も実行されません。X-Request-IdはイベントIDではありません。イベントIDがない場合、同一の本文と署名は10分以内であれば同じイベントとして扱われます。それ以降は再度実行されるため、デプロイごとに同じ静的な本文を送信するジョブは、デプロイのたびに実行されます。イベントごとに新しい値を指定したX-Beeuni-Delivery-Idを送信してください（リクエスト例では$(uuidgen)を使用しています）。
• 前回の試行が恒久的に失敗した（たとえば、アカウントのクレジットが不足していた）場合や、セッションが削除されていた場合、同じIDで再配信すると再度実行されます。重複配信によってlast_fired_atが変わることはありません。