- MCP-B：ブラウザネイティブAI自動化プロトコル
- 従来の画面キャプチャやクリック方式ではなく、WebサイトのAPIに直接アクセスすることで、AIが1,000倍高速かつ高精度に自動化できるよう支援するブラウザコンテキストプロトコル
- 約50行のコードを追加するだけで、別途OAuthやAPIキー、複雑な設定なしに、サイト内の認証情報でそのままAI連携が可能
- ブラウザセッションと既存の認証システムを活用し、新たな認証や権限設定なしですぐに動作し、各WebアプリのAPIセキュリティポリシーをそのまま尊重
- 拡張機能を通じて、AIアシスタントが複数のタブやアプリを横断しながら直接データ参照・作業実行でき、従来の自動化と比べて性能（数ms以内で実行）と信頼性が圧倒的に向上
- 構造化されたAPIアクセスであるため、UI変更、スクリーンショットの誤り、複雑なセレクタ管理の問題から解放される。インストールも利用も非常に簡単
MCP-B概要
- MCP-B(Machine Context Protocol for Browsers) はブラウザ向けのモデルコンテキストプロトコルで、AIベースのターミナル自動化に似た方式でブラウザ環境を制御・操作するための標準を提供
- 本プロトコルはブラウザとAIエンジン間の通信を明確に規定し、多様な自動化やモデル間インタラクションを構造化
従来方式との違い
- 従来のブラウザ自動化：スクリーンショット解析、要素クリック、UI変更に弱く、遅く不安定（作業ごとに10〜20秒、コストは4〜5ドル）
- 既存のMCP方式：APIキーや複雑な認証が必要で、初期セットアップのハードルが高い
- MCP-B：ブラウザセッションを活用し、APIへ直接アクセス、複雑な認証や設定なしですぐに動作
コア原理と構造
- タブごとのMCPサーバー：各Webアプリが独自にTypeScriptベースのMCPサーバーを実行（メモリ内転送、既存のCookie/JWT認証を再利用）
- MCP-B拡張機能：Chrome/Edge/Firefox拡張機能（コンテンツスクリプトがタブサーバーと
postMessageで通信）で、すべてのタブのツール・APIを一元統合
- AIアシスタント連携：Native Bridgeおよび各種クライアント（Claude Desktop、Cursor IDE など）からMCP-Bを通じてブラウザ自動化が可能
利用・展開方法
- 開発者：1) パッケージをインストール 2) MCPサーバーコードを追加 3) デプロイ完了 → 別途APIキー、OAuth、複雑な設定は不要
- ユーザー：拡張機能をインストール後すぐに利用でき、AI設定だけで即座に自動化可能
実用上の利点
- 認証：既存Webサイトのログイン・セッション情報をそのまま使用し、OAuth 2.1や別途認証は不要
- 性能：APIの直接呼び出しによりms単位で作業完了（従来比10,000倍向上）
- セキュリティ：アプリケーション内部で動作し、既存のアクセス制御および権限ポリシーをそのまま順守
- 拡張性：複数のWebアプリ、タブ、AIツールをMCP-B経由で統合管理可能
- 設定：約50行のコードだけで自動化の準備が完了
比較まとめ
| 方式 |
認証と設定 |
動作方式 |
性能と信頼性 |
| 従来の自動化 |
複雑な認証、APIキー |
画面スクレイピング、クリック |
遅く不安定（10〜20秒） |
| 既存のMCP |
APIキー、OAuthが必要 |
APIアクセス |
導入ハードルが高い |
| MCP-B |
設定不要、ブラウザセッションを使用 |
APIを直接呼び出し |
ms単位、非常に高速かつ安定 |
結論：次世代のブラウザベースAI自動化
- MCP-Bはブラウザ環境に最適化されたAI自動化プロトコルで、認証・セキュリティ・拡張性・性能のあらゆる面で革新的
- 追加認証や複雑な設定なしに、ブラウザベースのAPI直接呼び出しだけで大規模なAI自動化を実現可能
- MITライセンス、コミュニティ主導、主要ブラウザをすべてサポート
2件のコメント
MCP-B技術の中核となるビジョンは、次のようなものだと考えられます。
「信頼できる媒介であるChrome拡張機能（Extension）を通じて、ブラウザがすでに安全に管理しているユーザー情報（Cookie、セッション、認証など）を活用し、
Webページ上で開発者があらかじめ定義しておいた『ツール（Tools）』をAIチャット画面から自然言語の命令で呼び出し、制御する。」
しかし私は「拡大する余地はなさそうだ」と感じており、その理由は次のとおりだと思います。
この技術が提供する利便性が、その懸念を上回るほど圧倒的でなければ、ユーザーはインストールをためらうでしょう。
この技術が広く採用されることで得られる利益が大きくなければ、開発者はあえて二重の労力をかけようとはしないでしょう。
このような複雑さは、企業が技術導入をためらう要因になります。
結論として、
MCP-Bのアイデア自体は技術的に非常に興味深く革新的ですが、ユーザーと開発者の双方にとって「なぜわざわざこの方式を使う必要があるのか？」という根本的な問いに対する明確な答えを示せていないように思います。既存のAPI方式と比べて得られる利点は不明確である一方、セキュリティ上の懸念と開発の複雑さという欠点は明確だからです。
したがって現時点では、この技術は一部のマニアや特定の目的を持つ開発者の間で実験的に使われることはあっても、Webエコシステム全体へ拡大していくには多くの困難があるように見えます。
Hacker Newsの意見
予想としては、RSSと同じ道をたどるだろう。企業はユーザーがデータの活用方法を自分でコントロールすることを嫌がる傾向がある
REST APIも同様で、かつては「API-first」設計の流れとともに、サービス自動化・連携の未来になると期待されていた。ところが企業は、こうした機能を提供すると自社の収益構造への脅威になるとすぐに気づき、あっという間に方向転換した。結局、あらゆる収益源はこうした権限をユーザーに持たせないことにあるのだと、改めて認識した
RSSは失敗したのではなく、むしろ大成功だったと思う。Google Readerがなくなった後も別のリーダーへ移行でき、20年以上にわたってRSSフィードは問題なく動作している。RSSに対応していないサイトにはほとんど出会ったことがない
ほとんどのWebサイトはいまでもRSSをサポートしており、ページ上に表示していなくてもデフォルトでフィードが存在する場合がある。全文を公開していないものもあるが、更新通知や自動化トリガーとして依然価値が高い。RSSはいまでも非常に有用に生き続けていて、まるで電子レンジのように、当たり前に存在するものになっている
市場構造に変化が起き、いまや大企業はコンテンツそのものより「インテリジェンスレイヤー」に注力している。コンテンツはますますコモディティ化している。Googleはユーザーの視線と関心、そして彼らを惹きつけるスマートな技術を握らなければ広告を売り続けられない。GoogleがRSSを望まなかったのは、RSSがGoogle Searchを迂回できたからだ
AIがまもなく人間のようにクリックやスクロールできるようになれば、再び果てしない競争が始まるだろう
Githubプロジェクトの貢献履歴が非常に興味深い（直接リンクを引用）。MiguelsPizzaが3回、Claudeが2回コミットしているが、Claudeのコード変更量がほぼ圧倒的だ
一時的に拡張機能を非公開にしつつgit履歴を調整したため、実際の履歴とは少し差がある。それでもClaudeのコードが全体の約85%を書いたのは事実だ
今後はこうしたパターン（巨大なAIベースのコード貢献）がますます増えていきそうだ
Claudeのコミットグラフは非常に独特だ。Claude Codeが直接コミットしているように見えるが、実際にはほとんどない。claudeプロフィールも参照
実際のコミット一覧を見ると、すべてMiguelsPizza / Alex Nahas名義になっている（リンク）。何か妙に見える
ブログからの抜粋に触れつつ、MCPの認証問題を扱っている。OAuth2.1は長期的に見ても悪くないが、ユーザーの代理で動くエージェント向けの認証を新たに再発明しなければならない状況だ。マルチテナントアプリ内でのデータ漏洩リスクはまだ解決されていない
モデルの被害範囲とアクセスできるデータを制限できることが、MCPの大きな利点かもしれない。マルチテナントアプリのクライアント側APIはすでにユーザースコープに制限されているはずなので、それだけをモデルに渡すなら被害は大きくないだろう。Amazon社内認証システムとOAuth2.1の互換性の問題にも触れられている（Amazonでは認証方式が異なる）
OAuth2.1の一部機能が、すでにRFC 8693の委任と詐称で扱われているのか気になる
モデルがアクセスできる範囲は結局ユーザーと同じなので、確実なセキュリティ実装はWebサイト管理者の責任だ
OAuthが適切に適用されていないAmazonの例は、本質的な問題ではないと思う。ユーザー権限の範囲を超えるバックドア的なアクセスは非常に危険だ。MCPアプリのすべての挙動がユーザーアクセスと同じカテゴリで記録されるなら、コンプライアンス上の問題が多くなり得る。この観点では非常に興味深いが、セキュリティ面では抜け道として問題の種になりそうだ
Swagger(OpenAPI)仕様を公開し、汎用のswagger mcpクライアントさえあれば、これらの実装の大半はほぼ置き換えられるのではないか、というアイデアが出ている。ユーザー自身に認証セッションを手動で開かせればよさそうだ。Claudeがプロンプト/設定からAPIキーをうまく把握し、swaggerベースのAPIクライアントを使えば同じではないか、という提案だ
MCP登場時に誰もが最初に思いついたやり方だ。しかし実際にはツールが多すぎて、うまく機能しないことが明らかになった。それでもこの分野では面白い試みが続いている
APIキーをプロンプトに入れないよう注意を促す声もある
Claude CodeはCLAUDE.mdにswagger.jsonのリンクを置くだけでもAPIテストが本当に便利になる
まず自分で試してみるよう勧めている
誰がターゲットユーザーなのかよく分からない。フロントエンドテストでは、UIが大きく変わればテストが壊れること自体がむしろ有用だ。そのほかの自動化目的なら、実際のAPIを提供するほうがよいと思う
「Home Depotでテーブルを作ろうとしたら、かえって大変だろう」という比喩に対し、Home Depotにも木材は山ほどあるのに、という点から疑問が呈されている
Home Depotではすでに完成したテーブルも売っている
Home Depotにはもっと良い精密工具はもちろん、専門家もいるので、むしろ作業が簡単になるかもしれない
「木材は自分で想像して作り出さなければならない」というニュアンスで冗談を言っている
指摘を受けて文言を修正したと述べている
MCPを実際に使ったことはないが、障害のある人の立場からすると、MCPはブラウザ・スマートフォン自動化におけるアクセシビリティ関連の用途が大きいように見える。ただし、この技術は悪意ある利用者に濫用される可能性があるため、実際に主要なWeb/アプリで導入されるのかは疑問だ。実際にアクセシビリティ改善に使われている事例があるのか気になる
MCP-Bがオープンソースとして公開されたことに感謝している。たいていのことはブラウザ内で起きるが、MCPはAIクライアントが作業する前提という点が少し異なる。根本的に、MCP-BがWebアプリのJS APIをLLMサーバーと直接つないで使うのとどう違うのか気になる。結局同じなのか、それともより大きな構想があるのかという質問だ
ホームページの内容だけではよく理解できず、Seleniumのブラウザ版のようなものかと考えて質問している
無料LLMユーザー向けにMCPでブラウザ自動化が始まれば、無料モデルにもCaptchaが要求される世界になるだろうと予想している。問題はCaptchaがLLMにあまり効果的ではないため、最終的にはLLMたちが自動化LLMのアクセスを止めるために互いに戦う、奇妙なロボット戦争の時代が来るかもしれないということだ