BlogWebMCPとは？MCP・Browser Useとの違いから実装、セキュリティ、導入判断まで徹底解説

AIエージェントにWebサイトを操作させる方法として、WebMCPへの関心が高まっています。「通常のMCPサーバーと何が違うのか」「Browser Useのようなブラウザ自動化で足りるのではないか」「提案段階の技術を本番環境で使ってよいのか」と判断に迷う企業も多いでしょう。

WebMCPは、AIに画面を読ませてクリック位置を推測させるのではなく、Webアプリ側が利用可能な機能を構造化して伝える考え方です。本記事では、方式の選び方、実装時の注意点、安全な運用設計、PoCで効果を測る方法を、開発者と事業責任者の双方に向けて整理します。

WebMCPとは：WebアプリをAIエージェント向けの構造化ツールとして公開する仕組み

WebMCPとは、Webアプリケーションが自らの機能を、AIエージェントが呼び出せる構造化ツールとして公開するための仕組みです。提案中のWeb標準であり、確定済みの標準仕様として扱える段階ではありません。

一般的な画面操作型の自動化では、AIがDOM、アクセシビリティ情報、画面画像などを読み取り、「このボタンを押す」「この入力欄に値を入れる」と判断します。これに対しWebMCPでは、Webアプリが「在庫を検索する」「予約候補を確認する」「下書きを作成する」といった機能の目的、入力、返却結果を明示します。

AIは画面構造を推測する代わりに、許可されたツールを呼び出します。ただし、WebMCPを導入しても、認証・認可、入力検証、業務ルールの適用を省略できるわけではありません。実行処理の最終判断は、従来どおりサーバー側で行う必要があります。

「AIが画面を読む」から「Webアプリが機能を説明する」への転換

WebMCPの本質は、AIにUIを解釈させる設計から、アプリケーションが機能を説明する設計への転換にあります。たとえば予約画面のボタン配置やHTML構造が変われば、画面操作型の自動化は影響を受ける可能性があります。一方、予約候補検索というツールの名称、説明、入力条件、返却形式が維持されれば、AIは目的に沿って呼び出しやすくなります。

人間向けUIを不要にする技術ではありません。人は従来の画面で確認・修正し、AIは定義済みの機能を使って情報収集や下書き作成を進める。WebMCPは、こうした協働を設計するための選択肢です。

結論：WebMCP・通常のMCPサーバー・Browser Useの選び方

WebMCP、通常のMCPサーバー、Browser UseやPlaywrightのようなブラウザ自動化は、単純な競合関係ではありません。接続したい対象と、求める統制の水準に応じて使い分けます。

自社のAPI、データベース、社内業務システムをAIに利用させたい場合は、通常のMCPサーバーやAPI連携が候補です。既存サイトにAPIがなく、画面を横断して操作する必要がある場合はブラウザ自動化が選択肢になります。ログイン中のWebアプリが、ブラウザ上の文脈でAIへ機能を提示したい場合に、WebMCPを検討します。

もっとも、WebMCPは提案段階の技術です。重要な更新処理をいきなり全面移行するのではなく、参照系の限定的なPoCから始め、対応環境、運用上の制約、効果を確認するのが現実的です。

比較表：認証・適用範囲・実装コスト・安全性・仕様成熟度

• WebMCP：ブラウザで開いているWebアプリの機能を、構造化ツールとして公開する考え方です。画面操作への依存を減らせますが、対応ブラウザ、エージェント、APIの詳細は導入時点で個別に確認する必要があります。
• 通常のMCPサーバー：バックエンドのデータや業務機能をMCPクライアントへ提供する構成です。対象機能、認証方式、権限、運用責任をサーバー側で設計しやすい一方、サーバー開発、接続設定、保守が必要です。
• Browser Use・Playwrightなど：ブラウザを介して既存画面を操作します。APIがない外部サイトや探索的な作業で有用ですが、画面変更、特殊な認証、利用規約、自動アクセスの許諾に影響されます。ログイン済みセッションを使う場合は、資格情報と権限の分離が特に重要です。

安全性は方式だけでは決まりません。どの方式でも、サーバー側の再認可、入力検証、承認フロー、監査ログ、失敗時の停止・復旧がなければ、重要業務には不十分です。

