MCP時代のRPAはどこまで安全か？ ― APIを使え、という現実

MCP時代のRPAは安全か？ ― APIを使え、という現実 TECH

MCPやPlaywright、RPAはそれ自体が危険な道具ではない。だが、SaaSの世界では「どの入口から連携するか」は技術ではなく契約で決まっている。APIを避けてUIを叩いた瞬間、話は一気にビジネスと契約の問題になる。MCP時代に善良な実務者が踏みがちな地雷と、安全に使うための現実的な指針を整理する。

導入：なぜこの話をするのか

MCP（Model Context Protocol）によって、AIが外部ツールやシステムを“普通に”扱える時代が来た。
ファイル、データベース、API、場合によってはブラウザ操作まで、すべてが一つの文脈でつながる。これは間違いなく便利だし、実務へのインパクトも大きい。

その流れで、Playwright や各種 RPA ツールを組み合わせて、

  • 「毎月の定型作業を自動化したい」
  • 「管理画面からレポートを取って要約させたい」
  • 「人がやっている操作を、そのままAIに任せたい」

そう考えるのは、ごく自然な発想だ。

一方で、どこかにこんな不安もあるはずだ。

これ、普通に使っていても法的にまずいことにならない？
知らないうちに地雷を踏んだりしない？

結論から言うと、MCPやRPAを使っただけで、いきなり「御用」になる世界ではない。
ただし、話はそこで終わらない。問題になるのは技術そのものではなく、「どの境界線を越えるか」だ。

この記事では、

  • Playwright や RPA は何が問題になりうるのか
  • なぜ SaaS は API を用意し、UI 自動化を嫌がるのか
  • MCP 時代に、実務者がどこを意識しておくべきか

このあたりを、法律に踏み込みすぎず、実務の感覚で整理していく。

怖がらせるための記事ではない。
「便利に使い続けるために、どこを見ておけばいいか」の地図を描くのが目的だ。

第1章：PlaywrightやRPAは“危ない道具”なのか？

まずは、よくある誤解から片付けておこう。

Playwright や Selenium、各種 RPA ツールは、技術的にはただのブラウザ自動操作だ。
人間がマウスでクリックし、キーボードで入力し、画面を遷移する。その操作を、プログラムが代わりにやっているだけに過ぎない。

  • 不正侵入ツールでもない
  • マルウェアでもない
  • ハッキングツールでもない

やっていることは、極端に言えば「超高速でミスしないオペレーター」を雇っているのと同じだ。

MCP も同様で、これは AI にツールやデータソースをつなぐための“配線規格”に近い。
MCP が危ないのではなく、MCP 経由で何をさせるかが問題になる。

ここで重要なのは、過去に問題になってきた事例の多くが、

  • ツールそのものが違法だった
    のではなく、
  • そのツールを使って「何をしたか」が問題にされた

という点だ。

たとえば、

  • 認証を突破した
  • 他人のアカウントに侵入した
  • サービスを妨害するレベルでアクセスした
  • データを無断で再配布・再販売した

こういう行為は、人間が手作業でやってもアウトだ。
自動化ツールを使ったから問題になる、という話ではない。

逆に言えば、

  • 自分の権限でログインし
  • 普段人間がやっている操作を
  • 自分の業務のために自動化する

この範囲に収まっている限り、それだけで即アウトになる世界ではない。

では、なぜ Playwright や RPA に「グレーなイメージ」がまとわりつくのか。
それは次の章で触れる SaaS と API と契約の話が関係してくる。

第2章：SaaSがAPIを用意している“本当の理由”

多くのSaaSは、最初から API を用意している。
しかも、たいていの場合その API は、

  • 利用量に応じて課金されたり
  • レート制限があったり
  • プランによって使える範囲が決まっていたり

する。

一方で、管理画面（UI）のほうは、当然ながら人間向けに作られている。
ボタンがあり、フォームがあり、ページが遷移する。
Playwright や RPA を使えば、ここを機械に操作させることも技術的には簡単にできる。

では、なぜ多くの SaaS は規約で

ボット、クローラー、自動化ツールによるアクセスを禁止する

といった条項を入れるのか。

これは道徳の話ではない。ビジネスと運用の話だ。

