Airbyte公式ブログ解説: agent trigger は webhook か polling かだけでは決まらない

Airbyte は 2026年5月14日、AI agent の trigger architecture を扱う公式ブログを公開しました。webhook と polling の二択ではなく、webhook、log-based CDC、message bus、scheduled polling の delivery contract を分けて考える内容です。

要点

• agent trigger は単なる起動方法ではなく、誤った action を防ぐ基盤になる
• webhook は real-time に見えても重複、遅延、順序入れ替わり、欠落を前提に扱う必要がある
• CDC や message bus は durability / replay を改善できるが、外部 API action まで exactly-once にするわけではない
• agent runtime には durable execution、deduplication、idempotent write boundary が必要になる

今回のブログ記事で語られていること

この記事は、agent system が production に入った途端に trigger の設計が重要になる、という問題意識から始まります。dashboard が5分遅れても困る程度で済む場面はありますが、agent が5分遅れた状態をもとに顧客へメールを送ったり、refund を承認したり、解決済み ticket を escalation したりすると、遅延は業務上の誤作動になります。Airbyte はこの前提で、trigger を webhook か polling かという単純な選択ではなく、delivery contract の違いとして整理しています。

ブログでは、webhook、log-based CDC、message-bus subscription、scheduled polling with conditional GET の4つを並べます。webhook は多くの場合 at-least-once、unordered、best-effort です。Stripe、Shopify、HubSpot、GitHub などで retry、ordering、payload freshness の扱いが違い、consumer 側は重複や順序入れ替わりを前提にしなければなりません。polling は universal fallback ですが、endpoint 数や tenant 数が増えると rate limit にぶつかり、conditional GET を使えない provider では無駄な request が増えます。

CDC は、database を所有している場合には source of truth の transaction log を読めるため強力ですが、SaaS source には使えません。Kafka、Pulsar、EventBridge、Pub/Sub のような message bus は replay や fan-out に強い一方、exactly-once は条件付きで、agent が外部 API を呼んだ瞬間にその保証は途切れます。つまり、trigger layer だけで安全性は完結しません。

Airbyte が強調するのは、trigger と write boundary をセットで設計することです。agent は長時間動き、human approval を待ち、tool を複数回呼び、途中で restart する可能性があります。したがって、trigger は durable runtime に着地し、structural idempotency key、dedup store、read-back verification と組み合わさる必要があります。これは agent を「賢い関数」ではなく、状態と副作用を持つ分散システムとして扱う話です。

実務で確認したいポイント

1. source ごとに webhook / CDC / message bus / polling の選択肢と保証を棚卸しする
2. missing event と duplicate event のどちらがより危険かを workflow ごとに決める
3. trigger が着地する runtime に durable execution と resume があるか確認する
4. agent の write action に structural idempotency key と dedup store を持たせる

どう読むべきか

この投稿は、agent の失敗を model の hallucination だけに押し込めないための設計メモです。agent が業務 system を動かすなら、trigger は「便利な起動口」ではなく、監査、再実行、補償処理まで含む production boundary として扱うべきです。