ブラウザ操作AIに定型リサーチを任せるワークフロー設計｜指示範囲・確認ポイント・止めどきの決め方

競合サイトの巡回リサーチ、まだ自分の目でクリックして回っていませんか。

実は、この作業に時間を溶かしている担当者は少なくありません。

私はブラウザを操作できるAIに、この巡回作業をそのまま渡しています。渡した瞬間に工数はほぼゼロになりました。

ただし、渡し方を間違えた最初の数日は、意味のない差分レポートを量産しただけでした。想定していなかったポップアップを次々にクリックして通過し、実在しないキャンペーン情報まで「変化あり」として報告してきたこともあります。

指示の粒度と、途中で人に戻す境界線の設計を間違えると、ブラウザ操作AIは「速いだけの誤情報製造機」になります。

この記事では、私が実際に運用している「定型リサーチをブラウザ操作AIに任せる」ワークフローを、工程ごとに分解して置いていきます。

どこまで指示するか。どこで人の目に戻すか。どこで完全に止めるか。

この3つの境界線の引き方が、この記事の核です。

「ブラウザを歩き回るAI」に何を任せるか

まず対象にする業務を決めます。

今回扱うのは「複数の競合サイトを毎週巡回し、価格・キャンペーン・新機能などの変化を拾って、チームに共有する」という、EC事業やSaaS運営でよくある定型リサーチです。

この業務を、実際に手を動かしている工程まで分解すると、だいたい次のようになります。所要時間は体感の目安です。

• 監視対象の選定・優先順位付け(週次見直し・約5分)詰まり所: 対象が増え続けて棚卸しされないまま放置される

• 各サイトへの巡回とスクリーンショット取得(約40分)詰まり所: ログインが必要なページで毎回止まる

• 取得データの文字起こし・整形(約15分)詰まり所: レイアウトが崩れて重要な数字を読み落とす

• 前回データとの突き合わせ(約10分)詰まり所: デザイン変更を「価格変更」と誤検知する

• 差分の重要度判定(約15分)詰まり所: セールなのか正式な値上げなのか、その場では判断できない

• 例外画面の確認(ログイン要求・CAPTCHA・404など・約10分)詰まり所: 気づかず放置され、翌週も同じ場所で止まる

• 記録・レポート化(約10分)詰まり所: フォーマットが担当者ごとにバラバラで比較できない

• チームへの共有(約5分)

• 対応判断(約20分)詰まり所: 判断基準が属人化していて再現できない

• 監視対象リストの更新(約5分)

合計するとおよそ135分。週1回のはずが、対象が増えるたびにこの時間はじわじわ伸びていきます。

この10工程を、AI化の優先度で3段階に分けます。

即着手でよい工程はこちらです。

• 巡回とスクリーンショット取得

• 文字起こし・整形

• 前回データとの突き合わせ

• 記録・レポート化

理由は単純で、手順が毎回ほぼ同じで、判断らしい判断が入らないからです。

中期で設計を詰めてから渡す工程はこちらです。

• 差分の重要度判定(人の承認を挟む前提で部分的に)

• 例外画面のハンドリング(止める条件を先にリストにしてから)

そしてAI不要、人が持ち続ける工程がこちらです。

• 監視対象の選定・優先順位付け(事業判断そのもの)

• 対応判断(数字だけでは決まらない)

• 監視対象リストの最終承認

「全部AIに渡せば速い」と考えたくなりますが、この3段階の線引きを最初にやらないと、後で痛い目を見ます。

任せてよい業務・任せてはいけない業務

工程の分解だけでなく、そもそも「どのリサーチ業務ならブラウザ操作AIに渡せるか」を先に線引きしておくと、後の設計が速くなります。

任せてよい業務の例です。

• 競合ECサイトの価格・在庫表示の巡回

• 求人媒体に掲載された同業種の募集条件・給与レンジの収集

• SNS上の自社名・商品名のメンションの巡回

• 展示会・イベントの出展社一覧の収集

• 業界メディアのプレスリリース一覧の巡回

• 比較サイトのランキング順位の定点観測

• 競合の採用ページに掲載された募集職種の変化の確認

• 口コミサイトの新着レビューの収集

• 競合のキャンペーンバナー・LPのスクリーンショット取得

• 特定キーワードでの検索結果上位表示の定点観測

• 公開されている決算資料・IR情報のリンク先収集

これらに共通するのは、公開情報を「見て記録するだけ」で完結し、取引や個人情報が絡まないという点です。

任せてはいけない業務の例です。

• ログインが必要な会員限定ページへのアクセス

• 個人情報を含むフォームへの入力

• 購入・申込・退会などの取引操作

• 競合への問い合わせフォーム送信

• 有料会員限定コンテンツの閲覧(利用規約違反のおそれ)

• パスワードや認証情報を要求される操作

• 短時間に同一サイトへ繰り返しアクセスする高頻度巡回(相手サーバーへの負荷)

• SNSでのフォロー・いいね・コメントなどの能動的な行動

• スクレイピング規約で明確に禁止されているサイトへのアクセス

• 個人が特定できる情報(氏名・住所・電話番号)の収集を伴う調査

• 採用候補者の個人SNSを深掘りする調査

判断基準はシンプルです。「取引を伴うか」「個人情報が絡むか」「相手システムへの負荷が高いか」「規約で明示的に禁止されているか」のいずれかに触れる業務は、AIに渡さず人が持ちます。

なぜ「巡回さえ自動化すれば楽になる」わけではないのか

最初にやってしまいがちな設計ミスがあります。

「AIに巡回だけ任せて、差分チェックと重要度判定は自分でやる」という分担です。

これだと、巡回にかかっていた40分は消えても、差分確認と判定にかかっていた25分はそのまま残ります。工数全体で見ると3割程度しか減りません。

私が組んでいる全体フローは、こうなっています。

[監視対象リスト]
→ [ブラウザ操作AI: 巡回・スクショ取得・テキスト抽出]
→ [Claude: 前回データとの差分要約]
→ [差分ありなら: 該当ページだけ再訪して深掘り]
→ [Claude: 重要度スコアリング＋レポート化]
→ [人: 週次で確認し、対応を判断]

この流れには、3つの設計判断があります。

1つ目は、「巡回」と「差分要約」を別工程に分けたことです。

巡回するAIと要約するAIの役割を分けておくと、どちらが間違えたかを後から切り分けられます。1つのAIに全部任せてしまうと、誤りの発生源が特定できなくなります。

2つ目は、全ページを毎回総なめにせず、差分検知を挟んだことです。

総なめだと、処理時間もコストも監視対象の数に比例して膨らみます。変化があったページだけ深掘りする設計にすれば、変化のないページは軽い処理で済みます。

3つ目は、最終判断を人に残したことです。

「価格が下がった」という事実と、「値下げの意図」は別物です。意図の読み取りには業界文脈や取引背景の知識が要り、これはブラウザ操作AIの仕事の範囲外に置いています。

ここから先は、この7つの工程それぞれについて、実際に使っているプロンプトの雛形と、どこで人に戻すかの境界線を具体的に置いていきます。

なお、ここで触れている業務自動化の全体設計は、Relmeaの教材に体系化しています。

ECの改善をAIチームで自作する教材「Relmea AI Ops Vol.3(自動化実装編)」

このアカウントのメンバーシップ「AI実装ラボ」では、過去の有料記事が読み放題になります。