Playwright CLI on KnightLiブログ

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 CLI on KnightLiブログ

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、セッションおよびモニタリングパネル

--headed

session

監視パネル

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

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

ページ構造を取得する

出力結果

タブページ

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

参考リンク

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

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

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

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

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

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

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

`--headed`