📄 論文解説: MetaGPT — SOP駆動マルチエージェント協調フレームワーク

論文概要（Abstract）

MetaGPTは、人間のソフトウェア開発チームにおける標準業務手順（SOP: Standard Operating Procedures）をLLMエージェントに埋め込むことで、マルチエージェント協調の品質と効率を大幅に向上させたフレームワークである。Product Manager、Architect、Engineer、QA Engineerなどの役割をエージェントに割り当て、各役割が構造化された成果物（要件定義書、設計ドキュメント、コード、テスト）を順次生成する。HumanEvalで85.9%、MBPPで87.7%を達成し、GPT-4単体（67.0%）を大幅に上回った。

この記事は Zenn記事: Gemini 3.1 Proで構築するマルチエージェント協調コーディングの実践手法 の深掘りです。

情報源

• arXiv ID: 2308.00352
• URL: https://arxiv.org/abs/2308.00352
• 著者: Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, et al.
• 発表年: 2023年（初版）、2024年にv2改訂
• 分野: cs.AI, cs.SE
• コード: https://github.com/geekan/MetaGPT（MIT License）

背景と動機（Background & Motivation）

LLMベースのマルチエージェントシステムには「babbling problem」と呼ばれる深刻な課題がある。複数のエージェントが自由に対話すると、会話が発散し、事実と異なる出力（ハルシネーション）が連鎖的に増幅される。例えば、あるエージェントが生成した誤ったAPI仕様を別のエージェントが鵜呑みにしてコードを書き、さらに別のエージェントがそのコードを基にテストを書く——という破綻が容易に起こる。

従来のマルチエージェントフレームワーク（ChatDev、CAMEL等）は自由形式の対話に依存しており、エージェント間の情報伝達が非構造的であった。人間のソフトウェア開発チームが機能するのは、明確な役割分担と構造化された成果物（設計書、API仕様書、テスト計画書）によるコミュニケーションがあるからである。MetaGPTはこの知見をLLMエージェントに適用した。

主要な貢献（Key Contributions）

• SOP駆動の役割分担: ソフトウェア開発のウォーターフォール工程（要件定義→設計→実装→テスト）をエージェントの役割として明示的にコード化。各エージェントが構造化された成果物を出力する
• MessagePoolによる共有メモリ: 全エージェントが共有するメッセージプールを導入。各エージェントは自身の役割に関連するメッセージのみをサブスクライブし、情報のオーバーフローを防止
• 構造化出力の強制: 各エージェントが自由文ではなく、テンプレートに従った構造化ドキュメント（PRD、設計図、コード）を出力することで、下流エージェントの解析精度を保証
• 実行可能コードの生成率向上: SoftwareDevベンチマーク（70タスク）で実行可能コードの生成率が単一エージェント方式を大幅に上回り、タスク当たりのコストを約$0.2に削減

技術的詳細（Technical Details）

アーキテクチャ

MetaGPTは以下の5つの役割エージェントで構成される。

役割	入力	出力（成果物）	担当Action
Product Manager	ユーザー要件（自然言語）	PRD（Product Requirements Document）	WritePRD
Architect	PRD	システム設計書、API仕様書、データモデル	WriteDesign
Project Manager	設計書	タスク分割、依存関係グラフ	WriteTasks
Engineer	タスク + API仕様	実装コード	WriteCode
QA Engineer	コード	テストコード	WriteTest

処理は上流から下流へ順次実行される（ウォーターフォール型）。これはZenn記事で紹介されているGemini 3.1 Proの3層構造（計画層→実行層→検証層）と対応する。

メッセージングアーキテクチャ

MetaGPTのメッセージングはPublish-Subscribe（Pub/Sub）パターンを採用している。

\[\text{MessagePool} = \{m_1, m_2, \ldots, m_n\}\]

各エージェント $A_i$ は関心のあるメッセージタイプ $T_i \subseteq {T_1, T_2, \ldots, T_k}$ をサブスクライブする。

\[\text{Inbox}(A_i) = \{m \in \text{MessagePool} \mid \text{type}(m) \in T_i\}\]

ここで、

• $m$: メッセージ（構造化された成果物を含む）
• $T_i$: エージェント $A_i$ がサブスクライブするメッセージタイプの集合
• $\text{type}(m)$: メッセージ $m$ のタイプ

