
ShopifyがWebMCPをチェックアウトに拡張、AIエージェントが注文確定まで対応
Shopifyが9月28日、WebMCPツールをチェックアウトに拡張した。ブラウザエージェントは購入者のタブで開いているチェックアウトを読み取り、更新し、購入者の確認を得た上で注文を確定できるようになった。
8月時点のWebMCPは商品検索とカート管理が中心だった。チェックアウトページへの誘導はできたが、注文の確定は購入者自身が行う必要があった。今回の拡張でAIエージェントが購入完了まで関与する形になる。
この記事では4つの新ツールの役割、購入者が制御を取り戻す場面、ブラウザ自動化との比較テスト結果を解説する。
WebMCPチェックアウト拡張の概要

8月の展開からの進化
WebMCPとは、ブラウザ内でAIエージェントがWebサイトの機能を利用するための仕組みだ。Shopifyは2026年8月に最初のWebMCPツールを公開した。当時は商品検索とカート管理が中心で、エージェントは購入者をチェックアウトページまで誘導するに留まっていた。
9月28日の拡張により、ブラウザエージェントはチェックアウトの状態を読み取り、配送先や支払い方法を更新し、購入者の確認を得た上で注文を確定できる。Shopifyの開発者向けチェンジログは「新しいAPIを公開するわけではなく、マーチャントの設定も不要」と説明している。
新しいツールの仕組み
新しいツールは購入者が見ているチェックアウトページと同じ状態を利用する。エージェントが裏側で別のセッションを操作するのではなく、実際に開いているチェックアウトの状態を読み書きする仕組みだ。
これにより購入者とエージェントの間で情報のずれが生じにくい。チェックアウトは各更新時に独自の検証を行い、エージェントが注文の商品を変更することはできない設計になっている。
このデモは8月時点と9月28日以降のWebMCPの機能差を示している。エージェントが「誘導役」から「取引実行役」に変わった点が今回の拡張の本質だ。
チェックアウトで利用できる4つのツール

各ツールの役割
ShopifyのチェックアウトWebMCPドキュメントによると、対象となるチェックアウトには4つのツールが登録される。
- get_checkoutはチェックアウトを読み取り、購入後は注文詳細も取得する
- update_checkoutは連絡先、配送または受け取り方法、割引コード、支払い方法、税番号などの追加項目を変更する
- complete_checkoutは注文を確定する
- navigate_to_storefrontはタブをストアに戻す
4つのツールは役割が明確に分かれている。読み取り、更新、確定、移動という一連の流れをエージェントが実行できる設計だ。
支払い方法の制限
これらのツールは新しいカード情報を受け付けない。エージェントは保存済みのShop Payカードを選択するか、ゲストチェックアウトが許可している場合はエージェントが持っているShop Pay承認を利用して支援できる。
それ以外の支払い方法は購入者がチェックアウトページで直接選択する必要がある。エージェントはあくまでもShop Payの範囲内で支払いを支援する形だ。これはエージェントがクレジットカード情報を扱うリスクを避ける設計といえる。
また、エージェントはWeb Bot Authを使用してブラウザリクエストに署名する必要がある。Web Bot AuthとはShopifyがエージェントを認識するための署名方式だ。署名がない場合、リクエストは優先度が下がったり、ボット検出システムによってブロックされたりする可能性がある。
購入者が制御を取り戻す場面

注文確定前の同意
Shopifyのドキュメントは、complete_checkoutを呼び出す前に現在の注文と合計を購入者に表示し、「注文の許可を得ること」をエージェントに指示している。
注目すべきは、Web Bot Auth署名、Shop Pay承認、準備完了ステータスはこの同意には該当しない点だ。エージェントが技術的に注文を確定できる状態であっても、人間の購入者が最終確認を行わない限り注文は実行されない。
これはAIエージェントの暴走を防ぐ安全設計として評価できる。自動化が進んでも、最終的な購入判断は人間が行うという原則を守っている。EC事業者にとっては、エージェントが勝手に注文を確定してしまうリスクを抑えられる仕組みだ。
支払いチャレンジとUI拡張
Shop Payログインや3D Secureなどの支払いチャレンジは、購入者にページ上での制御を戻す。3D Secureとはオンラインカード決済の追加認証方式で、不正利用を防ぐためにパスワードや生体認証を求める仕組みだ。
ブロッキングUI拡張機能やレビューステップも同様に、購入者が直接操作する場面となる。購入者はアプリが定義するチェックアウト拡張機能とのやり取りも管理する。エージェントがすべてを代行するのではなく、特定の場面では必ず人間が介入する仕組みになっている。
対象チェックアウトの条件と利用環境

