AIエージェントの開発は、1年前と比べて様変わりしました。
モデルの推論能力が大幅に向上したことで、複雑なオーケストレーションロジックを書かなくても、実用的なエージェントを短いコードで動かせるようになっています。その流れを受けてAWSが公開したのが「Strands Agents」です。
この記事でわかること:
- Strands Agentsとは何か、なぜAWSが作ったのか
- モデル・ツール・プロンプトの3要素でエージェントを定義する仕組み
- MCPサーバーや@toolデコレータによるツールの追加方法
- LangChainなど既存フレームワークとの違い
https://github.com/strands-agents/sdk-python
AIエージェント開発の課題と背景
2023年頃、AIエージェントをゼロから作るには大量のオーケストレーションコードが必要でした。モデルに正しいJSON形式でツールを呼ばせるだけでも相当な実装コストがかかり、プロダクション投入まで数ヶ月を要するのが当たり前でした。
AWSのAmazon Q Developerチームも同じ問題を抱えていました。既存のエージェントフレームワークを使っていたものの、モデルの性能が上がるにつれ、フレームワーク側のオーケストレーションが逆に邪魔になるケースが増えてきたのです。そこで自社向けに開発したのがStrands Agentsの原型で、これによってQ Developerでは「数ヶ月かかっていた新エージェントの投入を、数日〜数週間に短縮できた」と公式ブログで述べています。
Strands Agentsとは
Strands AgentsはAWSが開発したオープンソースのAIエージェントSDKで、Python版とTypeScript版が提供されています。Apache 2.0ライセンスで公開されており、商用利用も自由です。
最新バージョンはv1.37.0(2026年4月22日リリース)で、PyPIから pip install strands-agents でインストールできます。現在Amazon Q Developer、AWS Glue、VPC Reachability Analyzerといった実際のAWSサービスでの稼働実績もあります。
設計思想はシンプルで、エージェントを次の3要素で定義します。
- モデル: 推論エンジンとなるLLM
- ツール: モデルが呼び出せる関数やAPIの集合
- プロンプト: エージェントの役割や動作方針を定義する指示文
Strands自身は「モデル主導(model-driven)」と呼んでいます。ツールの選択やステップの計画はモデルが自律的に行い、SDKはそのループを管理するだけです。開発者は複雑なステートマシンを書く必要はありません。
対応モデルとインストール
Strands Agentsが対応するモデルは幅広く、主要なプロバイダーをカバーしています。
- Amazon Bedrockのツール使用対応モデル(デフォルトはClaude 3.7 Sonnet in us-west-2)
- Anthropic APIを通じたClaudeファミリー(AnthropicがStrands本体にコントリビュート)
- Llama API経由のLlamaファミリー(Metaがコントリビュート)
- Ollamaによるローカル実行
- LiteLLM経由でのOpenAIその他プロバイダー
インストールは以下のコマンドです。
pip install strands-agents strands-agents-tools
strands-agents-tools パッケージには20以上のプレビルドツールが含まれており、ファイル操作、HTTP リクエスト、AWS API操作などをすぐに使えます。
エージェントの作り方
もっとも簡単なエージェントは、以下のように書けます。
from strands import Agent
from strands_tools import http_request
agent = Agent(
system_prompt="あなたはPythonの専門家です。",
tools=[http_request]
)
agent("requests ライブラリの使い方を教えてください")
これだけでモデルとツールが接続され、エージェントのループが回り始めます。
@toolデコレータで独自ツールを追加する
任意のPython関数をツールとして使うには @tool デコレータを付けるだけです。
from strands import Agent, tool
@tool
def get_weather(city: str) -> str:
"""指定した都市の天気を返します。"""
# 実際のAPI呼び出しに差し替える
return f"{city}の天気は晴れです"
agent = Agent(tools=[get_weather])
agent("東京の天気を教えて")
関数のdocstringがツールの説明としてモデルに渡されるため、モデルはいつそのツールを使うべきか自律的に判断します。
MCPサーバーをツールとして使う
Strands AgentsはModel Context Protocol(MCP)に標準対応しています。公開されている数千のMCPサーバーをそのままツールとして組み込めます。
from strands.tools.mcp import MCPClient
from mcp import stdio_client, StdioServerParameters
domain_tools = MCPClient(lambda: stdio_client(
StdioServerParameters(command="uvx", args=["fastdomaincheck-mcp-server"])
))
with domain_tools:
tools = domain_tools.list_tools_sync()
agent = Agent(tools=tools)
agent("example-project.com というドメインは空いていますか")
MCPサーバーのリストさえあれば、エージェントの機能拡張にコードを書く必要はほぼありません。
v1.37.0の主な変更点
最新リリースv1.37.0(2026年4月22日)では以下の変更が加えられています。
SlidingWindowConversationManagerでツール呼び出しが多い会話のフォールバック処理を修正- モデル設定に
context_window_limitを追加し、モデルごとのコンテキスト上限を明示的に制御できるように - チェックポイント機能をexperimentalとして追加(エージェントの実行状態を保存・再開できる仕組み)
- MCPClientのインタープリタ終了時クリーンアップ処理を修正
チェックポイント機能はまだ実験的ですが、長時間実行するエージェントや、途中で中断が想定されるワークフローにとって有用な機能です。
本番環境へのデプロイ
Strands Agentsは本番稼働を前提に設計されており、デプロイパターンのリファレンス実装がGitHubで公開されています。主な構成パターンとして以下をサポートします。
- モノリス構成: エージェントループとツール実行を同一環境で動かす
- API経由構成: AWS Lambda、AWS Fargate、Amazon EC2の背後にエージェントを配置
- マイクロサービス構成: エージェントループとツール実行を別環境に分離
- クライアント制御構成: クライアント側がツール実行を担うreturn-of-controlパターン
可観測性面ではOpenTelemetry(OTEL)に対応しており、エージェントの軌跡やメトリクスを任意のOTEL対応バックエンドへ送信できます。分散トレーシングにも対応しているため、マルチエージェント構成でも各コンポーネントをまたがったリクエスト追跡が可能です。
LangChainなど既存フレームワークとの比較
LangChainやLangGraphとの最大の違いは「オーケストレーションをどこに置くか」です。LangGraph等はワークフローのDAG(有向非巡回グラフ)を開発者が明示的に定義する設計で、制御しやすい反面、定義コストが高くなります。
Strands Agentsはその定義をモデルに委ねます。モデルが次に何のツールを呼ぶかを自律的に決めるため、コードベースは大幅に小さくなります。一方で、モデルの判断に依存するぶん、挙動の予測可能性はやや低くなります。
どちらが適しているかは用途次第です。手順が固定された業務フローにはワークフロー定義型が向き、柔軟な対話や探索的なタスクにはモデル主導型が合います。
まとめ
Strands Agentsはモデルの推論能力を最大限に活かすことで、エージェント開発のボイラープレートを大幅に削減したSDKです。MCP対応、複数モデルプロバイダーへの対応、本番向けのデプロイパターン提供と、実用上の要件はひと通り押さえています。
AWS環境を使っている開発者であれば、Amazon BedrockのClaude 3.7 Sonnetをデフォルトモデルとしてすぐに試せます。GitHubのリポジトリにはサンプルコードも豊富に揃っているため、まずは pip install strands-agents strands-agents-tools から始めてみるのが早道です。