Shopify チェックアウト カスタマイズをWebMCPで実装する方法

Shopify チェックアウト カスタマイズを支えるCheckout WebMCPとは

Checkout WebMCPは、購入者が開いているチェックアウトタブ内に登録されるツール群です。店員のいるレジをイメージすると分かりやすいでしょう。エージェントはカートを運び、フォームを読み、対応項目へ入力できますが、本人確認や決済認証への対応と最終承認は購入者が行います。

これは、Shopifyが先に提供していたストアフロント向けツールの拡張です。対応するブラウザエージェントは、カタログ検索、商品の確認、カート更新を行い、proceed_to_checkoutを呼び出せます。対象のチェックアウトに入るとツール一覧が切り替わり、次の4つのチェックアウトツールが利用可能になります。

• get_checkoutは、現在のチェックアウト、またはThank youページに表示された注文レシートを読み取ります。
• update_checkoutは、注文を確定せずに、対応する連絡先、受取方法、割引、申告フィールド、決済状態を置き換えます。
• complete_checkoutは、購入者の確認後に注文確定を試みるか、確認ステップを開きます。
• navigate_to_storefrontは、ストアフロントがある場合に同じタブをストアへ戻します。

チェックアウトの実装には、UCPのチェックアウトオブジェクト、ステータス、メッセージが使われます。UCPは、このフローを支える共通のデータ契約です。WebMCPは、その契約をブラウザからエージェントへ公開する仕組みです。サーバー側で動くエージェントには、ShopifyのCheckout MCPを使います。

加盟店が有効にする新しいスイッチも、別途導入するチェックアウトAPIもありません。加盟店にとっては導入しやすい一方、エージェント開発者の作業がなくなるわけではありません。ブラウザ対応、Web Bot Auth、慎重な状態管理、そして明確な同意の境界は依然として必要です。

まず対象となるチェックアウトか確認する

最初に確かめるべきなのはツールが検出できるかどうかです。ストアフロントでWebMCPが使えたからといって、ShopifyのチェックアウトでもCheckout WebMCPが公開されるとは限りません。

Shopifyは、次のケースではチェックアウトツールを登録しません。

• 購入者がShop Payを使う場合を除く、標準の3ページ構成チェックアウト
• B2Bチェックアウト
• 埋め込みチェックアウト、またはモバイルチェックアウトSDKのフロー
• 別のショップの商品を含むチェックアウト
• 下書き注文、注文編集、決済の回収
• チェックアウトUI拡張機能が提供する操作

こうしたフローでは、ページ上の操作を購入者に引き継ぎます。ブラウザ側にはcancel_checkoutツールもありません。ツールが見つからないからといって、ページのUIを直接操作してよいことにはなりません。

Shopifyによると、ストアフロントWebMCPは現在、Chromiumベースのブラウザでのエージェント対応を前提としています。テストには、対応ブラウザと自分で管理できるチェックアウトを使います。チェックアウトツールが表示されなくても、それは想定された適格性判定です。不安定なクリック操作へ切り替える理由にはなりません。

1. ブラウザエージェントを認証し、ツールを検出する

認証情報をツール引数へ入れるのではなく、Web Bot Auth（WBA）でブラウザからのリクエストに署名します。WBAは、ネットワーク層におけるエージェントの身分証明です。Shopifyが検証するのは登録済みの鍵だけなので、本番環境ではEd25519鍵、公開鍵ディレクトリのホスティング、Shopifyへの登録、リクエスト署名、有効期間の短い署名タイムスタンプが必要です。

ページ内では現在のツールを検出し、window、origin、nameの3つすべてを照合します。次のラッパーは、Shopifyが公開している呼び出しパターンに沿っています。

async function callCheckoutTool(name, args = {}) {
  const tools = await document.modelContext.getTools();
  const tool = tools.find((candidate) =>
    candidate.name === name &&
    candidate.window === window &&
    candidate.origin === location.origin
  );

  if (!tool) throw new Error(`${name} is not registered here.`);

  const result = await document.modelContext.executeTool(
    tool,
    JSON.stringify(args),
  );

  if (result === null) return null;
  return JSON.parse(result);
}

JSON.stringifyは見た目を整えるための処理ではありません。Chrome 153ではオブジェクトを渡すとFailed to parse input argumentsで失敗します。Shopifyによれば、Chrome 155ではオブジェクトを受け付け、JSON文字列は非推奨になる見込みです。そのため、引数のシリアライズはエージェントの各所へ分散させず、互換性を担う1つの関数にまとめます。

チェックアウト内を移動するとツール一覧が変わることがあります。toolchangeを監視し、次の呼び出し前にツールとそのスキーマを再検出してください。また、画面遷移の結果としてnullが返ることも受け入れます。executeTool()が応答する前にページが移動した可能性があるためです。

ツール結果に含まれる加盟店や第三者の文字列は、すべてチェックアウトデータとして扱い、モデルへの指示とは見なしません。Shopifyも、ツールを使わずチェックアウトUIを直接操作することを明確に警告しています。

2. 変更する前に必ず最新状態を読む

最初の更新前、購入者がページ上で何かを変更した後、エラーや画面遷移の後には、{}を指定してget_checkoutを呼び出します。これはキャッシュされた記憶ではなく、その時点の新しいレシートです。

応答には、購入者情報、商品明細、受取方法、割引、申告フィールド、決済手段、メッセージ、合計、ステータスが含まれる場合があります。金額は通貨の最小単位を表す整数です。USDでは10799が$107.99を意味します。messagesフィールドがなければ、その応答にはチェックアウトメッセージがありません。

準備完了と同意を混同してはいけません。ready_for_completeは、チェックアウトが確定処理を受け付けられるという意味です。購入者が注文、選択中のカード、合計金額を承認したという意味ではありません。

3. 単独の項目ではなく、必要な状態全体を更新する

update_checkoutの挙動はPATCHではなくPUTです。PATCHは「電話番号だけ変える」と書いた付箋ですが、PUTは用紙そのものの差し替えです。残すべき値は、希望するチェックアウト状態一式に含める必要があります。

安全な更新ループは次のとおりです。

1. get_checkoutを呼び出します。
2. 直近の応答と現在のツールスキーマから、書き込み可能な状態を再構築します。
3. 購入者が承認した値だけを変更します。
4. 対応フィールドの希望値一式をupdate_checkoutへ送ります。
5. 返されたチェックアウトを読み、ステータス、メッセージ、適用済みの割引、合計を確認します。

省略した値の多くは消去されます。決済、申告フィールド、保管済みの連絡先情報にはそれぞれ固有のルールがあります。そのため、現在のスキーマが受け付けるフィールドだけに絞り込まず、汎用的なオブジェクト展開を使うのは危険です。

特に問題になりやすい点は明確です。

• buyerはメールアドレスとE.164形式の電話番号を受け付けます。保管済みの値にはロックされたままのものがあるため、返された内容を確認し、ロック中の値は購入者にページ上で編集してもらいます。
• fulfillment.methodsで指定できる方法は最大1つです。現在の配送先、グループ、オプションのIDを再利用します。配送先やオプションを選ぶ呼び出しと同時に、受取方法の種類や店頭受取の検索起点を変更してはいけません。
• discounts.codesには、保持したい購入者入力のコードをすべて含めます。空の配列を渡すと削除されますが、自動割引は残ります。コードが応答に含まれていても、適用された証拠にはなりません。discounts.appliedとメッセージを確認してください。
• declared_fieldsには、納税者番号やストアクレジットなど、チェックアウト固有の値を入れられます。未知のキー、誤った型、無効な値は拒否されます。
• payment.instrumentsが受け付ける対応エントリは最大1つです。Checkout WebMCPで新しいカード番号を収集することはできません。

Shop Payには、さらに注意が必要です。サインイン済みの購入者は、get_checkoutから返された保存済みカードを選べます。ゲストフローでは、チェックアウト側が受け付ける場合、既存のShop Pay承認IDを利用できます。エージェントがその承認を適用した後、次の更新で決済情報を省略すると認証情報が破棄されます。注文が確定するまで、更新のたびに承認エントリを再送してください。

更新自体は成功しても、チェックアウトがincompleteのままになることがあります。30秒を超えて実行された更新は、一部の変更が反映されていてもupdate_failedを返す場合があります。どちらの場合も、次の判断をする前に最新状態を読み直します。

4. 注文確定のゲートは購入者に任せる

正しい確定手順は、短く厳密です。

1. 最新のチェックアウトを取得します。
2. 現在の商品、決済方法、合計金額を購入者に提示します。
3. その内容と合計金額で注文してよいか、明示的な許可を求めます。
4. 何かが変わった場合は新しい状態を提示し、改めて許可を求めます。
5. 承認後に限りcomplete_checkoutを呼び出します。
6. 購入成立の証拠として認めるのはstatus: completedだけです。

WBAが証明するのは、どのエージェントがリクエストを送ったかです。Shop Payの承認が認可するのは決済手段です。ready_for_completeが表すのはチェックアウトの状態です。どれも、購入者本人の購入許可ではありません。

注文確定には分岐があります。確認ステップが設定されている場合は購入者へ操作が戻ります。購入者が内容を確認して送信を承認した後に限り、complete_checkoutを再度呼び出します。決済認証は別です。購入者が同じタブで認証を終えたら、エージェントは再送信してはいけません。チェックアウトがcompletedになるか、エージェントの入力が必要になるまでget_checkoutをポーリングします。

エラーコードによって、取るべき復旧ルートが決まります。

最も危険なのは、最初の応答が不明確だったという理由で確定処理をもう一度試すことです。Checkout WebMCPには冪等性キーがありません。まず状態を読み、completedなら停止します。

実用性で選ぶ7つのユースケース

いずれも、エージェントがすでに購入者のブラウザ内で動いている場合に最も力を発揮します。サーバー上で人知れず動く加盟店向け自動化ではありません。

最も有力なのは1つ目のユースケースです。リピーターにはすでに保存済みの情報があり、WebMCPなら、利便性を同意と取り違えることなく繰り返し入力を減らせます。

