AI

「入力がめんどくさい」を解消：Bedrock AgentCoreでフォーム入力を自動化

概要：この記事でわかること

このブログでは、AWS のエージェント運用プラットフォームである Amazon Bedrock AgentCore の Browser 機能を活用して、

  • 企業サイトを自動で巡回して必要な会社情報を集め、その結果を社内フォームや Slack モーダルの入力に流し込んでくれる エージェントの構成と挙動
  • 企業サイトだけでなく、採用サイトや IR 情報まで自律的に辿って情報を集める 人間らしい動きのイメージ
  • フォーム入力サポート以外にも「情報収集基盤」として応用できそうなユースケース と、社内 PoC としての始め方

をざっくり掴めるようにまとめています。

Amazon Bedrock AgentCore とは？

Amazon Bedrock AgentCore（AgentCore）は、生成 AI エージェントの構築と実行を支援する AWS のマネージドサービスです。AgentCore には、エージェントが安全に Web コンテンツにアクセスするための Browser 機能（セキュアなリモートブラウザ環境）が含まれています。これにより、開発者は複雑なブラウザインフラを自前で管理することなく、Web サイトを閲覧・操作する AI エージェントを容易に実装できます。

この記事のターゲット

  • 業務効率化を支援している情シスやエンジニアの方
  • 「スクレイピングまではやりたくないけれど、AI とブラウザ自動操作で何ができるか知りたい」方
  • Amazon Bedrock を使ったエージェント活用の具体的なイメージを持ちたい方

画面イメージ

  • エージェント起動時の画面イメージ（例：Slack コマンドや Web フォームの入力画面）
  • クローリング結果のサマリ表示（例：会社名・所在地・事業内容などがまとまった画面）
  • 収集した情報が入力した状態でフォームが開く

    • ※フォームが開いた時点で、会社名や住所などの情報がすでに入力された状態になっています。人間は内容を確認して登録ボタンを押すだけです。

背景：入力の「めんどくさい」を解消したい

きっかけは、営業さんとの雑談で出てきた「入力めんどくさいんだよね」という一言でした。
SFA（営業支援システム）や社内申請フォームへの入力業務は、どうしても後回しになりがちです。

「URL を入力するだけで、自動でコーポレートサイトから会社情報（概要・事業内容など）を収集・抽出し、社内フォームへ転記入力できたら便利ではないか？」

目指したのは、「フォームを開いた瞬間には、もう入力が終わっている」 体験です。人間は入力作業から解放され、内容の確認と承認（登録ボタンを押す）だけに集中できるようになります。

この仮説を検証するため、Web 情報収集エージェントによる自動入力システム のプロトタイプを作成しました。
Amazon Bedrock AgentCore の Browser 機能（セキュアなブラウザランタイム）を活用し、サイトを人間のように巡回して情報を集め、フォーム入力の下書きを作成してくれる仕組みです。

実際の挙動：URL を渡すと何が起きる？

今回作成したエージェントの面白いところは、単にトップページをスクレイピングするのではなく、「会社情報ページだけで完結しない場合に、自律的に他のページを探しに行く」 点です。

実際のログを見ると、以下のような人間らしい動きをしていることが分かります。

実例：株式会社クラウドネイティブのサイトを巡回した場合

実際に https://cloudnative.co.jp/ を渡した際のエージェントの動作ログです。

Iteration 1: トップページでの判断

エージェントはまずトップページにアクセスし、ページ内容を分析します。

思考: "現在のページはホームページで、会社名「株式会社クラウドネイティブ」が確認できます。
      しかし、代表者名、設立年、所在地、電話番号、メールアドレスなどの詳細な会社情報は
      まだ収集できていません。ページコンテンツには「会社情報」へのリンクが利用可能です。
      このリンクをクリックして、詳細な会社情報を取得しましょう。"

アクション: クリック → a[href="/company"]

エージェントは、トップページだけでは必要な情報が揃わないと判断し、自ら「会社情報」へのリンクをクリックして次のページへ移動します。

Iteration 2: 会社情報ページでの情報抽出

会社情報ページ（https://cloudnative.co.jp/company）に移動後、エージェントは以下の情報を発見・抽出しました。

思考: "会社情報ページから、会社の詳細情報を確認できました。以下の情報が見つかりました：
      - 会社名: 株式会社クラウドネイティブ
      - 設立: 2017年5月
      - 所在地: 〒106-0032 東京都港区六本木1-4-5アークヒルズサウスタワー 16F
      - 代表電話番号: ***-****-****
      - Eメール: info@cloudnative.co.jp
      - 資本金: 10,000,000円
      - 代表取締役社長: 齊藤 愼仁
      - 従業員数: 38名（2025年6月現在）
      - 事業内容: 情報システム部門へのコンサルティング、クラウドコンピューティングに関わる
        全てのコンサルティング、設計、開発、構築及びそれらに関わる代理店業務

      このページから必要な会社情報がほぼ揃っているため、extractInfoアクションを実行して
      情報を抽出します。"

アクション: 情報抽出

