Amazon Nova Actがユーザーの意図を軸にSynthetic Monitoringを再構築
Amazonは、Amazon Nova Actを使ったSynthetic Monitoringの実装に向けた6ステップのリファレンス実装を公開した。固定的なUIセレクタを、自然言語によるブラウザ操作に置き換えるものだ。9月28日に公開されたこの仕組みは、Nova Act、Amazon Bedrock AgentCore、EventBridge Scheduler、CloudWatch、SNSを組み合わせる。その中核となる主張は、通常のインターフェース変更で従来のスクリプトが壊れる場合でも、エージェントなら重要な顧客ジャーニーを継続して確認できるという点にある。
この約束は、Synthetic Monitoringを巡る議論を変える。もはや、スクリプト化されたブラウザがボタンをクリックできるかだけが問われるわけではない。AIエージェントが意図されたボタンを認識し、ジャーニーを完了させ、結果を検証し、アプリケーションの障害と自身の不確実性を区別できるかが焦点となる。
SeleniumとPlaywrightは、決定論的な制御機能を備えた成熟した自動化フレームワークであり続けている。AWSは、ソフトウェアテスト全体でこれらのツールを置き換えようとしているわけではない。代わりに、各操作を完全に制御することと同じくらい、ロケータの保守負担を減らすことが重要な、反復的な本番チェック向けの異なる運用モデルを提案している。
AWS、ブラウザエージェントをスケジュール型モニターへ転換
このリリースは、ブラウザの推論、隔離された実行、スケジューリング、アラートを、一元管理された監視経路にまとめている。
Synthetic Monitoringでは、実際の顧客から問題報告が来る前に、アプリケーションに対して自動トランザクションを実行する。モニターは、サインイン、商品の検索、商品ページの表示、カートへの追加、チェックアウトの利用可否の確認を行う場合がある。
インフラストラクチャメトリクスだけでは、その一連のジャーニーが機能しているかを必ずしも明らかにできない。バックエンドが正常なステータスコードを返していても、無効化されたボタン、壊れたオーバーレイ、遅延するサードパーティ製ウィジェット、フロントエンドの回帰によって、顧客が先へ進めなくなる可能性がある。
新たな監視アーキテクチャでは、EventBridge SchedulerがAgentCore RuntimeでホストされたNova Actワークフローを呼び出す。Nova Actはその後、AgentCore Browserセッションを操作し、ジャーニーが失敗した際にはSNSがアラートを配信する。
AWSは、ジャーニーの重要度に応じて、5分ごとから1時間ごとまでのスケジュールを提案している。サンプルは6ステップのeコマースフローに焦点を当てており、ページの読み込み挙動に応じて、実行時間は2分から4分と報告されている。
このリリースが重要なのは、ブラウザ操作そのものにとどまらないからだ。サンプルには、エージェントコード、デプロイ自動化、Infrastructure as Codeの選択肢、アラートルーティング、デッドレター処理、実行漏れに対するアラームが含まれる。
AWSは2つのデプロイパスを用意している。Pythonデプロイスクリプトは前提条件を確認し、SNSトピックを作成し、ワークフローをデプロイして、スケジュールを接続する。別のAWS Cloud Development Kitスタックは、再現可能なインフラストラクチャのプロビジョニングを担う。
CDKパスは、失敗したスケジューラー呼び出しのためのAmazon SQSデッドレターキューを追加する。また、デッドレターキューの深さと、実行されなかったスケジュールを対象とするCloudWatchアラームも作成する。
この区別は重要だ。モニターの失敗は、スケジューラーがエージェントに到達しないために起こる場合もあれば、エージェントがアプリケーションに到達して壊れたジャーニーを検知するために起こる場合もある。インフラストラクチャアラームは前者をカバーし、エージェントのSNSメッセージは後者を扱う。
したがって、サンプル実装は、監視を個別に可観測なコンポーネントの連鎖として扱っている。ブラウザインテリジェンスをソリューション全体として提示するよりも、こちらの方が信頼性が高い。
この連鎖は新たな依存関係も生む。有効な結果は、EventBridge、AgentCore Runtime、AgentCore Browser、Nova Act推論、対象アプリケーション、アラート経路に依存する。チームは最終ステータスをただ信頼するのではなく、モニター自体を監視する必要がある。
ユーザージャーニーの失敗がセレクタ保守に圧力をかける
AWSは、本番ブラウザチェックにはすべてのインターフェース詳細を事前にエンコードしなければならないという前提に疑問を投げかけている。
従来のブラウザ自動化では、ロール、ラベル、テストID、CSSセレクタ、XPath式といった契約により要素を特定する。このアプローチは精度を提供する一方、その持続性は選択した契約に依存する。
Seleniumは、ページをブラウザが構造化して表現したDocument Object Model、すなわちDOM内で、要素を見つける複数の方法を提供する。ロケータに関するガイダンスでは、利用可能な場合は安定したIDを、そうでない場合は簡潔なCSSセレクタを推奨している。
Playwrightは、自動待機、リトライ、ユーザー向けプロパティに基づくロケータによって、このモデルを改善している。公式のロケータドキュメントでは、長いCSSやXPathの連鎖よりも、ロール、テキスト、ラベル、明示的なテストIDを推奨している。
こうした機能により、「AIは機能し、スクリプトは壊れる」という比較はより複雑になる。適切に設計されたPlaywrightテストは、再レンダリングや多くのタイミング変更に耐えられる。安定したアクセシビリティロールやテストIDも、視覚的な再設計を乗り越えられる可能性がある。
チームが完全には制御できないページを監視する場合、保守負担はより深刻になる。サードパーティのIDプロバイダー、決済インターフェース、同意ダイアログ、埋め込み型予約サービス、頻繁にテストされる本番バリアントでは、安定した契約が提供されない場合がある。
社内で制御するページでも、変更負荷は生じうる。ラベルの変更、チェックアウトコンポーネントの移動、実験による異なるレイアウトの配信によって、テストが失敗する可能性がある。エンジニアはその際、製品が失敗したのか、モニターが古くなったのかを判断しなければならない。
Amazon Nova Actは視覚的なアプローチを採る。マルチモーダルモデルでスクリーンショットを処理し、「Click the checkout button」のような自然言語の指示に基づいて動作する。この指示は、CSSクラスや要素IDではなく意図を説明する。
この抽象化こそが、セレクタベースの監視に対する中核的な圧力だ。プロダクトチームは、ユーザーに見えるタスクを変えることなく、スタイルや内部マークアップを変更できる。Nova Actがそのタスクを引き続き認識できれば、モニターはセレクタの更新なしに動作を続けられる。
AWSによれば、初期のエンタープライズユースケースでは、ブラウザワークフローの精度が90％を超えたという。この数値はAWSによるものであり、あらゆるサイト、ジャーニー、インターフェース条件での精度を保証するものではない。
それでも、この数字は意図されたトレードオフを示している。エージェントは、密結合したセレクタによって生じる決定論的な保守負担を減らすために、一定の確率的な挙動を受け入れる。
この圧力は、反復的なモニターが多く、インターフェースのリリース頻度が高いチームで最も強く現れる。個々のセレクタ修正は小さくても、多数のジャーニー、デバイス、バリアント、地域にまたがれば、継続的な運用負荷となる。
この変化は所有責任にも影響する。従来のチェックでは、テストエンジニアがアプリケーション構造を理解する必要があることが多い。意図ベースの操作により、オペレーターはビジネスジャーニーをより直接的に記述できるが、エンジニアには依然としてアサーション、権限、リトライ、可観測性の設計が求められる。
AWSは、網羅的なカバレッジを試みるのではなく、まず3〜5件の重要なワークフローから始めることを推奨している。ログイン、チェックアウト、アカウントアクセス、予約、サブスクリプション変更は、影響の小さいナビゲーション経路よりも有力な候補となる。
この助言は、提案を現実に即したものにしている。エージェント駆動の監視が最も価値を持つのは、ジャーニーの失敗が重大なビジネス上の影響をもたらし、多数の壊れやすいチェックを保守するコストを測定できる場合だ。
Amazon Nova Actを使ったSynthetic Monitoringの実装が制御レイヤーを変える
重要なのは自然言語プロンプトだけではなく、エージェント的な操作と明示的な結果検証を分離する点にある。
サンプルでは、ブラウザ操作をジャーニーステップにまとめている。Nova Actのact()メソッドは、自然言語で記述された操作を実行する。act_get()メソッドは、ワークフローがBooleanスキーマに照らして評価できる構造化情報を返す。
この分離は重要だ。ページをクリックして進むだけでは成功を証明できない。モニターは、顧客が重視する結果を確認しなければならない。
小売ジャーニーでは、完了の条件として、検索結果が表示されること、正しい商品がカートに入ること、チェックアウト経路が利用可能であることが求められる場合がある。単なるページ遷移では、空の検索結果、エラーバナー、不正なカート状態を見逃す可能性がある。
そのためAWSは、意味のあるチェックポイントでアサーションを行うことを推奨している。この設計は、すべての視覚要素を確認せずにビジネス成果を検証する。このバランスにより、外観上の変更がアラートを発生させる一方で機能障害が見えないままになる可能性を減らせる。
ステップが失敗した場合、サンプルはジャーニータイプ、対象URL、総所要時間、完了ステップ、失敗ステップを公開できる。詳細な例外はランタイムログに残り、オペレーターはそこで実行内容を調査できる。
AgentCore Runtimeは管理された実行レイヤーを提供する。ワークフローには安定したランタイムエンドポイントが割り当てられるため、EventBridge Schedulerは直接呼び出せる。更新されたデプロイでは、スケジューラーのターゲットを変更せずに新しいランタイムバージョンを作成できる。
Nova Actコマンドラインインターフェースは、ローカルのワークフローコードをパッケージ化し、そのコンテナイメージをAmazon Elastic Container Registryへプッシュして、ランタイムをプロビジョニングする。Nova Actインターフェースには、Python SDK、IDE拡張機能、ブラウザプレイグラウンド、実行トレース用のAWSコンソールも含まれる。
AgentCore Browserは、チームがブラウザファームを維持する必要がないよう、隔離されたリモートブラウザを提供する。各スケジュール実行には、Cookie、キャッシュ、ローカルストレージ、中間状態用の個別環境が割り当てられる。
AWSは、Synthetic Monitoringでは一時的なセッションを推奨している。一時的なセッションはクリーンな状態で開始され、実行後に消滅するため、前回成功したログインやキャッシュ済みページが新たな障害を隠すことを防ぐ。
AgentCore Runtimeは、CPU、メモリ、ファイルシステムのリソースを隔離する軽量仮想マシンである専用microVMを使用する。セッションアーキテクチャによれば、セッション終了時にはmicroVMが終了し、そのメモリはサニタイズされる。
隔離はセキュリティとテストの妥当性の両方を高める。あるモニターが、別のモニターの認証状態、ショッピングカート、実験の割り当て、ブラウザストレージを引き継ぐべきではない。
このアーキテクチャは内部アプリケーションにも対応する。AgentCore Browserはデフォルトでパブリックネットワークアクセスを使用する一方、VPC設定ではプライベート環境向けにエグレスを制限できる。IAMポリシーは、ワークフローが使用できるブラウザ、ランタイム、通知リソースを決定する。
認証済みジャーニーには、さらなる規律が必要となる。認証情報は、プロンプト、ソースファイル、デプロイアーティファクトに埋め込まれた環境値ではなく、AWS Secrets Managerから取得すべきだ。アクセスは、モニターに必要な特定のアカウントとトランザクション範囲に限定すべきである。
Amazon Nova Actを使ったSynthetic Monitoringの実装には、なおオーケストレーションコードが必要だ。どのジャーニーが重要か、どの頻度で実行するか、どの結果が成功を証明するか、不確実な結果をいつオペレーターに通知するかを、エージェントが決めるわけではない。
ブラウザ自動化を監視へと変えるのは、この人間が設計した制御レイヤーである。Nova Actはステップの実行方法を変えるが、信頼性は依然として周辺システムに依存する。
本当の争点は意図と決定論の対立
Nova Actはページ構造との結合を減らす一方で、予測可能なロケータの失敗を確率的な解釈に置き換える。
セレクタベースのチェックは、通常、検証可能な理由で失敗します。要素が一致しなかった、操作可能な状態にならなかった、またはタイムアウト内に想定した状態に到達しなかった、というものです。エンジニアはDOMを調べ、契約を更新できます。
エージェント型のチェックは、アプリケーションの不具合、モデルによるインターフェースの誤読、あるいは指示の曖昧さによって失敗する可能性があります。外部から見ると、これらのケースは似て見えることがあります。
これがAWSの提案における中心的な緊張関係です。意図ベースの自動化は、脆弱なセレクタを壊す日常的なインターフェース変更にも耐えられる可能性があります。一方、ページが安定した契約を公開している場合、決定論的な自動化の方が依然として理解しやすいものです。
最も強力な実装では、これらのアプローチを相互排他的なものとして扱いません。チームは、低レベルのAPIチェック、コンポーネントテスト、決定論的なブラウザスイートを維持しつつ、選定した本番ユーザージャーニー向けにエージェント駆動のモニターを追加できます。
各レイヤーは異なる問いに答えます。APIチェックはサービスが正しく応答するかを判断します。決定論的なエンドツーエンドテストは、定義済みのアプリケーション契約を検証します。エージェント駆動のモニターは、ブラウザが依然としてユーザーに見える目標を達成できるかを問います。
この違いはリデザイン時に明確になります。アクセシビリティの意味論が安定していれば、roleベースのPlaywrightロケーターは引き続き動作するかもしれません。CSSチェーンは即座に失敗する可能性があります。Nova Actは視覚的に成功するかもしれませんが、複数の要素が似て見えるため誤ったコントロールを選ぶ可能性もあります。
この変動性により、ジャーニーの文言そのものがテスト設計の一部となります。「チェックアウトを完了する」は、「表示されているチェックアウトコントロールを選択し、レビュー画面が表示されることを確認し、注文は確定しない」よりも大きな裁量を残します。
特に破壊的なトランザクションについては、指示で境界を明示する必要があります。本番モニターが実際の支払いを誤って送信したり、メッセージを送ったり、顧客データを変更したり、在庫への圧力を生み出したりしてはなりません。
結果のアサーションにも同じ注意が必要です。カートアイコンだけを確認するモニターは、誤った商品が追加されていても成功と報告する可能性があります。すべてのラベルとレイアウトの詳細を検証するモニターは、本来減らすはずだった保守負担を再び生み出します。
チームには不確実性に関する方針も必要です。単発のモデル障害に、繰り返される顧客影響のある障害と同じ重大度を自動的に与えるべきではありません。逆に、過度な再試行は、実際のユーザーがなお経験している断続的な不具合を隠す可能性があります。
AWSのサンプルでは、各ステップにつき1回の試行を選択しています。これによりブラウザ実行時間と推論利用量を抑えられますが、AWSも、Nova Actが存在する要素を見つけられない場合に誤アラートが発生し得ることを認めています。
ステップレベルの再試行は、こうしたアラートを減らせます。しかし、セッションは長くなり、新たな解釈上の問いも生まれます。2回目の試行で成功したことは、健全なアプリケーションを意味するのでしょうか、それとも劣化した体験を意味するのでしょうか。
答えはジャーニーによって異なります。低リスクな検索チェックでの1回の再試行は許容できるかもしれません。認証やチェックアウト中に繰り返されるためらいは、それ自体が調査に値する可能性があります。
エージェント駆動のモニタリングは、テストレビューも変えます。エンジニアはプロンプト、アサーションスキーマ、スクリーンショット、トレース、再試行の挙動、モデルの結果を検査しなければなりません。DOMセレクタは、もはや唯一の実行可能な仕様ではありません。
これは保守をなくすものではありません。保守の対象を、意図の定義、評価ルール、アクセス制御、失敗分類へと移します。この転換には価値があり得ますが、チームは当然視するのではなく測定すべきです。
したがって、SeleniumとPlaywrightにかかる圧力は限定的かつ特定のものです。Nova Actは、本番ジャーニー監視の唯一の手段としての両者の利用に挑戦します。しかし、精密で再現性の高いエンジニアリングテストにおける役割を置き換えるものではありません。
90パーセントのエージェントは、まだ信頼できるページャーではない
最大の未解決課題は、真の障害を見逃さずに誤アラートを低く抑えられるかどうかです。
AWSが報告する90パーセント超の精度は期待を持たせますが、個別モニターのサービスレベル目標ではありません。多様なワークフロー全体での精度からは、特定サイト、リリースパターン、認証フロー、地理的リージョンにおける性能は明らかになりません。
残るエラー率は、監視頻度において重要です。5分ごとに実行されるチェックは、30日間の月に約8,640回実行されます。エージェント起因の障害率が小さくても、この規模では気を散らすアラートを生む可能性があります。
AWSのサンプルでは、6ステップのジャーニーごとに約24回のアクションおよびアサーション呼び出しを見積もっています。5分間隔では、月あたり約207,360回のNova Act操作に達します。
これらの数値は、あらゆるデプロイメントの予測ではありません。対象範囲を拡大する前に、チームがステップごとの信頼性、セッション時間、アラート品質を評価すべき理由を示しています。
合理的な展開はシャドーモードから始まります。エージェントはオンコールチームを呼び出さずに実行でき、その間に運用担当者は結果を決定論的なチェック、アプリケーションテレメトリー、手動再現と比較します。
チームは障害を原因別に分類すべきです。有用なカテゴリには、確認済みのアプリケーション不具合、想定されたアプリケーション変更、エージェントの解釈エラー、認証問題、インフラストラクチャ呼び出しの失敗、結論不十分な結果が含まれます。
この分類により、指示と再試行を調整するために必要な証拠が得られます。また、エージェントが保守を減らしているのか、それとも単に別のレビューキューを生み出しているのかも明らかになります。
モニター自体の監視も不可欠です。CloudWatchの呼び出しメトリクスは、エージェントが意図した頻度で実行されているか、各実行にどれほど時間がかかるかを示せます。SQSデッドレターキューは、ランタイムに到達しなかったスケジューラー配信を明らかにします。
これらのシグナルは、ジャーニーアラートの代わりにはなりません。チェックアウトの障害を検出した後でも、ランタイムは正常に返る可能性があります。逆に、スケジューラー、ランタイム、ブラウザ、通知経路が失敗している一方で、アプリケーションは健全なままである可能性があります。
セキュリティも別の重要な論点を生みます。ブラウザエージェントは、信頼できないテキストを含む可能性のあるページコンテンツを見ます。チームは許可するドメイン、付与する権限、利用可能なツール、許容されるトランザクションを制限すべきです。
認証情報にも最小限の権限が必要です。合成アカウントが、実際の顧客や従業員と同じアクセス権を継承すべきではありません。そのデータは識別可能かつ削除可能であり、適切な場合には業務レポートから除外されるべきです。
地理的な監視には慎重な解釈が求められます。AWS Regions全体にワークフローをデプロイすれば、リージョン別のアクセスやレイテンシーの問題を明らかにできますが、クラウドブラウザはすべての住宅回線、デバイス、顧客環境を再現するわけではありません。
CAPTCHA、ボット検出、同意システム、不正対策も、合成ブラウザを実ユーザーと異なる形で扱う場合があります。エージェントセッションの成功は、すべての顧客が同じ経路をたどることを保証しません。
モデル自体も時間とともに変化する可能性があります。チームには、アプリケーションの変更とエージェントの挙動変化を分離するための回帰ジャーニーとバージョン記録が必要です。
AWSは、実行、セッション、アクト、ステップを含む実行トレースをNova Actコンソールから提供しています。これらの記録は障害調査に役立ちますが、組織はスクリーンショットや機密性のあるページデータを含むアーティファクトの保持期間を決める必要があります。
適切な基準は完全な精度ではありません。従来のモニターも不安定な障害を生みます。重要な問いは、新しいシステムが対応者を圧倒せずに検出を改善し、保守を削減するかどうかです。
独立した本番データが利用可能になるまで、AWSの精度に関する主張は出発仮説にとどめるべきです。各チームは、自らのジャーニーと障害許容度に照らしてその主張を検証しなければなりません。
エージェント型モニタリングが持ちこたえるかを示す3つのシグナル
次の段階は、アラート精度、ワークフローの耐久性、再現可能な本番導入の証拠によって判断されるべきです。
第1のシグナルは、確認されたアプリケーション障害とエージェント起因アラートの比率です。チームは、再現可能な不具合に対応するページ数と、解釈エラー、タイミング、曖昧な指示に起因するページ数を追跡すべきです。
限定的な再試行とプロンプト調整の後にその比率が改善するなら、Amazon Nova Actを用いた合成モニタリングを実装する根拠は強まります。運用担当者が日常的にアラートを却下するなら、このシステムはAWSが避けようとしているアラート疲れの問題を再現することになります。
第2のシグナルは、実際のインターフェース変更をまたいだ生存性です。説得力のある評価では、Nova Actを意図的に脆弱なXPathスクリプトではなく、適切に構築されたPlaywrightチェックと比較すべきです。
チームは、ラベル変更、レイアウト調整、コンポーネントの再レンダリング、実験をまたいで生き残るモニターを記録すべきです。また、決定論的なroleまたはtest-IDロケーターが動作し続ける一方で、エージェントが混乱するケースも記録すべきです。
この比較により、視覚的推論がどこで持続的な価値をもたらすかが分かります。また、契約が安定しており、アクションに精密な制御が必要なため決定論的に維持すべきジャーニーも特定できます。
第3のシグナルは、リファレンスアーキテクチャを超えたより広範な証拠です。ケーススタディでは、モニター数、実行頻度、誤アラート率、検出までの平均時間、保守時間、障害カテゴリを報告すべきです。
現在の実装と性能の主張はいずれもAWSによるものであるため、独立した結果が重要です。このアプローチがコマース、金融、旅行、医療、ソフトウェアサービス全体に一般化できるかは、本番での経験が決めます。
組織は最終的な結論を待つ必要はありません。高価値で可逆的なジャーニーを1つ選び、既存モニターと並行してエージェントを実行できます。ログインの準備状況、商品検索、チェックアウトの可用性は、範囲を限定した試行を提供できます。
この試行には、明示的な成功基準を含めるべきです。確認済み不具合の検出、誤アラート、保守の労力、セッション時間、各障害の説明に要する時間を測定してください。
比較中も既存のテレメトリーを維持してください。アプリケーションログ、APIチェック、トレース、フロントエンドのエラー報告、決定論的テストは、エージェントの結論を評価するために必要な証拠を提供します。
Amazon Nova Actを用いた合成モニタリングの実装は、万能な置き換えではなく、追加のオブザーバビリティレイヤーとして捉えるのが最も説得力があります。その価値は、ページ構造の変化がモニタリングコードに求められる変化より速い場所で、ユーザーの意図を検証することにあります。
実務上の問いは単純です。壊れたときのコストが十分に高く、スクリプト化されたチェックの負担になるほど頻繁に変化し、エージェントが継続的に実行しても十分安全な顧客ジャーニーはどれか。そこから始め、すべてのアラートを測定し、モデルをどこまで進めるべきかは本番の証拠に委ねてください。
