この記事の見どころ

AIエージェントって最近よく耳にするけど、正直「何それ？ChatGPTと何が違うの？」って思う人も多いと思います。
実は、AIエージェントは単体のAIよりも チームで動けるAI として期待されていて、将来のAGI（汎用人工知能）につながる重要な技術の一つです。

ただし、 今のエージェントには大きな課題があります。
「どんな役割を持たせるか」「どのツールを使わせるか」を人間が最初に全部設計しないといけないんです。
これってすごく手間がかかるし、もし新しい状況が出てきたら、また人間が設定し直さないといけません。

そんな“人力頼みの不便さ”を解決しようとしたのが、今回の論文です。
この研究では、AIが状況に合わせて新しい仲間（エージェント）を自動で作り、常に専門性を発揮できるようにしています。
つまり 「必要に応じて仲間を作るAI」 であり、これはより汎用的で柔軟なAI に近づく大きな一歩なんです。

紹介論文

https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1638227/full
Auto-scaling LLM-based multi-agent systems through dynamic integration of agents
(エージェントの動的統合による自動スケーリング型LLMベースのマルチエージェントシステム)

自己紹介

こんにちは、AIエンジニアを目指しているmitaです！

僕は、AIが急速に進化する中で 「仕事がなくなるのではないか」「エンジニアリングまでAIに奪われるのではないか」という不安を強く感じています。
ただ、漠然とした恐怖に心をすり減らすのではなく、AIが実際に何ができて、これから何ができるようになりそうで、まだ何が課題なのかを正しく理解し、未来にわくわくしていたいと考えています。

そのために僕は研究の最前線である論文を読んでいます。
論文を通じて現状を把握し、不必要な不安や誤解を減らしながら知識を蓄え、これからのAI時代においてエンジニアとして価値を生み出していきたいです。

記事としてまとめるのは、同じように不安や疑問を抱えている人に向けて、不安が解消されてわくわくに変わる感覚を共有したいからです。
AIは面白いものだと感じてもらえたら嬉しいし、一緒に未来を追いかけていけたら最高です。

論文の内容

結論

この論文は、AIエージェントに関して新しい2つのアーキテクチャを提案している。

IAAG (Integration of All Agents at the Beginning)
- 会話の最初に「必要そうなエージェント」を自動で作成してしまう方式
- 以降はそのエージェントを使用してタスクを進める
- 人間による設計負荷を減らしながら汎用性のあるアーキテクチャを作れることが強み
DRTAG (Dynamic Role-based Task-driven Agent Generation)
- 会話を進めながら「今必要な専門家は誰？」という問題をAIが判断し、自動で新しいエージェントを追加していく方式
- 人間が「この議題なら○○さん呼ぼう」と新しい専門家を会議に呼んでくるようなイメージ
- 動的にエージェントを追加できるため極めて高い汎用性を獲得

そもそもAIエージェントとは

AIエージェントとはそれぞれ専門性を持ったAIが協力し合い、自律的にタスクを遂行する仕組みを指します。

イメージをつかむためにSES企業を考えてみましょう。
SES企業とはシステムエンジニアリングサービスの略で、案件にエンジニアを月単価いくらという契約でアサインする企業形態です。
1つの案件にエンジニアをアサインするにしても、案件を取ってくる営業、エンジニアと案件をマッチングさせるマネージャー、アサインされるエンジニア、契約を承認する役員、、、などなど、複数の専門性を持った人がそれぞれの仕事をこなすことで会社を成り立たせています。

AIエージェントも会社と同じです。
複数のAIがそれぞれの専門性を活かしながらユーザーからの要求に応えるべく連携を取りながらタスクをこなしているのです。
~~唯一違う点は面倒くさい人間関係がないことです。~~

単一のAIでタスクをこなすより、問題を多角的に観察し、それぞれの専門性に注力した出力の連続になるため、ほとんどのタスクにおいて質の高い答えを出すことができます。
（これを汎用性と言い、人間がこなせるタスクを問題なく実行できるようになったAIをArtificial General Intelligence、汎用人工知能と表します。）

この論文のすごいところ

この論文のすごいところは 「人間依存からの脱却」 に尽きます。

従来のAIエージェントは人間が設計しAIが動く、という一般的なプログラムと同様の仕組みを取っていました。
この問題点は、設計したエージェントが解けない問題が生まれたときに人間が新しく追加開発する必要があり汎用性に限界があったことです。

