WebMCP がチェックアウトに対応 ブラウザエージェントが「決済の手前」まで手伝える

図解 ： WebMCP support for checkout（チェックアウトの WebMCP 対応） Developer Changelog / Checkout × AI エージェント WebMCP がチェックアウトに対応 ブラウザエージェントが「決済の手前」まで手伝える 購入者のブラウザ上で動く AI エージェントが、WebMCP ツールで進行中のチェックアウトを読み取り・更新できるようになった。3D セキュア認証のように本人の入力が必要な場面では、操作を購入者に返す。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： エージェントと購入者の役割分担 チェックアウトで呼べる 4 つのツール 買い物の全行程がカバーされた 導入条件・前提 典型的な呼び出しの流れ（4ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか ストアフロント・カート向けの WebMCP ツールはすでに公開済み。今回 チェックアウト向けのツール が加わり、 ブラウザエージェントは 商品探し → カート操作 → チェックアウト → 注文確認 までを手伝えるようになった。 これまで ： カートまで ストアフロントとカートのツールは提供済みだったが、チェックアウトに入った後の操作はツールの対象外だった。 これから ： 注文確認まで 購入者のブラウザセッション内のアクティブなチェックアウトを、エージェントが読み取り・更新・（購入者の確認後に）送信できる。 2 仕組み図解 ： エージェントと購入者の役割分担 ツールは checkout-web の内部 で動き、 チェックアウト UI と同じ状態 を使う。エージェントは画面とは別の裏口を通るのではなく、購入者が見ているチェックアウトそのものを操作する。 本人の入力が必要な場面（3D セキュア認証、ブロッキング UI 拡張など）では、ツールが 購入者に操作を返す 。 3 チェックアウトで呼べる 4 つのツール ストアフロントへ移動 navigate_to_storefront チェックアウトからストアフロントに戻る 状態を読む get_checkout チェックアウトの状態・メッセージ・完了後の注文詳細 項目を更新 update_checkout サポートされたチェックアウト項目を更新 送信 complete_checkout 購入者の確認後に チェックアウトを送信 update_checkout で更新できる「サポートされた項目」の具体的な一覧は本記事に記載なし。各ツールの引数・戻り値の仕様も記載なし（詳細は「WebMCP tools for checkout」のドキュメント参照）。 4 買い物の全行程がカバーされた 段階 ツール群 状況 商品探し ストアフロントツール 提供済み カート管理 カートツール 提供済み チェックアウト get_checkout / update_checkout / complete_checkout / navigate_to_storefront 今回追加 注文確認 get_checkout （完了後の注文詳細） 今回追加 5 導入条件・前提 マーチャントの設定は不要 記事には「マーチャントの設定は不要」と明記されている。 新しい API は追加されない ツールは checkout-web の内部で動き、新しい API を公開するものではない。 購入者のブラウザが前提 対象は購入者のブラウザセッション内のアクティブなチェックアウト。ブラウザから買い物をするエージェント向け。 対応プラン・対応地域・対応ブラウザ、無効化（オプトアウト）の方法については本記事に記載なし。 6 典型的な呼び出しの流れ（4ステップ） 1 状態を読む get_checkout で現在の状態とメッセージを取得。 2 項目を更新 update_checkout でサポートされた項目を埋める。 3 購入者が確認 3D セキュア等が必要なら購入者に操作が戻る。 4 送信・注文確認 確認後に complete_checkout 、完了後は get_checkout で注文詳細。 最終的な送信は購入者の確認が前提。 エージェントが勝手に決済を確定させる設計ではなく、本人の入力が要る場面は購入者に戻す。 7 技術者が押さえるべき5つのポイント 1. UI と同じ状態を共有 ツールは checkout-web 内で動き、チェックアウト UI と同じ状態を使う。エージェントによる更新と画面表示が別々の状態を持つわけではない。 2. 新しい API ではない サーバー側の新エンドポイントや API が増えるわけではない。購入者のブラウザ内で完結するツール群として理解する。 3. ブロッキング UI 拡張は購入者に戻る 購入者の入力を必要とするブロッキング UI 拡張があると、エージェントから購入者に操作が返る。自社の Checkout UI 拡張がエージェント経由の購入フローで「止めどころ」になる点を意識する。 4. 認証は人間が担う 3D セキュア認証のような本人確認は購入者に戻る設計。送信（ complete_checkout ）も購入者の確認後という位置づけ。 5. ストアフロント・カートと合わせて一気通貫 既存のストアフロント／カートツールと組み合わせることで、商品探索から注文確認までをエージェントが支援できる。コマースエージェントを作る側は、ツール一式を前提にした体験設計が可能になる（詳細は「building commerce agents」のドキュメント参照）。 8 業務に活かせる3つのユースケース USE CASE 1 チェックアウトのカスタマイズを「エージェント経由でも止まらないか」点検する 課題 Checkout UI 拡張を入れているストアで、ブラウザエージェント経由の購入がどこで購入者に戻るのか把握できていない。 打ち手 チェックアウトに入っている UI 拡張を棚卸しし、購入者の入力を要求するブロッキング型のものを洗い出す。 効果 エージェント経由の購入で購入者に操作が戻るポイントが明確になり、必要な拡張とそうでない拡張を整理できる。 技術メモ ブロッキング UI 拡張では購入者に制御が返る（記事記載）。どの拡張がブロッキング扱いかの判定基準は本記事に記載なし。 USE CASE 2 コマースエージェント開発で「注文確認まで」を一気通貫で設計する 課題 ブラウザエージェントで Shopify ストアの購入支援を作りたいが、カート以降をどう扱うかが決まらない。 打ち手 ストアフロント／カートツールに加え、 get_checkout → update_checkout → 購入者確認 → complete_checkout → get_checkout （注文詳細）の流れで設計する。 効果 商品探索から注文確認までを同じツール体系で組める。マーチャント側の設定作業も不要。 技術メモ 3D セキュア等で購入者に制御が戻る前提で、エージェント側は「待ち」と「再開」の状態を持たせる設計にする。 USE CASE 3 マーチャント向けに「AI エージェント経由の購入」を説明する 課題 「AI に勝手に決済されるのでは」「何か設定が必要なのか」という問い合わせに答えられない。 打ち手 本記事の要点（マーチャント設定不要／新 API なし／送信は購入者確認後／3D セキュア等は購入者に戻る）を整理して共有する。 効果 不安を解消しつつ、エージェント経由の購入がすでに成立しうる前提で施策を検討できる。 技術メモ オプトアウト方法や対応範囲は本記事に記載なし。案内時は公式ドキュメントで最新情報を確認すること。 9 提案で使える1行サマリ 「ブラウザエージェントが WebMCP で Shopify のチェックアウトを読み取り・更新できるようになり、 商品探しから注文確認まで AI が手伝える。マーチャント設定不要・新 API なし、 認証や最終確認は購入者に戻る安全設計。」 source ： shopify.dev / changelog / webmcp-support-for-checkout 公開日 2026-09-28