こんにちは、DX開発事業部の山中です。Google Cloud Next ’26 に現地参加しています！

Google Cloud Next ’26「Build multi-agent systems that actually work」のセッションレポートです。Anthropic の Cara Phillips さん（Member of Technical Staff）が、Vertex AI 上の Claude でマルチエージェントシステムを本番運用するための判断基準とアーキテクチャを語られました。

まずは単一エージェントから始める

主張はシンプルで、「適切なツールを与えた単一エージェントで、ほとんどのユースケースはカバーできる」です。

Anthropic 社内テストでは マルチエージェントは同じタスクで 3〜10 倍のトークンを消費する とのことでした。タスクコンテキストの複製、メッセージ交換、ハンドオフでの要約が積み上がるためです。想定より大きい数字でした。

3-10X more tokens than single-agent approaches

コストを抑える手段として、オーケストレーターには Opus などの上位モデル、単純なサブエージェントには Haiku などの軽量モデルの使い分けが推奨されていました。

マルチに踏み出す3つのドライバー

マルチエージェントを正当化する条件は3つだけで、どれにも当てはまらないなら単一エージェントのプロンプトを磨くべき、とのことでした。

  1. Context protection — コンテキスト汚染を防ぐ。例えばコード探索で数万トークン読んだ結果を、サブエージェント側で完結させてメインには 50トークン要約だけ返す
  2. Parallelization — 並列化。ただし目的は速度ではなく 網羅性。合計計算量が増えるので end-to-end では遅くなることもある
  3. Specialization — 専門化。ペルソナ競合や、ドメイン別の参考資料が混ざる場合に分ける

Three drivers that justify the investment

「並列化で速くなる」と思い込みがちですが、遅くなるけど網羅的になるのが真価、という整理は新鮮でした。

分け方：Context-centric で切る

Divide work by context, not problem type

Planner → Implementer → Tester → Reviewer のような問題領域での分割は罠で、ハンドオフが実作業より多くのトークンを食うケースもあったとのこと。

代わりに、エージェントが必要とするコンテキストで境界を切る。判断基準は「2つ目のエージェントは、1つ目の 推論 が必要か、それとも 結果 だけで仕事ができるか？」。結果だけで良いなら分割可能です。

5つのコーディネーションパターン

本番で観察される5つのパターンが、図・具体例・失敗モード付きで紹介されました。

# パターン 適用場面
1 Generator-Verifier 品質クリティカル、評価基準が明示可（サポートメールの下書き検証など）
2 Orchestrator-Subagent 明確な分解、境界のあるサブタスク（PR の並列レビュー。Claude Code もこのパターン）
3 Agent Teams 長時間の独立作業でコンテキストを worker 側に保持したい（コードベース移行）
4 Message Bus イベント駆動、エージェント生態系が成長していく（セキュリティオペ）
5 Shared State 共同調査、エージェント間で中間発見を共有（研究統合）

Choosing a pattern

Cara さんの推奨は「まず Orchestrator-Subagent から始める」でした。扱える問題範囲が広く、オーバーヘッドが小さく、デバッグしやすいためです。

移行のシグナル = ワークアラウンド

どのタイミングで別パターンに移行するか。4つの inflection point が示されました。

Inflection points

  • Orchestrator-Subagent → Agent Teams: サブエージェント状態を永続化するワークアラウンドを書き始めた
  • Orchestrator-Subagent → Message Bus: オーケストレーターにルーティングロジックを足し続けている
  • Agent Teams → Shared State: ワーカーが中間発見を共有する必要が出てきた
  • Message Bus → Shared State: イベントが「アクションのトリガー」ではなく「発見の共有」に使われ始めた

共通しているのは「今のパターンで別パターンが解くべき問題を解こうとして、ワークアラウンドが積み上がり始めている」という観察基準です。未来予測ではなく、実装中の違和感をシグナルにして移行するという実務的な姿勢が印象的でした。

まとめ：5つの Key Takeaways

Key takeaways

  1. 3つのドライバーをまず確認する。どれも無いなら単一エージェントを磨く
  2. マルチエージェントはトークンが 3〜10倍かかる
  3. 問題タイプではなく、エージェントが必要とする知識で分割する
  4. まず Orchestrator-Subagent から始める。品質が重要なら Verifier を足す
  5. 証拠に基づいて進化させる。inflection point を観察し、hype に従わない

どれも「当たり前に見えて実は守れていない」話ばかりで、耳が痛かったです。特に3番「問題タイプで分けたくなる誘惑」は、落とし穴にはまった覚えがあります。

参考リンク

セッション公式ページ: Build multi-agent systems that actually work