Shop Pay必須の制限
Shopifyの標準3ページチェックアウトは、購入者がShop Payでチェックアウトする場合を除き、WebMCPツールを取得しない。B2Bチェックアウト、埋め込みチェックアウト、モバイルチェックアウトSDK内のチェックアウトも対象外だ。
他のショップの商品を含むチェックアウト、ドラフト注文、注文編集、支払い回収も除外される。この制限はマーチャントにとって重要な意味を持つ。すべてのチェックアウトでAIエージェントが注文を確定できるわけではない。
現時点ではWebMCPチェックアウトの適用範囲は「Shop Payを使う標準チェックアウト」に限られる。Shop Pay以外の支払い方法を選ぶ購入者には、エージェントはチェックアウトの支援ができない。この制限がWebMCPチェックアウトの普及にどの程度影響するかは、今後の利用データを見る必要がある。
Chromiumブラウザ限定
現時点では、エージェントがWebMCPを使用できるのはChromiumベースのブラウザのみだ。ChromiumとはGoogleが開発するオープンソースのブラウザエンジンで、Google ChromeやMicrosoft Edgeが採用している。
FirefoxやSafariでは利用できない。この制限はWebMCPの普及に影響を与える可能性がある。ただしChromeとEdgeがブラウザ市場の大部分を占めていることを考えると、実用上の影響は限定的かもしれない。
Checkout WebMCPとCheckout MCPの選択

2つのルートの違い
Shopifyはチェックアウトでのエージェント向けに2つのルートを文書化している。サーバーベースのCheckout MCPと、ブラウザ内で動作するCheckout WebMCPだ。
ShopifyはサーバーベースのCheckout MCPを推奨している。この方式ではエージェントが自身のサーバーからチェックアウトセッションを管理する。Checkout WebMCPは「エージェントがすでに購入者のブラウザで動作している場合のみ」使用するよう案内している。
両方ともUniversal Commerce Protocolのチェックアウト機能に依存し、同じチェックアウトオブジェクトを使用する。Universal Commerce ProtocolとはShopifyが提唱する商取引の共通プロトコルで、異なるシステム間で取引情報をやり取りするための標準仕様だ。
Checkout WebMCPはチェックアウトページが購入者のブラウザに登録するツールを通じて動作する。一方、Checkout MCPはサーバー側でリクエストを処理する。実行場所が異なるだけで、扱うデータは同じだ。
マーチャントの立場
どちらの方法でも、Shopifyはマーチャントが記録上のマーチャントのままであると説明している。エージェントが仲介者になっても、販売者としての責任はマーチャントに残る。
これは法的・会計的な観点で重要なポイントだ。AIエージェントが注文を確定しても、取引の主体はあくまでもマーチャントである。エージェントが誤った注文を確定した場合の責任の所在も、マーチャントが負うことになる。
ブラウザ自動化との比較テスト

