LLM（大規模言語モデル）を使った自律エージェントを本番運用に組み込もうとしているSRE・インフラ担当者に向けた内容です。コード生成やデスクトップGUI操作を自動化するエージェント単体の性能は、この1年でかなり伸びました。OSWorldというデスクトップ操作タスクのベンチマークでは、Mano CUA 1.1が専用モデル部門で58.2%を記録し、2位のOpenCUA 72Bに約13ポイントの差をつけています。
ただし単体エージェントの限界も同時に見えてきました。3つの情報源を並行調査してから統合する競合分析、コード生成後に独立したセキュリティレビューが必要な開発フロー、複数案を独立に作らせてから選びたい創作作業。こうしたタスクは1つのエージェントに役割を詰め込むだけでは破綻しやすくなります。
この記事は、単一エージェント構成のまま拡張するか、複数エージェントを役割分担させる構成（マルチエージェント構成）に切り替えるかを、インフラ設計の観点から判断する材料を整理したものです。判断を誤ると、後からコンテキスト分離のためにシステム全体を作り直す羽目になりかねません。
どんな場面で判断が必要になるか
コーディングエージェントにテストも書かせている構成を運用しているなら、これは他人事ではありません。
同一のコンテキスト（エージェントが参照する会話履歴や状態）でコード生成とテストを両方担わせると、自分が書いたコードを自分でテストする状況になります。これは典型的な確認バイアス（自分の判断を過大評価してしまう傾向）を生みます。テストが儀式的になり、明らかなロジックエラーも見逃されやすくなるという報告があります。
同様の問題は、レビュー専任のエージェント（アドバーサリアル・レビューアー、あえて欠陥を探す役割）を置く場合にも起きます。コーダーがどこで妥協したかをレビューアーが知っている状態だと、指摘が甘くなる傾向が確認されています。人間のチームでも、コードを書いた本人がレビューも兼任すると同じことが起きるのと構造は同じです。
判断軸
軸1: コンテキスト分離の必要性
役割ごとに「見せてよい情報」が違うかどうかを確認します。
テスターにコーダーの思考過程を見せないようにする、レビューアーに実装の妥協点を隠すといった情報の非対称性が、レビュー品質を保つ上で有効だとされています。逆に言えば、全エージェントが同じ会話ログを共有する「共有ブラックボード」方式は、チャットルームで全員が全部聞いている状態を再現するだけで、役割分担の意味が薄れます。
軸2: 推論コストとレイテンシの許容度
エージェントを増やすほどトークン課金と待機時間（プリフィル、モデルが入力を処理してから出力を始めるまでの時間）が積み上がります。
ただしこの1年でコスト構造は変わりました。オンデバイス動作の小型モデル（Mano CUA 4B Thinkingなど）はM5 Pro上で1ステップ約7.9秒、macOSの実タスク100件で56%を記録し、クラウド上のQwen3 VL Plus（39%）を17ポイント上回っています。GUI操作のような垂直specificタスクなら、クラウドAPI呼び出しの一部をローカル推論に置き換えられる余地があります。
さらに量子化（モデルの重みを低ビット精度に圧縮し推論を高速化する技術）を使うCider SDKでは、W8A8方式がM5 Pro上でMLXのW8A16ベースライン比で約1.8倍速いプリフィルを実現しています。複数エージェントを並列稼働させる場合、プリフィルの待ち行列が体感速度に直結するため、この差は無視できません。
軸3: 統合の複雑さ
エージェントごとに独自のツール接続アダプタを組むと、役割を増やすたびに保守コストが増えます。
MCP（Model Context Protocol、ツールとモデルの接続方式を標準化するプロトコル）の採用が進むことで、この統合摩擦は下がる方向にあります。既存のCI/CDパイプラインやIaC（Infrastructure as Code）ツールとの連携を考えるなら、標準プロトコルに対応したエージェントフレームワークかどうかを事前に確認しておく価値があります。
軸4: 障害時の切り分けやすさ
単一エージェントなら失敗の原因は1箇所に集約されますが、マルチエージェントでは「どの役割が誤った判断をしたか」を追跡する仕組みが必要になります。
オブザーバビリティ（システム内部の状態を外部から観測できるようにする設計）の観点では、エージェントごとにトレースIDを分離し、役割間のメッセージパッシングをログとして記録できる構成かどうかが分かれ目になります。ここが曖昧なフレームワークは、本番導入後の障害対応で苦労しやすくなります。
選択肢の比較
| 構成 | 向いているタスク | コスト特性 | 運用上の注意点 |
|---|---|---|---|
| 単一エージェント（マルチロール切替） | 直列的な単純作業、プロトタイプ検証 | 低い(呼び出し回数が少ない) | 役割間の注意の混線(attention bleed)が起きやすい |
| マルチエージェント(共有コンテキスト) | 役割は分けたいが構築を急ぎたい場合 | 中程度 | 実質的にチャットルーム化しやすく分離の効果が薄い |
| マルチエージェント(コンテキスト完全分離) | 並列調査、独立レビュー、対立する視点が必要な作業 | 高い(ただし小型モデル併用で圧縮可能) | トレース設計とMCP等の標準化が前提 |
ケース別の推奨
コード生成とテストが同一エージェントに同居しているなら、まずテスターだけでもコンテキストを分離する構成に切り替えるのが妥当です。PRD（要求仕様）とコードのみを渡し、コーダーの思考ログは渡さない設計にするだけで、レビュー品質の改善が見込めます。
並行調査やクロスチェックが必要なタスクを扱っているなら、完全分離型のマルチエージェント構成を検討する価値があります。GUI操作のような垂直タスクの比率が高いなら、ローカル動作可能な小型モデル（4B級)をワーカーの一部に割り当ててコストを抑える設計も選択肢に入ります。
M5 ProやM4 Mac miniのようなオンデバイス環境をすでに保有しているなら、量子化対応のSDK(Cider SDKなど)を使った検証から始めるのが現実的です。プリフィル速度が並列数に効いてくるため、まずは2〜3エージェント並列でのレイテンシを計測してから本格導入を判断できます。
あえて見送るべき条件
単純な直列タスクしか扱わないなら、マルチエージェント化は見送るべきです。役割分担の恩恵より、トレース設計やコンテキスト分離のための実装コストの方が大きくなりやすい構成です。
MCPのような標準プロトコルに対応していないツール群を無理に組み合わせる状況も避けたほうが安全です。エージェントを増やすたびにカスタムアダプタが必要になり、統合の複雑さが線形以上に増えていきます。
オブザーバビリティの設計が後回しになっている状態で先にエージェント数を増やすのも避けるべきです。障害発生時に「どのエージェントの判断が原因か」を追えないままシステムだけ複雑化するのは、SREの視点から見て最も避けたいパターンです。
まとめ
マルチエージェント化を検討する際は、コンテキスト分離の必要性、推論コストとレイテンシ、統合の複雑さ、障害時の切り分けやすさの4軸で現状を棚卸しするところから始められます。
次の一歩として、まずは既存の単一エージェント構成で「役割が混在している箇所」を洗い出し、テスターやレビューアーだけでもコンテキストを分離できないか確認してみるのが現実的です。あわせて、利用中のツール群がMCPのような標準プロトコルに対応しているか、トレースIDを役割単位で分離できる構成かどうかも、導入前にチェックリストとして確認しておく価値があります。