サードパーティポータルに対する UI 依存の自動化
すべての企業には、本来自動化されるべきなのにされていない作業のために従業員が毎日手動でログインするポータルのリストがあります。注文状況を確認するためのベンダーポータル。規制申請を行うための政府サイト。資格確認と請求状況確認のための保険ペイヤーポータル。資格認定確認のための州ライセンス委員会。コンプライアンス申告のための税務当局ポータル。
これらのポータルには API がありません。あるいは、文書化されていない、レート制限がある、またはアクセス料を支払う「優先パートナー」に限定された API があります。データはログインページの後ろにあり、HTML でレンダリングされており、それを取り出す唯一の方法はログインして UI をナビゲートすることです。
従来の自動化はブラウザスクリプトを使用します。Selenium、Playwright、または Puppeteer のスクリプトがログインし、正しいページにナビゲートし、CSS セレクターまたは XPath で要素を見つけ、データを抽出してログアウトします。これらのスクリプトは機能しなくなるまで機能します。ポータルのリデザインで CSS クラス名が変わります。ログインフローに新しい CAPTCHA が追加されます。ナビゲーションメニューがサイドバーからハンバーガーメニューに移動します。Cookie 同意バナーが送信ボタンを覆い始めます。スクリプトは無言で壊れ、そのデータに依存する下流プロセスがエラーを出し始めるまで誰も気づきません。
州の医師会は特に過酷な例です。50 があり、それぞれが異なるウェブサイト、異なるレイアウト、異なる認証方法、異なるデータフォーマットを持っています。予告なしに独自のスケジュールでリデザインします。これらのサイトのスクレイピングに依存する資格認定サービスは、任意の時点で 50 のスクリプトのうち 5 から 10 が壊れており、それぞれ開発者が新しいレイアウトを検査してセレクターを書き直す必要があります。
Triggerfish の解決方法
Triggerfish のブラウザ自動化は、CDP 制御の Chromium と LLM ベースのビジュアルナビゲーションを組み合わせます。エージェントは DOM ツリーとしてではなく、レンダリングされたピクセルとアクセシビリティスナップショットとしてページを見ます。CSS クラス名ではなく、見た目と機能で要素を識別します。ポータルがリデザインしても、ログインフォームは依然としてログインフォームに見え、ナビゲーションメニューは依然としてナビゲーションメニューに見え、データテーブルは依然としてデータテーブルに見えるため、エージェントは適応します。
セレクタースクリプトの代わりのビジュアルナビゲーション
ブラウザ自動化ツールは 7 つの操作で機能します：navigate、snapshot、click、type、select、scroll、wait。エージェントは URL にナビゲートし、レンダリングされたページのスナップショットを撮り、見えるものについて推論し、実行するアクションを決定します。ページのコンテキストで任意の JavaScript を実行する evaluate ツールはありません。これは意図的なセキュリティ上の決定です。エージェントは UI を通じて、人間と同じようにページと対話し、悪意あるページによって悪用される可能性のあるコードを実行できません。
エージェントがログインフォームに遭遇すると、視覚的レイアウト、プレースホルダーテキスト、ラベル、ページ構造に基づいてユーザー名フィールド、パスワードフィールド、送信ボタンを識別します。ユーザー名フィールドが id="auth-input-email" または class="login-form__email-field" を持つ必要はありません。それらの識別子がリデザインで変わっても、エージェントはそれらに依存していなかったため気づきません。
共有ドメインセキュリティ
ブラウザナビゲーションは Web フェッチ操作と同じドメインセキュリティ設定を共有します。triggerfish.yaml の単一の設定ブロックが SSRF 拒否リスト、ドメイン許可リスト、ドメイン拒否リスト、ドメインから分類へのマッピングを定義します。エージェントが CONFIDENTIAL に分類されたベンダーポータルにナビゲートすると、セッション taint は自動的に CONFIDENTIAL にエスカレーションされ、そのワークフローのすべての後続アクションは CONFIDENTIAL レベルの制限に従います。
SSRF 拒否リストはハードコードされており上書きできません。プライベート IP 範囲、リンクローカルアドレス、クラウドメタデータエンドポイントは常にブロックされます。DNS 解決はリクエストの前に確認され、DNS リバインディング攻撃を防ぎます。これは、ブラウザ自動化があらゆるエージェントシステムで最高リスクの攻撃面であるため重要です。エージェントを内部サービスにリダイレクトしようとする悪意あるページは、リクエストがシステムを出る前にブロックされます。
ブラウザプロファイルのウォーターマーキング
各エージェントは独自のブラウザプロファイルを維持し、時間をかけてポータルとの対話でクッキー、ローカルストレージ、セッションデータを蓄積します。プロファイルには、使用された最高の分類レベルを記録する分類ウォーターマークが付いています。このウォーターマークはエスカレーションのみ可能で、減少することはありません。
エージェントがブラウザプロファイルを使って CONFIDENTIAL ベンダーポータルにログインすると、プロファイルは CONFIDENTIAL でウォーターマークされます。PUBLIC 分類で実行される後続のセッションはそのプロファイルを使用できず、機密情報を含む可能性のあるキャッシュされた認証情報、クッキー、またはセッショントークンを通じたデータ漏洩を防ぎます。プロファイル分離はエージェントごとであり、ウォーターマーク適用は自動です。
これはポータル自動化における微妙だが重要な問題を解決します。ブラウザプロファイルはアクセスしたデータを反映する状態を蓄積します。ウォーターマーキングなしでは、機密ポータルにログインしたプロファイルがオートコンプリート候補、キャッシュされたページデータ、または永続クッキーを通じて低分類のセッションに情報を漏洩する可能性があります。
認証情報管理
ポータルの認証情報は OS キーチェーン（パーソナルティア）またはエンタープライズボルト（エンタープライズティア）に保存され、設定ファイルや環境変数には保存されません。SECRET_ACCESS フックはすべての認証情報取得をログに記録します。認証情報はワークフローエンジンによって実行時に解決され、フォーム値をプログラム的に設定することなくタイピングインターフェースを通じてブラウザセッションに注入されます。これにより、認証情報は他のすべての機密操作と同じセキュリティ層を通じて流れます。
一般的なポータル変更への耐性
一般的なポータル変更が発生した場合の対応：
ログインページのリデザイン。 エージェントは新しいスナップショットを撮り、更新されたレイアウトを識別し、ビジュアルコンテキストでフォームフィールドを見つけます。ポータルが完全に異なる認証方式（SAML、OAuth、ハードウェアトークン）に切り替えない限り、設定変更なしにログインは機能し続けます。
ナビゲーションの再構成。 エージェントはログイン後のページを読み、URL パターンではなくリンクテキスト、メニューラベル、ページ見出しに基づいてターゲットセクションにナビゲートします。ベンダーポータルが「注文状況」を左サイドバーからトップナビゲーションのドロップダウンに移動した場合、エージェントはそこで見つけます。
新しい Cookie 同意バナー。 エージェントはバナーを見て、承認/却下ボタンを識別し、クリックして、元のタスクを続行します。これは特別な目的の Cookie ハンドラーではなく、LLM の一般的なページ理解によって処理されます。
CAPTCHA の追加。 これはアプローチに正直な限界がある部分です。単純な画像 CAPTCHA は LLM のビジョン能力によっては解決可能かもしれませんが、reCAPTCHA v3 および類似の行動分析システムは自動化されたブラウザをブロックできます。ワークフローはこれらを無言で失敗する代わりに人間介入キューにルーティングします。
多要素認証プロンプト。 ポータルが以前必要なかった MFA を要求し始めると、エージェントは予期しないページを検出し、通知システムを通じて状況を報告し、人間が MFA ステップを完了するまでワークフローを一時停止します。ワークフローは MFA の完了を待って一時停止した場所から再開するように設定できます。
複数ポータルにわたるバッチ処理
ワークフローエンジンの for ループサポートにより、単一のワークフローが複数のポータルターゲットを反復できます。資格認定サービスは単一のバッチ実行で全 50 州の医師会のライセンス状況を確認するワークフローを定義できます。各ポータルとの対話は、独自のブラウザセッション、独自の分類追跡、独自のエラー処理を持つ別のサブステップとして実行されます。50 のうち 3 つのポータルが失敗した場合、ワークフローは他の 47 を完了し、3 つの失敗をポータルごとの詳細なエラーコンテキスト付きでレビューキューにルーティングします。
実際の使用例
資格認定機関は、プロバイダー登録プロセスの一環として州の医師会にわたる医療プロバイダーライセンスを確認します。従来、確認アシスタントは各委員会のウェブサイトに手動でログインし、プロバイダーを検索し、ライセンス状況のスクリーンショットを撮り、資格認定システムにデータを入力します。各確認には 5 〜 15 分かかり、組織は毎週数百件を処理します。
Triggerfish では、ワークフローが完全な確認サイクルを処理します。ワークフローはライセンス番号と対象州を持つプロバイダーのバッチを受け取ります。各プロバイダーに対して、ブラウザ自動化が関連する州委員会ポータルにナビゲートし、保存された認証情報でログインし、プロバイダーを検索し、ライセンス状況と有効期限を抽出し、結果を保存します。抽出されたデータはプロバイダーの PII を含むため CONFIDENTIAL に分類され、書き下しルールによりその分類レベル以下のチャネルに送信されないことが保証されます。
州の委員会がポータルをリデザインすると、エージェントは次の確認試行で適応します。委員会が自動アクセスをブロックする CAPTCHA を追加すると、ワークフローはその州を手動確認のためにフラグを立て、バッチの残りの処理を続けます。確認アシスタントはすべての確認を手動で行うことから、自動化が解決できない例外のみを処理することに移行します。