この業務で起きている悩み
- 担当
- 営業企画・調査・バックオフィスの担当者
- 頻度
- 毎日または週次の決めた時刻
- 止まる場所
- 勤務時間外の実行管理と、途中で失敗した対象の切り分け
- 長い収集処理のために担当者のPCを起動したままにしている
- 複数の対象をどこまで処理したか把握しにくい
- 一部の失敗で全件をやり直している
Before / After
人が行う手順と、導入後に残す確認作業
以下は手順の比較です。所要時間や削減率は業務条件によって変わるため、数値効果は個別の条件で試算します。
Before
現在の手順
- 1対象URLと収集項目を一覧にする
- 2担当者のPCで順番にページを開く
- 3必要な項目をコピーして表へ貼り付ける
- 4途中で止まった対象を探してやり直す
- 5全件の完了と重複を確認する
After
Pigeon Workflow導入後
- 1定期実行でサーバー上のブラウザ処理を開始する
- 2Google スプレッドシートまたはPigeonCloudから処理済み識別子と状態を取得し、未処理分を特定する
- 3取得間隔を守りながら1件ずつ収集する
- 41件ごとに処理済み識別子と状態をGoogle スプレッドシートまたはPigeonCloudへ書き込む
- 5担当者は停止分・手動キューに加え、導入初期は成功分もサンプリングで確認する
Workflow
実装済みノードで組むワークフロー
決めた時刻に開始
定期実行
対象と前回の処理状態を取得
スプレッドシート取得
未処理分を特定
入力チェック
未処理が1件以上あれば進む
条件分岐
Webから収集
ブラウザ自動操作 RPA
識別子と状態を1件ずつ記録（またはPigeonCloud）
スプレッドシート書き込み
失敗を通知
Slack 送信
例外・確認の分岐
ブラウザ自動操作 RPA から分岐
- アクセス制限（429）を検知
- 指定時間だけ待機
- 上限回数内で再試行
上限到達または確認不能なら停止して通知（設計例・今回未検証）
ブラウザ自動操作 RPA から分岐
- ページ構造の変更を検知
- 取得処理を停止
- 対象URLとログを通知
設定を確認するまで再実行しない（設計例・今回未検証）
スプレッドシート書き込み から分岐
- 途中停止を検知
- 次回起動時に状態表を取得
- 処理済み識別子と照合
未処理分から続ける方法は個別に設計
再実行回数には上限を設けます。登録・送信を伴う処理は重複キーで反映状況を照合し、未反映の場合に限って再実行します。確認できない場合は停止して手動キューへ送ります。
Integrations
必要な連携
定期実行・Google スプレッドシート・PigeonCloud・Slack
決めた時刻の起動、対象一覧・処理済み識別子・状態の取得と1件ごとの記録、停止や手動確認対象の通知に使います。
取得元の公式API
公式APIへ接続できる場合は、その利用条件とレート制限に従ってREST APIを利用します。接続方法は個別に確認します。
Chromiumで操作するWeb画面
利用規約とrobots.txtを確認し、対象にできる場合にページ移動、データ抽出、ページ送りを行います。
Exception handling
例外時の挙動
01
アクセス制限
429などの制限を検知したら待機し、設定した上限回数まで再試行します。上限到達時は停止して通知します。
02
ページ構造の変更
想定した項目やページ送りを確認できなければ処理を停止し、対象URLとログを担当者へ通知します。
03
途中停止
次回起動時にGoogle スプレッドシートまたはPigeonCloudから処理済み識別子と状態を取得し、未処理分を判定します。再開の方法は個別に設計します。
Fit & design
適用条件と設計のポイント
- 01取得間隔とレート制限
- 利用規約と公式の制限に合わせて待機時間、同時実行数、再試行回数の上限を決めます。
- 02ページ送り
- 次ページの有無、最終ページの判定、同じページを巡回しないための識別方法をサンプルで確認します。
- 03状態台帳と再開方法
- 処理済み識別子と状態を1件ずつGoogle スプレッドシートまたはPigeonCloudへ書き込み、次回起動時に取得して未処理分を特定します。再開の方法は個別に設計します。今回の検証では1実行＝1対象で、完了した対象は次回の実行で再取得されないことを確認しました。
- 04取得してはいけない条件
- 利用規約やrobots.txtで禁止されている取得、権限のない情報、許可されていない高頻度アクセスは対象にしません。
Verification
検証した範囲と限界
- 実施日
- 2026-09-28
- 環境
- Pigeon Workflow 本番サービス上のデモ組織と、合成データ専用の検証テナント（PigeonCloud）で実施した社内検証。顧客の実運用実績ではありません
検証した構成
- 収集対象は自社サイトのブログ一覧23ページ（1ページ10件・最終ページ9件）。robots.txtで許可された自社ページのみを使用
- 状態台帳はPigeonCloudのテーブル（対象URL・状態・取得件数・収集結果）。定期実行のたびに「未処理」の先頭1件を取得し、「処理中」に更新してからブラウザRPAで一覧を表示、画面テキストをAIで「日付｜カテゴリ｜タイトル」に整形して「完了」に更新。ブラウザRPAは extract_mode=auto・vision 判定 ON・目標「ページを表示したら完了」の設定で、画面全文のテキストを後段に渡した（page_text 系モードでは画面テキストが3行に絞られ、auto＋vision OFF ではテキストが出力されず、いずれも構成が成立しなかった）
- 22:00〜23:50に10分おきの定期実行で12回起動。前後に手動実行で再開・失敗・空振りの経路を確認
確認できたこと
- 定期実行12回はすべて予定時刻の48〜50秒後に起動し、11回が完了（各98〜122秒）。11ページを未処理→完了に更新し、抜き取り4ページ39件は取得したHTMLと件数・順序が一致（36件は3項目とも一致、3件はカテゴリの大文字小文字だけが異なる）
- 完了した行は次の実行で再び取得されず、別の未処理行が処理された（状態台帳による再開）
- 存在しないページ（404）では記事が0件と判定され、状態を「失敗」に更新して担当者へメールを送信（受信側では迷惑メールフォルダに着信）
- 未処理が0件のときは、更新・RPA・通知を実行せずに終了
- 定期実行1回は基盤側のデータベースエラーで開始直後に失敗し、その回は処理されなかった（自動再試行なし・次回は正常に起動）
未検証
- ブラウザRPAのノード自体が失敗した場合の通知（この場合は後続の失敗更新と通知が実行されず、行は「処理中」のまま残ります。今回の失敗通知は、RPAが正常終了して内容が不合格だった場合のみ動作を確認）
- 「処理中」への更新は排他的なロックではないため、定期実行が重なった場合の同一行の二重取得（同時実行は未検証）
- アクセス制限（429など）の検知と待機、ページ構造の変更の検知（404で代替して確認）
- 23ページ全件の完走（12回分のみ実施）。AIによる整形結果の全ページ・全項目での正確性と誤りの自動検知（突合した4ページ39件のうち3項目一致は36件、別の1ページではカテゴリの取り違えが1件。業務で使う場合は元データとの照合が必要）
Price guide
料金目安
Light 月額50,000円
税抜・10ユーザー・25,000 AIクレジット・RPAノード
実行量、ブラウザRPAの利用範囲、連携要件によって必要なプランは異なります。適合確認後に個別にご案内します。
料金プランを見るFAQ
よくあるご質問
担当者のPCを起動しておく必要はありますか？
ブラウザRPAはサーバー上の実行基盤で動くため、実行中に担当者のPCを起動し続ける必要はありません。結果、停止分、手動キューは担当者が確認します。
途中で失敗すると最初からやり直しですか？
処理済み識別子と状態を1件ずつGoogle スプレッドシートまたはPigeonCloudへ記録し、次回起動時にその表を取得して未処理分を判定する構成にします。再開の方法は個別に設計します。RPAノード自体が失敗した場合は行が「処理中」のまま残るため、手動で「未処理」へ戻す運用が必要です（今回の検証で確認）。
どのWebサイトからでも収集できますか？
対象サイトの利用規約、robots.txt、アクセス制限、認証方法、画面構成を確認して個別に判断します。許可されていない取得は対象にしません。
どこまで検証済みですか？
本番サービス上のデモ組織と合成データ専用の検証テナントで、自社サイトのブログ一覧を対象に、状態台帳からの未処理取得、処理中→完了の更新、10分おきの定期実行12回（11回完了・1回は基盤側のデータベースエラーで未処理）、完了行を再取得しない再開、存在しないページでの失敗更新とメール通知、未処理0件での空振りを確認しました。ブラウザRPAのノード自体が失敗した場合の通知、同時実行、アクセス制限の検知、23ページ全件の完走、AI整形の全項目の正確性は未検証です。
More use cases