Skyvern (YC S23) – ブラウザ自動化のためのオープンソースAIエージェント
(github.com/Skyvern-AI)- SkyvernはLLMとコンピュータビジョンでWebサイトベースの手作業ワークフローを自動化し、Playwright互換SDKとノーコードのワークフロービルダーをあわせて提供
- 従来のブラウザ自動化がDOM解析とXPathに依存し、レイアウト変更に弱かったのに対し、SkyvernはVision LLMで画面要素を理解し、必要な動作を計画・実行
- Skyvernは、初めて見るWebサイトでも視覚要素を動作にマッピングし、事前定義されたXPathやセレクタなしで同じワークフローを複数のWebサイトに適用できると説明
- SDKは
page.act、page.extract、page.validate、page.prompt、page.agentコマンドを提供し、既存のPlaywrightアクションに自然言語promptベースの要素探索を追加 - ローカル実行、Docker Compose、Skyvern Cloud、既存Chromeの制御、ブラウザトンネリング、WebBench 64.4%精度、AGPL-3.0ライセンス、およびマネージドクラウドのアンチボット機能の例外が提示されている
Skyvernが解決しようとしている問題
- Skyvernは、ブラウザベースのワークフローをLLMとコンピュータビジョンで自動化するプロジェクト
- Playwrightの上にAI機能を追加したPlaywright互換SDKを提供
- 技術ユーザーと非技術ユーザーのどちらでも、あらゆるWebサイトで手作業ワークフローを自動化できるようにノーコードのワークフロービルダーも提供
- 従来のブラウザ自動化は、Webサイトごとのカスタムスクリプト、DOM解析、XPathベースの相互作用に依存することが多く、Webサイトのレイアウトが変わると壊れやすかった
- Skyvernはコードで定義したXPath操作だけに頼らず、Vision LLMでWebサイトを学習し相互作用する
動作方式と設計
- Skyvernは、BabyAGIとAutoGPTが普及させたタスク駆動型の自律エージェント設計に着想を得ている
- これにPlaywrightのようなブラウザ自動化ライブラリでWebサイトと相互作用する機能を加えている
- Webサイトを理解し、行動を計画し、実行するために複数エージェントのスウォームを使う
- このアプローチの利点は3つに整理されている
- カスタムコードなしで視覚要素を必要な行動にマッピングでき、初見のWebサイトでも動作可能
- 探索時に探す事前定義のXPathやセレクタがないため、Webサイトのレイアウト変更により強い
- 1つのワークフローを複数のWebサイトに適用し、各サイトで必要な相互作用を推論できる
- Skyvern 2.0技術レポートはSkyvern 2.0: State-of-the-art web navigation with 85.8 on WebVoyager evalで確認できる
実行方法
- Skyvern Cloudは、インフラを自分で管理せずにSkyvernを実行できるマネージドクラウド版
- Skyvern Cloudは複数のSkyvernインスタンスを並列実行でき、アンチボット検知対策メカニズム、プロキシネットワーク、CAPTCHA solverを含む
- ローカル実行は
pip install "skyvern[all]"の後、skyvern quickstartで開始できる skyvern quickstartとskyvern run serverはデフォルトで~/.skyvern/data.dbのSQLiteデータベースを使用- ローカルPostgresコンテナを使うには
--postgresを渡す - 既存データベースを使うには
--database-stringを渡す - Docker ComposeはバンドルされたPostgresサービスを使用
- ローカルPostgresコンテナを使うには
- Docker Compose実行ではPostgres、API、UIをすべてコンテナ化し、
.envにLLM APIキーを設定したうえでdocker compose up -dで開始 - UIにはデフォルトで
http://localhost:8080からアクセスできる
SDKとAIベースのPlaywright拡張
- Skyvern SDKは、AIベースのブラウザ自動化をPlaywrightに追加する拡張
- インストール方法は利用形態によって分かれる
- Python SDK / cloud API:
pip install skyvern - ローカルサーバーとパッケージUI:
pip install "skyvern[all]"の後、skyvern quickstart - Postgresを使うローカルサーバーとUI:
pip install "skyvern[all]"の後、skyvern quickstart --postgres - 既存APIに接続するパッケージUI:
pip install "skyvern[ui]"の後、skyvern run ui --api-url <api-url> --api-key <api-key> - TypeScript:
npm install @skyvern/client
- Python SDK / cloud API:
- ページオブジェクトには4つのAIコマンドが追加される
page.act(prompt): 「ログインボタンをクリック」のような自然言語で動作を実行page.extract(prompt, schema): 任意のJSON schemaで構造化データを抽出page.validate(prompt): ページ状態を検証してboolを返すpage.prompt(prompt, schema): 任意の応答schemaとともにLLMへ任意のプロンプトを送信
page.agentはより高レベルのワークフローコマンドを提供page.agent.run_task(prompt): 複雑な多段階タスクを実行page.agent.login(credential_type, credential_id): Skyvern、Bitwarden、1Passwordに保存された認証情報で認証page.agent.download_files(prompt): ナビゲーション後にファイルをダウンロードpage.agent.run_workflow(workflow_id): あらかじめ作成したワークフローを実行
- 既存のPlaywrightアクションは、任意の
promptパラメータによりAIベースの要素探索をサポートpage.click("#btn")の代わりにpage.click(prompt="Click login button")page.fill("#email", "a@b.com")の代わりにpage.fill(prompt="Email field", value="a@b.com")page.select_option("#country", "US")の代わりにpage.select_option(prompt="Country dropdown", value="US")page.upload_file("#file", "doc.pdf")の代わりにpage.upload_file(prompt="Upload area", files="doc.pdf")
- 相互作用モードは3種類
- 従来のPlaywright: CSS/XPathセレクタを使用
- AIベース: 自然言語を使用
- AI fallback: まずセレクタを試し、失敗したらAIに切り替え
高度なブラウザ制御
- Skyvernはユーザーの既存のChromeブラウザを制御できる
- この方式では、既存のCookie、ログイン状態、拡張機能が入ったブラウザをそのまま利用する
- Chromeのリモートデバッグは
chrome://inspect/#remote-debuggingで有効化できる skyvern init browserコマンドはリモートデバッグページを開き、ユーザーが有効化するまで待ってから設定を保存できる- Skyvern Cloudもローカルマシンで実行中のChromeを制御できる
skyvern browser serve --tunnelコマンドは、Chromeの起動とSkyvern Cloudへのトンネル作成を一度に行う- すでにログイン済み、またはVPNの背後にあるサイトを自動化する際に有用
- ブラウザをトンネルで公開する際は、必ず
--api-keyを使う必要がある- APIキーなしで公開すると、URLを知っている誰でもブラウザを完全に制御できてしまう
- 関連内容はbrowser tunneling security docsにある
性能と評価
- SkyvernはWebBench benchmarkで64.4%の精度を記録し、SOTA性能を達成したと説明
- 技術レポートと評価はWeb Bench: A new way to compare AI browser agentsで確認できる
- WRITEタスクでも最も高性能なエージェントだと説明
- WRITEタスクの例はフォーム入力、ログイン、ファイルダウンロードなど
- このカテゴリは主にRPAに近いタスクで使われる
TasksとWorkflows
- TaskはSkyvern内部の基本構成単位
- 各Taskは、Webサイトをナビゲートして特定の目標を達成するよう求める単一リクエスト
- Taskには
urlとpromptが必要 - 任意で
data schemaとerror codesを含められるdata schemaは出力を特定のschemaに従わせたいときに使うerror codesは特定の状況でSkyvernの実行を停止させたいときに使う
- Workflowは複数のTaskをつなげて1つの作業単位にする方法
- ワークフロー例
- 1月1日以降のすべての請求書をダウンロードするには、請求書ページへ移動、日付で絞り込み、対象請求書リストを抽出し、各請求書をダウンロードする順序で構成できる
- EC購入の自動化は、商品へ移動、カート追加、カート状態の検証、チェックアウトの順序で構成できる
- 対応するワークフロー機能には、Browser Task、Browser Action、Data Extraction、Validation、For Loops、File parsing、Sending emails、Text Prompts、HTTP Request Block、Custom Code Block、block storageへのファイルアップロードが含まれる
- Conditionalsは「Coming soon」と表示されている
主な機能
- Livestreamingは、SkyvernがWeb上で何をしているかを確認できるよう、ブラウザviewportをローカルマシンへリアルタイム送信する
- デバッグ、挙動の理解、必要時の介入に役立つ
- Form Fillingは、Webサイトのform inputをデフォルトで入力できる
navigation_goalで情報を渡すと、Skyvernが内容を理解してフォームを埋める
- Data Extractionは、Webサイトからデータを抽出する
data_extraction_schemaをメインプロンプトにjsonc形式で指定すると、出力はそのschema構造に従う
- File Downloadingは、Webサイトからファイルをダウンロードする
- ダウンロードされたファイルは、block storageが設定されている場合、自動的にアップロードされUIからアクセス可能
- Authenticationは、ログイン後の作業自動化を容易にするため複数の認証方式をサポート
- 2FAサポートは複数方式で提供される
- QRベースの2FA、例: Google Authenticator、Authy
- メールベースの2FA
- SMSベースの2FA
- 関連文書は2FA supportにある
- パスワードマネージャー統合の状況
- 対応: Bitwarden
- 対応: Custom Credential Service、HTTP API
- 非対応: 1Password
- 非対応: LastPass
統合と対応LLM
- SkyvernはModel Context Protocol(MCP) をサポートしており、MCP対応のLLMを利用できる
- MCP文書はMCP server documentationにある
- Zapier、Make.com、N8Nとの統合をサポート
- 対応LLMプロバイダーは以下の通り
- OpenAI: GPT-5.5、GPT-5.4、GPT-5、GPT-4.1、o3、o4-mini
- Anthropic: Claude 4.7 Opus、Claude 4.6 Sonnet/Opus、Claude 4.5 Haiku/Sonnet/Opus
- Azure OpenAI: AzureサブスクリプションにデプロイされたすべてのGPTモデル
- AWS Bedrock: Claude 4.7、Claude 4.6 Sonnet/Opus、Claude 4.5 Sonnet/Opus
- Gemini: Gemini 3.1 Pro、Gemini 3 Flash、Gemini 2.5 Pro/Flash
- Ollama: Ollama経由のローカルホスティングモデル
- OpenRouter: OpenRouter経由のモデルアクセス
- OpenAI-compatible: liteLLMを通じた、OpenAI API形式に従うカスタムAPIエンドポイント
- 詳細なLLM設定はLLM Configuration docsにある
実際の利用例
- 複数のWebサイトでの請求書ダウンロード自動化
- 採用応募プロセスの自動化
- 製造会社の資材調達自動化
- 政府Webサイトでのアカウント登録やフォーム入力
- ランダムなcontact usフォームの入力
- 多言語の保険会社Webサイトで保険見積もりを検索
トラブルシューティングと運用コマンド
pip install skyvern==1.0.31の既知バグにより、(sqlite3.OperationalError) table organizations already existsが発生することがある- 残っているSQLiteファイル
~/.skyvern/data.dbを削除し、pip install --upgrade skyvernで1.0.32以降にアップグレードしてからskyvern quickstartを実行する - 1.0.31を維持する必要がある場合は
uv pip install skyvernを使える
- 残っているSQLiteファイル
pip install skyvernがResolutionImpossibleを出して失敗する場合、1.0.31のlitellm/fastmcp依存関係解決の衝突の可能性がある- 1.0.32以降へアップグレードするか、
uv pip install skyvernを使う
- 1.0.32以降へアップグレードするか、
- デバッグに有用なコマンド
skyvern run server: Skyvernサーバーを個別に実行skyvern run ui: Skyvern UIを実行skyvern status: サービス状態を確認skyvern stop all: 全サービスを停止skyvern stop ui: UIを停止skyvern stop server: サーバーを停止
ライセンスとテレメトリ
- Skyvernはデフォルトで利用統計を収集し、利用方法の理解に活用する
- テレメトリを無効にするには、
SKYVERN_TELEMETRY環境変数をfalseに設定する - Skyvernのオープンソースリポジトリはマネージドクラウドによって支援されている
- コアロジックはAGPL-3.0ライセンスでこのオープンソースリポジトリに提供される
- マネージドクラウド提供に含まれるアンチボット対策は、オープンソースリポジトリのコアロジックの例外として明記されている
1件のコメント
Hacker News のコメント
Anthropic が最近発表した Claude の computer use 機能をどう見ているのか気になる
Claude の
computer useが比較的新しく出た今、Skyvern の中核的な差別化ポイントが何なのか知りたい従来の方法はたいてい、操作可能な要素の周囲に表示されるバウンディングボックスを描き、LLM に
click('A12')のようなツール呼び出しを出させたうえで、A12 を実際の HTML 要素にマッピングして Selenium/JS の動作を実行する、というものだった。こうしたバウンディングボックスをヒューリスティックに描くのも難しく、クリックハンドラが別の DOM 要素に付いている場合、正しい動作を実行するのも難しくなり得る視覚要素を HTML 要素へ再マッピングせず、
click(x, y)やtype("foo")のような高レベルの操作を画面に直接行うほうが、自動化のユースケースではより効果的である可能性が高い。ただし現時点では、HTML をコンテキストとして LLM に提供すると、純粋な視覚推論だけを使う場合より性能が良くなる傾向もある。だから Claude の方式にはより楽観的で、特に視覚推論が改善し続けるなら非常に期待できるただ、競合が似たものを作らずにじっとしているかは疑問だ。xAI、Gemini、OpenAI、Mistral、MetaAI のチームが待っているだけとは思えないし、この分野は将来の大きな軸になる可能性が高いので、1社がすべてを取ることにはならなさそう
また、この種のシステムで実際の価値がどこから生まれるのかも重要だ。デモや使える格好いいプロダクトだけでは十分でない可能性が高く、多くの人が本当に求めているのは実際のワークフロー自動化だ。個人用途ならそれで十分かもしれないが、企業はもっと複雑なものを求める可能性が高い
最後に、これが Claude だけに最適化されるのかも重要な点だ。自前のオープンソース LLM で動かしたい、あるいは市場で最良のモデルを継続的に切り替えて使いたい場合、大手が提供するソリューションではその柔軟性を得にくいかもしれない。Anthropic には社内で Claude を使わせるインセンティブがあるからだ
この最後の点は希望が持てる。Skyvern のオープンソースユーザーは好きなモデルを選べ、Claude に縛られない。Gemini、GPT-4O、Llama 3.2 のようなオープンソースモデルでも実行できる
今週出た Playwright 上の最初の AI ラッパーでもないだろうし、今月初の事例でもなさそう
業務プロセス自動化という観点での活用は、テスト自動化より説得力があるように見える。テスト自動化はプロセスの正確さと再現性をはるかに重視するが、業務自動化では結果さえ合っていれば、変な経路でたどり着いても大きな問題にならないことが多い
ただ、例の動画では動かすためにかなり大きなプロンプトを書く必要があり、数 KB 程度のペイロードデータも CSV ではなくプレーンテキスト形式で入れる必要があった。これが、Playwright のコードジェネレーターを直接使うには技術的すぎて難しい人たちを置き換えることを期待しているのだとしたら、一方はできるがもう一方はできない人がそんなに多いのかは確信が持てない
さらに、ユーザーは Web サイトのログイン認証情報やクレジットカード情報までプレーンテキストで渡さなければならないように見える。ユーザーの Skyvern アカウントが侵害された場合に深刻な結果を避けるには、機密データの扱い方が非常に堅牢でなければならない
LLM ベースの Playwright ラッパーを作る側には、Web サイト刷新の頻度を誇張する傾向もあると思う。特に古いサイトや政府系サイトを対象にする場合がそうだ。たとえば、政府サイトとやり取りする長い Playwright ブラウザ自動化の束を何年も運用してきたが、保守したのは機関の業務手順が変わったときの1回だけだった。Skyvern を使っていたとしても、手順が変わったのだからプロンプトとペイロードも変更する必要があったはずだ
Playwright 自動化との違いは、各ステップの成功/失敗やデータ記録の正確性をアサーションで検証できるため、手順の更新が必要だと分かる点にある。Skyvern ではそのような選択肢が見えないので、手順変更を見逃し、誤ったデータを入力したりステップを飛ばし始めたりしないか心配だ
技術系ユーザーはさらに学んで自分でペイロードを作りたがり、非技術系ユーザーは LLM に最終的な Skyvern プロンプトの作成を手伝ってもらって始めている。予想外だったが、驚くほど自然な流れだった
ステップ1は複雑な方法で作ること、つまり Playwright であり、ステップ2は複雑なプロンプトで Playwright 相当のものを作る現在の段階、ステップ3はより単純なプロンプトで Playwright 相当のものを作ってくれるものを作る段階だ。各段階は、自動化を作るために必要な技術的ハードルを下げている
Web サイトの変更頻度は、LLM ベース自動化の価値提案としては小さいほうだと思う。最大の価値は、非常に動的な状況を扱える点にある。たとえば毎週ポップアップの提案が変わる EC サイトを自動化する場合、Skyvern はそうしたものをほとんど気にしないが、Playwright のスクリプトは壊れる可能性がある
Geico の例が気に入っている理由も、以前は自動化が非常に難しかった点をよく示しているからだ。フォームが実行するたびに変わるが、Skyvern は簡単に通過する
データ正確性の面では、複数のタスクをチェーンでつなぐ ワークフロー機能をリリース中だ。この機能で面白いのは、続行する前に Skyvern が自分で結果を検証するステップを追加できる点だ。たとえば n 個の商品をカートに入れたあとカートへ移動し、カートの状態を検証できる
予想どおり、これは他のエージェントがこうしたツールを使い、より単純なプロンプトでワークフローを自分で作れるようにするための土台になる。要するに、LLM によって業務プロセス自動化を徐々に簡単にしていく長い旅の最初の一歩だ
現時点でサードパーティのLLMの上にスタートアップを作るのは、本当に度胸があるか、短期収益を狙うビジネスモデルが必要に見える
時間軸が数か月ではなく数年ならリスクは大きい。Anthropicが昨日この分野に参入したし、OpenAIとGoogleも近いうちに追随する可能性が高い
彼らは文字どおりAWSと競合しながらも、AWSを使って自社プロダクトを提供している。この市場は大きく、さまざまなアプローチが入り込む余地がある
OpenAI、Anthropic、Googleがこの分野で大きな事業を作るのは明らかだが、他の誰かが良いアイデアを出し、大手インフラ提供者に依存してそれを実現することを排除する理由はなさそうだ
AGPLでオープンソース化している点が興味深い
ドキュメントにすでに答えがあるかもしれないが、ソースを軽く検索してみたところ、LangChainは使っておらず、将来的にそのコミュニティへ提供できるよう統合を計画しているように見えた。Skyvernで思考/行動チェーンのロジックを作るときに何を使ったのか、今ゼロから始めるならLangChain/Graph方面を検討するのかが気になる
その名残はタスクやステップのような箇所に多く残っているが、さらにスケールさせて複雑なことをやろうとすると、そのフレームワークが非常に制限的だと分かった
例えば現在は、SVGを解析したり動的オートコンプリートを埋めたりするマイクロエージェントが動くマルチエージェントアーキテクチャを使っているが、こうした構造は既存フレームワークでは本当に難しかったはずだ
LangChainのようなフレームワークは初期プロトタイピングには良いが、限界を押し広げたいときには制約が大きすぎる
「ブラウザ自動化」が分かりにくいなら、Selenium系のように対象Webサイトをプログラムに操作させるものだ
通常は、他人が所有する対象Webサイトにキー入力イベントやマウス移動/クリックイベントを送り込み、そのサイトに何らかの処理をさせる方式だ。これを知っておくと残りの説明が理解できる
こうしたLLMワークフロー自動化ツールを見るたびに、各ユースケースと長期的な結果についていくつか疑問が湧く
第一に、ツール間の相互運用性不足によって生じた摩擦を迂回しているのではないか、という点が気になる。例えばWebサイト所有者がRESTサービスを提供していれば、より効率的だったことなのか。こうしたツールが存在すると、サービスエンドポイントを提供するのが妥当な場合でも、企業は提供しなくなるのだろうか
第二に、セキュリティ上の理由などでサービスエンドポイントが存在しない正当な理由があるなら、自動化ワークフローがそのセキュリティ対策を迂回するために使われる可能性がある。悪意ある行為者が主要サービスを無効化するためにツールを使えるのか。ツールを作る側がそうした行為者になり得るのか。リセラーが需要の高い商品を一般消費者が買えないようにするために使えるのか
第三に、社内ツールやプロセスの先送りされたメンテナンスを迂回するために使われるなら、こうしたツールの存在が経営陣にメンテナンスをさらに先送りする口実を与え得る。最終的にはサポートスタッフのワークフローにおける中核的な依存関係になるかもしれない
第四に、Webサイト設計のアンチパターンを善意で迂回するために使われるなら、Webサイト所有者はそのワークフローを壊すインセンティブを持つのだろうか。結局は軍拡競争の一段階にすぎないのか
複雑なプロセスの上にソフトウェアを載せ、根本のプロセスを単純化する代わりに複雑性をもう一層追加して覆い隠す場面を見るたびに、こうしたことを考える。このプロジェクトが有用であることは明らかだが、長期的な影響が気になる
Skyvernはこの問題を解決するが、LLMのコストが下がれば、こうしたWebサイトがAPIを作る必要をなくしてしまう可能性もある
Skyvernがこうした行為を禁止しているWebサイトで使われることは望んでいない。LinkedInが代表例だ。特にアンチボットやCAPTCHA関連のコードをオープンソース化していない理由も、「Redditの推薦操作」のような依頼を受けるからだ。そうした悪意ある行為者を支援したくない
AIによるブラウザ自動化は、全体としては正味で良い効果があると見ている。APIの必要性が減れば、APIとUIの両方を保守する必要が減り、体験はよりシンプルになり、コードも減ってシステムもより単純になる
最後の部分については100%確信しているわけではない。通常、企業がAPIを作らない理由は予算がないからだと仮定している。つまり悪意ある理由ではないと見ている。LinkedInのような企業は自動化の試みを防ごうとするだろうが、そうしたいたちごっこには参加したくない
Skyvernが、構造の異なる複数のWebサイトからデータを収集し、1つのCSVやJSONファイルに構造化データとしてまとめられるのか気になる
例えば、複数の銀行サイトから預金口座の金利を取得し、各口座の銀行名、銀行ロゴ、商品名、金利を抽出して、保存済みクエリを毎日または毎週のようなスケジュールで実行できるのか
航空会社のWebサイトでSkyvernを動かした経験があるのか気になる
例えば、A地点からB地点までのマイル特典航空券の空席状況を抽出するようなケースだ。航空会社は常に画面を変え、スクレイピング対策も強いように見える
クレジットカード取引をベータテストし、信頼性を検証する形になる予定だ
もっと小規模に似たものを作っているが、この分野はかなり有望に見える
問題範囲を単一ページでのインタラクション/スクレイピングに限定したところ、会社では非常に安定して有用だった。ただ、エージェント式の自動化も面白そうだ
例えば、数百のWebサイトの問い合わせフォームに入力する作業は、通常のコードでその多様性に対応するのは本当に難しいが、AIエージェントにとっては大きな問題ではない
WebArena(https://webarena.dev)やVisualWebArena(https://jykoh.com/vwa)での数値があるのか気になる