この時点で、会社名、代表者名、設立年、所在地、電話番号、メールアドレス、事業内容、従業員数など、必要な情報がほぼ揃いました。

Iteration 3: 完了判断

エージェントは、収集した情報を再確認し、必要な情報がすべて揃っていると判断して処理を終了します。

思考: "会社情報ページから必要な会社情報をすべて収集できました。収集対象の情報がすべて
      揃っているため、情報収集を完了します。"

アクション: 完了

実行時間: 約42秒（ブラウザセッション開始から終了まで）

エージェントの判断プロセスの特徴

この例から分かるように、エージェントは以下のような判断を自律的に行っています。

  1. 情報の不足を認識: トップページだけでは必要な情報が揃わないと判断
  2. 次のアクションを計画: 「会社情報」へのリンクをクリックすべきだと判断
  3. 情報の充足度を評価: 会社情報ページで必要な情報が揃ったと判断
  4. 適切なタイミングで終了: 無駄な探索をせず、情報が揃ったらすぐに完了

人間が「会社概要ページに全部載っていなさそうだから、会社情報ページを見ておくか」と考えるプロセスを、LLM がそのままなぞっているのが分かります。

補足：情報が不足している場合の探索動作

上記の例では、会社情報ページで必要な情報がすべて揃ったため、3回のイテレーションで完了しました。しかし、会社情報ページだけでは必要な情報が揃わない場合、エージェントは以下のように自律的に探索を続けます。

例えば、会社情報ページに「従業員数」や「事業内容」の詳細が記載されていない場合、エージェントは以下のような判断をします。

思考: "会社情報ページから基本的な情報は取得できましたが、従業員数や事業内容の詳細が
      見つかりません。ページコンテンツには「採用情報」や「IR情報」へのリンクが利用可能です。
      これらのページには従業員数や事業内容の詳細が記載されている可能性があります。
      まずは「採用情報」ページを確認してみましょう。"

アクション: クリック → a[href="/recruit"] または a[href="/careers"]

同様に、IR情報ページにも移動して情報を補完します。エージェントは、必要な情報が揃うまで、最大10回のイテレーションで複数のページを探索します。

このように、エージェントは固定のスクレイピングパターンではなく、その場その場で「次にどこを見るべきか」を判断しながら、必要な情報を集めていくという、人間に近い探索プロセスを実現しています。

実装について

システム構成図

処理フロー：

  1. Slack から Lambda にリクエスト送信
  2. Lambda が AgentCore Browser セッションを開始
  3. Playwright で AgentCore Browser に接続（WebSocket/CDP）
  4. エージェントループ開始（最大10回）：
    • Playwright でページコンテンツ取得
    • Bedrock (Claude) に送って次のアクションを判断
    • Playwright でブラウザ操作（クリック、遷移など）
    • 情報抽出して構造化データに保存
  5. 収集完了後、Lambda から Slack に結果返却

以下の内容は技術的な詳細になります。興味のある方はクリックして展開してご覧ください。

システム全体像と実装のポイント（クリックして展開）

システム全体像

システム構成：Lambda + Bedrock + AgentCore

今回のエージェントは、以下の AWS サービスを組み合わせた構成になっています。

  • AWS Lambda
    • エージェントの実行環境として使用。Slack からのリクエストを受けて、エージェントの処理を開始します。
  • Amazon Bedrock
    • Claude Haiku 4.5 モデルを使用して、エージェントの判断プロセスを実行します。
    • 各イテレーションで、現在のページ内容とこれまで収集した情報を LLM に送り、「次に何をするべきか」を判断させます。
    • LLM は JSON 形式でアクション（click, navigate, extractInfo, done）を返します。
  • Amazon Bedrock AgentCore
    • セキュアなブラウザランタイムを提供。AgentCore SDK (bedrock-agentcore) の BrowserClient を使用してブラウザセッションを管理します。
    • Playwright を介してブラウザに接続し、実際のページ遷移やクリック操作を実行します。

アーキテクチャの流れ

  1. Slack からの起動: ユーザーが /company-info [URL] コマンドを実行
  2. Lambda 関数の呼び出し: Slack からのリクエストを受けて Lambda 関数が起動
  3. AgentCore ブラウザセッションの開始: BrowserClient を使用してブラウザセッションを開始し、セッション ID を取得
  4. Playwright での接続: AgentCore が提供する WebSocket URL とヘッダーを使用して Playwright でブラウザに接続
  5. エージェントループの実行: 最大10回のイテレーションで以下を繰り返し
    • 現在のページのテキストとリンク情報を取得
    • Bedrock の LLM に送って次のアクションを判断
    • LLM の指示に従ってブラウザを操作（クリック、ページ遷移、情報抽出）
  6. 結果の返却: 収集した情報を Slack モーダルに返却

実装のポイント

1. ブラウザ操作の効率化

