LLM_MultiAgents_Survey_Papers：IJCAI 2024 サーベイ論文の付随リストをどう使うか

このリポジトリが埋めている穴は、コードではなく文献の所在だ

LLM ベースのマルチエージェント研究は2023年前半から論文が急増した。問題は、増え方が分野ごとにバラバラだったことにある。ソフトウェア開発、社会シミュレーション、ゲーム、経済、推薦、政策決定。同じ「マルチエージェント」という語で呼ばれていても、引用すべき先行研究も、評価に使うデータセットも違う。横断的に読もうとすると、まずどこから手を付けるかで止まる。

このリポジトリは、その停止を避けるための索引である。README は収録論文を5つの系統に分けている。Multi-Agents Framework、Multi-Agents Orchestration and Efficiency、Multi-Agents for Problem Solving、Multi-Agents for World Simulation、Multi-Agents Datasets and Benchmarks の5つだ。Problem Solving と World Simulation はさらに下位分類を持つ。前者は Software development、Embodied Agents、Science Team for Experiment Operations、Science Debate、Database。後者は Society、Game、Psychology、Economy、Recommender System、Policy Making、Disease propagation Simulation に分かれる。

対象読者は、マルチエージェント系の研究テーマをこれから決める大学院生か、社内でエージェント構成を検討していて先行事例の当たりを付けたいエンジニアだ。論文を読む前の段階で、どの系統に何があるかを一望したい人に向く。

5分類はサーベイ本文の構造をそのまま写したもの

このリストは独立した分類ではなく、親となるサーベイ論文の構成に対応している。README は冒頭で arXiv:2402.01680 を指し、その上で「Our summarized LLM-based Multi-Agents architecture is」として LLM-MA.png を、概要表として overview.png を掲げている。分類の定義や各論文の位置づけは画像と論文本文側にあり、README のテキストは見出しと書誌情報の列にとどまる。

つまり README 単体では分類の根拠が分からない。なぜ AutoGen が Framework に入り、crewAI が Orchestration and Efficiency に入るのか。README からは読み取れない。ここは実際に使うときに引っかかる点で、索引として使うなら arXiv:2402.01680 の該当節を並べて開く前提で読むべきだ。

各エントリの書式は統一されている。日付、タイトル、著者名、そして arXiv または GitHub へのリンク。日付は [2024/03] のような形式で先頭に付く。この並びは分類内では新しい順に見えるが、README に明示的な説明はない。日付だけを頼りに「この分野の最新動向」を判断するのは避けたほうがよい。

収録範囲にははっきりした偏りがある

README の News 節には [2024/02] の項目として「We will update our paper list every two weeks and include all the following papers in the next version of our paper」とある。更新は2週間ごとの予定で、リストに載った論文は次版の論文本文に取り込まれる、という運用だ。

ただし Orchestration and Efficiency の節を見ると、2026/04 の CORAL、2025/10 の CoMAS、2025/04 の Achilles Heel of Distributed Multi-Agent Systems といったエントリが並ぶ。日付表記が [2026/04] の形で、他の節と書式は同じだが、この節だけ年が先に進んでいる。リポジトリ全体の最終 push は 2026-08-21 なので、更新自体は続いていると読める。

偏りは更新頻度より中身にある。Framework 節は AutoGen、MetaGPT、CAMEL、AgentVerse、AutoAgents といった実装を伴う有名どころを2023年から2024年にかけて並べる。一方 Problem Solving の Software development 節は XUAT-Copilot、AgentCoder などテストやコード生成に寄った論文が中心で、World Simulation 節は社会・心理・経済のシミュレーション研究が並ぶ。分野横断の索引ではあるが、各分野の網羅性は均一ではない。自分の分野が薄いと感じたら、それはこのリストの性質であって、その分野に論文がないという意味ではない。

動かすものではない。clone して読むだけのリポジトリ

このリポジトリにはインストール手順も設定ファイルもない。README に書かれているのは論文リストと画像への参照だけである。したがって「セットアップ」に相当する操作は、リポジトリを手元に持ってくるか、GitHub 上で README を読むかの二択になる。

手元に置く場合のコマンドは次のとおり。

git clone https://github.com/taichengguo/LLM_MultiAgents_Survey_Papers cd LLM_MultiAgents_Survey_Papers

clone したディレクトリには README と、trend.png、LLM-MA.png、overview.png の3つの画像が置かれている。README が参照するのはこの3つだ。実行するスクリプトも、依存を解決する requirements.txt も、この時点では確認できない。

