アンチパターン集 ─ Premature multi-agent から Router の分類精度天井まで

2026/05/10

アンチパターン集 ─ Premature multi-agent から Router の分類精度天井まで

ここまでの章で、8 パターン × 6 トポロジー × 古典 × HITL 設計の語彙を揃えた。本章では、それらを組み合わせるときに頻出する失敗を 8 つのアンチパターンに整理する。

各アンチパターンは Zenn 上位記事のフォーマットに従い、症状 / 根本原因 / 脱出法で記述する。

アンチパターン早見表

#	名前	関連レイヤ	頻度
1	Premature multi-agent	トポロジー	★★★★★
2	HITL 過多	HITL	★★★★
3	HITL 放棄	HITL	★★★★
4	Pipeline SPOF	トポロジー	★★★★
5	Swarm 合意ループ	トポロジー	★★★
6	Router 分類精度天井	トポロジー	★★★
7	Lead 飽和 / Orchestrator SPOF	Supervisor-Worker	★★★
8	Reflection 暴走	Evaluator-Optimizer	★★

1. Premature multi-agent ── 「マルチエージェント信仰」

症状

1 エージェントで足りる業務に 3〜5 エージェント投入
トークンコスト 15× で性能向上わずか（または悪化）
debug が困難になり、振る舞いの予測不能性が増大
「sub-agent が前提を勝手に作って衝突」する（Cognition 警告）

根本原因

「マルチエージェントの方がかっこいい」と思っている
タスクが Single Agent で完結することを認められない
「Add tools before adding agents」（Truefoundry / Augment Code）の原則を知らない
Anthropic Multi-agent Research の +90.2% / 15× tokens を「+90.2% だけ」見て採用

脱出法

Single Agent + Augmented LLM に戻す
必要なら Tools と Memory を強化
明確なボトルネックが tool で解決できないと判明したら、Supervisor-Worker に切り替え
2 エージェント以上にするときは「タスクが独立に並列できるか」を必ず問う
コーディングのように深い前提共有が必要なタスクは Single 寄り

Claude Code が単一スレッド・マスターループ（codename “nO”）を選んだ最大の理由は、まさに Premature multi-agent を避けるためだ。

2. HITL 過多 ── 「全部承認」の罠

症状

全承認でエージェントの意義が消滅
ユーザーが「なぜ 1 件ずつ承認させるんだ」と離脱
1 セッション 30 件以上の承認ポップアップ
承認疲れ → rubber-stamp 化 → 実質 HITL なし

根本原因

リスクティアを設定していない
低リスク操作にも synchronous approval を付けている
HITL を「verification」のためと誤解している

脱出法

承認を 4 ティアに分ける：auto / spot / retroactive / synchronous
低リスクは auto + spot check、高リスクのみ synchronous
「1 セッション 10 件以下」が rubber-stamp 化の閾値として設計
HITL を「speed」でなく「accountability」のために残す

3. HITL 放棄 ── 「全自律」の罠

症状

全自律で暴走
インシデント発生時に「誰が判断したか」が追えない
エージェントが意図しない不可逆操作を実行（例：本番 DB の DROP TABLE）
「Auto Mode の 17% false-negative」を「人間レビューの代替」と誤認

根本原因

HITL を「速度の足枷」と誤解している
監査要件・EU AI Act を理解していない
「動いているから問題ない」という運用バイアス

脱出法

不可逆操作・高信頼度判断・規制対象操作は必ず synchronous HITL
retroactive review を必ず組み込み（決定理由ログ）
audit trail に WHO approved + WHY approved を残す
EU AI Act 高リスク領域（healthcare / credit / employment / critical infrastructure）は法的要請

4. Pipeline SPOF ── 「直線的鎖が連鎖崩壊」

症状

5 step Pipeline の 3 step 目で失敗 → 4-5 step が空打ち
1 step の retry コストが累積
8-10 sequential handoffs を超えると prompt tuning では救えない品質劣化（Augment Code: Swarm vs Supervisor, 2026-04）

