AIエージェントの子タスク6本の同時実行は1本ずつより55秒遅かった

本記事の概要

コードの課題を解くAIエージェントの子タスクを同時に流すと、全部が最後まで終わっても、全体の所要時間が1本ずつ流した合計より長くなる回があった。レート制限の429は、AIモデルを呼んでコードの課題を解くハーネスの出力に現れなかった。終わった子タスクの数とハーネスの出力のどちらを見ても、全体の所要時間が延びたことも429も分からなかった。

6本同時の全体の所要時間は280.1秒で、同じ6課題を1本ずつ流した所要時間の合計は225.0秒だった。短い文を返す子タスクを12本同時に流した回では、93件のリクエストのうち65件に429が返った。この回で各子タスクの標準エラーの末尾300字とエラーの文字列を検索すると、レート制限の表示が見つかった子タスクは12本のうち0本だった。

6本同時の回はリクエストごとのHTTPステータスを記録していないので、429が返ったかも、429の後の待ちが何秒かも分からない。全体の所要時間は各1回だけ測った値で、前の回の影響は分けていない。同時の本数を1本か2本に制限したときに429が無くなるかも、記録からは分からない。

記事から得られること

AIエージェントの子タスクを並列に流す仕組みを作る人に向けた記事である。

• 同時に流した全体の所要時間と、1本ずつ流した合計を、表で比べる。
• 所要時間の比の中央値8.21倍が、課題ごとにどう分かれていたかを示す。
• 出力に現れない429を、リクエストごとの記録で観測した結果を、経過の区間で分けた表で示す。
• 同時の上限を3本にする案と、起動の時刻をずらす案を、開発を一緒に進めるAIが採らなかった根拠を書く。

本文の根拠は、私が進めている取り組みの実行記録と設計文書である。

全部の子タスクが最後まで終わっても1本ずつ流した合計より長い全体の所要時間

私は、開発を一緒に進めるAIとともに、コードの課題を解くプログラムを同時に流して、全体の所要時間を測った。2026年9月の回では、全部の課題が最後まで終わっても、全体の所要時間が1本ずつ流した合計より長かった。2026年10月の回では、レート制限の429が、そのプログラムの出力に現れなかった。

この記事で使う語は、次のとおりである。

• ハーネス: AIモデルを呼び、ツールを実行してコードの課題を解く、コマンドラインのプログラム
• 実行機: 複数の子タスクを起動して結果を集める、自作のプログラム
• 子タスク: 実行機がハーネスを1回起動して解かせる、1つの仕事
• 重い子タスク: ツールを繰り返し呼んでバグ修正や実装の課題を解くので、エンドポイントへ送るリクエストの数が多く、本文も大きい子タスク
• 計測用のプログラム: 実行機とは別の、子タスクを同時に起動して所要時間を測るプログラム

計測用のプログラムで重い子タスクを3本同時と6本同時で流した結果は、次の表である。

6本同時の回は、1本ずつ流した合計より55.1秒長かった。どちらの回も全部の課題が最後まで終わったので、終わった課題の数からは差が分からなかった。同時に流しても全体の所要時間が短くならなかったので、開発を一緒に進めるAIは、実行機が同時に起動する子タスクの本数を、既定値の1のままにすると判断した。

55.1秒の差は、各1回の計測を比べた値である。3本同時、6本同時、1本ずつの3つの計測は間を置かずに続けたので、前の計測のレート制限の影響は切り分けていない。

所要時間の比の中央値8.21倍の読み方

課題ごとに、同時に流したときの所要時間を1本ずつ流したときの所要時間で割った値を、所要時間の比と呼ぶ。重い子タスクを6本同時に流した回では、この比の中央値が8.21倍だった。ただし、課題ごとの比は0.50倍から21.71倍まで分かれ、全部の課題が8.21倍遅くなったわけではない。

同時の本数で比べると、6本同時は中央値も最大も3本同時より大きい。

8.21倍は6課題の中央の2つの平均で、どの課題の比でもない。1本ずつの所要時間は課題ごとに1回だけ測ったので、その1回が外れ値だと比も大きく動くが、外れ値かどうかは確かめられない。2026年9月の2つの回はリクエストごとのHTTPステータスを記録していないので、429が返ったかも、429の後の待ちが何秒かも分からない。

ハーネスの出力に現れない429

計測用のプログラムがハーネスの出力を検索しても、レート制限や再試行の表示は見つからなかった。一方で、ハーネスとエンドポイントの間でリクエストごとのHTTPステータスを記録する手元のプロキシには、429が残っていた。

