Strands Agents は、ツールを使う LLM エージェントを構築するための Python フレームワークであり、軽量でコードファーストだと説明されている。複数のモデルプロバイダーとデプロイ先を本番運用に耐える形でサポートし、Claude モデルを用いた Amazon Bedrock をデフォルトの統合先としている。エージェントはツールのリストとモデルから構築され、ツールは @tool デコレーターを付けた通常の Python 関数で、その docstring がモデルに提示される説明として使われる。会話型と非会話型のエージェント、ストリーミングと非ストリーミングの応答をサポートし、オブザーバビリティ、トレーシング、セキュリティの機能も備えている。
ここでは、異なる情報源に基づいて 2 つの機能を記述する。1 つ目はフックシステムである。HookProvider が HookRegistry を通じてライフサイクルイベントにコールバックを登録し、BeforeToolCallEvent はツール呼び出しが実行される前に発火する。このイベントに対するコールバックは、保留中の呼び出し（その名前と入力）を受け取り、event.cancel_tool にメッセージを代入することでそれを止められる。その時点でフレームワークはツールの結果の代わりにそのメッセージを返し、ツールは一切実行されない。コールバックはモデルの外部で実行されるため、モデルはキャンセルを自身の呼び出しの結果として受け取り、パラメーターを変えて再試行することで回避することはできない。
2 つ目は会話管理であり、コンテキストエンジニアリング の問題に対するこのフレームワークの答えである。やり取りが進むにつれてコンテキストは蓄積し、管理しなければウィンドウのオーバーフロー、応答の遅延、コストの増大を招く。
機能
- エージェントはツールのリストとモデルから構築される。横取り処理を付け加えるには
hooks=[...]という引数を 1 つ追加するだけでよく、ツール定義とプロンプトには手を加えない。 - ツールは
@toolでデコレートされた普通の関数であり、検証ロジックを混ぜ込む必要はない。 BeforeToolCallEventは保留中のツール呼び出しを実行前に検査できるよう公開し、event.cancel_toolはそれをキャンセルして、結果の代わりに説明用のメッセージをモデルへ返す。- モデルプロバイダーは設定可能である。1 つ目の情報源で論じられている例はデフォルトで OpenAI GPT-4o-mini 上で動作し、フレームワークのドキュメントはサポートする他のプロバイダーを扱っている。
- 3 つの会話管理モードがあり、それぞれ何を残すかについて異なる方針を体現している。
NullConversationManagerはすべてを保持し、短いやり取り、デバッグ、研究用途、完全な記録を必要とするコンプライアンスのシナリオ向けに提供される。SlidingWindowConversationManagerは、最近の会話のほうが古い会話よりも関連性が高いという前提のもとで直近の一定数のターンを保持し、長すぎるツール結果のためのshould_truncate_resultsオプションを備える。要約型のマネージャーは、古い内容を捨てるのではなく要約すべき場合のために提供されている。 - フックの仕組みはメモリ統合のポイントも兼ねる。検索フックは関連する記憶をユーザーメッセージに注入し、保存フックは新たな会話内容を保存することで、どちらもエージェントのビジネスロジックの外に置かれる。
採用とエコシステム
1 つ目の情報源では、このフレームワークは ニューロシンボリック検証 パターンの実現手段として登場する。このパターンでは、決定論的なビジネスルールをプロンプトや docstring でモデルに伝えるのではなく、フックの中で評価し、ツールが実行される前に強制する。そのフック機構は エージェントフック で説明される横取りポイントの一実装であり、他のエージェントフレームワークにおける同等のものとして、LangGraph のノードガードと AutoGen の reply 関数が並べて挙げられている。この説明は AWS の組織名義で公開された 1 本の投稿によるもので、同投稿はフレームワークを文書化するのではなく使用しているにすぎないため、その例で使われたフック API は確認できるものの、プロジェクトについてそれ以上のことはほとんどわからない。
Agentic AI インフラ実践経験シリーズ（9）：コンテキストエンジニアリング は、このフレームワークを AWS のコンテキストエンジニアリングのスタックにおけるエージェントフレームワーク層、すなわち下層の Amazon Bedrock と上層の Amazon Bedrock AgentCore の間に位置づけ、そのメモリ管理が同じフックを通じて AgentCore Memory と統合されると説明している。同投稿は両者の対比も示しており、AgentCore Memory はエンタープライズでのデプロイと厳格なコンプライアンスに適するものとして、Strands Agents を通じて利用する Mem0.ai のようなサードパーティのメモリサービスは迅速なプロトタイピングと柔軟なカスタマイズに適するものとして提示されている。
3 つ目の情報源は、このフレームワークを文書化するのではなく位置づけている。Jimmy Song のオンラインハンドブック『智能体构建指南』のある章は、6 つのエージェント協調フレームワークを比較する中で、AWS Strands を モデル駆動 のアプローチ（計画と実行をモデルが担う）を取るものとして特徴づけ、最小限のコードで済み、MCP をネイティブにサポートし、Agent2Agent プロトコル（A2A） を通じてマルチエージェントの協調を可能にするとしている。そこで示された最適な用途は、AWS 上の本番運用に耐えるエージェントである。同章は、Strands についての説明を裏づける数値や測定結果を示していない。このページの 3 つの情報源はいずれも AWS が公開しているフレームワークについて述べたもので、うち 2 つは AWS 自身が公開しているため、どれも独立した評価ではない。