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

Strands agentsはAWSのオープンソースのモデル駆動型エージェントSDKです。ループ、ツール、モデルプロバイダー、MCP、マルチエージェント、デプロイ、そしてその利用時期について学びましょう。

Ashley Goolam

Ashley Goolam

26 6月 2026

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

Apidog エンタープライズ

オンプレミスデプロイ

SSO & RBAC

SOC 2 準拠

Apidog Enterpriseを見る

もし、巨大なif/elseステートマシンを組み立ててAIエージェントを構築したことがあるなら、それがどれほど早く脆くなるかご存知でしょう。Strands Agentsはその逆の賭けをしています。つまり、モデルに計画を任せ、あなたはプロンプトとツールリストを提供するだけです。これはAWSが提供するオープンソースのSDKで、2025年5月にApache License 2.0でリリースされました。Amazon Q DeveloperやAWS GlueのようなAmazonチーム内の本番環境のエージェントを強化しています。

ボタン

Strands Agentsとは何か

Strands Agentsは、数行のコードでAIエージェントを構築・実行するためのSDKです。エージェントには、モデル、システムプロンプト、ツールセットの3つを与えます。モデルはプロンプトを読み込み、どのツールを呼び出すかを決定し、それらを実行し、結果を見て、タスクが完了するまで処理を続けます。このサイクルが製品のすべてです。

PythonとTypeScriptで提供されます。その名前は、エージェントを構成する2つの「より糸」(Strands):モデルとツールに由来しています。AWSはこれを内部で運用した後、オープンソース化しました。そのため、その設計はデモ用ではなく、本番環境のニーズを反映しています。プレビュー公開以来、PyPIでのダウンロード数は15万回を超え、マルチエージェントプリミティブとAgent-to-Agent(A2A)プロトコルサポートを追加した1.0リリースに到達しました。

他のエージェントSDKについて読んだことがあるなら、その形状は馴染み深いものに感じられるでしょう。StrandsはLangGraphGoogle 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)

@toolデコレーターは、通常のPython関数をモデルが呼び出せるものに変換します。ドキュメンテーション文字列(docstring)と型ヒントがツールの説明と入力スキーマになるため、モデルはいつ、どのようにそれを使うべきかを知ることができます。別途レジストリを管理する必要はありません。agent(...)を呼び出すと、モデルが完了を決定するまでループが実行されます。

ツールとモデルプロバイダー

ツールはエージェントが外部と接触する方法です。ツールは、あなたが書いたPython関数、コミュニティから提供されたパッケージ化されたツール、またはエージェントに公開されたModel Context Protocol (MCP)サーバー全体でも構いません。

モデル側では、Strandsはプロバイダーに柔軟に対応します。デフォルトのプロバイダーはAmazon Bedrockで、エージェントはデフォルトでus-west-2リージョンのClaude Sonnetモデルを使用します(正確なデフォルトモデルIDはSDKのバージョンによって変更されるため、ハードコーディングするのではなく、インストールされているバージョンを確認してください)。他の場所を指し示すこともできます。

プロバイダーの切り替えは、モデルオブジェクトの変更であり、コードの書き換えではありません。エージェントループ、ツール、プロンプトは同じままです。これにより、ローカルのOllamaモデルで開発し、Bedrockでデプロイすることが現実的になります。

マルチエージェントとMCPのサポート

単一のエージェントでも多くのことを処理できますが、実際のシステムでは複数のエージェントが必要になることがよくあります。Strands 1.0では、マルチエージェントアプリケーション用のプリミティブが追加されました。これには、あるエージェントが他のエージェントを通常のツールと同様に呼び出す「Agent-as-Tool」パターンや、複数のエージェントが協力して問題を解決する「Swarmスタイル」の連携が含まれます。また、A2Aプロトコルもサポートしているため、Strandsエージェントは他のフレームワークで構築されたエージェントと通信できます。

