MCP Serverをブラウザ自動化環境へ接続する際の、バージョン確認、認証情報の管理、サービス登録、接続確認までの流れを整理し、ツール一覧が空、認証失敗、接続タイムアウトといった問題を切り分ける順序も解説します。
MCP（Model Context Protocol）を使うと、AIアシスタントがブラウザ操作のたびに手書きコードを必要とせず、必要なツールを順番に呼び出してタスクを完了できます。
実際の接続でつまずきやすいのは、プロトコルそのものより、何をインストールするか、どこへ接続するか、認証情報をどう渡すか、接続できたことをどう確認するかです。この4点を順に確認すれば、多くの問題は設定段階で見つけられます。
まず3つを確認する
1つ目は、ローカルインターフェースを提供するブラウザ自動化環境のクライアントです。ローカルAPIに対応したバージョンである必要があります。古いバージョンではインターフェース自体が存在せず、見た目上はツール一覧が空になるだけということがあります。2つ目はNode.js 18以上です。MCP Serverの多くはTypeScriptで実装され、Nodeランタイムを必要とします。3つ目はMCPに対応したAIツールです。
最初にクライアントのバージョンを確認するのがおすすめです。接続できない、ツール一覧が空といったエラーのかなりの割合は、サーバーではなく古いバージョンが原因です。
どこへ接続するか
クライアントを起動すると、ローカルマシン上でAPIサービスが立ち上がり、ループバックアドレスを待ち受けます。ポートはクライアントのインターフェース設定で確認・変更できます。ポートが使用中なら別のポートに変更し、クライアントを再起動します。
MCP Serverはこのローカルアドレスを通じて環境へアクセスするため、通信はパブリックインターネットを経由しません。逆に、このサービスはローカルだけに置き、外部へ公開しないことが重要です。
認証情報をどう渡すか
クライアント設定でAPI Keyを生成します。実装によってはIDとKeyの2要素を使います。この認証情報は実質的にアカウント配下のすべての環境を操作できる権限に相当し、取得した人は環境の起動、変更、削除を行える可能性があります。
基本的な対策は省かないでください。認証情報をコードリポジトリへコミットせず、環境変数またはローカル設定ファイルで管理し、そのファイルをignore対象に加えます。メンバー変更後はすぐに認証情報をローテーションします。用途ごとに別の認証情報を発行できるなら分けておくと、問題の特定や個別の失効がしやすくなります。AIツールの設定では、endpointと認証情報の両方を環境変数で渡し、履歴に残りやすいコマンドラインへ直接書き込まないようにします。
サービスを登録する
登録は通常、AIツールの設定ファイルにサービス定義を追加します。内容は3つです。起動方法、つまりコマンドまたはエントリーファイルのパス、ローカルendpointと認証情報を入れる環境変数、そしてツール一覧に表示される名前となるサービス識別子です。
登録後はAIツールを再起動してください。多くのツールは起動時に一度だけ設定を読み込むため、変更後に再起動しなければ、実質的に変更していないのと同じです。
本当に接続できたか確認する
2段階で確認し、順序を入れ替えないでください。
まずツール一覧を確認します。ブラウザ関連のツールが表示されれば、サービスが認識されたことを確認できます。次に、現在の環境をすべて一覧表示するなど、読み取り専用のタスクを実行します。読み取り専用操作には副作用がありませんが、認証、ネットワーク、サービスの3層を一度に確認できます。ここで失敗するなら、その先のタスクを試す必要はまだありません。
接続後にできること
サービスが通れば、AIアシスタントは一般に、環境の照会と検索、環境の作成と基本パラメータ設定、環境の起動と停止、ネットワーク出口の割り当て、さらにページ内のナビゲーション、クリック、入力、スクリーンショットといった操作を実行できます。
呼び出しは自然言語で行います。目的を伝えると、アシスタントがどのツールをどの順番で使うかを決めます。ここで混同しやすいのは、AIが「何をするか」を決め、環境レイヤーが「どのIDで実行するか」を決めるという違いです。両者を分けて考えると、問題発生時にどのレイヤーを調べるべきか判断しやすくなります。
接続できないときの切り分け順序
ツール一覧が空なら、まず設定ファイルのパスが正しいか確認し、次にAIツールを再起動したか確認し、最後にサービスを手動で起動して単独で立ち上がるか試します。この3つのどこかで失敗しているうちは、プロトコルを疑う段階ではありません。
認証失敗の原因は通常2つです。Keyのコピー時に余分な文字や改行が入ったか、環境変数が正しく読み込まれていないかです。設定を何度も変更するより、Keyをコピーし直す方が早いことがあります。
接続タイムアウトは多くの場合、ローカル側を示します。クライアントが動いているか、ポートが使用中またはファイアウォールで遮断されていないか確認します。多くのMCP Serverはクライアントが起動したままであることを前提としており、クライアントを終了するとツールを呼び出せなくなります。
サービスには接続できるのに操作が正しく実行されない場合、待機タイミングが原因であることが多いです。ページの読み込み完了をAIに推測させるのではなく、どの状態になるまで待ってから次へ進むかを指示に明記します。
もう1つ事前に気づきにくいのが、複数タスクで同じ環境を共有する問題です。セッション、Cookies、キャッシュが互いに上書きされ、タスク同士が干渉し始めると、明確なエラーではなくランダムな失敗に見えます。タスクごとに独立した環境を割り当て、一括作成と回収を環境レイヤーに任せる方が安定します。PurpleMarkの環境分離と集中管理はこのレイヤーにあり、MCP接続後もタスクのオーケストレーションとID管理は別の役割です。
追加で注意したい2点
自動化フレームワークがブラウザを制御する場合、driverのバージョンをクライアントが使用するエンジンのバージョンに合わせる必要があります。クライアントは通常、利用可能なdriver pathを返しますが、それでもバージョンが合わないことがあります。バージョン管理ツールでdriverを自動同期する方が簡単なことが多く、ページのendpointは引き続きクライアントが返した値を使えます。この2つは競合しません。
もう1つは並列実行です。ブラウザプロセス1つで約300～500MBのメモリを使用するため、同じマシンで同時に起動する環境は5個以下が推奨です。これを超えると起動失敗やプロセスのクラッシュが発生する場合があります。ページ操作でも固定時間の待機は避け、ページ読み込みのtimeoutを30秒、要素は明示的待機で最大20秒にします。sleepより安定します。
1つの境界
MCPが解決するのは、AIがブラウザをどう操作するかという技術的な問題です。各プラットフォームのルールを変えるものではありません。タスク自体は引き続き対象プラットフォームの利用規約に従う必要があり、技術的に可能かどうかと、ルール上許可されているかどうかは別の判断です。
プロトコルやインターフェースの詳細は公式ドキュメントを確認し、実行前に予定しているタスクが対象プラットフォームで許可されていることを確認してください。
