aws-benchのStep Functions診断タスクをKiro CLIの17モデルで試してみた
はじめに
AWS が公開した AI エージェント向けベンチマーク aws-bench について、これまで2本の記事を書きました。1本目はベンチマークの仕組み、2本目は単一アカウントで動かすミニテスト環境の構築を扱いました。
今回は、そのミニテスト環境で実際に測った結果を紹介します。取り上げるのは diagnose-step-functions-failing-executions の1タスクです。Step Functions のステートマシンで実行が失敗している原因を調べさせる内容です。
対象は17モデルで、同じ条件で3周ずつ解かせました。以降、1セルはモデル1つの1周を指し、分母の51は17モデル × 3周を表します。
| 項目 | 内容 |
|---|---|
| 対象モデル | 17。測定時に kiro-cli から選べたモデルのうち auto と qwen3-coder-next を除くすべて |
| 実行回数 | 同一条件で3周。1タスクあたり51セル |
| エージェント | kiro-cli 2.15.1 をヘッドレス実行。Docker コンテナに隔離し、ホスト側のベンチマーク資材はマウントしません |
| AWS 権限 | read-only ロールのみ。このタスクは診断だけで、リソースは変更しません |
| 1セルの上限 | エージェント300秒。公式の600秒から短縮しましたが、51セルすべてが上限内に収まりました |
| 判定 | ホスト側で claude-sonnet-5 に固定しました |
| クレジット | ヘッドレス実行の Credits にモデル倍率を掛けた比較用の値です。金額には換算していません |
| 測定期間 | 2026-07-29 14:16〜2026-07-30 03:34 |
タスク定義はデータセットのコミット 2daf77d2d41c21bae00bf8227fc463be51f721d0 を参照しています。ベンチマーク本体は edfab47710a505b7e73de66584a84f8b9bb6e26c です。なお、判定に使った claude-sonnet-5 は評価対象の17モデルにも含まれます。この重なりが判定に与える影響は、本記事では検証していません。
タスクの内容
タスク定義は公開データセットにあります。以下は要点で、指示文や参照回答の原文はリンク先で確認できます。
| 項目 | 内容 |
|---|---|
| 種別 | introspection（読み取り・診断のみ） |
| 対象サービス | Step Functions、Lambda |
| リージョン | ap-southeast-2 |
| 公式のタイムアウト | エージェント600秒 / 判定240秒 |
事前にデプロイするリソース
診断対象のリソースは、シナリオ付属の CDK スタック1本で作られます。
| リソース | 役割 |
|---|---|
| Lambda 関数（Python 3.12、インラインコード） | ステートマシンから呼ばれる処理関数 |
| CloudWatch Logs ロググループ | 上記 Lambda のログ出力先 |
| IAM ロール | ステートマシンが Lambda を呼ぶための権限 |
| Step Functions ステートマシン | InvokeProcessingLambda ステートで Lambda を呼びます |
仕込まれた異常
Lambda のインラインコードは、処理本体が次の1行だけです。
def handler(event, context):
raise RuntimeError("Configuration validation failed: missing required field 'targetBucket'")
エラーメッセージは「必須フィールド targetBucket が無い」と読めますが、実際にはコードが入力を検査していません。ハンドラーの本体が例外1行だけなので、どんな入力でも失敗します。
デプロイ後、setup スクリプトが動き、ステートマシンの実行を5本開始して終了まで待ちます。異常自体は CDK 側に埋め込まれており、このスクリプトは失敗した実行履歴と Lambda のエラーログを作る役割を担います。同名の実行が既にある場合はスキップする冪等な作りになっています。
エージェントへの依頼
指示文の要旨は「指定したステートマシンで実行が失敗している。なぜか」という1文です。プレースホルダを実際の ARN に置き換えたうえで、隔離コンテナ内のエージェントに渡します。エージェントは read-only の一時認証情報で AWS を調べ、最終回答を /logs/agent/agent-output.txt に書きます。参照回答やルーブリックはコンテナに渡していません。
回答の判定方法
判定は、回答と参照回答が同等かどうかの二値です。部分点はありません。
| 項目 | 内容 |
|---|---|
| 判定基準 | answers_equivalent。回答に従った実務者が、参照回答に従った場合と同じ結論・同じ行動に至るか |
| ルーブリック | judge_prompt.md。troubleshooting-multiservice の21タスク共通のファイルで、タスク固有の記述はありません |
| 判定モデルに渡すもの | エージェントの回答と参照回答だけです。AWS の実状態は渡しません |
| 参照回答の要旨 | すべての実行が InvokeProcessingLambda で失敗し、原因は Lambda が targetBucket 欠落の RuntimeError を投げていること |
ルーブリックは、次のいずれかに当たる回答を不合格とします。
- 壊れているか正常かの判断が逆
- 原因が違い、問題の説明にならず解決にもならない
- インフラの実状態やリソース構成について参照回答と矛盾している
- 提案した修正が実際には動かない（パラメータ不足、対象違い）
- 参照回答に挙げられた主要な原因が欠けている
- インフラについて誤った情報を断定し、実務者を誤らせる
このタスクは修正の提示を求めていないため、実質的には原因の一致だけが問われます。
公式判定の結果
17モデルすべてが3周とも pass で、51/51 でした。
判定理由も51件すべてが targetBucket に言及しており、同じ根本原因を指して pass しています。fail が1件もないため、このタスクには判定のずれを調べる対象がありません。
回答の中身は揃っていたわけではありません。Lambda のコードが入力を参照せず無条件に例外を投げる点まで踏み込んだ回答は、51件中10件でした。内訳は claude-opus-5 が3件、claude-opus-4.7 が3件、claude-opus-4.8 が2件、claude-sonnet-5 が2件です。次は claude-opus-5 の2周目からの抜粋です。
That Lambda's handler raises an unconditional RuntimeError on every invocation
...
is irrelevant to the failure because the handler never reads the event.
Primary fix - replace the unconditional raise in the Lambda with real validation and real work.
一方で、ステートマシンの入力に targetBucket を追加すれば直る、と提案した回答もありました。次は minimax-m2.1 の2周目からの抜粋です。ハンドラーは入力を読まないため、この修正では解決しません。
To fix this issue, ensure that when invoking the state machine, the execution input
includes a `targetBucket` field with a valid S3 bucket name.
同じく入力側で対処する案は gpt-5.6-luna と claude-haiku-4.5 も挙げています。claude-haiku-4.5 の3周目は、Lambda 側を直す案として「index.py の検証処理から必須項目を外す」と書いていました。ハンドラーには検証処理そのものが存在しません。ただし、この差は合否に影響していません。
正解1件あたりのクレジットと所要時間
全セルが正答なので、3周分のクレジットと時間を3で割った値がそのまま1件あたりの値になります。表はクレジットの降順です。
| モデル | 倍率 | 正答回数 | 正解1件あたりクレジット | 正解1件あたり所要時間 |
|---|---|---|---|---|
claude-opus-4.7 |
2.2 | 3/3 | 6.23 | 100秒 |
claude-opus-5 |
2.2 | 3/3 | 5.60 | 92秒 |
claude-opus-4.8 |
2.2 | 3/3 | 5.52 | 87秒 |
claude-opus-4.6 |
2.2 | 3/3 | 2.91 | 52秒 |
gpt-5.6-sol |
2.4 | 3/3 | 2.83 | 64秒 |
claude-opus-4.5 |
2.2 | 3/3 | 2.20 | 41秒 |
claude-sonnet-5 |
1.3 | 3/3 | 1.60 | 86秒 |
claude-sonnet-4 |
1.3 | 3/3 | 1.38 | 65秒 |
claude-sonnet-4.6 |
1.3 | 3/3 | 1.32 | 64秒 |
claude-sonnet-4.5 |
1.3 | 3/3 | 1.15 | 58秒 |
gpt-5.6-terra |
1.2 | 3/3 | 0.70（0.56） | 34秒 |
glm-5 |
0.5 | 3/3 | 0.51 | 43秒 |
deepseek-3.2 |
0.25 | 3/3 | 0.19 | 77秒 |
gpt-5.6-luna |
0.6 | 3/3 | 0.19（0.04） | 29秒 |
minimax-m2.5 |
0.25 | 3/3 | 0.15 | 49秒 |
claude-haiku-4.5 |
0.4 | 3/3 | 0.07 | 27秒 |
minimax-m2.1 |
0.15 | 3/3 | 0.05 | 34秒 |
gpt-5.6-luna と gpt-5.6-terra のかっこ内の値は、2026年7月30日に発表された Amazon Bedrock の値下げ率を使って計算しました。Kiro のモデル倍率にも同じ率で反映されると仮定した値です。Luna が 80%、Terra が 20% の値下げで、Sol は据え置きのため併記していません。今回の測定は値下げ発表前に行っており、Kiro 側の倍率改定は発表されていません。表の並びは、かっこ外の実測値の降順です。
最上位の claude-opus-4.7 が 6.23、最下位の minimax-m2.1 が 0.05 で、同じ正解に対する支払いは約120倍開きました。モデル倍率の幅は 0.15 から 2.4 までの16倍なので、倍率だけでは説明できません。倍率を掛ける前のクレジット消費量にも差があり、倍率との積で開きが広がっています。
所要時間の幅は27秒から100秒で、クレジットほどは開きませんでした。また、クレジットの順序と時間の順序は一致しません。deepseek-3.2 と gpt-5.6-luna は1件あたり 0.19 で並びますが、所要時間は77秒と29秒です。安く済むモデルが速いとは限りません。
まとめ
17モデルすべてが3周とも正答したため、このタスクには成績で選ぶ余地がありません。倍率0.15の minimax-m2.1 まで通っているので、廉価なオープンモデルでも解ける難易度でした。
選ぶ基準として残るのは支払いと所要時間です。今回紹介したタスクのようにシンプルな調査を Kiro で回すなら、gpt-5.6-luna と claude-haiku-4.5 が候補になります。前者は0.19・29秒（値下げ反映の仮定では0.04）、後者は0.07・27秒です。どちらもクレジットが低く、所要時間は最短で、原因の特定という要求には応えています。Opus 系と gpt-5.6-sol は 2.20〜6.23 で claude-haiku-4.5 の31〜89倍でした。所要時間も41〜100秒と長く、この要求には費用と時間の両面で過剰でした。
ただし、安価なモデルから得られるのは「どこで何が失敗しているか」までです。gpt-5.6-luna と claude-haiku-4.5 は、修正案として実行入力に targetBucket を渡す案と、Lambda の検証処理から必須項目を外す案を挙げました。どちらも Lambda が入力を検証している前提に立っていますが、その検証処理は存在しません。エラーメッセージの文面から実装を推測した結果で、ハンドラーは入力を読まないため、書かれたとおりに直しても失敗は止まりません。
一方、Lambda のコードを読み、入力に関係なく必ず失敗すると書いた回答は51件中10件でした。さらに、その観察を修正案まで一貫させ、直すべき場所は Lambda のコードだと明示したのは7件です。claude-opus-5 が3件、claude-opus-4.7 が2件、claude-opus-4.8 が2件で、うち2件は入力に targetBucket を足しても直らないと断っています。残る3件（claude-opus-4.7 の1件と claude-sonnet-5 の2件）は、無条件に失敗すると書いていました。しかし修正案では環境変数か Payload への targetBucket 追加を最有力に挙げており、観察と対処が食い違っています。
時間と費用を優先し、与える課題が異常の検出までであれば、安価なモデルでも対応できる可能性があります。これに対し、コードまで読んで根本解決の方針まで求める場面では、時間とコストをかけて Opus 系を充てるのが望ましいといえます。今回のタスクは前者に当たります。Opus 系を充てても成果は得られますが、支払いは数十倍になるため、この課題に対する費用対効果は良くありません。
なお、同じデータセットの別タスクでは正答率そのものが分かれたものもありました。そちらは別の記事で紹介予定です。
