ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-07-06上級

Managed Agent の完了通知を取りこぼさない — サーバーレス受信とポーリング突き合わせの二重化設計

クラウドの Managed Agent が完了しても通知が届かない、という不安定さをどう設計で潰すか。Cloudflare Workers の冪等な受信口とポーリング照合を二重化し、無人ジョブの完了を確実に回収する状態機械を実装します。

antigravity418managed-agents2cloudflare-workers8webhook3idempotency5

プレミアム記事

Managed Agents の公開プレビューが Gemini API に届いた週、私は嬉しさよりも先に一つの不安を抱えました。クラウド側で走る長時間ジョブは、こちらが画面を見ていない間に終わります。では、その「終わった」という事実は、どうやって手元に返ってくるのでしょうか。

個人開発で Cloudflare Workers を使い、複数サイトの無人処理をエージェントに任せて回している私にとって、これは他人事ではありませんでした。常時起動のサーバーを持たないと決めている以上、完了通知の受け口もサーバーレスになります。そして push 型の通知(webhook)は、便利な反面、静かに落ちます。落ちたことにさえ気づけないのが一番怖いところです。

ここから、Managed Agent の完了を「取りこぼさない」ための受信側の設計を、実際に動くコードとともに組み立てます。核になるのは、push(webhook)と pull(ポーリング)を最初から二重化し、どちらか一方が沈黙しても最終的な状態が一致する、という考え方です。

「完了したのに気づけない」はどこで起きるのか

まず、失敗の起き方を具体的に分解します。クラウドの Managed Agent → 自分の受信口、という経路には、想像以上に多くの隙間があります。

一つ目は、単純な配信欠落です。受信口が一瞬 5xx を返した、デプロイ中で数百ミリ秒だけ落ちていた、あるいはネットワークの都合で配送が諦められた。at-least-once を謳うプラットフォームでも、リトライ回数には上限があります。上限を超えれば、その通知は静かに消えます。

二つ目は、重複配信です。受信口が処理に成功したのに応答を返す直前で切れると、送信側は「失敗した」と判断して再送します。結果として、同じ完了イベントを二回受け取ります。ここで課金処理やファイル公開のような副作用を素直に二回実行すると、実害が出ます。

三つ目は、順序逆転です。runningsucceeded の二つの状態遷移通知が、逆の順で到着することがあります。ネットワーク経路が違えば追い越しは普通に起きます。素朴に「最後に来た通知の状態を採用する」と書くと、完了済みのジョブが running に巻き戻ります。

四つ目が、私が実際に一番刺さったレースです。ジョブを起動して、その job_id を KV に書き込む前に、完了 webhook が到着してしまう。クラウド側の処理が速いと、こちらの「起動を記録する」書き込みが終わる前に「終わった」が届きます。受信口は未知の job_id を見て「知らないジョブだ」と捨ててしまう。これは負荷でも障害でもなく、ただの順序の問題なので、再現も説明も難しいのが厄介でした。

これらを個別のバグとして潰していくと、対症療法の山になります。私は、経路そのものを二重化して「どちらかが真実を運んでくれればよい」構造にする方が、結局は堅牢だと考えています。

設計の前提: push と pull を最初から両輪にする

受信の経路を二つ用意します。

一つは push 経路。Managed Agent が完了した瞬間に webhook を叩き、こちらの Cloudflare Workers が受けます。速いですが、前述のとおり落ちます。

もう一つは pull 経路。こちらから定期的に「あのジョブ、終わった?」とクラウドへ問い合わせ、状態を突き合わせます。遅いですが、落ちません。問い合わせる限り、いつかは正しい状態が取れます。

この二つを合流させる場所が、KV に持つジョブレコードです。push でも pull でも、同じレコードの同じ状態遷移を目指します。両者が競合したときにどちらを採用するかは、状態機械のルールで決めます。「最後に来た方」ではなく「より進んだ状態」を採用する、という単調性を守るのが肝心です。

言い換えると、webhook は「速い近道」であって「唯一の真実」ではありません。真実の最終保証はポーリングが担い、webhook はその到達を早めるための最適化として位置づけます。この役割分担を最初に決めておくと、後の実装がぶれません。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
クラウドの Managed Agent がバックグラウンドで完了しても通知が届かない不安定さを、webhook 受信とポーリング照合の二重化で解消できる
Cloudflare Workers と KV で、重複配信・順序逆転・受信前コミットのレースに耐える冪等な受信口を実装できる
常時起動サーバーを持たない個人開発でも、無人ジョブの完了を数分以内に確実に回収する状態機械を設計できる
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

Agents & Manager2026-06-22
Antigravity の独自ツールが本番で事故るのは『設計』ではなく『再実行』のとき — 冪等化とエラー契約の運用メモ
Antigravity エージェントに独自ツールを足したあと、実運用で本当に問題になるのは再実行と二重副作用です。冪等キー・エラー契約・ヘルスゲート・ツール乱立の抑制を、実装と判断基準ごと整理しました。
Agents & Manager2026-05-26
Antigravity マルチエージェントの状態タイプ階層 — ephemeral / journal / canonical の3層設計と引き継ぎパターン
Antigravity の Background Agent と Sub-agent で状態管理がもつれる前に、ephemeral / journal / canonical の3階層に分けて責任を割り当てる設計則。Cloudflare KV / Durable Objects / R2 / D1 へのマッピング判断と、12年運用の壁紙アプリ群で固まった write-back 境界の決め方を共有します。
アプリ開発2026-04-27
AntigravityでWebhook受信エンドポイントを取りこぼしなく作る実践パターン
StripeやGitHubからのWebhookを確実に処理するエンドポイントの設計・実装・テストを、Antigravity を使って効率的に進めるための実践パターンをまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →