Playwright のスクリプトを書いて、いざ動かしてみたら MFA の画面で止まった——そういう経験、一度はありますよね。
「ログインができない」という問題に見えても、実際のところ Playwright 自体はちゃんと動いています。
詰まっているのはツール側ではなく、モダンな認証基盤のアーキテクチャそのものです。
Tencent が 2026 年 6 月に公開した OSS ツール BrowserSkill は、その詰まりに対してシンプルな答えを出してきます。
「新しいブラウザセッションを立ち上げる」のではなく「すでにログイン済みのブラウザをそのまま借りる」——この設計の転換が、Playwright では越えられなかった壁をどう崩すのか、仕組みレベルで見ていきます。
Claude Code からの操作イメージと、自分の担当業務への当てはめ方も一緒に整理します。
Playwright でログイン自動化が詰まる、本当の理由
「ログインできない」の正体を掘り下げると、大半のケースで MFA・SSO・デバイス信頼の三つが絡み合っています。
Playwright が Chromium を立ち上げたとき、そのブラウザは認証基盤から見て 見慣れないデバイス です。
デバイス証明書やブラウザフィンガープリントは既存の登録と一致しないため、たとえ正しい ID とパスワードを入力しても「このデバイスは未登録」と判断されて MFA が飛んできます。
TOTP をコードで生成して突破できるケースもありますが、それは TOTP 方式に限った話です。
Okta Verify や Microsoft Authenticator の Push 承認、FIDO2 による物理キー認証、企業の Conditional Access ポリシーが絡むと、コードだけでは越えられない壁になります。
storageState や launchPersistentContext を使って「セッションを使い回す」アプローチを試みた人も多いと思います。
最初の一回だけ手動でログインして Cookie をファイルに保存し、以降はそれを読み込む——これは一定機能します。
ただし、セッションの有効期限・IP アドレスの変化・デバイス信頼の再検証のどれかが引っかかると、保存した Cookie は無効化されます。
頻度が少ないバッチ処理なら何とかなるかもしれませんが、毎日動かすような業務自動化では定期的にセッションが切れて、結局誰かが手動ログインを挟む運用になりがちです。
もう一つの逃げ道として、IT 管理者に頼んで「自動化専用アカウント」を作り、そのアカウントだけ MFA 要件を緩和してもらう方法があります。
現実的に使えることもある選択肢ですが、セキュリティ例外の申請・承認フロー・定期レビューが発生するので、IT 部門との調整コストは無視できません。
中小規模の開発現場では「そこまでやるくらいなら手動でいいか」となることも珍しくないです。
これらの詰まりの根本を突き詰めると、共通の構造が見えてきます。
Playwright は 新規のブラウザを立ち上げる ツールである、という点です。
新しく立ち上げたブラウザには何のセッション情報もないので、ゼロから認証を通す必要があります。
「それができない」から詰まっているわけで、ツールを工夫しても前提そのものは変わりません。
この前提を根っこから変えたのが BrowserSkill のアプローチです。
BrowserSkill のアーキテクチャ：「借りる」という発想の転換
BrowserSkill の設計を一言で言えば、「セッションを作る」のではなく「すでに存在するセッションを借りる」です。
自分がいつも使っている Chrome で、すでに社内システムや SaaS にログインしている状態があるとします。
BrowserSkill はその状態のブラウザを、AI エージェントがそのまま操作できる形で公開してくれます。
仕組みの中心になるのは三つのコンポーネントです。
まず bsk CLI（ローカルデーモン）。
ローカルマシンで常駐するプロセスで、AI エージェントからの指示を受け付ける窓口になります。
エージェントはシェルコマンドとして bsk を呼び出せるので、Claude Code・Cursor・Codex など「シェルを使えるエージェント」であれば原則どれでも接続できます。
次に Chrome 拡張。
これがブラウザと CLI の橋渡しをします。
拡張が bsk CLI と通信することで、CLI 側からブラウザのタブを制御できる状態になります。
ここが Playwright との根本的な違いで、Playwright が外から新しいプロセスを立ち上げるのに対して、BrowserSkill は既存のブラウザの中に間借りする形です。
三つ目が エージェント（Claude Code 等）。
エージェントは bsk CLI に対してコマンドを投げ、CLI が拡張経由でブラウザを操作します。
エージェントから見ると、ブラウザ操作はただの CLI ツール呼び出しです。
動作モデルとして特徴的なのは、「タブを明示的に借りて、タスク完了後に返す」という点です。
エージェントが操作を始めると、別タブが「Agent Window」として開いて、その中でだけ作業が進みます。
残りのタブはそのまま触られないので、自分がブラウザを使い続けながら、バックグラウンドでエージェントが作業している状態が実現できます。
2026 年 6 月 22 日に公開された OSS で、執筆時点の GitHub Star 数は 1.3k 程度です。
活発に開発されていますが、まだ若いプロジェクトであることは念頭に置いておく必要があります。
対応環境としては、OS は macOS（Apple Silicon・Intel）、Linux（x64・ARM64）、Windows x64 をカバーしています。
ブラウザは Chrome と Microsoft Edge が対応済みで、他の Chromium 系ブラウザも動作が見込まれます。
Firefox は現時点では未対応で、計画はあるものの対応時期は未定です。
セットアップ：インストールから接続確認まで
全体の流れは「bsk CLI をインストール → Chrome 拡張を入れる → エージェントへスキルを登録する」の三ステップです。
bsk CLI のインストールは、macOS・Linux では curl のワンライナー、Windows では PowerShell のコマンドで完結します。
インストール先は ~/.local/bin です。
正確なインストールコマンドはバージョンによって変わる可能性があるため、GitHub リポジトリの README に掲載されている最新の手順を参照してください。
インストールが終わったらバージョン確認をします。
bsk --version
ここでバージョンが表示されれば CLI は動いています。
表示されなければ PATH が通っていない可能性が高いので、シェルを再起動するか ~/.local/bin を PATH に追加してください。
Chrome 拡張は Chrome Web Store または Edge Add-ons からインストールします。
インストール後に拡張を 有効化 するのを忘れがちなので、拡張の管理画面でトグルがオンになっていることを確認しておきましょう。
最後に、エージェントへのスキル登録です。
BrowserSkill には「スキル」という仕組みがあり、これをインストールするとエージェントが bsk の使い方を理解した状態になります。
スキルのインストールは bsk コマンド一行で完結する設計になっていて、Playwright MCP のように MCP サーバーを JSON で定義して別途立ち上げる必要はありません。
具体的なコマンドは GitHub リポジトリ を参照してください。
Claude Code から実際に操作してみる
セットアップが終わった状態で、Chrome ですでに社内のグループウェアにログインしているとします。
Claude Code のターミナルからこんな指示を出してみます。
以下は指示とエージェントの応答の イメージを示した架空の例 です。
実際の出力形式やメッセージ内容はエージェントのバージョンや操作対象によって異なります。
# 指示例
今日の自分宛ての未読メッセージを確認して、
件名と送信者の一覧を教えて。
グループウェアはすでに Chrome でログイン済みです。
# エージェントの応答イメージ
> bsk を使ってログイン済みのブラウザに接続します。
> グループウェアのタブを借ります... 取得に成功しました。
> Agent Window を開いて操作を開始します。
> 未読メッセージを確認しています...
[確認結果]
- 件名「来週の MTG 日程について」/ 送信者：田中
- 件名「Q3 レポートのレビュー依頼」/ 送信者：佐藤
- 件名「サーバーメンテナンスのお知らせ」/ 送信者：システム通知
操作が完了しました。タブを返却しました。
操作中は Agent Window として別タブが開いて、クリックや入力がリアルタイムで可視化されます。
何をやっているかが目で見えるのは、Playwright のヘッドレス実行と比べると透明性がかなり違います。
意図しない操作が走ったときにすぐ気づいて止められるのは、業務への適用を考えると地味に重要な点です。
Playwright MCP との比較でいうと、MCP サーバーを JSON で定義・登録する手順がそもそも不要になるため、セットアップの手数は明らかに少なくなります。
トークン消費量の差については裏付けのある数値が手元にないため言及しませんが、ブラウザとのやりとり方式がアーキテクチャレベルで異なる以上、実際に動かしてみると挙動の差は感じられるはずです。
「諦めていた業務」への適用と、使う前に考えておくこと
BrowserSkill が刺さりやすい業務は、「ログインできれば単純作業なのに、ログイン自体が壁になっていた」ケースです。
自分の担当業務を棚卸しする材料として、三つのケースを具体的に挙げてみます。
一つ目は 社内の SSO 必須システム（ERP・グループウェアなど）への定期操作です。
勤怠の集計、在庫状況の確認、ワークフローの承認など、毎日同じ画面を開いて同じ操作をしているならエージェントに任せられる候補です。
SSO + MFA の組み合わせで Playwright が詰まりやすい代表格であり、ログイン済みのブラウザをそのまま渡せるなら突破口になります。
二つ目は 取引先のポータルや EDI 画面 です。
受発注の確認、出荷ステータスのチェック、請求書のダウンロードなど、相手方が用意した画面を定期的に確認する作業が対象です。
こういった外部システムは API が提供されていないことが多く、スクレイピングしようにもログインで詰まって諦めていたケースが多いはずです。
三つ目は SaaS 管理画面 の定型操作です。
ユーザーの追加・削除、請求情報の確認、設定の変更といった作業は、API や CLI が整備されていない SaaS では手作業になりがちです。
自分がログイン済みの状態を活かせるなら、繰り返し発生する管理業務を任せる候補になります。
ただし、Cookie をそのまま扱う仕組みである以上、セキュリティ上の考慮は必要です。
bsk はローカルで動くデーモンであり、Cookie や認証情報がクラウドに送信されるわけではありません。
もっとも、エージェントがブラウザを操作する以上、 エージェントに何をさせるかを意識した権限設計 は欠かせません。
「確認だけ」のつもりが、意図せず送信・更新・削除を実行してしまうリスクはゼロではないため、最初のうちは操作ログを目視で確認しながら使うのが現実的です。
OSS としての成熟度についても正直に書いておきます。
Firefox には現時点で未対応です。
エラーハンドリングやエッジケースへの対応は、公開から日が浅いだけにまだ荒削りな部分があります。
プロダクション投入の前に、本番に影響しない環境で十分に動作確認することをすすめます。
「動くけど安定しない」という状態のまま業務運用に乗せると、自動化よりも障害対応のコストのほうがかさむ結果になりかねません。
BrowserSkill は「ログインさえできれば自動化できるのに」という積み上がった詰まりに対して、かなりシンプルな答えを出してきたツールです。
新しいブラウザを立ち上げるのではなく、使い慣れたブラウザをそのまま渡す——この一点を変えるだけで、諦めていた業務の自動化候補がいくつか浮かび上がってくるはずです。
まずは低リスクな確認系タスクから試してみるのが、一番着実なスタートだと思います。
株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援を手がけています。
「社内システムの自動化を検討しているが何から手をつければいいか分からない」といった相談も受け付けています。
気になることがあれば、お気軽に お問い合わせ からご連絡ください。