次回の更新記事:MetaのLLM『Muse Spark 1.1』評価報告を読み解く。コ…(公開予定日:2026年07月13日)
AIDBは、AI活用のノウハウ獲得や技術動向の調査のために、個人やチームが論文を探す・読む・活かす作業をサポートするプラットフォームです。なお、記事や投稿は人の手で書いています。

ソフトウェア開発におけるLLMマルチエージェントの設計パターン

2025.11.19
深堀り解説

エージェントがチームのように動いてコードを書いたり、要件をまとめたりする仕組みは、すでに開発の現場に入りつつあります。でも実際のところ、どんな設計がされていて、どのポイントが重視されているのかは、あまり見えていませんでした。

そこで今回は、ソフトウェア開発にLLMベースのマルチエージェントシステムをどう設計しているかを詳しく調べた事例を取り上げます。

背景

「マルチエージェントシステム」という仕組みが注目されています。複数のエージェントが協力してタスクを解決する仕組みのことを指します。LLMベースのマルチエージェントシステムでは、複数のエージェントがそれぞれ専門的な役割を持ち、対話しながら協力してタスクを進めます。

ソフトウェア開発の分野でとくに期待が高まっています。たとえば、ソフトウェアシステム全体を自動で開発したり、要件定義といった開発の初期段階を進めることに応用できると考えられています。

もちろん、実用レベルで使うには効果的な設計が欠かせません。良い設計を行うことが信頼性や保守性、拡張しやすさ、安全性といった品質に直結します。また、設計次第で複数のエージェントがどのように協力するか、たとえば自発的に動くのか、決められた手順に従うのか、予期せぬ破壊的な行動を取らないかといった振る舞いが変わります。

そのため設計思想を体系化するのは重要ですが、設計の実態における知見は欠けています。設計者がどの品質属性を重視し、どのような再利用可能な設計パターンを用いているのか、なぜその設計を選んだのかといった設計根拠についてこれまでの状況を整理する必要があります。

そこで本記事では、LLMベースのマルチエージェントシステムをソフトウェア開発に活かす際にどのような設計パターンがあるのかを詳しく見ていきます。

忙しい人向けに、重要なポイント5選

  1. LLMを使ったマルチエージェントシステムでは、成果物が正しく動くかどうかがもっとも重要
  2. エージェントごとに役割を分けて設計すると、システムのモジュール化が進み、保守がしやすくなる
  3. 人間がソフトウェアを開発するやり方を参考にすれば、タスクの分け方や確認の仕組みを自然に取り入れられる
  4. 全体の約半数のシステムが、性能の高さと保守のしやすさの両方を意識して設計されている
  5. 開発から保守まで一貫して支援できるシステムの開発が進んでおり、今後はこうした形が主流になっていくと考えられる

参照文献情報

  • タイトル:Designing LLM-based Multi-Agent Systems for Software Engineering Tasks: Quality Attributes, Design Patterns and Rationale
  • URL:https://doi.org/10.48550/arXiv.2511.08475
  • 著者:Yangxiao Cai, Ruiyin Li, Peng Liang, Mojtaba Shahin, Zengyang Li
  • 所属:Wuhan University, RMIT University, Central China Normal University

94本の論文をもとにマルチエージェントシステム設計を4つのポイントで整理

研究者らはLLMベースのマルチエージェントシステムが、ソフトウェア開発タスク向けにどのように設計されているかを整理して理解するために、4つの問いを設定しました。

タスクや品質など4つのポイントに注目する

1つ目の問い どのようなソフトウェア開発タスクに使われているか

まずはどんな場面で活用されているかを整理し、今後の応用や研究の方向性を見極めます。

2つ目の問い 設計時にどのような品質属性が意識されているか

品質属性とは、信頼性や保守性、性能などのいわゆる非機能要件のことです。実用的な設計の勘所をつかむために、どの品質が重視されているかを知る必要があります。

3つ目の問い どのような設計パターンが用いられているか

現場で「使い回しのできる解き方」を整理すれば、よくある問題に対応することができます。

4つ目の問い 設計パターンにおける設計根拠

タスクに応じてどのような設計を選ぶべきかを考えるために、設計者の狙いや判断理由を明らかにします。

サーベイ論文とarXivから94本の関連論文を集めた

調査対象のデータは、論文から収集されました。まず、LLMベースのエージェントシステムに関する最近のサーベイ論文2本が出発点とされました。Liuらのサーベイには118本、Wangらのサーベイには115本の論文が含まれていました。

