cloud

cloud skill の概要

cloud skill は何のためのものか

cloud skill は、ホスト型のブラウザ自動化プラットフォーム／API である Browser Use Cloud を使うための、ドキュメント起点の案内役です。クラウドサービス経由で Web サイトを自動化したい人、REST API や SDK を使いたい人、CDP で外部ブラウザツールを接続したい人、あるいは sessions・profiles・proxies・ライブ監視を前提にワークフローを設計したい人に特に向いています。

どんな人が cloud skill を入れるべきか

実際にやりたいことが次のどれかに当てはまるなら、cloud skill を入れる価値があります。

• 参照ファイルを全部読み込まずに Browser Use Cloud を素早く立ち上げたい
• v2 REST API、v3 agent API、SDK 利用、直接ブラウザ接続のどれを選ぶべきか判断したい
• Python、TypeScript、cURL、外部ツールからブラウザ操作を自動化したい
• Browser Automation 用途で、ホスト型インフラ上でブラウザ自動化を動かしたい
• sessions、永続 profiles、住宅系 proxies、CAPTCHA 対応、webhooks を扱いたい

逆に、オープンソースのローカル browser-use Python ライブラリの設定や構成を助けてほしいなら、この skill は適しません。この skill 自体が、cloud 利用とオープンソースの agent package を明確に分けています。

cloud skill が汎用プロンプトと違う点

汎用プロンプトでも、ブラウザ自動化を大まかに説明することはできます。ですが cloud skill は、Browser Use Cloud 固有の導線が必要なときに真価を発揮します。たとえば、どの API バージョンの資料を見るべきか、auth がどう動くか、liveUrl はどこから得るのか、cloud sessions と単発実行は何が違うのか、CDP アクセスはどう始めるのか、どの統合パターンが自分のスタックに合うのか、といった点です。

最大の価値は、隠し機能ではなく「適切な資料への案内」と「向き不向きの見極め」です。必要な参照ファイルへ素早くたどり着けます。

• 初期セットアップと料金確認なら references/quickstart.md
• 安定した REST エンドポイントを見るなら references/api-v2.md
• 新しい session ベースの agent API なら references/api-v3.md
• Playwright、Puppeteer、Selenium、raw CDP を使うなら references/browser-api.md
• session / profile 設計なら references/sessions.md
• proxies、webhooks、workspaces、skills、MCP、live view なら references/features.md
• 並列実行、streaming、geo-scraping、structured output なら references/patterns.md

Browser Automation 向け cloud の適した用途

この cloud skill は、ローカルのブラウザ制御ではなく、Browser Automation 向けの cloud を使いたい場面で特に有効です。よくある適合例は次のとおりです。

• stealth や proxies の恩恵を受けたい scraping / extraction
• 永続的なブラウザ profile が必要な認証付きワークフロー
• liveUrl で状況を見ながら進めたいリモートブラウザ session
• ホスト型 CDP 経由で Playwright、Puppeteer、Selenium を直接使う構成
• agent システム、chat UI、ノーコードツール、webhook 駆動のバックエンドとの統合

先に確認したい主な導入の判断ポイント

導入判断は、たいてい次の実務的な問いに集約されます。

• 必要なのはホスト型 cloud automation か、それともローカルのオープンソース制御か
• 欲しいのは安定した v2 REST endpoints か、それとも新しい v3 の session / message モデルか
• 必要なのはシンプルな run() タスクか、それとも明示的な session / profile 管理か
• 使うのは SDK、cURL、外部ブラウザフレームワークの CDP 接続のどれか
• 地理的ルーティング、認証の永続化、webhook callbacks が必要か

これらがまだ固まっていなくても、この skill は役立ちます。リポジトリが 1 本のチュートリアルではなく、「判断ルート」ごとに整理されているからです。

cloud skill の使い方

cloud skill をインストールする

通常の skills installer を使い、対象に cloud skill を指定します。

npx skills add https://github.com/browser-use/browser-use --skill cloud

