RescaleはStrands AgentsとAI-DLCを使い、テスト失敗を分類・振り分ける仕組みを構築しました。問題定義からステージングまで5日、本番へは数週間と報告しています。 実装を速める前に、判定基準と人の責任を明確にする事例です。誤分類、担当先の変更、根拠の確認を運用へ組み込むことが焦点です。 夜間テストの失敗を調べる反復作業を支援 AWSは10月22日、RescaleがAIによるテスト障害の分類を構築した事例を公開しました。分散サービスや複数のリポジトリーでテストが失敗すると、担当者はログや過去の傾向、コードを調べて担当チームへ送る必要があります。この作業が本番リリースの前提となり、複数部署の調整が続いていたと説明しています。RescaleはAI-DLCの方法論を用い、要件と設計を整理してからエージェントを実装しました。問題定義からステージング配備まで5日、その後数週間で本番へ進んだと報告しています。紹介された期間は、この事例の条件で得た結果です。テストの失敗を見つける処理ではなく、発生後の分類と担当への引き継ぎを支えます。限られた範囲の問題から、レビューできる仕様を作る点が特徴です。 要件と評価基準を人が決めた上で構築 Rescaleの方式は、AIが提案や実行を支援し、人が範囲を定め、結果を検証し、本番変更を承認する責任を持つ構成です。AI-DLCで確認すべき問いを整理し、要件や評価基準を明確にして、実装するエージェントに渡す仕様を作りました。Strands Agentsを用いる分類の仕組みは、失敗を調べて適切な担当へ振り分ける作業を支援します。対象はテストや当番運用を担う開発組織です。コード生成そのものより、何を分類できれば役に立つかを決める工程が強調されています。未解決のテストが配備を止める業務では、分類の誤りや証拠不足も遅延につながります。自動化する部分と、担当者が最終的に確かめる部分を分けることが重要と考えられます。原文はこの方法を他の開発工程にも広げる取り組みを紹介しています。 分類精度と証拠を運用に結び付ける 導入を検討する組織では、障害の分類体系や担当先を先に整理することが論点です。人によって判断が揺れる状態では、エージェントに渡す正解も不明確になります。ログやコードを参照する権限を絞り、どの証拠で判断したかを確認できる構成が必要と見られます。分類の速さだけでなく、誤ったチームへ送った件数や再調査にかかった時間も評価材料です。自動分類で解決が難しい場合は、人の当番へ戻す経路を用意する方法が考えられます。サンプルや事例の完成期間を、そのまま自社の計画へ当てはめることはできません。サービス構成やログの質、運用責任が異なるためです。小さく定義した問題で評価を始め、障害の種類や担当の変更に応じて仕様を更新することが、継続利用を判断する材料になります。担当の変更も追う対象です。