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

A2A のタスクが working のまま静かに滞留していたとき — 状態遷移を計測して詰まりを名指しする運用メモ

Antigravity の A2A 連携は、エラーで落ちるより「タスクが working のまま進まない」形で静かに詰まります。状態遷移を一本の時系列として記録し、滞留したタスクをどのエージェントのどの辺で止まったかまで名指しする監視の実装を、運用の実感とあわせて整理します。

A2A4Antigravity323マルチエージェント41observability16state-machine2python26

プレミアム記事

夜通し走らせたエージェントの連携パイプラインが、朝には「完了タスク 0 件」で止まっていました。ログにエラーは一行もありません。オーケストレータは三つのタスクを送ったまま、いつまでも完了を待ち続けていました。受け手のエージェントは処理を始めた気配すらなく、タスクは working の状態で静かに固まっていたのです。

厄介だったのは、どのエージェントのどこで止まったのかが分からなかったことです。A2A(Agent-to-Agent)の失敗は、例外を投げて派手に落ちるより、状態が進まないまま黙り込む形で現れます。ここでは、その静かな詰まりを状態遷移の時系列として計測し、滞留したタスクを辺の単位で名指しする監視の実装を、個人開発でエージェントを回してきた実感とあわせて整理します。

詰まりは、なぜ静かに起きるのか

A2A のタスクは submitted → working → input-required → completed / failed / cancelled という状態機械で進みます。エラーで落ちるなら failed に遷移し、少なくとも「失敗した」という事実は残ります。ところが実運用で多いのは、failed にすら至らず、非終端状態のまま時間だけが過ぎるパターンです。

私が観測した「静かな詰まり」は、大きく三経路に分かれます。

経路何が起きているか送信側から見える症状
envelope 未達trace_id 欠落や宛先誤りで、そもそも相手にメッセージが届いていないsubmitted のまま working にすら遷移しない
capability 発見漏れ受け手の capabilities に skill が未登録で、discover が候補を返さない送ったつもりが、相手が存在しない扱いになる
task_state 遷移漏れ受け手が処理は終えたのに completed を明示せず応答した処理は済んでいるのに working のまま待たされる

三つとも共通するのは、エラーではなく「遷移が起きない」ことで詰まる点です。だから例外ログをいくら眺めても手掛かりが出てきません。見るべきは「どの状態に、どれだけの時間とどまっているか」という時間軸のほうです。

状態遷移を一本の時系列として記録する

まず決めるのは、監視の単位です。個別のログ行ではなく、タスクごとの状態遷移を一本の時系列として持ちます。各遷移に trace_id・タスクID・エージェント・遷移前後の状態・時刻を残し、状態にとどまった時間(dwell time)を測れる形にします。

記録する項目意味
task_id / trace_idどのタスクの一連の流れか
agentその遷移を起こしたエージェント
from_state → to_state状態遷移の辺。詰まりを名指しする単位
dwell_seconds直前の状態にとどまっていた秒数

肝は、詰まりを「タスク単位」ではなく「辺(from → to)単位」で捉えることです。同じ working 滞留でも、submitted → working が起きないのか、working → completed が起きないのかで、疑う相手がまったく変わります。前者は envelope か discover、後者は受け手の遷移漏れです。辺で見ると、原因の当たりが一段速くつきます。

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

この記事の続きを読む

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

この記事で得られること
A2A の詰まりが静かに起きる三経路(envelope 未達・capability 発見漏れ・task_state 遷移漏れ)を、症状から切り分けます
状態遷移を一本の時系列に記録し、滞留タスクを『どのエージェントのどの辺で止まったか』まで名指しする watchdog を Python 実装で示します
滞留閾値を dwell time の p95 から逆算する決め方と、DAG 構成で追跡を軽くする設計判断を提示します
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

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

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

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

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

関連記事

Agents & Manager2026-04-24
Antigravity A2A プロトコル実装ガイド — エージェント同士が対話する現実的なパターン
Antigravity の A2A(Agent-to-Agent)プロトコルを実装ベースで解説します。2 つのエージェントの間でタスクを委譲・結果を受け取る最小構成から、複数エージェントの長期対話パターンまで、実際に動くサンプル付きで紹介します。
Agents & Manager2026-07-06
並列エージェントが同じタスクを二度実行して請求が膨らんでいたとき — 重複を計測して止める運用メモ
並列エージェントの請求が想定の約1.9倍に膨らんでいたのは、複数のワーカーが同じタスクを二重に実行していたからでした。重複を計測し、冪等キーで先取り予約し、コストをタスク単位に帰属させるまでの運用記録です。
Agents & Manager2026-06-27
自律エージェントの行動を、改ざんを検知できる監査ログに残す
Antigravity のエージェントが自律的に下した判断と実行を、後から追跡・検証できる形で残すために、ハッシュチェーンで改ざんを検知できる追記専用の監査ログを設計する方法を、実装コードとともにまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →