Strands Agents と Amazon Bedrock を活用したマルチエージェント社会知能

見込み顧客は複数の情報源に痕跡を残します。例えば、ある創業者が r/SaaS で「X には何を使うべきか？」と質問する一方で、その製品が Hacker News でローンチされ、Stack Overflow の質問数が急増し、GitHub リポジトリのスター数が 2,400 を突破します。これらのシグナルを単独で捉えてもノイズに過ぎませんが、複数の情報源間で相関関係を見出せば、「購入準備完了」の状態にある顧客が浮かび上がります。

Strands Agents と Amazon Bedrock AgentCore を活用したマルチエージェントシステムを使えば、こうしたソーシャルインテリジェンスを大規模に自動化できます。

AI 向けの広告インフラを構築している Thrad.ai は、LLM（大規模言語モデル）内に有料広告を導入するプラットフォームを提供しています。チャットインターフェースを通じて広告収益化を実現し、ブランドがその中で広告を出稿できる仕組みです。同社が直面したのは、特にシグナルの多いこの課題でした。

これらのパターンを手動で追跡するのはスケーラブルではなく、文脈を欠いた一般的なアプローチでは、メールを開封する価値さえ生まれません。Thrad.ai の営業チームは、1 通のアウトレッチメールを作成するために、6 つの情報源にわたって各リードに対して 30〜45 分もの調査時間を費やしていました。

単一の AI エージェントではこの課題を解決できません。シグナルの多様性が広すぎ、ソース API の種類が多岐にわたり、分析には高度なニュアンスが必要だからです。マルチエージェントによるオーケストレーションを採用すれば、各情報源を専門のエージェントに割り当て、それらの結果を統合する専用分析エージェントがクロスソースのパターンを検出します。

本記事では、Thrad.ai が Strands Agents と Amazon Bedrock AgentCore を活用してマルチエージェントシステムを構築し、見込み客の発見からパーソナライズされたメール生成までのパイプラインを自動化した事例を紹介します。また、レイテンシ、コスト、メールの質における直接比較ベンチマークを通じて、「Swarm」と「Graph」の 2 つのオーケストレーションパターンを対比します。

さらに、重み付け基準や意図分類、時間経過による減衰（テンプラル・デケイ）を用いた見込み客スコアリング手法と、本番環境での運用に必要なガバナンス制御についても解説します。これらのパターンは、競合調査や候補者選定、市場リサーチなどにも応用可能です。

詳しくは、コンパニオンリポジトリ をご参照ください。

前提条件

本記事では、Python と AWS Cloud Development Kit (AWS CDK) の基礎知識、そして大規模言語モデル（LLM）の概念についてある程度の理解があることを想定しています。

• Amazon Bedrock にアクセスできる AWS アカウント（Claude Sonnet 4.6 モデルの有効化済み）と Amazon Bedrock AgentCore の利用権限
• Amazon DynamoDB、AWS Lambda、AWS Secrets Manager、および AWS CDK に対するアクセス権限
• Python 3.12 以上、Node.js 18 以上
• strands-agents>=1.25.0、bedrock-agentcore[strands-agents]>=1.2.1、pydantic>=2.12.5

ハンズオンでのデプロイには約 60 分、費用は Amazon Bedrock のモデル呼び出しで概ね 3 ドルから 5 ドル程度を見込んでいます。

重要：デプロイしたリソース（DynamoDB テーブル、Lambda 関数、AgentCore サービス）は稼働中に課金されます。チュートリアル完了後は「クリーンアップ」の手順を必ず実行し、継続的なコストが発生しないようにしてください。

注釈：この投稿の概念を理解するだけであればデプロイは不要です。実際にコードを実行するには、事前に必要な環境を整えておく必要があります。

# Clone the companion repository
git clone https://github.com/aws-samples/sample-multi-agent-social-intelligence-strands-agentcore
cd sample-multi-agent-social-intelligence-strands-agentcore

# Install dependencies with uv
uv sync

# Deploy infrastructure
cd infra && cdk deploy --all

完全なセットアップガイド: README.md

ソリューションの概要