根本原因

直線的に並べたから決定論的だと思い込んでいる
各 step に retry / fallback がない
durable execution（第1部 ch7）と組み合わせていない

脱出法

各 step に retry を組み込む（指数バックオフ + jitter）
Durable execution（journal + replay）と組み合わせる：失敗 step だけ retry、完了 step は cached 値を返す
Step 間に validation gate を入れる：途中の出力が想定範囲か検査
8 step 以上の Pipeline は Orchestrator-Workers に切り替えを検討（動的再計画）

5. Swarm 合意ループ ── 「永遠に話し続けるエージェント」

症状

エージェント同士が永遠に話し合い続けて結論が出ない
1 タスクで 100 ターン以上の対話が発生
トークンコストが指数的に増大
中央 state が無いため circuit-break できない

根本原因

fully-connected swarm を採用した
失敗面が quadratic：4 agents で 6 点、10 agents で 45 点（Augment Code）
合意形成の終了条件が曖昧

脱出法

Swarm を捨てて Supervisor-Worker に切り替え：実本番では Swarm はまず採用されない
どうしても Swarm が必要なら、ターン上限と強制 tie-breaker（最終判断者）を必ず設ける
中央 state を導入して circuit-break を可能にする

Stack AI / Fast.io / Augment Code の共通見解：production の default は Hierarchical（Supervisor-Worker）か Graph で、純 Swarm は本番でコストを正当化しづらい。

6. Router 分類精度天井 ── 「ルーターが全体の上限」

症状

全体の精度が router の分類精度で頭打ち
入力分布が変わると silent drift（誰も気づかないまま品質が落ちる）
misclassified input が誤エージェント連鎖で hallucination 増幅（Patronus）

根本原因

Router を入れたまま運用に放置
分類器の精度を継続的に評価していない
入力分布の変化を監視していない

脱出法

Router の分類精度を online eval で常時監視（第1部 ch9 参照）
入力分布の drift を週次で点検
分類器を改善できないなら、Orchestrator-Workers に切り替え（動的判断）
Router の上に fallback ルートを設ける：分類器が低信頼度なら一般エージェントに渡す

7. Lead 飽和 / Orchestrator SPOF ── 「Lead が context あふれ」

症状

Supervisor-Worker で Lead Agent の context が飽和
全体が止まる（Lead が次の指示を出せない）
Sub Agent は手すきで待機しているのにコストだけかかる

根本原因

Sub からの返答を要約せずに Lead に戻している（context 肥大）
Lead に外部メモリ（progress.md）が無い
Sub の並列度が高すぎる（5 を超えて 10 sub 並列など）

脱出法

Sub からの返答は 1〜2K トークンに要約して Lead に戻す（Anthropic 経験則）
Lead が context 80% に達したら Compaction + 外部メモリ書き出し（第1部 ch5 参照）
Sub の並列度は 3〜5 に抑える（経験則）
Lead 自身を multi-instance にする（さらにヒエラルキー化）

8. Reflection 暴走 ── 「自己反省ループから抜けられない」

症状

Evaluator-Optimizer の reflection loop が終わらない
自分の出力を批判 → 修正 → さらに批判、を 50 回繰り返す
各反復で品質が改善せず、トークンだけ消費

根本原因

Reflection の終了条件が「品質が完璧になるまで」と曖昧
Evaluator 自身が flaky（同じ出力に対して異なる評価）
Optimizer が Evaluator のフィードバックを字句通りに解釈して微調整を繰り返す

脱出法

Reflection の上限ターン数を必ず設ける（例：3 回）
Evaluator の評価基準を閾値化（例：Ragas faithfulness ≥ 0.9 で通す）
改善が無いと判定したら停止（前ターンと比較して改善幅 < ε ならブレーク）
Evaluator-Optimizer は「反復で改善が見込める」タスクだけに使う（ch2 の使うべき条件）

アンチパターン横断の根本原因

