並行で動くエージェントを一枚の画面で眺めていると、速くなった気がしないのです。むしろ手が止まる時間が増えました。Antigravity 2.0 のデスクトップ版を一週間ほど自分の運用に組み込んでみて、いちばん意外だったのがこの感覚でした。モデルが速くなり、同時に三つも四つも走らせられるようになったのに、全体の進みは思ったほど上がらない。理由を突き止めていくうちに、自分の自動運用の組み方そのものを直す必要があると気づきました。今日はその記録です。
これまでは「時刻をずらすこと」で衝突を避けていました
私は Dolice Labs という名前でいくつかの技術サイトを個人で運用していて、記事の下書き生成やリンク切れチェックといった定型作業を、一日のなかの空いた時間に分散させて回していました。早朝にこのサイト、昼前に別のサイト、という具合に時刻をずらしていたのです。
ずらしていた理由は単純で、同じ時間帯に重い処理を重ねるとマシンも自分も詰まるからでした。生成タスクが複数同時に走ると、出てきた結果を確認する自分の側が追いつかない。だから「処理が重ならないように」ではなく、本当のところは「自分のレビューが重ならないように」時刻を配っていたわけです。当時はそこまで言語化できていませんでした。
Antigravity 2.0 のデスクトップ版は、この前提を正面から崩してきます。複数のエージェントを並行で走らせ、バックグラウンドでタスクを自動スケジュールできる。Manager Surface と呼ばれる画面で、各エージェントが何を計画し、いまどこを進めているかを一望できます。つまり「同時に走らせること」が標準動作になりました。ならば時刻をずらす運用はもう要らないのでは、と最初は考えたのです。
三つ走らせて分かった、本当のボトルネック
試しに、三つのサイトの下書き生成を同時に投げてみました。結果は速かったです。少なくとも、エージェントが文章を吐き出すまでの時間は明らかに短い。Go 製の新しい CLI と同じエージェントハーネスを使っているからか、応答の体感もきびきびしています。
ところが、三つ分の下書きが同時に上がってきた瞬間に、私の手が止まりました。どれも目を通さないと公開できません。一つを読んでいる間に、二つ目のエージェントは「次に進んでよいか」を尋ねて待っています。三つ目はすでに別の作業に取りかかろうとしている。気づけば、私はエージェントを待たせる側ではなく、エージェントに待たされる側になっていました。
ここで腑に落ちたのです。速くなったのはエージェントの生成であって、私のレビューではない。同時実行の数を増やすほど、ボトルネックは計算資源から自分の判断力へとはっきり移動します。三並列にした途端、一日のうちで「人が確認しなければ前に進めない地点」が三倍に増えました。速さの恩恵は、その渋滞の前まで運ばれてきて止まります。
任せる作業を「失敗の安さ」で選び直しました
そこで、何を並行エージェントに任せて、何を自分の手元に残すかを決め直しました。基準にしたのは、その作業が失敗したときに「取り返しがつくか」と「確認が安いか」の二つです。
取り返しがつき、確認も一瞬で済む作業は、迷わずバックグラウンドへ回します。たとえば内部リンクの整合チェックは、結果が機械的な合否で出るので、私は最後に緑のチェックを見るだけで済みます。下書きの初稿生成も、間違っていても捨てれば終わりなので、並行で走らせて構いません。失敗のコストが低く、レビューが軽いものほど、同時実行の恩恵を素直に受け取れます。
逆に、取り返しのつかない作業は並行から外しました。公開の確定と、ページの削除です。これらは一度実行すると検索エンジンのインデックスにまで影響が及び、あとから静かに戻すことができません。だからこの二つだけは、エージェントが何件積み上がっていても、最後に私が一件ずつ目で見て手で押すことにしています。並行化の対象にしないと最初から決めておくと、画面の上で待っているエージェントを見ても焦らずに済みます。
この線引きを、私はタスクの定義そのものに書き込むようにしました。バックグラウンドへ回す作業には、人手を介さず最後まで進む代わりに、確定の一歩手前で必ず機械的なゲートを通す約束を持たせます。
# バックグラウンドのタスクが「確定」の直前に必ず通すゲートの例。
# 機械的に判定できる検査だけを並べ、1件でも落ちたら確定させない。
run_safety_gates() {
local repo="$1"
# 公開してよい品質基準を満たしているか（機械判定）
quality_check "$repo" || return 1
# 内部リンクの参照先がすべて実在するか
link_integrity "$repo" || return 1
# 日本語版と英語版の本数が一致しているか（片方欠けは公開保留）
local ja en
ja=$(find "$repo/content" -path '*/ja/*.mdx' | wc -l)
en=$(find "$repo/content" -path '*/en/*.mdx' | wc -l)
[ "$ja" = "$en" ] || return 1
return 0
}
# ゲートを通ったものだけが、人間の確認キューに上がってくる
run_safety_gates "$REPO" && enqueue_for_human_review "$REPO"ここで大事なのは、ゲートが通っても自動では公開しないことです。ゲートは「人が見る価値のある状態まで仕上がったか」を判定するだけで、公開そのものは依然として私の手元に残します。並行エージェントを増やしても、確定の一点だけは直列のまま握っておく。これが一週間試して落ち着いた形でした。
結局、時刻をずらす運用は残しました
意外な結論として、私は時刻を分散させる古い運用を完全には捨てませんでした。同時に走らせられるからといって、同時に上げてくる必要はないと考え直したからです。
エージェントの起動は並行でも、私の確認キューに結果が届くタイミングは少しずつずらしておく。そうすると、三つの下書きが一度に押し寄せて手が止まる事態を避けられます。計算は並列に、確認は適度に直列に。この配分が、いまの自分の処理能力にはいちばん合っていました。デスクトップ版の並行実行は、その配分を細かく調整できる土台として効いています。以前はマシンの都合で時刻をずらしていたのが、いまは自分のレビュー能力の都合でずらしている。同じ「ずらす」でも、理由が入れ替わったのは面白い変化でした。
次に試すこと
もし同じように複数のプロジェクトを一人で回している方が読んでくださっているなら、まずは「いちばん失敗が安い定型作業」を一つだけ選んで、バックグラウンドのエージェントに渡してみるのがよいと思います。リンクチェックのような、結果が合否ではっきり出るものが向いています。そこで「自分の確認がどこで詰まるか」を一度体験しておくと、並行数を増やす前に、自分の側のボトルネックの位置が見えてきます。
私自身、並行化の本当の効きどころは「人が見なくてよい作業を増やすこと」であって「人が見る作業を速くすること」ではない、という当たり前を、画面いっぱいのエージェントを前にしてようやく腹に落としたところです。共に試行錯誤していけたら嬉しいです。