成功率と速度の差
Shopifyのエージェンティックコマース担当チームに所属するGil Greenberg氏は、WebMCPとブラウザ自動化を比較する社内テストの結果を公開した。ブラウザ自動化とは、エージェントがページを読み取ってクリック操作を行う方式だ。画面上の要素を視覚的に認識して操作する必要があるため、処理が遅くなりがちだ。
テストはGPT-6 Solを使って、同じプロンプトと開始条件で実施された。2つのテストショップで合計10のチェックアウトタスクを実行した結果、WebMCPは60回すべて成功した。一方、ブラウザ自動化は60回中56回の成功だった。
ページセットアップ時間を除いた1回あたりの時間は、WebMCPが10.3秒、ブラウザ自動化が27.4秒だった。WebMCPが約2.7倍高速だった計算になる。
1回あたり 10.3秒
コスト 58%削減
1回あたり 27.4秒
コスト 基準値
この比較はWebMCPの優位性を示している。成功率、速度、コストの3つの指標すべてでWebMCPが上回った。
コスト面の優位性
コスト面でもWebMCPが優位だった。OpenAIのリスト価格で比較すると、WebMCPのコストは1回あたり58%低かった。速度が速いだけでなく、API呼び出し回数やトークン消費量も抑えられるためだ。
ただし、この結果には注意点がある。テストはShopifyのテストショップと単一モデルで行われたもので、実際の注文やコンバージョン率などの実データは含まれていない。また、Greenberg氏の投稿には1行だけ60回の試行と一致しない合計値が含まれている。
とはいえ、WebMCPが「有望な方向性」を示していることは間違いない。ブラウザの画面を読み取ってクリックする方式よりも、専用のツールを介して直接操作する方式のほうが効率的であることは、このテスト結果から十分に裏付けられている。
この記事のポイント
- Shopifyが9月28日、WebMCPをチェックアウトに拡張した
- エージェントがチェックアウトの読み取り、更新、注文確定まで実行できる
- 注文確定には購入者の明示的な同意が必須
- Shop Pay必須の制限があり、対象チェックアウトは限定的
- ブラウザ自動化との比較テストで成功率100%、速度2.7倍、コスト58%削減を達成
- マーチャントが個々のツールをオフにできるかは未確認

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

Google-Agent登場でSEO激変?エージェント・ウェブの到来とWebMCPの衝撃
Googleが新しいユーザーエージェント「Google-Agent」を発表した。これは単なる情報の収集だけでなく、AIエージェントが人間に代わってウェブサイト上で「行動」することを前提とした仕組みだ。従来の「人間がブラウザでページを閲覧する」というウェブのあり方が、根本から覆されようとしている。
この変化は、SEO(検索エンジン最適化)の歴史において最も大きなパラダイムシフトになると予測されている。これまではキーワードで検索結果の上位を狙い、ユーザーのクリックを誘発することがゴールだった。しかし、これからは「AIエージェントがいかにスムーズにサイトの機能を利用できるか」が重要になる。
本記事では、Googleが推進する「エージェント・ウェブ」の正体と、それを支える技術プロトコル、そして今後のウェブ運営者が取るべき対策について深掘りしていく。検索の未来は、単なる情報の提示から「タスクの完了」へと急速にシフトしているのだ。
Google-Agentとは何か?新しいクローラーが示唆する未来

Googleが新たに導入した「Google-Agent」は、特定のAIエージェントがユーザーの指示を受けてウェブサイトにアクセスする際に使用される識別子だ。Google DeepMindが開発した「Project Mariner」のような、ブラウザを操作するAIモデルがこれを利用する。従来のGooglebotが検索インデックス作成のために巡回するのに対し、Google-Agentは「実務の代行」のためにサイトを訪れる点が異なる。
ユーザーに代わって「行動」するAIエージェント
AIエージェントとは、ユーザーの意図を汲み取り、自律的にタスクを実行するソフトウェアのことだ。例えば「来週の出張のために、予算3万円以内で東京駅近くのホテルを予約してほしい」と頼めば、エージェントが複数のサイトを巡回し、条件に合うプランを見つけ、予約フォームの入力まで済ませてくれる。この一連の動作において、人間は一度もサイトの画面を見る必要がない。
Googleの検索部門責任者であるLiz Reid氏は、将来的に「多くのエージェント同士が会話する世界」が来ると予測している。ユーザーのエージェントがホテルの予約システム(エージェント)と直接交渉し、最適な取引を成立させる。これが、Googleが描く「エージェント・ウェブ」の姿だ。
Google-Agentの識別とサイト側の対応
Google-Agentは、HTTPリクエストのUser-Agentヘッダーに含まれる。これにより、ウェブサイトの運営者は「今アクセスしているのは人間か、それともGoogleのAIエージェントか」を判別できる。Search Engine Journalの記事によれば、モバイル版とデスクトップ版の両方でこの新しいタグが使用されることが確認されている。
現在、多くのSEO担当者が「AIによるクローリングを拒否すべきか」を議論している。しかし、Google-Agentをブロックすることは、AIエージェント経由で訪れる「購買意欲の高いユーザー」を門前払いすることと同義だ。これからのウェブサイトは、AIが読みやすく、かつ操作しやすい構造を持つことが生き残りの条件となる。
「エージェント・ウェブ」を支える5つの主要プロトコル