選定フレームワーク：業務の重要度・画面の性質・統制要件で決める

選定時は、次の順番で考えると判断しやすくなります。

1. 業務の重要度：誤操作が売上、顧客、法令対応に与える影響を整理します。重要業務ほど、人の承認、権限分離、監査、復旧手順を先に決めます。
2. 画面・機能の性質：DOMやアクセシビリティツリーで安定して表現できる既存画面なら、ブラウザ自動化が適する場合があります。自社アプリの機能を明示的に提供できるなら、WebMCPやAPI連携が候補です。
3. 統制要件：誰が何を見て、何を変更でき、どの記録を残すかを決めます。個人情報や更新処理を扱う場合は、方式の選定より統制設計を優先します。

WebMCPの仕組み：発見・コンテキスト提供・実行・結果返却の流れ

WebMCPでは、Webアプリがエージェントに利用可能なツールを公開し、エージェントが説明と入力条件を確認して呼び出します。概念的な流れは次のとおりです。

1. Webアプリが、現在の画面や権限で利用できるツールを公開します。
2. エージェントがツール名、説明、必要な入力を確認します。
3. エージェントが入力を渡してツールを実行します。
4. アプリケーションはサーバー側で認証・認可・業務ルール・入力値を検証します。
5. 成功、失敗、確認が必要な理由を構造化した結果として返します。

重要なのは、AIに「何でもできる」権限を与えないことです。画面、セッション、ロールに応じて、公開するツール自体を絞り込みます。

参照系と操作系を分ける：観察→計画→確認→実行の安全なワークフロー

ツールは、情報を読む参照系と、状態を変える操作系に分けます。検索、在庫照会、注文状況確認は参照系です。予約確定、経費申請、送信、削除、権限変更は操作系にあたります。

実運用では、観察→計画→ユーザー確認→実行を基本にします。まず参照系ツールで必要な情報を集め、AIは実行予定の内容を人に提示します。日時、対象、金額、変更前後の差分、送信先を確認してから、操作系ツールを許可します。人の確認を残すことで、AIの提案と業務上の最終責任を切り分けられます。

WebMCPでできること・できないこと：業務ユースケースから考える

WebMCPは、AIエージェントがWebアプリの決められた機能を利用しやすくする仕組みです。万能な業務自動化ではなく、公開する機能、権限、承認、実装環境の制約を受けます。

相性がよいのは、検索条件を整理して結果を返す、予約候補を提示する、フォームの下書きを作る、問い合わせ内容を分類するといった、目的と入力が比較的明確な処理です。一方で、曖昧な判断、例外が頻発する承認、責任者しか決められない価格変更や契約判断を、AIだけに任せる設計は避けるべきです。

参照系ツール：検索・在庫照会・顧客情報確認を安全に設計する

参照系はPoCの最初の対象に向いています。商品検索、在庫の有無、案件の進捗、社内FAQ、顧客の対応履歴などが該当します。ただし、「読むだけ」の機能でも、表示できる情報を無制限にしてはいけません。

• 検索対象を、利用者の担当範囲や組織に限定します。
• 返却項目を必要最小限にし、不要な個人情報や機密項目はマスキングします。
• 検索条件、対象件数、参照日時を記録します。
• データが古い、取得に失敗した、権限がない場合は推測で回答せず、失敗を明示します。

操作系ツール：予約・申請・CMS下書きで求められる確認と復旧設計

操作系は、影響が小さく可逆的な処理から始めます。たとえばCMSの公開前下書き作成、予約候補の仮押さえ、経費申請の下書き、問い合わせの分類と担当者への割り当てです。

確定送信や公開の前には、差分、対象、金額、送信先、実行者を画面または確認ステップで示します。実行後には受付番号や変更結果を返し、取り消し可能な期限や担当窓口も用意します。取り消せない処理、外部送信、削除、権限変更には、より強い承認と監査が必要です。

実装方法1：HTMLの宣言型APIで既存フォームをAI対応する

宣言型APIは、既存のHTMLフォームにツール名や説明を付与し、フォームの構造をAI向けツールとして利用しやすくする考え方です。検索、資料請求、予約候補検索など、入力項目と通常の送信処理がすでに整っている画面で検討しやすい方法です。

