Brave／Chrome 拡張と MCP の違い｜業務システムのスクレイピングは契約違反になり得る（法務視点）

業務効率化の現場において、「ブラウザ上の作業を自動化したい」というニーズは絶えません。特にAPIが公開されていないレガシーな業務システムや、特定のSaaSからデータを抽出する際、これまではBraveやChromeの拡張機能（Extension）を用いたフロントエンドの自動化が主流でした。

しかし、2024年以降、Anthropic社が提唱したMCP（Model Context Protocol）の登場により、AIと外部データの連携のあり方が劇的に変化しています。その一方で、技術的な「できる・できない」の議論の陰に隠れがちなのが、「スクレイピングの法的・契約的リスク」です。

本記事では、IT実務者の視点からブラウザ拡張とMCPの違いを詳解しつつ、法務的な観点から「やってはいけない自動化」の境界線を明確にします。

1. 業務自動化の新たな選択肢：Brave/Chrome拡張とMCP

まず、私たちが業務で利用する「ブラウザ拡張」と、新規格である「MCP」が、それぞれどのような役割を担うのかを整理します。

1.1 ブラウザ拡張機能による「フロントエンド自動化」の現在

ChromeやBraveなどのChromium系ブラウザで動作する拡張機能は、DOM（Document Object Model）に直接アクセスできるため、描画されているテキストの取得やボタンの自動クリックが可能です。これは、APIが提供されていないシステムに対する「最後の手段」として重宝されてきました。

しかし、ブラウザ拡張による自動化には以下の実務的課題があります。

• UI変更に弱い: システムのボタン配置やIDが1つ変わるだけでスクリプトが破損する。
• メンテナンス負荷: 複数人のPCにインストールされた拡張機能のバージョン管理が困難。
• セキュリティ: ブラウザの全データにアクセス権限を持つ拡張機能は、サプライチェーン攻撃の標的になりやすい。

1.2 MCP（Model Context Protocol）がもたらす「AI駆動型」データ連携

MCPは、AIモデル（Claudeなど）がローカルまたはリモートのデータソースに安全にアクセスするためのオープンな標準規格です。従来のブラウザ拡張が「ブラウザの中」で完結するのに対し、MCPは「AIとデータの仲介役（サーバー）」として機能します。

公式サイト（modelcontextprotocol.io）のドキュメントによれば、MCPサーバーを介することで、データベース、Google Drive、GitHub、あるいはローカルのファイル群を、AIが直接読み書きできるようになります。

1.3 両者の決定的な違い：操作の主体とデータの流れ

ブラウザ拡張は「人間が行うブラウザ操作の模倣」が主目的ですが、MCPは「AIがコンテキスト（文脈）を理解するためのデータ提供」が主目的です。業務自動化においては、単なるコピペ作業なら拡張機能、データの背景を読み取った高度な処理ならMCPという棲み分けが進んでいます。

2. 実務における「技術選定」の比較表

APIがない状況で、どのような手法を採択すべきか。実務で検討される主な手法を比較しました。

高度なデータ連携を検討する場合、単なる画面の自動操作ではなく、バックエンドでの統合が推奨されます。例えば、BigQueryやリバースETLを用いたデータ基盤構築は、MCPのようなAI連携とも親和性が高く、メンテナンス性の高い構成と言えます。

3. 【法務視点】業務システムのスクレイピングに潜む契約リスク

技術的に「拡張機能でデータが抜ける」ことと、それが「法的に許される」ことは別問題です。特にB2BのSaaSや業務システムにおいて、スクレイピングは重大な契約違反となるケースが大半です。

3.1 「API未提供＝スクレイピングOK」ではない

多くのエンジニアが陥る誤解が、「公式APIがないのだから、画面から取得するしかない。これは正当な手段だ」という思考です。しかし、法的な判断基準は「技術の有無」ではなく「サービスの利用規約（Terms of Service）」にあります。

3.2 利用規約（ToS）における「自動化禁止条項」の解釈

大手のSaaS（Salesforce, freee, Sansan等）の規約には、ほぼ例外なく以下のような条項が含まれています。

「本サービスに関し、ロボット、スパイダー、その他の自動デバイス、プロセス、手法を用いて、本サービスの一部にアクセス、取得、コピーまたは監視する行為を禁止します。」

この条項がある場合、ブラウザ拡張機能やPythonスクリプトによるスクレイピングは、それ自体が明確な契約違反となります。違反が発覚した場合、アカウントの即時停止や、損害賠償請求の対象となるリスクがあります。

3.3 不法行為・偽計業務妨害罪に問われるケース

契約違反に留まらず、刑事罰や不法行為責任が問われる境界線は「サーバー負荷」と「著作権」です。

• 偽計業務妨害罪: 短時間に大量のリクエストを送り、システムの安定稼働を阻害した場合。
• 著作権法違反: 取得したデータに創作性（データベースの著作物等）が認められ、それを自社サーバーに蓄積して利用した場合。

特に経理や人事などのバックオフィス系システムでは、データの正確性と機密性が重視されるため、非公式な手段でのデータ取得は厳しく制限されています。例えば、freee会計のようなクラウド会計ソフトでは、公式APIが非常に充実しており、規約を遵守しながら自動化を進める環境が整っています。あえてリスクを冒してスクレイピングを選択する正当性は、実務上ほぼ存在しません。

4. 規約違反を回避し「安全に」システム連携を実現するアーキテクチャ

では、どのようにして安全に自動化を実現すべきでしょうか。推奨される優先順位は以下の通りです。

4.1 公式APIとWebhooksを優先すべき理由

最も安全かつ堅牢なのは、メーカーが提供する公式APIの利用です。APIは「規約で認められたデータ取得経路」であり、仕様変更時の通知や、レートリミット（流量制限）による保護が担保されています。

4.2 APIがない場合の次善策：CSVエクスポートとRPAの境界線

どうしてもAPIがない場合、手動またはシステム標準機能による「CSVエクスポート」を行い、そのファイルをプログラムで処理するのが最もクリーンな手法です。このプロセスをRPAで自動化する場合も、規約上の「自動操作の禁止」に触れないか、メーカーの公式見解を確認する必要があります。

4.3 MCPを活用したセキュアなローカルデータ連携

MCPの利点は、「クラウドにデータを送らずにAIを活用できる」点にあります。例えば、社内DBやローカルのExcelファイルをMCPサーバー経由でClaudeに読み込ませる場合、外部のスクレイピングとは異なり、自社管理下でのデータ処理となります。

もしSaaSコストやオンプレミスの負債を抱えている状況であれば、無理な自動化を重ねる前に、SaaSコストとオンプレミス負債の整理を行い、API連携が可能なモダンな構成へ移行することを検討すべきです。

5. ステップバイステップ：MCPによる安全なデータ統合の手順

ここでは、注目されているMCPを用いて、安全に業務データをAIと連携させるための実務手順を解説します。

5.1 ステップ1：データソースの特定とアクセス権限の整理

まず、AIに読み取らせたいデータが「どこに」「どのような形式で」存在するかを確認します。MCPでは、特定のディレクトリやデータベースへのパスを指定してサーバーを起動します。この際、読み取り専用（Read-Only）の権限を付与したユーザーで接続することが、セキュリティ上の鉄則です。

5.2 ステップ2：MCPサーバーの構築（Claude Desktop等との連携）

具体的な実装例として、公式のNode.js SDK等を用いて、ローカルのSQLiteデータベースを読み取るMCPサーバーを立てる手順は以下の通りです。

1. Node.js環境の構築。
2. @modelcontextprotocol/sdk のインストール。
3. リソース（データの定義）とツール（データの処理）を実装。
4. Claude Desktopの構成ファイル（claude_desktop_config.json）にサーバー情報を登録。

※詳細な実装仕様は、Anthropicの公式ドキュメントを参照してください。

5.3 ステップ3：エラーハンドリングとレートリミットの設計

自動化においてよくあるエラーは、「データ形式の不一致」と「接続タイムアウト」です。MCP経由でAIがリクエストを送る際も、一度に大量のデータを流し込むと、AIのコンテキストウィンドウ（入力上限）を超過し、精度が著しく低下します。必要なデータだけを抽出する「フィルタリング機能」をサーバー側に持たせることが重要です。

6. まとめ：持続可能な自動化は「規約の遵守」から始まる

Brave/Chrome拡張機能による強引なスクレイピングは、短期的には便利かもしれませんが、法的な契約リスクとメンテナンスコストの増大という「技術的負債」を抱えることになります。

一方で、MCP（Model Context Protocol）は、AIがデータを安全に扱うための標準化を進めており、今後の業務DXにおいて中心的な役割を果たすことが予想されます。APIが提供されているシステムであれば公式連携を、そうでない場合は規約を遵守した形でのデータ抽出とMCPサーバーの活用。これが、2026年現在のIT実務担当者が取るべき最適解です。

「とりあえず動く」自動化ではなく、5年後も安定して稼働し続ける、クリーンなシステム構成を目指しましょう。