1件の営業メール作成に30〜45分かかっていた問題を、4エージェントのパイプラインで自動化 — Thrad.aiの実測でSwarmよりGraphが29%高速、AWSが構築詳細を公開

7月15日、AWSが「Multi-agent social intelligence with Strands Agents and Amazon Bedrock」と題した記事を公開した。AIプラットフォーム企業Thrad.aiがAWSと共同で構築したマルチエージェントシステムの実装詳細を紹介する内容で、注目すべきはオーケストレーションパターンの実測比較だ。同一の50件見込み客データセットでSwarmとGraphを比較したところ、Graphは平均レイテンシでSwarmより29%速く（45秒→32秒）、トークン消費でも約29%少ないという結果が得られている。このベンチマークはThrad.aiが実施し、AWSが公式ブログで紹介した形だ。

1件のメール作成に30〜45分かかっていた問題

AIプラットフォーム企業Thrad.aiは、LLM（大規模言語モデル）内での広告配信インフラを構築している。同社の営業チームは、Hacker News・Reddit・Stack Overflow・GitHubなど6つのソースにまたがって各見込み客を手動でリサーチしており、1件のアウトリーチメール作成に30〜45分を費やしていた。

問題の核心は「シグナルの分散」にある。あるスタートアップがHacker Newsにプロダクトをローンチしつつ、Reddit r/SaaSで「X用のツールは何を使うべきか？」と質問し、GitHubのスターが2,400件を超えているとする。各シグナル単体はノイズだが、複数ソースで相関が取れれば「購買意欲の高い見込み客」が浮かび上がる。1つのAIエージェントでこれを処理するには、ソースAPIの多様性と分析の複雑さが大きすぎる。そこでThrad.aiが選んだのが、AWSのオープンソースフレームワークStrands Agentsを使ったマルチエージェントアーキテクチャだ。Strands AgentsはAWSが2025年にオープンソースとして公開したPython製のエージェントフレームワークで、SwarmとGraphの両オーケストレーションパターンをサポートしている。

4エージェント構成のパイプライン

記事が紹介するシステムは、4つの専門エージェントで構成される。

Trend ResearchとSearch Specialistが並列で動き、Analysis Agentが両方の結果を待ってからスコアリングを実行する。スコア60以上の見込み客だけがEmail Generationに渡される仕組みだ。

スコアリングは5つの重み付き基準で構成される：トピックの一致度（25%）、タイミングの関連性（20%）、エンゲージメントポテンシャル（20%）、意図シグナル（20%）、データ品質（15%）。さらに、オープンソース展開とB2Bフォーカスを持つデベロッパーツールにはICP（理想顧客プロファイル）マッチングで最大10ポイントのボーナスが加算される。シグナルの鮮度も考慮され、24時間以内のシグナルには1.5倍、7日以上経過したシグナルには0.5倍の重みが適用される。

Redditツールは5つのサブレディット（r/SaaS, r/startups, r/devtools, r/selfhosted, r/Entrepreneur）を監視し、投稿を「推奨を求めている」「競合への不満」「プロダクトローンチ」「購買意図」の4カテゴリに分類する。

最大の設計判断：SwarmかGraphか

パイプラインの骨格が決まったあと、Thrad.aiが次に直面したのが「どのオーケストレーションパターンを選ぶか」という問題だ。記事のエンジニアリング的な核心は、2つのパターンの実測比較にある。

Swarmはhandoff_to_agentツールを通じてエージェントが動的に制御を渡す方式。Analysisエージェントがデータ不足と判断すれば、Trend Researchに折り返して追加コンテキストを要求できる。設定例：

swarm = Swarm(
    agents=[trend_agent, search_agent, analysis_agent, email_agent],
    entry_point=trend_agent,
    max_handoffs=15,
    execution_timeout=1200.0,
    repetitive_handoff_detection_window=8,
    repetitive_handoff_min_unique_agents=3,
)

repetitive_handoff_detection_windowとrepetitive_handoff_min_unique_agentsは無限ループ防止のパラメータで、記事は「この設定なしでは2エージェント間でピンポンが起きる」と明記している。

Graphは有向グラフで実行順序を固定する方式。並列エントリーポイントと条件付きエッジをコードで宣言する：

builder = GraphBuilder()
builder.set_entry_point("research")
builder.set_entry_point("search")

wait_for_both = _all_dependencies_complete(["research", "search"])
builder.add_edge("research", "analysis", condition=wait_for_both)
builder.add_edge("search", "analysis", condition=wait_for_both)
builder.add_edge("analysis", "email", condition=_score_above_threshold)

Thrad.aiが同一の50件見込み客データセットで実測した結果は以下のとおりだ：

1,000件バッチでGraphを選ぶと、Swarmと比べて約3.6時間の処理時間削減と約$20のコスト削減になるという試算だ。一方でメール品質はSwarmが8.2、Graphが7.6と、Swarmに軍配が上がっている。動的なハンドオフによって見込み客ごとに情報を補完できるぶん、出力の質が高まる傾向があるようだ。

Thrad.aiはこの結果を受け、毎夜のバッチ処理にはGraph、週次の高価値見込み客への深掘り分析にはSwarmという使い分けを採用した。記事はシンプルな選択基準を提示している：ワークフローが反復可能で予測可能なレイテンシが必要ならGraph、入力品質が不均一でエージェントが適応する必要があるならSwarm。両方を同一コードベースに実装し、設定フラグで切り替えることも可能だ。

Amazon Bedrock AgentCoreによる本番デプロイ

プロダクション運用のために、システムはAmazon Bedrock AgentCoreの4つのサービスを使用する。なお、記事公開時点でAgentCoreがGA（一般提供）かパブリックプレビューかの明示はないため、実際に採用を検討する際はAWSの公式ドキュメントでサービスステータスを確認していただきたい。

• Runtime：エージェントを分離されたmicroVM（軽量仮想マシン）上でホスト。IAM認証、15分アイドルタイムアウト、8時間最大ライフタイムを管理
• Gateway：9つのツールに対する単一のMCP（Model Context Protocol）エンドポイントを提供。MCPはAnthropic発のオープン標準で、AIエージェントと外部ツール・データソースをつなぐプロトコルだ。エージェントは起動時にツールを動的に発見する
• Memory：セッション内の短期コンテキストとセッション横断の長期セマンティクスデータを保存
• Observability：OpenTelemetryによる分散トレーシング。スパン単位のレイテンシとトークン数を計測し、Amazon CloudWatchと連携

実際の運用で、Thrad.aiはトレースデータを分析した結果、YouTube APIの呼び出しが全体レイテンシの40%を占めていることを発見した。この知見をもとに指数バックオフ付きのリトライ処理を追加している。Observabilityレイヤーがなければ特定が困難だったボトルネックであり、分散トレーシングの実用的な価値を示す事例といえる。

インフラはAWS CDKで定義されており、コンパニオンリポジトリからクローンしてcdk deploy --allで展開できる。ハンズオン実行にかかる費用は概算で**$3〜$5**（Amazon Bedrockのモデル呼び出しコスト）。ただし、デプロイしたリソース（DynamoDBテーブル、Lambda関数、AgentCoreサービス）はチュートリアル完了後に削除しないと継続課金が発生する点は注意が必要だ。

詳細はMulti-agent social intelligence with Strands Agents and Amazon Bedrockを参照していただきたい。