7月15日、AWSが「Accelerating software delivery with agentic QA automation using Amazon Nova Act – Part 2」と題した記事を公開した。AIがブラウザを自律的に操作してテストを実行する「QA Studio」が、CI/CDパイプラインへの統合機能を獲得したことで、AIによるテスト自動化がローカルのデモ段階から実際の開発フローへと踏み込む実用段階に入った。今回のPart 2は、その具体的な実装方法を解説する内容だ。

前回の記事（Part 1）では、自然言語でテストケースを定義し、AIがブラウザを視覚的に操作してテストを実行する「QA Studio」の基本構造が紹介された。QA Studioの核心にあるのはAmazon Nova Act——AWSが提供するブラウザ操作に特化したAIモデルで、画面のスクリーンショットを視覚的に解析しながら「クリック」「入力」「スクロール」などの操作を自律的に判断・実行できる。さらにQA Studioはアジェンティック（Agentic）なアーキテクチャを採用している。Agenticとは、AIが単一の命令に答えるだけでなく、目標達成に向けて複数のステップを自律的に計画・実行し、結果に応じて行動を調整する設計思想を指す。これにより、「ログインしてカートに商品を追加し、決済を完了する」といった一連の操作を、人間が逐一指示しなくても自動的にこなせる。

今回のPart 2では、その仕組みを実際のソフトウェア開発フローに組み込むための2つの機能——テストスイートとCLI——に焦点を当てている。

テストスイート：並列実行で回帰テストを高速化

QA Studioでは、個別のテストケース（ユースケース）をまとめた「テストスイート」を構成できる。スイートを実行すると、各テストケースが独立したAmazon ECS on AWS Fargateのワーカータスク上で並列実行される。20本のテストがあれば、順次実行ではなく同時に走る。

スイートは目的別に整理できる。スモークテスト（デプロイのたびに重要パスを確認）、フル回帰テスト、クロス機能の結合テストなど、用途に応じた構成が可能だ。

実行後はスイート単位で集計ビューが提供される。何件が成功・失敗・実行中かを一覧でき、失敗したテストについてはトラジェクトリログ、スクリーンショット、セッション録画まで掘り下げて確認できる。スイートごとに実行履歴も蓄積されるため、回帰の安定性を時系列で把握できる。

CI/CDパイプラインへの組み込み：QA Studio CLI

ここが今回の記事で最も実用的なポイントだ。WebUIはインタラクティブな操作向けだが、CI/CDパイプラインにはコマンドライン実行・構造化出力・終了コードによる成否判定が必要になる。それを担うのがqa-studio CLIである。

CLIはWebUIと同一のAPIバックエンドに接続するが、テストをFargateワーカーにディスパッチするのではなく、CLIを実行しているマシン（CI/CDランナー）上でAmazon Nova Actを直接動かす点が異なる。

インストールと認証

pip install -e "./qa-studio-cli[runner]"

CI/CD環境向けにはOAuth 2.0クライアントクレデンシャル認証をサポートしており、ブラウザログインなしでトークンを自動取得・キャッシュする。

export OAUTH_CLIENT_ID="your-client-id"
export OAUTH_CLIENT_SECRET="your-client-secret"
export OAUTH_TOKEN_ENDPOINT="https://your-cognito-domain.auth.region.amazoncognito.com/oauth2/token"

環境別の向き先切り替え

同一テスト定義をステージング・本番など複数環境に向けて実行できる。--base-urlフラグでドメインだけを差し替え、パスやクエリパラメータはそのまま維持される。

# ステージング環境で実行
qa-studio run --suite-id suite-456 --base-url https://staging.example.com

# 本番環境で実行
qa-studio run --suite-id suite-456 --base-url https://production.example.com

--varフラグでテストステップ内の変数（{{VariableName}}構文）を実行時に上書きすることも可能だ。テスト定義を複製せずに、環境ごとのクレデンシャルやAPIキーを差し込める。

終了コードによるパイプライン制御

パイプラインとの連携で重要なのが3段階の終了コードだ。

テスト失敗（1）とインフラ障害（2）を区別できるため、それぞれに異なるアラートや再試行ロジックを設定できる。

セキュアなシークレット管理

パスワードやAPIキーなどの機密値はAWS Secrets Managerに暗号化して保存される。テストステップはシークレット名で参照し、実際の値は実行時にのみ取得される。実行ログや履歴にシークレット値が書き出されない設計になっている。

GitHub Actions / GitLab CI / Jenkins の実装例

記事ではGitHub Actions、GitLab CI、Jenkinsそれぞれの設定例が掲載されている。各環境の実装ポイントは以下のとおりだ。

GitHub Actionsでは、if: always()を使ったアーティファクト保存ステップが実装されている。テストが失敗してジョブが中断された場合でも、セッション録画・スクリーンショット・ログが確実に保全される。テスト失敗の原因調査においてこの録画データは不可欠なため、always()による無条件保存は実運用上の重要な設計ポイントとなる。また、GitHub ActionsのOIDC連携を使ったAWS認証（aws-actions/configure-aws-credentials）との組み合わせも自然に機能する。

GitLab CIでは、回帰テストジョブをonly: schedulesでスケジュールトリガー限定に絞る設定が示されている。毎コミット時にフル回帰テストを走らせるのではなく、深夜バッチなどの定期実行に限定することで、CI全体の実行時間とコストを抑える運用パターンだ。GitLab CIのartifacts: reports:セクションを使ったJUnit形式でのテスト結果レポート出力にも対応している。

Jenkinsでは、withCredentialsブロックを使ってOAuthクライアントシークレットを注入する実装が紹介されている。withCredentialsはJenkinsがコンソール出力を自動的にマスクする機能を持つため、シークレット値がビルドログに残らない。Jenkinsパイプラインのpost { always { ... } }ブロックでのアーティファクト保存も、GitHub Actionsのif: always()と同様の役割を担う。

3環境とも基本的なCLIの呼び出し方は共通しており、認証情報の注入方法とアーティファクト保存のトリガー設定が各プラットフォームの作法に合わせて記述されている形だ。GitLab CIとJenkinsについては、GitHub Actionsに比べてコード例のステップ数がやや少なく掲載されているが、CLIの動作原理は同一であるため、基本的なパイプライン構築には十分な情報量となっている。

今後の展開

記事の末尾では、モバイルアプリへのアジェンティックテスト自動化の拡張を次回テーマとして予告している。

QA Studioのリファレンス実装（テストスイートとCLI統合を含む）はGitHub上で公開されており、デプロイ手順と詳細ドキュメントはプロジェクトのREADMEに記載されている。

詳細はAccelerating software delivery with agentic QA automation using Amazon Nova Act – Part 2を参照していただきたい。