設定キーに相当するものも存在しない。強いて言えば README 内のアンカーリンクが唯一のナビゲーションで、Table of Content から #multi-agents-framework のような見出しへ飛ぶ。読む側の作業は、気になる節を開き、arXiv リンクを辿り、必要なら著者名で検索する、という流れになる。

なおライセンスはリポジトリ情報からは取得できていない。論文リストの再利用や転載を考える場合は、README に記載がない以上、著者への確認が要る。ここは推測で埋めない。

索引としての弱点は、鮮度と重複の管理が見えないこと

第一の弱点は、同じ論文が複数の分類に現れうる構造だ。マルチエージェントの議論手法は Framework にも Orchestration and Efficiency にも読める。README には重複をどう扱うかの記述がない。節をまたいで読むと、同じ論文に二度出会う可能性がある。

第二に、各エントリに短い注記がない。日付、タイトル、著者、リンクのみで、その論文が何を主張しているかは README からは分からない。100件近いリンクを前に、どれから読むかを決める手がかりは分類と日付だけである。

第三に、更新の運用が README の宣言と一致しているかを外から検証しにくい。News 節の「every two weeks」は2024年2月時点の予定であり、その後の運用実績は README からは読み取れない。最終 push の日付は分かるが、どの節がいつ最後に更新されたかは分からない。

こうした弱点は、このリポジトリが論文の付随物として作られたことに由来する。単体で完結するデータベースではなく、arXiv:2402.01680 を読むための補助輪だと考えるほうが実態に近い。

代替としての Papers with Code、違いは分類の出所

同じ用途でよく使われるのが Papers with Code だ。あちらは機械的にタスクとデータセットへ割り当て、ベンチマーク結果の表を各論文に紐づける。実装リンクやリーダーボードが付く点が利点で、数値比較をしたいときに向く。

このリポジトリは逆の設計である。分類は著者らがサーベイを書くために手で切ったもので、機械的なタグ付けではない。だから Problem Solving の下に Science Debate や Database のような、他では見かけない切り口が立つ。一方で、Papers with Code のようにベンチマークの数値や実装の有無を横並びで比較する機能は持たない。

使い分けは単純だ。ある手法の性能を比べたいなら Papers with Code、ある分野でどんな問題設定が試されているかを把握したいならこのリポジトリ、という住み分けになる。両方を見て、片方にしか出てこない論文を拾う読み方も有効だ。

メンテナンス費用とライセンスの扱い

このリポジトリを自分の作業に組み込む場合、かかる費用は clone の手間と、リンク切れの確認だけである。ビルドもテストもない。ただし README が参照する画像ファイル名（trend.png、LLM-MA.png、overview.png）に依存するため、fork して構成を変えると README の表示が壊れる。

更新は上流に依存する。自分で追記したい場合は README の Contributing 節と Contact 節が用意されているが、本文には具体的な投稿手順が書かれていない。プルリクエストの形式や採否基準は README からは確認できない。

ライセンスはリポジトリ情報から取得できていない。論文リストという性質上、各論文の著作権は個々の著者に帰属し、このリポジトリのライセンスとは別に扱う必要がある。リストを社内資料や別の索引に転載する場合は、リポジトリのライセンスと各論文のライセンスを分けて確認することになる。ここで法的な判断はできない。

維持コストの見積もりは、上流が更新を続ける限りにおいて低い。逆に上流が止まれば、このリポジトリは2024年前半のスナップショットとして固定される。そのときは自分で arXiv を検索する運用に戻すしかない。

編集部の結論

文献の地図が欲しい人、とくにフレームワーク系と問題解決系の代表論文を短時間で押さえたい人には向いている。逆に、動くコードやベンチマーク実行環境を探している人には向かない。このリポジトリには実装も評価スクリプトも含まれておらず、各エントリは arXiv リンクと著者名の列にすぎない。採用を検討する前に確認すべきは、まず arXiv:2402.01680 の本文で5分類の定義を読み、次に README の News 節にある「every two weeks」という更新頻度の記述が実際の最終 push（2026-08-21）と整合しているかを自分の目で確かめることだ。分類の境界が自分の関心分野と合わなければ、この索引は使えない。

公式情報源

1. Issues
2. Project website
3. README
4. taichengguo/LLM_MultiAgents_Survey_Papers on GitHub