Playwright on KnightLiブログ

CloakBrowserとは？PlaywrightとPuppeteerに、より実ユーザーに近いブラウザを使わせる

Tue, 19 May 2026 10:56:50 +0800

CloakHQ/CloakBrowser は、ブラウザ自動化向けのオープンソースプロジェクトです。単なる Playwright 設定や JavaScript パッチではなく、カスタム Chromium バイナリを中心に構成されており、ブラウザ指紋、WebGL、Canvas、音声、フォント、GPU、画面情報、WebRTC、ネットワークタイミングなどをより通常のブラウザ環境に近づけることを狙っています。

プロジェクトURL：https://github.com/CloakHQ/CloakBrowser

執筆時点では、GitHub API上で約1.5万 star、主要言語は Python、ライセンスは MIT でした。READMEでは、Playwright / Puppeteer の起動器を置き換えられる Stealth Chromium と説明されています。

何を解決するのか

通常の Headless Chromium で自動化スクリプトを動かすと、次のような自動化の痕跡が出やすくなります。

navigator.webdriver。
Headless UA の痕跡。
プラグイン、フォント、画面、GPU 指紋の不自然さ。
CDP の挙動と実ユーザー入力の違い。
一時 profile に通常の閲覧履歴がないこと。

CloakBrowser は、こうした一部の調整を実行時設定や JS patch だけでなく、Chromium のソースとバイナリ層に寄せています。Playwright ユーザーにとっては使い方が大きく変わらず、下層のブラウザだけをカスタムビルドに置き換える感覚です。

この種のツールは、適法な自動化テスト、サイト互換性検証、対策システムの自社テスト、Agent 用ブラウザ環境の実験に向いています。無許可アクセス、アカウント濫用、リスク制御の回避、利用規約違反のために使うべきではありません。

基本的な使い方

Python のインストール：

`1`	`pip install cloakbrowser`

JavaScript / Node.js のインストール：

`1`	`npm install cloakbrowser playwright-core`

README の Python 例は Playwright に近い形です。

from cloakbrowser import launch

browser = launch()
page = browser.new_page()
page.goto("https://protected-site.com")
browser.close()

JavaScript でも同じように使えます。

import { launch } from 'cloakbrowser';

const browser = await launch();
const page = await browser.newPage();
await page.goto('https://protected-site.com');
await browser.close();

Browser Profile Manager

CloakBrowser には Browser Profile Manager もあります。ブラウザ profile、テスト環境、繰り返し実行する自動化タスクを管理しやすくするためのものです。

`1`	`docker run -p 8080:8080 -v cloakprofiles:/data cloakhq/cloakbrowser-manager`

起動後は次を開きます。

`1`	`http://localhost:8080`

profile を管理できると、毎回使い捨ての一時 profile で動かす必要がなくなります。長期テスト、互換性確認、Agent 実験では、安定した profile のほうがデバッグしやすい場面があります。

通常の Playwright との違い

通常の Playwright は、安定したブラウザ制御に重点があります。CloakBrowser は、ブラウザ環境そのものをより自然に見せることに重点があります。

整理すると、Playwright は自動化API、CloakBrowser はカスタムブラウザ実行環境です。一般的なテストや自動化なら Playwright だけで十分な場面も多いですが、ブラウザ挙動や指紋の一貫性まで検証したい場合に CloakBrowser が候補になります。

ただし、すべての検知問題を解決する魔法ではありません。サイト側は行動、頻度、アカウント履歴、ネットワーク環境、業務ルールなども使ってリスクを判断します。

注意点

まず、コンプライアンスが重要です。より自然な自動化環境を使えることと、何でも自動化してよいことは別です。自動アクセスでは、権限、頻度制限、プラットフォーム規約を守る必要があります。

次に、カスタム Chromium に依存します。バージョン互換性、セキュリティ更新、バイナリの入手元を本番利用前に確認すべきです。

最後に、ブラウザ指紋は一部にすぎません。操作が不自然だったり、頻度が高すぎたり、アカウント運用が異常だったりすれば、リスクは残ります。

向いている人

CloakBrowser は、Playwright、Puppeteer、ブラウザAgent、QA自動化、Web互換性テストをすでに使っている開発者やチームに向いています。ノーコードの自動化ツールを探しているだけのユーザーにはやや技術寄りです。

まとめ

CloakBrowser の面白さは、ブラウザ自動化を「Headlessを操作する」だけでなく、「より実ユーザーに近いブラウザ環境を使う」方向へ進めている点です。テスト、Agent実験、管理された研究用途では注目に値します。ただし、実運用ではコンプライアンス、権限、リスク管理が前提です。

ai-goofish-monitor：AI で閒魚の商品を自動監視するオープンソースシステム

Sun, 17 May 2026 17:24:03 +0800

ai-goofish-monitor は、Usagi-org が公開している閒魚向けの商品監視システムです。

目的は明確です。閒魚での検索、絞り込み、商品分析、結果記録、通知を自動化し、大量の中古商品から条件に合うものをより早く見つけることです。プロジェクトは Playwright でページ操作を自動化し、画像入力に対応する AI モデルを接続して商品情報をさらに判断します。

プロジェクト：https://github.com/Usagi-org/ai-goofish-monitor

先に結論

ai-goofish-monitor は、単純なキーワード通知スクリプトというより、「閒魚の購入インテリジェンスダッシュボード」に近いです。

主な特徴は次の通りです。

タスク、アカウント、AI 判定基準、ログ、結果を管理できる Web 管理画面。
複数タスクの並行実行。各タスクでキーワード、価格、絞り込み条件、AI Prompt を設定できる。
Playwright で閒魚ページを取得し、ログイン状態やページ操作が必要な場面に対応しやすい。
キーワード一致だけでなく、AI で商品が条件に合うか判断する。
ntfy.sh、企業微信、Bark、Telegram、Webhook などの通知に対応する。
Cron 定期実行、複数アカウント管理、プロキシローテーション、失敗時リトライ、Docker デプロイに対応する。

特定の商品をよく閒魚で探す人、たとえば中古デジタル機器、カメラ機材、GPU、HDD、ゲーム機、楽器、家電、コレクション品を探す人に向いています。ただし「自動で掘り出し物を買うツール」ではありません。閒魚の検索結果は変化し、ログイン状態は失効することがあり、プラットフォームのリスク制御も自動化の安定性に影響します。人間の判断を置き換えるものではなく、補助的なフィルタリングツールとして使うべきです。

解決する問題

閒魚で中古商品を探すと、よく次の問題があります。

商品数が多すぎて手で見るのが疲れる。
タイトルや説明が不統一で、キーワードの取りこぼしや誤判定が起きやすい。
良い価格の出品は短時間で消える。
同じ商品でも地域、価格、状態、出品者が違う。
安い商品にはアクセサリ、故障品、再生品、誘導的なタイトルが混ざる。
複数キーワードを継続的に監視するのは手作業では続きにくい。

普通のキーワード通知で解決できるのは一部だけです。たとえば「ThinkPad X1」を検索すると、アクセサリ、壊れた画面、空箱、分解部品が混ざることがあります。「ソニー A7C」では、レンズセット、レンタル情報、釣りタイトル、異常価格に出会うこともあります。

