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

並列エージェントが同じタスクを二度実行して請求が膨らんでいたとき — 重複を計測して止める運用メモ

並列エージェントの請求が想定の約1.9倍に膨らんでいたのは、複数のワーカーが同じタスクを二重に実行していたからでした。重複を計測し、冪等キーで先取り予約し、コストをタスク単位に帰属させるまでの運用記録です。

マルチエージェント40冪等性8コスト管理9本番運用17Antigravity313

プレミアム記事

月末の請求を開いて、指が止まりました。処理件数はほぼ横ばいなのに、金額だけが想定の約1.9倍。障害アラートは一度も鳴っていません。ログを追っても、どのリクエストも正常終了しています。

原因にたどり着くまで半日かかりました。並列に走らせていた3体のワーカーのうち、2体が同じタスクを別々に拾い、どちらも「自分の仕事だ」と判断して最後まで実行していたのです。結果は同じなので出力は正しく見える。けれど裏では、生成トークンの課金が静かに二重に積み上がっていました。

この記事は、その「沈黙する二重実行」を計測で捕まえ、冪等キーで止め、コストをタスク単位に帰属させるまでの運用記録です。Antigravity の Managed Agents のように、複数エージェントへタスク群を委譲する構成を前提にしています。特定の SDK に依存しない層として組んだので、Gemini API でも自作のワーカーでも移植できます。

なぜ重複は「エラーにならず」に起きるのか

二重実行が厄介なのは、例外を投げないことです。両方のワーカーが成功し、両方が正しい結果を返す。オーケストレーターは後着の結果を捨てるか上書きするだけで、二度走った事実はどこにも残りません。

根っこにあるのは、LLM が「自分の担当ではないこと」を明示的に断らない性質です。これは並列構成に特有の落とし穴で、プロンプトの手直しだけでは根本的な対処になりません。責任範囲をあいまいに書くと、複数のワーカーが同じ依頼を自分事として引き受けてしまいます。

症状見えること見えないこと
二重実行出力は正しい・エラーなし同じタスクへの課金が2回発生
取りこぼし件数が合わないどのワーカーも「担当外」と判断して放置
ループレイテンシ増境界の押し付け合いで往復が発生

まず効いたのは、ワーカーの責任範囲を「やること」ではなく「やらないこと」まで書き切ることでした。

# ❌ 境界があいまい(重複・取りこぼしの温床)
あなたはデータ処理エージェントです。必要に応じてレポートも作成してください。
 
# ✅ 担当外を明示し、越境時は差し戻す
あなたは「JSON→スキーマ変換」専任のワーカーです。
担当: 受け取った JSON を指定スキーマへ変換して返す。
担当外: 保存・送信・レポート生成・他ワーカーの再依頼。
担当外の入力が来たら本文を返さず {"status":"out_of_scope"} だけを返し、
オーケストレーターへ差し戻すこと。自分で肩代わりしないこと。

ただしプロンプトの明確化は「起きにくくする」対策にすぎません。ゆらぎのある相手が並列で動く以上、構造として二重実行を止める仕組みが要ります。

重複を「見える化」する実行台帳

止める前に、まず数えます。どのタスクが何回実行されたのかを記録しなければ、対策の効果も判定できません。

鍵になるのはタスクの同一性をどう定義するかです。私は入力の意味的な本体(正規化した引数)からフィンガープリントを作りました。タイムスタンプや実行 ID のような「毎回変わる値」を除いて正規化するのがポイントです。

import hashlib
import json
import time
 
def task_fingerprint(task_type: str, payload: dict) -> str:
    """実行のたびに変わる値を除いて、タスクの意味的な同一性を鍵にする。"""
    volatile = {"request_id", "timestamp", "attempt", "trace_id"}
    stable = {k: v for k, v in payload.items() if k not in volatile}
    # キー順を固定して安定なハッシュにする
    canonical = json.dumps(stable, sort_keys=True, ensure_ascii=False)
    digest = hashlib.sha256(f"{task_type}:{canonical}".encode()).hexdigest()
    return digest[:16]
 
 
class ExecutionLedger:
    """タスクごとの実行回数を記録する台帳。store は Redis 等の KV を想定。"""
 
    def __init__(self, store):
        self.store = store  # get/incr/expire を持つ薄いラッパ
 
    def record(self, fp: str, worker_id: str) -> int:
        key = f"ledger:{fp}"
        count = self.store.incr(key)          # 実行回数を加算
        self.store.expire(key, 60 * 60 * 24)  # 24時間で自然に流す
        self.store.sadd(f"{key}:workers", worker_id)
        return count  # 2 以上なら、そのタスクは重複実行されている

これを本番に差し込んで一週間ほど回すと、重複率が見えてきました。全タスクの約18%が2回以上実行されていて、そのほとんどが特定の2つのタスク種別に集中していました。数える前は「たまに起きる程度」だと思っていたので、この18%という数字は素直に驚きでした。

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

この記事の続きを読む

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

この記事で得られること
タスクフィンガープリントで二重実行を検知する実行台帳の実装
SET NX による冪等キーの先取り予約(claim-before-run)で二重課金を止めるパターン
エージェント・タスク単位のコスト帰属で請求異常を早期に捕まえる計測手順
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

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

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

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

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

関連記事

Agents & Manager2026-04-23
Antigravity AgentKit 2.0 で作る本番マルチエージェント — 実戦で使える設計パターンと落とし穴
AgentKit 2.0 の Planning / Fast モードの使い分けから、Orchestrator-Worker 構成・状態管理・コスト制御・プロンプトインジェクション対策まで、実運用で詰まるポイントを設計パターン単位で整理しました。
Antigravity 基本2026-04-25
Antigravity の Retry を本番品質で設計する — 冪等性・バックオフ・コスト上限・失敗トリアージ
Antigravity エージェントの Retry を趣味レベルから本番品質に引き上げるための設計図。冪等性、指数バックオフ、コスト上限、失敗トリアージ、チェックポイント連動、チームでのポリシー運用まで、実装コードを添えて全工程を解説します。
Agents & Manager2026-06-30
Android CLI が3倍速・トークン7割減になったとき、増やすべきは並列数ではなく1件あたりの検証だった
Android CLI のエージェントが3倍速・トークン約7割減になった、というニュースを見て最初に考えたのは「では何本同時に走らせようか」でした。けれど速くなって本当に変わるのは生産量ではなく、詰まる場所です。レビューと検証ゲートに移ったボトルネックを Little's Law で見積もり、WIP キャップで並列数を抑え、浮いた予算を1件あたりの検証に回す設計を、動く Python 実装と実測値でまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →