Claude CodeのMCPの使い方｜ブラウザ連携で起きた4つの事故【2026年版】
目次
Claude Codeは、手元のファイルを読んで書くだけなら最初から得意です。ところが営業・マーケの仕事は、ファイルの外にあります。メールはGmailに、数字は分析ツールに、記事は投稿サービスに。そこに手を伸ばす接続口がMCP（Model Context Protocol）です。
繋ぐこと自体は数分で終わります。難しいのは、繋いだ後です。当社は営業・マーケの定型業務をClaude Codeの定時タスクで回していて、ブラウザ操作のMCPを毎日使っています。その運用で、「繋がっているのに、違う相手に繋がっていた」という種類の事故を4回踏みました。
この記事は、MCPの基本と、繋ぐ前に決めておくべき3つ、そして実際に起きた4つの事故と直し方の記録です。
この記事の要点
- MCPは、Claude Codeに外部サービスを操作する「手」を足す接続口。繋ぐより、繋いだ先が正しいかを確かめる方が難しい
- 繋ぐ前に決めるのは3つ。どの身元で操作するか／何をMCPに任せ、何をAPIや画面操作に回すか／人が画面を見ている間どう振る舞うか
- 当社の事故4件は、どれも「接続は成功しているのに、違う窓・違う人格に繋がっていた」型。エラーが出ないので気づきにくい
- 接続先は名前や番号ではなく、開いた先のページの中身（ログイン中のアカウント）で毎回確かめると事故が止まった
- MCPが落ちた日に作業が全部止まらないよう、代わりの経路を1本持っておく。当社は持っていなかった日に5枠が空振りした
MCPとは｜Claude Codeに「手」を足す接続口
結論：MCPは、Claude Codeが外部のサービスを読む・操作するための共通の差し込み口です。 サービスごとの「MCPサーバー」を繋ぐと、Claude Codeが使える道具（ツール）が増えます。ブラウザを操作する、ドキュメントを読む、といった操作を、会話の中から呼べるようになります。
ただし、外部に手を伸ばす方法はMCPだけではありません。当社は3つを使い分けています。
| 方法 | 向いている作業 | 弱いところ |
|---|---|---|
| MCP（ブラウザ連携など） | ログイン済みの画面でしかできない操作。画面を見て判断が要るもの | 接続先の取り違えが起きる。接続が落ちると止まる |
| API（サービスの公式の窓口） | 決まった形のデータの読み書き。件数が多いもの | 用意されていない操作はできない。利用規約と料金の確認が要る |
| 画面の裏の処理を直接呼ぶ（ブラウザ内で実行） | 画面のボタンを1つずつ押すと遅いもの | サービス側の変更で壊れる。使ってよい範囲の確認が要る |
体感ではなく実例で言うと、記事サービスの「スキ」を返す作業は、画面のボタンを押す方式だと1件ごとに画面の写真を撮って位置を確かめる必要がありました。ページの裏で動いている処理を呼ぶ方式に変えてからは、30件を画面写真0枚で処理できています（2026年8月6日の実証）。MCPは万能の入口ではなく、画面でしかできないことのための道具と位置づけると、使いどころを間違えにくくなります。
繋ぐ前に決める3つ
結論：MCPを繋ぐ前に「誰として・何を・人が見ている間どうするか」の3つを文章にしておくと、事故の大半は防げます。 当社の事故は、どれもこの3つのどれかを決めないまま繋いだところから起きています。
| 決めること | 決めないと起きること | 当社の決め方 |
|---|---|---|
| ① どの身元（アカウント）で操作するか | 別事業・個人用のアカウントで送信や保存をしてしまう | ブラウザのプロファイルごとに用途を固定。判定はログイン中のGoogleアカウントで行う |
| ② 何をMCPに任せ、何を他の方法に回すか | 全部を画面操作にして遅く・壊れやすくなる | 件数が多い読み書きはAPIや裏の処理へ。画面でしか判断できない操作だけMCP |
| ③ 人が画面を見ている間どう振る舞うか | 仕事中の画面を急に持っていかれる | タブの中で完結させ、画面を前に出す操作は「人が触っていない時だけ」に限る |
①は特に大事です。ブラウザを複数のアカウントで使い分けている会社では、MCPが繋がった窓＝正しい窓とは限りません。ここを名前や番号で決めると、次の章の事故がそのまま起きます。
実際に起きた4つの事故｜どれもエラーが出なかった
結論：4件とも「接続は成功しているのに、違う相手に繋がっていた」事故です。 エラーで止まってくれればすぐ気づけますが、この型は途中まで正常に動くので、気づくのが遅れます。
| 日付 | 何が起きたか | 本当の原因 | 直し方 |
|---|---|---|---|
| 2026-09-04 | 記事の公開タスクが止まった | MCPが繋がっていたのが、別の人格のブラウザだった | 接続先を、ログイン中のGoogleアカウントで判定する |
| 2026-09-14夜〜15朝 | 定時タスク4本が連続で中断 | 同じ会社の中で、SNS用とGoogle用の窓が別プロファイルに分かれていた | 「会社」ではなく「用途」で接続先を引く |
| 2026-10-04 | 午前の定時タスク5本が「未接続」で落ちた | アプリ側のログインアカウントが切り替わり、拡張が一覧から消えていた | 原因を機械で切り分け、代わりの経路で作業を続ける |
| 2026-10-24 | 作業中の画面を、定時タスクが持っていった | 新しいタブを開くだけで、その窓が最前面に上がっていた | 新規タブは背面で開き、元の窓に戻す |
事故1：SNSのアカウント名だけ見ると、別人格の窓が合格した
記事の公開タスクが、投稿サービスのアカウントがずれていて止まりました。調べると、MCPが繋がっていたのは別の用途で使っているブラウザでした。厄介だったのは、その窓でもSNSのアカウント名は正しく表示されていたことです。アカウント名で確かめる方式だと合格してしまう。
直し方は、判定の物差しを変えることでした。ブラウザのプロファイルは1つの人格なので、ログイン中のGoogleアカウントをその窓の正体として最初に確かめる。番号や「Browser 1」のような表示名は、再接続のたびに変わることがあるので判定に使いません。
事故2：同じ会社の窓でも、用途で2枚に分かれていた
事故1の対策で「Googleアカウントが自社なら合格」にした後、今度はSNSの操作だけが連続で中断しました。夜から翌朝にかけて4本です。実測すると、自社のGoogleにログインしている窓と、SNSにログインしている窓が、別のプロファイルに分かれていました。会社単位で接続先を引くと、必ずSNS未ログインの側を掴む構造です。
そこで接続先の呼び名を、会社名ではなく用途（SNS用／Google用）にしました。さらに9月18日には、閉じたプロファイルが候補の先頭に残っていて昼の予約投稿が落ちたため、いまChromeで開いているプロファイルを優先するように直しています。
事故3：「未接続」の真因は、ブラウザではなくアプリ側にあった
「最近たまに未接続と出る」という状態が続き、10月4日には午前のタスク5本がまとめて落ちました。最初はブラウザを疑いましたが、真因はClaudeのアプリ側のログインアカウントの切り替えでした。ブラウザ連携の接続一覧には、アプリと同じアカウントでサインインしている拡張しか出ません。記録を見ると、9月7日〜10月4日の間にアプリ側のアカウントが80回を超えて行き来していて、そのたびに片側の拡張が一覧から消えていました。
ここから決めたのは2つです。原因を「アカウント不一致」「拡張が落ちている」「プロファイルが起動していない」に機械で切り分けること。そして、人が直すべきもの（アプリのログインし直し）と、AI側で続けられるもの（別経路での作業）を分けることです。
事故4：新しいタブを開くだけで、画面を持っていった
人がブラウザで仕事をしている最中に、定時タスクが画面を切り替えてしまう。前に出す命令は書いていなかったので、最初は原因が分かりませんでした。実測で分かったのは、新しいタブを作るだけで、その窓が最前面に上がることです（2026年10月24日）。
いまは、人がブラウザを見ている間は新しいタブを背面で開き、同じ処理の中で元の窓・元のタブに戻しています。ファイルを選ぶ画面など、どうしても前に出す必要がある作業だけは「人の最後の操作から120秒以上たっている時だけ」に限り、終わったら元のアプリへ戻します。直近7日の記録は97件で、背面で開いて元に戻した80回・前に出した14回・人が操作中だったので見送った3回でした。全部記録しているので、「持っていかれた」と感じた時に、どのタスクがいつ何をしたかを後から突き止められます。
ブラウザの切り替え操作そのものを機械で止めた話は、Claude Codeのフック（hooks）の使い方に書いています。
「MCPでブラウザを全部操作すればいいのでは？」への答え
結論：全部をMCPに寄せると、MCPが落ちた日に全部が止まります。 これは当社が実際にやってしまった失敗です。
9月17日、ブラウザ連携の拡張の接続が落ち、SNSへの返信タスクが3枠、朝の返信タスクが2枠、合わせて5枠が空振りしました。タスクは「拡張の接続ボタンを押してください」と人に頼んで止まるだけで、ログイン自体は生きていたのに作業が進まなかった。代わりの経路が1本もなかったからです。
翌日までに、MCPを通さずにログイン済みの窓を探して操作する経路を用意し、「拡張が未接続」は人の作業ではなくAI側が経路を切り替えて続けるもの、と決め直しました。ここから読者が使える教訓は1つです。
- MCPは「一番便利な経路」にして、「唯一の経路」にしない
- 落ちた時に人へ戻す作業は、パスワード入力やログインし直しのような人にしかできないものだけに絞る
- 「接続を押してください」で止まるタスクは、止まった回数を数えておく。数えると、代わりの経路を作る価値が見える
非エンジニアがMCPを始める順番
結論：最初は「読むだけ」の接続から始め、書き込みや送信は接続先の確かめ方が決まってから足します。
- 読むだけのMCPを1つ繋ぐ。 ドキュメントや分析画面を読むなど、間違っても外に出ないもの
- 接続先の確かめ方を決める。 開いた先でログイン中のアカウントを毎回確かめる1行を、手順に入れる
- 書き込み・保存を足す。 下書き保存のように、人が後で確認できる操作から
- 代わりの経路を1本用意する。 MCPが落ちた日でも、少なくとも状況を記録して安全に止まれるように
- 送信・公開は最後。 ここまでの段階で事故が出た型を、全部機械で止められるようになってから
当社が一連の運用を組むまでの事故の全体像は、Claude Codeは危険か｜実際に起きた4つの事故と、機械で止める設計にまとめています。定時で回す場合の前提条件の違いは、Claude Codeのスケジュール実行が参考になります。自社の業務のどこまでをMCPに任せるかを一緒に決める支援は、月額24万円〜のClaude Code導入支援で行っています。
よくある質問
Q. Claude CodeのMCPとは何ですか？
Claude Codeに外部のサービスやブラウザを操作する道具を足すための、共通の接続口です。サービスごとのMCPサーバーを繋ぐと、会話の中からそのサービスの読み書きができるようになります。手元のファイルの外にある仕事に手を伸ばすための仕組みです。
Q. MCPとAPIはどう使い分ければいいですか？
件数が多く、形の決まった読み書きはAPI（または画面の裏の処理）に回し、ログイン済みの画面でしか判断・操作できないものだけをMCPに任せるのがおすすめです。当社では、画面のボタンを1件ずつ押していた作業を裏の処理に変えて、30件を画面写真0枚で済ませた例があります。
Q. ブラウザを複数のアカウントで使い分けていても大丈夫ですか？
使えますが、接続先の取り違えが一番起きやすい環境です。当社はこの環境で4つの事故を踏みました。接続先は名前や番号ではなく、開いた先でログイン中のアカウントを毎回確かめる方式にすると止まります。用途ごとに窓が分かれている場合は、用途の名前で接続先を引きます。
Q. MCPが「未接続」になるのはなぜですか？
当社の場合、真因はブラウザではなく、アプリ側のログインアカウントの切り替えでした。拡張とアプリが同じアカウントでないと接続一覧に出ません。原因は「アカウント不一致」「拡張が落ちている」「プロファイルが起動していない」のどれかに分けて確かめると早く特定できます。
Q. 定時タスクでMCPを使うと、仕事中の画面を奪われませんか？
何もしないと奪われることがあります。当社では新しいタブを作るだけで窓が最前面に上がりました。新規タブは背面で開いて元の窓に戻し、前に出す必要がある作業は人が触っていない時だけに限る、という運用で防いでいます。
---
執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）
自社の営業・マーケ業務をClaude Codeで運用しており、本記事の日付・件数・事故の記録はすべて自社の運用記録（ブラウザ割当の台帳・改善記録・画面操作の記録ファイル）に基づいています。