DEV Community

Cover image for Strands Agentsとは？ AWSのオープンソースモデル駆動型エージェントSDK
Akira
Akira

Posted on • Originally published at apidog.com

Strands Agentsとは？ AWSのオープンソースモデル駆動型エージェントSDK

巨大な if/else ステートマシンで AI エージェントを組んだことがあるなら、すぐに壊れやすくなることを知っているはずです。Strands Agents は逆の設計です。制御フローを細かく手書きするのではなく、モデルに計画を任せ、開発者はプロンプトとツールリストを渡します。これは AWS が提供するオープンソース SDK で、2025年5月に Apache License 2.0 でリリースされました。Amazon Q Developer や AWS Glue など、Amazon チーム内の本番エージェントでも使われています。

今すぐApidogを試す

Strands Agentsとは何か

Strands Agents は、少ないコードで AI エージェントを構築・実行するための SDK です。エージェントに渡す主な要素は次の3つです。

  1. モデル
  2. システムプロンプト
  3. ツールセット

モデルはプロンプトを読み、必要なツールを選び、実行結果を確認し、タスクが完了するまで推論とツール呼び出しを繰り返します。Strands の中心はこのループです。

Strands は Python と TypeScript で利用できます。名前は、エージェントを構成する2つの「より糸」、つまりモデルとツールに由来します。AWS はこれを内部で運用した後にオープンソース化しました。そのため、設計はデモ用途ではなく、本番環境の要件を反映しています。

プレビュー公開以来、PyPI でのダウンロード数は15万回を超え、マルチエージェントプリミティブと Agent-to-Agent（A2A）プロトコルサポートを追加した 1.0 リリースに到達しています。

他のエージェント SDK を使ったことがあるなら、Strands の位置づけは理解しやすいはずです。Strands は LangGraph や Google ADK と同じカテゴリに属します。ただし、開発者がグラフを明示的に描くのではなく、モデルが制御フローを駆動する点に強く寄っています。

モデル駆動型 vs ハードコードされたオーケストレーション

多くの初期エージェントフレームワークでは、先にワークフローを定義します。ノード、エッジ、条件分岐を作り、モデルの出力をそのグラフに沿ってルーティングします。

この方式は有効ですが、新しい機能が増えるたびにグラフも複雑になります。分岐の追加、パスの再テスト、例外処理の更新が必要です。

Strands はこの責任を反転します。最新のモデルは、計画、推論の連鎖、ツール呼び出し、結果の確認をすでに実行できます。そのため、開発者は目標と利用可能なツールを与え、手順の決定はモデルに任せます。

アプローチ あなたが定義するもの 制御フローが存在する場所 新機能のコスト
ハードコードされたオーケストレーション ノード、エッジ、条件、ルーティング グラフコード グラフを編集し、パスを再テストする
モデル駆動型（Strands） プロンプト + ツールリスト モデルの推論ループ ツールを追加し、プロンプトを更新する

トレードオフはあります。モデル駆動型エージェントは構築と変更が速い一方で、完全な決定性は下がります。常に同じ順序で実行すべきワークフローでは、フックやマルチエージェントパターンで構造を追加できます。

ポイントは、グラフが不要ということではありません。最初からすべてをグラフ化するのではなく、必要になった箇所にだけ構造を足すという考え方です。

最小限のエージェントを作る

最小構成の Strands エージェントは短く書けます。Agent クラスをインポートし、必要に応じて @tool デコレーターでツールを定義し、関数のようにエージェントを呼び出します。

from strands import Agent, tool

@tool
def word_count(text: str) -> int:
    """Count the words in a block of text."""
    return len(text.split())

agent = Agent(
    system_prompt="You are a concise writing assistant.",
    tools=[word_count],
)

response = agent("How many words are in this sentence?")
print(response)
Enter fullscreen mode Exit fullscreen mode

このコードで行っていることは次のとおりです。

  1. word_count という通常の Python 関数を定義する
  2. @tool でモデルから呼び出せるツールにする
  3. Agent にシステムプロンプトとツールを渡す
  4. agent(...) を呼び出して推論ループを開始する

@tool デコレーターは、関数の docstring と型ヒントを使ってツールの説明と入力スキーマを作ります。モデルはそれを見て、いつ、どのようにツールを呼び出すかを判断します。

別途ツールレジストリを管理する必要はありません。agent(...) を呼ぶと、モデルが完了と判断するまで、推論、ツール呼び出し、結果確認のループが実行されます。

