aws-benchのVPC Flow Logs診断タスクでKiro CLI 17モデルの合否が分かれた理由を確認してみた
はじめに
AWS が公開した AI エージェント向けベンチマーク aws-bench について、これまで3本の記事を書きました。1本目はベンチマークの仕組み、2本目は単一アカウントで動かすミニテスト環境の構築、3本目はそのミニ環境で測った Step Functions の診断タスクの結果です。
今回も同じミニテスト環境で測った結果です。取り上げるのは check-vpc-flow-log-destinations の1タスクです。VPC の Flow Log が複数の送信先へ配信されているように見える原因を調べさせるタスクです。前回の 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モデルにも含まれます。この重なりが判定に与える影響は、本記事では検証していません。
記事中のロググループ名、Flow Log ID、バケット名は伏せ字にしています。
比較は、このタスクの中だけで行います。他のタスクの結果と合計したり、モデルの総合順位を出したりはしません。前回のタスクとの違いには、まとめで触れます。
タスクの内容
以下はタスク定義の要点です。指示文や参照回答の原文はリンク先で確認できます。
種別は introspection（読み取り・診断のみ）、対象サービスは VPC Flow Logs、S3、CloudWatch Logs です。リージョンは us-east-1、公式のタイムアウトはエージェント600秒 / 判定240秒です。
事前にデプロイするリソース
診断対象のリソースは、シナリオ付属の CDK スタック1本が作ります。
| リソース | 役割 |
|---|---|
| VPC（10.2.0.0/16、2AZ、パブリックサブネットのみ、NAT なし） | 診断対象 |
| S3 バケット | Flow Log の実際の送信先 |
| VPC Flow Log 1本（送信先は S3、全トラフィック、集約間隔600秒） | 唯一の有効な Flow Log |
| CloudWatch Logs ロググループ 2本 | Flow Log 用に見える名前が付いているだけで、どの Flow Log からも書き込まれていません |
仕込まれた異常
このタスクには壊れたリソースがなく、setup スクリプトもありません。紛らわしい状態がそのまま置かれているだけです。
設定上の送信先は S3 の1本だけです。しかし名前の末尾が VpcFlowLogLogGroup1 と VpcFlowLogLogGroup2 のロググループが2本あるため、複数の送信先があるように見えます。CDK 側のコメントでは、過去に失敗したスタックデプロイの残骸という想定です。
送信先にデータは残っていません。Flow Log は ACTIVE で DeliverLogsStatus も SUCCESS ですが、VPC にインスタンスがなく ENI が0本のため、S3 バケットにはオブジェクトが1件もありません。ロググループ2本もログストリームが空です。どれが本当に使われているかは、実データではなく設定から判断することになります。
これはミニ環境固有の状態ではありません。CDK スタックが作るのは VPC、バケット、Flow Log 1本、ロググループ2本だけで、公式手順でシナリオ全体をデプロイしても、この VPC に記録対象となるリソースは置かれません。有効なログレコードが存在しない状態で診断するタスクです。
エージェントへの依頼
指示文の要旨は「指定した VPC の Flow Log が複数の送信先に出ているように見える。実際に何が設定されていて、どれが本当に使われているか確認してほしい」です。プレースホルダを実際の VPC ID に置き換えたうえで、隔離コンテナ内のエージェントに渡します。エージェントは read-only の一時認証情報で AWS を調べ、最終回答を /logs/agent/agent-output.txt に書きます。参照回答やルーブリックはコンテナに渡していません。
回答の判定方法
判定は、回答と参照回答が同等かどうかの二値です。部分点はありません。
| 項目 | 内容 |
|---|---|
| 判定基準 | answers_equivalent。回答に従った実務者が、参照回答に従った場合と同じ結論・同じ行動に至るか |
| ルーブリック | judge_prompt.md。troubleshooting-multiservice の21タスク共通のファイルで、タスク固有の記述はありません |
| 判定モデルに渡すもの | エージェントの回答と参照回答だけです。AWS の実状態は渡しません |
参照回答は2点を挙げています。
- 有効な Flow Log は1本で、全トラフィックを S3 バケットへ600秒間隔で配信している
- Flow Log 用に見える名前のロググループが2本あるが、どちらにも Flow Log のデータは書かれていない
ルーブリックは、次のいずれかに当たる回答を不合格とします。
- 壊れているか正常かの判断が逆
- 原因が違い、問題の説明にならず解決にもならない
- インフラの実状態やリソース構成について参照回答と矛盾している
- 参照回答が示すより多くのリソースを列挙している
- 提案した修正が実際には動かない（パラメータ不足、対象違い）
- 参照回答に挙げられた主要な原因が欠けている
- インフラについて誤った情報を断定し、実務者を誤らせる
このタスクは修正の提示を求めていないため、実質的に問われるのは原因と構成の一致です。判定理由のほとんどは「インフラの実状態やリソース構成について参照回答と矛盾している」と「参照回答に挙げられた主要な原因が欠けている」の2つでした。
「参照回答が示すより多くのリソースを列挙している」に言及した判定理由は51件中4件です。うち2件はこの条項を検討したうえで pass、残る2件（claude-haiku-4.5 の3周目と claude-opus-4.7 の2周目）では fail の根拠になっています。
公式判定の結果
正答は51件中22件、タイムアウトは0件でした。
| モデル | 倍率 | 1周目 | 2周目 | 3周目 | 正答 |
|---|---|---|---|---|---|
claude-opus-4.5 |
2.2 | pass | pass | pass | 3/3 |
claude-opus-4.6 |
2.2 | pass | pass | pass | 3/3 |
claude-opus-4.8 |
2.2 | pass | pass | pass | 3/3 |
claude-opus-5 |
2.2 | pass | pass | pass | 3/3 |
claude-opus-4.7 |
2.2 | pass | fail | pass | 2/3 |
gpt-5.6-sol |
2.4 | pass | pass | fail | 2/3 |
deepseek-3.2 |
0.25 | pass | fail | pass | 2/3 |
claude-haiku-4.5 |
0.4 | pass | fail | fail | 1/3 |
claude-sonnet-5 |
1.3 | fail | pass | fail | 1/3 |
gpt-5.6-terra |
1.2 | fail | pass | fail | 1/3 |
glm-5 |
0.5 | fail | fail | pass | 1/3 |
claude-sonnet-4 |
1.3 | fail | fail | fail | 0/3 |
claude-sonnet-4.5 |
1.3 | fail | fail | fail | 0/3 |
claude-sonnet-4.6 |
1.3 | fail | fail | fail | 0/3 |
gpt-5.6-luna |
0.6 | fail | fail | fail | 0/3 |
minimax-m2.1 |
0.15 | fail | fail | fail | 0/3 |
minimax-m2.5 |
0.25 | fail | fail | fail | 0/3 |
このタスクでは、Claude 系列内のグレードで結果が分かれました。Opus 系の5モデルは15件中14件が正答、Sonnet 系の4モデルは12件中1件だけが正答です。Opus 系 / Sonnet 系という括りは、このタスク内での観察にとどまります。
合否の分かれ目
設定されていないロググループ2本を名指ししたかどうかが、合否を分けました。名指しの有無と公式判定の pass / fail は、51件すべてで一致しています。
有効な Flow Log は S3 宛の1本だけという主要な所見は、不合格の回答もほとんどが当てています。差が付いたのは、利用者が「複数の送信先に見える」と感じた原因まで説明できたかどうかです。
正答側は、この2本を名指ししています。claude-opus-5 の1周目からの抜粋です。
NOT USED (2):
CWL group ExampleStack-Vpc-us-east-1-VpcFlowLogLogGroup1
CWL group ExampleStack-Vpc-us-east-1-VpcFlowLogLogGroup2
不合格側は、S3 以外の送信先は存在しないという結論で終わっています。gpt-5.6-luna の1周目からの抜粋です。
No separate CloudWatch Logs, Kinesis Data Firehose, or second S3 flow-log
destination is configured.
2本に辿り着いた経路
このロググループ2本は、どの Flow Log の送信先にも設定されていません。ec2:DescribeFlowLogs の結果からは辿れないため、CloudWatch Logs 側を自分で調べる必要があります。各回の実行ログから、ロググループの調べ方を分類しました。
| ロググループの調べ方 | pass | fail |
|---|---|---|
| 名前で絞らず全件列挙した | 20 | 5 |
| prefix を指定して絞った | 1 | 11 |
| 一度も照会しなかった | 1 | 13 |
prefix で絞った12件は、/aws/vpc や flow を推測で指定し、空振りしています。実際の名前はスタック名で始まり、末尾が VpcFlowLogLogGroup1 です。prefix を推測して当てるのは困難です。
pass 側の例外2件は、CloudFormation から辿っています。gpt-5.6-sol の2周目は cloudformation list-stack-resources、gpt-5.6-terra の2周目は describe-stack-resources と get-template で2本の名前を得たうえで、ロググループを名指しで確認しています。
全件列挙しても fail した5件は、一覧に2本が含まれていたのに触れずに終えるか、無関係のロググループを挙げています。
不合格だった29件の内訳
| 内訳 | 件数 |
|---|---|
| CloudWatch 宛の送信先は存在しないと述べた、または2本に触れなかった | 23 |
| このタスクとは無関係のロググループを挙げた | 6 |
判定を見直しても覆る回答はなく、公式判定の結果がそのまま集計値です。
送信先が空だったことは、不合格の理由になっていません。送信先にデータがない点に触れた回答は51件中42件あり、pass 21件と fail 21件に分かれます。判定理由も、空であることを不合格の根拠にしていません。
前者の23件について、判定モデルは「実状態と矛盾する」と書いています。送信先として設定されていないという記述自体は事実ですが、多くの回答は「Flow Log 用のロググループはない」と書いていました。ロググループ自体はあり、Flow Log の送信先になっていないだけです。
後者の6件には、ミニ環境固有の事情があります。ミニ環境を動かしている既存の AWS アカウントには、今回のタスクとは無関係な Flow Log 風の名前のロググループが1本ありました。6件はこれを見つけて、紛らわしい送信先として報告しています。判定モデルは、本数と名前のどちらも参照回答と違うとして不合格としました。該当は claude-sonnet-5 の1周目と3周目、claude-opus-4.7 の2周目、claude-sonnet-4.6 の2周目と3周目、gpt-5.6-sol の3周目です。
このノイズは、公式手順では起きません。シナリオごとにクリーンなテストアカウントを使うためです。
正解1件あたりのクレジットと所要時間
正答と判定された22件だけを対象に、1件あたりのクレジットと所要時間を出しました。表はクレジットの降順です。
| モデル | 倍率 | 正答回数 | 正解1件あたりクレジット | 正解1件あたり所要時間 |
|---|---|---|---|---|
claude-opus-4.7 |
2.2 | 2/3 | 10.44 | 131秒 |
claude-opus-5 |
2.2 | 3/3 | 10.00 | 150秒 |
claude-opus-4.8 |
2.2 | 3/3 | 8.96 | 143秒 |
claude-opus-4.6 |
2.2 | 3/3 | 6.37 | 105秒 |
claude-opus-4.5 |
2.2 | 3/3 | 4.39 | 77秒 |
gpt-5.6-sol |
2.4 | 2/3 | 3.97 | 120秒 |
claude-sonnet-5 |
1.3 | 1/3 | 2.73 | 136秒 |
glm-5 |
0.5 | 1/3 | 1.56 | 76秒 |
gpt-5.6-terra |
1.2 | 1/3 | 1.51 | 72秒 |
deepseek-3.2 |
0.25 | 2/3 | 0.76 | 200秒 |
claude-haiku-4.5 |
0.4 | 1/3 | 0.19 | 63秒 |
gpt-5.6-terra の値は、2026年7月30日に発表された Amazon Bedrock の値下げを反映していません。今回の測定は発表前に行っており、Kiro 側の倍率改定も発表されていないためです。Terra の値下げ率20%が倍率にも同じだけ反映されると仮定すると、1件あたりのクレジットは 1.21 相当になります。
正答が0だった6モデルは、1件あたりの値を出せないため表から外しました。この6モデルに使ったクレジットは、1件の正答も生みませんでした。
同じ倍率2.2の Opus 系5モデルの中でも、1件あたりのクレジットは 4.39〜10.44 と2.4倍の差が付きました。claude-opus-4.5 は3周とも正答しながら、クレジットと所要時間の両方が最小でした。安く済んだのは古い 4.5 と 4.6 で、4.7 以降の3モデルは 8.96〜10.44 に固まっています。
まとめ
主要な所見はほとんどのモデルが当てていました。合否を分けたのは、Flow Log の設定から辿れない場所を見に行ったかどうかです。ec2:DescribeFlowLogs で分かるのは S3 宛の1本だけで、そこで止めた回答が不合格の大半でした。紛らわしいロググループ2本はどの Flow Log にも紐づいていないため、送信先の設定をいくら丁寧に読んでも出てきません。
実務でも、利用者の「複数の送信先に見える」という前提そのものが誤っている場合、設定が正しいと確認するだけでは説明が終わりません。AI エージェントに調査を任せるなら、設定に現れないリソースも対象に含めるよう指示する必要があります。
前回の Step Functions のタスクでは17モデルすべてが正答し、安価な claude-haiku-4.5 と gpt-5.6-luna を候補に挙げました。同じ2モデルは、今回それぞれ 1/3 と 0/3 です。モデルを選ぶなら、実際のワークロードに近いタスクやテストシナリオを用意して測るのが確実です。
