📘

マルチエージェントフレームワークAIMEの紹介と実装

anyai

2025/10/09に公開

LLM

Agent

tech

近年、AI技術の進化に伴い、単一のAIではなく複数のAIエージェントが協調してタスクを遂行する「マルチAIエージェント」の概念が注目を集めています。複雑な問題を解決するためには、各エージェントがそれぞれの専門性を活かし、連携して動くことが不可欠です。
今回は、TikTokなどで有名なByteDance社が提唱したマルチエージェントのフレームワーク論文「AIME: TOWARDS FULLY-AUTONOMOUS MULTIAGENT FRAMEWORK」を簡単に紹介します。このフレームワークの肝は、従来の課題であった「静的な計画」と「エージェント能力の固定化」を、動的かつ自律的な仕組みで克服しようとしている点にあります。

また、自身の勉強も兼ねて実装に挑戦してみたので、AIMEの概要から、実際に実装してみた所感、そして見えてきた課題と学びについて解説します。
https://www.arxiv.org/abs/2507.11988

 従来の課題とAIMEの提案従来のマルチエージェントは「計画・実行（Plan-and-Execute）」フレームワークに則っており、指示されたタスクを「タスク理解→計画策定→専門エージェントが計画実行」のフローで分解・整備することで遂行していました。一方で、計画や専門エージェントが固定化されており、想定外のエラーなどが発生した際に柔軟な対応が困難である点が課題となっていました。

AIMEは、これらの課題に対し、コアコンポーネントを連携させることで、「自律性」と「適応性」を大幅に高めています。


従来の課題
問題点の指摘
AIMEの提案する解決策


Rigid Plan Execution (厳格な計画実行)
計画は一度策定されると静的で、柔軟性に欠ける。実行中の各エージェントからのフィードバックへ不適応。
Dynamic Plannerによる実行中の継続的かつ動的な計画修正・再構成。Progress Management Moduleからの最新情報に基づく意思決定。

Static Agent Capabilities (静的なエージェント能力)
エージェントの事前定義された能力が、予想されるすべてのタスクに十分であることが前提。
Actor Factoryによるサブタスク要件の解析。最適なペルソナ、知識、ツールを持つ専門エージェントのオンデマンド生成と割り当て（Dynamic Actor）。

Inefficient Communication (非効率なコミュニケーション)
エージェント間の情報引き渡しがボトルネックになり、タスク引き継ぎ時のコンテキストが欠落。
Progress Management Moduleによるリアルタイムな状態と進捗の一元管理。構造化された共有メモリによる全コンポーネント間の一貫した認識の保証。


 AIMEのコアコンポーネントAIMEは、動的なマルチエージェントコラボレーションを実現するために、連携して機能する4つのコアコンポーネントで構成されています。



論文から引用


コンポーネント
役割


Dynamic Planner
タスク管理の中央オーケストレーター。高レベルな目標をサブタスクに分解し、実行の進捗に応じて動的に計画を適応させる。

Actor Factory
特定のサブタスクに合わせて、最適なペルソナを推定しDynamic Actorをインスタンス化する役割を担う。

Dynamic Actor
Plannerから割り当てられたサブタスクを実行する自律エージェント。「ReAct」という推論と行動の反復サイクルを通じて動作する。

Progress Management Module
システム全体の共有メモリ。タスク階層とすべてのサブタスクのリアルタイムステータスを一元管理し、PlannerとActor間の一貫した進捗理解を保証する。

このフレームワークの肝は、Dynamic Plannerが中心となり、タスクの進捗状況やアクターからのフィードバックに基づいて、常に最適な計画を再考し続ける点にあります。この動的な計画変更によって、未知の状況や予期せぬエラーにも柔軟に対応できる可能になっています。
（実装が簡単かは置いといて）直感的でわかりやすい構成ですよね。残念なのがコード公開されていない点なので、ここからは実装に挑戦してみた話になります↓。

 実装してみた先にお断りしておくと、私自身AIエージェントの実装経験が薄いため、伸び代しかない実装状態になってます。

完全自力は難しいため、GeminiやClaudeと相談・コーディングしてもらいながら作成しました。

当初はシンプルな構成で始めましたが、動作検証のしやすさを考えて、途中でLangFuseとLiteLLMを組み込み、より詳細なログを追える環境にしました。
LangFuseLLMアプリケーションの監視、デバッグ、改善(いわゆるLLMOps)を目的としたプラットフォームです。

様々な機能がありますが、今回はLLMへのプロンプトや応答のトレースに使用しました。以下のように関数デコレータを付与するだけで、簡単に導入できます。
実装
from langfuse import observe
 
@observe()
def my_data_processing_function(data, parameter):
    # ... processing logic ...
    return {"processed_data": data, "status": "ok"}
 