8 つを並べると、共通の根本原因が見えてくる。

mindmap
  root((アンチパターン<br/>共通根因))
    複雑性信仰
      Premature multi-agent
      Swarm の採用
    終了条件不在
      Pipeline SPOF
      Reflection 暴走
      Swarm 合意ループ
    モニタリング不在
      Router silent drift
      Lead 飽和
      HITL 放棄
    リスクティア不在
      HITL 過多
      HITL 放棄

つまり 8 つは独立ではなく、4 つの根因から派生している：

複雑性信仰：シンプルで足りるところに複雑な構成を入れる
終了条件不在：「いつ止まるか」を決めていない
モニタリング不在：drift / 飽和 / 失敗を運用中に検知できない
リスクティア不在：すべて同じ重みで扱う

これらの 4 根因を意識すれば、新しいアンチパターンに遭遇したときも自力で対処できるようになる。

アンチパターンを集める意義

「成功例を真似るより、失敗例を避ける方が学習効率が高い」

これは Charlie Munger の有名な inversion 思考だ。AI エージェントの設計でも、「何が動くか」より「何が動かないか」を先に把握する方が、長期的にチーム全体の判断品質を底上げする。

そして、これらのアンチパターンは 第3部（運用工学編） の「壊れずに動き続ける」設計でも繰り返し出てくる。実装の壁を越えた後の運用の壁が、実はアンチパターンの再出現なのだ。

❌ もう 1 つのアンチパターン：「フレームワーク信仰」

最後にメタなアンチパターンを 1 つ追加する。

症状
─────────
- 「LangGraph で書けば全部解決する」と信じている
- フレームワークを変えれば品質が上がると思っている
- 月に 1 回フレームワークを変えるが、なぜ動かないかは追求しない

根本原因
─────────
- フレームワークが「パターンを抽象化したもの」であることを理解していない
- パターンの語彙を持っていないので、フレームワーク間の比較ができない
- 「動かないのはフレームワークのせい」と外部化する

脱出法
─────────
1. パターンの語彙（本作の 8 + 6 + 古典 + HITL）を先に学ぶ
2. フレームワークを「8 パターンのうちどれを抽象化したか」で評価する
3. パターンを意識したコードを書く（フレームワークを変えても流用できる）
4. ch7 で扱う「製品 × パターン」マトリクスを使って、自分の選択を点検する

業務投入の観点で重要な 3 点

アンチパターンの 4 根因を意識する：複雑性信仰 / 終了条件不在 / モニタリング不在 / リスクティア不在。これを抑えると個別のアンチパターンを自力で回避できる
「Premature multi-agent」が最頻アンチパターン：「Add tools before adding agents」の原則。Single + Augmented LLM で足りるか毎回問う
Pipeline SPOF と Reflection 暴走は終了条件で防ぐ：retry / 上限ターン数 / 閾値化 / 改善幅検知

次章への接続

ch7 では、本作の語彙（8 パターン × 6 トポロジー × 古典 × HITL）を実在する 7 つのエージェント製品にあてはめて解剖する。Devin / Manus / ChatGPT Agent / Replit Agent 3 / Claude Code / GitHub Copilot Workspace / Cursor が、それぞれ何を採用し、何を諦めたかをマトリクスで一覧化する。第1部 ch10 が「機能別の実例カタログ」だったのに対し、ch7 は「パターン別の実例解剖」だ。

この章のまとめ

アンチパターン早見表：Premature multi-agent / HITL 過多/放棄 / Pipeline SPOF / Swarm 合意ループ / Router 分類精度天井 / Lead 飽和 / Reflection 暴走
共通の 4 根因：複雑性信仰 / 終了条件不在 / モニタリング不在 / リスクティア不在
**「Add tools before adding agents」**が最重要原則
失敗例を避ける方が成功例を真似るより学習効率が高い（inversion 思考）
「フレームワーク信仰」もメタアンチパターン：パターン語彙を持たないとフレームワーク選定が迷走する