Strands Agents – オープンソース AI エージェント SDK の紹介

本稿は 2025 年 5 月 16 日に AWS Open Source Blog で公開された “Introducing Strands Agents, an Open Source AI Agents SDK” を翻訳したものです。

2025 年 5 月 16 日、Strands Agents のリリースを発表でき、嬉しく思います。Strands Agents は、わずか数行のコードで AI エージェントを構築・実行するモデル駆動型アプローチを採用したオープンソース SDK です。Strands は、シンプルなエージェントのユースケースから複雑なものまで、そしてローカル開発から本番環境でのデプロイまで対応します。AWS の複数チームが既に本番環境で AI エージェントに Strands を使用しており、これには Amazon Q Developer、AWS Glue、VPC Reachability Analyzer などが含まれます。今回、皆様が独自の AI エージェントを構築できるよう Strands について共有したいと思います。

開発者がエージェントに複雑なワークフローを定義する必要があるフレームワークと比較して、Strands は最先端モデルの計画、思考の連鎖、ツール呼び出し、リフレクションの機能を活用することでエージェント開発を簡素化します。Strands では、開発者はプロンプトとツールのリストをコードで定義するだけでエージェントを構築し、ローカルでテストしてクラウドにデプロイできます。Strands は、DNA の二重らせんのように、モデルとツールというエージェントの 2 つの核となる部分を結びつけます。Strands はモデルの高度な推論機能を使用してエージェントの次のステップを計画し、ツールを実行します。より複雑なエージェントのユースケースでは、開発者は Strands でエージェントの動作をカスタマイズできます。例えば、ツールの選択方法を指定し、コンテキストの管理方法をカスタマイズし、セッション状態とメモリの保存場所を選択し、マルチエージェントアプリケーションを構築できます。Strands はどこでも実行でき、Amazon Bedrock、Anthropic、Ollama、Meta、また LiteLLM 経由で利用できるその他のプロバイダーを含め、推論とツール使用機能を持つあらゆるモデルをサポートします。

Strands Agents はオープンコミュニティであり、Accenture、Anthropic、Langfuse、mem0.ai、Meta、PwC、Ragas.io、Tavily などの複数の企業がサポートと貢献で参加してくれることを嬉しく思います。例えば、Anthropic は既に Anthropic API を通じてモデルを使用するための Strands サポートを提供しており、Meta は Llama API を通じた Llama モデルのサポートを追加しています。ぜひ GitHub にアクセスして Strands Agents プロジェクトへの貢献にご協力ください！

エージェント構築の道のり

私は主に、ソフトウェア開発のための生成 AI アシスタントである Amazon Q Developer の開発に取り組んでいます。私のチームでは、オリジナルの ReAct (Reasoning and Acting) 論文が公開された 2023 年初頭頃に AI エージェントの構築を開始しました。この論文は、大規模言語モデルが推論、計画、そして環境での行動が可能であることを示しました。例えば、LLM はタスクを完了するために API 呼び出しが必要であることを推論し、その API 呼び出しに必要な入力を生成できます。その後、大規模言語モデルが複雑なソフトウェア開発や運用トラブルシューティングを含む多くの種類のタスクを完了するエージェントとして使用できることを私たちは理解しました。

当時、LLM は一般的にエージェントのように動作するよう訓練されていませんでした。主に自然言語による会話のために訓練されることが多かったのです。LLM を使って推論と行動を成功させるには、ツールの使用方法に関する複雑なプロンプト指示、モデルの応答に対するパーサー、オーケストレーションロジックが必要でした。当時は、LLM に構文的に正しい JSON を確実に生成させることだけでも課題がありました！エージェントをプロトタイプし、デプロイするために、これらの初期モデルでエージェントがタスクを確実に成功させるための変換とオーケストレーションを処理する必要があり、私のチームでは様々な複雑なエージェントフレームワークライブラリに依存していました。これらのフレームワークを使っても、エージェントを本番環境で使用できるようにするまでに数か月の調整と工夫が必要でした。

以降、タスクを完了するための推論とツール使用における大規模言語モデルの能力が劇的に向上しているのを私たちは目の当たりにしました。モデルが今やネイティブなツール使用と推論機能を持つため、エージェントを構築するためにそれほど複雑なオーケストレーションは必要なくなったことを私たちは理解しました。実際、エージェントを構築するために使用していたエージェントフレームワークライブラリの一部は、新しい LLM の機能を十分に活用する妨げになり始めました。LLM が劇的に良くなっているにもかかわらず、これらの改善は、使用していたフレームワークでエージェントをより速く構築し、反復できることを意味しませんでした。エージェントを本番環境に対応させるのに依然として数か月かかっていました。

Q Developer のチームからこの複雑さを取り除くために、私たちは Strands Agents の構築を開始しました。最新モデルの機能に依存してエージェントを駆動することで、複雑なオーケストレーションロジックでエージェントを構築することと比較して、市場投入時間が大幅に短縮され、エンドユーザーの体験が向上できることを発見しました。Q Developer チームが新しいエージェントでプロトタイプから本番環境まで進むのに以前は数か月かかっていたところを、Strands では数日から数週間で新しいエージェントを提供できるようになりました。

Strands Agents の核となる概念

エージェントの最もシンプルな定義は、1) モデル、2) ツール、3) プロンプト、の 3 つの要素の組み合わせです。エージェントはこれらの 3 つのコンポーネントを使用してタスクを完了し、多くの場合は自律的に行います。エージェントのタスクとしては、質問に答える、コードを生成する、休暇を計画する、または財務ポートフォリオを最適化することなどが考えられます。モデル駆動型アプローチでは、エージェントはモデルを使用して自身のステップを動的に指示し、指定されたタスクを達成するためにツールを使用します。

Strands Agents SDK でエージェントを定義するには、これらの 3 つのコンポーネントをコードで定義します。

モデル: Strands は柔軟なモデルサポートを提供します。ツール使用とストリーミングをサポートする Amazon Bedrock の任意のモデル、Anthropic API を通じた Anthropic の Claude モデルファミリー、Llama API 経由の Llama モデルファミリー、ローカル開発用の Ollama、そして LiteLLM を通じて OpenAI などの多くの他のモデルプロバイダーを使用できます。さらに、Strands で独自のカスタムモデルプロバイダーを定義することもできます。
ツール: エージェントのツールとして、公開されている何千もの Model Context Protocol (MCP) サーバーを選択できます。Strands は、ファイル操作、API リクエスト実行、AWS API との相互作用のためのツールを含む、20 以上の事前構築済みのサンプルツールも提供します。Strands の @tool デコレータを使用するだけで、任意の Python 関数を簡単にツールとして使用できます。
プロンプト: エンドユーザーからの質問回答など、エージェントのタスクを定義する自然言語のプロンプトを提供します。エージェントの一般的な指示と望ましい動作を提供するシステムプロンプトも提供できます。

エージェントは、プロンプトによって提供されたタスクを完了するまで、モデルとツールとのループで相互作用します。このエージェンティックループ (agentic loop) が Strands の機能の核心です。Strands エージェンティックループは、強力になってきた LLM の推論、計画、ツール選択の能力を最大限に活用します。各ループで、Strands はプロンプトとエージェントのコンテキスト、そしてツールの説明と共に LLM を呼び出します。LLM は、エージェントのエンドユーザーに対する自然言語での応答、一連のステップの計画、エージェントの過去のステップの振り返り、そしてツールを選択をすることができます。LLM がツールを選択すると、Strands はツールの実行を処理し、結果を LLM に返します。LLM がタスクを完了すると、Strands はエージェントの最終結果を返します。

Strands のモデル駆動型アプローチでは、ツールはエージェントの動作をカスタマイズする鍵となります。例えば、ツールはナレッジベースからの関連文書の取得、API の呼び出し、Python ロジックの実行、または追加のモデル指示を含む静的な文字列を単純に返すことができます。以下の Strands Agents の事前構築済みのサンプルツールのように、モデル駆動型アプローチで複雑なユースケースを達成するのにも役立ちます。

Retrieve ツール: このツールは Amazon Bedrock Knowledge Bases を使用してセマンティック検索を実装します。文書を取得する以外に、retrieve ツールはセマンティック検索を使用して他のツールを取得することで、モデルの計画と推論を支援することもできます。例えば、AWS 内部のあるエージェントでは 6,000 以上のツールから選択します！今日のモデルは、これほど多くのツールから正確に選択する能力はありません。すべての 6,000 のツールをモデルに説明する代わりに、エージェントはセマンティック検索を使用して現在のタスクに最も関連するツールを見つけ、それらのツールのみをモデルに説明します。多くのツール説明をナレッジベースに保存し、モデルが retrieve ツールを使用して現在のタスクに関連するツールのサブセットを取得できるようにすることで、このパターンを実装できます。
Thinking ツール: このツールは、複数のサイクルを通じてモデルに深い分析的思考を促し、エージェントの一部として洗練された思考処理と自己省察 (self-reflection) を可能にします。モデル駆動型アプローチでは、思考をツールとしてモデル化することで、モデルがタスクに深い分析が必要かどうか、いつ必要かを推論できるようになります。
マルチエージェント ツール (workflow、graph、swarm ツールなど): 複雑なタスクについて、Strands は様々なマルチエージェント協調パターンで複数のエージェント間を調整できます。サブエージェントとマルチエージェント協調をツールとしてモデル化することで、モデル駆動型アプローチはモデルがタスクに定義されたワークフロー、グラフ、またはサブエージェントの連携 (swarm) が必要かどうか、いつ必要かを推論できるようになります。マルチエージェントアプリケーション用の Agent2Agent (A2A) プロトコルの Strands サポートは近日公開予定です。

Strands Agents の始め方

Strands Agents SDK でエージェントを構築する例を見ていきましょう。長い間言われているように、物事に名前を付けることはコンピュータサイエンスの最も難しい問題の 1 つです。オープンソースプロジェクトの命名も例外ではありません！Strands Agents プロジェクトの潜在的な名前をブレインストームするのを支援するために、私は Strands を使用して命名 AI アシスタントを構築しました。この例では、Strands を使用して、Amazon Bedrock のデフォルトモデル、MCP サーバー、事前構築済みの Strands ツールを使った命名エージェントを構築します。

agent.py という名前のファイルを次のコードで作成してください。

from strands import Agent
from strands.tools.mcp import MCPClient
from strands_tools import http_request
from mcp import stdio_client, StdioServerParameters

# 命名にフォーカスしたシステムプロンプトの定義
NAMING_SYSTEM_PROMPT = """
あなたはオープンソースプロジェクトの命名を支援するアシスタントです。

オープンソースのプロジェクト名を提案する際は、必ずプロジェクトに使用できる
ドメイン名と GitHub の組織名を 1 つ以上提供してください。

提案する前に、ドメイン名がすでに登録されていないか、GitHub の組織名が
すでに使用されていないか、ツールを使って確認してください。
"""

# ドメイン名が利用可能かを判定する MCP サーバーを読み込む
domain_name_tools = MCPClient(lambda: stdio_client(
    StdioServerParameters(command="uvx", args=["fastdomaincheck-mcp-server"])
))

# GitHub の組織名が利用可能かを判定するためのリクエストを
# GitHub に送る Strands Agents の事前構築済みツール
github_tools = [http_request]

with domain_name_tools:
    # ツールとシステムプロンプトと共に命名エージェントを定義
    tools = domain_name_tools.list_tools_sync() + github_tools
    naming_agent = Agent(
        system_prompt=NAMING_SYSTEM_PROMPT,
        tools=tools
    )

    # エンドユーザーのプロンプトと共に命名エージェントを実行
    naming_agent("AI エージェント構築のためのオープンソースプロジェクトの名前を考えてください。")

エージェントを実行するには GitHub パーソナルアクセストークンが必要です。GitHub トークンの値で環境変数 GITHUB_TOKEN を設定してください。また、us-west-2 の Anthropic Claude 3.7 Sonnet への Amazon Bedrock モデルアクセスと、ローカルに設定された AWS 認証情報も必要です。

準備ができたらエージェントを実行してください。

pip install strands-agents strands-agents-tools
python -u agent.py

次のスニペットのような、エージェントからの出力が表示されるはずです。

私が確認した内容に基づいて、オープンソース AI エージェント構築プロジェクトの名前をいくつか提案します。

## プロジェクト名の提案:

1. **Strands Agents** 
- 利用可能なドメイン: strandsagents.com 
- 利用可能な GitHub 組織: strands-agents

お気に入りの AI アシスト開発ツールの上で Strands Agents SDK を使い、新しいエージェントの構築をすぐ簡単に開始できます。素早く始められるよう、Q Developer CLI や Cline などの MCP 対応開発ツールで使用できる Strands MCP サーバーを公開しました。Q Developer CLI をお使いの場合、以下の例を使用して CLI の MCP 設定に Strands MCP サーバーを追加してください。GitHub でより多くの設定例を確認できます。

{
  "mcpServers": {
    "strands": {
      "command": "uvx",
      "args": ["strands-agents-mcp-server"]
    }
  }
}

本番環境での Strands Agents のデプロイ

本番環境でエージェントを実行することは、Strands の設計における重要な原則です。Strands Agents プロジェクトには、エージェントを本番環境に導入するのに役立つリファレンス実装のセットを含むデプロイツールキットが含まれています。Strands は本番環境でさまざまなアーキテクチャーをサポートするのに十分な柔軟性があります。Strands を使用して、会話型エージェントや、イベントトリガー型、スケジュール実行型、または継続的に実行されるエージェントを構築できます。Strands Agents SDK で構築されたエージェントは、エージェンティックループとツール実行の両方が同じ環境で実行されるモノリスとして、または一連のマイクロサービスとしてデプロイできます。以下では、AWS 内部における Strands Agents のデプロイで利用している 4 つのエージェントアーキテクチャーについて説明します。

次の図は、クライアントアプリケーションを通じてユーザーの環境で Strands が完全にローカルで実行されるエージェントアーキテクチャーを示しています。GitHub で公開しているコマンドラインツールの例は、エージェント構築のための CLI ベースの AI アシスタント用の以下のアーキテクチャーに従っています。

次の図は、エージェントとそのツールが本番環境で API の背後にデプロイされるアーキテクチャーを示しています。AWS Lambda、AWS Fargate、または Amazon Elastic Compute Cloud (Amazon EC2) を使用して、Strands Agents SDK で構築されたエージェントを AWS の API の背後にデプロイする方法についても、GitHub 上でリファレンス実装を提供しています。

Strands エージェンティックループとツール実行を別々の環境で実行することで、関心事を分離できます。次の図は、エージェントが API 経由でツールを呼び出し、ツールがエージェントの環境とは別の分離されたバックエンド環境で実行される Strands のエージェントアーキテクチャーを示しています。例えば、エージェント自体を Fargate コンテナで実行しながら、エージェントのツールを Lambda 関数で実行することができます。

Strands では、クライアントがツールの実行を担当するリターンコントロール (return-of-control) パターンも実装できます。この図は、Strands Agents SDK で構築されたエージェントが、バックエンド環境でホストされるツールと、エージェントを呼び出すクライアントアプリケーションを通じてローカルで実行されるツールの組み合わせを使用できるエージェントアーキテクチャーを示しています。

アーキテクチャーの選択にかかわらず、エージェントの可観測性 (observability) は本番環境でのエージェントのパフォーマンスを理解するために重要です。Strands は、本番エージェントのトレースとメトリクスを収集するための機能を提供します。Strands は OpenTelemetry (OTEL) を使用して、可視化、トラブルシューティング、評価のために任意の OTEL 互換バックエンドにテレメトリデータを送信します。分散トレーシングに対する Strands のサポートにより、エージェントセッションの完全な全体像を描くために、アーキテクチャーの異なるコンポーネントを通じてリクエストを追跡できます。

Strands Agents コミュニティへの参加

Strands Agents は Apache License 2.0 の下でライセンスされたオープンソースプロジェクトです。皆様と一緒にオープンに Strands を構築できることを嬉しく思います。追加プロバイダーのモデルとツールのサポート追加、新機能のコラボレーション、ドキュメントの拡張など、プロジェクトへの貢献を歓迎します。バグを見つけた場合、提案がある場合、または何か貢献することがある場合は、GitHub のプロジェクトにご参加ください。

Strands Agents について詳しく学び、Strands で最初の AI エージェントの構築を開始するにはドキュメントをご覧ください。

著者について

Clare Liguori は AWS Agentic AI のシニアプリンシパルソフトウェアエンジニアです。彼女は、Amazon Q Developer チームの一員として、生成 AI と AI エージェントによって強化されたツールを使用することで、アプリケーションの構築方法と開発者の生産性を再考することに焦点を当てています。

翻訳は機械学習ソリューションアーキテクトの本橋が担当しました。

Amazon Web Services ブログ