Playwright／Puppeteer 系ブラウザ MCP｜ログインセッションとCAPTCHAの壁（法人向け注意喚起）

AIエージェントが自律的にブラウザを操作し、Web上のタスクを完遂する「Model Context Protocol (MCP)」の活用が急速に広がっています。特に、PlaywrightやPuppeteerをバックエンドに持つブラウザ系MCPサーバーは、これまでAPIが公開されていなかったレガシーなSaaSや、複雑な管理画面の操作を可能にする「DXの切り札」として注目されています。

しかし、実務においてプロトタイプから本番運用へ移行しようとする際、必ずと言っていいほど直面するのが「ログインセッションの消失」と「CAPTCHA（画像認証）によるブロック」という2つの高い壁です。これらの対策を講じずに自動化を進めると、AIが処理の途中で認証エラーを起こし、かえって人間の手作業によるリカバリコストが増大するという本末転倒な結果を招きます。

本記事では、IT実務担当者およびエンジニア向けに、ブラウザ系MCPを用いた自動化における認証維持の技術的アプローチと、法人として遵守すべきセキュリティ・規約上の注意点を詳説します。

1. ブラウザ系MCPが直面する「ログインと認証」の技術的課題

ブラウザ系MCPサーバー（例：modelcontextprotocol/server-playwright）の多くは、デフォルトの状態では「ゲストブラウザ」として起動します。これは、実行のたびにキャッシュやCookieが空の状態で新しいブラウザインスタンスが立ち上がることを意味します。

1.1 Playwright/Puppeteer MCPサーバーの基本構造

通常、MCP経由でLLMが「ブラウザで〇〇のサイトを開いて、売上データを取得して」と指示を受けると、背後では以下のようなプロセスが走ります。

• LLMがMCPサーバーの navigate ツールを呼び出す。
• サーバー側でPlaywright（またはPuppeteer）が起動し、ヘッドレスブラウザ（画面なし）でURLにアクセス。
• ページの内容をテキスト化、またはスクリーンショットを撮ってLLMに返す。

このフローにおいて、対象のサイトがログインを必要とする場合、LLMは「IDとパスワードの入力」を試みますが、多くの法人向けSaaSではここで多要素認証（MFA）やボット検知が作動し、自動処理が停止します。

1.2 なぜAIは「ログインボタン」の前で立ち止まるのか

AIがログインに失敗する主な要因は、入力ミスではなく「環境の変化」にあります。Webサービス側は、接続元のIPアドレス、ブラウザの指紋（フォント、解像度、OS情報）、そしてCookieの有無を常に監視しています。毎回「真っさらな状態」でアクセスしてくるMCP経由の接続は、セキュリティシステムから見れば「乗っ取りを狙う不審なボット」そのものです。

1.3 2026年現在の主要なボット検知アルゴリズム

現在、GoogleのreCAPTCHA v3やCloudflare Turnstileといった高度な検知システムは、単に画像を選ばせるだけでなく、マウスの動き（カーソルの軌跡）や、バックグラウンドでのJavaScriptの実行挙動を解析しています。AIによる自動操作は、人間と比較して動きが直線的で速すぎるため、即座に「人間ではない」と判定される傾向にあります。

2. ログインセッションを永続化する「ブラウザプロファイル」の実装

業務自動化を安定させる最短ルートは、AIに毎回ログインさせることではなく、「すでにログイン済みの状態」のブラウザをAIに渡すことです。これを実現するのが「ブラウザプロファイルの永続化」です。

2.1 userDataDir（ユーザーデータディレクトリ）の指定方法

PlaywrightやPuppeteerには、ブラウザのCookie、キャッシュ、LocalStorage、パスワード保存情報を特定のディレクトリに保存する機能があります。MCPサーバーの起動スクリプトや設定ファイルにおいて、このパスを固定することで、前回実行時のセッションを次回の実行時にも引き継ぐことが可能になります。

例えば、Playwrightであれば以下のようにコンテキストを起動します。

const context = await chromium.launchPersistentContext('/path/to/user/data', { headless: false });

法人環境では、このプロファイルディレクトリを安全な共有ストレージや、特定のサーバー内に隔離して管理することが求められます。これにより、MFA（ワンタイムパスワード等）を人間が一度突破すれば、その後数日間はAIがログイン操作なしで業務を継続できるようになります。

2.2 CookieとlocalStorageの抽出と再注入

環境によってはプロファイルディレクトリ全体を保持するのが難しい場合があります（例：エフェメラルなDockerコンテナ環境）。その場合は、特定のドメインのCookieをJSON形式でエクスポートし、MCP実行時に addCookies メソッドで注入する手法が有効です。

このような認証情報の適切な管理は、複雑なSaaS連携において不可欠です。例えば、複数の会計ソフトやSaaSを跨ぐ自動化については、以下の記事で解説しているデータアーキテクチャの考え方が参考になります。

【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

2.3 ステートレスな環境（Docker等）でのセッション管理

コンテナ環境でMCPサーバーを動かす場合、ブラウザプロファイルをボリュームマウント（Persistent Volume）する必要があります。これを行わないと、コンテナが再起動するたびに認証が解除され、現場から「AIが動かなくなった」という問い合わせが頻発することになります。

3. CAPTCHAの壁をどう乗り越えるか：3つの戦略

セッションを維持していても、定期的な再ログイン時や機密性の高い操作（CSVの大量ダウンロード等）を行う際に、CAPTCHAが要求されることがあります。これには主に3つの対処戦略があります。

3.1 戦略1：人間による手動介入（Human-in-the-loop）

最も確実で安全な方法です。MCPサーバーがCAPTCHAを検知した場合、LLMが「画像認証が表示されました。手動で解除してください」とユーザーに通知し、ヘッドフル（画面あり）ブラウザでユーザーがクリックを行うのを待機します。

メリット： 規約違反のリスクがなく、確実性が高い。

デメリット： 完全な無人自動化ができない。

3.2 戦略2：ブラウザ指紋（Browser Fingerprinting）の偽装

playwright-extra や puppeteer-extra-plugin-stealth といったライブラリを使用し、ブラウザが「自動操作されていること」を隠蔽するフラグ（navigator.webdriver 等）を書き換えます。これにより、CAPTCHAが出現する確率自体を大幅に下げることが可能です。

3.3 戦略3：CAPTCHA回避APIの連携とその倫理的・法的リスク

2CaptchaやAnti-Captchaといった外部サービスへ、表示された画像をAPI経由で転送し、裏側で人やAIに解かせる手法です。しかし、多くのSaaS（例：Google、Salesforce等）の利用規約では、このような「認証の自動回避」を明示的に禁止しています。法人の実務担当者としては、アカウント凍結や法的措置のリスクを考慮し、原則として採用すべきではありません。

4. ツール別比較：ブラウザ操作MCPの実力の違い

現在、コミュニティで公開されている主要なブラウザ系MCP実装の特性をまとめました。自社の要件（セッション維持の必要性やOS制約）に合わせて選定してください。

特に、勤怠管理システムや経費精算システムの自動化においては、ブラウザベースの操作が不可欠になるシーンが多いです。例えば、以下の記事で解説しているような経理の自動化アーキテクチャにおいて、APIがないレガシーシステムとの橋渡しとしてブラウザ系MCPが活用されます。

楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャ

5. 法人利用におけるセキュリティと運用ガイドライン

AIにブラウザ操作を委ねることは、AIに「社内システムへのアクセス権限を丸ごと渡す」ことに等しく、慎重な設計が求められます。

5.1 多要素認証（MFA）への対応フロー

MFAを完全に自動化することは、セキュリティポリシー上、多くの企業で禁止されています。現実的なフローは以下の通りです。

1. 初回実行時：開発者または利用者がヘッドフルモードで起動し、ID/PWおよびMFAを手動入力。
2. セッション保存：userDataDir に認証済みCookieを保存。
3. 定期更新：Cookieの有効期限（通常30日〜90日）が切れる前に、リフレッシュ作業を実施。

5.2 認証情報の暗号化保存とアクセス制御

MCPサーバーをホストするマシン自体が攻撃を受けた場合、保存されたブラウザプロファイルは「認証済みセッションの宝庫」となります。以下の対策は必須です。

• プロファイルディレクトリのディスク暗号化。
• MCPサーバーを実行するユーザー権限の最小化（管理者権限での実行禁止）。
• 外部ネットワークからのMCPサーバーポートへの直接アクセスの遮断。

また、退職者が発生した際のアカウント管理も重要です。ブラウザプロファイル内に残ったセッションをどう無効化するか、ID管理システム（IdP）との連携を含めて検討すべきです。詳細は以下の記事が参考になります。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

5.3 利用規約（ToS）への準拠確認プロセス

自動化に着手する前に、対象SaaSの利用規約を必ず確認してください。「Scraping」「Automated Access」「Bot」といった単語で検索し、明示的に禁止されている場合は、MCPによる自動化は断念し、公式APIの利用やRPAツールの導入を検討すべきです。規約違反によるアカウント停止は、ビジネス継続性に重大な影響を及ぼします。

6. まとめ：安定したブラウザ自動化アーキテクチャの構築に向けて

PlaywrightやPuppeteerをベースとしたMCPサーバーは、Web操作の柔軟性を飛躍的に高めますが、「ログイン」と「認証」というWebセキュリティの根幹部分においては、依然として人間による適切な設計と管理が必要です。

まずは以下の3点から着手することをお勧めします。

• スモールスタート： ログインが不要な公開情報の収集から始め、MCPの挙動に慣れる。
• 環境の固定： userDataDir を活用し、セッションが維持される環境を構築する。
• 手動介入の許容： 全自動に固執せず、認証時は人間が介入するハイブリッドなフローを設計する。

AIエージェントが真に「同僚」として機能するためには、こうした地味ながらも堅牢なIT実務の積み重ねが欠かせません。