あわせて、より網羅的な収集をめざして、プレプリントサーバであるarXivからも論文が追加されました。「大規模言語モデル」と「エージェント」をキーワードにソフトウェア工学カテゴリが検索され、2024年9月30日までに公開された194本の論文が取得されました。

これら3つのソースを統合し、重複を除くことで、236本の論文が得られました。ここから研究に関連する論文を選ぶために、次の3つの条件が設けられました。①少なくとも1つのマルチエージェントシステムを提案していること。②そのエージェントがLLMを用いて機能を実装していること。③少なくとも1つのソフトウェア開発タスクに取り組んでいることです。最終的に、これらの条件を満たす94本の論文が対象として選定されました。

論文から抽出するデータ項目は4つ。1つ目はソフトウェア開発タスク、2つ目は品質属性、3つ目は設計パターン、4つ目は設計根拠です。

調査全体の流れ

コード生成が最も多く、機能の正確性が最重視される

研究者らは、調査の結果、4つの研究課題それぞれについて一定の傾向があることを確認しました。

10種類のタスクのうちコード生成が47.9%で最多

LLMベースのマルチエージェントシステムが取り組んでいるソフトウェア開発タスクは、「コード生成」が全体の47.9%とほぼ半数を占めることが分かりました。

次に多かったのは「障害箇所特定」で、全体の9.6%でした。エラーの原因となるコード部分を特定するタスクです。

「エンドツーエンドのソフトウェア保守(問題検出から修正までをつなげて扱う保守タスク)」と「プログラム修正」は、それぞれ8.5%でした。

そのほか、「エンドツーエンドのソフトウェア開発」が7.4%、「コードレビュー」と「ソフトウェアテスト」がそれぞれ6.4%、「要件定義」が3.2%、「コード変換」と「ソフトウェアデプロイメント」がそれぞれ1.1%という分布になっていました。

94.7%が機能適合性を重視し機能正確性が最優先課題

品質属性を分析してみると、LLMベースのマルチエージェントシステムにおいては、いくつかの属性が特に重視されていることが分かりました。

まず最も多かったのは「機能適合性」で、94.7%の論文で扱われていました。システムが「必要な機能を正しくこなせているか」を示すものです。とくに「正しい結果を出せるか(機能正確性)」が多く、生成したコードが仕様どおりに動くかどうかが、設計者にとって大切なポイントになっていました。

次に多かったのは「性能効率」で、51.1%でした。CPUやメモリなどのリソースを使いすぎず、決められた時間内に処理を終えられるかが意識されていました。ここでは「リソースの使い方」と「処理の速さ」が同じくらい重視されています。

「保守性」も50.0%と高く、あとから修正したり機能を足したりしやすいことが求められていました。中でも「モジュール性」が多く、システムを部品ごとに分けて管理しやすくする考え方がよく使われていました。

そのほかの属性としては、信頼性が36.2%、柔軟性が25.5%、互換性とセキュリティがそれぞれ10.6%、インタラクション能力が9.6%という結果でした。

役割分担による協力と自己省察が主要な設計手法

設計パターンを整理した結果、以下の16種類が使われていることを確認しました。

設計パターン名(英語)日本語ひとことで言うと割合
Role-Based Cooperationロール分担協調エージェントごとに役割と責任を分けて協調させる46.8%
Self-Reflection自己振り返り各エージェントが自分の出力や行動を自己評価・修正する36.2%
Tool-Agent Registryツール登録レジストリツール群を一元管理し、タスクに応じて適切なツールをエージェントに割り当てる14.9%
Cross-Reflection相互振り返りエージェント同士が互いの出力をチェック・批評して精度を高める12.8%
Retrieval-Augmented Generation (RAG)検索拡張生成外部知識ベースから情報を検索し、その結果を生成に取り込む10.6%
Agent Adapterエージェントアダプタ異なるエージェントや外部システムとのインタフェースを標準化し、データ変換を担う6.4%
Human-Reflection人間フィードバック反映人間の評価やコメントを取り込み、エージェントの振る舞いを調整する5.3%
Single-Path Plan Generator単一路線プランナー直線的な一つの手順計画を作り、サブタスクに分解して実行させる5.3%
Prompt/Response Optimiserプロンプト最適化プロンプトやレスポンスを反復的に改良し、精度と一貫性を高める4.3%
Debate-Based Cooperation議論ベース協調賛成・反対など複数エージェントに議論させて、より妥当な結論を採用する4.3%
Layered-Based Cooperationレイヤ構造協調役割や抽象度ごとにレイヤを分け、階層ごとに異なるエージェントを配置する4.3%
Agent Evaluatorエージェント評価者専任の評価エージェントが他エージェントの成果物をテスト・採点する3.2%
Multi-Path Plan Generator複数経路プランナー複数の代替プランを並行生成し、より良い経路を選択する3.2%
Incremental Model Querying段階的クエリ複雑な課題を小さな問い合わせに分割し、段階的にLLMへ照会する3.2%
Hierarchical Coordination階層的コーディネーション必要に応じてエージェントやツールを段階的に増やしながら問題解決を進める3.2%
Voting-Based Cooperation投票ベース協調複数エージェントの候補解に対して投票し、多数決などで最終解を決める3.2%

