今月誕生日の人、おめでとうございます🎉 エデュケーショナルサービス課の森純子です。
【2026年7月30日 追記】GitHub Issueへの返信を受けて、自動採点（verifier）の認証エラーは解決しました。詳細は本文末尾の追記セクションをご覧ください。
「AI コーディングエージェントに AWS の運用タスクを任せたいけど、実際どのくらい正確にこなせるの？」そんな疑問、ありませんか？
2026年7月24日、AWS が AI エージェントの AWS タスク実行能力を測定するオープンソースベンチマークツール aws-bench を Research Preview として公開しました🎉
AWS announces aws-bench, an open-source benchmark for AI agents on AWS（2026年7月24日）
aws-bench は、実際の AWS 環境に対して AI エージェントにタスクを実行させ、その結果を自動採点する仕組みです。障害調査、設定ミスの診断、インフラ構築といった、AWS 実務者が日常的に行う作業を AI エージェントがどの程度正確にこなせるかを、定量的に評価できます。
なお、本記事で使用する「使い捨てアカウント」という表現は、AWS公式ドキュメント（README）の "disposable accounts" に基づいています。
今回は、Claude Code + Claude Sonnet 5 の組み合わせで quickstart データセット（9タスク）を実行し、スコアを確認しました。
- 本記事の登場サービス
- 対象読者
- 本記事で分かること
- aws-bench の概要
- 前提条件
- 検証環境
- 検証手順
- スコア結果
- 検証時のハマりどころ
- クリーンアップ
- コスト
- まとめ
- 参考
- 追記（2026年7月30日）: Issueに返信があり、解決しました
本記事の登場サービス
| 略称 | 正式名称 |
|---|---|
| aws-bench | aws-bench（オープンソースベンチマークツール） |
| Bedrock | Amazon Bedrock |
| Organizations | AWS Organizations |
| CDK | AWS Cloud Development Kit |
| CloudFormation | AWS CloudFormation |
| EC2 | Amazon Elastic Compute Cloud |
| Service Quotas | AWS Service Quotas |
| SCP | Service Control Policy |
| IGW | Internet Gateway |
| NACL | Network Access Control List |
| SG | セキュリティグループ（Security Group） |
| STS | AWS Security Token Service |
| IAM | AWS Identity and Access Management |
対象読者
- AI コーディングエージェント（Claude Code、Kiro CLI 等）を AWS 運用に活用したい方
- エージェントの性能を客観的に比較・評価したい方
- aws-bench の仕組みと実行手順を知りたい方
本記事で分かること
- aws-bench の概要と仕組み
- 環境構築からベンチマーク実行までの手順
- Claude Code + Claude Sonnet 5 のスコア結果
- 検証時の注意点とハマりどころ
aws-bench の概要
aws-bench は、AI コーディングエージェントが実際の AWS タスクをどの程度正確かつ効率的に完了できるかを測定するオープンソースベンチマークです。AWS が Research Preview として公開しており、GitHub リポジトリ（https://github.com/aws-bench/aws-bench）で Apache 2.0 ライセンスで提供されています。
特徴
- 使い捨ての実 AWS アカウントに対してエージェントがタスクを実行する（静的なテストではない）
- タスクは実際の AWS 利用パターンの分析から設計されている
- 自動採点：読み取り専用タスクは LLM による判定、リソース変更タスクは AWS の実状態をプログラムで検証
- 採点結果は reward.json に 1.0（合格）/ 0.0（不合格）で記録される
仕組み（3ステップ）
- aws-bench が Organizations 配下に使い捨てアカウントを作成し、CDK でテスト用インフラ（シナリオ）をデプロイする
- AI エージェントがサンドボックスコンテナ内でタスクを実行する
- 自動検証（verifier）が結果を採点し、変更タスクの場合はロールバックする
タスクの種類
- 内省（Introspection）タスク：読み取り専用。エージェントが環境を診断し、回答を記述する。LLM が正解と照合して採点する
- 変更（Mutation）タスク：リソースの作成・変更を行う。プログラムが AWS の実状態を検証して採点する
データセット
| データセット名 | タスク数 | シナリオ数 | 説明 |
|---|---|---|---|
| aws-bench-quickstart | 9 | 1 | インストール確認用の最小データセット（ec2-multiregion タスクを再利用） |
| aws-bench-basic | 78 | 4 | コア AWS サービスの基礎タスク。ベースライン確立に最適 |
| aws-bench-advanced | 47 | 3 | マルチサービスの実践的シナリオ。フル難易度 |
対応エージェント
| エージェント（-a） | モデルプロバイダー | 認証方式 |
|---|---|---|
| claude-code | Anthropic API or Amazon Bedrock | ANTHROPIC_API_KEY、またはAWS_BEARER_TOKEN_BEDROCKで自動検出 |
| codex | OpenAI or Amazon Bedrock | OPENAI_API_KEY、またはAWS_BEARER_TOKEN_BEDROCKで自動検出 |
| kiro-cli | Kiro | KIRO_API_KEY（ksk_…形式） |
| mini-swe-agent | Any LiteLLM provider（incl. Amazon Bedrock） | プロバイダー固有 |
| aws-bench-baseline-agent | Amazon Bedrock（Strands Agent SDK） | AWS_BEARER_TOKEN_BEDROCK |
| oracle | なし | なし（正解を再生するだけの検証用） |
また、aws-bench は Harbor フレームワーク上に構築されているため、Harbor が対応する他のエージェント（aider、gemini-cli、goose、opencode、cline-cli 等）も -a で指定可能です。
前提条件
| No | 条件 | 説明 |
|---|---|---|
| 1 | AWS Organizations 管理アカウント | 使い捨てアカウントを自動作成するため |
| 2 | 管理アカウントに AdministratorAccess 相当の権限 | Organizations、IAM、CDK デプロイに必要 |
| 3 | Amazon Bedrock のモデルアクセス（us-east-1） | エージェントが LLM を呼び出すため。2026年7月時点では初回呼び出し時に自動有効化 |
| 4 | Python 3.12 以上 | aws-bench の実行環境 |
| 5 | uv（Python パッケージマネージャー） | 依存関係の管理 |
| 6 | Docker（Compose v2 プラグイン + buildx 0.17.0 以上） | エージェント実行環境のコンテナビルド |
| 7 | リージョンは us-east-1 固定 | aws-bench の仕様 |
検証環境
| 項目 | 設定 |
|---|---|
| 管理アカウント | 個人 Organization の管理アカウント |
| 使い捨てアカウント | aws-bench が自動作成 |
| リージョン | us-east-1（管理）、us-east-1 / us-west-1 / us-west-2（テスト環境） |
| OS | Windows 11 + WSL2（Ubuntu 26.04） |
| Python | 3.12.13（uv でインストール） |
| Docker | 29.6.2（Docker Engine on WSL） |
| Docker Compose | v5.3.1 |
| Docker buildx | v0.35.0 |
| aws-bench | v0.7.0 |
| データセット | aws-bench-quickstart（9タスク / 1シナリオ） |
| エージェント | Claude Code + Claude Sonnet 5（Amazon Bedrock） |
検証手順
手順1: ローカル環境の準備
Python 3.12、uv、Docker Engine（Compose v2 + buildx）を WSL にインストールしました。
注意点: システムの Python が 3.14 の場合、aws-bench の依存ライブラリ（numpy 1.26.4）のビルドに失敗します。uv python install 3.12 で Python 3.12 を明示的にインストールし、uv sync --python 3.12 で解決しました。
手順2: aws-bench のクローンとセットアップ
git clone https://github.com/aws-bench/aws-bench.git cd aws-bench uv python install 3.12 uv sync --python 3.12
手順3: AWS 認証設定
管理アカウントに AdministratorAccess 相当の権限を持つプロファイルを設定し、環境変数を指定しました。
export AWS_PROFILE=<your-profile> export AWS_REGION=us-east-1
手順4: テスト環境の初期化（env init）
uv run aws-bench env init --env-name bench-test --dataset aws-bench-quickstart
このコマンドが実行する内容:
- Organizations 配下に OU「bench-test」を作成
- 使い捨てアカウントを新規作成（既存アカウントは使用しない）
- SCP（Service Control Policy）を作成・アタッチ（テスト用ロールの保護）
- Service Quotas の増加リクエスト
- 初期状態のスナップショットを取得
所要時間: 約8分
注意点: Service Quotas の反映に最大30分かかります。aws-bench env show --env-name bench-test で「Quotas met」が満たされたことを確認してから次に進みます。
手順5: テスト環境のデプロイ（env setup）
uv run aws-bench env setup --env-name bench-test --dataset aws-bench-quickstart
このコマンドが実行する内容: * CDK Bootstrap（us-east-1、us-west-1、us-west-2 の3リージョン） * ec2-multiregion シナリオのインフラデプロイ（VPC、サブネット、EC2 インスタンス、セキュリティグループ、IAM ロール等）
所要時間: 約17分
デプロイされた構成: * us-east-1: VPC（パブリック + プライベートサブネット）、WebServerInstance、MyEC2Instance、PrivateInstance、LaunchTemplateInstance * us-west-1: VPC（パブリックサブネット）、WebServerInstance * us-west-2: VPC（パブリックサブネット）、WebServerInstance
手順6: Bedrock bearer token の生成
eval $(uv run aws-bench env creds --eval)
このコマンドが実行する内容:
* IAM ユーザー（bedrock-api-user）を作成
* 長期 Bedrock キー（30日間有効）を生成
* Parameter Store にトークンを保存
* トークンを環境変数 AWS_BEARER_TOKEN_BEDROCK にセット
手順7: ベンチマーク実行（Claude Code）
uv run aws-bench run --env-name bench-test --dataset aws-bench-quickstart --agent claude-code -m global.anthropic.claude-sonnet-5 --ve "AWS_BEARER_TOKEN_BEDROCK=$AWS_BEARER_TOKEN_BEDROCK" --yes
所要時間: 約10分
注意点: --ve オプションでverifier（採点用 LLM judge）コンテナにも Bedrock トークンを渡す必要があります。これを省略すると、エージェントは正常に動作するが採点が認証エラーで失敗します。
スコア結果
自動採点（verifier）は Research Preview 段階の認証バグ（後述）により完了しませんでしたが、エージェントの回答内容を正解データ（ground_truth.json）と手動照合した結果は以下のとおりです。
| No | タスク名 | 内容 | 手動評価 |
|---|---|---|---|
| 1 | describe-cloudformation-stack-resources | us-west-1 の CloudFormation スタックのリソースを記述する | 合格（16リソース全てを正確に記述） |
| 2 | describe-ec-instances-cross-region-connectivity | 3リージョンの EC2台数と、us-east-1で同一VPC内のインスタンスを特定する | 合格（4/1/1台を正確に回答、VPC共有関係も正確） |
| 3 | ec-instances-without-default-vpc | デフォルトVPCに属さないEC2を全リージョンで列挙する | 合格（5インスタンスを正確に特定） |
| 4 | find-ec-instances-in-public-subnets | パブリックサブネットにあるEC2を特定する | 合格（5インスタンスを正確に特定、ルートテーブルと IGW（Internet Gateway）も確認） |
| 5 | list-ec-instances-all-regions | 全リージョンのEC2インスタンスIDを列挙する | 合格（6インスタンスを正確に列挙） |
| 6 | list-ec-instances-all-regions-1 | インターネットからSSH到達可能なEC2を特定する | 合格（2インスタンスを正確に特定、SG（セキュリティグループ）/NACL（Network Access Control List）/IGW も確認） |
| 7 | list-ec-instances-by-vpc-across-regions | 全リージョンでVPCごとにEC2を整理する | 合格（4VPC×6インスタンスを正確に分類） |
| 8 | list-ec-private-ips-all-regions | 全リージョンのEC2とプライベートIPをテーブル形式で出力する | 合格（6インスタンスのIPを正確に記載） |
| 9 | list-unused-security-groups-all-regions | 全リージョンで未使用のセキュリティグループを列挙する | 合格（8個の未使用SGを正確に特定） |
手動評価結果: 9タスク中9タスク合格（Pass_Rate相当: 1.000）
Claude Code + Claude Sonnet 5 の組み合わせは、EC2マルチリージョン環境に対するインフラ調査タスクを全て正確に完了しました。回答にはインスタンスID、IP アドレス、VPC ID、セキュリティグループID、ルートテーブル、NACL等の具体的な値が全て含まれており、正解データと完全に一致しています。
自動採点が完了しなかった理由
aws-bench の verifier（自動採点用 LLM judge）は、使い捨てアカウント内の IAM ロール経由で Bedrock を呼び出しますが、以下の問題により認証に失敗しました。
- 管理アカウントの us-west-2 リージョンで STS（AWS Security Token Service）エンドポイントが無効化されていた
- 使い捨てアカウントおよび管理アカウントで、Anthropic のユースケースフォームが未提出だった（初回利用時に必要）
- 上記2点を解決した後も、verifier コンテナ内で取得した STS トークンが Bedrock 呼び出し時に無効と判定される事象が継続
この問題は aws-bench Research Preview（v0.7.0）のバグとして GitHub に Issue を提出済みです。
Kiro CLI について
aws-bench は Kiro CLI にも対応していますが、認証に KIRO_API_KEY（ksk_…形式の静的 API キー）が必要です。このキーは Kiro ポータル（app.kiro.dev）の「API Keys」から発行します。今回は個人アカウントで検証したため Kiro サブスクリプションがなく、Kiro CLI での実行は見送りました。
検証時のハマりどころ
| No | 事象 | 原因 | 対処 |
|---|---|---|---|
| 1 | uv sync で numpy のビルドに失敗 |
Python 3.14 と numpy 1.26.4 の非互換 | uv python install 3.12 + uv sync --python 3.12 |
| 2 | env setup で Docker permission denied |
docker グループ未反映 | newgrp docker（util-linux-extra のインストールが必要な場合あり） |
| 3 | env setup で dataset 未指定エラー |
--dataset オプションが必須 |
--dataset aws-bench-quickstart を追加 |
| 4 | Quotas 未反映で setup 失敗の可能性 | Service Quotas の API 反映に最大30分 | env show で確認してから setup 実行 |
| 5 | Kiro CLI で全タスク PreflightError | KIRO_API_KEY 環境変数が未設定 |
Kiro ポータルで API キーを発行し export する |
| 6 | Claude Code で全タスク NonZeroAgentExitCodeError | Bedrock bearer token 未生成のまま実行 | eval $(uv run aws-bench env creds --eval) を実行してから run |
| 7 | verifier が RewardFileNotFoundError | verifier コンテナに Bedrock トークンが渡されていない | --ve "AWS_BEARER_TOKEN_BEDROCK=$AWS_BEARER_TOKEN_BEDROCK" を追加 |
| 8 | verifier が「Model use case details have not been submitted」 | 使い捨てアカウントで Anthropic のユースケースフォーム未提出 | 使い捨てアカウントの Bedrock コンソール → モデルカタログから Anthropic のフォームを提出 |
クリーンアップ
検証完了後、以下のコマンドでテスト環境を削除します。3リージョン分の CloudFormation スタック削除が行われるため、約30分かかります。
uv run aws-bench env cleanup --env-name bench-test --dataset aws-bench-quickstart
確認:
uv run aws-bench env show --env-name bench-test
「Stacks: none」と表示されればリソース削除が完了しています。次にアカウントを閉鎖します。
uv run aws-bench env terminate --env-name bench-test
次のメッセージが出ればOKです。
Terminated environment 'bench-test' successfully.
確認:
uv run aws-bench env show --env-name bench-test
次のメッセージが表示され、OU とアカウントが表示されなくなっていれば完了です。
TestEnvironmentNotFoundError: No testing environment OU 'bench-test' found. Run env init first.
最後に、AWS マネジメントコンソールで以下を実施します。
- Organizations コンソールで OU「bench-test」が「閉鎖済み」となっていることを確認
- IAM コンソール → ロール → 該当ロール → AdministratorAccess をデタッチ
- ReadOnlyAccess を再アタッチし、元の状態に戻ったことを確認
コスト
| 項目 | コスト |
|---|---|
| aws-bench ツール本体 | 無料（オープンソース、Apache 2.0） |
| Amazon Bedrock Claude Sonnet 5（エージェントの LLM 呼び出し） | $5.37 |
| Amazon Bedrock Claude Opus 5 | $0.004 |
| テスト用 EC2 インスタンス（t3.micro × 6台、検証中のみ） | 無視できる程度（無料利用枠内） |
| Lambda、S3 等 | $0.002 未満 |
| Tax | $0.54 |
| Organizations メンバーアカウント | 追加料金なし |
| 合計（7/28分） | 約 $5.92 |
今回は verifier の認証問題で合計18回実行したため（7/28: 10回、7/29: 8回）、通常より多くの Bedrock 費用が発生しています。正常に1回で完了した場合、Bedrock 費用は $1〜2 程度に収まると推定されます（9タスク × 約$0.15/タスク）。7/29分のコストは AWS Cost Explorer 未反映のため含まれていません。
まとめ
- aws-bench は AI コーディングエージェントの AWS タスク実行能力を、実環境で定量的に測定できるオープンソースベンチマークツールである
- 使い捨ての AWS アカウントを自動作成するため、既存環境への影響がない
- quickstart データセット（9タスク / 1シナリオ）であれば、環境構築からベンチマーク実行まで約1時間で完了する
- Research Preview のため、認証設定やユースケースフォーム提出などのセットアップでハマりどころが多い。本記事の「検証時のハマりどころ」を参照していただくことで回避可能
- Claude Code + Claude Sonnet 5 は、EC2マルチリージョン環境に対するインフラ調査タスク9問全てに正確に回答した（手動評価 Pass_Rate 相当: 1.000）
- 自動採点（verifier）は Research Preview 段階のバグにより完了しなかった（GitHub に報告済み）
- 2026年7月30日追記: GitHubメンテナーから回答があり解決に至った。後述する
参考
- What's New: AWS announces aws-bench, an open-source benchmark for AI agents on AWS（2026年7月24日）
- GitHub: aws-bench/aws-bench
- GitHub: aws-bench/aws-bench-datasets
追記（2026年7月30日）: Issueに返信があり、解決しました
本記事公開後、GitHub Issueにメンテナーから返信がありました。要点は以下の通りです。
- ドキュメント（Getting Started guide）の記載に不備があったことを認める。修正予定とのこと
- 実際には verifier はコンテナが持つアンビエントな認証情報をそのまま使う仕様になっており、これはエージェントがトライアル中に使うのと同じ使い捨てアカウントの
OrganizationAccountAccessRoleである。このロールには Bedrock アクセス権限がないため、上記のエラーが発生していた - 推奨される回避策として、管理アカウント側で Bedrock 推論を行うことを提案。具体的には、
aws-bench env credsで Bedrock bearer token を生成し、--veオプションで verifier コンテナにも渡す - 補足として、
--include-task-name "タスク名"を付けることで、quickstartデータセットのうち1タスクだけを実行し、数分でセットアップの動作確認ができる、というTipsも共有された
eval $(uv run aws-bench env creds --eval) uv run aws-bench run --env-name bench-test --dataset aws-bench-quickstart \ --agent claude-code -m global.anthropic.claude-sonnet-5 \ --ve "AWS_BEARER_TOKEN_BEDROCK=$AWS_BEARER_TOKEN_BEDROCK" \ --yes
教えてもらった --include-task-name のTipsを使い、まず1タスクだけで切り分けて再テストしたところ成功。改めて9タスク全てを実行したところ、以下の結果になりました。
Trials: 9 Exceptions: 0 Pass_Rate: 1.000 N_Tasks: 9 N_Passed: 9 Total runtime: 10m 54s
全9タスクが自動採点（verifier）でも reward 1.0（合格）となり、手動評価の結果と完全に一致しました。
なお、この --ve オプション自体は本記事の検証時から使用していたにもかかわらず失敗していたため、なぜ再実行時に成功したのかは明確には分かっていません。更新があったらブログをアップデートします。