公開情報では、フォームにtoolname、tooldescriptionといった属性を付与し、name、required、typeなど既存のHTMLフォーム属性から入力条件を表現する方法が紹介されています。属性仕様は変わる可能性があるため、実装前に対象ブラウザの公式ドキュメントと仕様を確認してください。

在庫検索フォームなら、検索語、拠点、希望日を明示します。日付形式、必須項目、文字数、数量の上限などは、フォーム上だけでなく、送信先のAPIでも検証します。

宣言型APIが向くケースと、フォーム送信で起こりやすい失敗

宣言型APIは、既存フォームを活かしながらAIに目的と入力を伝えたい場合に向きます。しかし、フォームが構造化されていることと、安全に実行できることは別問題です。

• 似た項目を取り違え、意図しない値が入力される。
• 必須項目、日付、件数、金額の制約を満たさない。
• 送信直前に画面の内容が変わり、古い前提で実行される。
• 自動送信によって、人が確認すべき申請や契約処理まで確定する。

対策は、入力制約を明確にすること、確認画面を置くこと、サーバー側で認可と業務ルールを再検証することです。属性名や自動送信に関する細かな挙動は提案・実装の更新対象になり得るため、未確認の仕様を前提に本番設計を固定しないことが重要です。

実装方法2：JavaScriptの命令型APIで複雑な業務ロジックをツール化する

複数の画面、条件分岐、外部API、確認処理をまたぐ業務では、JavaScriptで明示的にツールを登録する命令型APIが検討対象になります。公開情報では、navigator.modelContextを通じ、個別ツールを登録するregisterTool()、ツール群のコンテキストを提供するprovideContext()、公開を取り消すunregisterTool()といった考え方が示されています。

ただし、引数や戻り値、スキーマの正確な形式は、利用時点の公式仕様、型定義、対応ブラウザで確認してください。ここでは、実装時に守るべき設計原則を紹介します。

registerTool・JSON Schema・execute：曖昧さを減らすツール設計の原則

ツールは「何をするか」「何を受け取るか」「何を返すか」を狭く定義します。たとえば「顧客を更新する」という大きすぎるツールではなく、「顧客の住所変更案を検証する」「承認済みの住所変更を確定する」のように分けます。

• ツール名は動詞と対象を含め、似たツールと区別します。
• 説明には用途、対象範囲、実行しないことを記載します。
• 入力はJSON Schemaなどで型、必須項目、許容値、件数上限を定義します。
• executeでは、クライアント入力を信用せず、サーバーで認証、認可、再検証、業務ルール判定を行います。
• 返却値には結果だけでなく、対象ID、実行可否、確認が必要な理由、次に取るべき行動を含めます。

AIに曖昧な自然言語だけを渡すより、入力と結果を構造化するほど、実行意図の確認、テスト、監査がしやすくなります。

provideContext・unregisterTool：画面状態と利用可能操作を正しく同期する

ツールは常時公開するのではなく、現在の画面、選択中のデータ、ログイン状態、利用者ロールに合わせます。閲覧者が管理者向けの更新ツールを見られる状態や、画面を離れた後も前画面のツールが残る状態は避けるべきです。

画面状態が変わったら、利用可能なツール群を更新し、不要なツールを解除します。ツールの公開状態だけを信用せず、実行時にも必ず再認可します。クライアント側の登録・解除は使いやすさと事故防止に役立ちますが、セキュリティの最終境界ではありません。

React・SPAでのWebMCP設計：古い状態をAIに渡さないライフサイクル管理

ReactやSPAでは、URL遷移を伴わずに画面内容、選択レコード、権限、ログイン状態が変わります。このとき、ツール登録が古い状態を参照すると、別案件の情報を操作したり、失効した権限のまま実行を試みたりする危険があります。

設計上は、ルート、選択中のID、ロール、セッション状態を、ツール公開の依存要素として扱います。状態変更時には現在の状態に対応するツールへ更新し、コンポーネントのアンマウント時や権限失効時には解除します。非同期通信の完了順序が逆転し、古い結果で再登録される競合にも注意が必要です。

