Antigravity 2.0 が「エディタ」から「複数のエージェントを束ねて走らせる基盤」へ性格を変えてから、個人開発でも「あるエージェントが実装し、別のエージェントがテストを回す」という並行運用が現実的になりました。
ただ、並列化できることと並列化すべきことは別の話です。私自身、4つのサイトの記事生成と検証を回していて、何でも並列にした時期がありましたが、かえって遅く・読みにくくなった経験があります。ここでは「どこを並列にし、どこを順番のまま残すか」を、感覚ではなくざっくりした見積もりで決める考え方を整理します。
並列化は「速くなる」とは限らない
並列化の直感的なイメージは「3つ同時にやれば3分の1の時間で終わる」です。けれど実際には、同時に走らせるための準備、結果を集める処理、衝突したときの調整が新しく増えます。
つまり並列化は、待ち時間を縮める代わりに、調整コストという別の支出を生みます。縮む時間が増える支出より大きければ得、小さければ損。これだけのことなのですが、見落とすと「並列にしたのに前より遅い」が起きます。本番でこれが起きると原因の切り分けに時間を取られるので、設計の段階で当たりをつけておくのが大切です。
私はまず、対象のタスクが「並列化で縮む時間」と「並列化で増える手間」のどちらが大きそうかを、おおまかに見積もってから設計に入ります。
並列で得をするのは「独立して長い」タスク
並列化が確実に効くのは、2つの条件が揃ったときです。各タスクが互いに依存しないこと。そして1つあたりの実行時間が長いこと。
私の4サイト運用でいえば、サイトごとの記事生成はこの条件にぴったり当てはまります。Claude Lab の記事生成と Gemini Lab の記事生成は互いに何も共有しませんし、1本あたりの生成と検証には相応の時間がかかります。独立していて長い。だからここは並列にして待ち時間を縮める価値があります。
逆に、一瞬で終わる処理を無理に並列化しても、得られる短縮はごくわずかで、起動と集約の手間だけが残ります。並列化の効果は、1タスクの所要時間が長いほど大きくなる、と覚えておくと判断が速くなります。
直列のまま残すべき仕事
一方で、次のいずれかに当てはまるものは、私は原則として直列のまま残すことを推奨します。
前の出力が次の入力になる（依存がある）
同じファイルやリソースに書き込む（衝突する）
失敗したときに途中状態を戻す必要がある（巻き戻しが難しい）
記事の品質ゲートと push の関係が、まさに1番の例です。ゲートを通過したことを確認してから push する、という順序には意味があります。これを並列にして同時に走らせると、ゲートの結果を見る前に push が始まり、違反記事が公開される事故につながります。実際これは過去に踏んだ落とし穴で、それ以来ゲートと push は必ず別の工程として直列に分けて対処しています。
2番の衝突も見落としがちです。複数のエージェントが同じファイルへ書き込むと、後から書いた方が前の変更を上書きします。共有リソースへの書き込みを伴う仕事は、並列の効果より調整コストの方が大きくなりがちです。
損益分岐をざっくり見積もる
厳密な計算は要りません。次の単純な比較で十分です。
並列で縮む時間は、おおよそ「直列で全部やった合計時間」から「一番長いタスクの時間」を引いた分です。N 個のタスクがほぼ同じ長さ t なら、直列は N×t、並列は t に近づくので、縮むのは (N−1)×t あたりになります。増える調整コスト c は、起動の手間、結果を集める処理、衝突を解く手間の合計です。判断は「(N−1)×t が c より大きければ並列」だけです。
この判定は、毎回頭で計算するより小さなスクリプトに任せた方が一貫します。私は次のような関数で、依存・衝突の有無と所要時間から方式を決めています。
def choose_mode (n, t_sec, coord_sec, has_dependency, writes_shared): """並列か直列かを返す。依存・衝突があれば無条件で直列。""" if has_dependency or writes_shared: return "serial" # 安全優先: 損益以前に並列にしてはいけない saved = (n - 1 ) * t_sec # 並列で縮む時間 if saved > coord_sec * 1.5 : # 調整コストに余裕を見て1.5倍で判定 return "parallel" return "serial"
# 例: 記事3本・各5分・調整1分・独立 → 縮み600秒 > 調整90秒 → 並列 print (choose_mode( 3 , 300 , 60 , False , False )) # parallel # 例: 軽い整形3件・各3秒・調整3秒・独立 → 縮み6秒 < 調整4.5秒 → 直列 print (choose_mode( 3 , 3 , 3 , False , False )) # serial 数値を入れてみると分かりやすいです。3本の記事生成で1本5分、起動と集約が合計1分なら、縮むのは10分、増えるのは1分で、明確に並列が得です。逆に1件3秒で終わる軽い処理を3つ並べても、縮むのは6秒で、ほぼ釣り合って旨みがありません。t が小さいほど並列の魅力は薄れます。
4サイト運用での実際の線引き
私の自動運用では、層によって並列と直列を使い分けています。整理すると次のようになります。
処理 方式 理由
4サイトの記事生成 並列 サイト間に依存がなく、1本の生成が長い 1記事内の日本語版と英語版 直列寄り 英語版は日本語版の構成を踏襲するため依存がある 品質ゲート → push 直列 合否を確認してから公開する順序に意味がある 各サイトのログ記録 並列 書き込み先が別ファイルで衝突しない
ここで効いているのは「サイト単位は独立だから並列、記事の中の工程は依存があるから直列」という粒度の分け方です。大きな単位では並列で待ち時間を縮め、その内側の依存のある工程は直列で安全を取る。この二段構えにしてから、運用が速く・壊れにくくなりました。個人開発で一人で回す以上、壊れにくさは速さと同じくらい大切だと感じています。
並列数を上げすぎると逆に遅くなる
最後に、並列なら多いほど良い、という思い込みについて。同時に走らせるエージェントを増やすほど、レート制限やクォータに早く到達します。上限に当たると待たされたり弾かれたりして、結局トータルでは遅くなります。
私はこの点に対して、並列数に上限を設け、それを超える分はキューに積んで順に流すようにしています。体感では、無制限に並べるより、適度な上限で回す方が安定して速いことが多いです。並列度は「2倍にすれば2倍速い」ではなく、どこかで頭打ちになり、その先は逆効果になる、という前提で設計するのが安全です。
並列か直列かは、新しい基盤の機能というより、昔からある「どこまで同時にやるか」という運用判断そのものです。縮む時間と増える手間を天秤にかけ、依存と衝突のあるところは無理に並べない。地味な見積もりですが、複数のエージェントを束ねる時代にこそ効いてくる線引きだと感じています。同じように並行運用を組んでいる方の参考になれば幸いです。