AGIを実現するためには、人間が無意識に行っているように、未知の現象にぶつかっても解決への道筋を立て、必要な情報を集め、解決策を考えて実行することが必要になります。
従来のエージェントでは決まったタスクをうまく早く解決することは得意でしたが、未知タスクへの柔軟な対応は難しかったです。

しかしこの論文では、AIエージェント自身が 「必要なら仲間を新しく作る」 という仕組みを2つも提案しています。

1つ目のIAAGという手法では、タスク解決に必要そうな役割を会話冒頭で一気に作り出し、作り出したチームで課題に取り組む方式です。
従来人間がタスクをこなすために必要な機能を一から考えていた部分を自動化することに成功しています。

2つ目のDRTAGという手法では、最低限エージェントを作っておき会話を進めます。
その中で、既存エージェントでは対応できないと判断したらそのタスクに特化した専門エージェントを自分で作成し会話に参加させます。

特にDRTAGは、未知の課題に直面しても柔軟に新しい専門性を呼び込めるため、従来の静的なエージェントに比べて汎用性が格段に向上しました。

これはつまり、 人間がわざわざ設計図を書き直さなくても、AI自身が問題に応じてチームを最適化していける、ということです。
従来のAIが「決められた道を走る車」だとしたら、この論文の提案は「必要なときに新しい仲間を乗せて、道を切り拓いていける車」に近いイメージです。

従来手法との性能比較

この論文では、AIエージェント同士の会話を以下の観点で評価しています：

TF-IDFスコア：会話の中で出てくるキーワードの多様性や関連性を測る指標
MTLD（Measure of Textual Lexical Diversity）：語彙の多様性を測る指標
タスク関連性・一貫性：生成された会話がテーマに沿っているか

AutoGen（従来のマルチエージェント基盤）
・事前に固定したエージェントで会話を進める
・結果：TF-IDFスコア・MTLDともに最も低い
　→ 「多様性が低く、会話が狭い範囲に閉じがち」

IAAG（最初に全部揃える）
・会話開始前に必要そうなエージェントを一括生成
・結果：Autogenより改善、語彙の多様性が増える
・ただし不要なエージェントも混ざりやすく効率は悪い

DRTAG（動的に増やす）
・会話を進める中で必要なエージェントを追加
・結果：最も高いTF-IDFスコア、MTLDも優秀
　→ 会話がテーマに沿いつつ多様で、より豊かな知識を引き出せた

結果として汎用性は、DRTAG > IAAG > AutoGenという結果になりました。
これは、AIが状況に合わせて仲間を追加できる方が、人間の設計に頼るよりも豊かで的確な会話ができるということで、AGIに近づく大きな一歩といえます。

僕たちへの影響

僕たちの仕事や私生活への影響は下記のようになると考えます。

AIエージェント作成コストの削減
従来は「FAQ対応」「予約管理」「決済処理」といった機能ごとにエージェントを個別に設計する必要がありました。
この研究のアプローチでは、会話の中で必要に応じてエージェントを自動生成できるため、開発者が逐一すべてを準備する必要がなくなります。結果として、工数の削減だけでなく「どんな専門家が必要か」を考える負担そのものも減ります。
UX向上
ユーザーにとっては「回答がよりリッチになる」以上のメリットがあります。まるで専門家チームに相談しているかのように、対話が自然に展開されるのです。
従来の単調なやりとりでは 1 問 1 答にとどまっていた会話が、今後は文脈を踏まえて掘り下げられる。これにより「調べごとが早く終わる」「安心して任せられる」といった体験が生まれます。

この論文の課題

本論文はAGIに近づく大きな一歩となったことは間違いありません。
しかしAGIとして運用するためにはまだ解決すべき課題があると考えています。

ツール利用への拡張性

本論文に使用されているソースコードは下記のようになります。

try:
    userMsg = getUserMsg()
    while askConversationMgtAgentToConcludeConversation() == "No":
        newAgent = askConversationMgtAgentToAddNewAgent()
        if newAgent != "No" and (newAgent not in agentsList):
            agentsList.append(newAgent)
            newAgentSysPrompt = askConversationMgtAgentToGenerateSysPromptForNewAgent(newAgent)
            systemPromptDict[newAgent] = newAgentSysPrompt
        nextAgentName = askConversationMgtAgentToFindNextAgent()
        sendMsgForAgent(nextAgentName)