ai-goofish-monitor の考え方は、まず自動化で候補商品を集め、それを AI に渡して条件に合うか再判断し、最後に注目すべき結果を通知する、というものです。

主な機能

README に列挙されている機能はかなりそろっています。

Web 可視化管理：タスク管理、アカウント管理、AI 基準編集、実行ログ、結果閲覧。
AI 駆動：自然言語でタスクを作成し、マルチモーダルモデルで商品を分析。
複数タスク並行：タスクごとにキーワード、価格、絞り込み条件、AI Prompt を個別設定。
高度な絞り込み：送料無料、新規出品時間範囲、省 / 市 / 区の地域フィルタ。
即時通知：ntfy.sh、企業微信、Bark、Telegram、Webhook など。
定期実行：Cron による周期タスク。
アカウントとプロキシのローテーション：複数アカウント、タスクへのアカウント紐付け、プロキシプール、失敗時リトライ。
Docker デプロイ：コンテナ化された運用。

これらを組み合わせることで、「監視タスク作成」から「命中通知」までの流れをカバーします。

ワークフロー

典型的な流れは次のようなものです。

サービスをデプロイして Web UI を開く。
閒魚アカウントのログイン状態をインポートする。
監視タスクを作成する。
キーワード、価格範囲、地域、新規出品範囲などを設定する。
判定基準を書く、または AI に生成させる。
タスクをリアルタイムまたは定期実行する。
Playwright がページを開き、商品情報を取得する。
AI がタイトル、説明、画像、Prompt をもとに条件適合を判断する。
命中結果を SQLite に保存する。
設定済みの通知チャネルで結果を送る。
Web UI で結果、ログ、価格履歴を見る。

この流れで AI の価値が最も大きいのは 8 番目です。「状態が良い、価格が妥当、アクセサリだけではない、修理品ではない、できれば同城で手渡し」などの自然言語条件を理解できるため、単純なキーワード規則より柔軟です。

Docker デプロイ

プロジェクトは Docker デプロイを推奨しています。

git clone https://github.com/Usagi-org/ai-goofish-monitor && cd ai-goofish-monitor
cp .env.example .env
vim .env
docker compose up -d
docker compose logs -f app
docker compose down

デフォルトの Web UI アドレス：

`1`	`http://127.0.0.1:8000`

公式イメージ：

`1`	`ghcr.io/usagi-org/ai-goofish:latest`

イメージ取得が遅い場合、README にはミラー例もあります。

1
2
3

docker pull ghcr.nju.edu.cn/usagi-org/ai-goofish:latest
docker tag ghcr.nju.edu.cn/usagi-org/ai-goofish:latest ghcr.io/usagi-org/ai-goofish:latest
docker compose up -d

Docker イメージには Chromium が含まれているため、ホスト側に別途ブラウザを入れる必要はありません。デフォルトの永続化ディレクトリは次の通りです。

data/：SQLite の主ストレージ。タスク、結果、価格履歴を保存。
state/：ログイン状態の cookie ファイル。
prompts/：タスク用プロンプト。
logs/：実行ログ。
images/：商品画像とタスク一時画像ディレクトリ。

.env の SERVER_PORT を変更した場合は、docker-compose.yaml のポートマッピングも合わせて変更します。

最小構成

最小構成は主に AI モデルと Web UI ログインに関するものです。

OPENAI_API_KEY=your_api_key
OPENAI_BASE_URL=your_openai_compatible_base_url
OPENAI_MODEL_NAME=your_multimodal_model
WEB_USERNAME=admin
WEB_PASSWORD=change_me

最初の 3 つは AI モデル接続に必須です。

OPENAI_API_KEY：モデル API Key。
OPENAI_BASE_URL：OpenAI 互換 API エンドポイント。
OPENAI_MODEL_NAME：画像入力に対応するモデル名。

WEB_USERNAME と WEB_PASSWORD は Web UI ログイン用です。README ではデフォルト認証情報が admin/admin123 とされていますが、本番環境では必ず変更してください。

初回利用

初回利用の流れはおおよそ次の通りです。

http://127.0.0.1:8000 を開く。
Web UI にログインする。
「閒魚アカウント管理」に入る。
プロジェクト付属の Chrome 拡張で閒魚ログイン状態 JSON をエクスポートする。
ログイン状態をシステムに貼り付ける。
ログイン状態ファイルは state/ に保存される。例：state/acc_1.json。
「タスク管理」に戻り、タスクを作成してアカウントを紐付ける。
タスクを実行し、結果を見る。

ここで最も重要なのはログイン状態です。閒魚は第三者が自由に取得できる標準 API を公開しているわけではないため、プロジェクトはブラウザのログイン状態を使って通常のページアクセスを模擬します。ログイン状態の失効、リスク制御、captcha、アカウント異常はいずれもタスク実行に影響します。

AI タスクとキーワードタスク

プロジェクトは 2 種類のタスク作成方式をサポートします。

1 つ目は AI判断 です。

「詳細な要件」を入力すると、システムが非同期に分析基準を生成します。複雑な条件に向いています。

本体のみ、アクセサリは不要。
市場価格より明らかに安い場合だけ通知。
状態が良く、説明に水没、修理、隠れた不具合がない。
同城優先、手渡しできるとなお良い。
画像にシリアル番号、箱、重要付属品が写っている。

2 つ目は 关键词判断 です。

これは従来のルール型監視に近く、キーワード、価格、地域などの条件で直接タスクを作成します。AI 生成を使いません。ルールが単純で、多少の誤検知を許容できる場面に向いています。

実際には併用できます。キーワードで初期フィルタし、AI で誤検知を減らす形です。

Web UI でできること

Web UI は、このプロジェクトが普通のスクリプトと違う重要な部分です。

タスク管理ページでは次を設定できます。

AI 作成タスク。
キーワード規則。
価格範囲。
新規出品範囲。
地域フィルタ。
アカウント紐付け。
定期実行ルール。

アカウント管理ページでは次ができます。

閒魚アカウントログイン状態のインポート。
ログイン状態の更新。
アカウント削除。
タスクへのアカウント指定。
システムによる自動アカウント選択。

結果とログページでは次ができます。

命中商品の確認。
結果のエクスポート。
履歴検索。
タスク実行過程の確認。
ログイン失効、リスク制御、AI 呼び出し問題の調査。

システム設定ページでは次ができます。

システム状態の確認。
Prompt の編集。
プロキシとローテーション設定の調整。

長期監視では Web UI が重要です。タスクが増えると、設定、ログ、結果、通知はすぐ管理しにくくなります。

データ保存

現在のオンライン主ストレージは SQLite で、デフォルトパスは次です。

`1`	`data/app.sqlite3`

Docker はデフォルトで SQLite の主 DB を次のようにマウントします。

`1`	`./data:/app/data`

アプリ起動時に DB とテーブルを自動作成し、古い config.json、jsonl/、price_history/ から一度だけ履歴データをインポートしようとします。

注意点として、state/、prompts/、logs/、images/ は引き続きファイルシステム上のディレクトリであり、SQLite 内には入りません。商品画像は次のようなディレクトリに一時保存されます。

`1`	`images/task_images_<task_name>/`

タスク終了後、デフォルトではクリーンアップされます。

この構成は個人または小規模チームに向いています。SQLite は軽量で移行しやすく、ファイルディレクトリにログイン状態、画像、ログが残るため調査もしやすいです。

通知チャネル

プロジェクトは複数の通知チャネルに対応します。よく使う設定は次の通りです。

NTFY_TOPIC_URL
GOTIFY_URL / GOTIFY_TOKEN
BARK_URL
WX_BOT_URL
TELEGRAM_BOT_TOKEN / TELEGRAM_CHAT_ID / TELEGRAM_API_BASE_URL
WEBHOOK_*

通知はこの種のツールの体験の中心です。監視システムが結果をバックエンドに書くだけなら、ユーザーは結局ページを何度も開く必要があります。プッシュ通知があれば、命中商品をすぐ受け取れます。

実用的には商品価値で通知を分けるとよいです。

普通のキーワード命中はバックエンドにだけ記録。
AI 高信頼度の結果はスマホへ通知。
高価値商品は企業微信または Telegram へ通知。
デバッグ中はログを増やし、安定後にノイズを減らす。

開発者向け実行

Docker を使わないローカル開発には次が必要です。

Python 3.10+
Node.js + npm
Playwright CLI
Chromium または Chrome / Edge ブラウザ

基本コマンド：

1
2
3

git clone https://github.com/Usagi-org/ai-goofish-monitor
cd ai-goofish-monitor
cp .env.example .env

ワンコマンド起動：

1
2

chmod +x start.sh
./start.sh

start.sh は Playwright CLI とブラウザ条件を確認し、依存関係のインストール、フロントエンドビルド、成果物コピー、バックエンド起動を行います。

バックエンドを手動起動：

`1`	`python -m src.app`

または：

`1`	`uvicorn src.app:app --host 0.0.0.0 --port 8000 --reload`

フロントエンド開発：

1
2
3

cd web-ui
npm install
npm run dev

テストとビルド：

1
2

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 pytest
cd web-ui && npm run build

向いている人

ai-goofish-monitor は次のようなユーザーに向いています。

閒魚で特定モデルをよく探す人。
中古デジタル機器、カメラ機材、ゲーム機、ハードウェア部品を監視したい人。
「キーワード検索 + 手動選別」を自動化したい人。
OpenAI 互換モデル API を持ち、AI 判定コストを受け入れられる人。
Docker または基本的なコマンドラインデプロイに慣れている人。
命中結果をスマホ、企業微信、Telegram に通知したい人。

あまり向いていないケース：

デプロイを全く知らず、すぐ使える App だけが欲しい。
ログイン状態、captcha、アカウントリスク制御を扱いたくない。
公式認可された強いコンプライアンスのデータ API が必要。
大規模かつ高頻度にプラットフォームデータを収集したい。
AI に取引リスクを自動判断させ、注文まで代行してほしい。

リスクと境界

この種のツールでは境界を意識する必要があります。

第一に、プラットフォーム規則を守ることです。

閒魚には独自の利用規約、リスク制御、アカウント安全機構があります。自動化アクセスは制限を引き起こす可能性があります。高頻度に取得したり、リスク制御を回避したり、出品者への迷惑行為、プライバシーの一括収集、プラットフォーム秩序の破壊に使ってはいけません。

第二に、アカウントのログイン状態を保護することです。

state/ に保存されるのはログイン状態 cookie ファイルです。これは実質的にアカウントアクセス資格情報です。Git リポジトリにコミットせず、信頼できないサーバーにも置かないでください。サーバーをインターネットに公開する場合、Web UI のデフォルトパスワードは必ず変更し、VPN、リバースプロキシ認証、または内部ネットワークの背後に置くべきです。

第三に、AI 判定は事実保証ではありません。

AI は誤検知を減らせますが、商品の真偽、出品者の信頼性、価格の妥当性、取引安全性を保証しません。最終的には商品詳細、出品者評価、チャット履歴、配送方法、支払いプロセスを人間が確認する必要があります。

第四に、コストに注意してください。

すべての候補商品をマルチモーダルモデルで分析すると、呼び出しコストはすぐ増えます。まずキーワード、価格、地域で強く絞り込み、少数の候補だけを AI に渡すのがよいです。

第五に、プライバシーに注意してください。

商品スクリーンショット、チャット関連内容、アカウント状態、通知内容には機密情報が含まれる可能性があります。通知 Webhook、ログディレクトリ、データベースは適切に保護してください。

普通のスクリプトとの違い

普通の閒魚監視スクリプトは、通常 3 つのことだけをします。

キーワードを検索する。
価格を判定する。
通知を送る。

ai-goofish-monitor はさらに進んでいます。

Web UI でタスクとアカウントを管理する。
AI Prompt で複雑な購入基準を表現する。
マルチモーダルモデルで商品画像と説明を見る。
SQLite に結果と価格履歴を保存する。
ログページでタスク失敗原因を調査する。
プロキシローテーションと複数アカウントで安定性を高める。
定期タスクで長期運用を支える。

機能が多いぶん、デプロイと運用コストも高くなります。一般ユーザーには Docker デプロイが最も簡単です。開発者にとっては、Web UI、FastAPI、Playwright、SQLite の構成が二次開発しやすい形です。

使い方の例

実用的には、小さなタスクから始めるのがよいです。

たとえば中古カメラを探すなら、次のようなタスクを作れます。

キーワード：A7C、索尼 A7C
価格範囲：市場価格に基づいて上限を設定
地域：同じ省または同じ市を優先
新規出品範囲：直近 1 日または数時間
AI 基準：レンズ単体を除外、修理品を除外、明らかなアクセサリを除外、シャッター数と状態に注目
通知：AI 判定を通過した結果だけ通知

安定して動くようになってから、タスク数を少しずつ増やします。最初から数十キーワード、複数アカウント、高頻度 Cron にしないでください。ログイン状態の安定性、誤検知率、AI コスト、通知ノイズを見てから調整するのが安全です。

まとめ

ai-goofish-monitor は、閒魚監視を「キーワードスクリプト」から「管理可能な AI 監視システム」へ進めるプロジェクトです。Playwright でページ操作を自動化し、AI で複雑な判断を行い、Web UI でタスクと結果を管理し、SQLite にデータを保存し、複数通知チャネルで結果を届けます。

特定商品を監視したい個人や小規模チームに向いています。特に中古デジタル機器、ハードウェア、カメラ機材のように、価格変動が大きく、出品タイミングが重要で、説明ノイズが多いカテゴリに適しています。

ただし慎重に使う必要があります。ログイン状態を保護し、デフォルトパスワードを変更し、取得頻度を抑え、AI 結果を人間が確認し、プラットフォーム規則とプライバシー境界を守ることが重要です。補助的なフィルタリングツールとしては価値がありますが、完全自動取引システムとして見ると能力を過大評価しやすいです。

参考リンク：

Playwright CLI ビデオ録画: 画面録画、チャプターマーカー、オーバーレイおよびデバッグの比較

Wed, 15 Apr 2026 08:22:45 +0800

ブラウザ自動化プロセスをデバッグ用、ドキュメントデモンストレーション用、または実行結果のファイルとしてビデオに記録したい場合、Playwright CLI は比較的簡単なソリューションを提供します。 VP8/VP9 としてエンコードされた WebM ビデオを出力します。

この記事は、公式 video-recording リファレンスドキュメントに従って構成されており、基本的な録画プロセス、チャプターマーカー、ヒーロースクリプト全体の録画、オーバーレイ API、およびビデオとトレースの違いに焦点を当てています。この記事のコマンドライン、コードスニペット、およびパラメーターの説明は、参照コンテンツとして保持されています。

01 基本的な録音の流れ

最も基本的なプロセスは、まずブラウザを開き、次に録画を開始し、操作を実行し、最後に停止して保存します。

# Open browser first
playwright-cli open

# Start recording
playwright-cli video-start demo.webm

# Add a chapter marker for section transitions
playwright-cli video-chapter "Getting Started" --description="Opening the homepage" --duration=2000

# Navigate and perform actions
playwright-cli goto https://example.com
playwright-cli snapshot
playwright-cli click e1
# Add another chapter
playwright-cli video-chapter "Filling Form" --description="Entering test data" --duration=2000
playwright-cli fill e2 "test input"

# Stop and save
playwright-cli video-stop

このコマンドセットは、最も一般的な記録パスをカバーしています。 video-chapter は、録画したビデオを理解しやすくするために、さまざまなステージの間にチャプターカードを挿入するのに適しています。

02 ベストプラクティス

1. わかりやすいファイル名を使用する

ビデオが他の人に見てもらうためのものである場合、または後でレビューする場合は、ファイル名にシーンとコンテキストを直接含めるのが最善です。

1
2
3

# Include context in filename
playwright-cli video-start recordings/login-flow-2024-01-15.webm
playwright-cli video-start recordings/checkout-test-run-42.webm

2. 完全なヒーロースクリプトを記録する

公式アドバイス: ビデオをユーザーに配信する場合、または作業証明として使用する場合は、シーンをコードにまとめて run-code で実行するのが最善です。これにより、ビデオ内のアクションのリズム、一時停止のタイミング、注釈効果を制御しやすくなります。リファレンスドキュメントには、Playwright がシーンの記録に適した新しい API をいくつか追加したことも具体的に記載されています。

推奨されるプロセスは次のとおりです。

まず、CLI を使用してシーンをウォークスルーし、すべてのロケーターとアクションを書き留めます。後でハイライトしたい場合は、これらのロケーターを使用して境界ボックスをリクエストする必要があります。
ビデオ用に別のスクリプトファイルを作成し、次のように記述します。コンテンツを入力する際には、pressSequentially および delay を使用し、一時停止時間をできるだけ自然に配置するようにしてください。
playwright-cli run-code --filename your-script.jsを使用して実行します。

Important: Overlays are pointer-events: none — they do not interfere with page interactions. You can safely keep sticky overlays visible while clicking, filling, or performing any actions on the page.

async page => {
  await page.screencast.start({ path: 'video.webm', size: { width: 1280, height: 800 } });
  await page.goto('https://demo.playwright.dev/todomvc');
  // Show a chapter card — blurs the page and shows a dialog.
  // Blocks until duration expires, then auto-removes.
  // Use this for simple use cases, but always feel free to hand-craft your own beautiful
  // overlay via await page.screencast.showOverlay().
  await page.screencast.showChapter('Adding Todo Items', {
    description: 'We will add several items to the todo list.',
    duration: 2000,
  });
  // Perform action
  await page.getByRole('textbox', { name: 'What needs to be done?' }).pressSequentially('Walk the dog', { delay: 60 });
  await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter');
  await page.waitForTimeout(1000);

  // Show next chapter
  await page.screencast.showChapter('Verifying Results', {
    description: 'Checking the item appeared in the list.',
    duration: 2000,
  });
  // Add a sticky annotation that stays while you perform actions.
  // Overlays are pointer-events: none, so they won't block clicks.
  const annotation = await page.screencast.showOverlay(`
    <div style="position: absolute; top: 8px; right: 8px;
      padding: 6px 12px; background: rgba(0,0,0,0.7);
      border-radius: 8px; font-size: 13px; color: white;">
      ✓ Item added successfully
    </div>
  `);
  // Perform more actions while the annotation is visible
  await page.getByRole('textbox', { name: 'What needs to be done?' }).pressSequentially('Buy groceries', { delay: 60 });
  await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter');
  await page.waitForTimeout(1500);

  // Remove the annotation when done
  await annotation.dispose();
  // You can also highlight relevant locators and provide contextual annotations.
  const bounds = await page.getByText('Walk the dog').boundingBox();
  await page.screencast.showOverlay(`
    <div style="position: absolute;
      top: ${bounds.y}px;
      left: ${bounds.x}px;
      width: ${bounds.width}px;
      height: ${bounds.height}px;
      border: 1px solid red;">
    </div>
    <div style="position: absolute;
      top: ${bounds.y + bounds.height + 5}px;
      left: ${bounds.x + bounds.width / 2}px;
      transform: translateX(-50%);
      padding: 6px;
      background: #808080;
      border-radius: 10px;
      font-size: 14px;
      color: white;">Check it out, it is right above this text
    </div>
  `, { duration: 2000 });
  await page.screencast.stop();
}

このコード部分の焦点は、単に「記録する」ことではなく、ビデオをより鮮明にすることです。チャプターカードはセグメンテーションを担当し、pressSequentially は入力アクションをより自然にし、showOverlay はプロンプト、ハイライト、説明を実行できます。

この文書の最後には、「創造性を受け入れ、オーバーレイは強力です」という一文も追加されています。

03 オーバーレイ API の概要

ビデオを録画する場合、オーバーレイ API はチャプターの切り替え、ローカルプロンプト、および継続的な注釈に非常に適しています。公式の概要は次のとおりです。

Method	Use Case
`page.screencast.showChapter(title, { description?, duration?, styleSheet? })`	Full-screen chapter card with blurred backdrop — ideal for section transitions
`page.screencast.showOverlay(html, { duration? })`	Custom HTML overlay — use for callouts, labels, highlights
`disposable.dispose()`	Remove a sticky overlay added without duration
`page.screencast.hideOverlays()` / `page.screencast.showOverlays()`	Temporarily hide/show all overlays

自動化されたプロセスを「視聴可能なビデオ」に変えることが目標の場合、基本的にはこの API セットを最初に習得するのが最も価値があります。

04 トレースとビデオの違い

公式ドキュメントでは、この 2 つの位置付けが明確に区別されています。

Feature	Video	Tracing
Output	WebM file	Trace file (viewable in Trace Viewer)
Shows	Visual recording	DOM snapshots, network, console, actions
Use case	Demos, documentation	Debugging, analysis
Size	Larger	Smaller

簡単な理解:

video は、「ユーザーから見たプロセス」のデモンストレーション、配信、レビューに適しています。
tracing は、問題のトラブルシューティング、アクションの詳細の分析、実行コンテキストの表示に適しています。

2 人はお互いの代わりではありませんが、それぞれが異なる目的を果たします。

05 利用制限

この文書では、次の 2 つの非常に実際的な制限も指摘しています。

Recording adds slight overhead to automation
Large recordings can consume significant disk space

言い換えれば、記録機能は非常に実用的ですが、自動化されたプロセスにある程度のオーバーヘッドが追加されます。ビデオが非常に長い場合、ディスク使用量も大幅に増加します。

06 簡単なまとめ

重要なポイントだけに焦点を当てると、次のことを思い出すことができます。

video-start / video-stop は最も基本的なビデオ録画プロセスに対応します
video-chapter はビデオにチャプタートランジションを追加でき、プレゼンテーションをより明確にするのに適しています
より複雑なビデオシーンの場合は、スクリプトを作成して run-code で実行するのが適しています。
showOverlay と showChapter を使用すると、ビデオの読みやすさが大幅に向上します。
video はデモンストレーションに適しており、tracing はデバッグに適しています。ターゲットに合わせて選ぶと良いでしょう。

すでに Playwright CLI を自動デモンストレーション、承認ファイル、またはプルーフオブワークに使用している場合、video recording は非常に価値のある追加となります。

参考リンク

Playwright CLI ビデオ録画リファレンスドキュメント: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/video-recording.md
Playwright CLI プロジェクトのホームページ: https://github.com/microsoft/playwright-cli

Playwright CLI セッション管理: マルチブラウザセッション、分離、永続化、クリーンアップ

Wed, 15 Apr 2026 08:15:12 +0800

自動化に Playwright CLI を使用している場合は、すぐに実際的な問題に遭遇することになります。それは、相互に干渉せずに同時に複数のブラウザーセッションを開くことができるかということです。答えは「はい」です。Playwright CLI により、このメカニズムが非常に簡単になりました。

この記事は、公式 session-management リファレンスドキュメントに従い、名前付きセッション、セッション分離、永続性プロファイル、同時実行モード、一般的なクリーンアップコマンドなどの最も実用的な部分を整理します。この記事のコマンドラインとコマンドブロックの説明は、参考コンテンツとして保持されています。

01 ブラウザセッションに名前を付けます

公式の推奨事項は、-s パラメーターを使用して、異なるブラウザーコンテキストを分離することです。

# Browser 1: Authentication flow
playwright-cli -s=auth open https://app.example.com/login

# Browser 2: Public browsing (separate cookies, storage)
playwright-cli -s=public open https://example.com

# Commands are isolated by browser session
playwright-cli -s=auth fill e1 "user@example.com"
playwright-cli -s=public snapshot

ここで重要な点は、異なる session 名が異なるブラウザーコンテキストに対応するということです。ログインプロセスには auth を使用し、匿名アクセスには public を使用できます。 Cookie やローカル状態を共有しません。

02 ブラウザセッションは何を分離しますか?

各ブラウザセッションは、次のコンテンツを独立して保持します。

Cookies
LocalStorage / SessionStorage
IndexedDB
Cache
Browsing history
Open tabs

これは、auth セッションで Web サイトにログインしても、自動的には public セッションに影響を与えないことを意味します。これは、複数アカウントのテスト、ログイン検証、匿名比較を行う場合に特に重要です。

03 ブラウザセッション関連コマンド

公式ドキュメントには、セッション管理で最も一般的に使用される一連のコマンドがまとめられています。

# List all browser sessions
playwright-cli list

# Stop a browser session (close the browser)
playwright-cli close                 # stop the default browser
playwright-cli -s=mysession close   # stop a named browser

# Stop all browser sessions
playwright-cli close-all

# Forcefully kill all daemon processes (for stale/zombie processes)
playwright-cli kill-all

# Delete browser session user data (profile directory)
playwright-cli delete-data              # delete default browser data
playwright-cli -s=mysession delete-data # delete named browser data

これらは、次の 3 種類の操作として理解できます。

list: 現在利用可能な会話を確認します
close/close-all/kill-all: セッションを終了するか、スタックしたブラウザープロセスをクリーンアップします
delete-data: セッションに対応するユーザーデータディレクトリを削除します

ブラウザを終了するだけの場合は、通常、最初に close を使用します。残留プロセスまたはゾンビプロセスがある場合は、kill-all を使用する方が適切です。

04 環境変数を使用してデフォルトのセッションを設定します

コマンドごとに -s=mysession を繰り返し書きたくない場合は、公式が環境変数メソッドも提供しています。

1
2

export PLAYWRIGHT_CLI_SESSION="mysession"
playwright-cli open example.com  # Uses "mysession" automatically

このように、-s が明示的に指定されていない場合、コマンドはデフォルトで mysession ブラウザーセッションを使用します。

05 一般的なパターン: 同時クロール

参考資料には、同時クロールの非常に典型的な例が示されています。

#!/bin/bash
# Scrape multiple sites concurrently

# Start all browsers
playwright-cli -s=site1 open https://site1.com &
playwright-cli -s=site2 open https://site2.com &
playwright-cli -s=site3 open https://site3.com &
wait

# Take snapshots from each
playwright-cli -s=site1 snapshot
playwright-cli -s=site2 snapshot
playwright-cli -s=site3 snapshot

# Cleanup
playwright-cli close-all

このモードは、複数のサイトを同時に開き、ページのステータスを個別に取得して、それらをまとめてクリーンアップするのに適しています。各サイトは個別のセッションで実行されるため、互いのローカル状態を汚染することはありません。

06 一般的なパターン: A/B テストセッション

もう 1 つの一般的なシナリオは、異なる実験版を同時に比較することです。

# Test different user experiences
playwright-cli -s=variant-a open "https://app.com?variant=a"
playwright-cli -s=variant-b open "https://app.com?variant=b"

# Compare
playwright-cli -s=variant-a screenshot
playwright-cli -s=variant-b screenshot

この書き方は、2 つのバージョンが独立したセッションで実行され、スクリーンショットとステータスチェックを個別に管理しやすいため、A/B ページの差分比較に非常に適しています。

07 永続的なブラウザプロファイル

公式ドキュメントには具体的に次のように記載されています: デフォルトでは、ブラウザーのプロファイルはメモリにのみ保存されます。

ブラウザープロファイルをディスクに保存したい場合は、--persistent を open に追加する必要があります。

# Use persistent profile (auto-generated location)
playwright-cli open https://example.com --persistent

# Use persistent profile with custom directory
playwright-cli open https://example.com --profile=/path/to/profile

この機能は、ログインステータス、ローカルキャッシュ、または拡張デバッグ環境の長期的な再利用が必要なシナリオに適しています。特に、同じサイトを何度もデバッグする場合は、毎回最初から開始するよりもプロファイルを永続化する方が効率的であることがよくあります。

08 デフォルトのブラウザセッション

-s が明示的に渡されない場合、コマンドはデフォルトのブラウザーセッションを使用します。

# These use the same default browser session
playwright-cli open https://example.com
playwright-cli snapshot
playwright-cli close  # Stops default browser

つまり、-s のない複数のコマンドは、デフォルトで同じデフォルトセッション内で継続的に実行されます。

09 セッション構成で開く

セッション名に加えて、公式ではいくつかの一般的な起動設定方法も提供しています。

# Open with config file
playwright-cli open https://example.com --config=.playwright/my-cli.json

# Open with specific browser
playwright-cli open https://example.com --browser=firefox

# Open in headed mode
playwright-cli open https://example.com --headed

# Open with persistent profile
playwright-cli open https://example.com --persistent

これらのパラメータはセッション管理と組み合わせて使用できます。たとえば、名前付きセッションを常に firefox で実行したり、セッションを常に headed モードで開始して手動で観察しやすくしたりできます。

10 の公式ベストプラクティス

参考資料には、3 つの非常に実践的なベストプラクティスがリストされています。

1. セマンティックなセッション名を使用する

# GOOD: Clear purpose
playwright-cli -s=github-auth open https://github.com
playwright-cli -s=docs-scrape open https://docs.example.com

# AVOID: Generic names
playwright-cli -s=s1 open https://github.com

目的を直接表現するセッション名を付けるのが最善です。 github-auth や docs-scrape のような名前は、後でスクリプトを保守するときにはるかに明確になります。

2. 使用後は適時に掃除してください

# Stop browsers when done
playwright-cli -s=auth close
playwright-cli -s=scrape close

# Or stop all at once
playwright-cli close-all

# If browsers become unresponsive or zombie processes remain
playwright-cli kill-all

タスクの完了後にブラウザを閉じないと、セッションとバックグラウンドプロセスが残ります。短期的には大きな問題ではありませんが、タスクが多すぎると環境が混乱しやすくなります。

3. 古いブラウザデータを削除する

1
2

# Remove old browser data to free disk space
playwright-cli -s=oldsession delete-data

一部の古いセッションが使用されなくなった場合、対応するデータディレクトリを削除すると、ディスク領域を節約し、後で期限切れステータスの悪用を避けることができます。

11 簡単なまとめ

重要なポイントだけに焦点を当てると、次のことを思い出すことができます。

-s=<name> は、独立したブラウザセッションを作成および使用するために使用されます。
Cookie、ストレージ、キャッシュ、履歴、タブはセッション間で分離されます
close-all は統合シャットダウンに適しており、kill-all は異常な残留プロセスの処理に適しています。
--persistent は、長期間の再利用に適したプロファイルをディスクにダウンロードするために使用されます。
セッション名はできる限りセマンティックである必要があり、古いデータは定期的にクリーンアップする必要があります。

ワークフローにすでにログイン状態の再利用、複数アカウントの並列処理、A/B 比較、またはバッチクロールのニーズがある場合、基本的に session management は、Playwright CLI の機能を習得するのに最も価値があります。

参考リンク

Playwright CLI セッション管理リファレンスドキュメント: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/session-management.md
Playwright CLI プロジェクトのホームページ: https://github.com/microsoft/playwright-cli

Playwright CLI ストレージ状態の使用法: ログイン状態の保存、Cookie とローカルストレージの読み取り

Tue, 14 Apr 2026 22:19:55 +0800

ブラウザの自動化に Playwright CLI を使用する場合、storage state は基本的に最もよく使用される機能の 1 つです。その機能は非常に直接的です。現在のログイン状態とローカル状態をブラウザに保存し、後でそれを再利用して、毎回再度ログインする必要がなくなります。

01 現在の保存状態を保存します

最も一般的なシナリオは、一度ログインしてから現在のステータスをファイルにエクスポートすることです。

`1`	`playwright-cli storage-state save auth.json`

このコマンドは、現在のブラウザーコンテキストの状態を auth.json に保存します。後でログイン状態を再利用する場合は、通常はこのステップから開始します。

02 既存のストレージ状態をロードします

状態ファイルをすでに作成している場合は、起動時にそれを直接ロードできます。

`1`	`playwright-cli --storage-state auth.json`

auth.json の状態でブラウザーコンテキストを開始します。一般的な使用法は、繰り返しのログインをスキップして、ログインした環境に直接入ることです。

現在のセッションにどのような Cookie があるかを確認したいだけの場合は、それらを直接表示できます。

`1`	`playwright-cli cookies`

このコマンドは、現在のコンテキスト内の Cookie をリストします。ログイン状態が存在するかどうか、Cookie が正常に書き込まれたかどうかを確認するのに適しています。

04 クッキーを設定する

すでに Cookie データがある場合は、直接書き込むこともできます。

`1`	`playwright-cli cookies set '[{"name":"session","value":"abc","domain":"example.com","path":"/"}]'`

この使用法は、認証のデバッグ、特定のセッションの再現、またはスクリプトの前に Cookie 条件を手動で挿入する場合に適しています。

05 ローカルストレージの読み取り

一部のサイトのログインステータスまたはフロントエンドステータスは、Cookie だけでなく localStorage にも保存されます。

`1`	`playwright-cli local-storage`

このコマンドは、現在のページの localStorage コンテンツを表示するために使用されます。この手順は、「ログインしているように見えますが、ページの動作が間違っている」というトラブルシューティングを行う場合に役立ちます。

06 ローカルストレージへの書き込み

フロントエンドのステータスをシミュレートする必要がある場合は、それを直接設定することもできます。

`1`	`playwright-cli local-storage set token abc123`

指定されたキー値を localStorage に書き込みます。一般的な用途は、トークン、基本設定、または一部のフロントエンドスイッチを挿入することです。

07 セッションストレージの読み取り

sessionStorage は、現在のセッションの一時的なステータスを表示するのに適しています。

`1`	`playwright-cli session-storage`

このコマンドは、現在のページの sessionStorage を出力します。特定のページロジックがワンタイムセッションデータに依存している場合は、ここから確認できます。

08 セッションストレージへの書き込み

必要に応じて、sessionStorage を手動で設定することもできます。

`1`	`playwright-cli session-storage set key value`

これは、一時的な状態に依存する特定のページ動作を再現したり、初期化ステップに必要なフィールドを入力したりするのに適しています。

09 IndexedDB の表示

より重い Web アプリケーションの場合、本当に重要なデータは IndexedDB にある可能性があります。

`1`	`playwright-cli indexed-db`

このコマンドは、現在のページの IndexedDB データを表示するために使用されます。複雑な単一ページアプリケーション、オフラインキャッシュ、またはローカルデータベーススタイルの状態に遭遇した場合は、最初にここを確認できます。

10 最も実用的なワークフローの 1 つ

ログイン状態を安定して再利用したいだけの場合、最も単純なプロセスは通常次のようになります。

まずサイトを開いて手動でログインを完了します。
次のコマンドを実行してステータスを保存します。

`1`	`playwright-cli storage-state save auth.json`

後続の実行中に直接ロードします。

`1`	`playwright-cli --storage-state auth.json`

ロード後もページに異常がある場合は、引き続き次の確認を行ってください。

playwright-cli cookies
playwright-cli local-storage
playwright-cli session-storage
playwright-cli indexed-db

このシーケンスで「状態が完全に復元されていない」という問題のほとんどはすでにカバーできます。

11 使用上の注意点

注目すべき点は次の 3 つです。

storage state ファイルは本質的に機密データであり、ログイン Cookie またはトークンが含まれる場合があります。安易に倉庫に提出しないでください。
単に Cookie を復元するだけでは必ずしも十分ではなく、多くの最新のサイトは localStorage、sessionStorage、または IndexedDB にも依存しています。
ステータスファイルは永続的に有効ではないため、通常、Cookie の有効期限が切れた後、アカウントが変更された後、または環境が切り替わった後に再生成する必要があります。

12 簡単なまとめ

一文しか覚えていない場合:

**Playwright CLI の storage state は、ブラウザの現在の状態を保存し、後続のタスクで引き続き使用します。 **

実際のトラブルシューティングでは、最も一般的に使用されるコマンドのセットは次のとおりです。

playwright-cli storage-state save auth.json
playwright-cli --storage-state auth.json
playwright-cli cookies
playwright-cli local-storage
playwright-cli session-storage
playwright-cli indexed-db

最初に保存してからロードします。そうでない場合は、Cookie とさまざまなローカルストレージ層を確認してください。これは基本的に、このリファレンスドキュメントの最も実践的な部分です。

参考リンク

Playwright CLI ストレージ状態リファレンスドキュメント: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/storage-state.md
Playwright CLI プロジェクトのホームページ: https://github.com/microsoft/playwright-cli

Playwright CLI の入門: インストール、スキル、セッション管理、および一般的なコマンド

Sun, 12 Apr 2026 14:36:58 +0800

現在、ブラウザ自動化に Claude Code、GitHub Copilot、またはその他のコーディングエージェントを使用している場合、microsoft/playwright-cli は注目に値する新しいツールです。これは、「コマンドを手動で入力するために使用される」従来の意味でのブラウザガジェットではなく、エージェントをコーディングするための Playwright CLI であり、トークンオーバーヘッドの低減、軽量のコマンドインターフェイス、およびスキルワークフローとの統合を重視しています。

公式 README から判断すると、Playwright CLI の核となる考え方は非常に明確です。モデルコンテキストに多数のツールスキーマとページ構造を詰め込む MCP と比較して、CLI コマンド方式はよりコンパクトで、大規模なコードベース、テストタスク、ブラウザ自動化の間を行き来するエージェントワークフローにより適しています。

01 Playwright CLIとは何ですか?

playwright-cli は、Microsoft がオープンソース化した Playwright コマンドラインツールです。公式説明は「一般的な Playwright アクション用の CLI」です。主に次のことを実現するために使用されます。

ページを開いてブラウザを起動します
Playwright コードを記録して生成する
ページのスナップショットを取得し、要素の参照を取得します
スクリーンショット、PDF のエクスポート
コーディングエージェントと連携して自動テストとWebページ運用を行います。

現在の GitHub README では、これを非常に明確に位置づけています。コーディングエージェントを使用している場合は、Playwright MCP よりも CLI の方が適していることがよくあります。永続的な状態、豊富なイントロスペクション、長いエージェントループが必要な場合でも、MCP には価値があります。

言い換えれば、Playwright CLI は、人間のエンジニアが Web ページを手動でクリックするための単なるツールではなく、「AI コーディングアシスタントのためのブラウザ自動化インターフェイス」に近いものです。

02 そのメリットは何ですか?

1. エージェントのワークフローにさらに適した

公式READMEには、最初の利点がToken-efficientとして直接書かれています。データのページ全体を LLM コンテキストに強制的に組み込むのではなく、エージェントはより短く、より特殊なコマンドを通じてブラウザを操作できるようになります。

これはエージェントのコーディングにとって重要です。実際のプロジェクトでは、エージェントはブラウザを実行するだけでなく、コードの読み取り、ファイルの変更、テストの実行、ログの読み取りも行うためです。ブラウザツール自体が非常に「コンテキストを食べる」場合、全体の効率が大幅に低下します。

2. スキルを使って作業する能力

README では特に playwright-cli install --skills を強調しています。これは、公式がこれを単なるシェルツールとして捉えておらず、Claude Code や GitHub Copilot などのエージェントが直接利用できるスキルの入り口として設計していることを示しています。

ワークフロー自体がスキルに基づいて構築されている場合は、Playwright CLI への接続がより自然になります。

3. セッション管理が比較的完了している

Playwright CLI はセッションをサポートします。デフォルトでは、ブラウザプロファイルはメモリに保存され、同じセッション内の Cookie とストレージは複数の CLI 呼び出し間で保持されます。 --persistent が追加された場合、プロファイルをディスクにドロップし、ブラウザを再起動しても引き続き使用することもできます。

これにより、「コマンド 1 つでブラウザを開いて実行後に破棄する」というおもちゃのツールよりも実用的となり、継続的なデバッグやエージェントの長時間プロセスの実行にも適しています。

4. 視覚監視パネルが付属しています

playwright-cli show は README に含まれており、ダッシュボードを開いて実行中のすべてのブラウザーセッションを監視および制御するために使用されます。これは、ただやみくもに実行するのではなく、いつでも引き継ぎ、監視、トラブルシューティングを行うことができるため、エージェントがバックグラウンドで自動化されたタスクを実行するシナリオで役立ちます。

03 設置および環境要件

現在の GitHub README によると、Playwright CLI の基本要件は次のとおりです。

Node.js 18 以降
Claude Code、GitHub Copilot、またはその他のコーディングエージェント

インストールコマンドは以下のとおりです。

1
2

npm install -g @playwright/cli@latest
playwright-cli --help

ここには特に注意しなければならない非常に簡単な落とし穴があります。

現在推奨されている公式インストールは @playwright/cli です。
これを、npm 上の歴史的で非推奨となった古いパッケージ playwright-cli と混同しないでください。

つまり、実際にインストールする必要があるのは、古い時代からの同名の履歴パッケージではなく、スコープ指定されたパッケージです。

04 始め方

1. スキルをインストールする

コーディングエージェントに Playwright CLI を直接使用させたい場合は、最初にスキルをインストールすることが公式推奨されています。

`1`	`playwright-cli install --skills`

README には、Claude Code や GitHub Copilot などのツールがローカルにインストールされたスキルを使用することが明確に記載されています。

2. エージェントに CLI を直接呼び出させる

最初にスキルを処理したくない場合は、エージェントに CLI ヘルプ情報を直接読み取らせることもできます。

1
2

Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.

正式にはこの方法を「スキルレス操作」といいます。これは、スキルがプリインストールされていない場合でも、CLI 自己記述機能を通じてエージェントを駆動できることを意味します。

3. 最小限の工程を手動で体験

README には、開始するのに非常に適した一連の TodoMVC サンプルが含まれています。

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli type "Water flowers"
playwright-cli press Enter
playwright-cli check e21
playwright-cli check e35
playwright-cli screenshot

