マルチエージェント：役割分担で難しい仕事を分ける

横にスクロール

どんなパターンか

マルチエージェントとは、役割を分けた複数のLLMエージェントを協調させ、1つの大きな仕事を成し遂げる設計パターンだ。1体のエージェントにすべてを詰め込む代わりに、調査を担う者、文章を書く者、内容を検証する者というように仕事を分割し、それぞれを別々のエージェントとして走らせる。全体を束ねるのがオーケストレータ（司令塔）であり、仕事を分解してサブエージェントへ割り振り、返ってきた結果を1つの成果へ統合する。

人間のチームを思い浮かべるとわかりやすい。1人が調査から執筆、校正までをすべて抱えるより、調査担当・執筆担当・レビュー担当に分けたほうが、大きな案件は速く、質も安定する。マルチエージェントはこの分業をLLMの世界へ持ち込んだものだ。ただし人間のチームと同じく、分ければ必ず速くなるわけではない。仕事の性質によっては、分業の調整コストが利益を上回る。

このパターンが単一エージェントと決定的に違うのは、コンテキストを分離できる点だ。サブエージェントはそれぞれ自分の仕事に必要な情報だけを持てばよく、無関係な履歴に埋もれずに済む。反面、エージェントをまたいで情報を渡すには明示的な設計が要る。ここが後述する難しさの源になる。

混同しやすいが、マルチエージェントは単に呼び出し回数が多いことを指すのではない。1体のエージェントがツールを何度も呼ぶのは、あくまで単一エージェントだ。役割の異なる複数のエージェントが、それぞれ独立したコンテキストと責務を持って動き、司令塔がそれらを束ねて初めてマルチエージェントと呼べる。ここを取り違えると、ただ複雑なだけで利点のない構成になりやすい。

仕組み

典型的な流れは3段だ。第1段でオーケストレータが仕事を受け取り、サブタスクへ分解する。第2段で各サブエージェントがそれぞれのサブタスクを実行する。第3段でオーケストレータが結果を集約し、最終的な成果へ統合する。

サブエージェントの呼び方には大きく2通りある。1つは並列（ファンアウト）で、独立した複数のサブタスクを同時に走らせる方式だ。たとえば3社のクラウドの料金体系を比較せよという仕事なら、各社を1体ずつのサブエージェントに割り当て、3体を同時に調べさせる。3社は互いに依存しないので、待ち時間は最も遅い1体ぶんに縮まる。調査や情報収集はこのファンアウトと相性がよい。

もう1つは逐次で、前段の出力を次段の入力にする方式だ。調査エージェントが集めた材料を執筆エージェントへ渡し、その下書きをレビューエージェントが点検する、という流れがこれにあたる。逐次型は依存関係を素直に表せるが、並列の速さは得られない。段を重ねるほど遅くなり、途中の1体が誤ればその誤りが下流へ伝播する。

統合の段も侮れない。並列で集めた結果は、そのまま並べれば済むとは限らない。3体の調査結果に食い違いがあれば、どれを採るかを決めねばならず、重複した記述は畳んで1つにまとめる必要がある。オーケストレータはこの取捨選択と要約を担うが、集約するサブエージェントの数が増えるほど、統合そのものが重い仕事になっていく。分けた先で得た速さを、統合の手間で食い潰さないかは常に意識したい。うまく設計されたファンアウトほど、各サブエージェントの出力形式をそろえ、統合しやすい形で返させている。

役割分担の例をいくつか挙げる。調査役は外部から情報を集める。執筆役は集まった材料から文章を組み立てる。レビュー役は成果を別の視点から点検し、誤りや抜けを指摘する。このレビュー役を独立させる発想は、1体のエージェントが自分の出力を見直すリフレクションを、別のエージェントへ切り出したものと捉えられる。同じ文脈に染まっていない第三者だからこそ、書き手が見落とした欠陥に気づける。

なお、仕事を分解して順に実行するという骨格は計画と実行とも重なる。違いは、計画と実行が1体のエージェント内で計画を立てて手順を進めるのに対し、マルチエージェントは実行そのものを別々のエージェントへ配る点にある。両者は排他ではなく、オーケストレータが計画を立て、その各手順をサブエージェントへ振る、という組み合わせも自然だ。

使いどころと注意

マルチエージェントが効くのは、大きく2つの場面に絞られる。第1に、仕事を並列かつ独立に分解できる時だ。複数の対象を同時に調べる、複数の候補を同時に生成するといった、互いに依存しないサブタスクが並ぶ場面では、ファンアウトで時間を大きく縮められる。第2に、独立した検証が欲しい時だ。生成と検証を同じエージェントに任せると、自分の誤りに甘くなりやすい。書き手とは別のレビュー役を置けば、視点の違いが見落としを拾う。

一方で代償も小さくない。まずコストだ。エージェントを増やせば、そのぶんだけトークン消費とAPI呼び出しが増える。5体で並列に調べれば、入力コンテキストの費用も単純にかさむ。次に調整の複雑さだ。誰が何を担当し、どの順で呼び、結果をどう統合するかを設計せねばならず、失敗点も増える。あるサブエージェントが黙り込む、あるいは的外れな答えを返す、といった綻びのどれもが全体を止めうる。そしてコンテキスト共有の難しさがある。あるサブエージェントが得た知見を別のサブエージェントは知らないため、必要な情報は明示的に渡すか、いったんオーケストレータへ集めて配り直す必要がある。この受け渡しが太くなると、分離したはずのコンテキストがかえって重複し、コストと混乱を生む。

ありがちな失敗は、分ける必要のない仕事を無理に割ることだ。たとえば短い問い合わせへの返答を、意図分類・下書き・整形と3体に分けても、各段の受け渡しでかえって遅くなり、費用だけがかさむ。ひとつなぎで考えたほうがよい仕事を切り刻むと、文脈が寸断されて品質はむしろ落ちる。無理に分けた構成は、動いてはいても、単一エージェントに戻すだけで速く安くなることが多い。分割はあくまで、独立して並べられる単位が自然に見えている時に限りたい。

判断の軸はこう整理できる。サブタスクが独立で並列に走らせられるか。別視点の検証に見合う価値があるか。増えるコストと調整の手間を、得られる速さや品質が上回るか。これらにはっきり「はい」と言えない限り、単一エージェントのほうがたいてい速く、安く、壊れにくい。逆に、独立した調査を大量にさばく、あるいは高い正確さのために独立レビューを挟む、といった場面では分業が明確に報われる。分けるかどうかは好みではなく、この損得で決めるべきだ。

まとめ

マルチエージェントは、オーケストレータがサブエージェントへ仕事を割り振り、結果を統合する分業の設計だ。並列に分解できる仕事や、独立した検証が欲しい場面で力を発揮する一方、コスト増・調整の複雑さ・コンテキスト共有の難しさという代償を伴う。だからこそ、単一エージェントで足りるなら分けないという原則を出発点に置きたい。ほかの設計パターンはAIエージェント設計パターンから辿れる。