まず、API は「正式な入口」として設計されている。

  • 課金モデルを組み込める
  • レート制限で負荷をコントロールできる
  • セキュリティや監査の前提を置ける
  • 仕様変更時の互換性ポリシーも管理できる

つまり、サービス提供者が“責任を持てる範囲”のインターフェースが API だ。

一方、UI は違う。

  • 内部仕様に近い
  • いつ変えてもおかしくない
  • 人間の操作を前提にしている
  • 自動化前提の負荷設計になっていないことも多い

ここを RPA や Playwright で叩かれると、サービス提供者から見れば、

料金も制御も前提も違う経路で、機械的にアクセスされている

という状態になる。

そして、ここが一番重要なポイントだ。

API が有料で提供されている場合、
UI 自動化でそれを回避する行為は、ビジネスモデルを迂回している と評価されうる。

これはもう「技術の話」ではない。
「サービス提供者に損害を与えているかどうか」という民事の構成の話になる。

  • 本来、API 利用料を払う前提のユースケースを
  • UI 自動化でタダ乗りしている
  • しかも機械的に大量処理できる

こうなると、

自動化そのものが悪い、という話ではなく、
“正規ルートを避けて利益を得ている”構図が問題になる

という整理になる。

だからこそ、多くの SaaS は規約で、

  • UI への自動アクセスを禁止し
  • API を正規の連携手段として指定する

という設計を取る。

ここで押さえておきたいのは、次の点だ。

  • RPA や Playwright は「ズルい裏口ツール」ではない
  • しかし API が用意されている世界では、UI は“非正規ルート”になりやすい
  • そして、その非正規ルートで商用スケールの自動化を始めると、
    話は一気に「契約」と「損害」の世界に入る

この構図を理解しておくと、
「なぜ SaaS は Bot を嫌がるのか」が、かなり現実的に見えてくるはずだ。

次の章では、実際に “Bot 禁止”を明示している SaaS の世界がどうなっているかを、もう少し具体的な話として整理していく。

第3章：実際に“Bot禁止”を明記しているSaaSの世界

「SaaSはAPIを正規ルートにして、UI自動化を嫌がる」と言っても、抽象論だけだとピンと来ない。
なので、実際にそういうスタンスを取っている代表的なサービスのタイプを見てみよう。

ここで挙げるのは、「危ない会社」ではなく、むしろエンタープライズ寄りで、ガバナンスがしっかりしている会社ほどそうしているという例だ。

Salesforce

Salesforce は典型的な例だ。

  • 豊富な公式 API を用意している
  • API 利用にはプランや制限、場合によっては追加コストがある
  • 一方で、UI（管理画面）へのスクレイピングや自動操作は、規約上グレー〜禁止の扱いになっている

理由はシンプルで、Salesforce 側から見れば、

機械連携は API でやってほしい。
UI は人間の操作を前提にしたもので、そこを機械に叩かれると、
課金モデルも負荷設計も前提が崩れる。

という話になる。

技術的にできるかどうか、ではなく、契約上の正規ルートはどこか、という整理だ。

ServiceNow

ServiceNow も同じ系統のSaaSだ。

  • 公式に REST API や各種連携手段を用意している
  • それ以外の手段、特に ボット・クローラー・RPA的な自動アクセスは、原則として許可しない という立場を取っている

ここでも論理は同じで、

  • API は管理・制御・課金・保証の対象
  • UI は内部実装寄りで、そこを自動化されるのは想定外

という線引きになる。

Google Workspace（Gmail / Drive など）

Google もこの構造は分かりやすい。

  • Gmail や Drive には公式 API が用意されている
  • OAuth やスコープ制御、レート制限などがある
  • 逆に、画面をスクレイピングしたり、DOMを自動操作してデータを取るやり方は、規約上アウト寄りの扱いになる

要するに、

自動化したいなら、API を使ってくれ。
UI は人間のためのものだ。

というメッセージを、契約の形で明示している。

Shopify などのECプラットフォーム系

Shopify のような EC プラットフォームも同様だ。

  • 正規の連携は API 経由
  • 在庫、注文、商品情報などは API で取得・更新する前提
  • 管理画面を RPA で叩く形の自動化は、規約上は歓迎されない

ここも理由はビジネス的で、

  • API はパートナーエコシステムと課金モデルの一部
  • UI 経由の自動化は、その設計を迂回してしまう

という話になる。

ここまでの例を見ると、共通点ははっきりしている。

  • 大きなSaaSほど
  • APIを「正規の機械連携ルート」として整備し
  • UIへの自動アクセスは「想定外」あるいは「禁止」に寄せている

これは、

自動化が悪い
ではなく、
“どの入口から入るか”が契約で決まっている

という話だ。

そして、もし

  • API が有料で提供されているのに
  • それを避けて UI を RPA で叩いている

という構図になっていれば、
それは 「規約違反」どころか「ビジネス上の損害を与えている」と評価されうる構成になる。

ここまで来ると、話は完全に 技術ではなく契約と取引条件の世界だ。

次の章では、この話をもう一段引いて、
アメリカのフェアユースの感覚と、日本の現実をどうつなげて考えるか、という視点に移ろう。

第4章：フェアユースの話と、日本の現実

ここまでの話を読んで、

アメリカにはフェアユースがあるって聞くし、
研究目的とか内部利用なら、そんなに気にしなくていいんじゃない？

と思う人もいるかもしれない。

確かに、アメリカには「フェアユース」という考え方がある。
社会的に有益な利用、たとえば研究・批評・報道・教育などについては、一定の条件のもとで著作物を無断利用しても許容されるという発想だ。
「その利用が市場を食っていないか」「変換的（transformative）か」など、いくつかの観点から総合判断される。

ただし、ここで注意が必要なのは、日本にはアメリカ型の包括的なフェアユース規定は存在しないという点だ。

日本の著作権法は、

  • 引用
  • 私的利用
  • 研究・教育目的の一部利用
  • 情報解析（いわゆるデータ解析目的の利用）

といったように、個別に定義された例外規定の集合で運用されている。
「フェアだからOK」という包括的な逃げ道は用意されていない。

とはいえ、実務の空気が完全に違うかというと、そうでもない。

日米どちらでも、結局のところ評価軸はかなり似ている。

  • その利用は元のビジネスを食っていないか
  • 取得したデータをそのまま再配布・再販売していないか
  • 利用の目的は研究・分析・内部利用・変換的利用か
  • それともデータそのものを商品にしているのか

このあたりが、実務的な「危険度」を分ける境目になる。

たとえば、

  • データを集めて社内で分析する
  • 統計値や傾向に変換して外に出す
  • 要約や分類など、元データを置き換えない形に加工する

こういった使い方は、少なくとも

「他人のコンテンツを無断で再販売している」

という構図にはならない。

一方で、

  • 取得した記事やデータをそのまま再配布する
  • 元サービスの代替になる形で公開・販売する
  • APIの有料機能をUIスクレイピングで回避して商用利用する

こうなると、話は一気に変わる。
これはフェアユース以前に、ビジネスの土俵を侵食している構図になるからだ。

ここで大事なのは、

日本にはフェアユースがないから何もできない
でもなく、
フェアユースがあるから何をやってもいい
でもない

という現実的な落とし所だ。

実務の感覚としては、

  • 人のデータをそのまま持ち出して金儲けしない
  • 元サービスの価値を置き換える形で使わない
  • 分析・変換・内部利用に留める

このラインを守っている限り、
少なくとも「うっかり地雷を踏みに行く」確率はかなり下がる。

MCP や RPA の話に引き戻すと、ここでも本質は同じだ。

問題になるのは、

  • 自動化したかどうか
    ではなく、
  • その自動化で、何を取得し、どう使っているか

という点にある。

次の章では、ここまでの話をもう一度「現場の目線」に戻して、
善良な実務者が、どんな場面でうっかり地雷を踏みかねないかを、もう少し具体的なシーンで整理してみよう。

第5章：善良な実務者が踏みかねない“現実的な地雷”

ここまで読んで、「悪意がなければ大丈夫そうだな」と感じた人も多いと思う。
実際その感覚はかなり正しくて、普通に業務で使っている限り、いきなり大ごとになるケースはまれだ。