このコマンドセットの価値は、Playwright CLI がどのように対話するかをすぐに理解できることです。

open はページを開く責任があります
type および press は入力を担当します
check 要素参照を使用したチェックボックスの操作
screenshot 結果を保存

05 `--headed`、セッションおよびモニタリングパネル

`--headed`

Playwright CLI はデフォルトではヘッドレスです。ブラウザウィンドウを直接表示したい場合は、--headed を open に明示的に追加する必要があります。

`1`	`playwright-cli open https://playwright.dev --headed`

これは、セレクター、ログインプロセス、検証コードの前後のインタラクティブな観察のデバッグに便利です。

session

公式 README ではセッションの使用法が強調されています。異なるセッションを使用して、異なるプロジェクトまたは Web サイトを分離できます。

1
2
3

playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list

エージェントを長時間動作させたい場合は、環境変数を直接指定することもできます。

`1`	`PLAYWRIGHT_CLI_SESSION=todo-app claude .`

一般的に使用されるセッション管理コマンドには次のものがあります。

1
2
3

playwright-cli list
playwright-cli close-all
playwright-cli kill-all

で：

list はすべてのセッションをリストするために使用されます
close-all は、すべてのブラウザを通常どおり閉じるために使用されます。
kill-all は、すべてのブラウザプロセスを強制的に終了するために使用されます。

監視パネル

ブラウザでエージェントが現在何を行っているかを確認したい場合は、次のコマンドを実行できます。

`1`	`playwright-cli show`

README によると、このダッシュボードには主に 2 つのビューがあります。

セッショングリッド: すべてのアクティブなセッションをワークスペースごとに表示し、ライブビュー、URL、ページタイトルを表示します。
セッションの詳細: 単一セッションのリアルタイムインターフェイスを表示し、マウスとキーボードを引き継ぐこともできます

これにより、Playwright CLI は「コマンドラインが利用可能」になるだけでなく、比較的成熟した可観測性も備えます。

06 最初に覚えるべき一般的なコマンドはどれですか?

Playwright CLI を初めて使用する場合は、最初からすべてのコマンドを覚える必要はありません。最初に次の中心点を覚えておくだけで十分です。

ページとインタラクション

playwright-cli open [url]
playwright-cli goto <url>
playwright-cli click <ref>
playwright-cli fill <ref> <text>
playwright-cli type <text>
playwright-cli hover <ref>
playwright-cli press <key>

ページ構造を取得する

playwright-cli snapshot
playwright-cli snapshot <ref>
playwright-cli snapshot --depth=N
playwright-cli eval <func> [ref]

後続の多くの操作は要素参照 ref に依存するため、snapshot は重要です。通常は、最初にスナップショットを取得し、次に返された要素番号を使用してクリック、入力、チェック、またはスクリーンショットの取得を行います。

出力結果

1
2

playwright-cli screenshot
playwright-cli pdf

タブページ

playwright-cli tab-list
playwright-cli tab-new [url]
playwright-cli tab-close [index]
playwright-cli tab-select <index>

07 どんな人に向いていますか？

次のいずれかのシナリオに該当する場合は、Playwright CLI を試してみる価値があります。

E2E テストに Claude Code、Copilot、またはその他のコーディングエージェントを使用している
ブラウザ自動化インターフェイスをより軽量にしたいが、コンテキストに多くのページ構造を詰め込みたくない場合
複数のコマンド間で同じブラウザセッションを維持したい場合
エージェントが Web ページタスクを自動的に実行するとき、いつでも監視パネルを開いて進行状況を観察したいと考えています。

「ブラウザの自動化がコーディングエージェントとどのように効果的に連携できるか」が仕事の焦点である場合、Playwright CLI は従来の人による手動のデバッグ方法よりも便利である可能性があります。

Playwright on KnightLiブログ

CloakBrowserとは？PlaywrightとPuppeteerに、より実ユーザーに近いブラウザを使わせる

何を解決するのか

基本的な使い方

Browser Profile Manager

通常の Playwright との違い

注意点

向いている人

まとめ

ai-goofish-monitor：AI で閒魚の商品を自動監視するオープンソースシステム

先に結論

解決する問題

主な機能

ワークフロー

Docker デプロイ

最小構成

初回利用

AI タスクとキーワードタスク

Web UI でできること

データ保存

通知チャネル

開発者向け実行

向いている人

リスクと境界

普通のスクリプトとの違い

使い方の例

まとめ

Playwright CLI ビデオ録画: 画面録画、チャプター マーカー、オーバーレイおよびデバッグの比較

01 基本的な録音の流れ

02 ベストプラクティス

1. わかりやすいファイル名を使用する

2. 完全なヒーロー スクリプトを記録する

03 オーバーレイ API の概要

04 トレースとビデオの違い

05 利用制限

06 簡単なまとめ

参考リンク

Playwright CLI セッション管理: マルチブラウザ セッション、分離、永続化、クリーンアップ

01 ブラウザセッションに名前を付けます

02 ブラウザセッションは何を分離しますか?

03 ブラウザセッション関連コマンド

04 環境変数を使用してデフォルトのセッションを設定します

05 一般的なパターン: 同時クロール

06 一般的なパターン: A/B テスト セッション

07 永続的なブラウザプロファイル

08 デフォルトのブラウザセッション

09 セッション構成で開く

10 の公式ベスト プラクティス

1. セマンティックなセッション名を使用する

2. 使用後は適時に掃除してください

3. 古いブラウザデータを削除する

11 簡単なまとめ

参考リンク

Playwright CLI ストレージ状態の使用法: ログイン状態の保存、Cookie とローカル ストレージの読み取り

01 現在の保存状態を保存します

02 既存のストレージ状態をロードします

03 現在の Cookie を表示する

04 クッキーを設定する

05 ローカルストレージの読み取り

06 ローカルストレージへの書き込み

07 セッションストレージの読み取り

08 セッションストレージへの書き込み

09 IndexedDB の表示

10 最も実用的なワークフローの 1 つ

11 使用上の注意点

12 簡単なまとめ

参考リンク

Playwright CLI の入門: インストール、スキル、セッション管理、および一般的なコマンド

01 Playwright CLIとは何ですか?

02 そのメリットは何ですか?

1. エージェントのワークフローにさらに適した

2. スキルを使って作業する能力

3. セッション管理が比較的完了している

4. 視覚監視パネルが付属しています

03 設置および環境要件

04 始め方

1. スキルをインストールする

2. エージェントに CLI を直接呼び出させる

3. 最小限の工程を手動で体験

05 --headed、セッションおよびモニタリングパネル

Playwright CLI ビデオ録画: 画面録画、チャプターマーカー、オーバーレイおよびデバッグの比較

2. 完全なヒーロースクリプトを記録する

Playwright CLI セッション管理: マルチブラウザセッション、分離、永続化、クリーンアップ

06 一般的なパターン: A/B テストセッション

10 の公式ベストプラクティス

Playwright CLI ストレージ状態の使用法: ログイン状態の保存、Cookie とローカルストレージの読み取り

05 `--headed`、セッションおよびモニタリングパネル

`--headed`