ツールとモデルプロバイダーを選ぶ

ツールは、エージェントが外部システムにアクセスするための境界です。Strands では、次のようなものをツールとして扱えます。

  • 自分で書いた Python 関数
  • コミュニティが提供するパッケージ化されたツール
  • Model Context Protocol（MCP）サーバーが公開するツール群

モデル側では、Strands は複数のプロバイダーに対応します。デフォルトのプロバイダーは Amazon Bedrock です。エージェントはデフォルトで us-west-2 リージョンの Claude Sonnet モデルを使用します。ただし、正確なデフォルトモデル ID は SDK のバージョンによって変わる可能性があるため、コードに固定するのではなく、インストールしている SDK の設定を確認してください。

利用できるモデルの例は次のとおりです。

  • ツール使用とストリーミングをサポートする Amazon Bedrock モデル
  • Anthropic API 経由の Claude ファミリー
  • Llama API 経由の Llama モデル
  • ローカル開発用の Ollama
  • LiteLLM 経由の OpenAI などのプロバイダー

重要なのは、プロバイダー切り替えがエージェント全体の書き換えではなく、モデルオブジェクトの変更で済む点です。エージェントループ、ツール、プロンプトはそのまま使えます。

たとえば、ローカルでは Ollama で開発し、本番では Bedrock に切り替える、という進め方が現実的になります。

マルチエージェントとMCPを使う

単一エージェントでも多くのタスクは処理できます。ただし、実運用では役割ごとにエージェントを分けたくなることがあります。

Strands 1.0 では、マルチエージェントアプリケーション向けのプリミティブが追加されました。代表的なパターンは次のとおりです。

  • Agent-as-Tool: あるエージェントが別のエージェントを通常のツールのように呼び出す
  • Swarm スタイルの連携: 複数のエージェントが協力して問題を解決する
  • A2A プロトコル: Strands 以外のフレームワークで作られたエージェントと通信する

MCP も第一級の機能として扱われます。Model Context Protocol は、モデルをツールやデータソースに接続するためのオープンな標準です。

Strands では、公開されている MCP サーバーに接続し、そのツールをエージェントに渡せます。すでに MCP サーバーを運用している場合、エージェントに新しい機能を追加する最短ルートになります。

ただし、MCP サーバーに依存するということは、その背後の API やデータソースが正しく動く必要があるということです。エージェントの品質は、モデルだけでなく、ツールの信頼性にも依存します。

Strandsエージェントをデプロイする

Strands は、ローカル開発から本番環境まで同じフレームワークで移行できるように設計されています。まずローカルでツールとプロンプトを検証し、その後スタックに合った実行環境へデプロイします。

主なデプロイ先は次のとおりです。

  • マネージドエージェントランタイム向けの Amazon Bedrock AgentCore
  • イベント駆動で短命なエージェント向けの AWS Lambda
  • コンテナ化された長時間実行サービス向けの AWS Fargate または Amazon EKS
  • コンテナを実行できる任意の環境向けの Docker

Strands エージェントは通常の Python または TypeScript アプリケーションです。そのため、パッケージング、依存関係管理、環境変数、CI/CD は既存のアプリケーションと同じ考え方で扱えます。

本番投入時には、可観測性も重要です。AWS は可観測性フックをドキュメント化しているため、エージェントがどの判断を行い、どのツールを呼び出したかを追跡できます。

Apidogが適合する場所

Strands はエージェントを構築するための SDK です。ただし、エージェントが呼び出す API そのものを作ったり、検証したりするわけではありません。

Strands エージェントは主に2種類の HTTP エンドポイントに依存します。

  1. モデルの背後にある LLM プロバイダー API
  2. @tool 関数や MCP サーバーの背後にある REST API またはツール API

これらのエンドポイントが壊れていると、エージェントは失敗します。そしてその失敗は、モデルの問題のように見えることがあります。実際には、ツール API のレスポンス形式、ステータスコード、認証、タイムアウトが原因であることも多いです。

Apidog は、エージェントが API に触れる前に、基盤となる API をテスト、モック、検証するための作業場所です。