実務チェックリスト：ルート・選択レコード・権限が変わったら何を更新するか

• ルート遷移時に、前画面専用のツールを解除できているか。
• 選択中の顧客・注文・案件が変わったら、対象IDを固定した古いツールが残っていないか。
• 権限変更、ログアウト、セッション失効時に、操作系ツールをただちに非公開にできるか。
• 非同期処理のキャンセルや世代管理により、古い通信結果が最新状態を上書きしないか。
• 状態変更後のツール一覧、入力スキーマ、実行結果を開発者ツールで確認できるか。
• ツールの公開状態とは別に、API側で毎回認証・認可を確認しているか。

Chrome DevToolsには、WebMCPツールの公開確認、実行のデバッグ、スキーマの確認を支援する情報があります。画面遷移や権限変更のテストケースに、ツールの登録・更新・解除の検証を組み込みましょう。

セキュリティ設計：誤操作・権限逸脱・プロンプトインジェクションを防ぐ

WebMCPの導入で問われるのは、AIに機能を公開すること自体ではありません。どの操作を、誰の権限で、どの確認を経て実行可能にするかです。ログイン済みブラウザの文脈を利用する場合は、セッションを持つ本人の操作に見えても、AIへの指示や外部ページの内容に誘導される可能性を考慮します。

最小権限・参照／操作分離・ユーザー承認を実装要件にする

まず、ツールを参照系と操作系に分離します。参照系は対象データ、項目、件数を絞り、操作系は用途ごとに細分化します。広範な更新権限を持つ万能ツールは作らないことが原則です。

重要な操作では、実行前に対象、変更前後の差分、送信先、金額、件数を表示し、ユーザーまたは権限者の承認を求めます。承認なしに実行できる処理は、低リスクかつ可逆的な範囲に限定します。操作の許可リスト、ロール別権限、件数制限、時間帯制限も有効です。

セッション・CSRF・なりすまし・プロンプトインジェクションへの多層防御

クライアント上でツールを隠すだけでは防御になりません。実行APIでは、セッション認証、CSRF対策、ロール確認、対象レコードへのアクセス権、入力値、業務上の条件を再検証します。セッションを共有する構成では、端末、利用者、用途ごとの分離、短い有効期限、失効処理、資格情報の保管方法を設計します。

プロンプトインジェクション対策では、外部ページ、添付ファイル、顧客入力などを「命令」ではなく不信なデータとして扱います。AIが読み取った内容だけで送信、削除、権限変更を実行させず、決定論的なポリシー判定と人の確認を間に置きます。機密データを返すツールでは、出力の最小化とマスキングも必須です。

本番運用の信頼性設計：監査ログ、冪等性、再試行、異常検知

デモで一度動くことと、本番業務で安全に運用できることは別です。ネットワーク障害、タイムアウト、二重実行、外部連携の部分失敗、AIによる連続呼び出しを前提に設計します。

二重送信・部分失敗・再実行を前提にしたAPI設計

更新系APIでは、同じ要求が届いても処理を重複実行しないための冪等性キーを検討します。応答を受け取れなかったからといって無条件に再送すると、予約、申請、メール送信、決済などが二重になるおそれがあります。

再実行前には、相関IDや状態照会で実行済みかを確認します。外部サービスへの送信だけ成功し、社内DBの更新に失敗するような部分失敗も想定し、保留状態、補償処理、担当者への引き継ぎを定義します。ロールバックできない操作は実行前の承認を強くし、復旧窓口と手順を明確にします。

監査ログには、利用者、セッション、ツール名、引数の要約、対象ID、承認記録、判定、実行結果、失敗理由、時刻、相関IDを実行前後で結び付けて残します。個人情報や秘密情報をログへ過剰に保存しないよう、マスキング、保存期間、閲覧権限も定めます。

レート制限と異常検知：AIによる大量・不自然な操作を止める

AIエージェントは短時間に多数の操作を試行できるため、利用者、セッション、ツール、対象ごとに回数や件数を制限します。通常と異なる大量検索、連続した失敗、深夜の高権限操作、同一対象への繰り返し更新などは、通知、追加承認、停止の対象にします。

