前置き

普段、AIエージェントツールの開発をやっているのですが、とりあえずは動くものの、サンプルコードの寄せ集めのような実装になっていました。

一度、AIエージェントの設計に関連する勉強をしようと思い調べたところ、LangGraphの公式ページにマルチエージェントアーキテクチャのパターン記事がありました。

良い勉強材料になると思ったので、それを和訳し、わかりやすいよう補足していきます。イメージしやすいように料理を題材とした、具体例も書いています。

和訳の正確性より、内容のわかりやすさを優先しています。

元記事内では、実装に関する記述がありますが、それは本記事の対象外とします。別の記事として、まとめる予定です。

この記事の対象読者

‐AIエージェント系開発をしている方で設計・実装に自信がない方
‐マルチエージェント開発に興味のある方

元記事が非常に良い内容なので、すでにLangGraphを使ったエージェント開発に慣れている方にもお勧めです。

元記事

以降、元記事の内容に入っていきます。
一番最初は、マルチエージェントシステムについて書かれています。

Multi-agent System

AIエージェントシステムの開発規模が大きくなると、以下の問題に直面する。　　　

エージェントに設定したツールが多すぎて、エージェントがどのツールを使うべきかの判断ができない
コンテキストが複雑になり、エージェントが流れを把握できない

これらの問題を解決するためには、それぞれが小さく、独立したエージェントたちによって構成された、マルチエージェントシステムを構築する必要がある。

独立したエージェントとは、
プロンプト呼び出しをするだけの単純なLLMの場合や、
推論し、ツールを駆使するような複雑なLLM(ReActとか)の場合がある。

マルチエージェントシステムには、上記の問題が解決できること以外にも、以下のような利点がある。

Modularity：エージェントをモジュール化することで、システムの開発、テスト、運用がしやすくなる。
Specialization：特定の分野に特化したエージェントで構成されることにより、システム全体の精度向上ができる。

Multi-agent architectures

ここからは、マルチエージェントシステムのアーキテクチャを紹介する。

Network

ネットワーク型アーキテクチャ

すべてのエージェント間でやり取り可能なアーキテクチャ。
各エージェントが、次に呼び出すエージェントを自由に決定可能な点が特徴である。

有効な場面

エージェント間に上下関係がない
エージェントの呼び出しに特定の順序が決まっていない

例

レシピ考案エージェント
食材下処理エージェント
調理エージェント
盛り付けエージェント

レシピ考案エージェントは、レシピに応じて、下処理エージェントにお願いしたり、直接調理エージェントに調理をお願いしたりする。
サラダとかであれば、調理をとばして、レシピ考案→下処理→盛り付けの順にエージェントが呼ばれる。

Supervisor

管理型アーキテクチャ

特定の作業を担う複数の作業者エージェントと、それらのエージェントと作業そのものを管理する管理者エージェントによって構成されるアーキテクチャ。
管理者-作業者間でやりとりができるが、作業者間でやりとりはできないのが特徴。

有効な場面

並列して複数のエージェントを呼び出したい場合

例

シェフエージェント
下処理エージェント
調理エージェント
盛り付けエージェント

シェフエージェントは、どのような料理を、どのようなレシピで、どのように盛り付けるかなどを決定し、料理全体を管理する

各作業エージェントは、自分の作業をシェフエージェントに確認してもらい、シェフが納得するまで作業を繰り返す。

Hierarchical

階層型アーキテクチャ

会社とかでよくある組織構造と同じで、全体管理者、中間管理者、作業者といった階層的に構築されたアーキテクチャ。
複数の専門チームによって構成された多段のSupervisorアーキテクチャとしてもみることができる。
各エージェントは、自分の直接的な上下関係のあるエージェントとのみやり取りができる。

有効な場面

単一のSupervisorアーキテクチャでも扱いきれないぐらい、システムが複雑化した場合

例

レストランオーナーエージェント
- シェフエージェント
  - 下処理エージェント
  - 調理エージェント
  - 盛り付けエージェント
- デザインリーダーエージェント
  - 店外のデザイナーエージェント
  - 店内のデザイナーエージェント
  - 食器のデザイナーエージェント

レストランの料理に関しては、シェフエージェントが責任をもって、自分のチームのエージェントを指揮して管理する。

レストランのデザインに関しては、デザインリーダーエージェントが責任を持って管理する。

レストランオーナーエージェントは、レストラン全体の責任を持ち、シェフエージェントとデザインリーダーエージェントの作業を管理する。料理もデザインもオーナーが納得するまで、作業が繰り返される。

Custom multi-agent workflow

ワークフロー型アーキテクチャ

事前に人によって設計されたワークフローの中に、エージェントを組み込んでいるのが特徴。

大きく2パターンに分けることができる。

Explict controll flow

事前に設計されたワークフローの流れで処理が進むパターン

エージェントはワークフローで決められた作業のみを実施できる。ワークフローの流れに対して、エージェントは関与できない。

例

レストランチェーンなどであるマニュアル調理が良い例。
調理手順や量、盛り付け方法はすでに事前に決められていて、調理作業のみ、エージェントに任されている。

Dynamic controll flow

状況に応じて、エージェントがワークフローの流れを決定できるパターン

ワークフローで事前に定義された作業工程もあるが、エージェントが状況に応じて決定できる作業工程もある。どのフローをエージェントに判断させるかは人が決める。

例

家庭内でありがちな例。
使用する食材、レシピ、調理手順は同じだが、エージェント（妻）は、子供の分の場合、丁寧に盛り付ける。私の分の場合、盛り付けが適当になる。

元記事の紹介は以上です。

最後に

個人的には、抽象度の高い作業は、HierarchicalやSupervisorアーキテクチャを使用して、あらかじめ作業手順が決まっている場合には、Custom-multi agent workflowを採用すれば良いかなと思いました。　
networkアーキテクチャを採用するケース思い浮かばなかったので、出番はなさそうです。

実際には、カスタムワークフローの中に Supervisorエージェントを組み込むハイブリッド型が主流になりそうな気もします。

LangGraphを用いた実装方法に関する記載をごっそり省いているので、物足りない記事になったかもですが、今後、LangGraphの実装に関する記事も書いていきたいなと思っています。

以上、最後まで読んでいただきありがとうございました！