MCPは第一級市民です。Model Context Protocolは、モデルをツールやデータソースに接続するためのオープンな標準です。Strandsを使用すると、公開されているMCPサーバーに接続し、そのツールを直接使用できます。これにより、数千もの既存の統合がカスタムのグルーコードなしで利用可能になります。MCPクライアントを介して接続を管理し、そのツールを他のツールリストと同様にエージェントに渡します。

すでにMCPサーバーを運用している場合、これはエージェントに新しい機能を与える最も安価な方法です。トレードオフとして、これらのサーバーが適切に動作することに依存することになり、これが基盤となるエンドポイントのテストが重要になる理由の一つです。

Strandsエージェントのデプロイ

Strandsは、フレームワークを変更することなく、ラップトップから本番環境へ移行できるように構築されています。ローカルでテストした後、あなたのスタックに合ったターゲットにデプロイします。

エージェントは通常のPythonまたはTypeScriptであるため、そのパッケージ化は他のアプリケーションと同じルールに従います。AWSは可観測性フックもドキュメント化しているため、エージェントが稼働した後にモデルが何を決定し、どのツールを呼び出したかを追跡できます。

Apidogが適合する場所

Strandsはエージェントを構築します。エージェントが呼び出すAPIを構築するわけではなく、それが計画すべきギャップです。すべてのStrandsエージェントは、2種類のHTTPエンドポイントに依存しています。モデルの背後にあるLLMプロバイダーAPIと、`@tool`関数およびMCPサーバーの背後にあるRESTまたはツールAPIです。これらのエンドポイントが誤動作すると、エージェントはモデルの問題のように見えるが実際はそうではない方法で失敗します。

Apidogは、エージェントがそれらに触れる前に、これらの基盤となるAPIをテストおよびモックする場所です。いくつかの具体的な用途は次のとおりです。

明確にするために、Apidogはエージェントフレームワークではなく、何もオーケストレーションしません。Strandsが脳の役割を果たします。Apidogはその下の配管のための作業台です。Apidogをダウンロードして、数分でツールエンドポイントのモックを設定できます。

Strands Agentsを使うべき時

迅速に開発を進め、モデルが計画を立てることを信頼したい場合は、Strandsを検討してください。AWSを利用しており、すでにBedrockを使用している場合、1つのエージェントから始めて後にマルチエージェントに拡張したい場合、または統合コードを書かずにMCPツールを利用したい場合に、Strandsは非常に適しています。

Strandsが適さないのは、厳格で監査可能、決定論的なフローが必要で、すべての分岐が事前に定義されている必要がある場合です。フックやマルチエージェント構造でそれを実現することも可能ですが、グラフファーストのフレームワークの方がより直接的に適しているかもしれません。正直なところ、モデル駆動型とグラフ駆動型のアプローチは異なる問題を解決するものであり、Strandsはモデル駆動型のアプローチです。

よくある質問

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はどのようにテストすればよいですか?

エージェントとは独立して、開発前および開発中にテストしてください。LLMおよびツールエンドポイントをモックし、それらの応答形式をアサートし、CIでこれらのチェックを実行します。Apidogのようなツールはモックとアサーションを処理し、ApidogでChatGPT APIをテストする方法に関するウォークスルーでは、認証、ストリーミング、ツール呼び出しのテストがカバーされており、これはエージェントのバックエンドに直接対応します。

結論

Strands Agentsは、エージェント構築に対するすっきりとしたアプローチを提供します。モデル、プロンプト、ツールを定義し、あとはモデルにループの実行を任せるだけです。1つのエージェントから多数のエージェントへと拡張可能で、MCPとA2Aに対応し、書き換えなしにAWSスタック全体にデプロイできます。フレームワークが推論を処理します。あなたの仕事は、その下のAPIが堅固であることを確認することであり、Apidogがその役割を果たすのはまさにここです。エージェントが呼び出すエンドポイントをモックおよびテストすることで、障害が本番環境ではなくテストで表面化するようにします。

ボタン

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる