「AIに自社のサービスを使わせたい」と考えたとき、手段は一つではありません。API、RPA、スクレイピング、そして新しく提案されているWebMCPがあります。この記事は、自社サービスの責任者や新規事業の担当者に向けて、どれをどんな場面で選ぶかの基準を整理します。エンジニアでなくても読めるように、用語には短い補足を付けました。
読み終えると、自社の状況で「まず何を使うか」「何を併用するか」を、自分の言葉で説明できるようになります。なお、WebMCPはW3Cのコミュニティグループが公開している草案に基づく提案で、内容は変わり続けています。この記事は2026年10月時点の情報です。最新の状況は、末尾の参照元でご確認ください。全体像はWebMCPとAIエージェントに使われるサイトの考え方にまとめています。
4つの手段を、ひとことで言うと
まず、それぞれが何をする手段なのかを揃えます。ここでの整理は、一般的な理解に基づく大づかみなものです。個別の製品や契約によって、細部は異なります。
- API：サービスが、外部のプログラム向けに用意した正式な窓口です。決められた形で依頼を送り、決められた形で答えを受け取ります。
- RPA：人が画面で行う操作（クリックや入力）を、ソフトが代わりに再現する仕組みです。
- スクレイピング：Webページの表示内容を、プログラムで読み取って取り出す方法です。
- WebMCP：Webサイトが自分の機能を「ツール」として、ブラウザ上のAIエージェントに公開する仕組みの提案です。ツールは、名前・説明・入力の形・実行する処理でできています。
RPAとスクレイピングは、サイト側に準備がなくても使えます。APIとWebMCPは、サイト側が入口を用意する点が違います。この「入口を誰が用意するか」が、選び方の最初の分かれ目です。
得意・不得意の比較表
次の表は、考え方の目安です。数値ではなく、傾向をまとめています。WebMCPの欄は、現時点で仕様が固まっていないため、「見込み」を含みます。
| 観点 | API | RPA | スクレイピング | WebMCP |
|---|---|---|---|---|
| 入口を用意する人 | サイト側 | 使う側 | 使う側 | サイト側 |
| 画面の変更への強さ | 強い（窓口が別にある） | 弱い | 弱い | ツール定義は画面と別に持てる（効果は未検証で、仕様は変動中） |
| 向いている相手 | システム同士の連携 | 画面しかない業務 | 公開情報の読み取り | ブラウザ上のAIエージェント |
| 人の関わり | 設計次第 | 設計次第 | 通常は不要 | 人が関わる使い方が主に想定 |
| 現時点の成熟度 | 広く使われている手段 | 広く使われている手段 | 広く使われている手段 | 草案・試験運用の段階 |
表のとおり、どれか一つが全部に勝つわけではありません。大切なのは、相手が誰で、何を守りたいかです。
それぞれの手段が向く場面と、向かない場面
比較表を、もう少し言葉で補います。ここでも、一般的な傾向としての整理です。
APIが向く場面
自社の業務システム同士をつなぐ場合や、取引先のシステムと決まった形でデータをやり取りする場合です。窓口の仕様が文書で決まっているため、動作の予測がしやすい手段です。一方で、窓口を作る側に設計と保守の手間がかかります。また、画面でしかできない操作は、窓口がなければ扱えません。
RPAが向く場面
古いシステムなど、画面でしか操作できない業務を、人の代わりに回したい場合です。システム側を改修できない状況では、現実的な選択肢になります。ただし、画面が更新されると動かなくなることがあり、例外が起きたときの扱いも決めておく必要があります。
スクレイピングが向く場面
公開されている情報を、集めて整理したい場合です。相手に準備を求めずに始められる反面、ページの作りが変わると取れなくなります。取得してよい情報かどうか、利用規約や権利の面で確認が必要です。
WebMCPが向きそうな場面
自社のWebサイトの機能を、利用者のブラウザ上にいるAIエージェントに、分かりやすく差し出したい場合です。エージェントが画面を推測する代わりに、サイトが「できること」を名前と説明、入力の形で示します。ただし、現時点では草案と試験運用の段階です。実際の効果や、どれほどのエージェントが対応するかは、まだ分かっていません。
選ぶ基準を6つに分けて考える
手段を選ぶときは、次の6つの問いに答えると整理しやすくなります。
1. 相手は誰か
相手が社内のシステムなら、APIが自然です。相手が利用者のブラウザで動くAIエージェントなら、WebMCPが候補になります。相手が自社の画面しかない古いシステムなら、RPAを検討することになります。
2. どれだけ安定させたいか
業務の中心にあたる処理は、止まると困ります。画面の見た目に頼る方式は、画面が変わると止まりやすくなります。止まったときの影響が大きい処理ほど、正式な窓口を優先します。
3. 保守の担当は誰か
RPAやスクレイピングは、相手のサイトが変わるたびに、使う側が直す必要があります。APIやWebMCPは、サイト側が窓口を保守します。つまり、保守の責任がどちらにあるかが変わります。
4. 安全性をどう守るか
AIに操作させると、意図しない操作が起きる可能性があります。WebMCPの草案には、読み取り専用か、取り消せない操作かを示す注釈（ヒント）が用意されています。ただし、宣言と実際の動作が一致する保証はなく、草案自身もリスクとして挙げています。どの手段でも、重要な操作の前に人が確認する設計が大切です。草案が挙げるリスクには、ツールの説明や出力に紛れる悪意ある指示（プロンプトインジェクション）や、宣言と実際の動作のずれがあります。
5. 費用と手間はどれくらいか
初期費用だけでなく、変更への対応を含めた全体で見ます。画面に頼る方式は、始めやすい反面、直し続ける手間が残ります。正式な窓口は、最初に設計の手間がかかりますが、変更に強くなります。具体的な金額は、規模や契約で大きく変わるため、ここでは示しません。
6. 利用者の同意はどう扱うか
購入や送金など、取り消しにくい操作では、利用者の同意が重要です。WebMCPの草案の本文は、ツール実行時のユーザー確認を必須とは定めていません。確認を出せるのは、主にクライアント（AIを動かす側）の判断です。Chromeの資料は、購入などの重要な操作で、確認ダイアログを出す指示をツールに含められると述べています。自社の設計でも、確認の場面を決めておくと安心です。
画面の変更に弱い方式の弱点
RPAとスクレイピングには、共通する弱点があります。どちらも、画面の見た目や構造に頼っている点です。
- ボタンの位置や名前が変わると、操作が失敗することがあります。
- 失敗しても、静かに別の場所を押してしまい、気づきにくいことがあります。
- サイトの利用規約で、自動での読み取りや操作が制限されている場合があります。
- 直す作業が、使う側に継続的に発生します。
規約や法的な扱いは、サイトや国によって異なります。判断に迷う場合は、専門家に確認してください。
WebMCPは、この弱点への一つの答えとして提案されています。エージェントは画面を推測せず、サイトが公開したツールを呼びます。ただし、これは「提案」です。Chromeの資料も、議論の最中で変更される可能性があると明記しています。今日から全面的に頼れる手段ではない、という前提で考えてください。
併用の考え方：API＋WebMCP
手段は、置き換えではなく、役割を分けて併用するのが現実的です。WebMCPの仕様の位置づけも、人間向けのUIが主役のまま、バックエンド連携の代わりではなく補完、というものです。
次の架空の例で考えてみます。
架空の例：ある小さな宿泊予約サイトがあります。在庫や料金は、社内のAPIで管理しています。そのAPIを土台にして、「空室を検索する」「予約の状況を調べる」といった機能だけを、ブラウザ上のAIエージェント向けにツールとして公開します。予約の確定のような取り消しにくい操作には、確認を挟む設計にします。
この例では、APIが事業の本体を支え、WebMCPがブラウザ上のエージェントへの窓口になります。ツールの中身は、既存のAPIを呼ぶだけにしておけば、二重に作らずに済みます。
また、MCPとの違いを知りたい方は、WebMCPとMCPの違いをご覧ください。MCPは、AIアプリを外部のシステムにつなぐオープンソースの標準です。WebMCPは用語や考え方を共有しつつ、Webの仕組みに合わせて設計されています。
段階的な移行の考え方
いきなり全部を切り替える必要はありません。次のような順で進めると、リスクを抑えられます。
- 現状を棚卸しする：いまAIや自動化が触れている画面と処理を、一覧にします。
- 止まると困る処理を選ぶ：業務の中心にあたる処理から、正式な窓口（API）に移します。
- 読み取りだけのツールで試す：検索や状況確認など、影響の小さい機能から、WebMCPを検証環境で試します。
- 注釈と確認を設計する：取り消しにくい操作は、注釈と人の確認を組み合わせます。
- 併存させる：WebMCPは、あれば使われ、なくても画面は動く、という補強として扱います（Chromeの資料の勧め）。
Chromeでは、Chrome 149からオリジントライアルとして提供されています。ローカルで試すためのフラグや、DevToolsでツールを確認する機能があります。まずは、本番ではなく検証環境で試すのが無難です。
よくある失敗
- 画面の操作で始め、そのまま本番の中心にしてしまう：変更のたびに止まり、直す作業が増えます。
- WebMCPがAPIの代わりになると考える：仕様の位置づけは補完です。バックエンドの連携は別に必要です。
- 公開するツールを増やしすぎる：草案も、ツール数はモデルの文脈量に制約されると述べています。目的に合うものに絞ります。
- 説明文を雑に書く：エージェントはツールの名前と説明で判断します。何をするのか、何をしないのかを、明確に書きます。
- 確認の場面を決めていない：購入や送金で、AIが人の確認なしに進むと、取り返しがつかないことがあります。
- 仕様の変動を見ていない：名前や機能が短期間で変わっています。実装前に、最新の仕様を確認します。
判断のための簡単なチェックリスト
次の問いに、はい・いいえで答えてみてください。結果から、最初の一手が見えてきます。
- 相手は社内のシステムですか。はいなら、APIを優先します。
- 止まると業務に大きな影響が出ますか。はいなら、画面に頼る方式は避けます。
- 自社のサイトを、利用者のAIエージェントに使ってもらいたいですか。はいなら、WebMCPを検証環境で試す価値があります。
- 画面しか操作の手段がありませんか。はいなら、RPAを検討し、変更への備えも用意します。
- 取り消しにくい操作がありますか。はいなら、人の確認の場面を先に決めます。
この結果は、方向づけのための目安です。最終的な判断は、自社の事情に合わせて、人が行ってください。
注意点
この記事の比較は、考え方の整理であり、特定の手段を勧めるものではありません。WebMCPについては、次の点が現時点では確認できていません。
- Chrome以外のブラウザが、いつ対応するか（公式な確認が取れていません）。
- 草案が、将来どの形で確定するか。
- ログインや認証の扱いが、仕様としてどう定義されるか（草案は、ページ自身の実行環境で動く、という範囲までしか述べていません。Chromeの資料は、ログイン中のセッション情報やCookieにアクセスすると述べています）。
セキュリティ、個人情報、契約や規約に関わる判断は、専門家に確認してください。AIの出力も、そのまま信じず、人が確認する前提で運用してください。
Otsumuに相談できること
手段の棚卸しや、止まると困る処理の洗い出しは、社内でも進められます。まずは、AIが触れている画面と処理を、一覧にしてみてください。
一方で、既存システムの窓口づくりや、ツールの設計、確認の入れ方は、判断が難しい部分です。Otsumuは、AIを前提に事業を組み直す、AIファーストの事業再構築を支援しています。AIが下書きや実装を担い、人が判断と責任を持つ形で、設計から運用までを一緒に考えます。
具体的には、AIエージェント開発をご覧ください。ご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日です。WebMCPの仕様は変動中のため、最新の内容は参照元をご確認ください。参照元：W3C Web Machine Learning Community Group の仕様草案、Chrome の公式資料、MCP の公式サイト。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20