Claude Code / AgentTeams に批判的エージェントを入れたら、精度が上がった「気がした」話

最近、AI駆動開発（AI-driven development） という言葉をよく見かけるようになりました。 AIにちょっと手伝ってもらう開発から、AIが主体でタスクを回す開発へ。そんな流れが加速しているように感じます。

ClaudeCode の Swarm Mode は、まさにその流れの中で生まれた仕組みで、複数のエージェントに役割を振って、チームとして動きます。

本記事では、Swarm Mode をベースにプロンプトとオーケストレーションを独自に構成したマルチエージェント体制を 「AgentTeams」 と呼んでいます。Swarm Mode のネイティブな動作（タスク分割 → 子エージェント並列実行 → 親エージェント統合）とは異なり、今回は役割ごとに直列パイプラインを組んで制御しています。

この AgentTeams に 批判的エージェント（Critical Agent） を追加してみたら、アウトプットの質が体感で良くなった、という話をまとめてみました。

どんな Agent 構成だったのか
なぜ批判的エージェントを入れたのか
なぜ効果があったと感じたのか（仮説）

あくまで実践ログベースの話なので、定量評価や厳密な比較実験はしていないです。現場の試行錯誤の記録として読んでもらえると嬉しいです。

AI駆動開発と AgentTeam の現在地

AI駆動開発では、AIはもはやコード補完ツールではないです。

タスク分解
技術調査
実装案の作成
成果物の統合

こういった工程を、AIが自律的に進めてくれます。

ClaudeCode の Swarm Mode は、こうした AI駆動開発を実現するために、複数のエージェントに役割を分けて、並列・協調で動かす仕組みを提供してくれています。

今回の AgentTeam は、この Swarm Mode の仕組みを活かしつつ、役割分担と実行順序をプロンプトで明示的に制御した独自構成です。

ただ、実際に運用してみると、いくつか気になる点が出てきました。

各 Agent は優秀なんだけど、全体としてはやたら楽観的
前提条件や設計判断が暗黙のまま進んでいく
「一見それっぽいけど、よく見ると雑な設計」が混ざる

要するに、賢いけど、誰もツッコミを入れない状態 になりやすいです。

📎 「思ったより品質が出ない」という期待値調整の声が出始めている[^1]。

Before：もともとの AgentTeam 構成

最初はこんな構成で AgentTeam を組んでいました。

Planner Agent — ユーザーの指示をタスクに分解
Research Agent（複数） — 技術調査、仕様確認
Implementation Agent — 実装案・コード生成
Integrator Agent — 各 Agent の成果を統合

この構成で、調査から実装までの流れ自体はスムーズに回っていました。

ただ、ひとつ足りないと感じる部分がありました。

成果物そのものを「疑う」役割の Agent がいなかった。

課題認識：AgentTeam はなぜ雑になりやすいのか

私自身も感じておりましたが、いろんな検証記事や事例を見ていても、こういう指摘はよく目にします。

Agent を増やすだけでは品質は必ずしも上がらない
誤った前提や勘違いが Agent 間で増幅されることがある

AgentTeam は協調に強い。でもその裏返しとして、 全員が同じ方向を無批判に目指すと、探索が浅くなる という構造的な弱点があるそうです。

📎 LLM の追従性（Sycophancy）がマルチエージェント環境で連鎖し、集団浅慮や誤情報の増幅を引き起こしうるという指摘がある[^2]。

追加したもの：批判的エージェント（Critical Agent）

役割

この課題に対して追加したのが、批判的エージェントです。

この Agent には、かなりシンプルな制約を与えました。

実装しない
修正しない
まとめない
否定・疑問・違和感だけを出す

具体的にはこんな観点で突っ込ませています。

その前提、本当に必要？
要件と実装が混ざってない？
エッジケースは考慮してる？
もっとシンプルなやり方ない？

一言でいえば、空気を読まない Agent です。

紛争解決プロトコル（Integrator の強化）

批判を出しっぱなしだと単なるノイズになってしまうので、後続の Integrator Agent にもうひと仕事させています。具体的には以下の権限を明示的に持たせました。

精査と棄却: 批判を吟味して、取り入れるか「的外れ」として棄却するかを判断する
再指示: 有益な批判なら Implementation Agent へ差し戻し、そうでなければ統合を進める

📎 LLM を Devil's Advocate として使い意思決定精度が向上した報告[^3]がある。

After：批判的エージェント追加後のフロー

追加後のフローは下記のようになっています。

Planner Agent がタスク分解
Research Agent が調査
Implementation Agent が実装案を生成
Critical Agent が個別の成果物を批判し、欠陥やリスクを炙り出す
Integrator Agent が批判を吟味し、必要なら差し戻し、不要ならそのまま統合

統合後に全体をひっくり返すのはコストが大きいけれど、統合前なら個別の成果物単位で修正が効くと思い、 統合「後」ではなく、統合「前」に批判フェーズを挟んで います。

ただし、この配置にはトレードオフもあります。Critical Agent は統合前の個別成果物を見ているため、成果物間の整合性や全体アーキテクチャに関する批判は構造的に出しにくい です。全体整合性のチェックが必要な場合は、統合後にもう一段レビューフェーズを入れるか、人間がそこを担うことになります。

何が変わったか（体感）

