AWS 謹製 AI エージェント構築 SDK `Strands Agents` を触ったメモ✍

タダです.

X をみていたら以下のブログ記事を見つけました.AWS 謹製の AI エージェント構築 SDK Strands Agent が発表されたので触ってみたメモを書きます.

aws.amazon.com

Strands Agent の概要

Strands Agent は2025å¹´5月18日時点ではパブリックプレビュー状態です.

Strands Agents is currently available in public preview. During this preview period, we welcome your feedback and contributions to help improve the SDK. APIs may change as we refine the SDK based on user experiences.

Strands Agent はブログ記事によると3つのコアコンポーネントで構成されていそうです.Strands Agent はプロンプトによって提供されたタスクを完了するまでモデルおよびツールとループしてやりとりする動きを取り,最終結果をユーザーに返します.

• Model: Bedrock/Claude/Llama/Ollama/OpenAI などさまざまなモデルプロバイダーを提供する
• Tools: MCP サーバーを利用したツールやファイル操作,APIリクエスト,AWS APIとの連携など20以上の事前構築されたツールを提供する
• Prompt: ユーザーからの質問への回答などエージェントのタスクを定義する自然言語プロンプトを提供

開発環境構築

ドキュメントを参考に開発環境を作ってみました.仮想環境を作って,SDK をインストールだけしました.

$ python3 -m venv venv
$ pip install strands-agents

サンプルコードの実行

Strands Agent 実行環境を作った後これもドキュメントに則ってコードを実行してみます.

from strands import Agent

agent = Agent()

agent("AWS謹製のAIエージェント構築SDK Strands Agentを解説してください")

事前にオハイオリージョンの Bedrock Claude 3.7 Sonnet のモデルアクセスを有効化して認証情報をターミナルで与えておいたうえで, python -u agnet.py を実行してみると以下の結果が返ってきました.

$ python -u agent.py
# AWS Strands Agentの解説

## 概要
AWS Strands Agentは、AWSが2024年4月に発表した、AIエージェント構築のためのオープンソースSDKです。このフレームワークは、エージェントの構築プロセスを標準化・簡素化し、開発者がAIエージェントアプリケーションを効率的に開発できるよう設計されています。

## Strands Agentの主な特徴

### 1. マルチモダリティのサポート
- テキスト、画像、音声などの複数の入力モダリティを処理できます
- 様々なタイプのユーザー入力に対応するエージェントを構築可能

### 2. 拡張性のある設計
- モジュール式のアーキテクチャにより、カスタムコンポーネントの追加が容易
- 様々なLLMとの連携が可能（Amazon Bedrock、Claude、LLaMa、Anthropicなど）

### 3. ReActフレームワークの実装
- Reasoning and Acting（ReAct）パターンを採用
- エージェントが推論と行動を交互に行うことで、複雑なタスクをステップごとに解決

### 4. ツールの統合
- 外部APIやサービスを「ツール」として簡単に統合できる機能
- データベース、検索エンジン、社内システムなどとの連携が可能

## 主要コンポーネント

### 1. Agent Core
エージェントの中核ロジックを担い、入力処理から出力生成までを制御します。

### 2. Tool Registry
エージェントが使用できるツールを登録・管理するシステムです。

### 3. Memory System
会話の文脈や状態を保持し、一貫性のある対話を実現します。

### 4. Prompt Engine
LLMへの指示や入力を最適化するコンポーネントです。

## 利点

- **開発の標準化**: エージェント開発のためのベストプラクティスを組み込んだ設計
- **迅速な開発**: 複雑なエージェントロジックを少ないコードで実装可能
- **AWSサービスとの連携**: Amazon Bedrockなど他のAWSサービスとスムーズに統合
- **カスタマイズ性**: 様々なユースケースに合わせてエージェントをカスタマイズ可能

Strands AgentはまだAWSのAIエコシステムの中では新しいコンポーネントであり、今後さらなる機能強化が期待されています。オープンソースという性質上、コミュニティからのフィードバックや貢献によって進化していくでしょう。 

ブログ記事を参考に MCP サーバーへの問い合わせもできることを確認しました.

まとめ

Strands Agents をサクッと触ってみたのでメモをまとめました.Lambda/Fargate/EC2 へのデプロイもできるようなので,次はローカルで書いたコードをデプロイしてみようと思います.

Amazon Q Developer Operation Investigations のサンプル調査を触ってみたメモ✍

タダです.

CloudWatch の画面を見ていたら AI Operation というメニューがあります.これは Amazon Q Developer Operation Investigations でプレビュー中ということですが,東京リージョンもサポートされているため試しにサンプル調査を触ってみたのでメモをまとめます.

aws.amazon.com

Amazon Q Developer Operational Investigationsとは

Amazon Q Developer Operational Investigations はシステム内のインシデントへの対応に役立つ 生成AIを活用したアシスタントです.