図 1 に示すアーキテクチャを採用すれば、ソーシャルからの生データ信号を自動的にパーソナライズされた outreach（アプローチ）に変換できます。発見、情報補完、スコアリング、メール生成という 4 つの工程をそれぞれ専門化するエージェントが担当し、各エージェントは独自のツールを持ち、出力には厳格な検証ルールを適用します。

Amazon Bedrock AgentCore Runtime、Gateway、Memory、Observability を活用した 4 エージェントのパイプライン

以下の表では、各エージェントの役割、使用するツール、および利用する AgentCore サービスを説明します。

2 つのエージェントが並列でデータ収集を開始します。トレンド調査エージェントは、Hacker News、YouTube、dev.to、ProductHunt、Reddit、Stack Overflow の 6 つのソースを照会し、注目のローンチや購入意欲を示すシグナルを探します。一方、検索専門エージェントは、Wikipedia、GitHub、Lobste.rs、Stack Overflow を活用して各見込み顧客の詳細情報を補完します。

両方のエージェントが完了すると、分析エージェントが Claude Sonnet 4.6 を Amazon Bedrock で使用し、各見込み顧客とトレンドの組み合わせを 0 から 100 のスコアで評価します。エージェントは グローバル推論プロファイル（global.anthropic.claude-sonnet-4-6）を利用し、リクエストを最も近い利用可能なリージョンにルーティングします。これにより、IAM ポリシーで特定のリージョン固有のモデル ARN を指定する必要がなくなり、マルチリージョン展開が効率化されます。高スコアの見込み顧客はメール生成エージェントへ引き継がれ、特定のトレンドに関連したパーソナライズされたメールメッセージが作成され、ブランドガイドラインに照らして各ドラフトが検証されます。

各エージェントは 1 つの責任と、1 つのツールセット、そして Pydantic で検証された出力契約を保持しています。Pydantic は Python のデータ検証ライブラリであり、実行時に型安全なスキーマを強制します。もしエージェントが誤った形式でデータを返した場合でも、システムは次のエージェントがそれを受け取る前に検出・処理します。

Reddit ツールは、r/SaaS、r/startups、r/devtools、r/selfhosted、r/Entrepreneur の 5 つのサブレディットをスキャンし、キーワードパターンマッチングを用いて投稿を「推奨を求める」「競合への不満」「製品リリース」「購入意図」の 4 つの意図カテゴリに分類します。もし Hacker News でのリリースが Reddit の「何を使うべきか？」というスレッドにも登場すれば、その見込み顧客の評価はさらに高まります。

このスコアリングは信号の三角測量に基づいています。つまり、少なくとも 2 つの独立したソースからの相関する証拠が必要です。Trend Research Agent はまず check_existing_leads を呼び出し、すでにパイプラインにある見込み顧客をスキップします。トレンド入りしている Hacker News の投稿でも、Reddit で議論がなく、Stack Overflow での活動もゼロで GitHub のスター数もない場合、それは単なるプロモーションの押し売りである可能性が高く、分析にトークンを消費する前にシステムがフィルタリングします。

Analysis Agent は 5 つの加重基準を適用します。トピックの整合性（25%）、タイミングの関連性（20%）、エンゲージメントの可能性（20%）、意図のシグナル（20%）、データの質（15%）です。Ideal customer profile (ICP) に合致する場合は、オープンソースでの存在感と B2B への焦点を持つ開発ツールに対して最大 10 ポイントのボーナス点が加算されます。また、時間経過による減衰もスコアを鋭くします。24 時間以内のシグナルは 1.5 倍の重みを持ち、7 日以上前のシグナルは 0.5 倍になります。

Strands orchestration: Swarm vs. Graph

ここでの中心的な設計判断は、4 つのエージェントをどう連携させるかです。Strands Agents は 2 つのオーケストレーションパターンを提供しています。Thrad.ai は両方のパターンを実装し、同じ 50 件の見込み顧客を対象としたワークロードで比較検証しました。以下では各パターンの仕組みを解説し、ベンチマーク結果を示します。

Swarm: 自律的なハンドオフ

