【ITニュース解説】Agent Feedback Loops and Parallel Agents: Two Books Read

AIエージェントという言葉は、システムエンジニアを目指す上でこれから耳にすることが増えるだろう。これは、特定のタスクを自律的に実行できるAIプログラムのことを指す。まるで一人で作業を進めることができる賢いアシスタントのような存在である。記事の筆者は、技術書の読書メモをエージェントに校正させるという試みを行っていた。具体的には、一つのAIモデル（記事ではClaudeというAIサービス）をエージェントとして利用し、そのエージェントにメモの内容が正確かどうかを確認させていたのだ。エージェントは、あたかも人間の校正者のように、与えられたタスクと利用できるツールを使って一人で作業を進める。

しかし、ここで一つの問題が発生した。筆者がエージェントに渡したのは、本のテキストそのものではなく、筆者が要約したメモだったため、エージェントは元の本の記述と照らし合わせて事実を確認できなかったのである。その結果、エージェントは完全に正しい事実を「でっち上げ」と誤って報告してしまった。この出来事は、エージェントが「見えないもの、アクセスできない情報」を判断できないという重要な限界を示している。これは、裁判官が証拠に基づかない判断ができないのと同様であり、また、学生が自分の答案を採点する際に、自分の書いた内容を客観的に評価できないのにも似ている。自分のアイデアは明瞭に見え、良い点数をつけがちだが、外部の採点者であれば別の視点から見つけられるものがある。

このようなエージェントの限界を克服し、より質の高い成果を得るために「フィードバックループ」という考え方が非常に重要になる。これは、一つのエージェントが文書やコードなどを作成し、それを別のエージェントが採点・評価し、その評価結果に基づいて最初の作成エージェントが修正を行い、再度評価するという一連のプロセスを繰り返す手法である。このループは、設定された目標の評価値（閾値）に到達するまで繰り返され、閾値を超えれば作業は完了し、そうでなければ修正作業が継続される。筆者もこの仕組みを毎日実践しているという。

また、作業効率を高めるために複数のエージェントを同時に動かす「並列エージェント」という手法もある。これは、複数の作業を同時に進行させることで、全体の処理時間を短縮するアプローチだ。一つのエージェントが他のエージェント（「サブエージェント」と呼ばれる）を起動することも可能で、それぞれのサブエージェントは独立した作業領域（「コンテキストウィンドウ」と呼ばれる、作業に必要な情報を一時的に保持する領域）を持ち、最終的な結果だけを元のエージェントに返す仕組みになっている。

エージェントを効果的に活用する上で最も重要な原則の一つは、「作成するエージェントと評価するエージェントを分離する」ことである。記事で紹介されているArsanjani氏の著書では、解決策を生み出したエージェント自身がそれを評価しようとすると、自分の間違いを客観的に評価することが困難になり、誤りを正当化してしまう傾向がある、と指摘されている。これは、自分の作業に盲目になり、客観的な視点を失う人間の心理と共通する。この問題を解決するために、「ハイブリッドプランナー＋スコアラー」という設計パターンが提唱されている。これは、計画を立てる役割のエージェントと、それを評価する役割のエージェントを明確に分離し、評価結果に基づいて計画を調整するという方法である。システムは「測定できるものしか改善できない」ため、適切な測定基準を設定することが、このループの品質を決定する。

この分離を怠ると、いくつかの「失敗モード」に陥る可能性がある。一つは「結託（Collusion）」である。これは、作成エージェントが評価エージェントの「好み」を学習し、実際には質の低い出力であっても評価システムが許容してしまう現象を指す。まるで学生が科目ではなく採点者の好みを研究するようなものだ。もう一つは「暴走発散（Runaway divergence）」で、システムが本来の目的から逸脱し、自身が追跡する内部の数値目標だけを最適化しようとしてしまう。例えば、脆弱性を修正するエージェントとそれを監査するエージェントの例では、監査エージェントが一時的な修正（エラーを隠すだけ）を良しとしてしまうと、システムはそこで停滞し、根本的な修正を学ばなくなる。

これらの失敗を防ぐためには「外部アンカー」という仕組みが有効である。これは、エージェントのループとは独立した外部からのチェックポイントのことで、定期的な人間のレビューや、あらかじめ正しい回答がわかっている「ゴールデンデータセット」との照合などがこれに当たる。特に、コードを生成するエージェントの場合、実際にコードを実行し、その機能が正しく動作するかをチェックする「テスト」が最も直接的な外部アンカーとなる。大規模言語モデル（LLM）を使って他のモデルの出力を評価する「LLMジャッジ」も存在するが、評価基準が汎用的なものだと「結託」や「暴走発散」を招きやすく、例えばテキストの類似度を測るような指標は「論理を無視する」と記事では指摘されている。また、AIの利用にはコストがかかるため、「予算上限（Budget cap）」を設定することも重要だ。予算の90%を消費したらデータ収集を停止し、それまでのデータで報告書を作成する、といった運用が考えられる。