@observe(name="llm-call", as_type="generation")
async def my_async_llm_call(prompt_text):
    # ... async LLM call ...
    return "LLM response"
トレース結果例


https://langfuse.com/docs
LiteLLMLiteLLMは、様々なLLMのAPIを同じインターフェースで呼び出せるライブラリです。

以下のようにmodel引数を変えるだけで、複数プロバイダのAPIを使用できます。
OpenAIの場合
from litellm import completion
import os

## set ENV variables
os.environ["OPENAI_API_KEY"] = "your-api-key"

response = completion(
  model="openai/gpt-4o",
  messages=[{ "content": "Hello, how are you?","role": "user"}],
  stream=True,
)
Anthropicの場合
from litellm import completion
import os

## set ENV variables
os.environ["ANTHROPIC_API_KEY"] = "your-api-key"

response = completion(
  model="anthropic/claude-3-sonnet-20240229",
  messages=[{ "content": "Hello, how are you?","role": "user"}],
  stream=True,
)
https://www.litellm.ai/
実装は以下にて公開しています。

https://github.com/anyai-28/aime-workflow
検証用のタスクは、情報検索してレポートするタスクで実施しています。toolは、初めは無料で使用可能なduckduckgo_searchを使用していましたが、検索に失敗する頻度が高く、Google検索にきりかえました。

MCPなども使えると良さそうだと思いましたが、勉強不足で取り組めていません。

（会社の同僚が書いたMCP本が来月出るのでそれで勉強しようと思います）
"東京での1泊2日の完璧な観光プランを作成してください。移動手段と予算の見積もりもお願いします。"というお題で実際に動かしてみた様子が以下になります。

初めのタスクリストから徐々に紆余曲折を経て、タスクリスト自体が変化しているのがわかります。
https://x.com/rikunchu_28/status/1971448561549312165?s=12
出来上がった最終レポートも添付しておきます。若干時間がタイトですが、バランスよく巡れるプランになってるんじゃないでしょうか。
東京観光プラン# 東京1泊2日観光プラン

## 概要
このプランは、東京での1泊2日を最大限に楽しむための観光スケジュールを提供します。主要な観光スポットを効率的に訪問し、公共交通機関を利用して移動します。予算は約19,410円で、宿泊、食事、交通費を含みます。

## 1日目のスケジュール

1. **朝食**
   - 場所: ホテル周辺のカフェまたはコンビニ
   - 予算: 500円

2. **午前: 浅草寺訪問**
   - 移動手段: 東京メトロ銀座線
   - 移動費: 約200円
   - 滞在時間: 9:30 - 11:00

3. **昼食**
   - 場所: 浅草周辺のもんじゃ焼きレストラン
   - 予算: 1,500円

4. **午後: 東京スカイツリー訪問**
   - 移動手段: 東武スカイツリーライン
   - 移動費: 約200円
   - 滞在時間: 12:00 - 14:00

5. **夕方: 上野動物園訪問**
   - 移動手段: 東京メトロ銀座線
   - 移動費: 約200円
   - 滞在時間: 15:00 - 17:00

6. **夕食**
   - 場所: 上野周辺の居酒屋
   - 予算: 2,000円

7. **ホテルに戻る**
   - 移動手段: 電車
   - 移動費: 約200円

### 合計費用
- 移動費: 800円
- 食事費用: 4,000円
- 観光費用: 9,000円（既に予算に含まれている）

## 2日目のスケジュール

1. **朝食**
   - 場所: ホテル周辺のカフェまたはコンビニ
   - 予算: 500円

2. **午前: 明治神宮訪問**
   - 移動手段: 電車（東京メトロ千代田線）
   - 移動費: 約200円
   - 滞在時間: 9:00 - 10:30

3. **昼食**
   - 場所: 原宿・表参道エリアのカフェ
   - 予算: 1,500円

4. **午後: 原宿・表参道エリア散策**
   - 滞在時間: 13:00 - 15:00

5. **夕方: 渋谷スクランブル交差点訪問**
   - 移動手段: 電車（JR山手線）
   - 移動費: 約200円
   - 滞在時間: 15:30 - 16:30

6. **夕食**
   - 場所: 渋谷周辺の居酒屋
   - 予算: 2,000円

7. **夜: 新宿御苑訪問**
   - 移動手段: 電車（JR山手線）
   - 移動費: 約200円
   - 滞在時間: 19:00 - 20:30

8. **ホテルに戻る**
   - 移動手段: 電車
   - 移動費: 約200円

### 合計費用
- 食事: 4,000円
- 移動費: 1,000円

## 宿泊施設
浅草周辺での宿泊施設として、以下のホテルを提案します。これらは観光に便利な立地で、予算内で宿泊可能です。
- 浅草ビューホテル
- ホテルウィングインターナショナルセレクト浅草駒形
- リッチモンドホテル浅草

