Upgrade to Pro — share decks privately, control downloads, hide ads and more …

マルチエージェントシステム勉強会資料

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for SatAI.challenge SatAI.challenge
January 30, 2026
2

 マルチエージェントシステム勉強会資料

本資料はSatAI.challengeのサーベイメンバーと共に作成したものです。
SatAI.challengeは、リモートセンシング技術にAIを適用した論文の調査や、
より俯瞰した技術トレンドの調査や国際学会のメタサーベイを行う研究グループです。
speakerdeckではSatAI.challenge内での勉強会で使用した資料をWeb上で共有しています。
https://x.com/sataichallenge

Avatar for SatAI.challenge

SatAI.challenge

January 30, 2026
Tweet

More Decks by SatAI.challenge

Transcript

  1. Multi-Agent Systemsとは 
 • MAS(Multi-Agent System):複数のエージェント(目的と行動を持つ実行主体)が相互作用して、シングル エージェントより複雑な問題を解くためのフレームワーク 
 • 下記の例の場合だと

    
 ◦ ユーザーの質問に対して賛成派と反対派のエージェントに議論・情報収集をさせて最終的な出力を得る仕 組み)
 なぜ仮想通貨は法 定通貨よりも持続可 能なのか?
 仮想通貨は常に持続 可能性が高いのです。 なぜなら……どう思い ますか?
 反対だが、もっ と情報が必要 だ
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  2. (MASの利点を触れる前に)LLMの課題について 
 • 大規模言語モデル(LLM)は執筆や推論、意思決定など高度なタスクを実行し、その性能は人間のレ ベルに匹敵するようになった
 • LLMには以下のような弱点が知られている 
 ◦ ハルシネーション:LLMがもっともらしい嘘

    を生成してしまう問題 
 ▪ 事実確認をしていないのに、断言口調で間違ったことを言う 
 ▪ 存在しない論文・統計・引用を作る 
 ▪ 仕様や規約をそれっぽく捏造する 
 ◦ 自己回帰的な性質:前の出力を受けて次の単語を順番に出す生成方式のこと 
 ▪ 一度出した流れに引っ張られて、途中で方針転換が難しい 
 ▪ 途中の誤りが後段に連鎖しやすい 
 ▪ じっくり検討してから結論という振る舞いをデフォルトではしにくい 
 ◦ スケーリング則の制約:計算資源・コスト・データの質など現実的な限界 
 ▪ LLMの性能を向上するためにお金と労力が必要 
 ▪ 資源がない人は性能改善が難しい 
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  3. LLMの課題を克服する(LLMベース)AIエージェント 
 • これらの課題を解決するためにLLMを脳、AIエージェントとして活用する研究が盛んに 
 ◦ 幻覚対策:外部の検索・DB・検証ツールで根拠を取りに行ける 
 ◦ 熟考の代替:計画→実行→評価→修正のループ(反復)のように手順として考える

    
 ◦ スケール依存の軽減:モデルサイズを用いずツール・手続き・環境で性能向上 
 Earth AIの例
 AIエージェントがモデルAPIを活用 
 思考・計画・実行・修正をループ 
 Aaron Bell et al. (2025), “Earth AI: Unlocking Geospatial Insights with Foundation Models and Cross-Modal Reasoning”, arXiv:2510.18318. より引用
  4. 6 シングルエージェントの問題点 
 • エージェントを導入することで課題は緩和したがシングルエージェントでは下記のような課題が登場した
 ◦ 事実性・推論誤り(幻覚)
 ▪ cascading hallucinations(連鎖的幻覚):エージェントの入出力が直列連結の場合だと論理矛盾

    や幻覚が発生すると連鎖して複雑なタスクで破綻(MetaGPT)
 ▪ 上記の性質を利用して、エージェントを攻撃する恐れがある
 ◦ 熟考・探索が“自己反省”だと行き詰まる
 ▪ self-reflection型の反復は、いったんモデルが自分の解に確信すると、間違っていても新しい 考えを出せなくなる
 論理矛盾・厳格
 ↑1回幻覚が起き ると抜け出せない
 Justin Chih-Yao Chen et al. (2024), “RECONCILE: Round-Table Conference Improves Reasoning via Consensus among Diverse LLMs”, arXiv:2309.13007 より引用 Sirui Hong et al. (2024), “MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework”,arXiv:2308.00352より引用
  5. マルチエージェントシステム(MAS)を用いる利点 
 • マルチエージェントはシングルエージェントの課題を克服するだけでなくLLMの課題を克服するフレー ムワークとして(紹介する論文では)位置づけられている 
 • これまでの研究により以下の内容などが分かっている 
 ◦

    ハルシネーションに対して
 ▪ 複数のエージェント間で討論することで、事実性・推論が強化 
 ▪ 人間のワークフロー(SOP等)を取り込んだ多役割協調で連鎖的破綻を抑えて複雑なタス クを解けるように工夫する
 ◦ 自己回帰的な性質の課題について 
 ▪ 討論的なコミュニケーションを設けることによりタスクの設計の推論を強化 
 ◦ スケーリング則の制約に対して
 ▪ 知識の分散保持:1体に詰め込まず、分散した知識ベースを共有できる 
 ▪ 長期計画の強化:タスク委譲で、長い相互作用・持続的問題解決を支える 
 ▪ 一般化の強化:異なるプロンプト/personaの“専門家”を束ねて多様な問題に対応 
 ▪ 効率:サブタスクを並列に回して、多段タスクを速く解く 

  6. MAS研究の概要
 • MASを体系的に理解するために紹介した論文では以下のように整理
 • エージェント間の相互作用を協調チャネル として切り出しその性質を5軸で分類
 ◦ 誰が関わるか(actors)
 ◦ 協調か競争か(types)


    ◦ 接続形(structures)
 ◦ 運用ルール(strategies)
 ◦ 複数チャネルの組み方(coordination)
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  7. Agentの数式を用いた整理 
 • 数学的にエージェントは次の5つで構成 
 a={m,o,e,x,y} • モデル m:エージェントの頭脳にあたる部分 m={arch,

    mem, adp}
 ◦ アーキテクチャ(arch):AIの種類や構造(例:GPT、BERTなど) 
 ◦ メモリ(mem):エージェントが保持する情報や過去の状態 
 ▪ エージェント固有のメモリ mem は通常システムプロンプト 
 ◦ アダプタ(adp):追加の知識や能力を柔軟に取り込むモジュール 
 ▪ speculative decoding
 ▪ parameter-efficient adapter
 • 目的 o:エージェントが何を達成したいかの指針 
 • 環境 e:エージェントが動作する状態や条件を含む環境や文脈 
 • 入力 x:エージェントが観測する情報(センサ情報) 
 • 出力 y:エージェントが返す結果や行動 
 関数で表すと 
 ◦ 𝑦=𝑚(𝑜,𝑒,𝑥)
 • モデル 𝑚が目的 o と環境 e を使って、入力 x に応じた出力を生成する 
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  8. マルチエージェントシステムの数式を用いた整理 
 通常、多様なデータセットで事前学習(pre-training)され、個々のエージェントは必要なスキルや理解力を備え、協調環境に有意義 に貢献し、各エージェントは独自の外部ツール(例:電卓やPythonインタプリタなど)を活用することができる 
 この時、マルチエージェントコラボレーションシステム は以下の数式を用いて一般化される。 
 •    :LLMベースのエージェント群 はエージェントの数で、システムの要件に応じて事前に定義されるか動的に調整

    される
 •    :各エージェントに分割可能な集合的目標でシステム全体の目標と整合されるように設定 
 •   :エージェントが文脈情報を受け取る共有環境 LLMベースのマルチエージェントシステムでは、環境はベクトルベースデータ ベースや共通メッセージングインターフェースなど、さまざまな形態を取り扱う 
 • C={cj} :エージェント間の相互作用を促進する協調チャネルの集合 で、与えられた目的、環境、入力に基づいて情報交換を 可能に(エージェント動詞がやり取りする道筋やルールのこと) 
  
 
 •     : システムから受けた入力 
     :システムの出力 
 
 マルチエージェントシステム全体の出力は、 システムの目標・環境・入力、そして構成されるエージェント と協調チャネルに よって決まる
 アクターと出力と環境に よって1つのチャンネルが 定義
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  9. 協調チャンネルの例 
 • 環境はVillagerBench 
 • エージェントは下記で定義され目的はそれぞれの役割に応じて設定されている 
 ◦ Task

    Decomposer
 ◦ Agent Controller
 ◦ State Manager
 ◦ Base Agentが2人
 ◦ StateManagerから構成 
 • コミニュケーションチャンネルは下記の図中で矢印が引いてあるところ・チャンネルの出力の集合がシステムの 集合と定義
 Yubo Dong et al. (2024), “VillagerAgent: A Graph-Based Multi-Agent Framework for Coordinating Complex Task Dependencies in Minecraft”, arXiv:2406.05720 より引用
  10. MASのコラボレーションタイプ 
 • コラボレーションタイプ(collaboration types)には以下の3つが存在
 ◦ 協調(Cooperation):複数エージェントが同一な目的を共有し、相互に利益が出る形でタスクを進める コラボレーションの型
 ◦ 競合(Competition)

    :エージェントが自分の成功基準(個別目的)を優先し、他者と衝突しうる状況で 成立するコラボレーションの型
 ◦ 協調と競争の混在(Coopetition):エージェントがある側面では共同で目的を達成しつつ、別の側面 では利害が衝突する(競う)状況を扱うコラボレーションの型
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  11. MASのコラボレーションタイプ 協調 
 • 協調タイプでMASを構築する利点 
 ◦ 単体LLMだと破綻しやすい 「長い手順」「多観点」「複数制約」 をサブタスク分解→並列処理→ 統合で前に進められる点


    • 典型パターンは
 ◦ (1) 役割分担(調査・推論・実装・レビュー等) 
 ◦ (2) 共有コンテキスト(途中結果の共有) 
 ◦ (3) 統合役が最終出力の流れで協調を“手順化”すること 
 総合役が作業手順を作成し、各エー ジェントにタスクを依頼・最終的な得ら れた結果をユーザーに返す
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  12. MASのコラボレーションタイプ Cooperation 
 • 設計上のあるあるが協調タイプは以下の構造になりがち 
 ◦ 通信構造が中央集権型
 ◦ 協調戦略がRule-based
 •

    注意点:Cooperationは誤りの“増幅”が起きうる(誤った前提が共有されると、複数エージェントで正 当化されてしまう)。
 • そのため レビュー役・検証プロセスを協調チャネル内に組み込む設計が重要になる。 
 協調タイプのあるある
 中央集権型
 Rule-based
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  13. MASのコラボレーションタイプ 競合 
 • 競合タイプを活用する利点
 ◦ サーベイタスクでは、競合タイプが「回答の頑健性」や「創造的な問題解決」を促し、各エージェン トの限界をテストすることで適応力を高めうると言われている 
 • 競合タイプの一例(Multi-Agent

    Debate) 
 ◦ self-refine的なシングルエージェントの思考ではDegeneration-of-Thought(自己反省が同じ思 考に収束して弱る現象)を問題化 
 ◦ Multi-Agent Debate(MAD:複数エージェントが反論し合い、judgeが収束を管理)では発散した CoTを探索すると性能が上がることを報告 
 (例:GPT-3.5-Turbo+MADがCommonMTでGPT-4を上回った、等)。 
 self-refineとMADのコラボレーションを表した例 
 Justin Chih-Yao Chen et al. (2024), “RECONCILE: Round-Table Conference Improves Reasoning via Consensus among Diverse LLMs”, arXiv:2309.13007 より引用
  14. MASのコラボレーションタイプ 協調と競争の混在 
 A~Eの5つの交渉項目があり、その中にa1~a4と いった選択肢があり5つの交渉項目を取り合う設 定での実験
 (項目を取り合いつつも、合意が近づくと自分の スコアを下げつつ集団平均を上げるという妥協 の軌跡を示した
 • 下記の例で、multi-agent・multi-issueのスコア可能な交渉テストベンチを提案

    
 ◦ 交渉が要求する能力を算術・推論・探索・計画として整理しそれを評価できる 
 • 評価ではGPT-3.5や小型モデルはほぼ失敗・GPT-4やLlama-3 70Bでも十分に解けないと報告 
 Sahar Abdelnabi et al. (2023), “Cooperation, Competition, and Maliciousness: LLM-Stakeholders Interactive Negotiation”, arXiv:2309.17234 より引用
  15. MASコラボレーション方針について 
 • コレボレーション方針(collaboration strategies)下記の3つに分類される。
 • Rule-based(RB:ルールベース)エージェント間の相互作用を事前定義ルールで厳密に制御し、システム制約 に沿ったコラボレーション方針 
 •

    Role-based(役割ベース):エージェントごとに事前定義の役割(責務・目的・出力形式)を割り当て、分割さ れた目的を担当して全体目標に寄与するコラボレーション方針
 • Model-based(確率・モデル駆動):知覚の不確実性や環境変動を前提に、入力・環境データ・共有目標を 使って確率的(probabilistic)に次行動を意思決定する協調戦略である。
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  16. コレボレーション方針 Rule-basedの例 
 • 利点:効率・予測可能性・デバッグ容易性。手順が明確なタスクで性能が出しやすい。
 • 欠点:想定外への適応が弱く、ルールが増えるとスケールしにくい。
 • 下記の例では、社会心理学由来のルール(討論+多数決)で性能と効率が両立する知見から
 ◦ trait(例:overconfident)×thinking

    pattern(議論 / 内省)という“社会”を作成
 ◦ 結果として複数ベンチマークで精度向上とAPIトークン効率に貢献した
 Jintian Zhang et al. (2024), “Exploring Collaboration Mechanisms for LLM Agents: A Social Psychology View”, arXiv:2310.02124. より引用 いくつかのグ ループを作成
 議論と内省
 議論と内省の繰り返しでど のような結論になるのかを シミュレート

  17. コレボレーション方針 Role-basedの例: MetaGPT 
 概要
 • ソフトウェア開発を主眼に置いたマルチエージェントフレームワーク
 • プロダクト マネージャー、アーキテクト、プロジェクト マネージャー、エンジニアなどの


    役割のエージェントがいて、それぞれが役割を果たすことで目的を達成するように動作する
 • ユーザの1行の要望からコードだけでなく文書なども作成
 
 使い方(詳しくは公式 repoを参照)
 • OpenAI APIのAPIキーを用意する
 • インストール: pip install –upgrade metagpt
 • 初期設定: metagpt –init-config
 → APIのタイプやモデル名、APIキーなどを入力
 • 実行: metagpt “要望をここに記載”
 出典: https://github.com/FoundationAgents/MetaGPT/
  18. コレボレーション方針 Model-basedの例: ToM(Theory of Mind:他者の信念・意図の推定) 
 • 利点:動的環境でも協調を崩れにくくできる 
 • 下記の例では、協力型テキストゲームを解く際、LLMエージェントに協調行動と高次ToMの兆候を観

    察した
 • 一方、長期文脈管理と状態の幻覚で計画最適化が崩れる課題も発見し 
 • この対処には明示的な信念状態表現がタスク性能とToM推定精度を改善すると報告 
 3人のエージェントが爆弾を解除するゲーム 
 行動内省テキスト
 はい、現在ルーム5の内容は以下の通りです:プレイヤー アルファ(あなた)と爆弾3。 
 いいえ、プレイヤーチャーリーはルーム5からルーム6に移動したた め、ルーム5の現在の内容を知りません。彼らはルーム5を出る前に 持っていた情報のみを認識しています。 
 はい、プレイヤーチャーリーはあなたが部屋5の現在の内容を 知っていることを認識しています。なぜなら、あなたは前のメッ セージで爆弾3の支援のために部屋5に移動すると述べていたか らです。
 Huao Li et al. (2024), “Exploring Collaboration Mechanisms for LLM Agents: A Social Psychology View”, arXiv:2310.10701. より引用
  19. MASコミュニケーション 
 • 通信構造は下記の3つに分類
 ◦ 中央集権:全エージェントが中央エージェント(hub)に接続し、hubが管理・制御・調停して協調を 進める通信構造
 ◦ 分散:中央の指揮ノードを置かず、各エージェントがローカル情報とP2P(peer-to-peer:エージェ ント同士の直接通信)や近傍通信で意思決定する通信構造

    
 ◦ 階層:エージェントを複数レイヤに配置し、各レイヤが異なる機能を担い、主に同一レイヤ内 or 隣接レイヤ間で通信する構造
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  20. MASコミュニケーション 中央集権 
 • 中央集権の利点:(1)設計・実装が単純 (2)リソース配分が効率的である
 • 中央集権の欠点は (1)hubが故障すると全体が崩れる (2)撹乱に弱くレジリエンスが低い点にある


    • 同サーベイは中央集権をさらに2系統分類:
 ◦ Type-1「LLMは各クライアントに居て、中央は集約器(aggregator)」
 (例:FedITのようなFL型)
 ◦ Type-2「LLMが中央に居て、中央が計画・統合を主導」(例:AutoAct)
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  21. MASコミュニケーション 分散構造 
 • 分散構造の利点:(1)一部が故障しても動き続ける (2)スケールしやすい (3)各エージェントが自律的に適応 できる
 • 分散構造の欠点は

    (1)資源配分が非効率になりがち (2)通信オーバーヘッドが増えやすい
 • 分散P2Pの効能の代表例:Multi-agent Debate。
 • 複数のLLMインスタンスがラウンド制で互いの推論を批判・更新する Multiagent Debate
 ◦ 数学/戦略推論が改善し生成内容の事実整合性向上や幻覚の低減も示した
 
 Justin Chih-Yao Chen et al. (2024), “RECONCILE: Round-Table Conference Improves Reasoning via Consensus among Diverse LLMs”, arXiv:2309.13007 より引用 Yilun Du et al. (2023), “Improving Factuality and Reasoning in Language Models through Multiagent Debate”, arXiv:2305.14325 より引用 MADのイメージ図
 事実整合性の性能評価結果

  22. Zijun Liu et al. (2024), “A Dynamic LLM-Powered Agent Network

    for Task-Oriented Agent Collaboration”, arXiv:2310.02170 より引用 MASコミュニケーション 階層構造 
 • 階層構造の利点:(1)通信とタスクがレイヤに分散され低ボトルネック (2)資源配分がしやすい (3)タスクを 上位→下位へオフロード可能
 • 階層構造の欠点: (1)エッジ故障が全体障害に直結しうる (2)複雑性とレイテンシが増える
 • DyLAN(Dynamic LLM-Agent Network; Liu et al., 2023)
 ◦ エージェントを多層(multi-layer)に組み
 ◦ (1) Team Optimizationで貢献度にもとづき有効エージェントを選抜
 ◦ (2) Task Solvingで選抜チームが協調する二段構えを提案
 ◦ コード生成・意思決定・推論・算術で性能と効率を両立しMMLUの一部領域で最大+25%精度向上

  23. マルチエージェントシステムを活用したアプリケーションの方向性 
 • MASを用いたアプリケーションの分野として下記の3つが紹介されている 
 ◦ 5G/B6G and Industry 5.0(本資料では5Gに限定して深堀り)

    
 ▪ 5G/B6G(B6G=Beyond 6G)と Industry 5.0 を「LLM がエッジネットワーク性能を高める」代 表的応用領域として同じ節で整理している(通信性能だけでなく、運用・自動化も含む)。 
 ◦ Question Answering / Natural Language Generation (QA/NLG) 
 ◦ Social and Cultural Domains
 ▪ AIエージェントを題材に人間社会の社会・文化的振る舞いをシミュレーション 
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  24. • 5G/B6G側の中心軸は SemCom(semantic communication:ビット列ではなく 意味の伝送・復元を重視 する通信)
 ◦ 従来の通信理論の枠組みを拡張し、「記号を正確に送る」 
 ◦

    セマンティック通信は情報が持つ意味に焦点をあてる 
 • 送信情報が「にんげん」で1文字誤りが発生して「にんじん」を受信するケースと「ひとびと」を受信する ケースでは前者は信頼性が高い通信、セマンティックの観点からは後者の方が信頼性の高い通信 
 アプリケーション 5G/B6G 
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  25. • LLMは「意味表現」「事前知識」「文脈補完」が得意なので、SemComと相性が良い
 • Tokenizerを用いてテキストを符号化、信号化し、復号に使用するアプリケーションも提案
 ◦ 送信側で LLMのtokenizer学習をsemantic encoderに対応づけ、
 ◦ 受信側で

    LLMの事前学習が作る確率をsemantic knowledge baseとして復号に活用
 ◦ 結果DeepSCを上回る性能を報告
 5G/B6G Tokenizerを用いたセマンティック通信 
 Zhenyi Wang et al. (2025), “Large-Language-Model-Enabled Text Semantic Communication Systems”, arXiv:2407.14112. より引用 符号化
 信号化
 復号化

  26. アプリケーションQA/NLGのアプリケーションの実際の活用例 
 • Swarmは、2024年10月12日にOpenAIが公開したマルチエージェントオーケストレーションのためのフレーム ワーク
 • OpenAIの Swarm は手順をまとめた routine

    と会話状態を別エージェントへ移す handoff で複数エージェン トをオーケストレーションしカスタマーサポートのようなQA/NLGフローでの適用可能性を示している
 協調タイプ
 Roleベース
 階層構造
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用
  27. • 社会的な応用(Social Applications) 
 人間行動のシミュレーション :LLMエージェントを特定の条件下で人間参加者の代替として用いる。 
 「従業員」「家族」などの役割(ロール)を付与して相互作用させ、会話能力/他者の心的状態推論)/Hobbes的社 会契約(秩序維持のための権威受容)/非言語行動の推論を観察・分析する。 


    社会インフラ/政策の検証(ABMの拡張) : 市民エージェントに対して政策介入を行い、介入効果の検証や(文脈 によっては)規範違反の検知などを通じて、社会理論や政策の仮説をテストする。 
 • 文化的な応用(Cultural Applications) 
 異文化理解と偏見の軽減 :異なる文化背景を持つ人物像をエージェントに担わせ、対話や相互作用を通じて異 文化理解の促進偏見(バイアス)の低減を検討・シミュレーションする。 
 文化的進化(文化伝播)の解明 :文化的情報がエージェント間で 伝播・変形していく過程をモデル化し、人間社 会における文化伝播の理解に繋げる。 
 • 限界・リスク 
 シミュレーションの不完全性 :世界規模の心理的多様性が十分に表現されないなど、LLMが人間を完全には再現 できない前提がある。 
 安全面と信頼の課題(過剰な人間視) :AIを過度に人間視すると、ユーザーの過剰信頼や誘導・操作といったリス クが高まり得る(この点は倫理・安全の議論として強調される)。 
 Khanh-Tung Tran et al. (2025), “Multi-Agent Collaboration Mechanisms: A Survey of LLMs”, arXiv:2501.06322. より引用 社会的・文化的ドメインにおけるマルチエージェントシステム(MAS)の応用 

  28. 32 • Turing Experiment 
 LLMが人間のような判断を下せるという特性を利用し、アンケート回答、経済ゲーム、道徳的判断などのシミュレーション。 
 • AgentCoord 


    LLMベースのマルチエージェント共同作業における調整戦略(Coordination Strategy)を視覚的に設計・探索する。 
 • AgentInstruct 
 強力なモデル(教師)を使って別のモデル(生徒)に新しいスキルを教えるための、高品質な合成データを大規模に自動生 成。
 • Mango
 LLMから文化的常識知識(CCSK)を抽出・統合し、異文化間の対話を改善するための手法。 
 • CulturePark 
 異なる文化背景を持つエージェント同士の対話をシミュレートし、文化的データの収集とモデルのバイアス軽減を図るフレー ムワーク
 • SocialMind 
 AR(拡張現実)グラスを通じてリアルタイムで社会的支援を行う、先的な仮想アシスタントシステムで、 
 センサーから得られる多言語・非言語的手がかり(表情、ジェスチャー、距離など)を統合し、現場で適切な社会的助言を提示 
 タスクや研究段階を選べば有用 、ただし解釈や限界に注意 社会的・文化的ドメインにおけるマルチエージェントシステム(MAS)の応用 

  29. 未解決問題と議論
 • ガバナンスは「役割設計+障害復旧」で協調を壊れにくくする
 ◦ Unified Governanceは、協調の計画(どの手順で、誰が参加し、どう分担するか)を一貫して制御する仕組みである。
 ◦ 役割割当は性能を上げ得るが、入力や状況が変わるため、最適割当を維持しつつ動的適応させるのが難所になる。
 ◦ 協調はミスコミュニケーションやタスク中断が起きる前提なので、検知と復旧(冗長化/フォールバック)を組み込む必要があ

    る。
 ◦ さらにShared Decision Makingとして、独裁・多数決以外の集約(嗜好の差や過信の集約問題を避ける方法)が研究課題にな る。
 • MAS評価は「正しさ+協調の質+原因切り分け」を同時に測る必要がある
 ◦ MASは協調が入る分、単体LLMより評価が難しく、成功率以外に協調効率や文脈適合性などの軸が要る。
 ◦ 失敗原因を特定するには、システム全体だけでなく、エージェント/協調チャネル単位の細粒度評価が必要になる。
 ◦ 現状は設定がバラバラで比較不能になりがちで、標準プロトコルと包括的ベンチマークが不足している。
 ◦ 固定ベンチは陳腐化・リーク・過学習を招き得るため、状況に追随するdynamic benchmarkingが重要になる。
 • 安全性は「誤りと攻撃が協調で増幅する」ことが本質リスクである
 ◦ MASでは幻覚が他エージェントに伝播し、LLMの過信や協調中の誤解によって誤りが増幅しうる。
 ◦ adversarial attack により一部エージェントが侵害されると、悪性の出力が協調経路を通じて拡散し、エージェント数増加でリス クがスケールする。
 ◦ スケール面では、資源管理とボトルネック回避が難しくなり、MASのスケーリング則理解が設計の前提になる。
 • AIを走らせるのに必要なエネルギーが急増する中で、ある種の贅沢なエネルギー利用になりそう。省エネで同等のパフォーマンスを 出せるようにするのも、AI開発企業の持続可能性の視点から重要ではないか

  30. • AIエージェントの仕組みを学ぶことでエンジニアリングだけでなく、人間がどの用に関わると性能を欲しいアウトプットに近づく ことができるのか?という観点につながるんだという気付きを得ることができました。(中村) 
 • セマンティック通信のところではLLMの活用が行われていて、新しい気付きでした。衛星のセンシングの側面でも地上リモート センシングと衛星リモートセンシングのセマンティクスが近づくことが1つポイントなので、そのような広がりがあると面白いなと 期待しています。(中村)
 • マルチエージェントについてはざっくり知っていましたが、その仕組みや類型を知ることで、

    
 エンジニアリングも大事だが、チームマネジメント的な能力も今後必要になってくると感じました。 
 リモセンやGIS分野への応用も考えていきたいです。(青木) 
 • 猫も杓子もエージェントだ~~って状況の中なのに、あまりよくわかってなかったので良いサーベイ論文にでありました。LLM に仮想的な人格を与えて疑似社会を作ってシミュレーションする手法はいろいろな場所に使えそうなのでリモセンに限らず 使っていきたい。その仮想市民の市民らしらの評価や、LLMエージェンたちがポピュリズムになってしまったりの制御をどこま でするかなどが今後の問題になりそう(篠原) 
 • マルチエージェントタスク自体は,単一のエージェントでタスクを解く場合において思考過程の自由度を下げている気がする, うまく思考過程を人間が行う粒度に分解してエージェントに与えることでより優れた答えにたどり着くのかなと(藤野) 
 • 逆にモデルがもっと大きくなったりすると,単一エージェントでもよくなるのかもしれない.逆にその自由度を下げているのが邪 魔になる?(藤野)
 勉強してみての感想(1/2) 

  31. • 深層学習、基盤モデル等もそうだが、AI分野で話題になっている技術がリモセンに適用されるにはタイムラグがある。このマ ルチエージェントの考え方もリモセンにどんどん取り入られることになると思うので、こうしたAIに立脚した論文を通して、トレン ドの先取りができることは非常にありがたい。(平出) 
 • マルチエージェントによる社会構造の設計は、実社会への介入可能性を含んでいる点で非常に興味深く、同時に大きな責任 を伴う領域だと感じています。エージェントの構築や相互作用の設計手法を具体的に学べる本論文は、実践的なノウハウを 習得する上で極めて価値の高い資料でした。(平出) 


    • エージェントの概念は定性的には見聞きしていたものの、実装されてるものは状況に応じた使い分けがあるなど、興味深かっ た(しまだ)
 • 課題のところでも書いたものの、かなり計算機を贅沢に使っているような印象を受けるので、今後は単純な性能改善だけでな く、どれほど省メモリ・省エネルギーで学習や予測ができるかという視点も大事ではないか。OpenAIも赤字続きと聞くし、単純 に計算力でスケールさせていくのは損益分岐点が高そうで懸念(しまだ) 
 • AIのエージェントの一部として人間が機能するという考え方は面白かった。我々のI/Oが遅いうえに、自然言語に縛られてい る(機械語で思考しながら脳に刺したプラグでAIと会話すれば一番いいのかもしれない)というのは、なんだかんだで使う人の 処理能力に依存しているのかも(しまだ) 
 • 古のリモセン感覚としてはデータやアルゴリズムは説明性を意識してしまうが、リモセンの処理の方向性でも大規模・大量に データを入れてエンコードしてしまおうというのは面白い考え方だった(しまだ) 
 勉強してみての感想(2/2) 

  32. 協調チャンネルの例 
 Self-planning Code Generation with Large Language Models 


    • エージェント間の協調が計画され、その後、実際にエージェントがコード作成タスクを遂行する例 

  33. 協調を行う段階 
 • 後期(late-stage)協調:協調目標に向けて、出力や行動 𝑦 をアンサンブルする 
 • 中期(mid-stage)協調:複数のモデル 𝑚のパラメータや重みを、連合学習(federated

    learning)やプライバシー保 護の形で交換する
 • 初期(early-stage)協調:データ、コンテキスト、環境の共有など、モデル開発のための情報交換(これに限定さ れない)
 

  34. Competitionは「対立を設計して推論を強化できる」が、条件次第で単体LLMに負けうる 
 • 競争環境は“戦略の変化”を誘発する(CompeteAI):Zhao et al. は、GPT-4エージェントで仮想タウン(レストラン同士が顧客 獲得で競争)を作り、競争が運営戦略の変化(新しい戦略の獲得)を促すこと、観察結果が市場・社会理論と整合することを 示した。
 •

    ゲーム系ベンチで競争能力を“測る”と弱点も見える(LLMArena):Chen et al. は、7つの動的ゲーム環境でLLMエージェントを 評価し、競争状況で必要な能力(空間推論・戦略計画・敵対者モデリング等)を測定可能にした一方、opponent modelingや team collaborationが依然として難所だと報告している。 
 • “Critic役”という競争(反証)が改善に効く(LEGO):He et al. は因果説明生成で、Explainerが出した説明をCriticが批判し反 復改善する設計を含む枠組みを提案し、反復フィードバックで説明品質を上げる方向性を示した(世界知識統合+多面的 フィードバック)。
 • ただし「競争を入れれば必ず強くなる」ではない(Wang et al.):Wang et al. は多エージェント議論を再検証し、プロンプトが十分 強い単体エージェントは、多エージェント議論と同等水準になり得ること、議論の典型失敗としてjudge mistakeや**wrong answer propagation(誤答の伝播)**を報告している。 
 • 設計上の含意:Competitionを“有益な競争”にするには、(1) 衝突の解消ルール(judge/投票/停止条件など)と、(2) 誤りの伝 播を止める検証線(Critic・根拠確認・最終統合の責務分離)が必要で、下手な設計だと単体に負けうる、という位置づけ 

  35. 5G/B6G と Industry 5.0 では、LLM-MAS が「意味理解+エッジ実行」の層として通信・運用をまとめて押し上げる 
 • Industry 5.0側の中心軸は「ローカル(オンプレ/エッジ)実行+協調」で、(i)プライバシー制約、(ii)多様なデバイスAPIの吸収、

    (iii)監視・異常検知の自動化を、LLM-MAS で実装できるかが主題として置かれている。 
 • GIoT(Xiao et al., 2024):商用LLMを避ける必要からオープンソースLLMをローカルネットワークに配置し、Prompt ManagementとPost-processingで性能を補う構成を提案。Table-QAの2データセットで SOTA LLMと競合する性能、かつ学習 なしで新規タスクへ拡張可能と報告している。 
 • SAGE(Rivkin et al., 2024):スマートホームで、ユーザ要求に対して **「行動→成功判定→次の行動」**を LLMプロンプト木 で制御する“grounded execution”を提案し、50タスクで **75% 成功(既存LLMベースラインは30%)**を報告している。 
 • CASIT(Zhong et al., 2024):IoT向けに**複数LLMの集合知(collective intelligence)**でデータ分析・異常検知を行い、段階 的な要約と分類でレポートを生成する“LLM-agent 기반IoT”を提示している(サーベイでも同趣旨で紹介)。 
 • 
 • (補足:没入型の Industry 5.0/6G 文脈)Internet of Senses(IoS)×6G では、生成AI/LLM を使った没入通信のアーキテク チャやケーススタディを議論する流れもあり、**「エッジでの生成・要約・再構成」**が帯域・遅延要求とセットで扱われる。 

  36. 5G/B6G と Industry 5.0 では、LLM-MAS が「意味理解+エッジ実行」の層として通信・運用をまとめて押し上げる 
 • Industry 5.0側の中心軸は「ローカル(オンプレ/エッジ)実行+協調」で、(i)プライバシー制約、(ii)多様なデバイスAPIの吸収、

    (iii)監視・異常検知の自動化を、LLM-MAS で実装できるかが主題として置かれている。 
 • 
 • 
 • GIoT(Xiao et al., 2024):商用LLMを避ける必要からオープンソースLLMをローカルネットワークに配置し、Prompt ManagementとPost-processingで性能を補う構成を提案。Table-QAの2データセットで SOTA LLMと競合する性能、かつ学習 なしで新規タスクへ拡張可能と報告している。 
 • SAGE(Rivkin et al., 2024):スマートホームで、ユーザ要求に対して **「行動→成功判定→次の行動」**を LLMプロンプト木 で制御する“grounded execution”を提案し、50タスクで **75% 成功(既存LLMベースラインは30%)**を報告している。 
 • CASIT(Zhong et al., 2024):IoT向けに**複数LLMの集合知(collective intelligence)**でデータ分析・異常検知を行い、段階 的な要約と分類でレポートを生成する“LLM-agent 기반IoT”を提示している(サーベイでも同趣旨で紹介)。 
 • 
 • (補足:没入型の Industry 5.0/6G 文脈)Internet of Senses(IoS)×6G では、生成AI/LLM を使った没入通信のアーキテク チャやケーススタディを議論する流れもあり、**「エッジでの生成・要約・再構成」**が帯域・遅延要求とセットで扱われる。 

  37. Coopetitionは「合意形成の協調」と「利得最大化の競争」を同居させ、適応的な切替で推論性能を押し上げられる 
 • 交渉ゲームで“協調×競争”を評価すると弱点が露出する(Davidson et al., 2024):交渉ゲームをLMのエージェンシー評価に 使い、6モデルをself-play / cross-playで比較した結果、(i)

    OSSモデルはタスク完了できない、(ii) 協調的バーゲニングが最も 難しい、(iii) 強いモデルが弱い相手に負けることがあると報告。 
 • “協調×競争+安全”を同時に含む交渉ベンチは極めて難しい(Abdelnabi et al., 2024):multi-agent・multi-issueのスコア可 能な交渉テストベッドを提案し、交渉が要求する能力を算術・推論・探索・計画として整理。評価ではGPT-3.5や小型モデルは ほぼ失敗し、GPT-4やLlama-3 70Bでも十分に解けない(underperform)と報告し、greedy/敵対的プレイヤの影響など安全面 も評価対象に入れた。
 • 協調と競争を“固定”せず、状況で切り替えると推論が強くなる(AdCo; Huang et al., 2025):推論時フレームワークAdaptive Coopetition (AdCo)を提案し、各ラウンドで粗いverifier信号に基づき「協調するか競争するか」を選択する(UCB:Upper Confidence Boundで探索/活用を制御)。高性能verifierに頼らず、数学推論ベンチで相対20%改善・設定に対して頑健と報 告。
 • (非対話の例)MoEも“協調×競争”として機能する(Read-ME; Cai et al., 2024):**MoE(Mixture-of-Experts)は、ルータ (gating/route)が入力ごとに専門家を選抜(競争)し、選ばれた専門家が合成されて最終出力を作る(協調)**構図。 Read-MEはdense LLMを小型MoEへ変換し、MMLU最大+10.1%、**平均E2Eレイテンシ最大-6.1%**を報告。 
 • この論文(2501.06322)での位置づけ:Coopetitionは「交渉のようなトレードオフ最適化」や「MoEの選抜と合成」のように、協調 と競争を同時に要求する局面を表す軸として整理されている(ただし深掘り研究はまだ少ない、という但し書き付き)。 

  38. Rule-basedは「手順(ルール)で相互作用を固定」することで、予測可能で再現性の高い協調を実現する 
 • RBの一般的な効果は、効率・予測可能性・デバッグ容易性(挙動を「どのルールが効いたか」に帰せる)で、手順が明確なタ スクで強い。一方で、想定外への適応が弱く、ルールが増えるとスケールしにくい。 
 • 合意形成(consensus seeking)では、LLMエージェントが“平均”ルールを自発的に選びやすい:Chen et

    al.(“Multi-Agent Consensus Seeking via Large Language Models”, 2023)は、数値状態を交渉で一致させる課題で、明示的に戦略を指示しな いと平均(average)戦略が主に選ばれること、さらに人数・性格・ネットワークトポロジが交渉過程に影響することを示した。 
 • 同研究は、このRB的な合意形成を**マルチロボット集合(aggregation)**に適用し、ゼロショットでの自律的な協調計画の可 能性をデモしている。
 • ピアレビュー手順(解く→査読→修正)を固定すると推論精度が上がる:Xu et al.(“Towards Reasoning in LLMs via Multi-Agent Peer Review Collaboration”, 2023)は、各エージェントが独立解答→相互レビュー(confidence付き)→改稿する ルール化プロトコルを提案し、複数の推論タスクで既存法より高い精度を報告(単なる解答共有よりフィードバック交換が有 効、能力差と多様性も重要)。 
 • 設計上の含意:RBは「何をいつ誰が言うか」を固定できるので、検証線(レビュー役/多数決/停止条件)を組み込みやすい 一方、環境変化が大きいタスクではルール更新コストとルール爆発がボトルネックになる 

  39. Role-basedは「役割=責務」を先に固定することで、分業の衝突を減らし協調をスケールさせる 
 • サーベイ(Tran et al., 2025)はRole-basedを、モジュール性・再利用性・性能の面で利点がある一方、役割設計が不適切だと 硬直・対立・連携ブロックが起き、依存関係が性能を左右すると整理している。 
 •

    AgentVerse(Chen et al., 2023):人間の集団ダイナミクスに着想し、役割を持つエージェント群を動的に編成して協調させる枠 組みを提案。実験でマルチエージェント群が単一エージェントを上回ること、協調過程で社会的行動が観察され得ることを報 告。
 • MetaGPT(Hong et al., 2024):ソフトウェア会社を模した複数役割を並べ、SOP(Standard Operating Procedures:標準作業手 順)をプロンプト列として符号化して工程を整流化。中間成果を相互検証でき、素朴な連鎖で起きる誤り(cascading hallucinations)の伝播を減らし、より一貫した出力を狙う設計として提示。 
 • ChatDev(Qian et al., 2024):要求分析・実装・テスト等の**社会的役割(roles)を持つ“software agents”を配置し、chat chain で「何を話すか」を、communicative dehallucinationで「どう話すか」を誘導。結果として完全性(completeness)・実行可能性 (executability)・要求整合性(consistency)**が改善したと報告。 
 • CAMEL(Li et al., 2023):自律協調の失敗要因(例:role flipping等)に対し、role-playingとinception prompting(会話開始時に 役割と方針を“種”として埋め込む誘導)で、最小限の人手からでもタスク完遂に向けて会話を自己推進させる枠組みを提案。 
 • LEGO(He et al., EMNLP Findings 2023):5つの役割(Cause/Effect Analyst, Knowledge Master, Explainer, Critic)を role-playingで割当し、世界知識統合+反復フィードバックで、spurious causal associations(もっともらしいが誤った因果の飛 躍)を抑えつつ因果説明を改善。WIKIWHY / e-CAREで多エージェント構成の優位性を報告。 
 • 設計上の含意(いつ効くか):Role-basedは「成果物が工程分解できる仕事」(例:要件→設計→実装→テスト、あるいはデー タ処理→学習→検証のようなパイプライン)で効果を出しやすい一方、役割境界や受け渡し仕様が曖昧だと、硬直化や連携 断がボトルネックになり得る。 

  40. Role-basedは「役割=責務」を先に固定することで、分業の衝突を減らし協調をスケールさせる 
 • サーベイ(Tran et al., 2025)はRole-basedを、モジュール性・再利用性・性能の面で利点がある一方、役割設計が不適切だと 硬直・対立・連携ブロックが起き、依存関係が性能を左右すると整理している。 
 •

    AgentVerse(Chen et al., 2023):人間の集団ダイナミクスに着想し、役割を持つエージェント群を動的に編成して協調させる枠 組みを提案。実験でマルチエージェント群が単一エージェントを上回ること、協調過程で社会的行動が観察され得ることを報 告。
 • MetaGPT(Hong et al., 2024):ソフトウェア会社を模した複数役割を並べ、SOP(Standard Operating Procedures:標準作業手 順)をプロンプト列として符号化して工程を整流化。中間成果を相互検証でき、素朴な連鎖で起きる誤り(cascading hallucinations)の伝播を減らし、より一貫した出力を狙う設計として提示。 
 • ChatDev(Qian et al., 2024):要求分析・実装・テスト等の**社会的役割(roles)を持つ“software agents”を配置し、chat chain で「何を話すか」を、communicative dehallucinationで「どう話すか」を誘導。結果として完全性(completeness)・実行可能性 (executability)・要求整合性(consistency)**が改善したと報告。 
 • CAMEL(Li et al., 2023):自律協調の失敗要因(例:role flipping等)に対し、role-playingとinception prompting(会話開始時に 役割と方針を“種”として埋め込む誘導)で、最小限の人手からでもタスク完遂に向けて会話を自己推進させる枠組みを提案。 
 • LEGO(He et al., EMNLP Findings 2023):5つの役割(Cause/Effect Analyst, Knowledge Master, Explainer, Critic)を role-playingで割当し、世界知識統合+反復フィードバックで、spurious causal associations(もっともらしいが誤った因果の飛 躍)を抑えつつ因果説明を改善。WIKIWHY / e-CAREで多エージェント構成の優位性を報告。 
 • 設計上の含意(いつ効くか):Role-basedは「成果物が工程分解できる仕事」(例:要件→設計→実装→テスト、あるいはデー タ処理→学習→検証のようなパイプライン)で効果を出しやすい一方、役割境界や受け渡し仕様が曖昧だと、硬直化や連携 断がボトルネックになり得る。 

  41. Model-basedは「不確実性と他者モデル」を明示して、動的環境でも協調を崩れにくくする 
 • Model-based(確率・モデル駆動)とは、知覚の不確実性や環境変動を前提に、入力・環境データ・共有目標を使って確率的 (probabilistic)に次行動を意思決定する協調戦略である。 
 • ToM(Theory of Mind:他者の信念・意図の推定)を組み込むと協調が進む:Li

    et al.(EMNLP 2023)は協力型テキストゲーム で、LLMエージェントに協調行動と高次ToMの兆候を観察した一方、長期文脈管理と状態の幻覚で計画最適化が崩れる課題 も示し、明示的なbelief state(信念状態)表現がタスク性能とToM推定精度を改善すると報告した。 
 • 「相手の信念を考える」場面がボトルネックになる:Agashe et al.(LLM-Coordination)は純粋協調ゲームで、LLMエージェント は環境変数中心なら強いが、相手の信念・意図の能動的考慮が必要になると苦戦し、ToM推論と共同計画に改善余地が大 きいことを示した(=Model-basedの必要性を実証的に示す位置づけ)。 
 • PGM(Probabilistic Graphical Model:確率変数の依存関係をグラフで表すモデル)で多者依存を扱える:Xu et al.(ICLR 2024, MAGIC)はLLMにPGMを“条件”として与えるPGM-aware agentを提案し、7指標(判断・推論・協調等)の総合で平均37%改善、 Chameleonゲームのケーススタディでも勝敗が改善する例を報告した。 
 • 確率論理+ToMで、部分観測下の人間協調が強くなる:Cao et al.(ICLR 2024)は、隠れたルールを潜在変数として扱う確率 論理で目標推定を行い、観測に応じて信念とサブゴールを更新しながら協調する枠組みを提案し、Watch-and-Help / HandMeThatで成功率や手数などでベースラインを有意に上回ると報告した。 
 • 形式モデルで「協調の安全・安定」を保証する方向もある:Mu et al.(2023)は異種マルチエージェントの自己適応を確率時間 オートマトン(Probabilistic Timed Automata)でモデル化し、スマート駐車のケースで、協調ロジックの正当性を担保しつつ正 常稼働時間が約21%向上すると報告した。 

  42. 中央集権は「ハブが統合・指揮する」ことで設計と資源配分が簡単になるが、単一点障害を抱える 
 • 中央集権(Centralized topology / star structure)は、全エージェントが中央エージェント(hub)に接続し、hubが管理・制御・調 停して協調を進める通信構造である。 


    • サーベイ整理では、中央集権の利点は (1)設計・実装が単純、(2)リソース配分が効率的である一方、欠点は (1)hubが故障す ると全体が崩れる、(2)撹乱に弱くレジリエンスが低い点にある。 
 • 同サーベイは中央集権をさらに2系統に分けている:Type-1「LLMは各クライアントに居て、中央は集約器(aggregator)」(例 :FedITのようなFL型)と、Type-2「LLMが中央に居て、中央が計画・統合を主導」(例:AutoAct)である。 
 • (QA:統合型の効果)LLM-Blenderは、複数LLMの候補出力を中央のPairwise Ranking(PairRanker)→生成融合(GenFuser) で統合する枠組みを提案し、最良単体モデルや既存アンサンブルより一貫して高性能になることを報告している(MixInstruct など)。
 • (生成効率:計画→並列展開)Skeleton-of-Thought(SoT)は、まず中央で回答の骨子(skeleton)を作り、その後に各ポイント を並列に展開することで、逐次デコードのボトルネックを回避し、生成の高速化(例:GPT-3.5/4で約2×のspeed-up)と、条件 によっては品質改善も起こり得ると報告している。 
 • (エージェント学習:中央の自己計画+分業生成)AutoActは、QAに対して人手や強いクローズドモデルに依存せずに計画軌 跡を自動合成し、タスク情報と軌跡から分業サブエージェント群を構成する。実験では強いベースラインに対し同等以上、か つdivision-of-laborと軌跡品質の有効性を示した。 
 • (意思決定:中央の“指揮者”で検証込み統合)Meta-Promptingは、単一LMをconductor(指揮者)として複数の“expert”問い 合わせを管理・統合し、(Python等の外部ツールも組み込みつつ)平均で+17%前後の改善を報告している=中央集権の「統 合役」をプロンプトとして実装した例。 

  43. 分散構造は「中央ハブなしのP2P/局所接続」で頑健性とスケールを得る一方、通信量と最適化の難しさを抱える 
 • サーベイ(Tran et al., 2025)の整理では、 
 • 分散構造の利点:(1)一部が故障しても動き続ける

    (2)スケールしやすい (3)各エージェントが自律的に適応できる 
 • 分散構造の欠点は (1)資源配分が非効率になりがち (2)通信オーバーヘッドが増えやすい 
 • 分散P2Pの“効能”の代表例:Multi-agent Debate。Du et al. (2023) は、複数のLLMインスタンスがラウンド制で互いの推論を 批判・更新する Multiagent Debateにより、数学/戦略推論が改善し、生成内容のfactuality(事実整合性)向上や幻覚の低減 も示した。
 • 
 • 通信トポロジを“設計変数”にすると性能が動く:EoT。Yin et al. (2023) は EoT(Exchange-of-Thought:クロスモデル通信)とし て、ネットワーク発想の複数パラダイム(Memory/Report/Relay/Debate)を提案し、誤った思考連鎖のリスクに対して confidence評価を組み込んだ上で、複数推論タスクでベースラインを上回ることを報告した。 
 • 
 • “最適な通信構造はタスクとメンバーで変わる”が示唆されている:サーベイは、固定の形が万能ではなく、タスクやエージェン ト構成により最適構造が変化する、という方向の報告が増えているとまとめている。 
 • 
 • 分散の中でも「動的グラフ化」が効く例:CR。Zhang et al. の **CR(Cumulative Reasoning)**は、命題を検証しながら **DAG (Directed Acyclic Graph:有向非巡回グラフ)**として推論を累積し、複数の難しい推論タスクで既存法より性能が上がること を示している(サーベイはこの“動的DAG構造”を分散構造の有効例として言及)。 
 • 
 • 通信量を抑えた分散協調の方向:ProAgent。Zhang et al. (2024) の ProAgentは、観測からチームメイトの意図を推定し、信念 を更新しながら行動を適応させることで、過剰な通信に頼らず協調する枠組みを提案している(=分散構造の“通信コスト課 題”への一つの打ち手)。 

  44. 階層構造は「レイヤ分業+隣接通信」でボトルネックを下げられる一方、設計複雑性と遅延が代償になる 
 • 階層構造の利点:(1)通信とタスクがレイヤに分散され低ボトルネック (2)資源配分がしやすい (3)タスクを上位→下位へオフ ロード可能
 • 階層構造の欠点: (1)エッジ(下位)故障が全体障害に直結しうる

    (2)複雑性とレイテンシが増える点 
 • DyLAN(Dynamic LLM-Agent Network; Liu et al., 2023):エージェントを多層(multi-layer)に組み、(1) Team Optimizationで貢 献度にもとづき有効エージェントを選抜し、(2) Task Solvingで選抜チームが協調する二段構えを提案。強いベースラインに対 して、コード生成・意思決定・推論・算術で性能と効率を両立し、MMLUの一部領域で最大+25%精度向上を報告。 
 • ChatDev(Qian et al., ACL 2024):要件→設計→実装→テストのように工程を分け、専門役割エージェントが対話して成果物 を作る枠組みを提案。コミュニケーション手順(chat chain)と幻覚抑制(communicative dehallucination)を組み合わせ、生成ソ フトウェアの completeness / executability / requirements整合性が改善したと報告。 
 • CAMEL(Li et al., NeurIPS 2023):**role-playing(役割演技)**と inception prompting(会話の初期条件で役割・方針を固定 する誘導)により、少ない人手の指示でもエージェント同士が自律協調してタスク完遂へ進む枠組みを提案(サーベイは図示 例として階層構造に位置づけ)。 
 

  45. • LLM を「復号の事前分布/外部知識」「マルチモーダル特徴の統合」「タスク分解」などに使い、従来の end-to-end 学習だけ では伸ばしにくい場面(低SNR・マルチユーザ・知識不足)を埋めにいく。 
 • LLM-SC(Wang et

    al., 2024):LLM を物理層の符号化・復号に直接適用し、受信側で言語系列の事前確率を使った最適復号 を導出。報告では SNR>3 dB で DeepSC を上回り、さらに **BER=10^-3 で約 8 dB の coding gain(チャネル符号化なし)** を得たとしている。
 • マルチモーダル拡張(LaMoSC / LAM-MSC): 
 • LaMoSC(Zhao et al., 2024)は、LLM の外部知識で生成したプロンプト文を使い視覚伝送向けのマルチモーダル融合 SemComを構成し、低SNR条件(例:SNR=4 dB)で Deep-JSCC / MLSC を上回ったと報告している。 
 • **LAM-MSC(Jiang et al., 2024)**は、**MLM(Multimodal Language Model)による Multimodal Alignment(MMA)**と、LLM 기반 Knowledge Base(LKB)で曖昧性・個人化を扱い、さらにチャネル推定(CGE)まで含めて総合的に性能優位を示したとし ている。
 • M2GSC(Yang et al., 2024):6Gの massive access を背景に、MLLM(Multi-Modal LLM)を共有知識ベース SKB(Shared Knowledge Base)として位置づけ、(1)複雑タスク分解 (2)意味表現の仕様化 (3)翻訳・マッピング を担わせることで、符号化の 標準化と復号の個別化を狙う(加えて、SKB を閉ループのエージェント化する/オフローディング設計などを研究方向として 提示)。
 • 運用(O&M)まで含めた「エージェント化」:**MSADM(Tang et al., 2024)**は **DHN(Dynamic Heterogeneous Networks)** のヘルスマネジメントを、異常検知→診断→緩和まで一気通貫で扱い、下流で CoT(Chain-of-Thought)型 LLM による解析 レポート生成を組み込む。異常検知では 91.31% の精度を報告している。 
 5G/B6G と Industry 5.0 では、LLM-MAS が「意味理解+エッジ実行」の層として通信・運用をまとめて押し上げる 
 Zhenyi Wang et al. (2025), “Large-Language-Model-Enabled Text Semantic Communication Systems”, arXiv:2407.14112v2. より引用
  46. QA/NLGでは、MASが「生成」だけでなく「評価」と「データ生成」を分業化して、実運用に耐える品質ループを作る 
 • 本サーベイは、LLMベースの MAS(Multi-Agent System:複数エージェント系) が、**QA/NLG(質問応答/自然言語生成)** の能力を押し上げる応用領域として「実務フレームワーク」「評価」「合成データ」の3方向の進展を整理している。 
 •

    
 • 実務フレームワーク(=役割分担でQA/NLGを回す):OpenAIの Swarm は、手順をまとめた routine と、会話状態を別エー ジェントへ移す handoff で複数エージェントをオーケストレーションし、カスタマーサポートのようなQA/NLGフローでの適用可 能性を示している。
 • 
 • 汎用マルチエージェント(QA/NLG+ツール実行):Magentic-One は、中央の Orchestrator(統括役) が計画・進捗追跡・エ ラー時の再計画を行い、Web操作・ローカルファイル操作・Python実行などの専門エージェントへ委譲する設計を提案してい る(=QA/NLGを“回答生成”で終わらせず、ツールで完遂させる方向)。 
 • 
 • 評価のMAS化(生成品質を“プロセスごと”判定):Agent-as-a-Judge(Zhuge et al., 2024)は、エージェントが別のエージェント を評価する枠組みを提案し、**DevAI(55個の現実的AI開発タスク、365の階層要件)**で検証。結果として LLM-as-a-Judge を大きく上回り、人手評価ベースライン並みに信頼できると報告している。 
 • 
 • ベンチマーク自体を“自己進化”させる評価:Benchmark Self-Evolving(Wang et al., 2024)は、複数エージェントで既存ベンチ の文脈/質問を改変して新しい難問を生成し、動的評価を可能にする。実験では、多くのLLMで元ベンチより成績が下がり、 モデル間・同一モデル内の差も広がって「本当の強み/弱み」が見えやすくなると述べている(データ汚染にも対処)。 
 • 
 • 合成データ生成(NLGを“データ工場”にする):AgentInstruct(Mitra et al., 2024)は、複数の agentic flows(生成フロー) で高 品質な合成データを作る枠組みを提案し、25MペアのデータでMistral-7Bをpost-trainした結果、**AGIEval +40%、MMLU
  47. 社会的・文化的ドメインにおけるマルチエージェントシステム(MAS)の応用 
 • 本サーベイはS&C応用を、LLM-MASが人間行動・社会ダイナミクス・文化的相互作用をシミュレートし、社会現象理解の新し い方法論になり得る領域として位置づける(ただし単体LLMの偏りや限界も強調)。 
 • 社会シミュレーションの実証例(Generative Agents; Park

    et al., 2023):LLMに記憶(経験ログ)→要約的内省(reflection)→計 画(planning)を持たせた25体のエージェントを仮想環境で動かすと、招待が伝播してパーティが成立する等の創発的な社会 行動が観察され、各モジュールが“それらしさ”に寄与することをアブレーションで示した。 
 • 「人間代替の限界」を測る枠組み(Turing Experiment; Aher et al., 2023):LLMを“人間参加者の代替”として評価するための **TE(Turing Experiment)**を提案し、特定の行動は再現できても、**一貫した歪み(distortions)**が露呈する=人間実験 の完全代替には注意が必要、という知見を提示した。 
 • 文化バイアス低減に向けたデータ生成(CulturePark; Li et al., 2024):異文化の役割を持つエージェント同士の対話で41kの 文化データを生成し、文化別に微調整したモデルが (a) content moderationでGPT-4相当以上、(b) cultural alignmentで GPT-4超え、(c) cultural educationでも学習効果・UXで優位、を報告(=MASを“文化データ収集装置”として使う価値)。 
 • 文化常識の蒸留(MANGO; Nguyen et al., 2024):概念×文化の2入口からLLMを反復プロンプトして統合し、167kの高精度な 文化知識アサーションを構築。対話システムに知識を付与すると、人手評価で応答の質・具体性・文化的配慮が改善すること を示した(=“知識ベース+生成”をMASで回す方向)。 
 • サーベイは同時に、学習データ由来の偏り(例:心理的多様性の不足)などから、単体LLMを普遍的な社会モデルとして扱う ことへの警鐘を述べ、S&C応用でも標準化ベンチマークが必要だと整理している。 

  48. 中村 凌 株式会社天地人 / SatAI.challenge 主宰 / cvpaper.challenge HQ •

    株式会社天地人データサイエンティスト (2024/04 - 現在) • SatAI.challenge 主宰(2024/09 - 現在) • cvpaper.challenge HQ(2021/1 - 現在 ) • 福岡大学大学院 理学研究科 応用数学専攻 博士課程(2021/04 - 2024/03) • 産業技術総合研究所 コンピュータビジョンチーム RA(2021/05 - 2024/03) • 福岡大学大学院 理学研究科 応用数学専攻 修士課程(2019/04 - 2021/03) 自己紹介 Twitter LinkedIn 54 これまでの個人的な活動 • 研究効率化Tips (ViEW2021招待講演) • 国際会議への論文採択実績(IROS / ICCV 2023, ICASSP / ECCV2024) • CCCS,W2021/2022 GC PC(登録者800名超え) • SSII2023オーディエンス賞受賞 • SatAI.challenge運営(国際論文の日本語資料・動画のアーカイブ化)
  49. 自己紹介 
 55 研究テーマ :3次元モデリング、サロゲートモデル、動的システム、土木インフラ 55 X(旧 Twitter) LinkedIn 産総研

    - サロゲートモデル: 制御x深層学習モデル - 土木インフラxAI: インフラ劣化予測 篠原 崇之
  50. 56 自己紹介
 平出 尚義 (ひらで なおよし) 
 
 ・一般財団法人 リモート・センシング技術センター

    (RESTEC) 
 ・筑波大学大学院 博士課程後期1年生 (2025/04 -, 社会人D) 
 
 - 国/地域レベルでの土地利用土地被覆分類 
 - 衛星の校正検証 (ラジオメトリック / ジオメトリック) 
 - 衛星データ×AI系 (抽出、分類、超解像、基盤モデル) 
 土地利用土地被覆図作成 
 校正検証業務 (現地測量) 

  51. 青木 亮祐(ぴっかりん) • 株式会社パスコ 研究開発センター ◦ 地理空間情報×AIで色々行ったり、その環境整備 • Project PLATEAU

    ADVOCATE 2025 • 一般社団法人OSGeo日本支部( OSGeo.JP ) 運営委員 自己紹介 57 X(旧Twitter) GitHub 過去に個人で行った衛星データ関連の発表
 個人開発したPLATEAU APIのMCPサーバー

  52. 藤野 倫太郎 東京理科大学大学院 創域理工学専攻 社会基盤工学研究科 修士1年   - 東京理科大学 水理研究室所属   - AcademiX(AIを学びたい学生が集まるコミュニティ)の運営メンバー   - 未踏アドバンス(2023)

    野球の動作解析アプリの開発 研究テーマ :河川橋梁洗掘(実験・混相流の数値計算) 59 興味のある分野:数値計算         人工知能全般(距離学習、GNN、サロゲートモデル) リモートセンシング 自己紹介
  53. 強化学習のAgentとこのAgentの違い 
 項目 強化学習エージェント LLMベースエージェント 主な目的 環境からの累積報酬を最大化 タスク目標に沿った出力を生成 行動選択 方策

    s)) に基づく 環境 明示的な状態・報酬がある コンテキストや外部情報、ツールなど 学習 試行錯誤(探索) を通じて学習 事前学習+プロンプト設計などで動作 出力の依 存 報酬に強く依存 目的やプロンプトに依存 探索が必要ないのか? LLMは大量のテキストデータで事前学習されています。 意味:既に一般的な知識や推論能力が備わっており、タスクに対して「すぐにある程度合理的な行動(出力)」を生成可能。 試行錯誤の代替 :大量のデータに基づく統計的パターン学習が、ある意味で「探索の省略」に相当します。 エージェントの目的 ooo や環境 eee を入力 xxx と一緒に提示することで、適切な出力 yyy を誘導。
  54. 導入:なぜ今MAS協調か(問題設定・狙い) 
 単体LLMの限界を、MASで“役割分担+相互作用”として解消する 
 • LLM単体は強力だが、ハルシネーション、逐次生成ゆえの計画の弱さ等の限界があり、外部ツール統合やエー ジェント化(Agentic AI)で補う流れがある。 
 •

    さらに近年は「横方向スケール」=複数LLMエージェントを並べて協調させ、集団として問題解決させる方向が加 速している。
 • MASの価値は
 ◦ (i)サブタスク分割と並列化 
 ◦ (ii)専門性の合成 
 ◦ (iii)相互チェックでの頑健化 
 • が同時に狙える点。 
 • ただし、エージェントを増やすだけでは破綻しやすく、協調“メカニズム”の設計が本質になる。 

  55. • リモセンとAI技術者に向けて 
 • MASについて(MASのオーバービューとなぜ活用するかがわかる) 
 ◦ 外観(Fig1)
 ◦ なぜMASが用いられている?

    
 ▪ 近年のAgentについて(LLM based Agentに付いての説明) 
 ▪ Agentを単体で用いる際の課題(LLm based Agentについての課題) 
 • MSAにつついての詳細(MASの原理や仕組みについて理解できる) 
 ◦ エージェントの定義
 ◦ 協働システムの定義 
 ◦ 問題設定
 • MASにおけるコラボレーション Fig2 (MAS研究の大きな分類) 
 ◦ actorsについて
 ◦ typeについて
 ◦ structureについて
 ◦ strategyについて
 ◦ coordinationについて 
 • MASを活用するための方法論 
 • 未解決問題と議論
 • 
 • 1 その分野の原理や仕組みについて理解できる 
 導入:なぜ今MAS協調か(問題設定・狙い) 

  56. 今日のアジェンダ 
 63 1. セクションごとに担当領域を決定(10分) 
 a. タイムキーピング・全体調整係(スライドのレイアウトの修正や足りないところにアサインする担当) 
 b.

    各セクションの担当
 2. 各章の要点を事実チェック・人手で修正する&図を差し込む 40分 
 3. 各セクションの横断修正・全体理解 10分 
 4. 読み合わせ10分
 5. 感想書く時間 10分
 6. 反省
 
 前回の反省
 LLMの要点書き出し・修正で思ったより時間がかかりすぎた。→事前にLLMの要点の書き出しを行い、修正に注力 
 どうやったら改善できる? 
 今回は謎のホワイトペパー過ぎたので、ある程度体型づいた論文だといけるかも? 
 ChatGPTの要約が思ったよりいけてなかった。(要約と理解のしやすさに距離があった) 
 ↑NotebookMLを使って理解を深める仮定には意味があるかも? 
 

  57. 1. Introduction 1人(柴田、篠原) 
 2. Earth AI Capabilities 2人 (中村、ピッカリン)

    
 ◦ Earth AI Models
 ▪ Imagery: Remote Sensing Foundations 
 ▪ Population: Population Dynamics Foundations 
 ▪ Environment: Weather & Climate Models 
 ◦ Combining Earth AI Models: Predictive Applications 
 ◦ Orchestration: Solving Complex Queries with Geospatial Reasoning Agents 
 3. 実験結果 2人 (嶌田、平出)
 ◦ Earth AI Models 
 ◦ Combining Earth AI Models: Predictive Applications 
 ◦ ~~~~
 4. Discussion 1人 (柴田、篠原) 
 5. Conclusion / Future Work1人(柴田、篠原) 
 
 64 XXXX 

  58. ワークショップの反省点・感想 
 • 遅刻してごめんなさい!途中参戦だと自分の明確な役割が定義しづらかったので、開始から参加できるように 業務調整します...。(平出) 
 • 実働60分で読むにはボリューム感がマシマシなので、だいぶ脳がしんどい(予習してきてもざっと見では所見技 術が多くて。。。)このボリューム感をまとめようと思うと、参加者側の勉強できる利点と、公開された資料を読む だけの人の利点がトレードオフになりそうなので、どっちかに振り切ったほうがやりやすいかも。とはいえ、マルチ

    エージェントの名前は知っててもよくわかってなかたったので良い機会。我々のやってたメタサーベイが数か月コ ネコネしてたボリューム感を読むのは大変ねえ。。。(篠原 
 • 新しい技術をどうリモセンに活かすか?という雑談が楽しかったです。 (平出) 
 • 個人的には技術論文を1本読むだけだと得られない知識があってよかった。(中村) 
 • ただ、今回のサーベイ論文のボリュームが大きくて、まとめきるのに時間がかかりすぎるのがボトルネック(中 村)
 • 役割分担に時間がかかりすぎたのは反省点。でも、みんなの興味に基づいて深ぼっていくという構造自体は大 変おもしろいし、ためになるなと思っています。(中村) 
 • 真面目に回そうと思うと事前の準備が大切だなと思っています。本来であれば、集まったからこそできるワーク に専念したいけど、そこをどう構築するか。。(中村) 
 • survey論文はどうしてもボリュームがあるので、2回に分けてとか行っても良いのかなと思いました。担当箇所が 表に出せる質かがちょっと心配。。。(青木) 
 • 全体像を大まかに示していただいていて,全体をあらかじめ理解した状態で細かい部分に集中できたので取り 組むことがはっきりしていてよかった.ただ,その細かい部分の主旨を理解するのに時間がかかってしまってうま くまとめられなかった(藤野) 
 • LLMの理論系は正直なところ専門知識がない分野なので、自分としては話を聞くのはとても面白いが、逆に皆さ 65
  59. 出席
 66 神山さん
 参加
 書記
 篠原さん
 中村さん
 不参加
 中村さん
 嶌田さん


    佐々木さん
 青木さん
 草さん
 平出さん
 笹川さん
 柴田さん
 藤野さん
 河内さん