ブラウザ操作部分は、AgentCore の Browser 機能と Playwright を組み合わせて実装しています。
LLM に生の HTML を全て読ませるとトークン量が膨大になるため、以下のような工夫をしています。

  • テキストの軽量化: ページ内のスクリプトやスタイルを除去し、本文テキストと主要なリンク情報（テキストと URL）だけを抽出して LLM に渡す。これにより、1ページあたりのトークン数を大幅に削減しています。
  • 操作の簡略化: LLM は CSS セレクタや「会社情報」といったリンクテキストを指定するだけでクリックできるようにする。これにより、LLM が判断しやすい形式で情報を提供しています。

2. エージェントの動作ループ（OODA ループ）

エージェントは、以下のサイクルを繰り返しながら情報を収集します。

  1. Observe（観察）: 現在のページのテキストとリンクを取得。JavaScript の実行を待機し、動的なコンテンツも取得可能。
  2. Orient（判断）: これまで集めた情報と現在のページ内容を合わせて Bedrock の LLM に送り、「次に何をするべきか」を問う。システムプロンプトには、収集すべき情報のリストと優先順位が記載されています。
  3. Decide（決定）: LLM が JSON 形式でアクション（移動、抽出、終了など）を返す。レスポンスはパースして、実際の操作に変換します。
  4. Act（実行）: Playwright でブラウザを操作し、情報を保存する。クリック、ページ遷移、情報抽出のいずれかを実行します。

このサイクルを最大 10 回程度繰り返すことで、複数のページにまたがる情報を収集しています。

3. エラーハンドリングとガードレール

  • ステップ数の上限: 無限ループを防ぐため、最大10回のイテレーションで制限
  • タイムアウト処理: ページ読み込みやネットワーク待機にタイムアウトを設定し、長時間待機を防止
  • JSON パースのフォールバック: LLM が返す JSON が不完全な場合でも、コードブロックや JSON オブジェクトを抽出してパースを試みる

このように、Lambda + Bedrock + AgentCore の組み合わせにより、インフラ管理を最小限に抑えながら、柔軟で拡張性の高いエージェントシステムを構築できています。


情シス・セキュリティ分野での応用例

今回のプロトタイプは「会社概要」向けのプロンプトを使っていますが、プロンプト（欲しい情報のリスト）を変えるだけで、全く別の用途に転用可能 です。特に、情報システム部門やセキュリティ管理業務において、以下のような応用が考えられます。

1. SaaS 利用状況の可視化

管理画面や請求メールから、契約ライセンス数、アクティブユーザー数、月額コストなどの情報を定期的に抽出します。API が提供されていない SaaS でも、管理画面を人間のように巡回することでデータを集約できます。

2. 取引先セキュリティチェックの自動化

新規取引先のWebサイトを巡回し、「プライバシーマーク」や「ISMS 認証」の取得状況、プライバシーポリシーの有無、セキュリティに関する開示情報を自動チェックします。チェックシートの記入を一部自動化することで、担当者の負担を軽減できます。

3. 脆弱性情報の収集と監視

複数のセキュリティニュースサイトやベンダーのリリースノートを定期的に巡回し、自社で利用している特定の製品（OS、ミドルウェア、SaaSなど）に関する脆弱性情報だけを抽出・集約してSlackに通知します。

その他のビジネス活用

  • 競合調査: 「製品の価格プラン」「導入事例の社名」などをリストアップさせる。
  • 採用情報のモニタリング: 競合他社の採用ページを監視し、募集職種の変化を検知する。

同じエージェントの仕組みを使いながら、プロンプトを変更するだけで、様々な情報収集タスクに対応できるのが、このアプローチの強みです。

コスト感とパフォーマンス

実際に運用する上で気になるコストですが、今回のプロトタイプの実測値は以下のようになります。

実測コスト（Claude Haiku 4.5 使用時）

AWS Cost Explorer で確認した実際の請求データに基づくと、1社あたりの情報収集コストは以下の通りです：

  • Claude Haiku 4.5: 約 $0.1〜0.2/社（約15〜30円）
  • AgentCore Browser: 約 $0.004/社（約1円）
  • Lambda 実行料: 無料枠内のため $0

1社あたりの総コスト: 約 約15〜30円

なお、エージェントが迷子になって無限ループしないよう、ステップ数の上限（今回は 10 回）を設けるなどのガードレールは必須です。
今回のプロトタイプは検証用にざっくりと実装したものであり、プロンプトの最適化やトークン使用量の削減、エージェントループの効率化などのチューニングにより、さらにコストを抑えられる可能性があります。

おわりに

今回は、「入力がめんどくさい」という課題に対し、Amazon Bedrock とブラウザ操作を組み合わせたエージェントで解決を図る事例をご紹介しました。

単なるスクレイピングツールとの最大の違いは、「サイトの構造がわからなくても、人間のようにメニューを探して情報を補完できる」 点にあります。
この仕組みは、フォーム入力支援だけでなく、情報の自動収集・監視基盤としても広い応用可能性を秘めています。

まずは「この入力作業、AI にやらせたらどうなるだろう？」という身近な業務から、社内 PoC を始めてみてはいかがでしょうか。

keiji

開発チーム所属。おっさんエンジニア。人間というレガシーシステムを運用中。次のアップデート（AI）に対応できません。

記事一覧