利用可能リージョン

バージニア/オハイオ/オレゴン/アイルランド/フランクフルト/ストックホルム/スペイン/東京/香港/シドニー/シンガポール/ムンバイリージョンで利用可能です.

対応サービス

Amazon Q Developer Operational Investigations では EC2/ECS/EKS/Lambda/DynamoDB/S3/EBS/Kinesis Data Streams/Kinsis Data Firehose/API Gateway/SQS/SNS がサポートされています.

docs.aws.amazon.com

料金について

プレビュー期間中は追加料金なしで利用可能そうですが, CloudWatchやX-Rayなどの通常料金は発生するでしょう.

調査の開始

Amazon Q Developer Operational Investigations の調査は3つの方法で作成できます.

• 自然言語での問い合わせ: 例えば「Lambda関数が遅い原因は？」といった質問が可能
• 自動調査の開始:CloudWatchアラーム発火時に自動的に調査開始
• CloudWatch メトリクスや Lambda のモニターからの開始

docs.aws.amazon.com

サンプル調査を触ってみたのでメモ

サンプル調査を試してみます.

サンプル調査を試すをクリック

サンプル調査画面を開くと Amazon Q Developer Operational Investigations の提案と結果イメージを示してくれます.Amazon Q Developer Operational Investigations からの提案について [承諾] を選択して調査に追加するか,役に立つ提案ではない場合は [拒否] を選択します.

DynamoDB に関する調査した結果を示しています

まとめ

現在プレビュー中の Amazon Q Developer Operational Investigations の概要とサンプルをさらってみました.

Git サブモジュールの更新を定期的に Dependabot で検知、自動承認及び自動マージできるかを試したメモ✍

タダです.

Git サブモジュールを使っているリポジトリでサブモジュールの更新を自動で検知・自動でマージできるよう仕組み化したい要望があり,Dependabot で対応できないかと思って調査・検証したメモを書きます.

Dependabot のサポート範囲

Dependabot が監視する,新バージョンのパッケージマネージャは以下のドキュメントをまとめられています.Git サブモジュールも対象になっていたので,Dependabot での監視を仕組み化検証することにしました.

docs.github.com

dependabot.yml の定義

Git サブモジュールの更新を検知する Dependabot の定義として以下で設定しました.今回サブモジュールはプライベートリポジトリになっていて,ドキュメントとこのissueを参考に設定しました.secrets.DEPENDABOT_PRIVATE_KEY ã‚’ Fine-grained tokens(試しに Read access to metadata/Read and Write access to administration and code を付与)を発行して Dependabot Secrets に登録しました.

version: 2
registries:
  git-submodule-repo:
    type: git
    url: https://github.com
    username: x-access-token
    password: ${{ secrets.DEPENDABOT_PRIVATE_KEY }}
updates:
  - package-ecosystem: "gitsubmodule"
    directory: "/"
    schedule:
      interval: "daily"
      time: "10:00"
      timezone: "Asia/Tokyo"
    registries:
      - git-submodule-repo

この状態で test-submodule というサブモジュールの更新を検知して Pull Request を作成できました.

Pull Request を自動承認及び自動マージさせる

ついでにサブモジュールの Pull Request を自動承認とマージを GitHub Actions で行ってみました.以下はサンプルコードですが, dependabot/fetch-metadata を参考にしています.自動承認と自動マージのセクションで処理させるのはサブモジュールの時だけに限定するため dependabot/fetch-metadata の output を確認し, ${{ contains(steps.metadata.outputs.package-ecosystem, 'submodules') }} という条件にしました.

name: Dependabot auto-approve for submodule
on:
  pull_request:
    types: opened

jobs:
  submodule:
    runs-on: ubuntu-latest
    permissions:
       pull-requests: write
       contents: write
    if: github.event.pull_request.user.login == 'dependabot[bot]'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@8ca800c1642f5e46fd4fe73c07af0e3baf1375d6
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Auto approve a PR & merge it
        if: ${{ contains(steps.metadata.outputs.package-ecosystem, 'submodules') }}
        run: |
          gh pr review --approve "$PR_URL"
          gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GH_TOKEN: ${{secrets.GITHUB_TOKEN}}

この Actions で実行すると以下のスクリーンショットのように自動承認と自動マージが実現できました.

まとめ

Git サブモジュールの更新を定期的に Dependabot で検知と自動承認及び自動マージができるかを試したのでまとめました.Dependabot が使用する PAT はもっと権限を絞るべきなので確認できたら記事の内容も後追いして更新します...

特定の Aurora MySQL Version3 にてマイナーバージョン標準サポートが2025年8月31日で切れるため試しにバージョンを上げたときメモ✍

タダです.

Aurora MySQL のマイナーバージョン標準サポートが2025年8月31日で切れるバージョンがあります.現在使用しているエンジンバージョンが3.05~3.07だったら,3.08以上にしていくことを計画する必要があります.今回該当するバージョンにあたっているものがあったので,マイナーバージョンを試しに上げてみたときの備忘録をまとめます.

