第14章: ループを重ねる ─ 自己改善とマルチエージェント
深夜、ある開発者がこんなツイートを投げる。
「Claude Code に書かせたコード、もう一回別の Claude Code にレビューさせたら、最初の Claude Code が見落としてたバグを 3 つ拾ってきた。なんだこれ」
別の開発者が答える。
「それ、間に Planner 噛ませて 3 段にすると、もっと止まらなくなる」
エージェントが、エージェントを呼ぶ。 レビューが、レビューを生む。 ループの上に、もうひとつループが乗る世界 に、私たちは入りつつある。
14.1 そもそも、なぜ単一ループでは足りないのか
第3章で見たとおり、エージェントの心臓は agentic loop ── 一人の LLM が「考えて、道具を呼んで、結果を見て、また考える」を繰り返す単一の輪っかだった。 このループだけでも、たいていのタスクはこなせる。
ところが、書く対象が 少し複雑になった瞬間、奇妙な現象が起きはじめる。
- 自分で書いたコードを、自分でレビューさせると 「問題ありません」 と言って通してしまう
- ループの途中で 当初の計画から逸れていた ことに、本人は気づいていない
- 「テストを書いてから実装」と頼んだはずなのに、いつの間にか テストを後回し にしている
この章では、なぜ単一ループでこういうことが起きるのか、そして どんな構造を上に積めば緩和できるか を扱う。
単一ループの最大の弱点は、書き手と評価者が同じ脳・同じ文脈 であること。 人間でも、自分の書いた文章を自分で校正すると誤字が見つからない。エージェントも同じだ。
14.2 自己レビューはなぜ甘くなるのか
少し原理に踏み込む。 LLM は第1章で見たとおり「続きを書く機械」だ。直前まで自分が組み立てた論理の続きとして、レビュー結果を返す。
すると、こうなる。
- 直前に「この実装で正しい」と書いた直後に、それを自分でレビューさせると、続きとして “問題なし” が出やすい
- 直前まで読んでいたコードに 意識が引っ張られて、本来見るべき周辺ファイルを見落とす
- そもそも context (会話履歴) に「自分が書いたコードは正解だ」という前提が積み上がっている
これは「LLM が嘘をついている」のではない。 続きを書く機械の構造上、書き手と評価者を同居させると評価が甘くなる という、避けがたい性質だ。
さらに厄介なのは、「どこで止めるか」も自己判断になる こと。 書き手と評価者が同じだと、「もう十分」と判定するのも本人になる。結果として、満足したら止まる ── あるいは、満足できないまま ループが止まらなくなる。 評価の独立性は、品質だけでなく 停止判断 にも効いてくる。
ここから自然に出てくる発想がある。
「評価者を、書き手とは別のエージェントにすればいいのでは？」
これが、ループを重ねるアイデアの出発点だ。
14.3 ループの上にループを重ねる ── 三つのパターン
別のエージェントに評価させる、と一口に言っても、実際には やり方が何通りもある。 現在広く使われているのは、次の三つだ。
| パターン | 何をするか | 強み |
|---|---|---|
| Planner-Generator-Evaluator | 計画 → 生成 → 評価の 3 段ループ | 仕様逸脱を抑える |
| Self-referential loop | タスクファイルを更新しながら自己呼び出し | 長時間の漸進改善に強い |
| マルチエージェント並列 | 仕事を分割して同時に走らせる | スループットを稼ぐ |
それぞれが「単一ループの何が足りないか」を別の角度で補っている。順に見ていこう。
14.4 パターン①: Planner-Generator-Evaluator ── 計画 / 実装 / 評価を別人格に
Anthropic が紹介した 3 エージェント構成 (Planner-Generator-Evaluator、通称 dev-loop) がこれにあたる。
Planner-Generator-Evaluator計画担当 (Planner)・実装担当 (Generator)・評価担当 (Evaluator) の 3 つの役割を、それぞれ独立したサブエージェントに割り当てる構成。 評価で不合格になったら計画か実装に戻す。Anthropic 由来の構成で、dev-loop という通称で呼ばれている。
具体的にはこう流れる。
- Planner が、ユーザーの要求を仕様に翻訳し、契約 (interface / 期待される出力) を書く
- Generator が、仕様だけを見て全体を実装する
- Evaluator が、別コンテキストで実物を走らせてテストし、合否を判定する
- 不合格なら、不合格理由を添えて Planner か Generator に戻す
- 合格するまで繰り返す
要点は、Generator は 自分が合格させたいゴールを知らない（仕様しか見ない）し、Evaluator は コードがどう書かれたかの会話履歴を持たない（実物だけ見る）こと。 役割と文脈が両方とも分かれていて、はじめて評価が独立になる。
Planner と Generator と Evaluator は、会話履歴 (context) を共有しない。 これが第9章で扱った context isolation の実応用そのものだ。 書き手のバイアスが評価者に漏れない構造を、context の分離で物理的に作っている。
14.5 パターン②: Self-referential loop ── 自分自身を呼び続ける
二つ目は、もう少し原始的で粘り強いスタイルだ。
Self-referential loopタスクファイル（やることリスト・進捗・残りの懸念事項を書いた markdown 等）を媒介に、エージェントが自分自身を繰り返し呼び出す構成。 1 回の呼び出しで完璧にやろうとせず、ファイルに残した状態を次の自分が読んで続きをやる。OSS コミュニティで
ralphという名前で実装が広まった。
何が嬉しいかというと:
- 1 回のループが長くなりすぎず、毎ターン context をリセット できる（context rot を抑える ── 第15章で詳述）
- 進捗が ファイル として残るので、人間がいつでも介入できる
- 失敗しても、タスクファイルさえ残っていれば 続きから再開 できる
Planner-Generator-Evaluator が「役割を空間的に分ける」のに対して、self-referential loop は「自分を時間的に分ける」アプローチだと思えばいい。 今の自分と、1 ターン後の自分は、同じ LLM だが 別の context を持つ。書き手と評価者を時間でずらしているわけだ。
試しに、第3章の単一ループと比較してほしい。
第3章は「1 個の context の中で、思考と道具呼び出しを繰り返す」。
self-referential loop は「毎ターン新しい context で、ファイルに残した状態だけを共有する」。
記憶を context ではなく 外部ファイル に逃がしているのが鍵。
14.6 パターン③: マルチエージェント並列 ── 仕事を分割して同時に走らせる
三つ目は、評価の精度を上げる方向ではなく、スループットを稼ぐ ための重ね方だ。
第13章で見た サブエージェント を、独立したタスクで複数同時に起動する。 たとえばこういう構成は、技術ブログや教科書の執筆そのものにも応用できる ── 親エージェントが章を分割し、複数のサブエージェントが 別々の章を並列に執筆 し、最後に親が結果を束ねる、といった具合だ。
マルチエージェント協調独立したタスクを複数のサブエージェントに割り当てて並列実行し、親エージェントが結果を統合する構成。 1 つの長いタスクを縦に伸ばすのではなく、横に広げる ことで時間効率を上げる。
並列で走らせるには、タスク同士の独立性 が前提条件になる。 互いに参照し合うコードを 2 人に同時に書かせると、後で merge conflict が爆発する。 だから事前に Planner が、互いに影響しない単位 に分割するのが普通だ。
| 縦に積む (Planner-Generator-Evaluator) | 横に並べる (マルチエージェント並列) |
|---|---|
| 同じ仕事を 質的に 強化 | 違う仕事を 量的に 同時処理 |
| 評価の独立性が目的 | スループットが目的 |
| 1 件の仕様の精度を上げる | n 件のタスクを同時に消化 |
実際の運用では、両方を組み合わせる ことが多い。並列に複数の Generator を走らせ、それぞれに対して Evaluator が評価する ── ループの上にループを重ね、さらにそれを横にも広げる二次元構造になる。
14.7 共通する設計判断 ── 「役割」と「別文脈」
ここまでの三つに、共通する核がある。
ループを重ねるとは、結局のところ 「役割を分けること」と「context を分けること」 に尽きる。 役割を分けないと評価が甘くなり、context を分けないとバイアスが伝播する。
これは新しい原理ではない。本書ですでに見てきた話の 延長線上にある。
- 第8章 (memory): 何を context に残し、何を外部ファイルに出すか
- 第9章 (sub-agent / context isolation): なぜ別人格の context を作るのか
- 第10章 (permissions): 誰に何を許すか ── 役割の境界
- 第11章 (hooks): 役割の境界を物理的に強制する仕掛け
ループを重ねるという発想は、ここまでに揃った道具を組み合わせて 「より大きな仕事を任せられる構造」 を作ることに他ならない。
14.8 重ね合わせの代償 ── コストと制御性
良いことばかりではない。ループを重ねると、避けがたい代償が二つある。
ひとつめは コスト。 Planner と Generator と Evaluator が別々に LLM を呼ぶので、単純計算で 3 倍以上 のトークンを消費する。 不合格で何度もループすれば、それが 10 倍、20 倍 に膨らむこともある。 業務で使うときには、評価の精度上昇と費用増のバランスを毎回考えることになる。
ふたつめは 制御性。 外側の人間から見ると、サブエージェントの中で何が起きたかが 見えにくくなる。 親が「OK でした」と報告してきても、その奥で Evaluator がどんな根拠で OK にしたかは、ログを掘らないと分からない。 これは次章 (第15章) で扱う 透明性の喪失 という限界に直結する。
「ループを重ねれば賢くなる」というのは、半分しか正しくない。 重ねた分だけ、コストも、制御の難しさも、デバッグの面倒さも増える。
私が現場で見てきた失敗の多くは、「重ね方が問題に対して大袈裟だった」 ケースだ。 ちょっとした関数を書くために、わざわざ Planner-Generator-Evaluator を組んで 30 分待つ ── これは典型的な過剰設計。
逆に、「この変更は影響範囲が広い」「あとで戻すと痛い」 という場面では、重ねる価値が一気に出てくる。 道具と同じで、ループの重ね方も 問題に見合った最小の構造 を選ぶのがコツだ。
14.9 この章の振り返り
- 単一ループの弱点は 書き手と評価者が同じ context を持つこと
- 解決策は 役割と context を分けて、ループの上にループを重ねる こと
- パターン①: Planner-Generator-Evaluator (dev-loop) ── 計画・実装・評価を 3 段
- パターン②: Self-referential loop (ralph) ── タスクファイルを媒介に自己呼び出し
- パターン③: マルチエージェント並列 ── タスクを分割して同時実行
- 共通する核は 役割の分離 と context の分離。第9〜11章で揃えた道具の組み合わせ
- 代償は コスト爆発 と 制御性の低下。問題に見合った最小の構造を選ぶ
この章で読めるようになるツイート / ブログ
- 「Claude Code に Claude Code をレビューさせたら自分のバグ見つけてきた」 → 書き手と評価者を分けると評価が独立する、というパターン①の現れ
- 「ralph でタスクファイル更新しながら一晩回したら本当に PR まで作ってあった」 → self-referential loop で context をリセットしつつ漸進改善する典型例
- 「サブエージェント 4 本並列で章ごとに書かせてる」 → マルチエージェント並列パターンの実運用。執筆系タスクとの相性が良い
- 「dev-loop 組んだら API 課金が 10 倍になった」 → 重ね合わせの代償としてのコスト爆発。設計判断ミスの典型
ループを重ねれば、エージェントはどこまでも賢くなれるのか。 答えは 「いいえ、限界がある」 だ。 次章ではいよいよ第Ⅰ部の締めとして、現代エージェントが超えられない壁 ── hallucination、context rot、計画破綻、停止判断、透明性 ── を地図にする。