ひとことで言うと
AWS Labs の、専門エージェントを束ねて協調させるためのフレームワークです。「なんでもやる1体のエージェント」を作る代わりに、リクエストごとに分類器（多くの場合 LLM）が担当エージェントを選び、やり取りの間ずっと会話コンテキストを維持します。Python と TypeScript で使えます。
要するに、コールセンターの一次受付です。かけてきた人の用件を受付が聞き分けて、注文の話は注文係へ、商品の話は商品係へ、手に負えない話は人間のオペレーターへ回す。回した先が変わっても、それまでの会話は引き継がれます。
だから試験でも「Agent Squad の書き方」ではなく、「1体のループに任せるのか、受付を立てて振り分けるのか」として出ます。
なぜ生まれたか
| 何が不便だったか | Agent Squad が置いた答え |
|---|---|
| 1体のエージェントに全業務のツールを持たせると、ツール定義がコンテキストウィンドウを食い、モデルがツール選択を誤る | 業務ドメインごとにエージェントを分け、分類器が1体だけ選ぶ。選ばれなかったエージェントのツールは文脈に載らない |
| ドメインごとに必要なモデルの格が違うのに、1体だと一番重いモデルに引きずられる | エージェントごとに別モデルを割り当てる（AWS のガイダンス実装では注文管理に Claude 3 Sonnet、商品情報に Claude 3 Haiku） |
| AIが答えられない問い合わせの逃げ道がない | Human Agent を振り分け先の1つとして最初から並べ、キュー経由で人間に渡す |
| エージェントを切り替えると、それまでの会話が失われる | 振り分けてもコンテキストを維持することを設計の前提に置く |
構造的に言うと、Agent Squad が解いているのは推論の質ではなく、文脈と権限の隔離です。ドメインが増えるほど「全部入りの1体」は劣化しますが、分けたら分けたで会話が切れる。その両方を同時に立てるための枠組みになっています。
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| インテントに応じたルーティング | 分類器（LLM ベース。AWS のガイダンス実装では Amazon Bedrock Classifier）がメッセージ内容を解析し、どの専門エージェントが処理するかを決める | D2 |
| リード役による調整 | SupervisorAgent。「agent-as-tools」方式で、チームのエージェントを呼び出し可能なツールとして公開し、リードエージェントが作業を調整する | D2 |
| ドメインごとのモデル最適化 | エージェントごとに別モデルを割り当てる（重い推論と軽い応答を分ける） | D2 |
| 人間へのエスカレーション | Human Agent に振り分け、SQS のサポート用キューへ送って「人間が対応する」と利用者に通知する | D2 |
| 会話履歴・セッションの保持 | Amazon DynamoDB に会話履歴とセッションデータを保存する | D2 |
| 非同期・イベント駆動での運用 | AppSync（GraphQL）→ SQS → Lambda がオーケストレータを初期化 → 応答は送信用キュー経由で GraphQL サブスクリプションに返す | D2 |
| ナレッジ参照 | 専門エージェント側から Bedrock Knowledge Bases（OpenSearch Serverless バックエンド）を引く | D1・D2 |
試験でどう問われるか
D2（実装と統合・26%）で、スキル文 2.1 と 2.5 に名指しで出ます。ただし主役では出ません。「マルチエージェントをどう組むか」を問うシナリオの中で、Strands / Bedrock のマルチエージェント協調 / LangGraph と並ぶ選択肢の1つとして出る形です。したがって覚えるべきは機能一覧ではなく、**他の3つと分かれる一点＝「分類器による振り分け」**です。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| マルチエージェントの構成を選ぶ | 業務ドメインが明確に分かれ、リクエストごとに1体を選べば足りる → Agent Squad の分類器ルーティング | 全ドメインのツールを1体に持たせる案（ツール定義が文脈を食う） |
| 逆に、1体で足りる | ツールの順番が入力次第で変わるだけで、ドメインは分かれていない → Strands の単一エージェントループ | 用途ごとにエージェントを立てて分類器を挟む案（過剰設計） |
| ドメインごとにモデルの格を変えたい | 重い推論と軽い応答を分けてコストを下げたい → エージェントごとに別モデル | 全エージェントを同一の最上位モデルで揃える案 |
| 人間へのエスカレーションが要件 | 「AIが処理できない問い合わせは担当者へ」 → Human Agent をルーティング先に含め、キューで渡す | エラーを返して会話を終了する案／人間側を別システムとして切り離す案 |
| 専門エージェント間の文脈の混入を防ぐ | エージェントごとに会話コンテキストを分けたい → 振り分け型（コンテキスト隔離） | 全エージェントで会話履歴を共有する案 |
| リアルタイムに応答を返したい | 振り分け結果を段階的に返す → SSE / GraphQL サブスクリプションなどのストリーミング経路 | 完了までポーリングさせる案 |
| Bedrock のマルチエージェント協調との比較 | マネージドでよい／Bedrock Agents の既存資産がある → Bedrock 側。コードで完全に制御したい／独自の調整ロジックが要る → Agent Squad | 「Bedrock Agents を新規に作る」（Classic は新規顧客に開放されていません） |
試験ガイドに名前があるのに、AWS Prescriptive Guidance のフレームワーク比較には載っていません。あの章がプロファイルしているのは Strands Agents / LangChain・LangGraph / CrewAI / Amazon Bedrock Agents / Amazon Bedrock AgentCore / AutoGen / LlamaIndex の7つで、Agent Squad は含まれていません。「AWS が推す第一候補」として出題される種類のものではないと読むのが安全です。深追いせず、分類器ルーティングという一点だけ押さえること。
実務でどう使うか
- AWS のガイダンス実装での Agent Squad は、マイクロサービスの集合として描かれています。 専門エージェントが独立したマイクロサービスとして動き、調整ロジックは自前で書く。裏返すと、Runtime も Memory も付いてきません。動かす場所と状態の持ち方は自分で決める必要があります
- 振り分けの経路にキューが挟まります。 ガイダンス実装では、受信が SQS のカスタマーメッセージキュー、送信が SQS の送信キュー、人間へのエスカレーションがサポートキュー。同期の API 呼び出しではないので、レイテンシとリトライの設計が別途要ります
- 会話履歴は DynamoDB に置く前提で描かれています。 マネージドな長期記憶の抽出（会話から嗜好や事実を自動で取り出す類）は付いてこないので、必要なら Amazon Bedrock AgentCore Memory のような外部の部品を足すことになります
- 分類器の精度が全体の上限になります。 振り分けを誤ると、その後の専門エージェントがどれだけ優秀でも答えは合いません。分類器自体が LLM 呼び出しなので、リクエスト1件につき最低2回の推論（分類＋実処理）が走ります。コスト見積りで分類側を忘れないこと
- エージェントごとのモデル割り当てが、そのままコスト設計になります。 高頻度・低複雑度のドメインを軽いモデルに寄せられるのが、この構成の実利です
ハマりどころ: Agent Squad はマネージドサービスではなくライブラリです。AWS のサービスクォータもリージョン提供状況も SLA もありません。可用性・スケール・障害時の挙動は、載せた先（Lambda・ECS など）とキューの設計で決まります。「AWS のフレームワークだから運用は面倒を見てもらえる」は成り立ちません。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Strands Agents | Strands は1体のループの中でモデルがツールを選ぶ。Agent Squad は分類器がリクエストごとにエージェントを選ぶ。「ツール選択」か「エージェント選択」かで分かれます |
| Strands の agents-as-tools | 名前が SupervisorAgent の「agent-as-tools」と似ていますが、Strands 側はオーケストレータが制御を握ったまま専門家に相談する形。Agent Squad の分類器ルーティングは担当ごと渡す形です |
| Amazon Bedrock のマルチエージェント協調 | あちらはマネージドで、スーパーバイザーエージェントに協働エージェントを紐づける階層モデル。ただし Bedrock Agents（Classic）は新規顧客に開放されていません |
| Amazon Bedrock AgentCore | AgentCore は実行基盤。Agent Squad はその上に載るコード。AWS のガイダンスでも AgentCore 版と Agent Squad 版は別アーキテクチャとして並記されています |
| Amazon Lex のインテント | Lex のインテント分類は決められたインテント集合への分類。Agent Squad の分類器は LLM による担当エージェントの選定で、後段が生成モデルです |
| API Gateway / AppSync のルーティング | あちらはパスやオペレーションによる決定論的なルーティング。分類器は自然言語の内容で行き先を決めます |
想起チェック
Q1. Agent Squad と Strands Agents を分ける一点は？
何を選ぶかが違います。 Strands は1体のエージェントループの中でモデルがツールを選び、Agent Squad は分類器がリクエストごとに担当エージェントを選びます。ドメインが明確に分かれていて1体を選べば足りるなら後者に寄ります。
Q2. SupervisorAgent は何をする部品ですか。
「agent-as-tools」方式で、チームのエージェントを呼び出し可能なツールとして公開する部品です。これによりリードエージェントが作業を調整できます。分類器による1体選択とは別の、束ねる側の仕組みです。
Q3. 「AIが処理できない問い合わせは担当者へ回す」という要件は、この構成のどこに落ちますか。
Human Agent をルーティング先の1つとして並べます。 分類の結果として人間が選ばれ、メッセージはサポート用のキューへ送られ、利用者には人間が対応する旨が通知されます。エラー終了や別システムへの切り離しではありません。
Q4. Agent Squad を選んだとき、コスト見積りで見落としやすいものは？
分類器そのものの推論コストです。分類も LLM 呼び出しなので、リクエスト1件につき分類と実処理で最低2回の推論が走ります。エージェントごとにモデルの格を分けられる利点と合わせて見積もります。