定量的に測ったわけではないけど、こんな変化を感じました。

レビュー時の「なんか違う…」が減った
設計の前提が自然とドキュメント化されるようになった
後戻り・手戻りが減った
人間がレビューするときの負荷が下がった

「精度が上がった」というよりは、「雑さが減った」 という感覚に近いです。

なぜ効いたのか（仮説）

仮説1：Agent は役割を与えないと否定しない

Claude を含む多くの LLM は、基本的に協調的で肯定的に振る舞う。

AgentTeam でもそれは同じで、否定を明示的な役割として与えなければ、誰もブレーキを踏まない構造 になりやすいようです。

📎 この傾向は、単一エージェントとユーザーの対話においても、能力的に否定できる場面で追従してしまう形で確認されている[^4]。マルチエージェント環境での直接的な検証はまだ少ないが、同様の力学が働くと考えている。

仮説2：人間の開発フローを AI 内に再現している

人間のソフトウェア開発は、実装者・レビュアー・承認者みたいな役割分離で品質を支えている。

批判的エージェントは、この「レビュー工程」を AgentTeam 内に再現する存在として機能しているんだと思います。

仮説3：Agent 間の緊張関係が探索空間を広げる

全 Agent が同じゴールを無批判に目指すと、探索は最短距離に収束しがち。

批判的エージェントがいることで、一度立ち止まって別ルートを検討する余地が生まれる。

ただし、この効果は条件次第で限定的でもある。後述する注意点セクションでも触れるが、Multi-Agent Debate が単純な多数決に対して一貫した優位性を示せていないという分析[^5]もあり、「批判役を入れれば常に良くなる」わけではない。批判の質と、それを受け止める側の設計が揃って初めて機能するという感触です。

注意点・限界

いいことばかり書いたけれど、もちろん課題もあります。

批判が強すぎると収束しない: プロンプトでの「攻撃性」のチューニングが地味に大事
批判の「幻覚」: Critical Agent 自身が的外れな批判を生成するリスクもある
プロンプトが曖昧だと単なる重複に: 批判の観点を明示しないと、他 Agent と似た出力になりがち
コスト増: 批判と再修正のステップが増えるので、トークン消費・実行時間は増加する。差し戻しが頻発するケースでは体感で倍近くになることもあり、差し戻し頻度によって大きく変動する
小規模タスクではオーバーキル: このプロセス自体が過剰になるケースもある
人間の審美眼は代替できない: AI が批判し AI が修正しても、最終的な設計判断の責任は人間にある

Agent は増やせばいいってもんじゃない。

📎 現行の Multi-Agent Debate が単純な多数決に対して一貫した優位性を示せていないという分析[^6]や、本番運用組織の 32% が「品質」を最大の障壁に挙げている調査[^7]もある。

まとめ

AI駆動開発で大事だったのは、新しいモデルを使うことでも、プロンプトを工夫することでもなく、

いかに AI に忖度させないチームを設計するか

という Agent 設計そのものにあるのかなと個人的に考えています。

批判的エージェントは、開発を「加速」させるものではない。むしろ、適度な「摩擦」を生むことで品質を担保する、ブレーキのような存在 です。

また、副次的な効果として、批判に応答する過程で 暗黙だった設計前提が自然とドキュメント化される という変化もありました。忖度を防ぐだけでなく、チーム全体の透明性を上げる効果もあるようです。

ClaudeCode / AgentTeam は、単なる自動化ツールじゃない。 開発組織を設計する道具 として捉えることで、もっと価値を引き出せると思っています。

この摩擦こそが、AI による自動生成を真の「エンジニアリング」に昇華させる鍵だと感じています。

⸻

参考資料

- [^1]: k-yoshinobu, [「AI駆動開発」の現在地を振り返って - 2026年のテーマはこれだ！](https://qiita.com/k-yoshinobu/items/d75f8926e8aab47ac232), Qiita, 2026

- [^2]: Leanne Tan, [Yes, you're absolutely right… Right?: A mini survey on LLM sycophancy](https://medium.com/dsaid-govtech/yes-youre-absolutely-right-right-a-mini-survey-on-llm-sycophancy-02a9a8b538cf), GovTech, 2026

- [^3]: Jiaqi Li et al., [Enhancing AI-Assisted Group Decision Making through LLM-Powered Devil's Advocate](https://dl.acm.org/doi/10.1145/3640543.3645199), IUI 2024, ACM

- [^4]: Chin et al., [When helpfulness backfires: LLMs and the risk of false medical information due to sycophantic behavior](https://pmc.ncbi.nlm.nih.gov/articles/PMC12534679/), PMC, 2025

- [^5]: Yilun Du et al., [Improving Factuality and Reasoning in Language Models through Multiagent Debate](https://composable-models.github.io/llm_debate/), ICML 2024

- [^6]: [Multi-LLM-Agents Debate: Performance, Efficiency, and Scaling Challenges](https://d2jud02ci9yv69.cloudfront.net/2025-04-28-mad-159/blog/mad/), ICLR Blogposts, 2025

- [^7]: LangChain, [State of Agent Engineering](https://www.langchain.com/state-of-agent-engineering), 2025

スパイダープラス Tech Blog

建設SaaS「スパイダープラス」のエンジニアとデザイナーのブログ