生成コード品質向上が44.7%で最多の設計動機

設計根拠で最も多かったのは「生成コードの品質を上げる」で、44.7%を占めました。LLMが作るコードの質がそのまま成果物の質につながるため、多くの設計がここを重視していました。

次に多かったのは、人間がタスクを解く手順を参考にすることでより自然にタスクを進められるシステムを目指すという考え「人間の開発プロセスをまねる」29.8%でした。

計算やメモリなどをムダなく使う「リソース管理の最適化」も28.7%ありました。

続いて「成果物の生成効率を上げる」が24.5%でした。

「タスク解決の難しさを下げる」は20.2%でした。

そのほかには、「エージェントの適応性を高める」が19.1%、「成果物の多様性を広げる」が12.8%、「セキュリティを確保する」が4.3%という結果でした。

設計の実態から分かった6つの大事なポイント

調査結果をもとに、研究者らは実務で参考になる設計のポイントをまとめました。

どのタスクでも正確さが最優先、性能と保守性も半数が重視

まず、ソフトウェア開発タスクと品質属性の関係を調べたところ、いくつかの明確な傾向が確認されました。

品質属性主に重視されたサブ属性設計者がねらっていること
機能適合性機能正確性(86件)仕様どおりに動くコードを出し、デバッグや統合の手間を減らす
性能効率リソース利用・応答時間計算資源と時間のムダを抑え、高いレスポンスを保つ
保守性モジュール性(46件)ワークフローを部品に分け、差し替えや改修をやりやすくする
信頼性故障許容性誤りや不確実な出力があっても、全体として壊れにくい仕組みにする
柔軟性適応性変わる要件やプロンプトに合わせて、ふるまいを素早く調整できるようにする
互換性相互運用性既存の開発環境やツールチェーンとスムーズにつなぐ
セキュリティ機密性自動コード生成・分析の過程で機密情報を漏らさないようにする
インタラクション能力操作性・ユーザーエンゲージメントユーザーが操作しやすく、フィードバックを回しやすい対話を実現する

コード生成には役割分担と自己ふり返り、保守には効率的なリソース利用が効果的

タスク、品質属性、サブ品質属性、設計パターン、設計根拠の5つの要素を対応づけて分析したところ、タスクごとの設計の特徴がよりはっきりしました。