図 2 は、共有コンテキストを活用した handoff_to_agent ツールを通じてエージェントが制御権を引き継ぐ様子を描いています。Swarm オーケストレーションでは、エージェントは動的に handoff_to_agent ツールを使って制御を渡します。トレンド調査エージェントが見込み顧客を発見すると、エンリッチメントのために検索スペシャリストへ引き継ぎます。次に検索スペシャリストが分析担当へ渡し、スコアリングを行います。データが不足している場合は、分析担当からトレンド調査へ戻して追加の文脈を取得することも可能です。各エージェントは共通の作業メモリを共有しています。

共有作業メモリを介した動的なエージェント間転送

Swarm の各エージェントは、共通コンテキストを持つ自律的な同僚として振る舞い、それぞれが専門家に引き継ぐタイミングを自ら判断します。トレンド調査が見込み顧客を発見して検索スペシャリストへエンリッチメントを依頼し、検索スペシャリストが分析担当へスコアリングを渡すという流れです。

データが不足している場合、Analysis は Trend Research に結果を返して、より多くの文脈を受け取ります。この双方向の引き渡しにより、エージェントは必要に応じて追加の情報を要求できます。

以下のコードは、安全性の制約を設けた Swarm の設定方法を示しています:

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,
)

繰り返される引き渡しのパラメータ設定が重要です。これを怠ると、2 つのエージェントが互いに無限に ping-pong 状態になりかねません。ウィンドウサイズを 8 にし、最小エージェント数を 3 人に制限することで、前進を強制しています。

Swarm は、 prospect の複雑さが変動し、エージェントが以前の段階へ再参加するメリットがある場合に最も効果を発揮します。ただし、実行パスの予測は難しくなり、引き渡しに伴う推論オーバーヘッドによりトークン消費量が増加します。

Graph:構造化されたワークフロー

図 3 は、並列的なリサーチと検索のエントリーポイントから始まり、分析で収束し、条件付きエッジを通じてメール送信へ至る有向グラフの仕組みを示しています。Graph オーケストレーションでは、エージェントは固定された有向ワークフローに従います。Trend Research と Search Specialist はエントリーポイントとして並列で実行され、Analysis は両者が完了するまで待機します。Email Generation は条件付きエッジによって制御され、prospect のスコアが 60 以上の場合のみ実行されます。

並列エントリー、全依存関係完了時のゲート制御、および条件付きスコア閾値

Graph パターンは、明示的な一方向のエッジを通じてエージェントを固定されたワークフローに接続します。トレンド調査と検索専門家は並列で実行されるため、データ収集にかかる時間を半分に短縮できます。分析タスクは両者の完了を待ってから開始されます。また、見込み顧客のスコアが 60 以上の場合のみメール送信が実行され、これがポリシーゲートとして機能します。

以下に、並列エントリポイントと条件付きエッジを持つ Graph を定義するコードを示します：

builder = GraphBuilder()
builder.add_node(trend_agent, "research")
builder.add_node(search_agent, "search")
builder.add_node(analysis_agent, "analysis")
builder.add_node(email_agent, "email")

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)

ワークフローの反復可能性が高く、監査証跡が重要となる場合に Graph は特に威力を発揮します。各実行は同じパスをたどるため、同じ入力データを再生することで失敗を再現できます。ただし、明示的なフィードバックエッジがない限り動的にループバックすることはできません。エージェントがより多くの文脈を必要とする場合は、有向非巡回グラフ（DAG）定義内に専用のフィードバックエッジを追加する必要があります。

直接比較結果

両方のパターンは、50 の Hacker News の見込み顧客に対してそれぞれ 3 回実行されました。2 人のレビューアが、メールの関連性について「具体性」「トーン」「正確性」を基準とした 1 から 10 の評価尺度で採点を行いました。

ビジネスへの影響: 1,000 件の見込み顧客を対象としたバッチ処理において、Graph は Swarm に比べて約 3.6 時間の処理時間を短縮し、トークンコストを 20 ドル削減しました。

Swarm はデータが不足した際にエージェントが追加の文脈取得のためにループするため、より高品質なメールメッセージ（スコア 8.2 vs. 7.6）を生成できました。一方、Graph は見込み顧客あたりのコストが 25% 低く、レイテンシの上限も厳格に保たれています。Thrad.ai では、夜間のバッチ処理には Graph を、高価値な見込み顧客に対する週次の詳細分析には Swarm を採用しています。