ただし、MCP や RPA のように「できること」が一気に増えると、悪意ゼロでも踏みかねない地雷はいくつか見えてくる。
どれも、「効率化したい」「楽したい」「ミスを減らしたい」という、まっとうな動機から始まるものだ。

ケース1：自分のSaaS管理画面をRPAで自動化

たとえば、

  • 毎月、同じ手順でレポートをダウンロードしている
  • 毎週、管理画面からCSVを落として加工している
  • 人がやるとミスるし、時間もかかる

ここに MCP + Playwright を入れて、「全部自動でやらせよう」と考える。
動機は100%善良だし、業務改善としても正しい。

でも、もしそのSaaSの規約に

ボット・自動化ツールによるアクセスは禁止

と書いてあったら、話は“技術”ではなく“契約”の問題になる。

  • 刑事事件になる可能性はほぼない
  • でも、契約違反によるアカウント停止や契約解除は現実的にありうる

本人の感覚では「自分のデータを自分で取っているだけ」なのに、
契約の世界ではアウト、という典型的なパターンだ。

ケース2：クライアント環境の“ついで自動化”

受託や運用代行の現場でも、ありがちな話がある。

  • クライアントから渡されたアカウントでSaaSにログイン
  • 毎月の定型作業を人力でやっている
  • 「これ、自動化したほうが楽じゃない？」と思ってRPA化

これも動機は完全に善意で、むしろ親切ですらある。

でも、

  • 利用規約で第三者ツールの利用が制限されている
  • 契約書で「自動化は禁止」「再委託禁止」となっている
  • 監査要件上「人の操作前提」になっている

こういう条件が混じっていると、本人に悪意ゼロでも契約違反ゾーンに入ることがある。

ケース3：データの“外に出し方”で線を越える

MCP の文脈で特にありがちなのがこれだ。

  • 社内DBやSaaSからデータを集める
  • LLMに食わせて要約・分類・分析する
  • 結果は便利で、仕事も楽になる

ここで、うっかり

  • 個人情報や契約上センシティブなデータを外部APIに投げる
  • 「二次利用禁止」のデータを別サービスに渡してしまう
  • 保存場所や学習利用の扱いを確認していない

こうなると、意図せず“第三者提供”や“目的外利用”の地雷に近づく。

本人の感覚では「ただの要約・分析」でも、
契約やコンプライアンスの世界では、評価が変わることがある。

ケース4：気づいたら“過剰アクセス”になっている

もう一つ、地味だけど現実的なのがこれだ。

  • MCP経由でバッチ処理を組んだ
  • 人間より何十倍も速く、何百回も操作する
  • 結果的に、サービス側から見ると「異常トラフィック」

これも悪意ゼロ、ただの設計ミス。
でも、

  • アカウントの一時停止
  • セキュリティアラート
  • サポートからの問い合わせ

くらいは普通に起きうる。

共通点はひとつ

ここまで挙げたケースに共通しているのは、これだ。

  • 悪意はない
  • データを盗んで売るつもりもない
  • ただ「仕事を楽にしたい」だけ

それでも、

技術の問題ではなく、「契約」と「データの扱い」の境界線で引っかかる

可能性がある。

逆に言えば、

  • 自分の権限内で
  • 契約の範囲内で
  • データを外に再配布せず
  • 商売の素材にしない

このラインを守っている限り、いきなり“御用”になる世界ではまずない。

次の章では、ここまでの話を踏まえて、
MCPを“安全に”使うための、現実的な指針をまとめよう。

第6章：MCPを“安全に”使うための現実的な指針

ここまで読んでくれた人なら、もう気づいていると思う。

問題になるのは、MCPでもPlaywrightでもRPAでもない。
「それを使って、どの入口から、何をしているか」だ。

なので、実務レベルで意識しておくべきポイントは、実はそんなに多くない。

1) APIがあるなら、迷わずAPIを使う

これはもう原則だ。

  • SaaSが公式にAPIを用意している
  • そこに課金やレート制限や利用条件がある
  • それが「正規ルート」

である以上、機械連携はAPI経由が前提になる。

UI自動化は、

  • APIが存在しない
  • どうしても人間操作を再現するしかない
  • 一時的・例外的な業務対応