AIエージェントがウェブサイトを効率的に利用するためには、人間向けの視覚的なUI(ユーザーインターフェース)だけでは不十分だ。Googleは、マシン同士がデータをやり取りし、機能を実行するための複数のプロトコルを提唱している。これらは、今後のウェブ開発における共通言語となる可能性が高い。
WebMCP:サイトの機能をネイティブに操作する
WebMCP(Model Context Protocol)は、AIエージェントがウェブサイトのバックエンドデータや機能に安全にアクセスするための仕組みだ。従来のブラウザ操作では、AIは画面上のピクセルを解析してボタンの場所を探す必要があり、処理が遅くエラーも起きやすかった。WebMCPを使えば、エージェントはサイトが提供する「ツール」を直接呼び出せるようになる。
例えば、問い合わせフォームを埋める際、エージェントはHTMLの構造を解析するのではなく、WebMCP経由で必要なデータ項目を直接受け取り、正確な値を流し込む。これにより、人間が操作するよりも遥かに高速かつ正確なタスク実行が可能になる。これは、ウェブサイトが「閲覧される文書」から「呼び出し可能なAPIの集合体」に変わることを意味している。
UCPとA2A:AI同士が商談し決済する世界
ECサイトにとって特に重要なのが、UCP(Universal Commerce Protocol)だ。これは、検索結果画面(SERPs)から直接、AIが商品の購入手続きを行えるようにするプロトコルだ。ユーザーは商品詳細ページに遷移することなく、AIアシスタントに「これを買って」と伝えるだけで注文が完了する。
また、A2A(Agent to Agent)は、異なるサービスのエージェント同士が通信するための規格だ。Marie Haynes氏によれば、将来的には「私のSEOエージェントが、あなたの提供するツールのエージェントと価格交渉を行う」といったシナリオも現実味を帯びている。ビジネスの接点が、人間対人間から、プログラム対プログラムへと移行していくのだ。
このデモは、従来の人間主体のウェブ閲覧と、AIエージェントが直接システムと対話する次世代のウェブ構造の違いを視覚化したイメージだ。
検索の概念が変わる。AI Searchへの完全移行

GoogleのNick Fox氏は「検索はAI Search(AI検索)になりつつあり、Geminiアプリはあなたのパーソナルアシスタントである」と述べている。これは、従来の「10本の青いリンク」が並ぶ検索結果ページが、最終的にはAIとの対話インターフェースに吸収されることを示唆している。Googleは「AIモード」と「AI Overviews(AIによる概要回答)」を一体のものとして捉え始めている。
「検索結果」から「パーソナルアシスタント」へ
これまでの検索エンジンは、ユーザーが入力したクエリに対して「関連する可能性が高いページ」を提示する場所だった。しかし、これからのGoogleは、ユーザーの代わりに問題を解決する「アシスタント」へと進化する。ユーザーが情報を探す手間を省き、答えを直接提示したり、アクションを実行したりすることが主目的となる。
この変化により、ウェブサイトへの流入(クリック数)は減少する可能性がある。AIが検索結果画面でユーザーの疑問を解決してしまえば、サイトを訪れる必要がなくなるからだ。しかし、Marie Haynes氏は、これを「摩擦のない商取引(フリクションレス・コマース)」のチャンスだと捉えている。クリックを稼ぐのではなく、AIを通じて直接コンバージョン(成果)を得るモデルへの転換が求められている。
コンテンツ制作者とプラットフォームの新たな関係
1998年の創業以来、Googleとコンテンツ制作者の間には「コンテンツを提供すれば、代わりにトラフィックと広告収益を還元する」という暗黙の了解があった。しかし、AIがコンテンツを学習し、その要約をユーザーに提供する現在のモデルでは、このパートナーシップは崩壊しつつあるとの見方もある。
これからのクリエイターや企業は、単に情報を発信するだけでなく、AIエージェントが「利用できる価値」を提供する必要がある。それは独自のデータであったり、AIが実行可能な特定のサービス機能であったりする。情報の「量」ではなく、エージェントにとっての「有用性」が、新しい評価軸となるだろう。
実務者が今すぐ取り組むべき3つのアクション

