古いWeb業務をAI化する前の5確認

先に結論

APIのない古いWebシステムをAIエージェントで操作するなら、最初から全工程を自動化してはいけません。対象を1つの可逆な操作に絞り、送信直前で人が止められる設計から始めるのが現実的です。

導入前に確認するのは、対象範囲、セッション分離、停止条件、人の承認、操作記録の5点です。画面を認識して入力できることと、業務として安全に完了できることは別問題だからです。

AWSの発表で確認できたこと

AWSは、Amazon Bedrock AgentCore Browser ToolとStrands Agentsを組み合わせ、APIを持たないレガシーWeb画面を操作する構成例を公開しました。管理されたChromiumへPlaywright経由で接続し、JavaScriptを使う画面や複数ページのフォームを操作する設計です。

公式ドキュメントでは、ブラウザセッションはコンテナで分離され、Live View、CloudTrailログ、セッション再生を利用できると説明されています。カスタムブラウザでは、DOM変更、ユーザー操作、コンソール、ネットワークイベントをS3へ記録できます。セッション時間は既定15分、最大8時間です。

重要なのは「AIなら古い画面も触れる」という部分より、操作を隔離し、見守り、後から追える構成が最初から必要だという点です。

公開フォームで実際に試した

AWS環境そのものは構築せず、参照実装でも使われるPlaywrightの意味ベース操作を、公開テストフォームで確認しました。

httpbinのテストフォームに対して、ラベル名から次の3操作を実行しました。

1. 「Customer name」へテスト用の文字列を入力

2. 「Medium」のラジオボタンを選択

3. 「Bacon」のチェックボックスを選択

3項目はいずれも画面上のラベルから特定でき、入力値と選択状態を取得できました。送信ボタンが有効になることも確認しましたが、送信は意図的に実行していません。この境界が、本番導入で人の承認を置く場所です。

今回確認できたのは「意味のあるラベルが付いた画面なら、座標固定より壊れにくい操作ができる」ことです。本人確認、独自SSO、動的な業務ルール、通信障害からの復旧までは検証していません。

導入前の5確認

1. 対象を1画面、1操作に絞る

最初の対象は、テスト用アカウントでやり直せる入力にします。更新、削除、決済、外部送信を含む工程は分離し、読み取りと下書き作成から始めます。

2. 認証情報とセッションを分ける

共有ブラウザや個人の常用プロファイルを使わず、業務ごとに隔離したセッションを用意します。権限は対象画面に必要な最小範囲とし、秘密情報をプロンプトや操作ログへ直接残さない設計にします。

3. 停止条件を先に書く

想定外の画面、対象レコード不一致、入力値の検証失敗、一定回数の再試行、タイムアウトを停止条件にします。「AIが判断できなければ人へ戻す」を正常系として扱うことが重要です。

4. 確定操作の前に人を置く

送信、更新、削除、承認など元に戻しにくい操作は、直前の画面と変更内容を人が確認します。AIが高い確信度を示しても、この承認を省略しないほうが事故原因を追いやすくなります。

5. 記録から再現できるようにする

セッションID、開始者、対象URL、入力前後、停止理由、最終承認者を残します。スクリーンショットだけでなく、操作とネットワークの時系列があると、UI変更とモデル判断のどちらで失敗したかを切り分けられます。

採用判断

古いWeb業務が大量に残っていても、まずはAPI化や通常のRPAで安定する処理を優先します。AIブラウザを使う価値があるのは、画面の揺れや例外が多く、固定ルールだけでは保守負荷が高い工程です。

本番化の判断基準は成功率だけではありません。人への引き継ぎ率、誤入力率、処理時間、再実行回数、1件あたりの費用を少なくとも2週間記録し、手作業より安全で説明可能かを確認します。

一次情報

1. Automate legacy web applications with Amazon Bedrock AgentCore Browser Tool / AWS Machine Learning Blog

2. Interact with web applications using Amazon Bedrock AgentCore Browser / AWS Documentation

著者

しろのあ。AIと自動化を実際の運用へ入れるときの、失敗条件、監査、引き継ぎ方法を検証しています。今回は公式資料の構成を読み、公開フォームで意味ベースの入力操作まで確認しました。