ひとことで言うと
AWS が最初に公開したオープンソースのエージェント SDKです。エージェントの定義は「モデル・ツール・プロンプト」の3つだけで、あとはエージェントループがモデルを繰り返し呼び、モデルが会話で答えるか・計画するか・振り返るか・ツールを呼ぶかを自分で決めます。AWS はこれを**モデル駆動（model-driven / model-first）**と呼び、「開発者が複雑なワークフローを組み立てる」方式と対比しています。
要するに、手順書を渡すのではなく、道具箱と目的だけを渡す方式です。従来のフレームワークは「まずAをして、結果がこうならB、そうでなければC」という配管を人間が引きました。Strands はその配管を引かず、道具の一覧と目的を渡して、順番はモデルに決めさせます。
だから試験でも「Strands の書き方」は問われません。問われるのは「順番を人間が決める必要があるか、モデルに任せてよいか」のほうです。
なぜ生まれたか
| 時期 | 何が起きたか |
|---|---|
| 2025-05-16 | AWS Open Source Blog で発表（プレビュー）。 「数行のコードでエージェントを構築・実行するモデル駆動のアプローチ」として公開 |
| 2025-07-15 | 1.0 リリース。 マルチエージェントのプリミティブ4種（agents-as-tools / handoffs / swarms / graphs）、SessionManager による状態の永続化、stream_async による非同期ストリーミングが入る。プレビューからの 150 以上のマージ済み PR のうち 22% がコミュニティからの貢献 |
背景にあるのは、モデル側が賢くなった結果、フレームワーク側の配管が余計になったという判断です。初期の LLM は計画も振り返りもできなかったので、人間がチェーンと分岐を書く必要がありました。Strands は「最新モデルは計画し、思考を連ねし、ツールを呼び、振り返る能力を持つ」という前提に立ち、その配管を捨てています。
AWS 自身の本番サービスでも使われており、AWS Transform for .NET は複数の専門エージェントを Strands で動かして .NET アプリの解析・移行計画・コード変換を人手を介さずに実行します。
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| 単一エージェント＋ツール | モデル・ツール一覧・プロンプトを定義してループを回す。組み込みツールが20種以上（ファイル操作・API リクエスト・AWS サービス連携） | D2 |
| MCP サーバのツール利用 | MCP をネイティブサポート。ツールを SDK に直接登録せず MCP 経由で渡せる | D2 |
| 階層的な委譲 | agents-as-tools。専門エージェントをツールとして公開し、オーケストレータが制御を手放さずに専門家へ相談する | D2 |
| 人間へのエスカレーション | handoffs。組み込みの handoff_to_user ツールで、会話コンテキストを保ったまま人間に引き継ぐ | D2 |
| 自律的なチーム協調 | swarms。共有メモリを通じて複数エージェントが動的に協調する。事前定義のワークフローを持たない | D2 |
| 決定論的なワークフロー | graphs。条件分岐と決定点を明示したエージェントワークフロー。承認フローのように順番が決まっている処理向け | D2 |
| モデルの使い分け | Bedrock（Claude・Nova Premier / Pro / Lite / Micro）、Anthropic、Meta、OpenAI、Cohere、Mistral、Stability、Writer、Ollama、LiteLLM 経由。エージェントごとに別モデルを割り当てられる | D2 |
| 会話状態の永続化 | SessionManager で会話と状態を外部データストア（Amazon S3 など）へ自動保存・復元 | D2 |
試験でどう問われるか
**D2（実装と統合・26%）専属です。**試験ガイドのスキル文では 2.1（エージェント型AIとツール統合）と 2.5（アプリ統合パターン）に名指しで出ます。**Strands の API を覚える問題は出ません。**出るのは「この要件で、どの層のどれを選ぶか」です。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| エージェントの実装方法を選ぶ | 手順が事前に決まっておらず、入力に応じてツールの順番が変わる → Strands のモデル駆動ループ | Step Functions で全分岐を先に書く案（順番が決まらないので破綻する） |
| 逆に、順番が決まっている | 承認・監査があり、実行順が毎回同じでなければならない → graphs（または Step Functions） | 「swarm に任せる」（決定論が要る場面で自律協調を選ばせる） |
| 専門エージェントを束ねたい | 制御をオーケストレータが握ったまま専門家に聞きたい → agents-as-tools | 分類器でルーティングして制御ごと渡す案（そちらは AWS Agent Squad の形） |
| 人間レビューを挟む | 会話文脈を保ったまま人へ → handoffs（handoff_to_user） | セッションを切って別チャネルに投げ直す案 |
| Strands か AgentCore か | 「書く側」の話なら Strands、「本番で走らせて監視する側」なら Amazon Bedrock AgentCore | 両者を競合として並べる選択肢。上下関係であって択一ではない |
| モデルを差し替えたい | エージェントごとに別プロバイダのモデル → Strands のモデルプロバイダ抽象 | 「モデルを変えるならコードを書き直す」前提の選択肢 |
| 本番の挙動が追えない | OTEL でトレースしたい → Strands 組み込みのテレメトリ（追加の計装ライブラリ不要） | アプリログを CloudWatch Logs に出すだけの案 |
可観測性は「追加で入れるもの」ではありません。Strands Agents SDK はテレメトリを内蔵しており、追加の計装ライブラリを必要としません。スパンは strands.telemetry.tracer というスコープ名で出ます。AgentCore Runtime 上に ADOT（AWS Distro for OpenTelemetry）付きでデプロイした場合、Runtime 側が session.id 属性を注入してスパンとイベントレコードを自動でエクスポートします。「計装コードを書く」という選択肢は、この時点で不要な作業になります。
実務でどう使うか
- スパンの種別は
gen_ai.operation.nameで決まります。invoke_agent（エージェント呼び出し）／execute_tool（ツール実行）／chat（推論）の3つ。評価サービスはこの属性でスパンを分類するので、独自にスパン名だけ変えてもトレースの読み取りは変わりません - テレメトリの配信モードで、会話の中身がどこに載るかが変わります。 split telemetry ではスパンと相関する別のイベントレコードに、unified telemetry ではスパンにぶら下がるインラインイベントに載ります。識別属性（
gen_ai.operation.name）はどちらのモードでもスパン側にあります。ログの掘り方を書く前にどちらで出ているかを確認しないと、空振りします - デプロイ形態は4通りが想定されています。 クライアントローカル実行／エージェントを API の後ろに置く／エージェントとツールの実行環境を分離する／ツール実行をクライアントとバックエンドに混在させる。「エージェントは必ずサーバ側」という前提を置かないこと
- Python と TypeScript の両方にクイックスタートがあります。 言語選択がそのまま制約にならない設計です
- AWS サービスとの統合は Bedrock だけではありません。 Lambda・Step Functions などとも繋がる前提で作られています。「Strands ＝ Bedrock 専用」と読むと、モデルプロバイダの一覧（OpenAI・Mistral・Ollama ほか）と矛盾します
ハマりどころ: Strands はSDK であって、マネージドサービスではありません。SLA も、リージョン別の提供状況も、AWS のサービスクォータもありません。可用性・スケール・隔離は、載せる先（AgentCore Runtime / Lambda / ECS など）の性質で決まります。「Strands を使えば本番運用が付いてくる」という読み方をしないこと。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Bedrock AgentCore | Strands は書くための SDK、AgentCore は載せるための基盤。AWS の枠組み案内でも「フレームワーク」と「プラットフォーム」は別の章。Runtime はフレームワーク非依存なので、Strands で書いたものをそのまま載せます |
| AWS Agent Squad | あちらは分類器がリクエストごとに担当エージェントを選ぶ方式。Strands は1つのエージェントのループの中でモデルがツールを選ぶ方式。「振り分けか、ループか」で分かれます |
| LangGraph / CrewAI / AutoGen / LlamaIndex | AWS の Prescriptive Guidance では Strands と同じ「フレームワーク」の章に並列でプロファイルされています。Strands だけが特別扱いされているわけではありません |
| Amazon Bedrock Agents（Classic） | あちらはマネージドサービスで、新規顧客には開放されていません（既存顧客は継続利用可）。Strands はコード側の選択肢なので、新規設計の比較対象としては非対称です |
| AWS Step Functions | Step Functions は状態遷移を人間が定義します。Strands の graphs も決定論的ですが、ノードの中身はエージェントです。「ワークフローが LLM を呼ぶ」のか「エージェントが決定論的に並ぶ」のかで読み分けます |
| MCP | MCP はプロトコル、Strands はそれを喋るクライアント側の実装のひとつ。「MCP に対応している」は機能であって、競合関係ではありません |
想起チェック
Q1. シナリオに何が書いてあれば、Step Functions での明示的なワークフローではなく Strands のモデル駆動ループに寄りますか。
実行するツールの順番が入力によって変わり、事前に列挙できないことです。逆に「承認ステップが固定」「監査で毎回同じ経路であることを示す必要がある」と書いてあれば、決定論側（graphs や Step Functions）に寄ります。
Q2. agents-as-tools と handoffs の違いを1文ずつで。
agents-as-tools は専門エージェントをツールとして公開し、オーケストレータが制御を手放さずに呼び出す階層的委譲です。handoffs は組み込みの handoff_to_user で、会話コンテキストを保ったまま責任を人間に渡す仕組みです。
Q3. swarms と graphs はどちらも複数エージェントですが、選択の基準は？
事前定義のワークフローが要るかどうかです。swarms は共有メモリを通じて動的に協調し、ワークフローを事前定義しません。graphs は条件分岐と決定点を明示した決定論的な制御で、承認チェーンのように順番が決まっている処理向けです。
Q4. Strands で書いたエージェントの可観測性を確保するために、追加で書くべき計装コードは？
ありません。 SDK がテレメトリを内蔵しており、追加の計装ライブラリは不要です。AgentCore Runtime 上に ADOT 付きでデプロイすれば、Runtime が session.id を注入してスパンとイベントレコードを自動エクスポートします。
Q5. 「Strands と AgentCore のどちらを使うべきか」という問いが成立しない理由は？
層が違うからです。 Strands はエージェントを書くための SDK、AgentCore はエージェントを実行・監視するための基盤で、AgentCore Runtime はフレームワーク非依存です。択一ではなく重ねて使う関係になります。