ブラウザ操作をMCPに任せるとワークフローはどう変わり、コードから何が消えるのか。役割分担の考え方、つまずきやすい4つの設定問題、問題発生時の切り分け順序を実践ベースで整理します。
Claude Codeでブラウザ自動化を書くと、最初につらくなるのがグルーコードです。ブラウザの起動、プロキシの設定、環境の作成、ハンドル待ちなどはビジネスロジックと関係がないのに、何度も書く必要があります。ブラウザ操作をMCP経由で外に任せると、この部分はほぼコードから消えます。やりたいことを説明すれば、どのツールを呼ぶかはモデルが判断します。
どう役割分担するか
Claude Codeはコマンドライン上のコーディングアシスタントで、ファイルの読み書き、コマンド実行、Git操作ができます。得意なのはコードとターミナル側の作業です。ブラウザを直接操作するのは得意分野ではなく、そもそも担当させる必要もありません。
MCPはまさにその部分を補います。ブラウザ自動化環境の機能をツール群としてまとめ、登録後はモデルから呼び出せるようにします。環境の一覧取得や作成、ブラウザの起動・停止、スクリーンショット、ページ内容の取得などです。一方がコードとログを担当し、もう一方がブラウザとページを担当する。境界が明確になるほど、問題の切り分けも楽になります。
ワークフローはどう変わるか
最も分かりやすい変化は、処理の流れを組み上げるまでが速くなることです。以前はフローを一度変えるだけでもスクリプトを修正していました。今はまず自然言語で試せます。現在の環境を一覧し、そのうち2つでログインしてスクリーンショットを取り、結果をまとめる。うまく動いてからスクリプトとして固定します。
実際のプロジェクトでは、通常3つの層を組み合わせます。MCPは自然言語の指示を受け持ち、探索や一時的な作業に向いています。ローカルHTTP APIは、一度に数十個の環境を作るような一括処理を受け持ち、安定していて再試行もしやすいです。特定の状態を待つ、ページ内の構造化データを取得するといった細かな操作は、CDPでブラウザに接続して行います。3つは競合するものではなく、それぞれ別の範囲を担当します。
環境レイヤーを独立して管理することも、この段階でようやく重要性が見えました。環境が各スクリプトに散らばっていると、タスクが増えたときに原因調査が難しくなります。現在は環境レベルのツールで作成、確認、一括回収を集中管理し、スクリプトは環境IDを1つ受け取って使うだけにしています。複数アカウントを扱う場合、PurpleMarkのような環境分離ソリューションがこの層を担い、各アカウントの環境、セッション、キャッシュを分離することで、実行レイヤーが安定してスケジュールできるようにします。
つまずきやすい4つのポイント
1つ目は、ツールが認識されないことです。多くのクライアントは起動時にしか設定を読み込まないため、登録後に再起動しないと反映されません。設定ファイルのパス間違いもよくあり、ツールごとに保存場所が異なります。単純ですが有効な切り分け方法は、サービスを手動で起動することです。起動できるなら設定側、起動できないなら環境側の問題と考えられます。
2つ目は認証失敗です。最も多いのは、認証情報をコピーしたときに余分な空白や改行が入っているケースです。まずそこを確認し、その次に環境変数の読み込み方を確認します。OSや起動方法によって結果が変わることがあります。
3つ目はローカルAPIが起動していないことです。この種のMCPサービスの多くは、クライアント本体が動いていることを前提にしています。クライアントが閉じていると、サービスが起動しなかったり接続がタイムアウトしたりします。ポートの競合にも注意が必要です。以前のプロセスが正常終了していないとポートを占有したままになることがあります。ポート番号はクライアント設定で確認できます。
4つ目は、並行タスク同士の干渉です。単独では正常に動くのに、同時実行するとデータが混ざったり、ログイン状態が上書きされたりします。原因の多くは、複数タスクが同じ環境を共有していることです。これはデバッグだけでは解決できません。1タスク1環境という制約を設け、環境の作成と回収は一括APIで行い、スクリプト内でその場しのぎに作らないようにします。
デバッグで意識していること
指示には待機条件を明確に書きます。「送信ボタンをクリックする」だけでは情報が足りません。「送信ボタンがクリック可能になるまで待ってからクリックする」と書くと、成功率が明らかに変わります。何をするかはモデルに判断させても、いつ待つかは人が明示する必要があります。
最初は読み取り専用のタスクで経路を確認します。環境の一覧取得、スクリーンショット、ページテキストの取得は副作用がありませんが、認証・ネットワーク・サービスの3点を一度に検証できます。経路が通っていない段階で、副作用のある操作を急いで実行しないことが大切です。
認証情報はコードに書かず、環境変数やローカル設定ファイルを使い、そのファイルは無視リストに追加します。チームメンバーが変わったら認証情報もローテーションします。ローカルAPI側の検証を無効にしている場合でも、少なくともローカルマシンだけで待ち受け、外部からアクセスできない状態にしておく必要があります。
最後に境界を確認しておきます。MCPがつなぐのは技術的な経路であり、プラットフォームのルールを変えるものではありません。統合がどれだけスムーズでも、そのタスクに適用される利用規約は引き続き守る必要があります。
