この記事は、ECサイトを運営する事業責任者や担当者に向けて書いています。WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を使うと、商品検索や再注文のような操作をAIに任せられる可能性があります。読み終えると、自社サイトで「AIに開く操作」と「人が持つべき判断」を、どう仕分けるかが分かるようになります。
先にお断りします。WebMCPはW3Cの標準ではなく、W3CのWeb Machine Learning Community Groupが公開している仕様の草案です。Chromeではオリジントライアル（期間限定の試験提供）として提供されており、内容は変わる可能性があります。記事の内容は、2026年10月20日時点の確認に基づきます。
全体像はWebMCPの入門記事で扱っています。この記事は、その中でECサイトに絞った内容です。
ECサイトでWebMCPが関わる場面
ECサイトでは、利用者の行動がいくつかの段階に分かれます。探す、絞る、確かめる、買う、あとで買い直す、問題があれば返す、といった流れです。WebMCPのツールは、この流れの中の個々の操作を、エージェントが呼べる形にしたものです。
Chromeの公式資料の使いどころのページには、ECに近い例が紹介されています。購入の例として、search_products()、add_to_wishlist()、refine_search() といったツールが挙げられています。再注文の例としては、get_order_history() と、受け取り方法を指定する delivery(method="pickup") があります。これらはChrome資料の例であり、自社のサイトにそのまま当てはまるとは限りません。
ここで大事なのは、ツールが増えれば便利になる、とは限らないことです。どの操作を開き、どれを人に残すか。その線引きを先に決めることが、ECでは特に重要です。お金と配送が絡むからです。
AIに開く操作の候補
操作を、読み取り系と、確認が要る系に分けて考えます。以下の表は、考え方の一例です。仕様に書かれた分類ではありません。商品や機能はすべて架空の例で、特定の店舗や実績とは関係ありません。
| 操作（架空の例） | 種類 | 考え方 |
|---|---|---|
| 商品を検索する | 読み取り系 | 状態を変えない。最初に開く候補になりやすい |
| 条件で絞り込む | 読み取り系 | 色・サイズ・価格帯など。入力は具体的な型で受ける |
| 在庫を確認する | 読み取り系 | 返す内容が古くならないよう、取得元に注意する |
| 配送の見込みを調べる | 読み取り系 | 「見込み」であることを返答に含める |
| ウィッシュリストに入れる | 軽い書き込み | 取り消しやすい。利用者の画面に反映させる |
| 過去の注文を呼び出して再注文の候補にする | 確認が要る系 | 利用者の情報が見える。カートに入れるまでに留める案もある |
| 返品を受け付ける | 確認が要る系 | 取り消しにくく、規約も絡む。人の確認を挟む前提にする |
| 購入を確定する・決済する | 確認が要る系 | 人が確認する。最初は開かないことも選択肢 |
読み取り系のツールには、仕様の草案にある readOnlyHint（読み取りのみを示す注釈）を付けられます。Chrome資料も、readOnlyHint は状態を変えないことを示し、確認が要るかを判断する材料になると説明しています。
一方、購入や返品のように取り消しにくい操作には、consequentialHint（実世界への影響や取り消せない操作を示す注釈）を付けられます。Chrome資料によれば、これを手がかりに、エージェントやブラウザが利用者の確認を求められます。ただし、草案の本文は、実行時の確認を必須とは定めていません。確認の仕組みは、クライアント（エージェントを動かす側）の作りに左右されます。自社側でも、確認を前提にした設計にしておくのが安全です。
人が持つべき判断
ECで最後まで人に残すべきなのは、お金と契約に関わる判断です。具体的には、次のような場面です。
- 購入の確定：数量、届け先、金額を見て、買うと決める判断。
- 決済：支払い方法の選択と、支払いの実行。
- 返品や交換の可否：規約と状況に照らした判断。
- 個人情報の扱い：どの情報をエージェントに見せてよいかの判断。
Chromeの資料は、購入など重要な操作では、ユーザーに確認ダイアログを出す指示をツールに含められる、と述べています。また、仕様の草案は、宣言と実際の動作が一致する保証がない点をリスクに挙げています。例として、finalizeCart という名前のツールが、実際には購入まで行ってしまう場合です。名前は実際の動作と一致させる（購入まで行うなら、確定と分かる名前にする）という配慮が要ります。
確認の設計は、人の確認を挟む設計の記事で詳しく扱っています。また、Chromeの資料は、ローカルのブラウザで人が関わる使い方を主に想定しています。完全に無人で購入まで進める運用を想定したものではない、という点も押さえておいてください。
なお、決済、個人情報、返品、表示のルールなどには、業種ごとの法令や業界の決まりが関わります。この記事では踏み込みません。自社に当てはまるものは、法務などの専門家に確認してください。
既存の検索フォームやカートとの関係
すでにECサイトには、検索フォームやカートがあるはずです。WebMCPは、それを作り直すものではありません。仕様の位置づけは、人間向けの画面が主役のままで、ツールはそれを補う、というものです。
Chromeの資料では、ツールの登録方法が二つ紹介されています。一つは、JavaScriptで registerTool を呼ぶ方法（命令型API）です。もう一つは、HTMLのフォームに toolname と tooldescription という属性を付ける方法（宣言的API）です。後者は、Chrome資料では紹介されていますが、W3C草案の本文にはまだ含まれていません。
宣言的APIでは、エージェントがツールを呼ぶと、ブラウザがフォームに入力します。フォームは、利用者に見える状態のままです。既定では、利用者が送信ボタンを押して完了します。toolautosubmit を付けると自動で送信されますが、ECの購入のような操作に付けるかどうかは、慎重な判断が要ります。
この性質は、ECにとって扱いやすい面があります。既存の検索フォームがあれば、Chrome資料の言う「2ステップ」で、ツールにできる可能性があります。しかも、利用者は画面で何が起きているかを見られます。画面の状態とツールの結果がずれないよう、関数の完了後に画面を更新することも、Chromeのベストプラクティスで勧められています。
カートは、読み取りと書き込みが混ざる場所です。中身の確認は読み取り系ですが、数量の変更や削除は書き込みです。ここは分けて考えてください。ツールの設計の基本は、ツール設計の記事にまとめています。
よくある失敗
ECで起こりやすい失敗を、表にまとめます。仕様に書かれた失敗例ではなく、ツール設計の考え方から導いた注意点です。
| 失敗 | 起きること | 対策の方向 |
|---|---|---|
| 価格や在庫が古い | エージェントが古い情報を利用者に伝える | 表示と同じ取得元を使い、取得時点が分かる返答にする |
| 似たツールの乱立 | 「商品を探す」「商品を検索する」が並び、選び間違いが起きる | 1ツール1機能にして、重複を避ける |
| 名前と動作が食い違う | 確認なしに購入や返品が進む | 名前を動作と一致させ、consequentialHint を付ける |
| 厳しすぎる入力検査 | エージェントが先に進めなくなる | スキーマは緩く、検証はコードで厳しく。次の手が分かるエラーを返す |
| 失敗時に何も返さない | エージェントが立て直せない | 「先に検索してください」のように、誘導先を伝える |
| 利用者の情報を出しすぎる | プライバシー上の問題になりうる | 返す項目を最小にし、専門家にも確認する |
「検証はコードで厳しく、スキーマでは緩く」という考え方は、Chromeのベストプラクティスにある表現です。たとえば、色の指定がスキーマと少し違っても、エージェントを止めるのではなく、実行側で受け止めて、選べる色を返す、といった形です。
返す内容の量にも注意してください。Chromeの安全性ガイダンスは、エージェントに見せる量の目安として、ツール名とパラメータ名は30文字、ツールの説明は500文字、パラメータの説明は150文字、ツールの出力は1.5K文字を挙げています。一方、W3C草案の上限は、名前128文字以内です。短く書くほうが安全です。
また、レビューや商品説明のように、利用者や外部が書いた文章を返すツールもあります。そこには、悪意のある指示が紛れる可能性があります（プロンプトインジェクション）。Chromeの資料は、そうした内容を返すツールに untrustedContentHint を付けるよう説明しています。ただし、Chrome資料自身が、LLMの内側で安全を保証することは不可能だと述べています。注釈は万能ではありません。
最初の一歩
いきなり購入まで開く必要はありません。次の順で進めると、無理がありません。
- 操作を書き出す：サイト上で利用者ができる操作を、一覧にする。
- 仕分ける：読み取り系／軽い書き込み／確認が要る系に分ける。
- 読み取り系から始める：商品検索と絞り込みなど、状態を変えないものを少数だけ開く。
- 会話を想定する：利用者が実際に口にしそうな言葉で、やり取りを書いてみる。Chromeの資料も、会話のロールプレイを設計の手順に挙げています。
- DevToolsで確かめる：ChromeのDevToolsのApplicationタブにWebMCPの画面があり、登録したツールの一覧や呼び出しの履歴を見られます。
- 評価して見直す：どのツールが選ばれるか、引数が合っているかを確かめる。ツールの数の考え方は、AIエージェント対応サイトのチェックリストも参考になります。
ローカルでの検証には、chrome://flags/#enable-webmcp-testing のフラグを使えます。本番の利用者に向けて公開するかどうかは、オリジントライアルの条件も含めて、Chromeの最新の資料で確認してください。
注意点
- 仕様は変わります。WebMCPはW3Cの標準ではなく、コミュニティグループの草案です。Chromeの資料も、議論の最中で変更される可能性があると明記しています。
- 対応状況は限られます。Chromeではオリジントライアルです。Edgeなど他のブラウザの対応時期は、確認できていません。
- 画面が主役です。ツールは、人が使う画面を補うものです。バックエンドの連携の代わりでもありません。
- 購入と決済は人が確認します。草案は確認を必須としていないため、自社でも確認の設計を用意してください。
- 法令と個人情報は専門家に確認します。決済、返品、表示、個人情報の扱いは、業種や契約によって条件が異なります。
Otsumuに相談できること
操作の棚卸しと、読み取り系・確認が要る系の仕分けは、社内でも始められます。まずは、サイトでできる操作を書き出してみてください。
どの操作をAIに開くか、確認をどこに挟むか、既存の検索フォームやカートとどうつなぐかは、実装との兼ね合いで悩みやすい部分です。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、その一環として、サイトを「AIが使える形」にする設計もご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。この記事の例はすべて架空の例です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20