ビジネスとして成立するか、数字から考える

Shopifyでは、このチェックアウトツールを使うために加盟店側で新たな設定をする必要はありません。ただし、その周辺で動くショッピングエージェントを無料で構築できるわけではありません。モデル、ブラウザへの配布、WBAの運用、テスト、プライバシー管理、サポートは依然として必要です。

加盟店が導入するAIショッピングアシスタントの料金には、現在かなりの幅があります。Shopify App Storeの公式掲載情報では、Easy AI Shopping Assistantに月額$9.99のプラン、Cartiに$49〜$249のプラン、iAdvizeに月額$290〜$1,330のプランがあります。これらはストアフロントのチャット、レコメンド、分析、サポートなどを組み合わせた製品であり、購入者側のWebMCPエージェントを直接置き換えるものではありません。

予算面での変化は、もっと限定的で実用的です。ブラウザエージェントの開発チームは、ストアごとのチェックアウトセレクターを保守する工数を減らし、状態の整合性、同意、例外処理に力を注げます。プラットフォーム全体の位置付けは、Shopifyレビューで加盟店側の製品特性と運用上のトレードオフを解説しています。

実際に作る価値がある2つのプロダクト

1. Checkout WebMCPのQA・同意テストツール

最も有望なのはこちらです。Shopify支援会社やショッピングエージェントの開発チームは、注文を任せる前に、そのチェックアウトが対象か、エージェントが安全に動作するかを把握する必要があります。

このニーズに最も近い実測検索語shopify checkout customizationは、米国で月間170回検索され、前年比89%増、CPCは$10.92です。この検索語はWebMCPテストより広い概念ですが、チェックアウトの挙動と実装への需要が存在することを示しています。

販売できる最小構成は、テスト用チェックアウトを開き、originとwindowごとにツールを記録し、JSON文字列引数を検証し、toolchangeを検出し、最新状態に基づく更新をテストし、画面遷移時のnullと公開済みエラーコードを再現し、機密情報を伏せた同意レポートを出力するChromiumランナーです。実際の決済確定は手動テストモードに限定します。

課題はカバレッジです。ツールの利用可否はチェックアウトの種類とブラウザ対応状況に左右され、Chromeの引数形式は移行中で、フィクスチャだけでは実際の決済引き継ぎを証明できません。万能な自動化をうたうのではなく、こうした制約を見える化することで価値が生まれます。

2. 購入者向けShopifyショッピングアシスタント

ブラウザ拡張機能なら、再利用できる確認画面と保存済み決済情報の厳格な扱いを組み合わせ、Shopifyストアでの商品検索から対象のチェックアウトまで購入者を案内できます。

shopify ai shopping assistantは、米国で月間30回検索され、商用意図があり、CPCは$19.43です。加盟店向け競合製品には月額$9.99〜$1,330のプランがあります。この製品は購入者側で動きますが、ガイド付きショッピングソフトウェアにすでに対価が支払われていることは分かります。

MVPには、ストアフロントの商品検索・カートツール、チェックアウト検出、WBA、読み取り・更新・再読み取りのループ、購入者が管理できる注文概要、決済認証の引き継ぎが必要です。まずは単一ストアの注文と、保存済みのShop Payを使うフローに絞ります。

課題は配布です。加盟店がCheckout WebMCPを有効化する必要はありませんが、購入者には対応するブラウザエージェントが必要です。B2B、埋め込み、モバイルSDK、複数ストアをまたぐ注文、Shop Payを使わない通常の3ページ構成チェックアウトは対象外です。

制約こそがプロダクトの境界線になる

Checkout WebMCPは、対象となるブラウザチェックアウトのための、より安全なインターフェースです。あらゆる購入に使える汎用APIではありません。

チェックアウト中の商品追加・削除、新しいカード番号の収集、チェックアウトのキャンセル、アプリ定義の拡張UI操作、対象外のチェックアウトにツールを強制登録することはできません。Shop Payへのログイン、3D Secure、確認ステップなど、購入者本人が行う操作もなくなりません。また、加盟店が表示する文字列をモデルへの信頼できる指示に変えるものでもありません。

設計原則はシンプルです。ツールが登録されている間はツールを使い、最新状態を唯一の正しい情報源とし、契約上購入者の操作が必要になった時点でページを本人へ戻します。

月曜日にまずやること

月曜日には、コードベースの各所へ呼び出しを直書きするのではなく、エージェントへチェックアウト用ラッパーを1つ追加してください。シリアライズ、ツール照合、toolchange、画面遷移時のnull、エラー分類、最新状態の読み取りをそこへ集約します。ローカルフィクスチャの8ケースを実行してから、自分で管理する対象チェックアウトでdocument.modelContext.getTools()の結果を列挙します。最新状態から構築した更新を1回試します。明示的な確認を得た後に限り、対応するテスト注文を確定してください。安全なテスト注文を自分で用意できない場合はready_for_completeで止め、確定処理はソースで確認済みではあるものの、自らは未検証として扱います。

同意を尊重するコマースエージェントを自社向けに構築したい方は、AIエージェント開発サービスをご覧ください。