例えば、ArchitectエージェントはProductManagerの出力（PRD）のみをサブスクライブし、QA Engineerの出力は受け取らない。これにより不要な情報によるコンテキスト汚染を防ぐ。

構造化成果物の具体例

Product Managerが生成するPRDの構造：

class ProductRequirement:
    """Product Requirements Document structure"""
    original_requirements: str     # ユーザーの元の要件
    competitive_analysis: list     # 競合分析
    requirement_pool: list[tuple]  # (要件, 優先度P0-P2)
    user_stories: list[str]        # ユーザーストーリー
    ui_design_draft: str           # UI設計の概要
    anything_unclear: str          # 不明点

class SystemDesign:
    """Architectが生成するシステム設計"""
    implementation_approach: str   # 実装アプローチ
    python_packages: list[str]    # 必要パッケージ
    file_list: list[str]          # ファイル一覧
    data_structures: dict         # データモデル定義
    program_flow: str             # mermaid形式のフロー図

Architectエージェントは設計書の中にMermaid形式のシーケンス図・クラス図を含める。これが下流のEngineerエージェントにとって実装の正確な指針となる。

アルゴリズム

MetaGPTの実行ループを以下に示す：

from metagpt.roles import ProductManager, Architect, Engineer, QAEngineer
from metagpt.team import Team
from metagpt.logs import logger

async def run_metagpt_pipeline(user_requirement: str) -> dict:
    """MetaGPT パイプラインの実行

    Args:
        user_requirement: ユーザーの要件（自然言語）

    Returns:
        生成されたプロジェクトファイル群
    """
    team = Team()
    team.hire([
        ProductManager(),
        Architect(),
        Engineer(n_borg=3),  # 3つのEngineerインスタンス
        QAEngineer(),
    ])

    team.invest(investment=5.0)  # APIコスト上限（$5）
    team.run_project(idea=user_requirement)

    result = await team.run(n_round=10)
    return result

各エージェントの実行サイクル：

class Role:
    """エージェントの基底クラス"""

    async def _act(self) -> Message:
        """1ステップの行動を実行"""
        # 1. 関連メッセージをMessagePoolから取得
        messages = self._rc.memory.get_by_actions(self._watch_actions)

        # 2. 現在のActionを実行（例: WritePRD, WriteCode）
        result = await self._rc.todo.run(messages)

        # 3. 結果を構造化メッセージとしてMessagePoolに公開
        msg = Message(
            content=result,
            role=self.profile,
            cause_by=type(self._rc.todo),
        )
        self._rc.memory.add(msg)
        return msg

実装のポイント（Implementation）

構造化出力の強制

MetaGPTの最も重要な実装上の工夫は、各エージェントの出力をJSON/Markdownテンプレートで強制する点にある。

WRITE_PRD_PROMPT = """
## Output Format
Return a JSON object with the following fields:
- "original_requirements": string
- "competitive_analysis": list of strings
- "requirement_pool": list of [requirement, priority] pairs
  where priority is one of "P0", "P1", "P2"
- "user_stories": list of strings

## Important
- Each field MUST be filled
- Priority P0 = must-have, P1 = should-have, P2 = nice-to-have
"""

LLMの出力を直接パースするため、JSONスキーマに従わない出力はリトライされる。

コスト管理

MetaGPTはトークン使用量を厳密に管理する：

• 各エージェントのコンテキスト長を制限（最大4,096トークンの要約を保持）
• MessagePoolのメッセージは古いものから要約・圧縮
• invest() でAPIコストの上限を設定し、超過時にパイプラインを停止

タスク当たり平均$0.2（GPT-4使用時）は、SWE-agentの$4/タスクと比較して大幅に安価である。

Gemini 3.1 Proとの対応

Zenn記事のGemini 3.1 Pro 3層構造との対応関係：

Zenn記事の構成	MetaGPTの構成	共通点
計画層（Planner, thinking=high）	ProductManager + Architect	タスク分解・設計
実行層（Coder, thinking=medium）	Engineer（複数インスタンス）	コード生成
検証層（Reviewer, thinking=medium）	QA Engineer	テスト・品質検証

MetaGPTのSOP駆動アプローチとGemini 3.1 Proのthought signatures + ADKオーケストレーションを組み合わせることで、より堅牢なマルチエージェントパイプラインを構築できる可能性がある。

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

トラフィック量別の推奨構成:

規模	月間リクエスト	推奨構成	月額コスト	主要サービス
Small	~3,000 (100/日)	Serverless	$80-200	Lambda + Bedrock + DynamoDB
Medium	~30,000 (1,000/日)	Hybrid	$400-1,000	Lambda + ECS Fargate + ElastiCache
Large	300,000+ (10,000/日)	Container	$2,500-6,000	EKS + Karpenter + EC2 Spot

Small構成の詳細 (月額$80-200):

• Lambda: 1GB RAM, 60秒タイムアウト、マルチエージェントオーケストレータ ($25/月)
• Bedrock: Claude 3.5 Haiku（各エージェント用）、Prompt Caching有効 ($100/月)
• DynamoDB: On-Demand、MessagePool永続化 ($15/月)
• SQS: エージェント間メッセージキュー ($5/月)
• CloudWatch: 基本監視 ($5/月)

コスト削減テクニック:

• Bedrock Batch API使用で50%割引（非リアルタイムのコード生成に最適）
• Prompt Caching有効化でシステムプロンプト部分のコストを30-90%削減
• 役割別モデル選択: Product Manager/ArchitectにはSonnet、EngineerにはHaikuを使用

コスト試算の注意事項:

• 上記は2026年2月時点のAWS ap-northeast-1（東京）リージョン料金に基づく概算値です
• 実際のコストはトラフィックパターン、リージョン、バースト使用量により変動します
• 最新料金は AWS料金計算ツール で確認してください

Terraformインフラコード

Small構成 (Serverless): Lambda + Bedrock + SQS

# --- IAMロール（最小権限） ---
resource "aws_iam_role" "agent_orchestrator" {
  name = "metagpt-orchestrator-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy" "bedrock_invoke" {
  role = aws_iam_role.agent_orchestrator.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"]
      Resource = "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-*"
    }]
  })
}

# --- Lambda: マルチエージェントオーケストレータ ---
resource "aws_lambda_function" "orchestrator" {
  filename      = "orchestrator.zip"
  function_name = "metagpt-orchestrator"
  role          = aws_iam_role.agent_orchestrator.arn
  handler       = "main.handler"
  runtime       = "python3.12"
  timeout       = 300
  memory_size   = 1024

  environment {
    variables = {
      BEDROCK_MODEL_PLANNER = "anthropic.claude-3-5-sonnet-20241022-v2:0"
      BEDROCK_MODEL_CODER   = "anthropic.claude-3-5-haiku-20241022-v1:0"
      SQS_QUEUE_URL         = aws_sqs_queue.agent_messages.url
      DYNAMODB_TABLE        = aws_dynamodb_table.message_pool.name
    }
  }
}

# --- DynamoDB: MessagePool永続化 ---
resource "aws_dynamodb_table" "message_pool" {
  name         = "metagpt-message-pool"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "session_id"
  range_key    = "message_id"

  attribute {
    name = "session_id"
    type = "S"
  }
  attribute {
    name = "message_id"
    type = "S"
  }

  ttl {
    attribute_name = "expire_at"
    enabled        = true
  }
}

# --- SQS: エージェント間メッセージング ---
resource "aws_sqs_queue" "agent_messages" {
  name                       = "metagpt-agent-messages"
  visibility_timeout_seconds = 300
  message_retention_seconds  = 86400
}

# --- CloudWatch: コスト監視 ---
resource "aws_cloudwatch_metric_alarm" "lambda_cost" {
  alarm_name          = "metagpt-cost-spike"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name         = "Duration"
  namespace           = "AWS/Lambda"
  period              = 3600
  statistic           = "Sum"
  threshold           = 200000
  alarm_description   = "Lambda実行時間異常（コスト急増の可能性）"
  dimensions = {
    FunctionName = aws_lambda_function.orchestrator.function_name
  }
}

セキュリティベストプラクティス

• IAMロール: 最小権限の原則。BedrockのInvokeModel権限のみ付与
• シークレット管理: Secrets Manager使用、環境変数へのハードコード禁止
• ネットワーク: Lambda VPC内配置、パブリックサブネット不使用
• 暗号化: DynamoDB/SQSともにKMS暗号化有効
• 監査: CloudTrail全リージョン有効化

運用・監視設定

import boto3

cloudwatch = boto3.client('cloudwatch')

