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

途中で失敗したエージェントの副作用を巻き戻す — 補償トランザクション設計の実装メモ

Antigravity のエージェントに複数の外部システムをまたぐ作業を任せると、途中の一段が失敗したときに半分だけ世界が書き換わって残ります。やり直しでは直らないこの状態を、補償トランザクション(Saga)で安全に巻き戻す設計を、TypeScript の実装と実運用の数値つきで整理しました。

Antigravity338AIエージェント36補償トランザクション信頼性設計8本番運用17

プレミアム記事

6本のアプリを個人で並行運用していると、リリース作業は「ひとつのボタン」では終わりません。AdMob のメディエーション設定を更新し、App Store Connect のメタデータを差し替え、Remote Config のフラグを上げ、最後に告知用の短い投稿を下書きする。2014年から手で回してきたこの一連の流れを、Antigravity のエージェントに束ねて任せ始めたのが今年の春でした。

最初の数回は気持ちよく回りました。問題が起きたのは、ある木曜の深夜です。AdMob 設定の反映は成功し、Remote Config のフラグも上がったのに、App Store Connect のメタデータ更新が API のレート制限で 4 本目のアプリの途中で止まりました。エージェントは素直に「失敗しました」と報告して停止しました。誠実な挙動です。けれど私の手元には、広告設定だけが新しく、ストア表記は半分だけ新しく、フラグはもう新機能を有効にしているという、どこにも存在してはいけない中間状態が残りました。

ここでエージェントに「もう一度やって」と言うのは危険です。冪等でない操作を二度実行すれば、すでに成功した AdMob 設定をもう一度書き換え、二重に課金イベントを発火させかねません。やり直し(リトライ)では直らない壊れ方があるのです。必要なのは、成功してしまった副作用を意図的に取り消す仕組み ―― 分散システムでいう補償トランザクション(Saga パターン)でした。

なぜ「リトライ」では足りないのか

エージェントの信頼性設計というと、まずリトライと冪等性キーが思い浮かびます。私も以前、冪等性キーで重複実行を抑える記事を書きました。けれどあれは「同じ操作を二度送っても一度しか効かない」ための仕組みであって、「複数の異なる操作のうち一部だけ成功した状態を畳む」ための仕組みではありません。

多段の副作用には、3つの状態があります。

  1. 全段成功 ―― 何もしなくてよい
  2. 全段失敗(最初の一歩も踏み出していない) ―― リトライで足りる
  3. 部分成功 ―― ここが本題。前に進めて完成させるか、後ろに戻して無かったことにするか、判断が要る

リトライが守ってくれるのは 2 だけです。3 の部分成功は、放置すると「半分だけ新しい世界」が本番に固着します。エージェントは止まったことを報告できても、止まった地点より前で起きた副作用までは勝手に片付けません。そこを設計で埋める必要があります。

補償アクションが満たすべき4条件

Saga の核は、各ステップに「順方向の操作(do)」と「巻き戻しの操作(undo=補償)」を対で持たせることです。補償アクションは普通の関数より制約が厳しく、私は次の4条件を満たさないものは補償として認めない運用にしています。

  • 冪等であること ―― 補償自体が途中で失敗して再実行されても、二重に取り消さない。「フラグを false にする」は冪等ですが、「カウンタを 1 減らす」は冪等ではありません
  • 順方向の前提に依存しないこと ―― 「do が完全に終わっている」と仮定しない。do が途中まで進んで失敗した地点からでも安全に呼べる
  • 可観測な完了条件を持つこと ―― 補償が「効いた」ことを、推測ではなく確認できる(フラグの再取得、メタデータの再読み込みなど)
  • それ自体が新たな部分失敗を生まないこと ―― 補償が複数の副作用を持つなら、その補償もまた Saga である

4つ目が現場では一番きつい制約です。「App Store メタデータを元に戻す」補償が、実は「メタデータ更新+スクリーンショット差し戻し」の2段だったりするからです。

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

この記事の続きを読む

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

この記事で得られること
外部API・ストア・課金をまたぐ多段作業で「3段目が失敗して1・2段目だけ世界に残る」部分失敗を、前進回復と補償(後退)の2軸で安全に収束させる Saga オーケストレータを TypeScript でそのまま組める
6アプリ並行の iOS 更新で実際に起きた「AdMob 設定だけ反映され、App Store メタデータが半分で止まった」事故を題材に、補償アクションが満たすべき4条件と、巻き戻しても安全な操作・できない操作の線引きが分かる
補償の冪等性・補償不能ステップの前倒し・部分失敗の検知時間(私の運用で平均 90 秒 → 8 秒)まで、過剰設計で運用を重くしない実数値で決められるようになる
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

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

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

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

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

関連記事

Agents & Manager2026-06-30
Android CLI が3倍速・トークン7割減になったとき、増やすべきは並列数ではなく1件あたりの検証だった
Android CLI のエージェントが3倍速・トークン約7割減になった、というニュースを見て最初に考えたのは「では何本同時に走らせようか」でした。けれど速くなって本当に変わるのは生産量ではなく、詰まる場所です。レビューと検証ゲートに移ったボトルネックを Little's Law で見積もり、WIP キャップで並列数を抑え、浮いた予算を1件あたりの検証に回す設計を、動く Python 実装と実測値でまとめました。
Agents & Manager2026-06-03
やり直せる操作とやり直せない操作を分けて任せる — 可逆性で自律度を決めるエージェント設計
Antigravity のエージェントに本番作業を任せるとき、賢さより先に効いてくるのは「その操作をあとから取り消せるか」です。操作を可逆性で3階層に分け、自動実行・チェックポイント付き実行・人間ゲートへ振り分ける設計を、TypeScript の実装と6アプリ並行運用の実測値つきで整理しました。
Agents & Manager2026-05-31
自律エージェントの流量を制御する — バックプレッシャーと待ち行列で本番を壊さない設計
Antigravity のエージェントを複数同時に走らせると、賢さより先に「下流が捌けない」問題にぶつかります。同時実行数・到着レート・処理能力の3つで流量を捉え、待ち行列・セマフォ・トークンバケット・バックプレッシャーで本番を守る設計を、TypeScript の実装と実測値つきで整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →