11月9日、O'Reillyが「Why AI Agents Are Repeating 2019's Microservices Mistake」と題した記事を公開した。この記事では、AIエージェントのマルチエージェント設計がかつてのマイクロサービス分解と同じ運用上の失敗パターンを踏んでいるという考察について詳しく紹介されている。以下に、その内容を紹介する。
「静かな品質劣化」という見えない障害
記事の著者は、ワークフローを3つのエージェントに分割した設計判断を振り返りながら、この問題を具体的なインシデントで説明している。
構成はシンプルだった。第1エージェントがドキュメント群を受け取り、第2エージェント（サマライザー）に渡す。サマライザーは「シグナルが低い」と判断したフィールドを出力から省いた。第3エージェントはそのフィールドなしで推論し、自信満々な推薦を返した。レイテンシは正常、エラーレートもフラット、各エージェントは設計通りに動作していた。それでも、出力の品質は徐々に低下していた。
問題が発覚したのは品質レビューで、レビュアーの「何かおかしい」という直感がきっかけだった。自動監視では何も検知できなかった。原因の特定に約3週間を要した。
マイクロサービスの「二日酔い」が再来している
2019年前後、多くのチームがマイクロサービスの複雑さに追いつけなくなった。数百のサービスを走らせながらトレーシングもコントラクトバージョニングも不十分で、問題はインシデントではなく「リリースが遅くなる」という形で表面化した。複雑さがサービス間の"隙間"に移動しただけで、消えたわけではなかった。
AIエージェントはこの周期をさらに速く回している。マイクロサービスはリポジトリとデプロイパイプラインを要したが、エージェントは「午後一つとプロンプト」で立ち上がる。作成コストが下がった結果、プロダクトチームは誰にも確認せずエージェントを作り、誰も全体像を把握できなくなる。
NeurIPS 2025で発表された研究MASTでは、7つの主要マルチエージェントフレームワークにわたる1,600件以上の実行トレースを分析し、14種類の再発する障害パターンを分類している。その大半は、モデル自体ではなく仕様の曖昧さとエージェント間の協調に起因している。
3つの固有リスク
インベントリの欠如：Kubernetesのマニフェストにはサービス一覧が残るが、エージェントはワークフローツールや週末の個人自動化の中に生まれ、記録が残らない。コンプライアンス審査で「どの自動システムがこの判断に触れたか」を問われたときに初めて実態がわかる。
信頼度の連鎖増幅：分散システムはHTTP 500で大きく失敗する。エージェントは流暢に静かに失敗する。上流エージェントが「もっともらしいが誤った」サマリを出力すると、下流エージェントはそれを正しい前提として推論し、根拠のない自信を積み重ねる。ユーザーに届く時点で、元の証拠が支持しない確信度で結果が提示される。
コスト構造の非対称性：マイクロサービスのリトライループはCPUを消費し午前3時にアラートを鳴らす。エージェントのループはターンごとに実際のコストが発生し、飽和するような症状が出ない。障害はインフラのアラートではなくビリングサイクル末の数字として現れ、PMがその説明をする羽目になる。
マイクロサービスから転用できる解決策
著者は「マルチエージェント設計が悪い」と主張しているわけではない。運用プラクティスがアーキテクチャと同時に進化しないことが問題だ、というのが論旨である。
レジストリ：最も安くて最初に省略されるもの。マイクロサービス時代のサービスカタログと同様に、各エージェントのオーナーとスコープ、そして呼び出しを許可されているもののリストを記録する。
分散トレーシング：OpenTelemetryのGenAI Semantic Conventionsを使えば、エージェントの実行をスパンツリーとして可視化できる。冒頭のインシデントでこれが実装されていれば、サマライザーのスパンとレコメンダーのスパンが同一トレースに並び、フィールドの欠落は「3週間の調査」ではなく「差分の確認」で済んだはずだ。
コントラクトテスト：プロンプトの変更はスキーマdiffも型チェックも発生させない。マイクロサービスのコントラクトテストの規律を転用し、下流エージェントが依存する出力要件を定義し、プロンプト変更前に評価を通過させる。Google A2Aインフラに行動コントラクトモデリングを適用したSEMAPでは、MASTスコアで関数レベルのコーディングタスクの障害が最大約70%減少したと報告されている。
ツールアクセスのポリシー化：エージェントが広範なツールアクセスを得るのは「我々が作ったから」という理由であってはならない。許可範囲はモデルが「話し合って回避できない」ポリシーレイヤーで管理すべきで、丁寧にお願いするだけのシステムプロンプトではない。
設計承認前に問う4つの質問
著者は設計レビューで以下を必ず確認するという。
- 一つのリクエストを通して追跡し、各エージェントの判断を再構成できるか？ できないなら、デバッグ不可能なものを作っている。
- 上流エージェントが誤ったとき何が起きるか？ 「次のエージェントが普通に処理を続ける」が答えなら、障害モードを設計したのではなく、障害を放置している。
- このエージェントのオーナーは誰で、ツールアクセスはどこで強制されているか？ システムプロンプトは強制ではない。
- 今の10倍の量でコストはいくらになり、数字がおかしくなったとき何が止めるか？ 誰も自発的には答えないので、早めに問う。
マイクロサービスへの移行を最もうまく乗り切ったチームは、トレーシングとコントラクトテストを最初から組み込んでいた。同じ教訓を今度は最初から適用できる立場にある。40エージェントを走らせてから「どれが顧客データに触れたか」を問われるよりも、スプリント1〜2本分の投資でその問いに答えられる状態を作る方が合理的だ。
詳細はWhy AI Agents Are Repeating 2019's Microservices Mistakeを参照していただきたい。
