ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-05-31上級

自律エージェントの流量を制御する — バックプレッシャーと待ち行列で本番を壊さない設計

Antigravity のエージェントを複数同時に走らせると、賢さより先に「下流が捌けない」問題にぶつかります。同時実行数・到着レート・処理能力の3つで流量を捉え、待ち行列・セマフォ・トークンバケット・バックプレッシャーで本番を守る設計を、TypeScript の実装と実測値つきで整理しました。

Antigravity338AIエージェント36本番運用17バックプレッシャー信頼性設計8

プレミアム記事

個人で 5,000万DL 規模のアプリ事業と4つの技術ブログを回していると、エージェントに任せたい仕事はどんどん増えていきます。記事の下書き生成、多言語リリースノートの整合、AdMob のメディエーション設定の比較、Crashlytics で見つかった同型クラッシュのまとめ修正。2014年からほとんど手で回してきた作業ほど、自動化したい気持ちが強くなります。

ところが、Antigravity のエージェントを「数を増やせば速くなるはず」と素朴に並列で走らせ始めた頃、私は速さではなく詰まりに悩まされました。4サイトそれぞれに記事生成エージェントを立て、同時に6本のアプリ運用エージェントも動かしたところ、GitHub への push、Cloudflare のデプロイ、AdMob コンソールの操作、Stripe の参照が一斉に集中し、下流が次々と 429 を返し始めたのです。エージェント自体は正しく動いていました。壊れたのは、エージェントが仕事を生み出す速さに、下流が捌ける速さが追いつかなかったことでした。

このとき痛感したのは、エージェント運用で先に効いてくるのは賢さではなく 流量(throughput/単位時間あたりに流れる仕事の量) の制御だということです。賢いエージェントを10体並べても、下流の処理能力が毎秒1件なら、残りの9体分の仕事はどこかに溜まるか、捨てられるか、エラーになります。ここでは、流量を構造的に制御して本番を壊さないための設計を、実装とともに整理します。

なぜ「賢さ」より先に流量が問題になるのか

エージェントを1体で動かしているうちは、流量はまず問題になりません。1体が直列に仕事をするので、下流が受け取る仕事も自然と直列になります。問題が顔を出すのは「速くしたい」と思って並列度を上げた瞬間です。

並列化はエージェントの数を増やすだけで簡単に実現できてしまいます。けれども下流——外部 API、データベース、課金システム、コンソール操作——の処理能力は、こちらの都合で増えてくれません。AdMob コンソールは1秒間に何十回も操作できませんし、GitHub の API にはレート制限があり、Stripe にも秒間リクエスト上限があります。エージェントの数を2倍にしても、下流が同じなら、捌けない仕事が2倍のスピードで積み上がるだけです。

私が最初にぶつかったのは、まさにこの非対称でした。記事生成エージェントを4体に増やした日、生成そのものは速くなったのに、push 段階で 429 が多発し、リトライが重なって結果的に1体で回していた頃より遅くなりました。流量を制御しないまま並列度だけ上げると、速くするつもりが遅くなる——これは直感に反しますが、待ち行列理論が予測する通りの結果です。

流量を3つの数字で捉える

「詰まって困る」は感想であって設計にはなりません。流量制御を始める前に、流れを測る物差しを3つ決めます。私は次の3軸で考えています。

  • 到着レート(arrival rate): 単位時間あたりにエージェントが生み出す仕事の件数。記事生成なら「毎分何本の push 要求が発生するか」
  • 処理能力(service rate): 下流が単位時間あたりに捌ける件数。GitHub API なら「秒間いくつのリクエストまで 200 が返るか」
  • 同時実行数(concurrency): いま下流に対して同時に進行している仕事の数。「いま何件の push が in-flight か」

この3つの関係はシンプルです。到着レートが処理能力を継続的に上回ると、待っている仕事は無限に増えます。 一時的に上回るだけなら、待ち行列が吸収してくれます。だから流量制御の本質は「到着レートを処理能力以下に整える」ことと、「一時的な超過を安全に吸収する」ことの2点に尽きます。

数字の取り方は難しくありません。到着レートはエージェントのスケジューラが知っています。処理能力は下流のレート制限ドキュメントに書かれているか、429 が返り始める閾値を実測すれば分かります。同時実行数は、後で作るキューが数えてくれます。

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

この記事の続きを読む

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

この記事で得られること
複数の自律エージェントを「待ち行列 → セマフォで同時実行数制限 → トークンバケットでレート整形 → バックプレッシャー → デッドレター」の順に並べ、下流の429やコスト急増を構造的に防ぐ流量制御をTypeScriptでそのまま組める
4サイト×1日4本の記事生成と6アプリのバックグラウンド運用を並行させた実体験から、「到着レートが処理能力を超えた瞬間に何が壊れるか」を具体的な数字で示します
同時実行数の上限・トークンバケットの補充レート・キューの上限長・あふれた仕事の退避先を、過剰防御で生産性を殺さない実数値で決められるようになる
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-06-01
途中で失敗したエージェントの副作用を巻き戻す — 補償トランザクション設計の実装メモ
Antigravity のエージェントに複数の外部システムをまたぐ作業を任せると、途中の一段が失敗したときに半分だけ世界が書き換わって残ります。やり直しでは直らないこの状態を、補償トランザクション(Saga)で安全に巻き戻す設計を、TypeScript の実装と実運用の数値つきで整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →