背景・目的
AI エージェントを学ぶ中で、AWS のエージェント基盤 Amazon Bedrock AgentCore の全体像を整理しました。その中で、エージェント本体を書くフレームワークとして Strands Agents が繰り返し登場します。AgentCore Runtime も Strands Agents を含む OSS フレームワークで書いたエージェントをデプロイ・スケールさせる基盤です。
そこで、いきなり AgentCore Runtime にデプロイする前に、まずローカルで Strands Agents の最小エージェントを動かして、エージェントの基本構造(モデル・プロンプト・ツール)を試してみます。ローカルで動いたエージェントは、後段で AgentCore Runtime にそのまま乗せられるため、そのまま流用します。
まとめ
| 項目 | 内容 |
|---|---|
| これは何 | AWS製のOSSエージェントSDK Strands Agents で、最小のAIエージェントをローカルで動かす手順 |
| 何ができる | ①数行でエージェントを定義 ②組み込み/自作ツールをエージェントに持たせる ③ローカル実行で推論→ツール選択→実行→応答のループを体感 |
| モデル | デフォルトで Amazon Bedrock の Claude Sonnet 4 を使用(他プロバイダーも選択可)※2026-07時点の検証環境では Sonnet 5 が提供されていた |
| 前提 | Python 3.10+、Bedrock で Claude 系モデル(検証では Sonnet 5)にアクセスできるAWSクレデンシャル |
| 位置づけ | AgentCore Runtime デプロイの前段(助走)。ローカルで動いたものを本番基盤に乗せる流れ |
概要
用語の整理
- Strands Agents:AWS製のOSSエージェントSDK。モデル駆動アプローチで、数行でエージェントを構築できる。Python と TypeScript に対応
- ツール(tool):エージェントが呼び出せる関数。Pythonの関数に
@toolデコレータを付けるだけで自作できる - エージェントループ:入力 → 推論(LLM) → ツール選択 → ツール実行 → 応答 という繰り返し
- モデルプロバイダー:エージェントが使う基盤モデルの供給元(Bedrock / Anthropic / OpenAI / Gemini 等)
Strands Agents とは
Strands Agents は、モデル駆動アプローチでAIエージェントを構築・実行するOSS SDK。シンプルな会話アシスタントから複雑な自律ワークフローまで、ローカル開発から本番デプロイまでを同じ書き方でカバーする。公式ドキュメントには下記のようにある。
Strands Agents is a simple yet powerful SDK that takes a model-driven approach to building and running AI agents. From simple conversational assistants to complex autonomous workflows, from local development to production deployment, Strands Agents scales with your needs.
Strands Agents はモデル駆動アプローチでAIエージェントを構築・実行する、シンプルかつ強力なSDKであり、単純な会話アシスタントから複雑な自律ワークフロー、ローカル開発から本番デプロイまでニーズに応じてスケールする。
モデルプロバイダーとデフォルトモデル
Strands はデフォルトで Amazon Bedrock の Claude Sonnet 4 を使います。文字列でモデルIDを直接指定する方法と、モデルプロバイダーのインスタンスを作る方法があります。Bedrock 以外にも Anthropic / OpenAI / Gemini / LiteLLM などに対応している
Strands defaults to the Bedrock model provider using Claude Sonnet 4.
Strands はデフォルトで Claude Sonnet 4 を使う Bedrock モデルプロバイダーになっている、という説明。ただし提供モデルは時期で変わり、本記事の検証時点(2026-07)では Claude Sonnet 5 が提供されていた。このため、Bedrock で Claude 系モデル(本記事では Sonnet 5) にアクセスできるAWSクレデンシャルが前提になる
ツールの仕組み
Strands の特徴は、Python関数に @tool デコレータを付けるだけでエージェントのツールにできる点。組み込みツール群は strands-agents-tools パッケージ(コミュニティ製)で提供され、calculator や current_time などがすぐ使える。エージェントは入力内容に応じて、どのツールを使うかを自動で判断する
The agent automatically determines when to use tools based on the input query and context.
エージェントは入力クエリとコンテキストに基づいて、いつツールを使うかを自動的に判断する、という説明
実践
1. 前提を確認する
- Pythonのバージョンを確認します
# Pythonのバージョンを確認 % python --version - モデルの疎通確認します
aws sts get-caller-identity % aws bedrock-runtime converse --region us-west-2 --model-id "us.anthropic.claude-sonnet-5" --messages '[{"role":"user","content":[{"text":"こんにちは。1文で自己紹介して"}]}]' --inference-config '{"maxTokens":2048}' --output json 2>&1 | head -c 1500 { "output": { "message": { "role": "assistant", "content": [ { "text": "こんにちは!私はAI assistantで、質問への回答や文章作成、アイデア出し、プログラミング支援など、さまざまなタスクのお手伝いをしています。" } ] } }, "stopReason": "end_turn", "usage": { "inputTokens": 21, "outputTokens": 63, "totalTokens": 84, "cacheReadInputTokens": 0 }, "metrics": { "latencyMs": 2357 } } %
2. SDKをインストールする
-
SDKをインストールします
% mkdir strands_test % cd strands_test/ % python -m venv .venv % % source .venv/bin/activate ((.venv) ) % pip install strands-agents strands-agents-tools -
最小エージェントを書く
calculator/current_time)と自作ツール(letter_counter)を持つエージェントを定義します。((.venv) ) % cat > agent.py <<'PY' from strands import Agent, tool from strands.models import BedrockModel from strands_tools import calculator, current_time @tool def letter_counter(word: str, letter: str) -> int: """Count occurrences of a specific letter in a word.""" if not isinstance(word, str) or not isinstance(letter, str): return 0 if len(letter) != 1: raise ValueError("The 'letter' parameter must be a single character") return word.lower().count(letter.lower()) bedrock_model = BedrockModel( model_id="us.anthropic.claude-sonnet-5", region_name="us-west-2", ) agent = Agent(model=bedrock_model, tools=[calculator, current_time, letter_counter]) message = """I have 3 requests: 1. What is the time right now? 2. Calculate 3111696 / 74088 3. Tell me how many letter R's are in the word "strawberry" """ agent(message) PY ((.venv) ) % ls -l agent.py -rw-r--r--@ 1 XXXXX XXXXX 837 7 26 21:31 agent.py ((.venv) ) %
4. 実行する
- Python スクリプトとして実行します
((.venv) ) % python -u agent.py Tool #1: current_time Tool #2: calculator Tool #3: letter_counter Here are your answers: 1. **Current time:** 2026-07-26T12:33:18 UTC 2. **3111696 / 74088 = 42** 3. **"strawberry"** contains **3** letter R's% ((.venv) ) %
次の出力が得られました。エージェントが current_time → calculator → letter_counter の3ツールを順に自動で使い分け、3問すべてに正しく回答しました。推論 → ツール選択 → ツール実行 → 応答 のループがそのままコンソールに流れました
5. 観測データを覗いてみる
-
下記のように修正します
result = agent("What is 2+2?") print(result.metrics) -
下記のように表示されました
((.venv) ) % python -u agent.py 2 + 2 = 4EventLoopMetrics(cycle_count=1, tool_metrics={}, cycle_durations=[1.7588999271392822], agent_invocations=[AgentInvocation(cycles=[EventLoopCycleMetric(event_loop_cycle_id='22109e0b-e786-4cbe-be1b-fe0593595d99', usage={'inputTokens': 2937, 'outputTokens': 11, 'totalTokens': 2948})], usage={'inputTokens': 2937, 'outputTokens': 11, 'totalTokens': 2948})], traces=[<strands.telemetry.metrics.Trace object at 0x10a5d33b0>], accumulated_usage={'inputTokens': 2937, 'outputTokens': 11, 'totalTokens': 2948}, accumulated_metrics={'latencyMs': 1415}) ((.venv) ) %
エージェント呼び出しの戻り値 AgentResult から、トレースやメトリクスを取得できます。
| 項目 | 値 | 意味 |
|---|---|---|
| cycle_count | 1 | エージェントループが1周(今回はツール不要な単純計算) |
| tool_metrics | {} | ツール未使用(2+2は直接回答) |
| cycle_durations | 約1.76秒 | ループ1周の所要時間 |
| inputTokens | 2937 | 入力トークン(システムプロンプト等込み) |
| outputTokens | 11 | 出力トークン(「2 + 2 = 4」は短い) |
| totalTokens | 2948 | 合計 |
| latencyMs | 1415 | レイテンシ 約1.4秒 |
考察
- Strands Agents の最大の特徴は「Python関数に
@toolを付けるだけでツールになる」というモデル駆動の簡潔さだと、実際に書いてみて実感しました。グラフを手で組む方式と違い、エージェントの定義がほぼ Python そのままで済むため、学習の入口として敷居が低いです - 実行結果を見て一番腹落ちしたのは、3つのツールを「こちらが指示しないのにエージェントが自分で使い分けた」点です。
current_time→calculator→letter_counterの順に呼び出しており、推論→ツール選択→実行のループが目で見えました。これが「AI Agentが動く」ということかと納得しました - 次のステップとして、このローカルで動いた
agent.pyを AgentCore Runtime にデプロイし、「ローカルで動く → 本番基盤に乗る」の連続性を体感したいと考えています。その先で Gateway でのツール接続、Observability での可観測化(今回触れなかったresult.metricsの活用)へ広げる予定です
参考