# Bedrock トークン使用量アラート
cloudwatch.put_metric_alarm(
    AlarmName='metagpt-token-spike',
    ComparisonOperator='GreaterThanThreshold',
    EvaluationPeriods=1,
    MetricName='TokenUsage',
    Namespace='Custom/MetaGPT',
    Period=3600,
    Statistic='Sum',
    Threshold=500000,
    AlarmDescription='MetaGPTトークン使用量異常'
)

コスト最適化チェックリスト

• ~100 req/日 → Lambda + Bedrock (Serverless) - $80-200/月
• ~1000 req/日 → ECS Fargate + Bedrock (Hybrid) - $400-1,000/月
• 10000+ req/日 → EKS + Spot Instances (Container) - $2,500-6,000/月
• Bedrock Batch API: 50%割引（非リアルタイム処理）
• Prompt Caching: 30-90%削減（役割別システムプロンプト固定）
• 役割別モデル選択: Planner=Sonnet, Coder=Haiku
• DynamoDB On-Demand: 低トラフィック時に最適
• SQS: メッセージTTL設定でストレージコスト削減
• Lambda Reserved Concurrency: 不要な並列実行を防止
• CloudWatch Logs: 保持期間を30日に設定（コスト削減）

実験結果（Results）

ベンチマーク	GPT-4単体	ChatDev	MetaGPT	改善率（vs GPT-4）
HumanEval	67.0%	73.7%	85.9%	+28.2%
MBPP	—	—	87.7%	—
SoftwareDev (70タスク)	—	実行可能率低	実行可能率高	—

MetaGPTの特筆すべき点は、タスク当たりのコストが約$0.2に抑えられている点である。ChatDevと比較して、生成コードの実行可能率が大幅に向上している。

SWE-Bench評価では直接的なスコアは公開されていないが、MetaGPTのSOP駆動アプローチはZenn記事で言及されているGemini 3.1 ProのSWE-Bench Verified 80.6%のようなエージェント性能向上に寄与する設計原則を提供している。

実運用への応用（Practical Applications）

MetaGPTのSOP駆動設計は、Zenn記事のGemini 3.1 Proマルチエージェント構成に直接応用可能である。

具体的な応用パターン:

1. ADK + SOP: Google ADKのSequentialAgentにMetaGPTの役割分担を適用する。PlannerAgent → CoderAgent → ReviewerAgentの各ステップで構造化出力テンプレートを定義し、出力品質を保証する

2. thinking_level × 役割: MetaGPTのProductManager（抽象的推論）にはGemini 3.1 Proのthinking_level=highを、Engineer（コード生成）にはmediumを割り当てることで、コストと品質のバランスを最適化

3. MessagePool → thought signatures: MetaGPTのMessagePoolによる状態管理を、Gemini 3.1 Proのthought signaturesで代替可能。thought signaturesはAPIレベルで推論状態を暗号化保持するため、明示的なメモリ管理が不要になる

関連研究（Related Work）

• ChatDev (Qian et al., 2023): チャットベースのマルチエージェントソフトウェア開発。MetaGPTとの違いは、ChatDevが自由形式の対話に依存する点
• CAMEL (Li et al., 2023): ロールプレイングによるマルチエージェント協調。汎用フレームワークだがSE特化の構造化出力がない
• AgentVerse (Chen et al., 2023): マルチエージェント協調の汎用フレームワーク。動的なエージェント構成が特徴だが、SOP的な制約がない

まとめと今後の展望

MetaGPTは「構造化された成果物による情報伝達」と「SOP駆動の役割分担」により、マルチエージェントコーディングの品質を大幅に向上させた。Zenn記事のGemini 3.1 Pro + ADKとの組み合わせにおいて、以下が示唆される：

• thinking_level制御とSOP駆動設計の組み合わせでコスト最適化が可能
• thought signaturesによりMessagePool的な状態管理を簡素化できる
• ADKのSequential/Parallelワークフローにより、MetaGPTのパイプラインをより柔軟に定義できる

今後はLLMの推論能力向上に伴い、より少ないエージェント数で同等の品質を達成できる可能性がある。Gemini 3.1 Proのmediumレベルの導入はその方向性を示唆している。

参考文献

• arXiv: https://arxiv.org/abs/2308.00352
• Code: https://github.com/geekan/MetaGPT（MIT License）
• Related Zenn article: https://zenn.dev/0h_n0/articles/a7935e0412571c