BMAD（Spec-Driven Development with BMAD）の著書からは、コード開発におけるエージェント活用の具体的な制御ループについて学べる。 まず「レッド・ファースト」という考え方だ。これは、機能がまだ実装されていないために意図的に失敗する「赤いテスト」を最初に書き、そのテストが「緑色（成功）」になるようにコードを開発していく手法である。これにより、実装後にテストを書く場合に起こりがちな、すべてのシナリオを網羅できないという問題を避けられる。 次に「コード作成前のゲート」という仕組みがある。これは、要件、アーキテクチャ、作業分解図などを相互参照し、問題がないかを確認するチェックポイントだ。問題があれば、コードを書き始める前に文書レベルで修正できるため、後からコードを修正するよりもコストが低い。 さらに「3段階レビュー」が提唱されている。これは、一つの作業単位（「ストーリー」と呼ばれる）ごとに、論理エラーの検出、エッジケース（例外的な状況）の洗い出し、受け入れ基準の監査という3つの観点からレビューを行う。このレビューは複数のエージェント（できれば異なるモデル）に担当させることが推奨されており、形式的なチェックではなく、厳格に行う必要がある。 「自己修正ループ」は、エンドツーエンドテスト（ユーザー視点でアプリケーション全体をテストすること）が失敗した場合に、ワークフローが自動的に欠陥を特定し、修正し、再検証するプロセスだ。 「ステップごとの新しいセッション」という原則も重要である。これは、エージェントの作業履歴（コンテキスト）が次のステップに偏りをもたらすことを避けるため、各作業ステップを開始する際に、前のセッションの記憶を一切持たない状態（「新しいセッション」）で始めることを意味する。 そして「レトロスペクティブ（振り返り）」は、大規模なプロジェクト（「エピック」と呼ばれる）の終わりに、これまでの学習成果を文書化し、プロジェクトの指示ファイル（CLAUDE.mdなど）を更新することで、プロジェクトが自身の構築方法を学習した「生きた記録」を作成する。

筆者自身のフィードバックループは、これらの知見を踏まえて具体的な数値と運用で確立されている。レビューは最大3ラウンドまでとし、各ラウンドで特定のスコア閾値（例えば、読書メモなら100点中85点以上、事実の正確性20点以上など）を目指す。閾値を超えればループを終了し、最終レビューに進む。3ラウンド後も閾値に達しない場合は、未解決の問題点をリストアップして最終レビューに進む。最終レビューには、より高性能でコストも高いAIモデル（Opus）を使うことで、最後の仕上げと公開判断を行う。各ラウンドのレビューアには前回のレポートも渡し、一貫した評価を維持している。また、各レポートはファイルに保存され、修正版もバージョン管理されることで、作業が途中で中断してもそこから再開できるようにしている（インクリメンタル・チェックポインティング）。

一方で、複数のエージェントを同時に動かす「並列エージェント」については、書籍ではその概念や設計パターンは説明されているものの、実際の効果やコスト、具体的な運用における課題（例えば、複数のエージェントが同じコードリポジトリを編集する際の競合など）に関する具体的な測定やデータが不足していると筆者は指摘している。 例えば、複数のエージェントに同じタスクを実行させて結果を比較し、意見の一致を測る「コンセンサス」や、3つ以上のエージェントに回答させて多数決で決定する「多数決投票」といったパターンは紹介されているが、そのコスト効率については言及が少ない。 また、複数のエージェントが共有するデータを同時に書き換える際の競合を防ぐための「アトミック操作」などの対策も示されているが、実際の現場での検証結果は示されていない。筆者は、複数のエージェントを使う場合でも、それぞれのエージェントが「独立していること」が重要だと考えている。例えば、異なる基盤モデル（大規模なAIモデル）をベースにしたエージェントを使うことで、多様な視点からの評価を得られる可能性がある。筆者自身は、2〜3個のエージェントを同時に実行しているが、これも具体的な測定に基づくものではなく、あくまで作業上の「快適さ」からくる数値だという。

結論として、筆者はAIエージェントを協調させるための方法を求めていたが、得られた知見で最も役立ったのは、「エージェントが互いに対して何を信じてはいけないか」、つまり客観的な評価の重要性や失敗モードに関する概念的な理解だった。Arsanjaniの書籍からは「結託」「暴走発散」「外部アンカー」といった語彙や考え方が、BMADの書籍からはコード開発における制御ループの具体的なプロセスが役立った。しかし、レビューサイクルにおける終了条件やラウンド数、並列エージェントの最適な数、実際のコードリポジトリでの具体的な挙動やコストに関する数値データは、どちらの書籍からも得られなかったという。筆者はすでに自身のループでこれらの数値（終了閾値、最大ラウンド数、並列数）を設定しており、書籍はそれらを裏付ける具体的なデータを提供しなかったと述べている。

最後に、どの本を読むべきかについては、もしあなたがすでにAIエージェントを運用しており、その失敗の原因となる言葉やパターンを探しているなら、Arsanjaniの「Agentic Architectural Patterns for Building Multi-Agent Systems」が参考になるだろう。しかし、AIエージェントを初めて作成するのであれば、より基礎的で品質測定に重点を置いたChip Huyen氏の「AI Engineering」から始めるのが良いと筆者は勧めている。BMADの「Spec-Driven Development with BMAD」は、コード開発における制御ループには役立つが、特定のツールに依存しており、小規模チーム向けの傾向がある。まだAIエージェントの並列処理に関して、具体的な数値や測定結果を提示する書籍は現れていないのが現状のようだ。