検知後に誰が判断し、どの機能を停止し、どのログを確認し、どう復旧するかを運用手順に落とし込みます。AIの判断に任せる前に、許可、拒否、追加確認といった決定論的なポリシー層で止める設計が重要です。

WebMCPの効果を過大評価しない：PoCで測るKPIと比較実験の進め方

WebMCPを導入すれば、必ず処理時間や成功率が改善するとは限りません。画面の性質、ツール設計、エージェントの能力、確認手順、例外の多さによって結果は変わります。印象ではなく、導入前のベースラインと比較して評価します。

検証テンプレート：同一業務でWebMCPあり・なしを比較する

PoCでは、同一の業務を「WebMCPあり」「GUI自動化」「人手操作」で比較します。対象データ、完了条件、操作環境、例外ケースをそろえ、方式以外の条件をできるだけ固定します。

• 完了時間：依頼開始から、定義した完了状態までの時間です。
• 成功率：人の介入なし、または事前に決めた最小限の介入で完了した割合です。
• 再試行回数・エラー率：同じ処理をやり直した回数、入力・業務エラーの割合です。
• 有人確認工数：確認、修正、例外処理に使った時間です。
• 運用コスト：APIや実行費だけでなく、開発、保守、監視、障害対応、確認作業を含めます。

開始前に、対象件数、期間、成功判定、重大インシデントの定義、停止条件を文書化します。定量指標に加え、現場が安心して使えるか、確認画面が分かりやすいかといった定性評価も集めてください。

対応ブラウザ・対応エージェント・仕様成熟度：導入前の互換性チェック

WebMCPは提案されたWeb標準であり、広範なブラウザやエージェントで安定利用できると断定できる段階ではありません。Chrome for DevelopersにはWebMCPとデバッグに関する情報がありますが、それだけで他ブラウザや全エージェントの対応を示すものではありません。

導入判断の直前に、対象ブラウザ、対象バージョン、実験機能・オリジントライアルの要否、利用するエージェントや開発ツールの対応範囲、既知の制限を公式情報で確認します。確認日と確認した環境を記録し、検証環境だけでなく実際の利用者環境でもテストします。

フォールバックと仕様変更監視：早期採用をロックインにしない設計

早期採用では、WebMCPが利用できない環境でも、通常のUI、フォーム、APIが機能する構成を維持します。WebMCPを必須経路にせず、追加の利便性として段階導入するプログレッシブエンハンスメントが有効です。

機能フラグで対象ユーザー、対象操作、対象環境を絞り、問題があれば即時に無効化できるキルスイッチを用意します。仕様、権限モデル、対応環境の変更を監視し、更新時には入力スキーマ、認可、監査ログ、フォールバックを再テストします。WebMCPに固有の実装を業務ロジックへ強く埋め込まず、APIと業務ルールを分離するほど、将来の変更に対応しやすくなります。

利用規約・Bot禁止・個人情報：第三者サービス連携の導入可否を判定する

外部サービスをAI経由で操作・連携する前に、利用規約、API規約、自動アクセスやBotに関する条項、契約上の許諾を確認します。robots.txtだけで、法的・契約上の可否を判断することはできません。公式APIが提供されているなら、画面自動化よりAPI利用が適切な場合があります。

個人情報を外部のAIや海外サービスへ送る場合は、利用目的、保存期間、再利用・学習利用の設定、委託・再委託、保存先を確認します。外国にある第三者への個人データの提供や委託には、条件に応じて本人同意などが必要になるため、個人情報保護委員会のガイドラインを確認し、個別案件は法務・プライバシー担当と判断してください。

データは必要最小限にし、匿名化・マスキングを検討します。「委託だから安全」「AIを使うから例外」とは考えず、契約と実際のデータフローの両方で可否を確認することが重要です。

WebMCP導入ロードマップ：PoCから本番展開までの5ステップ

WebMCPは、技術検証と業務・リスク評価を並行させながら段階導入します。