インストール後は、ローカルのオープンソース package ではなく、Browser Use Cloud に関する質問のときに呼び出してください。

目的に合ったファイルから読む

ファイル順ではなく、判断軸で読み進めるのが基本です。

• プラットフォーム自体が初めて: references/quickstart.md
• 安定した API カバレッジと cURL 例が必要: references/api-v2.md
• 新しい agent / session モデルを使いたい: references/api-v3.md
• 既存のブラウザフレームワークからホスト型ブラウザに接続したい: references/browser-api.md
• 永続状態、認証、profile 戦略が必要: references/sessions.md
• proxies や webhooks などの上級機能が必要: references/features.md
• 実装パターンを見たい: references/patterns.md

これは重要です。cloud skill は製品の複雑さを隠すものではなく、最短で役立つ読み順を選ぶための補助だからです。

まず cloud の主要な 4 つの利用パスを把握する

プロンプトを書く前に、次のどれを求めているのか決めてください。

1. SDK 経由の run() タスク実行
2. v2 REST API の task / session / browser endpoints
3. sessions・messages・workspaces を使う v3 agent API
4. Playwright、Puppeteer、Selenium 向けの直接 CDP ブラウザ接続

「Browser Use Cloud の使い方を教えて」とだけ書いた弱いプロンプトが失敗しやすいのは、この利用パスが明示されていないからです。

認証を正しく設定する

Browser Use Cloud では X-Browser-Use-API-Key ヘッダーを使い、SDK では通常 BROWSER_USE_API_KEY を環境変数から読み取ります。

export BROWSER_USE_API_KEY=your-key

参照資料から押さえておきたい実務情報:

• v2 の API base: https://api.browser-use.com/api/v2
• v3 の API base: https://api.browser-use.com/api/v3
• API key 作成画面: https://cloud.browser-use.com/new-api-key

プロンプトで auth の扱い方に触れていないと、回答が抽象的なまま終わりやすくなります。

例を求める前に SDK・REST・CDP のどれかを決める

最も簡単な開発体験を求めるなら SDK 例が向いています。
endpoint 単位で細かく制御したいなら REST が向いています。
すでにブラウザ自動化コードがあり、ホスト型ブラウザの接続先だけ欲しいなら CDP が向いています。

この違いで、返ってくる答えの中身は大きく変わります。

• SDK の回答は run()、sessions、profiles、structured output が中心
• REST の回答は endpoints、polling、schemas、headers が中心
• CDP の回答は WebSocket URL とブラウザツール統合が中心

あいまいな要件を、使える cloud 利用プロンプトに変える

弱いプロンプト:

Help me use Browser Use Cloud.

より良いプロンプト:

I want cloud usage guidance for Python. I need a hosted browser workflow that logs into a site, persists cookies across runs, uses a US proxy, and lets me monitor progress live. Show whether I should use run() with auto-created sessions or manual sessions with a profile, and point me to the exact repo files to read first.

これが良い理由:

• 使用言語が明示されている
• ワークフローの種類が明示されている
• session の永続性に触れている
• proxy 要件が入っている
• ライブ監視の必要性が入っている
• コード例だけでなく、読むべきファイル案内も求めている

入力に入れると cloud skill の出力品質が上がる情報

cloud skill でより実用的な回答を得るには、次の情報を含めてください。

• 言語: Python、TypeScript、cURL
• API モード: v2、v3、または未定
• 実行スタイル: 単発タスク、複数ステップの session、直接ブラウザ制御
• 状態要件: stateless か persistent profile か
• インフラ要件: proxy の国、custom proxy、timeout、画面サイズ
• 監視要件: liveUrl、streaming、webhooks
• 出力形式: 自由文か structured schema か
• 統合先: Playwright、Puppeteer、Selenium、chat UI、subagent、no-code tool

これらがないと、回答は正確でも、すぐ実装に移せるほど具体的にはなりにくいです。

sessions / profiles 設計に cloud skill を使う

cloud skill の実務上の大きな価値のひとつは、まずい session 設計を避けやすくなる点です。