## 全体予算
- 宿泊費: 10,000円
- 食事代: 8,000円
- 交通費: 1,800円
- 観光地入場料: 9,000円

**合計予算: 約19,410円**

このプランを基に、東京での1泊2日を存分にお楽しみください。
実際に動かしてみると、Dynamic Plannerがタスクの進捗に合わせて計画を組み直す様子は、見ていてとても楽しかったです。しかし、実装を進める中で、いくつかの壁にぶつかり、重要な学びを得ることができました。
動的プランニングよりも「タスク遂行能力」が重要

当初は「動的プランニングこそがこのフレームワークの核心だ」と考えて実装に注力していました。しかし、実際に試してみると、いくらPlannerが綿密な計画を立てて再考を繰り返しても、各Actor（エージェント）のタスク遂行能力が最低限なければ、計画自体が無駄になってしまうことを痛感しました。

当初はActorにペルソナ・ツール(検索・思考・完了報告)を与えていましたが、タスク事前情報(前タスクの結果など)の不足により完遂能力が低くタスク失敗→計画再考のループに陥ってました。対策として、事前情報やツールなどActorへの入力情報を拡充することで、ループを回避できるようになりました。
この経験から、LLMがタスクを正確に理解・遂行できるような環境づくり、すなわちコンテキストやツール、プロンプトエンジニアリングの最適化が、フレームワークの成功には不可欠だと再認識しました。
タスクの依存関係の考慮が難しい

Plannerはタスクを分解し、再計画する能力を持っていますが、タスク間の依存関係を考慮するのが難しいという課題にも直面しました。
例えば、「A」というタスクが完了しないと「B」というタスクが実行できない場合、Plannerがこの依存関係を無視して計画を立ててしまうと、再計画のループに陥ることが多々ありました。
この問題の解決策として、LLMにタスクの依存関係も併せて出力させた上で、後処理として適切な順序に並び替えるアプローチが有効でした。

 まとめ今回の実装を通じて、フレームワークの仕組みだけでなく、それを支える各エージェントのタスク遂行能力の重要性を改めて学びました。いくら優れた計画があっても、それを実行する能力がなければ絵に描いた餅に過ぎないという、当たり前のことを再認識できた貴重な経験でした。
今後は、Plannerが優柔不断になり余計なタスクを詰め込みがちだった点を改善したり、エージェントに適切なフレームワークを選定させたりする工夫を試していきたいと思います。また、今回導入したLangFuseは便利だったので、今後も活用していきたいです。
今回の経験を通じて、AIエージェントを構築する上で、プロンプトエンジニアリングやツールの提供など、LLMが能力を最大限発揮できるような環境を人が整えることの重要性を強く感じました。
最近公表されたOpenAI社のAgentKitなどを活用すると、実装がよりスムーズになるかもしれませんね。

AIエージェントの実装に興味がある方は、ぜひAIMEを参考に挑戦してみてください。

従来の課題	問題点の指摘	AIMEの提案する解決策
Rigid Plan Execution (厳格な計画実行)	計画は一度策定されると静的で、柔軟性に欠ける。実行中の各エージェントからのフィードバックへ不適応。	Dynamic Plannerによる実行中の継続的かつ動的な計画修正・再構成。Progress Management Moduleからの最新情報に基づく意思決定。
Static Agent Capabilities (静的なエージェント能力)	エージェントの事前定義された能力が、予想されるすべてのタスクに十分であることが前提。	Actor Factoryによるサブタスク要件の解析。最適なペルソナ、知識、ツールを持つ専門エージェントのオンデマンド生成と割り当て（Dynamic Actor）。
Inefficient Communication (非効率なコミュニケーション)	エージェント間の情報引き渡しがボトルネックになり、タスク引き継ぎ時のコンテキストが欠落。	Progress Management Moduleによるリアルタイムな状態と進捗の一元管理。構造化された共有メモリによる全コンポーネント間の一貫した認識の保証。

コンポーネント	役割
Dynamic Planner	タスク管理の中央オーケストレーター。高レベルな目標をサブタスクに分解し、実行の進捗に応じて動的に計画を適応させる。
Actor Factory	特定のサブタスクに合わせて、最適なペルソナを推定しDynamic Actorをインスタンス化する役割を担う。
Dynamic Actor	Plannerから割り当てられたサブタスクを実行する自律エージェント。「ReAct」という推論と行動の反復サイクルを通じて動作する。
Progress Management Module	システム全体の共有メモリ。タスク階層とすべてのサブタスクのリアルタイムステータスを一元管理し、PlannerとActor間の一貫した進捗理解を保証する。

松尾研究所テックブログ

株式会社松尾研究所のテックブログです。

従来の課題とAIMEの提案

AIMEのコアコンポーネント

実装してみた

まとめ

Discussion