Workflow Useの「決定的・自己修復」RPAを一次資料で読み解く
何を「決定的」と呼ぶのかの前提
Workflow Useはブラウザ操作を記録し、決定的な手順として再実行する仕組みを標榜している。 出典の記述では、手順が失敗したときにBrowser Useへフォールバックし、自己修復的に続行するとされる。 資料は開発初期で本番利用を勧めないと明言しており、リリース計画も未定だとされる。 ここで言う決定性は、同じ入力で同じ結果に収束させる運用上の性質を指していると読める。
一方で、Browser UseはLLMがDOMとやり取りしながら操作を組み立てる方式であり、モデル出力の揺らぎが介在しやすい。 そこでWorkflow Useは、一度の実行履歴からパラメータ化した「セマンティックなワークフロー」を生成し、次回以降はAI推論なしで流せる経路を用意すると説明している。 ただし、失敗時にAIへ戻る設計が残る限り、全体の実行は常に完全決定的とは限らない。 この非決定的分岐がどの程度起きるかは、手順設計と対象サイトの変化率に依存する。
出典の主張を突き合わせる
Hacker Newsに掲載の説明は、自然言語からの自動生成モード、保存されたワークフローの再実行、--promptでの入力差し替えなどを示している。
workflows/storage/配下にmetadata.jsonとworkflows/<id>.workflow.jsonを置く保存形式も記され、workflow-infoやdelete-workflowなどのCLIが列挙されている。
プログラムからはHealingServiceをChatOpenAI(model='gpt-4.1')と組み合わせて使う例が示され、フォールバックの実装位置が推測できる。
さらに、モデル指定やクラウドブラウザ利用、データベース保存の有無を切り替えるオプションも提示されている。
他方、Browser Useのリポジトリはクラウド、CLI、Pythonライブラリの三経路を案内している。 クラウド経路ではホスト型のエージェントやプロフィール管理が示され、新規サインアップに15ドル分のクレジットが付くと資料は述べている。 この記載は2026年9月12日に確認した内容であり、将来の変更可能性は残る。 CLIはエージェントにプロンプトを貼り付けてセットアップさせる方式、ライブラリはPythonからローカルまたはクラウドのブラウザを選ぶ方式として説明されている。
PyPIの記載では、Browser Useは「AIエージェントにブラウザを使わせる」ことを目的に掲げ、uv add browser-useやpip install browser-useの導入手順が示されている。
環境変数はBROWSER_USE_API_KEYのほか、GOOGLE_API_KEYやANTHROPIC_API_KEYも例示されている。
一方でGitHub側のサンプルは.envにOPENAI_API_KEYを置く例が前面に出ており、鍵の扱いの記載に差があることがわかる。
また、PyPIのバージョンは2026年9月12日時点で0.13.10と記されている。
対照的に、Playwrightの公式資料はテスト用途の決定的実行を前提に機能が整理されている。 自動待機や役割ベースのロケータ、並列実行によりフレークを抑える設計が明言される。 さらに、AIエージェント向けにはアクセシビリティスナップショットやMCPサーバが用意され、視覚モデルに頼らない一貫したページ理解をうたう。 これは生成AIの出力揺らぎを介在させない設計思想として位置付く。
食い違いが日々の運用に及ぼす影響
Workflow Useは成功パスでは決定的に流し、失敗時のみAIに委ねる二層構造を採る。 この構造は、正常時の再現性と異常時の回復力を両立しやすい一方、障害頻度が高い環境では非決定的経路が常態化しうる。 結果として、リトライで通る作業と、恒常的に修正すべき手順の切り分けが運用の主要作業になる。 監視と通知を用意しないと、成功に見えるが中身は回復で通したという事実を見落としやすい。
保存形式がローカルのworkflows/storage/である点は、可搬性と監査に影響する。
ローカルファイルであればバージョン管理に載せやすいが、機微情報を含む入力や出力の扱いは設計段階で分離する必要がある。
共有環境での同時編集や承認フローを求める場合、外部のストレージやレビュー手順を組み合わせる運用が前提になる。
ファイル粒度が<id>.workflow.jsonで固定されるなら、差分の可読性を高める命名や分割規則をチームで定義する方が安全だ。
モデル指定が可能という設計は柔軟性を増すが、推論コストとレート制限の影響を受けやすい。 失敗時のフォールバックが頻発する想定なら、請求額と待ち時間のばらつきが大きくなる。 とりわけ2026年9月12日時点での資料には価格体系の詳細が見当たらないため、検証環境での計測と上限値の設定を先に置くのが現実的だ。 同時に、モデルの差し替えで品質が変動する可能性があるため、ワークフロー自体の回帰評価指標を用意しておく必要がある。
テストと運用の境界では、Playwrightのように非AIで閉じた決定的実行が向く場面が残る。 UIが頻繁に変わらず、役割ベースのロケータで十分に要素を捉えられる業務は、まずテストランナーで固めた方が再現性を維持しやすい。 対して、入力の多様性やサイトごとの差異が避けられない収集系の業務は、失敗時の回復経路を持つ利点が生きる。 両者を同列に比べるのではなく、要件の側から適材適所で選び分けるのが健全だ。
現時点での選択肢と留保付きの見立て
最初の導入は、小さな範囲でWorkflow Useの自動生成と再実行を確かめ、失敗頻度と復帰コストを計測する流れが現実的だ。 同じタスクをPlaywrightとBrowser Useで並行実装し、実行時間と成功率の系列を比較すれば、どの条件で分岐が発生するかが見えてくる。 そのうえで、保存先の設計と鍵の管理方式を固め、監査ログと通知の粒度を運用に合わせて決めると移行がしやすい。 なお、資料は本番利用を推奨していないため、検証から段階移行する判断は意図的に遅らせるべきだ。
最後に、鍵の指定方法やクレジット付与などの細部は資料間で表現が割れている箇所があった。 2026年9月12日に確認した記載の範囲で論じたが、将来の変更は避けられない。 本番向けの前提で読み替えず、一次資料の更新を起点に設計を見直すことが重要だ。 検証ログとワークフロー定義をセットで保管しておけば、変更の影響範囲を後から辿りやすい。