こういう場合の最終手段として考えるのが、いちばんトラブルが少ない。

2) UI自動化をするなら、規約を一度は確認する

「毎回読む」のは現実的じゃない。
でも、

  • 利用規約
  • API利用規約
  • 自動化・ボットに関する条項

このあたりを一度は目を通す習慣があるだけで、踏み抜く地雷の数はかなり減る。

特に、

  • 「自動化禁止」
  • 「スクレイピング禁止」
  • 「非公式手段によるアクセス禁止」

この手の文言があるかどうかは、チェックする価値がある。

3) データは「どこに出すか」を常に意識する

MCP時代に一番起きやすい事故は、たぶんこれだ。

  • 便利だからといって
  • 深く考えずに
  • 外部のLLMやサービスにデータを投げる

ここで見るべきポイントは、

  • それは契約上、第三者提供に当たらないか
  • 二次利用禁止のデータではないか
  • 保存や学習利用の扱いはどうなっているか

「分析する」ことと「持ち出す」ことは別、という意識は持っておいたほうがいい。

4) スケールさせる前に、一度立ち止まる

手作業を自動化しただけのつもりが、

  • 回数が10倍、100倍に増える
  • アクセス頻度が桁違いになる
  • サービス側から見ると“異常な使い方”になる

というのは、よくある話だ。

  • これ、人間がやっても同じ頻度か？
  • サービス提供側から見て、想定内の使い方か？

一度ここで考えるだけでも、余計なトラブルは避けやすくなる。

5) 規約は変わる、という前提に立つ

これはとても大事なポイントだ。

  • 規約はサービス提供者側の都合で変わる
  • 昨日までOKだったことが、今日からNGになることもある
  • しかも、たいていはユーザーが気づかないうちに変わる

だからこそ、

「一度確認したから大丈夫」ではなく、
「たまに見直す」くらいの距離感

が、現実的でちょうどいい。

結局のところ、MCPはただの“配線”だ。
PlaywrightやRPAも、ただの“手足”に過ぎない。

危ないのは道具ではなく、

契約の境界をまたいでしまうこと
データの扱い方を間違えること

この2つだ。

そして、ここまでのポイントを押さえて使っている限り、
MCPを普通に業務ツールとして使っていて、いきなり“御用”になる世界ではまずない。

結び：結局、MCPは危ないのか？

ここまで見てきた通り、MCP や Playwright、RPA はそれ自体が危険な道具ではない。
ただし、便利さが「契約」と「データの境界線」を見えにくくするのは事実だ。

特に SaaS の世界では、

  • 機械連携の正規ルートは API
  • UI は人間向けの操作口
  • その境界は 技術ではなく契約で引かれている

という構造がある。

だから、

MCPを普通に業務ツールとして使っている限り、
いきなり“御用”になる世界ではない。
ただし、APIを避けてUIを叩き始めた瞬間から、話は技術ではなく契約になる。

この一文に、ほぼすべてが集約される。

怖がる必要はない。
でも、どの入口から入って、何をしているかは、少しだけ意識したほうがいい。
それだけで、MCP は安心して「仕事の道具」として使える。

この記事の要点

  • MCPやRPA、Playwrightは道具そのものが危険なわけではない
  • 問題になるのは「何をしたか」ではなく、「どの入口からやったか」
  • 多くのSaaSでは、機械連携の正規ルートはAPIとして設計されている
  • APIが有料・制限付きで提供されている場合、UI自動化での回避は契約・民事の問題になりうる
  • 日本には包括的なフェアユースはないが、実務感覚では
    「元データをそのまま再配布・再販売しない」「市場を食わない」利用はリスクが低い
  • 善良な実務者が踏みがちな地雷は、
    規約違反の自動化、データの持ち出し、過剰アクセスといった“境界線”の問題
  • 安全に使うための基本はシンプル：
    • APIがあるならAPIを使う
    • UI自動化は最終手段
    • 規約を一度は確認する
    • データの外部持ち出しに注意する
    • 規約は変わる前提で、たまに見直す
  • 結論：MCPは危険な技術ではない。危険になりうるのは、契約とデータの境界を越えたときだけ