エージェント・ウェブの全貌はまだ不透明だが、今から準備を始めることは可能だ。技術の進化をただ待つのではなく、AIが好むサイト構造へと段階的にシフトしていくことが推奨される。ここでは、具体的な3つのステップを挙げる。
構造化データを超えた「機能の公開」
これまでのSEOでは、Schema.orgなどの構造化データを用いて、情報の意味を検索エンジンに伝えてきた。これからはさらに一歩進んで、サイトの「機能」をAIが利用できるように整備する必要がある。具体的には、WebMCPのようなプロトコルの動向を注視し、将来的にAPIやエージェント専用のインターフェースを提供できる準備をしておくことだ。
特にECサイトを運営している場合は、UCP(Universal Commerce Protocol)について学ぶことが不可欠だ。Googleのショッピング機能と連携し、AIが商品を正しく認識し、決済フローを理解できるようにデータを整えておくことが、将来の売上に直結する。
「バイブ・コーディング」による開発スピードの向上
Marie Haynes氏は、AIツールを活用して直感的に開発を行う「バイブ・コーディング(Vibe Coding)」の重要性を説いている。Claude CodeやGoogle AI Studioなどのツールを使い、自然言語で指示を出しながら、AIエージェントに対応した機能を素早く実装していく手法だ。
技術的な詳細をすべて手書きするのではなく、AIと対話しながら「エージェントが使いやすい構造」をプロトタイピングしていく。このスピード感が、変化の激しいAI時代には武器になる。開発者だけでなく、マーケターもこれらのツールに触れ、AIがどのようにコードやデータを解釈するのかを肌感覚で理解しておくべきだ。
独自分析:SEO担当者は「エージェント最適化」へ舵を切るべきか

筆者の見解として、今後のSEOは「Search Engine Optimization」から「Agentic Ecosystem Optimization(エージェント・エコシステム最適化)」へと変質していくだろう。これまでは「人間にどう見せるか」というUX(ユーザーエクスペリエンス)が重視されてきたが、今後はそれに加えて「AIエージェントにとっての使い勝手」を考慮したAX(エージェントエクスペリエンス)が重要になる。
これは、小規模なサイト運営者にとっては大きなチャンスかもしれない。巨大なドメインパワーを持つサイトが検索結果を独占する時代から、特定のタスクを最も効率的に解決できるエージェントを持つサイトが選ばれる時代になる可能性があるからだ。ユーザーの「悩み」を解決する具体的な「機能」を提供できれば、検索順位に関わらずAIエージェントがあなたのサイトを指名してくれるようになるだろう。
一方で、単なる情報のまとめサイトや、独自の価値がないコンテンツは、AI Overviewsによって完全に代替され、存在意義を失うリスクが高い。これからのウェブサイトは、単なる「情報の置き場所」ではなく、特定の目的を遂行するための「道具」として再定義される必要がある。Google-Agentの登場は、その長い旅の始まりに過ぎない。
この記事のポイント
- Google-Agentは、AIエージェントがユーザーに代わってサイトを操作するための新しい識別子だ。
- WebMCPやUCPといった新プロトコルにより、AIがサイトの機能をネイティブに利用可能になる。
- 検索は「情報の提示」から「タスクの実行(パーソナルアシスタント)」へと進化している。
- 今後のSEOは、クリックを稼ぐことよりも、AIエージェントを通じた直接的なアクションの完了を目指すべきだ。
- 「バイブ・コーディング」などのAI開発ツールを活用し、変化に即応できる体制を整えることが重要だ。

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
