マルチLLMエージェントシステム（MLAS）のアーキテクチャ4分類
最近はXのタイムラインがAIエージェントに染まっています、kagaya(@ry0_kaga)です。
ソフトウェアエンジニア畑であることもあり、マルチエージェントシステムや、複数のエージェントやコンポーネントを連携するコンパウンドAIシステムのアーキテクティングは興味深いテーマだと感じています。
今回は「Multi-LLM-Agent Systems: Techniques and Business Perspectives」という論文で登場するマルチLLMエージェントシステム（MLAS）のアーキテクチャ分類について、私自身の理解を深めるのも兼ねてまとめてみます。
論文自体は、上海交通大学とOPPO Research Instituteの研究チームによるマルチLLMエージェントシステム（MLAS）を技術とビジネスの両面から分析した内容となっています。
MLASの4つのアーキテクチャ
「Multi-LLM-Agent Systems: Techniques and Business Perspectives」では、MLAS（マルチLLMエージェントシステム）を4つのアーキテクチャに分類していました。
（ネットワークトポロジーから着想を得たとは明示的には書いてなかったはず）
是非はともかく、既存パターンの類推で整理するのはとっつき易くはありますね。
-
スター型
- 中央オーケストレーターが全体制御
-
リング型
- パイプライン処理が明確な場合に有効
- 「入力→前処理→分析→校正→出力」のように連鎖的な工程を想定するシナリオに適合
-
グラフ型
- 柔軟・多方向の連携が必要、各エージェントが自由に相互通信できるネットワーク構造を持つデザイン
-
バス型
- 標準フローや手順が明確で、タスクをイベント駆動的に割り振る
スターアーキテクチャ
スターアーキテクチャは、中央エージェント（オーケストレーター）を中心とした放射状の構成を持つデザインです。
名前のとおり、中心にオーケスレートを担うエージェントがあり、そこから役割特化の専門エージェント等を呼び出すイメージで、中央エージェントがすべてのタスクを統括、プランニングを司るため、オーケストレーションに強みを持ちます。
筆者作のイメージ図
-
制御の集中化
中央エージェントが全体のタスクを分割し、個別のエージェントに割り当てます。また、エージェント間の通信や進捗を一元管理するため、リソース管理やワークフローの可視化が比較的容易です。 -
専門化の活用
各周辺エージェントは特定の機能に特化しており、中央エージェントから指示を受けて、その役割を遂行します。
シナリオ
-
複雑なワークフローの管理が必要な場合
タスクの進捗を中央で追跡する必要がある場面。 -
試験的または段階的なシステム展開
中央エージェントを軸に新しいエージェントを段階的に追加していく設計。
スターアーキテクチャは、中央エージェントに役割が集中している分、単純さと実用性を兼ね備えており、初期段階のMLAS構築やシンプルなユースケースに最適です。
リングアーキテクチャ
リングアーキテクチャは、エージェントを環状に配置し、隣接するエージェント間で直接通信を行う構造をもつデザインです。
この形式は、データやタスクを順次処理する際に非常に有効であり、シンプルなパイプラインを実現しやすい点が特徴と言えます。
筆者作のイメージ図
-
シンプルな通信フロー
各エージェントが前後のエージェントと通信するだけでタスクが進行するため、通信構造が単純かつ直感的です -
拡張性
前後のエージェントとのみやり取りを行うため、新しいエージェントの追加も比較的考えやすいです。
たとえば、ドキュメントレビューのワークフローをリング型で構成すると、以下のように処理を順に受け渡していきます。
-
前処理エージェント
ドキュメントの形式や内容を整える。 -
解析エージェント
内容を分析し、要約や重要なポイントを抽出。 -
校正エージェント
言語や表現の正確性を検証し、結果を最終出力。
このように前処理 → 解析 → 校正と段階的にタスクをパイプライン化することで、各エージェントが連携しながら処理を進められます。
シナリオ
-
逐次的なデータ処理が必要な場合
データやタスクが段階的に処理される場面。 -
単純な依存関係を持つタスク
各タスクが前段階の結果をそのまま利用可能な状況。 -
分散的かつ段階的なプロセス
タスクがエージェント間で継続的に流れるような構造。
課題と対策
リング型の課題の一つは、前後のエージェントによるバトン渡しが前提となるパイプライン構造であるため、一つでも停止すると後続の作業がすべてストップする点です。
これはシステム的な停止だけでなく、各タスクが前段階の結果を利用するパイプラインであればあるほど、一部のエージェントの出力のおかしさが後続に伝播するという結果となります。
とはいえ、リングアーキテクチャはタスクの流れが明確でありながら柔軟な設計が可能なため、シンプルな処理が求められるシステムや段階的なタスクの進行が求められる場面で有用です。
グラフアーキテクチャ
グラフアーキテクチャは、各エージェントが自由に相互通信できるネットワーク構造を持つデザインです。
各エージェントが自ら「今必要な情報はどれか」を判断し、複数のエージェントと同時にやり取りを行います。最も自律的な挙動を許容する、AIエージェントいえばこの形を想像するであろうアーキテクチャです。
筆者作のイメージ図。図内のエージェント名は雰囲気です
-
高い柔軟性
すべてのエージェントは、ネットワーク内の他の任意のエージェントと直接通信できます。これにより、エージェント間の連携が非常に柔軟になり、複雑なタスクに対応できます。 -
分散型:
各エージェントは自律的に意思決定を行い、他のエージェントと連携してタスクを遂行できます。これにより、中央の制御に依存しない、より柔軟なシステムを構築できます。
シナリオ
-
複雑な依存関係を持つタスク
- スター型やバス型では、ある程度あらかじめ定義されたワークフローに従う構造が主となる
- 単純な「直列パイプライン」や「中央オーケストレーター」では扱いきれないような分岐・判断が頻繁に発生し、やり取りが多方向に展開する可能性がある場合
- グラフ型ではどのエージェントも直接的に連携できるため、LLMに思考・判断を一部委ねながら複雑な依存関係を表現・実行
-
多様なエージェント間のコラボレーション
- それぞれが独立した専門性を持つエージェント（翻訳、要約、分析、事実検証など）を柔軟に組み合わせる必要があるケース
- 「Aエージェントが成果物を作り、Bエージェントが検証し、Cエージェントが補足情報を付与、さらにAとBが追加議論…」といった“多方向のやり取り”が自然に発生
- グラフ型は、こうした複数の役割エージェントが同時並行で連携・議論し合いながら合意を形成するシナリオに最適
課題と対策
グラフアーキテクチャでは通信経路が自由に生成されるぶん、通信の複雑化や管理の難度が課題となります。
「どのエージェントがどこへ通信しているのか」、「どのようなロジック・思考プロセスで処理を行ったか」を可視化・コントロールするのが困難になるため、可観測性（Observability）や監視ツールなどの「エージェント同士の関係」、「思考プロセス」を把握・管理する仕組みの整備が必須です。
- プロンプトフローや思考ログの追跡が難しい
- 単なるAPIコールのように“リクエスト→レスポンス”で管理するだけでなく、複数のLLMが連鎖的に思考・議論を行うため、「どのやり取りがどの結論を導いたのか」を追跡しにくい。
- 思考プロセスがLLM内部に隠蔽される場合もあり、監査ログとして収集しづらい。
- コンテキスト共有と秘匿性のトレードオフ
- 複数AIが自由にやり取りすると、一部のエージェントに与えた秘密データや機密トークンが意図せず別のエージェントにも流出するリスクが増加。
- これを防ぐには、通信制御ルールやアクセス制限を厳格に設定し、それを自動的にチェックする仕組みが必要。
- モデルアップデート／バージョン管理
- 複数のLLMを並行運用していると、あるモデルをアップデートした際に、他エージェントとの相性問題（プロンプトフォーマットの非互換、出力スタイルのズレ）が起きる場合もある。
「高い自由度と創発性」を得られる反面、「連携やバージョン管理のカオス化」を招きかねないのがグラフアーキテクチャのAIエージェント的な特徴と言えます。
バスアーキテクチャ
バスアーキテクチャは、タスクが中央の「バス（データフローの経路）」を介して流れる構造を持ちます。
標準操作手順（SOP）などによるあらかじめ定義されたワークフローに従いながら、複数のエージェントがタスクを順次処理する形式を取ります。
正直一番捉えきれてないですが、実際の実装を行う際にはpub/subやイベント駆動型に近くなりそうだなと思いながら読んでいました。
中央で処理の流れを司りながら、各エージェントにタスクを割り振ることで、エージェント同士は疎結合に、かつ標準化されたフローを実現しやすいという狙いかなと。
リング型でも「工程を段階的に処理する」という点は似ているように見えますが、リング型はバトン渡しの形でタスクを移動させるのに対し、バス型はあくまで中央でワークフローやイベントの進行を管理します。
リング型はエージェント同士が隣接関係で直接受け渡すため「パイプライン型」の色が濃いですが、実装まで考慮すると、バス型は 「イベント型」 の性質が強くなりそうだなと捉えました。
シナリオ
-
エージェントの疎結合性
エージェントごとに機能を独立させ、他のエージェントに直接依存しない環境。 -
ワークフローの明確化が必要な場合
入力から出力までのプロセスを一元的に管理・可視化したい場面。
他のアーキテクチャでは実装しづらい標準化フローを手軽に可視化し、エージェント同士を疎結合に保てるという点が利点だと言えるかもしれません（たぶん）
アーキテクチャの組み合わせ
実際のシステムに落とし込む際には複数のアーキテクチャを組み合わせることになりそうです。
- 例1: スター型＋リング型
- 中央オーケストレーターが各エージェントを指揮しつつ、詳細な処理部分はリング型のパイプラインで処理
よく言われるようなエージェントからワークフローを呼び出す形は、スター型のオーケストレーターエージェントからリング型の処理を呼び出す設計と近いと言えるでしょう。
スター型、リング型は実装・運用イメージは湧きやすく、グラフ型もTHE・AIエージェント味を感じる設計ではありますが、難しさもひとしおです。
| アーキテクチャ | 特徴・シナリオ・留意点・リスク |
|---|---|
| スター型 | - 特徴: 中央のオーケストレーターが全エージェントを指揮し、一元管理が容易 - シナリオ: 試験運用やセキュリティ重視の場面、段階的拡張 - 留意点 / リスク: 中央エージェントの障害・不具合で全体に影響 |
| リング型 | - 特徴: エージェントを環状に配置し、段階的パイプラインを構築 - シナリオ: 逐次処理が本質のワークフロー、シンプルな追加・拡張 - 留意点 / リスク: 1エージェント障害で後続停止／複雑な相互通信が苦手 |
| グラフ型 | - 特徴: すべてのエージェントが相互に直接通信、最も柔軟で冗長性が高い - シナリオ: 多様な専門AIが動的に連携、大規模分散環境やリアルタイム調整 - 留意点 / リスク: 通信が複雑化しやすい／管理と可観測性の仕組みが必須 |
| バス型 | - 特徴: 中央バスで標準化された手順（SOP）を管理、明確な入出力 - シナリオ: ワークフローが固定的、イベント駆動でタスクを割り振るケース - 留意点 / リスク: バス障害で全体停止／柔軟な相互通信に不向き、中央負荷に注意 |
まとめ
4つのアーキテクチャ（スター、リング、グラフ、バス）について紹介してきました。
ネットワークトポロジーをベースにアーキテクチャを考える切り口は初見だったので、取り上げてみました。
最近は論文やOSS実装を見ても増えてきている認識ですが、イベント駆動の要素を汲んだ設計はもっと増えても良さそうだなーと感じました。
今回は以上です！
Discussion