具体的には、次のように使えます。

  • エージェントループを反復開発するときに、モデルやツールエンドポイントをモックする

    実 API を毎回呼ばないことで、トークン消費やレート制限を避けられます。詳しくは、Apidogを使用したAIエージェントテストハーネスの構築に関する記事を参照してください。

  • ツール API のレスポンス形式をアサートする

    フィールド、型、ステータスコードを事前に検証しておくと、不正なペイロードが本番でエージェントに渡るのを防げます。検証方法は、APIアサーションに関するガイドで説明されています。

  • エラーケースを含む モックAPI を立ち上げる

    タイムアウト、認証エラー、空レスポンス、不正な JSON など、エージェントが処理すべきケースを先に再現できます。

  • 環境ごとに API キーを管理する

    開発、ステージング、本番で異なるバックエンドを使う場合でも、資格情報をコードに埋め込まずに管理できます。

Apidog はエージェントフレームワークではなく、オーケストレーションもしません。Strands がエージェントの推論とツール選択を担当します。Apidog は、その下にある API の設計、モック、テストを担当します。

ツールエンドポイントを先に検証したい場合は、Apidogをダウンロードして、モック API を作成できます。

Strands Agentsを使うべき時

Strands が向いているのは、次のようなケースです。

  • すばやくエージェントを作りたい
  • モデルに計画とツール選択を任せたい
  • AWS や Bedrock をすでに使っている
  • まず単一エージェントで始め、後でマルチエージェントへ拡張したい
  • MCP ツールを統合コードなしで使いたい
  • ローカル開発とクラウドデプロイを同じ構造で進めたい

一方で、Strands が最適でないケースもあります。

すべての分岐を事前に定義し、監査可能で決定論的なフローが必要な場合は、グラフファーストのフレームワークの方が直接的に適している可能性があります。Strands でもフックやマルチエージェント構造で制御を追加できますが、基本思想はモデル駆動型です。

モデル駆動型とグラフ駆動型は、どちらが常に優れているというものではありません。解いている問題が異なります。Strands は、モデルに計画させることを前提にした SDK です。

よくある質問

Strands Agentsは無料ですか、それともオープンソースですか？

はい。Strands Agents は Apache License 2.0 の下でオープンソースとして公開されています。ソースコードは GitHub で確認できます。

SDK 自体にライセンス費用はありません。ただし、利用するモデル、Bedrock の推論、Lambda の実行、コンテナ実行環境など、デプロイ先のクラウドリソースには料金が発生します。

StrandsでAmazon Bedrockを使用する必要がありますか？

いいえ。Bedrock はデフォルトのプロバイダーですが、必須ではありません。

Strands は Anthropic API、Llama API、ローカル実行用の Ollama、LiteLLM 経由の他プロバイダーもサポートしています。モデルオブジェクトを変更すれば、残りのエージェントコードは基本的にそのまま使えます。

このため、ローカルでプロトタイプを作り、本番ではマネージドプロバイダーに切り替える構成を取りやすくなります。

Strandsとグラフベースのフレームワークの違いは何ですか？

Strands はモデル駆動型です。開発者はプロンプトとツールを提供し、モデルが手順を決めます。

グラフベースのフレームワークでは、制御フローをノードとエッジとして明示的に定義します。Strands は構築と変更が速く、グラフフレームワークはより厳密で予測しやすい実行に向いています。

実際には、チームが用途ごとに両方を使い分けることもあります。

Strandsエージェントが依存するAPIはどのようにテストすればよいですか？

エージェントとは独立して、開発前と開発中にテストするのが基本です。

実施すべきことは次のとおりです。

  1. LLM エンドポイントやツール API をモックする
  2. レスポンス形式、型、ステータスコードをアサートする
  3. 認証エラーやレート制限などの失敗ケースを再現する
  4. CI で API チェックを実行する

Apidog のようなツールを使うと、モックとアサーションをまとめて扱えます。ApidogでChatGPT APIをテストする方法では、認証、ストリーミング、ツール呼び出しのテストが扱われており、エージェントのバックエンド検証にも応用できます。

結論

Strands Agents は、モデル、プロンプト、ツールを定義し、推論ループをモデルに任せるエージェント SDK です。単一エージェントからマルチエージェントへ拡張でき、MCP と A2A に対応し、AWS スタックやコンテナ環境へデプロイできます。

ただし、エージェントの安定性はモデルだけで決まりません。ツール API、MCP サーバー、LLM プロバイダー API が正しく動くことも同じくらい重要です。

Strands がエージェントの推論を担当するなら、Apidog はその下の API をモック、テスト、検証する役割を担います。エージェントが本番で失敗する前に、依存するエンドポイントの問題をテスト段階で見つけられるようにしておくべきです。

Top comments (0)