タスク主な設計パターン(件数)主な設計根拠(件数)設計のねらい
コード生成ロール分担協調(Role-Based Cooperation)18件 / 自己振り返り(Self-Reflection)18件生成コードの品質向上 25件役割分担と自己チェックで、正確で保守しやすいコードを出す
障害箇所特定ロール分担協調(Role-Based Cooperation)6件ソフトウェアリソース管理の最適化 5件並列に原因を探しつつ、計算資源のムダを減らす
エンドツーエンドソフトウェア保守ロール分担協調(Role-Based Cooperation)6件生成コードの品質向上 3件 / 人間プロセスのシミュレート 3件 / ソフトウェアリソース管理の最適化 3件 / ソフトウェア成果物の生成効率向上 3件長い保守フローを役割ごとに分けて、分かりやすく効率よく進める
プログラム修正ロール分担協調(Role-Based Cooperation)2件 / 相互振り返り(Cross-Reflection)2件 / 検索拡張生成(Retrieval-Augmented Generation)2件生成コードの品質向上 3件役割分担と相互チェック、外部情報の参照で修正精度を高める
エンドツーエンドソフトウェア開発ロール分担協調(Role-Based Cooperation)6件生成コードの品質向上 6件分業したエージェントで、品質の高い成果物を一気通貫で作る
コードレビューロール分担協調(Role-Based Cooperation)2件人間プロセスのシミュレート 4件人間のレビュー手順をまねて、多面的にコードをチェックする
ソフトウェアテスト自己振り返り(Self-Reflection)3件生成コードの品質向上 3件自分で出力を見直すテストエージェントで、テストの質と多様性を上げる
要件定義ロール分担協調(Role-Based Cooperation)3件ソフトウェアリソース管理の最適化 2件 / 生成されるソフトウェア成果物の多様性向上 2件役割分担で並列に要件を詰めつつ、多様な候補案を出す
コード変換ロール分担協調(Role-Based Cooperation)1件タスク解決の難易度低減 1件複雑な変換処理を分割し、負荷を下げて進めやすくする
ソフトウェアデプロイメント自己振り返り(Self-Reflection)1件 / エージェントアダプタ(Agent Adapter)1件ソフトウェアセキュリティの確保 1件デプロイ時の問題を自律的に検知しつつ、環境ごとに安全に統合する

良い成果物を作ることをまず第一に考える

調査から得られた最初の示唆は

「成果物の品質を最優先にすべき」

という点です。

とくに機能正確性は、調査対象の91.5%のシステムで最重要視されていました。これは、成果物が仕様通りに動作し、タスクを確実にこなせるかに直結します。

そのため、設計段階で品質を重視する姿勢が求められます。たとえば以下のような取り組みが有効です。

  • 形式的または半形式的な仕様による要件の明確化
  • 自動テストと手動テストの組み合わせによる広範な検証
  • 実行環境に近い状況での継続的なテスト

また、「生成されるコードの品質」は、44.7%の設計根拠として言及されていました。
LLMによるマルチエージェントシステムでは、コード生成が主要なタスクになっています。しかし今後は、コード以外の成果物(例:設定ファイルや構成定義)の品質確保も重要になります。

成果物の品質は、以下のような観点で実用性を左右します。

  • 要件を満たしているか
  • 既存のシステムと無理なく統合できるか
  • 実運用下で保守しやすいか

つまり、品質を意識した設計は、システム全体の信頼性や継続的な活用に直結するといえます。

役割を分けることでモジュール化が進み、保守しやすくなる

2つ目の示唆は、

「LLMベースのマルチエージェントシステムでは、役割分担が保守性の向上につながる」

ということです。

分析の結果、保守性はモジュール性に支えられており、モジュール性は役割ベースの協力から生まれていると分かりました。
つまり、役割を明確に分けて設計することで、関心の分離が進み、機能ごとにエージェントを独立させることができます。
その結果、個別のコンポーネントだけを対象に、更新やテスト、改善がしやすくなります。

役割ベースの設計では、各エージェントが独自のロジックやプロンプト設計、ツールとのやり取りを持ちます。
こうした分離によって、各エージェントを個別に開発・デバッグ・テストできるようになります。
また、全体の構造を大きく変えずに、特定のエージェントだけを置き換えたり強化したりすることも可能になります。

さらに、役割ごとにふるまいが明確に分かれているため、問題の原因を特定のエージェントに絞り込みやすくなります。
このように、役割分担に基づく設計は、システムの保守性と柔軟性を高める鍵になります。

人の開発プロセスを参考にすることで設計の質が上がる

3つ目の示唆は、LLMベースのマルチエージェントシステムの開発において、

「人間中心のソフトウェア開発のやり方が参考になる」

という点です。

分析の結果、人間の開発プロセスを模倣する設計が全体の約30%を占めていました。これは、設計者が人間の開発方法に着想を得てシステムを作っていることを示しています。

人間中心のやり方を参考にすることで、タスクの分け方や役割の専門化、調整や検証といった原則を取り入れやすくなります。その結果、システムの動きがわかりやすくなり、検証もしやすく、より壊れにくくなると考えられます。

たとえば、人間のチームが行う開発スタイルや認知の仕組みを参考にできます。タスクを段階的に分けたり、注意を分散させたり、記憶容量の制限やミスの見つけ方などの工夫です。こうした知見を応用すれば、役割の明確化やタスク分解、検証のチェックポイントなどを含む軽めの調整プロトコルに落とし込めます。

