Amazon Bedrock AgentCoreでWebインサイト抽出を自動化する構成

ソリューションの概要

本記事は、AWSが公式ブログで公開した、Webサイトからインサイトを自動抽出するソリューションの解説です。対象ユーザーは、競合調査や市場分析を行う設計チームやプロダクトマネージャーです。手作業でサイトを巡回し、内容をコピーして整理する作業を自動化することを目的としています。

ソリューションの核となるのは、Amazon Bedrock AgentCoreのAgentCore Browserというマネージドブラウザサービスです。従来のルールベーススクレイパーはページ構造に依存していましたが、このサービスはJavaScriptを実行して完全にレンダリングしたページを取得できます。これにより、サイトのリニューアルやJSフロントエンドへの移行といった変更にも強いパイプラインを構築できます。

アーキテクチャの構成

全体はイベント駆動型で、コンテンツ収集とAI処理が分離されています。まずAmazon EventBridgeが15分ごとにLambdaを呼び出し、設定済みのRSSフィードをチェックします。新しい記事があれば、URLハッシュに基づいて重複を排除し、Amazon S3に保存します。

新しい記事に対しては、AgentCore Browserがリモートブラウザセッションを起動し、PlaywrightがCDP経由で操作します。このブラウザはJavaScriptをレンダリングし、動的要素の読み込みを待ってからスクリーンショットを撮影し、画像も取得します。HTML、スクリーンショット、メタデータなどの成果物はS3に構造化された形式で保存されます。

S3へのアップロードをトリガーにSQSへメッセージが送られ、別のLambdaがHTMLからテキストを抽出します。そのテキストはAmazon Bedrockに渡され、要約・テーマ・エンティティ・インサイトの抽出、そしてベクトル埋め込みの生成が行われます。結果はOpenSearch Serverlessにインデックスされ、キーワード検索とベクトル検索の両方が可能になります。

従来手法との違い

従来のルールベースのスクレイパーは、ページ構造に依存するため、サイトのリニューアルやJavaScript化によってサイレントに破損するリスクがありました。一方、AgentCore Browserはマネージドなブラウザサービスであり、JavaScriptを実行した後の完全なページを取得するため、こうした変化に対する耐性が高いと説明されています。さらに、WebSocket接続を介してPlaywrightから操作されるため、Lambda内でヘッドレスブラウザを動かす必要がなく、基盤管理の負担も軽減できます。

アーキテクチャの分離も重要なポイントです。収集Lambdaと処理Lambdaの間にSQSとデッドレターキューを挟むことで、処理失敗時の自動リトライが可能になります。また、ベクトル検索を使えば、キーワードが完全に一致しなくても、概念的に類似したコンテンツを検索できます。記事では、「what are emerging design trends」というクエリで、原文にその語句がなくても関連結果が返るとしています。

コストと注意点

一方で、コスト面には注意が必要です。AgentCore Browserのセッションは強力ですが、テストでは1回のPlaywrightレンダリングに10〜30秒かかり、通常のHTTPリクエストよりも大幅にコストがかかると報告されています。そのため、S3でURLハッシュにより重複を確認してからセッションを起動するなど、不要なレンダリングを避けることがコスト管理の鍵となります。

また、OpenSearch Serverlessは使用量に関わらず最小容量ユニットが必要なため、常時利用が前提です。トラフィックが少ない段階では、Amazon RDSとpgvectorを使って同様のベクトル検索を行う方が、低コストで始められる可能性があります。さらに、外部サイトのコンテンツを処理するため、Amazon Bedrock Guardrailsでコンテンツフィルタリングや、生成した要約がソースに基づいているかを検証するコンテキストグラウンディングを入れることを推奨しています。

まとめ

このソリューションは、競合情報収集、市場調査、コンテンツキュレーション、コンプライアンス監視などの用途に応用できます。ユーザーはAmazon Cognitoで認証してReact製のWeb UIからアクセスでき、さらにMCPサーバーを介して他のAIエージェントからも検索可能です。MCPはオープン標準であり、AIアシスタントが外部ツールを呼び出すための統一インターフェースを提供します。

実装コードはGitHubで公開されており、AWS CDKでデプロイできます。記事では、本番運用に入る前に、ガードレールの設定とコスト構造の理解が重要だと述べています。また、低頻度の利用ではOpenSearch Serverlessの最小容量コストを考慮し、代替ストレージを検討することが示されています。