except Exception as e:
    print(e)
finally:
    with open("DRTAG-llm-selection.json", "w") as f:
        f.write(json.dumps(globalAgentConversation))

askConversationMgtAgentToAddNewAgentで新しいエージェントの名前を作成し、そのエージェントが持つ人格をaskConversationMgtAgentToGenerateSysPromptForNewAgentで作成しています。

エージェントの切り替えはsystemロールにエージェントの人格を表すプロンプトを追加することによって実現しています。

一方で、この仕組みはあくまで「会話の人格切り替え」にとどまっており、サービスごとの API に対応するインターフェース作成までは考慮されていません。
つまり、新たに外部ツールとの接続を確立する（例: MCPを経由してExcelを操作する、稟議申請書を自動生成するといった処理を行う）といった拡張は想定されていないのです。

AIに人間が求める上位機能のひとつは「成果物を生み出すこと」です。
現在は MCP を活用すれば、文書作成や表計算といった具体的なアウトプットまで自動化できますが、本研究のアーキテクチャはそこまで踏み込んでいません。
将来的にツール連携まで拡張できれば、単なる会話生成を超えて、実際の業務プロセスに直接的な価値をもたらす可能性が広がると考えられます。

保守工数の増加/ハードウェアの限界

本エージェントでは動的に新しいエージェントを追加していきます。
そこが強みであり今後のAGI作成に大きく貢献する部分ですが、逆に課題でもあります。

単一のタスクであれば論文のようにエージェントを増やして解決することは可能ですが、実運用においては同じAIエージェントに対して異なるタスクを複数投げることが想定されます。
その際タスクに合わせたエージェントを増やし続けてしまうと使用メモリが増加し続け、ハードウェアがボトルネックになり運用継続が困難になる可能性があります。

また、何か問題が発生してAIだけでは解決できなくなった際には人間が直接コードを確認しますが、エージェントが増加し続けると問題の特定が難しくなり、保守性を著しく損ないます。

コンピュータサイエンスで古くから使われ散るLRU、LFUやタスクへの関連性に関するスコアリング方式で使用しないエージェントを削除するなどの対策が必要と考えます。

運用コストの増加

AIエージェントはエージェント同士が協業してタスクをこなします。
その際高精度な回答を出そうと対話を重ねれば重ねるほどLLM利用料がかさむ可能性が高いです。

DRTAGのように新しいエージェントが必要かどうかを判断し、エージェントを作成し、プロンプトを考え、回答をエージェント同士で検定し答えを出すというプロセスを重ねるとコストは増加します。

プロンプト作成には計量モデルを使用するなどの対応をしつつ、モデル自体の軽量化・性能向上が必要となります。

評価の難易度向上

新しい技術が生まれた際、それをどう定量的に評価するのかは課題になります。

今回の論文でもTF-IDFやMTLDなどを使用して評価していましたが、実際に人間にとって役立つ会話かどうかを測るのは難しいので、自動評価指標と人間評価を組み合わせる必要があると考えます。

ただし、自己修正をするAIエージェントという新しい領域におけるベンチマークの研究なども盛んなので、時間が解決する問題だとも考えています。
https://zenn.dev/zenn_mita/articles/96396140c5db39

考察（感想）

今回の研究は非常に面白かったです。私はもともと AGI に強い関心があり、この研究が発展していけば AGI 実現に一歩近づくのではないかと思うとワクワクしました。

ソースコードを実際に見てみると、IAAG も DRTAG もほとんど同じ構造で、最後の動かし方だけが違うというシンプルな作りでした。正直、研究はもっと複雑で難解なプログラムを使っているのかと思っていたので、少ない行数で論文の核心を表現している点に驚きと嬉しさを感じました。自分も将来こうした最新の研究に携われたらと思います。

下記が本論文のソースコードです。
https://github.com/ravinduramesh/Auto-Scalling-LLM-based-Multi-Agent-Systems/tree/main

今後は、この論文の基盤となった研究もキャッチアップしながら、AIエージェントやRAG、さらに MCP のように実際の業務やツールとつながり始めている技術について、最新の論文を追っていきたいです。