AIエージェントの「ログインの壁」を突破する：AgentCore Browserの実践的活用術

深夜の障害対応や、終わりの見えない定型業務の自動化を試みるエンジニアにとって、最も忌々しい存在の一つが「ログインが必要なWebアプリケーション」です。APIが公開されていれば話は早いのですが、現実はそう甘くありません。レガシーな社内システムや、セキュリティポリシーでガチガチに固められたSaaSなど、GUI経由でしか操作できない「ブラックボックス」が、自動化のパイプラインを常にデッドロックさせてきました。これまで我々は、SeleniumやPlaywrightを駆使して無理やりログイン処理をスクリプトに埋め込み、パスワードの管理に頭を抱え、MFA（多要素認証）の壁に阻まれては深夜にアラートを鳴らすという不毛なループを繰り返してきました。

しかし、AWSが提供する「AgentCore Browser」のブラウザプロファイル機能は、この長年の苦痛に対する一つの明確な解となり得ます。この機能の本質は、Cookieやローカルストレージといったセッション情報をサンドボックス環境で永続化し、AIエージェントが「人間のように」ログイン状態を維持したままWebアプリを操作できる点にあります。単にブラウザを立ち上げるだけでなく、認証情報をプロファイルとして切り離して管理することで、AIに直接パスワードを渡すというセキュリティ上の悪夢を回避しつつ、セキュアな自動化を実現する。これは、単なる機能追加ではなく、AIエージェントが「社内システム」という閉じた世界へアクセスするための「正規のパスポート」を手に入れたことを意味します。

具体的には、AWS CLIを用いてaws bedrock-agentcore start-browser-sessionを実行し、サンドボックスブラウザを起動。人間が一度だけログイン操作を行い、そのセッションをプロファイルとして保存します。以降、エージェントが起動する際には--profile-configurationオプションでそのプロファイルを指定するだけで、ログイン済みの状態からタスクを開始できるのです。この「人間が一度だけ認証し、あとはAIに任せる」というワークフローは、運用の現場において極めて現実的かつ強力なアプローチです。我々エンジニアがこれまで手作業で積み上げてきた「ログインの儀式」を、AIエージェントのワークフローにシームレスに統合できるようになったことは、自動化の適用範囲を劇的に広げるブレイクスルーと言えるでしょう。

ブラウザプロファイルが用意できたとしても、それをどうエージェントに組み込むかが次の課題です。ここで重要になるのは、CDP（Chrome DevTools Protocol）ベースの自動化と、OSレベルの操作をどう使い分けるかという設計思想です。Playwrightを用いたDOM操作は、Webページの構造が安定している場合には極めて高速かつ正確に動作しますが、複雑なUIや動的な要素に対しては脆さを露呈します。一方で、OSアクションによるマウス・キーボード操作は、より人間的な操作を模倣できるため、CDPが届かない領域を補完する「最後の砦」となります。この二刀流こそが、実務で使えるAIエージェントを構築するための必須条件です。

実装においては、環境変数の管理が運用の鍵を握ります。BROWSER_PROFILE_IDやARTIFACT_BUCKETといった設定をソースコードにハードコードするのは、スパゲッティコードへの第一歩です。これらをRuntimeの環境変数として注入し、IaC（Infrastructure as Code）で管理するリソースと、動的に生成されるセッションを明確に分離する設計が求められます。特に、CDKを用いたブラウザ環境の定義では、recordingConfigを有効にすることで、エージェントがどのような操作を行ったかを後から検証可能な状態にすることが重要です。これは単なるデバッグのためではなく、AIが「なぜその操作を行ったのか」という監査ログを残すためにも不可欠なプロセスです。

以下に、AgentCore Browserを運用する上での主要な設定項目と役割を整理しました。

このように、技術スタックを適切に組み合わせることで、AIエージェントは単なる「チャットボット」から、ブラウザというGUIを介して業務を完遂する「デジタルワーカー」へと進化します。しかし、ここで我々が直面するのは「AIが誤った操作をした際のリカバリ」という新たな課題です。ログイン状態を維持するということは、AIが誤操作によって重要なデータを削除したり、意図しない設定変更を行ったりするリスクも同時に抱えることを意味します。この技術を導入する際、我々は「AIにどこまで権限を与えるか」というガバナンスの設計を、コードを書くこと以上に深く考えなければなりません。

AgentCore Browserの登場により、これまで「APIがないから」という理由で諦めていた自動化の壁は、物理的に破壊されました。しかし、技術的に可能になったからといって、すべてを自動化すべきなのでしょうか。我々エンジニアは、AIエージェントがブラウザを操作する環境を構築する際、常に「この操作は本当に自動化すべきか」という問いを自分自身に投げかける必要があります。ログイン情報をプロファイルとして保存し、AIに委ねることは、利便性と引き換えに「認証の境界線」を曖昧にする行為です。もしAIが乗っ取られたら、あるいはAIの推論が暴走したら、そのブラウザプロファイルは攻撃者にとっての特等席になりかねません。

明日から我々が取るべき実践的な対策は、まず「最小権限の原則」をブラウザプロファイルにも適用することです。特定の業務にしか使わないプロファイルを作成し、そのプロファイルでアクセスできる範囲を厳格に制限する。そして、AIの操作ログをS3に蓄積し、異常な操作パターンを検知する仕組みを構築することです。技術コミュニティに身を置く者として、新しいツールを試す熱量は大切ですが、それ以上に「自動化されたシステムが壊れたとき、誰が責任を持って復旧させるのか」という運用設計の責任を忘れてはなりません。

最後に、読者であるあなたに問いかけます。AIエージェントがブラウザを操作し、人間が介在せずに業務が完結する世界において、エンジニアの価値はどこにシフトするのでしょうか。単に「動くコードを書く」ことの価値は、AIによって急速にコモディティ化しています。我々が真に注力すべきは、AIが操作する「ブラウザの向こう側」にある業務プロセスそのものを再定義し、AIが安全かつ効率的に働ける環境を設計する「アーキテクト」としての視点ではないでしょうか。ツールを使いこなすのは当たり前。その先で、あなたはどのような自動化の未来を描き、どのようなリスクを許容するのか。その答えを出すのは、他でもないあなた自身です。