参照資料から分かること:

• run() は通常 session を自動作成する
• 手動 session は複数ステップのワークフローに向いている
• profiles は sessions をまたいで cookies と local storage を保持する
• 同じ profile を使う concurrent sessions はスナップショットから開始され、互いの状態変更は見えない

最後の点は、ざっと読んだだけだと見落としやすく、認証付きの並列処理では特に重要です。

Browser Automation フレームワーク用途で cloud skill を使う

すでに Playwright、Puppeteer、Selenium を使っているなら、agent task よりも、cloud browser への直接接続が最適な場合があります。

リポジトリには次のような CDP エントリポイントが示されています。

wss://connect.browser-use.com?apiKey=YOUR_KEY&proxyCountryCode=us&timeout=30

ここは重要です。接続時にブラウザが自動起動し、切断時に自動停止するため、task を手動で作成・破棄する運用モデルとは考え方が変わります。

高度な cloud 機能の判断にも cloud skill を使う

この skill は、単なる構文ではなくプラットフォーム機能が導入判断に効くケースでも役立ちます。

• stealth のデフォルト設定
• 多くの国に対応した residential proxies
• custom proxies
• CAPTCHA 対応
• 署名検証付き webhooks
• ライブビューと共有リンク
• workspaces
• skills と marketplace support
• MCP 関連のプラットフォーム資料

こうした点は、Browser Use Cloud が本番要件に合うかどうかを左右します。

インストール後の最初のおすすめ手順

新規ユーザー向けの現実的な進め方は次の順番です。

1. references/quickstart.md を読む
2. SDK または cURL でごく簡単な最初のタスクを動かす
3. 本番のワークフローに手動 session が必要か判断する
4. 永続ログインや状態保持が必要な場合にだけ profiles を追加する
5. proxy や geography 設定は必要になった段階で追加する
6. 基本経路が動いてから structured output や webhooks を足す
7. 並列実行や streaming が必要なら references/patterns.md に進む

この順番なら、最初の成功前に設計を盛りすぎて混乱するのを防げます。

cloud skill FAQ

この cloud skill は単なるドキュメント案内ですか？ それとも挙動を変えますか？

基本的には参照先を振り分けるための skill です。価値は、agent やユーザーが Browser Use Cloud の正しいドキュメント経路を選び、誤った前提を減らして回答できることにあります。プラットフォームの SDK や API を置き換えるものではありません。

cloud skill は初心者向けですか？

はい。少なくとも Browser Use Cloud が初めての人には有用です。最初の入り口として最適なのは references/quickstart.md です。ただし、必要なのがシンプルな task 実行なのか、session 管理なのか、フレームワークレベルのブラウザ制御なのかは、あらかじめ切り分けておく必要があります。

どんなときに cloud skill を使わないほうがよいですか？

オープンソースの browser-use ローカルライブラリ内部、agent config、cloud ではない package のセットアップに関する質問には使わないでください。その用途は、明示的に open-source skill を使う前提になっています。

v2 と v3 はどちらを使うべきですか？

安定した REST API と広い endpoint カバレッジが欲しいなら v2 を使ってください。
sessions、messages、files、workspaces を中心にした新しい BU Agent API モデルを使いたいなら v3 が候補です。ただし、参照資料では experimental 扱いである点は受け入れる必要があります。

この cloud skill は一般的なブラウザフレームワークにも役立ちますか？

はい。リポジトリには references/browser-api.md があり、Playwright、Puppeteer、Selenium、およびホスト型ブラウザへの直接 CDP 接続を扱っています。

Browser Automation 用途では、普通のプロンプトより cloud skill のほうが良いですか？

Browser Use Cloud のタスクであれば、通常はそのとおりです。通常のプロンプトだと、auth headers、endpoint versions、liveUrl、profile の挙動、webhook signatures、接続時に自動起動する CDP モデルのようなプラットフォーム固有事項を取りこぼしがちです。

cloud skill は料金や運用上の制約もカバーしていますか？

