GEMINI LABEN
API — Event-driven WebhooksでBatch APIや長時間処理の完了を通知受信。ポーリングが不要になりますSEARCH — File Searchがgemini-embedding-2に対応し、画像もネイティブに埋め込み・検索できますSECURITY — 6/19以降、未制限APIキーからのリクエストが遮断されました。キー制限の点検をMODEL — Gemini 3.5 Flashが一般提供。gemini-flash-latestの本体になりましたAGENT — Managed AgentsがGemini APIで公開プレビュー。隔離サンドボックスで自律エージェントを実行できますDEPRECATED — 画像プレビュー2モデルが6/25で停止。preview依存の処理は確認しておきましょうAPI — Event-driven WebhooksでBatch APIや長時間処理の完了を通知受信。ポーリングが不要になりますSEARCH — File Searchがgemini-embedding-2に対応し、画像もネイティブに埋め込み・検索できますSECURITY — 6/19以降、未制限APIキーからのリクエストが遮断されました。キー制限の点検をMODEL — Gemini 3.5 Flashが一般提供。gemini-flash-latestの本体になりましたAGENT — Managed AgentsがGemini APIで公開プレビュー。隔離サンドボックスで自律エージェントを実行できますDEPRECATED — 画像プレビュー2モデルが6/25で停止。preview依存の処理は確認しておきましょう
記事一覧/API / SDK
API / SDK/2026-06-28上級

完了したはずの Gemini ジョブが『実行中』に戻った — Webhook の順序入れ替わりを止める単調適用の設計

Gemini の長時間オペレーションを Webhook で受けると、古い『実行中』イベントが完了後に届いて状態を巻き戻します。状態に順位を与え、後退する更新を捨てる単調適用のリデューサーを実装します。

gemini90webhook3long-running-operationsproduction98

プレミアム記事

ある朝、夜間バッチの管理画面を開くと、前夜に公開まで終わっていたはずのジョブが「実行中」に戻っていました。再公開が走った形跡もあり、最初はジョブ自体が再実行されたのかと疑いました。けれど操作台帳をたどると、ジョブは確かに前夜のうちに SUCCEEDED を受け取っていて、その 40 分後に古い RUNNING のイベントがもう一度届いていたのです。受け口は素直に state = event.state と上書きしていたので、完了が実行中へ巻き戻りました。

個人開発で夜間バッチを回していると、Webhook 移行のあとに残る事故はだいたいこの形をしています。重複(同じ完了が二度来る)でもなく、欠落(イベントが落ちる)でもない。順番が入れ替わって届くという、三つ目の事故です。

巻き戻りは「重複」でも「欠落」でもない、三つ目の事故

Webhook 移行の文脈では、重複と欠落はよく語られます。重複は完了イベントを実質1回にする冪等な受け口で、欠落は長時間オペレーションを照合で二重化する設計で扱いました。どちらも「同じ状態を二度処理しない」「来なかった状態を拾い直す」ための話です。

順序の入れ替わりはそのどちらでもありません。イベントは一度ずつ、正しく署名された本物として届きます。ただ到着順がオペレーションの進行順と一致しないだけです。PENDING → RUNNING → SUCCEEDED と進んだジョブに対して、受け口が SUCCEEDED → RUNNING の順で受け取ることが起こります。冪等キーで弾こうとしても、二つは別のイベントなので重複としては落ちません。照合ポーラーで拾い直そうとしても、欠落ではないので拾う対象がありません。順序は、専用の防ぎ方が要ります。

なぜ Webhook は順序を保証しないのか

Gemini の Webhook は、Batch API や長時間オペレーションの完了をイベントで届けてくれます。配送のモデルは at-least-once(最低1回)で、順序保証は前提に含まれません。順番が崩れる経路は、いくつも重なります。

受け口が一瞬 5xx を返すと、その更新は後で再配送されます。その間に次の更新が先に通れば、再配送された古いイベントは新しいイベントの後ろに回ります。配送が並列なら、ネットワークの揺らぎだけで前後が入れ替わります。デプロイの瞬間に取りこぼした分を照合ポーラーが拾い直すと、Webhook と照合の二経路から、別の鮮度のイベントが時間差で合流します。

つまり順序の入れ替わりは「たまの不運」ではなく、at-least-once と二経路化を選んだ時点で構造的に入ってくる前提です。受け口の側で、後退する更新を見分けて捨てる責任を持つしかありません。

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

この記事の続きを読む

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

この記事で得られること
完了済みのジョブが古いイベントで『実行中』へ巻き戻る原因を、重複・欠落とは別の事故として切り分けられるようになる
状態に順位を与える格子と updateTime によるフェンシングで、後退する更新だけを安全に捨てる単調適用のリデューサーをコピペで導入できる
Webhook ハンドラと照合ポーラーを同じリデューサーに通し、終端状態が二度と崩れない受け口へ作り替えられる
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

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

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

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

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

関連記事

API / SDK2026-06-23
File Search のストアが本番で静かに陳腐化する — カタログ同期とドリフト検知を実装した運用メモ
File Search に一度カタログを流し込んで終わりにすると、配信を止めたアセットを案内する『古い回答』が本番で返り始めます。ハッシュ差分の増分取り込みと、削除を割り切るブルーグリーン再構築、そして定期ドリフト検知までを実装で整理しました。
API / SDK2026-06-17
Flash と Pro のルーティングしきい値を、シャドウ再評価で較正し続ける
Flash で生成し、自信のないものだけ Pro に回すルーターは、しきい値を手で決めた瞬間から少しずつ古くなります。サンプリングしたシャドウ再評価で不一致率を測り、しきい値を品質予算から逆算して較正し続ける仕組みを、動くコードで組み立てます。
API / SDK2026-06-16
既定モデルが上がっても折れない — Gemini 呼び出しに起動時の能力検出レイヤーを挟む設計
モデル名のピン留めも既定への依存も、どちらも静かに折れます。いま実際に届いているモデルが何をできるのかを起動時に確かめ、その結果でリクエストを組み立て直す能力検出レイヤーの設計と、コピペで動く Python を残します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →