a16zパートナーのYoko Li氏が今回投げかけたのは、AIエージェントのループが「うまく回っているように見える」ことと「実際に収束している」ことは別物だという論点だ。ループが収束するには、目標状態の明確な表現・観測可能な現在状態・エラー箇所だけを直せる局所的な変更手段という3条件が揃わなければならず、加えて外部から与える停止条件にはコストも勘定しなければならないと説く。エージェントを日常的に大量に回す開発者にとって、これは「テストが通ればOK」という判定基準だけでは不十分だという指摘に等しい——著者自身のLighthouseスコア改善実験では、最初の1.40ドルの支出でスコアが26から89まで伸びた一方、残りの2.84ドル（総支出の67%）はスコア改善に一切寄与しなかった。ハーネス／オーケストレーション設計の巧拙が成果を左右するという大きな流れの中で、この論考は「どう回すか」だけでなく「いつ止めるか」もまた設計対象であることを明確にした。本当に問われているのは、テストの合否という技術的な収束条件だけでなく、支出対効果という経済的な収束条件をループの停止条件にどう組み込むかだ。

何が起きたか

a16zパートナーのYoko Li氏が2026-08-06、a16z公式ブログで「Knowing when to stop: the art of making a loop converge」と題するエッセイを公開した。AIエージェントのループ設計において、タスクの完了をどう判定し、いつ反復を止めるべきかを論じた内容だ。

仕組み・詳細

エッセイの出発点は、ループの品質は各ステップの検証器（verifier）の強さで頭打ちになるという原則だ（"the nuance when writing a loop is that the loop is only as good as the verifier at each step"）。検証器が不完全だと、ループはタスク本来の目的ではなく検証チェックの通過そのものに最適化されてしまう。

その上でLi氏は、ループが収束するための3条件を提示する。

  1. 明確な目標状態 — システムは「完了（done）」が何を意味するかの表現を持たなければならない（"The system needs a representation of what 'done' means."）
  2. 観測可能な現在状態 — システムはいま何が存在するかを検査できなければならない（"The system needs to inspect what exists now."）。ファイルやdiffなどが例として挙げられている
  3. 局所的で正確な変更手段 — エージェントは、エラーの原因となっている部分だけを直し、他のすべてを作り直さずに済む変更手段を持たなければならない（"The agent needs to change the part responsible for the error without regenerating everything else."）

さらにLi氏は、停止条件は生成器（generator）そのものではなく外部——テストの合格や制約など——から与えられるべきだとした上で（"The condition should come from outside the generator: tests passing, constraints"）、その停止条件にはコストも勘定に入れなければならないと述べる。「500回の試行の末に正解へ辿り着くループは、技術的には収束していても経済的には収束していないかもしれない」（"a loop that reaches the right answer after 500 attempts may converge technically but not economically"）。

数字で見る

Li氏はコスト勘定の必要性を、自身が実施したLighthouseスコア改善ループの実測値で裏付けている。

  • 最初の1.40ドルの支出で、スコアが26から89まで改善
  • 残りの2.84ドル（総支出の67%）は、スコア改善にゼロしか寄与しなかった（"The first $1.40 of spend took the score from 26 to 89. The remaining $2.84, 67% of the total bill, bought exactly zero points"）

なぜ重要か

このエッセイが示すのは、ループの「うまくいっている」の基準が二重化しているという構造だ。テストや制約に合格するかという技術的収束条件と、その合格までにかかった支出が見合っているかという経済的収束条件は、独立に評価しなければ片方が見落とされる。特に後者は、ループを長く回し続けるほど気づきにくい——著者自身の実験でも、総支出の3分の2以上が成果ゼロの試行に費やされていた。

エージェントを日常的なワークフローに組み込む開発者・意思決定者にとって、この論点は「テストが通るまで回し続ける」設計から「どこで止めれば支出対効果が最大化するかを見積もった上で回す」設計への転換を促す。ハーネス／オーケストレーション設計の巧拙が成果とコストの両方を左右するという大きな流れの中で、本エッセイは「いつ止めるか」を目標状態・現在状態・変更手段と並ぶ、ループ設計そのものの構成要素として位置づけ直した。