マイナーバージョンの標準サポート早見表

docs.aws.amazon.com

検証概要

Aurora MySQL のエンジンバージョンが 3.07.1 の環境があるため,その環境をクローンして 3.08.0 にマイナーバージョンあげて再起動が発生するかを確認します.

3.08.0へのバージョンアップをすぐ適用してみる

適用中のイベントログを引用したのが以下です.zero-downtime patching が行われたようで, 13397ミリ秒でバージョンアップが完了し,コネクションのロストしていないことが記録されていました.zero-downtime patching はデータベースエンジンへのパッチ修正中にもクライアントとの接続を保持しようとするものです

Attempt to upgrade the database instance 'hoge' with zero downtime finished. The process took 13397 ms, 4 connections preserved, 0 connections dropped. See the database error log for details.

参考情報

aws.amazon.com

検証を踏まえて振り返り

検証では zero-downtime patching によって再起動は起こりませんでした.ドキュメントに記載があるようにデータベースの接続維持はベストエフォートになるため,本番に適用する場合は短いメンテナンスを検討するのが良さそうです.

ダウンタイムのないパッチ適用 (ZDP) 機能では、ベストエフォートに基づいて、Aurora MySQL アップグレード中のクライアント接続を維持するよう試みます。ZDP が正常に完了されると、アプリケーションのセッションが保持され、アップグレードの進行中にデータベースエンジンが再起動します。データベースエンジンの再起動により、数秒から約 1 分間スループットが低下する可能性があります。

まとめ

Aurora MySQL Version3 のマイナーバージョンが標準サポートが切れる予定があり,そのためにエンジンバージョン 3.07.1 を 3.08.0 に試しに上げた時のメモをまとめました.

AWS ã®è² è·ãƒ†ã‚¹ãƒˆã‚½ãƒªãƒ¥ãƒ¼ã‚·ãƒ§ãƒ³ã‚’ä½¿ã£ã¦ã¿ãŸãƒ¡ãƒ¢âœ

タダです.

システム開発において負荷テストをかけてみるケースってあると思うのですが,ローカルだとマシンスペックが足りないかもってなったときに専用環境が欲しくなります.AWS は分散型の負荷テストを簡単に行うためのソリューションを提供しています.この記事では Distributed Load Testing on AWS を試してみたメモをまとめます.

aws.amazon.com

AWS の負荷テストソリューション概要

Distributed Load Testing on AWS はアプリケーションのパフォーマンステストを大規模に自動化するためのソリューションです.

docs.aws.amazon.com

負荷テストソリューションの展開方法

Distributed Load Testing on AWS を展開するために専用の CloudFormation テンプレートを使用します.デフォルトではテンプレートはバージニアリージョンで展開されるようになっていますが,別リージョンでも展開可能です.今回は東京リージョンでやります.大体8分ほどでスタック作成が完了しました.

CloudFormation で入力するパラメーター

負荷テストコンソールへのログイン情報通知

試しに負荷テストをかけてみる

負荷テストソリューション環境が作成された後,簡易なテストシナリオを作ります.以下がシナリオの主要パラメーターでそのまま RUN NOW からテスト実行しました.

• Name: <任意の名前>
• Description: <任意の説明>
• Task Count: <負荷をかける ECS タスク数>
• Concurrency: <タスク毎の同時接続数>
• Ramp Up: <設定した Concurrency 数に達するまでの時間>
• Hold For: <設定した Concurrency 数を保持する時間>
• HTTP endpoint under test: <テストを実行するターゲット URL>

Nginx を ECS Fargate でパブリックサブネットにて稼働させてる環境へのテストシナリオ

テスト完了するとレポートが表示されます.ここで表示される情報の意味は以下のとおりです.

• Average Response Time: テストによって生成されたすべてのリクエストの平均応答時間 (秒)
• Average Latency: テストによって生成されたすべてのリクエストの平均レイテンシー (秒)
• Average Connection Time: テストで生成されたすべてのリクエストについて、ホストへの接続にかかった平均時間 (秒)
• Average Bandwidth: テストで生成されたすべてのリクエストの平均帯域幅
• Total Count: リクエストの総数
• Success Count: 成功したリクエストの総数
• Error Count: エラーの総数
• Requests Per Second: テストで生成されたすべてのリクエストの 1 秒あたりの平均リクエスト数
• Percentile Response Time: テストの応答時間のパーセンタイル値 (最大応答時間は 100 %、最小応答時間は 0 %)

テスト結果表示イメージ

まとめ

AWS の負荷テストソリューションの概要と簡単に試した結果をまとめました.簡単にテスト実行環境を用意してすぐに負荷をかけられるのは良いなと感じました.さらっとしか触られていないため色々試してみたいなと思います.