AWS が公開した AI エージェント向けベンチマーク aws-bench の仕組みを確認してみた

はじめに

2026年7月24日、AWS が AI エージェントの AWS 操作能力を測るオープンソースベンチマーク aws-bench をリサーチプレビューとして公開しました。実際の AWS アカウントにシナリオごとのリソースをデプロイし、AI エージェントに操作させて、回答内容や操作後のリソース状態を採点する仕組みです。

https://aws.amazon.com/about-aws/whats-new/2026/07/aws-bench/

https://github.com/aws-bench/aws-bench

本記事では公式リポジトリとドキュメントをもとに aws-bench の仕組みの確認を試みました。ベンチマークそのものの実行結果、AI エージェントやモデル間の性能比較、公開スコアの再現、独自ベンチマークの設計は扱いません。

aws-bench の実行フロー

1. AWS Organizations の管理アカウントから、ベンチマーク用の OU とテストアカウントを準備します。テストアカウントはシナリオごとに1つ使います。
2. シナリオに含まれる CDK 定義で、評価対象となる AWS リソースをテストアカウントへデプロイします。
3. コンテナで構成されるサンドボックス環境内の AI エージェントに、タスクの指示文とテストアカウントの AWS 認証情報を渡し、制限時間内に AWS を操作させます。
4. 採点はタスクの種類で分かれます。読み取り・診断系のタスクはエージェントの回答を参照回答と比較して判定し、作成・変更系のタスクは実際のリソース状態を検証します。
5. 実行後は env verify で drift と残留リソースを確認し、env reset で同一環境を再初期化するか、リソースを撤去します。

読み取り・診断系の introspection タスクは99本あり、参照回答との同等性を LLM judge が二値で判定します。introspection では check.py のような検証コードは実行されず、回答文の判定のみです。作成・変更系の mutation タスクは35本あり、シナリオごとに用意された check.py の判定基準をすべてクリアした場合のみ合格となり、部分点はありません。

データセットとシナリオ

データセットは8シナリオ・134タスクで構成されています。

「主な性格」は、各タスクの task.toml にある request_type と intent を静的に集計して分類したものです。

quickstart が使うのは ec2-multiregion の9タスクのみなので、最初から8シナリオすべてを実行する必要はありません。

https://github.com/aws-bench/aws-bench-datasets

実行に必要な条件

AWS 環境：

• AWS Organizations の管理アカウント
• 実行するシナリオ数分のテストアカウントを追加できること（1シナリオ1アカウント。空き枠、メールを受信できるドメイン、アカウント数クォータの充足が必要）
• シナリオが使うリージョンとサービスのクォータ（env init --wait-for-quotas で自動申請されますが、即時承認されない場合があります）
• Amazon Bedrock のモデルアクセス（LLM による判定に使用します）

ローカル環境：

• Python 3.12 以降
• uv
• Docker Compose v2
• Docker buildx

https://github.com/aws-bench/aws-bench/blob/main/docs/getting-started.md

所要時間と費用の目安

シナリオごとに設定されたタイムアウト時間と、ワーストケースの概算最大費用です。

timeout 上限はデプロイから撤去までのタイムアウト合算値で、概算最大費用は主要高額リソースの時間課金を積み上げたワーストケースの静的概算です。いずれも実測ではなく、実際の費用は稼働時間や従量課金の量によって変わります。

これらに加え、エージェントのモデル呼び出しと LLM judge によるトークン費用が別途かかります。

quickstart（ec2-multiregion）は、1時間あたり約 $0.1 の AWS リソース費用で試せる規模です。

ec2-multiregion の9タスクで調べること

quickstart が使う9タスクはすべて introspection（読み取り・診断系）で、タスクごとの制限時間は600秒です。いずれも読み取りのみを求めるタスクで、リソースの作成・変更は含まれません。

troubleshooting-multiservice の21タスクで診断すること

読み取り系で実務に近い障害診断を扱うシナリオとして、troubleshooting-multiservice の中身も確認しました。21タスクもすべて introspection で、診断結果や調査結果を文字列で回答させます。

まとめ

aws-bench は、AI エージェントの AWS 操作能力を、読み取り・診断系では回答内容、作成・変更系では操作後のリソース状態を用いて評価するベンチマークです。

実行には、AWS Organizations でシナリオごとにテストアカウントを用意できる環境が必要です。この点は導入時のハードルになりますが、AI エージェントに実際の AWS 環境を安全に操作させるための設計としては妥当だと感じました。

次は、AWS Organizations 環境の準備ができ次第、Kiro で比較的低コストで試せる ec2-multiregion で一連の流れを確認する予定です。
その後は公式リポジトリをフォークし、高コストになりやすいサービスや構成を除外したうえで、Step Functions、Lambda、ECS、VPC などを対象にベンチマークを試してみたいと思います。

参考リンク

• AWS Organizations のクォータ
• Amazon EC2 の料金
• Amazon EBS の料金
• Amazon VPC の料金
• Amazon Bedrock の料金