もちろん課題もあります。人間とエージェントでは前提や能力が違いますし、やりとりの仕方が曖昧だったり、やったことの良し悪しを判断しにくい場合もあります。ただ、こうした問題も、人間が評価に関わる反復的な開発や、認知のしくみを参考にした設計を取り入れることで、ある程度は解消できます。

開発の流れ全体を助ける仕組みが広がっている

LLMベースのマルチエージェントシステムを使って、

設計者がソフトウェアのライフサイクル全体を支援する取り組みが広がりつつあります。

エンドツーエンドの保守や開発を目的としたシステムの導入事例が少しずつ増えています。2023年には対応する論文はごく少数でしたが、2024年には発表数が倍増しています。特に、エンドツーエンドの保守に関する論文はすべて2024年に集中しています。

統一的なマルチエージェントシステムは、要件定義から保守までの一貫した知識を持ち、設計やコーディング、テストの基準を通して一貫性を保つのに役立ちます。

一方で、ライフサイクル全体を対象とした研究が少ない背景には、いくつかの課題があります。たとえば、全体を通した評価基準の不在や、各開発フェーズ間の整合性確保の難しさがあります。また、個別に最適化されたツール同士が、うまくつながらないこともあります。

とはいえ、個々の開発タスクに対する研究やツールの蓄積が進んでおり、設計者たちはライフサイクル全体を支えるシステムの構築に意欲的になっています。

リソースと時間をできるだけ節約する設計が求められる

5つ目の示唆は、

マルチエージェントシステムの設計では、時間やリソースの無駄を減らす工夫が重視されている

という点です。

設計者は、ソフトウェアリソースの管理を最適化し、成果物の生成を効率化することで、時間やリソースのコストをできるだけ抑えようとしています。

分析では、「リソース管理の最適化」が28.7%、「成果物の生成効率向上」が24.5%の割合で設計の動機に挙げられていました。さらに、時間のかかり方(タイムビヘイビア)とリソースの使われ方については、それぞれ27件の設計事例で考慮されていました。

これらの要素は、マルチエージェントシステムの実用性や性能に直結します。たとえば、処理が遅いとユーザー体験を損ね、リアルタイム性が求められるタスクでは支障が出ます。一方で、リソースの使い方が非効率だと、コストがかさみ、スケールが難しくなり、性能の限られた端末では動かせなくなります。

そのため、設計者たちは、時間と空間のコストを減らすためのさまざまな工夫をこらしているのです。

高い性能と保守しやすさを両立させる方向へ進んでいる

最後に6つ目の示唆として

設計者は、性能と保守性のバランスを取るように工夫している

ことが挙げられます。

LLMベースのマルチエージェントシステムでは、処理の速さや効率だけでなく、長期的な保守のしやすさも大切にされています。

分析では、約半数のシステムでパフォーマンス効率(51.1%)と保守性(50.0%)のいずれかが設計時に重視されていました。そして22.3%のシステムは、両方を同時に意識して作られていました。

つまり、即時の効率性と長期のメンテナンス性を両立できるよう、設計者たちは工夫しているということです。

こうした両立を目指すには、役割の分担とその調整の仕方が重要なポイントになります。たとえば、特定の仕事だけを担うエージェントを用意すれば、通常の処理はスムーズにこなしつつ、難しい状況には別の手厚い対応ができるようになります。

まとめ

本記事では、LLMベースのマルチエージェントシステムをソフトウェア開発に活用する際の設計の実態を、94本の学術論文を分析して明らかにした事例を取り上げました。

調査の結果、もっとも多く扱われていたのはコード生成のタスクでした。重視されていた品質属性は「機能が正確に動くかどうか」で、これは91.5%のシステムで最重視されていました。設計パターンとしては「役割ベースの協力」が最も多く使われており、背景には生成コードの品質を高めたいという意図が見られました。

これらの知見から、次のような実務的な示唆が得られました。成果物の品質を最優先にすること。役割分担によってモジュール性を高めること。人間中心の開発手法から学ぶこと。パフォーマンスと保守性の両立を意識すること。また、最近ではソフトウェアのライフサイクル全体をカバーする動きも加速しており、より統合的な設計が進みつつあります。

LLMを業務に取り入れる際は、こうした設計の原則を理解しておくと、より効果的で信頼性のあるシステム構築に近づけるかもしれません。

記事検索

年/月/日
年/月/日

こちらもどうぞ