Googleが2026年5月、Gemini APIにイベント駆動型Webhookを正式追加した。長時間AIジョブの完了通知をプッシュ型で受け取れるようになり、エンジニアが長年悩まされてきた「ポーリング地獄」が解消される。エージェント型ワークフローが普及するなか、このインフラ整備は実務面で見逃せないアップデートだ。

ポーリング問題——なぜこれが辛かったのか

AIパイプラインで数千件のプロンプトを一括処理したり、Deep Researchのような深い調査を走らせたりすると、処理時間は数分から数時間に及ぶ。従来はGET /operationsを定期的に叩いてジョブの完了を確認するしかなかった。

この「ポーリング」方式には3つの問題がある。

  • コスト増大: 数時間にわたって数秒ごとにAPIを叩き続けるとAPIクォータとコンピュートリソースを無駄に消費する
  • レイテンシ: ジョブが完了した瞬間ではなく「次のポーリングタイミング」でしか通知を受け取れない
  • スケーラビリティ: 並列ジョブ数が増えるほど問題が指数的に悪化する

Webhookの仕組み——プッシュ型への転換

Webhookはこの問題を概念的にシンプルな方法で解決する。「ジョブが終わったか？」と繰り返し聞く代わりに、ジョブが完了した瞬間にGemini APIがあなたのサーバーにHTTP POSTを投げる方式だ。

2つの設定モード

実装は「スタティック」と「ダイナミック」の2モードで構成される。

スタティックWebhookはプロジェクトレベルの設定で、WebhookService APIで一度登録すると以後すべての対象イベントに適用される。Slackへの通知やデータベースへの同期など、全体共通の処理に向いている。

ダイナミックWebhookはリクエストレベルのオーバーライドで、特定のジョブ呼び出しにwebhook_configペイロードでURLを渡す方式だ。エージェントオーケストレーションで「このジョブだけ別のキューに送りたい」という細かい制御が可能になる。さらにuser_metadataフィールドでキーバリュー形式のメタデータをジョブに付与できるため、{"job_group": "nightly-eval", "priority": "high"}のような情報を通知と一緒に受け取れる。

セキュリティアーキテクチャ

セキュリティ面ではStandard Webhooks仕様に準拠している点が重要だ。すべてのリクエストはwebhook-signature・webhook-id・webhook-timestampヘッダーで署名され、冪等性の保証とリプレイアタック防止が標準で組み込まれている。

スタティックWebhookはHMAC（Hash-based Message Authentication Code）による対称鍵署名を採用。ただし署名シークレットは作成時の1回しか表示されないため、環境変数に安全に保存することが必須だ。紛失した場合はローテーションが必要になる。

24時間の自動リトライ保証も備えており、サーバーが一時的にダウンしていても通知が失われない設計になっている。

実務への影響

バッチ処理の設計が楽になる: 夜間に大量のプロンプト処理を走らせ、朝イチで結果を確認するパターンが、ポーリングループを書かずに実現できる。Webhookエンドポイントを立ててSlackに通知を飛ばすだけで、完了確認のインフラが整う。

エージェントオーケストレーションに直接使える: 複数のAIエージェントが連携するワークフローでは、前段の処理完了を後段に伝えるトリガーが必要だ。ダイナミックWebhookとuser_metadataを組み合わせれば、専用のジョブトラッキング層を別途構築しなくても実現できる。

Standard Webhooks準拠の安心感: 業界標準仕様に乗っかっているため、既存のWebhookライブラリやミドルウェアがそのまま使える。独自実装を検証する手間が省ける。

筆者の見解

AIエージェントが実用になるかどうかの分岐点は、「単発の指示→応答」から脱却できるかどうかにある。自律的に判断・実行・検証を繰り返すループを回すには、ジョブの完了を確実かつ効率的に検知できるインフラが不可欠だ。その意味でこのWebhook対応は、エージェント基盤として当然あるべき機能が揃ってきたことを示している。

Standard Webhooks仕様への準拠は評価したい。業界標準に乗ることは「車輪の再発明をしない」という正しい判断で、24時間リトライ保証も本番運用を意識した設計だ。

一方で、このようなインフラ整備は「やっと当たり前のところに来た」という見方もできる。イベント駆動アーキテクチャは既に成熟した設計パターンであり、AI APIがこれを持つのは当然の進化といえる。

重要なのは「Webhookが追加された」こと自体より、これを使いこなす設計力だ。ポーリングをWebhookに置き換えるだけでなく、エージェントループ全体の設計を見直す契機として捉えてほしい。エンドポイントの冗長化、リトライ時の冪等性保証、メタデータを使ったルーティング設計——こうした要素をきちんと組み込んで初めて、エージェントが「ちゃんと動く仕組み」になる。AIを単なる「便利ツール」から「自律して動く仕組み」へ昇華させるために、インフラ層の設計にも目を向けてほしい。

出典: この記事は Google Adds Event-Driven Webhooks to the Gemini API, Eliminating the Need for Polling in Long-Running AI Jobs の内容をもとに、筆者の見解を加えて独自に執筆したものです。