はい。quickstart の参照には料金や FAQ が含まれており、ほかの参照では timeout、session の扱い、concurrency の注意点、機能ごとの制約なども確認できます。

cloud skill を改善する方法

説明だけでなく、判断を求める

cloud skill の出力を最も早く改善できるのは、説明ではなく「選んでほしい」と依頼することです。

• “Should I use v2, v3, or CDP?”
• “Should this be auto-session or manual session?”
• “Should I use a profile or keep it stateless?”

こう聞くと、広い要約ではなく実装判断に直結する案内が返ってきます。

具体的なタスクと環境を書く

より良い例:

I need cloud install and usage help for a TypeScript backend. The workflow logs into a dashboard weekly, downloads a file, and posts completion to my server. I need persistent auth, webhook notifications, and a recommendation between SDK and REST.

この書き方が有効なのは、言語、実行頻度、状態要件、完了通知の方法が見えるからです。

実行間で何を保持したいかを明示する

よくある失敗は、状態要件を曖昧にしたまま相談することです。login、cookies、local storage、保存済み credentials が重要なら、その点を明記し、references/sessions.md ベースの profile 方針を求めてください。

状態が不要なら、そのことも明言してください。そうすれば cloud skill は、より単純な単発実行を勧めやすくなります。

監視が必要か、callbacks が必要かを指定する

多くのユーザーは次のどちらかを気にしているのに、依頼文に書き忘れます。

• liveUrl で実行をライブ監視したい
• step updates を stream したい
• タスク完了時に webhook callbacks を受けたい

これらは実装パターンも読むべきファイルも変わります。

まず最小実行ルートを求める

改善の定石は次の流れです。

1. 最小の動作例を求める
2. 実際に動かす
3. その後で profiles、proxies、webhooks の足し方を聞く

この skill が最も強いのは、導入順序を整理するときです。最初から本番アーキテクチャ全体を一気に設計させると、強みが出にくくなります。

API バージョンの混同に注意する

弱い回答になりやすい典型例のひとつが、v2 と v3 の概念を 1 つの依頼で混ぜてしまうことです。比較したいなら比較として頼み、実装したいならどちらか 1 つのバージョンを指定してください。

良いプロンプト:

Compare Browser Use Cloud v2 vs v3 for a multi-step agent workflow, then recommend one and give only that version's starter example.

ファイル単位の読み順を聞く

リポジトリには十分な参照資料があるので、狙いを絞った読み順を聞くと時間を節約できます。たとえば次のように質問します。

• “Which file should I read first for webhook verification?”
• “Which reference covers CDP and Playwright setup?”
• “Which document explains concurrent sessions with the same profile?”

こうした聞き方をすると、cloud guide は汎用的な要約より実行に移しやすい案内になります。

明確な成功条件を置くと出力が良くなる

次のような依頼より:

Show me cloud usage.

こちらのほうが有効です:

Show me a cloud usage path that gets from API key to first successful task in under 10 minutes, then list the next file to read if I need structured output.

成功条件を入れると、答えが実務的な導入ルートに寄りやすくなります。

最初の回答の後は、やり直しではなく不足点を足していく

最初の返答を受けたら、足りない点を具体的に示して改善してください。

• auth handling が足りない
• polling example が足りない
• session cleanup が足りない
• proxy config が足りない
• structured output schema が足りない
• webhook verification が足りない
• Playwright connection details が足りない

最初から聞き直すより、このやり方のほうが 2 回目の案内品質は上がります。

価値の高い cloud 案内を得るベストな聞き方

cloud skill が最も力を発揮するのは、プロンプトに次の情報が入っているときです。

• 自分のスタック
• ブラウザ自動化の目的
• 状態を保持する必要があるか
• ホスト型ブラウザ制御と agent 実行のどちらを優先するか
• monitoring、streaming、webhooks が必要か
• geo-routing や stealth 制約を気にするか

この組み合わせがあると、cloud skill は適切な Browser Use Cloud の資料へ案内しやすくなり、そのまま実装に移せる助言を返せます。