1. 対象業務を選ぶ：業務価値、対象者、入力データ、失敗時の影響、代替手段、責任者を整理します。
2. 参照系PoCを行う：最小権限、テストデータ、人の確認を前提に、読み取り専用のツールから検証します。
3. 効果測定と脅威分析を行う：KPI、誤操作、情報漏えい、権限逸脱、プロンプトインジェクションを評価し、残余リスクを判断します。
4. 承認・監査付きで操作系を限定公開する：操作の許可リスト、ロール別権限、承認、ログ、ロールバックを整え、対象ユーザーと機能を絞ります。
5. 本番監視と仕様追随を続ける：エラー、異常操作、利用環境、仕様変更を監視し、停止、再テスト、再承認の手順を運用します。

非エンジニア向け導入チェックリスト：業務価値・責任・統制を先に決める

• 何を改善し、どの数値で成功と判断するか。
• AIが扱うデータと、絶対に扱わせないデータは何か。
• AIに許可する操作、必ず人が承認する操作は何か。
• 誤操作や障害が起きた場合、誰が停止・復旧を判断するか。
• 誰が実行し、誰が承認し、どのログを残すか。
• 対応ブラウザや仕様が変わったとき、誰が再確認するか。

AI導入の価値は、ツールを増やすことではなく、現場の業務に定着し、確認、責任、復旧まで含めて運用できることにあります。

WebアプリへのAI機能の組み込みや、既存業務システムとの安全な連携を検討している場合

株式会社エイムハックは、Web技術からインフラ運用まで一貫して対応し、AIを組み込んだ業務システムやWebアプリのプロトタイプ開発、段階的な導入設計を支援しています。要件が固まっていない段階でも、業務課題からご相談いただけます。

お問い合わせはこちら

FAQ：SEO・既存MCPサーバー・本番導入に関するよくある疑問

WebMCPを導入するとSEOは上がりますか？
WebMCP自体が検索順位を直接上げる要因とは断定できません。導入によってユーザーが検索、予約、問い合わせなどのタスクを完了しやすくなれば、導線や自己解決率などのUX改善につながる可能性はあります。順位ではなく、タスク完了率、離脱率、問い合わせ転換率などを実測して評価します。

既存のMCPサーバーがあればWebMCPは不要ですか？
一概には言えません。既存MCPサーバーが必要なデータ、機能、認証、権限を満たしているなら、その構成で十分な場合があります。ブラウザ上のライブな画面文脈で、自社Webアプリの機能を構造化して提示する必要があるかを基準に検討します。

今すぐ本番導入すべきですか？
重要な更新処理を全面的に任せるより、参照系の小さなPoCから始めることをおすすめします。対応環境、成功率、有人確認工数、監査、停止、復旧の運用を確認し、承認付きの限定操作へ段階的に広げます。

チャットボットはどう変わりますか？
回答だけを返すチャットボットから、ユーザーの許可を得て検索、予約候補確認、申請下書きなどのタスクへつなぐ設計を検討しやすくなります。ただし、回答と実行ではリスクが異なるため、操作範囲と承認方法を分ける必要があります。

まとめ：WebMCPで、AIが動けるWebアプリを先行して設計する

WebMCPは、Webアプリの機能をAIエージェント向けの構造化ツールとして公開するための、新しいWeb標準の候補です。画面を見て操作させるだけではなく、検索、予約、申請、下書き作成などの業務機能を、AIが理解しやすい形で提供できます。

ただし、WebMCPは通常のMCPサーバーやBrowser Useを置き換えるものではありません。自社APIや社内システムにはMCPサーバー、画面しかないサービスにはブラウザ自動化、ブラウザ上の自社WebアプリにはWebMCPというように、業務と統制に合わせて選ぶことが重要です。

導入するなら、参照系のPoCから始め、成功率、処理時間、有人確認工数、運用コストを測定します。そのうえで、認証・認可、最小権限、ユーザー承認、監査ログ、冪等性、異常検知、フォールバックを整え、操作系へ段階的に広げます。

これからのWebアプリには、人が使う画面だけでなく、AIが安全に使える操作面も求められます。株式会社エイムハックは、AIを組み込んだWebアプリ開発からインフラ運用まで対応し、先端技術を実際の業務で使えるシステムへ落とし込む設計・開発を支援します。WebMCPを含むAI連携を、自社の業務にどう組み込めるか検討している方は、ぜひご相談ください。

お問い合わせはこちら