短い文を1行だけ返し、ツールを使わない子タスクを、1往復の子タスクと呼ぶ。2026年10月にこれを12本同時に流した回では、12本の全部が429を2回以上受けてから完了した。レート制限の表示があった子タスクは、12本のうち0本だった。検索した範囲は、標準エラーの末尾300字とエラーの文字列だけである。

重い子タスクの回では、計測用のプログラムが標準出力と標準エラーの全文から、429、rate limit、quota、retry、backoffなどの文字列を探した。2026年9月の2つの回でも、9件の429が返った2026年10月の3本の回でも、これらの文字列は出力に無かった。

短いリクエストの同時送信と1往復の子タスクの429

計測用のプログラムがハーネスを通さずにエンドポイントへ短いリクエストを同時に送ると、6件、8件、10件の回には429が無く、12件の回で12件のうち2件が429だった。リクエストは1と1の足し算を問う内容で、回と回の間は120秒空けた。

短い文を1行だけ返す1往復の子タスクでは、同時の本数が増えると、429と全体の所要時間が増えた。表の値は、120秒以上の間を置いて流した各1回の計測である。

6本同時に流した回では、全体の所要時間が最も遅い1本で決まった。429を4回受けた子タスク1本が90.2秒かかり、429を受けなかった4本は6.8秒から13.6秒で終わった。6件の429のうち残る2件は、ほかの1本が受けた。

1往復の子タスクの遅さは、429だけでは説明できない。子タスクの所要時間から、手元のプロキシが記録したリクエストの所要時間の合計を引くと、429が0件だった3本の回でも、子タスクごとに13秒が残った。2秒待って固定の応答を返す手元のモックのサーバへ向けた3本の回では、残りは1.6秒だった。12本の回では、200が返ったリクエストが最長54.6秒かかった。13秒と1.6秒の差の理由と、54.6秒かかった理由は分かっていない。

エンドポイントがレート制限に使うウィンドウの長さと、上限のリクエスト数は、この計測では分からない。429は、利用者が一定の時間に多すぎるリクエストを送ったことを示す応答である。定義はRFC 6585にある。

重い子タスク3本のリクエストごとの記録

2026年10月に重い子タスク3本を同時に流した回では、最初のリクエストから9秒までに送った11件に全部200が返り、最初の429は13秒後の12件目だった。24件のリクエストを経過の区間で分けると、9件の429はどれも13秒から22秒までにある。

この回では、最初の起動から85.0秒で、3課題が全部最後まで終わった。配列のバグ修正の課題では、ハーネスが16秒後までに429を4回受けた後、61秒間リクエストを送らず、77秒後のリクエストで200を受けた。

同じ3課題を1本ずつ流した合計は100.8秒で、85.0秒より長い。ただし、この合計は、2026年9月に課題ごとに1回だけ測った値である。文字列処理の課題は、1本ずつ流したときが74.5秒で、2026年10月の3本の回では28.0秒だった。同じ課題の所要時間がこれだけ違うので、開発を一緒に進めるAIは、100.8秒との差から速くなったとは言えないと判断した。

同時の上限を3本にする案と起動の時刻をずらす案

開発を一緒に進めるAIは、重い子タスク3本でも429が出たので、同時の本数を3本までに制限する規則を採らなかった。起動の時刻を1秒ずつ遅らせる仕組みも実装しなかった。最初の429は起動の直後でなく13秒後で、起動をずらしても13秒後より後のリクエストどうしの間隔は変わらないと見込んだからである。この見込みは測っていない。

重い子タスクのリクエストは24件のうち21件の本文が105KBから113KBと大きいが、エンドポイントの上限がリクエストの数だけで決まるか、トークンの量でも制限されるかは、この計測では切り分けていない。重い子タスクを1本か2本だけ同時に流した回は測っていないので、同時の本数を制限したときに429が無くなるかも分からない。HiveMindの論文は、同じAPIを共有するエージェントの競合をHTTPプロキシで調整する方法を、主にモックのAPIサーバで評価したので、この計測の値とは比べられない。

遅さの原因をエンドポイントと断定した最初の文書の根拠不足

2026年9月の計測の後に、開発を一緒に進めるAIは、遅さの原因はエンドポイントだと、3つの文書で断定した。その後の一次レビューが根拠の不足を指摘したので、AIは3つの文書を、記録から判定できないという文に修正した。同じ指摘を受けて、AIは計測用のプログラムも修正し、ハーネスの出力を読めないときは判定をせずに止まるようにした。

参考にした資料

• RFC 6585 Additional HTTP Status Codes https://www.rfc-editor.org/rfc/rfc6585.html

参考にした研究

• HiveMind: OS-Inspired Scheduling for Concurrent LLM Agent Workloads: 主な評価はモックのAPIサーバで行われ、モックのエージェントは回復できないエラーで止まる。この記事の計測では、全部の子タスクが最後まで終わった。