選択基準: ワークフローが反復可能で予測可能なレイテンシが必要な場合は Graph を選びます。入力品質にばらつきがあり、エージェントの適応性が求められる場合は Swarm を選びましょう。両者は同じコードベースで動作し、設定フラグによって切り替えることができます。

Amazon Bedrock AgentCore でのデプロイ

本番環境では、ローカルでのプロトタイピングを超えたセッションの分離、キャパシティ管理、観測性が不可欠です。Amazon Bedrock AgentCore は、これらの要件をマネージドサービスとして提供します。CDK スタック（インフラストラクチャを定義するクライアント側のオーケストレーションコード）は、aws-cdk-lib/aws-bedrock-agentcore-alpha の L2 構文を使用して、4 つのサービスをデプロイします。

• Runtime: エージェントを隔離されたマイクロ VM（軽量な仮想マシン）でホストし、AWS Identity and Access Management (IAM) による認証とライフサイクル制御（アイドル状態から 15 分、最大稼働時間 8 時間）を提供します。

Gateway は、9 つのツールを統括する単一の Model Context Protocol (MCP) エンドポイントを提供します。MCP は LLM とツールの通信のための標準プロトコルです。エージェントは起動時に Strands の MCPClient を通じてツールを動的に発見します。

Memory は、セッション内の短期コンテキストと、セッションを超えた長期のセマンティックデータを保存します。必須ではありませんが、これがない場合でもエージェントは機能低下せずに動作できます。

Observability は、テレメトリデータのオープン標準である OpenTelemetry を通じて分散トレーシングをキャプチャし、スパンレベルでのレイテンシとトークン数を記録します。Amazon CloudWatch やサードパーティ製サービスとも連携可能です。

Thrad.ai の調査では、YouTube API への呼び出しが全体のレイテンシの 40% を占めていることが判明しました。このトレーシングデータに基づき、チームは HTTP コールに指数バックオフ機能を持つ get_with_retry を追加しました。

このブログ記事用の コンパニオン README と AgentCore ドキュメント には、CDK スタック全体、Gateway のセットアップ方法、デプロイの手順が記載されています。

ウォークスルー：実際の実行例

現在の Hacker News フィードに対して Graph が生成する結果は以下の通りです。

[Graph] Starting nodes: research, search (parallel)
[research] 12 trending HN posts + 4 Reddit intent signals, filtered to 3 AI launches
[search] Enriched 3 prospects: GitHub stars, Wikipedia context, Lobste.rs discussions
[Graph] All dependencies complete → starting: analysis
[analysis] Scored 3 prospects:
  - Prospect A (AI code review tool): 88/100, intent: recommendation_seeking
  - Prospect B (ML monitoring dashboard): 61/100, no intent signal
  - Prospect C (LLM fine-tuning CLI): 45/100, below threshold, skipped
[Graph] Conditional edge: score >= 60 → starting: email (Prospects A, B)
[email] Generated 2 personalized emails, persisted to DynamoDB

Prospect A 用に生成されたメールの例は次のとおりです。

Subject: Saw your AI code review launch trending on HN

Hi [Name],

Congrats on crossing 2,400 stars on GitHub this week—impressive
traction for an AI code review tool. I noticed the r/SaaS thread
where developers are asking for alternatives to [Competitor]; your
approach to contextual suggestions seems to address exactly what
they're frustrated about.

We're building Thrad for teams scaling developer outreach. Our
customers use it to turn signals like yours into qualified
conversations. Would love 15 minutes to share how similar
dev-tool founders shortened their sales cycle.

Best,
[Sender]

Prospect A は、HN、Reddit、dev.to といった複数の情報源からのシグナルが一致した結果、88 点を獲得しました。また、ICP（理想顧客像）に合致する GitHub のスター数が 2,400 件あり、すべてのシグナルが 48 時間以内の最新データであることも評価されました（時系列重みは 1.5 倍）。一方、Prospect C は 60 点未満だったため除外され、約 3,000 トークンの削減につながりました。Graph パターンは、これら 50 の見込み顧客すべてを処理しました。