StripeがCheckout全体でWebMCPに対応｜AIエージェントに「画面を読ませず関数を渡す」設計を業務目線で読む

Stripeが2026年9月22日に開発者ブログで、決済画面「Stripe Checkout」にWebMCPを組み込んだと発表しました。WebMCPは、Webページがブラウザの中でAIエージェント向けの「ツール」を公開するための提案中の標準です。エージェントはボタンや入力欄を画面から探して推測する代わりに、ページが用意したfill_payment_formのような関数を呼び出して決済を進めます。Stripeの自社計測では、WebMCPを使ったエージェントはトークン消費が42%減り、ツール呼び出しが38%減り、完了までの時間が39%短くなったとされています。

数字は目を引きますが、この発表から業務で持ち帰るべきなのは「自社サイトもすぐWebMCP対応を」という結論ではありません。むしろ、エージェントに画面を読ませるのではなく、どの操作を・どの状態で・どこまで渡すかを設計するという考え方と、その設計が既存のアクセシビリティ実装とつながっているという点です。この記事では、Stripeのブログ、Stripeのドキュメント、Chromeの開発者向けドキュメント、仕様ドラフトとExplainerを一次情報として、何が発表されたか、WebMCPとは何か、数字をどう読むか、自社のWebサイトや社内システムの担当者がいま何を検討し、何を待つべきかを整理します。

何が発表されたか#

Stripeの開発者ブログ「How Stripe is designing Checkout for AI agents」(2026年9月22日、Cara Mecozzi氏とSteve Kaliski氏の連名)の要点は次のとおりです。

• WebMCPをすべてのStripe Checkout UIで有効にした
• 目的は、事業者が組み込みを変えなくても将来のエージェント経由の買い物客に対応できるようにし、同時に速く確実な購買体験を提供すること
• エージェントが画面の見た目とDOM(ページの構造)を解釈して操作を推測する方式は、モデルが改善しても遅く、回りくどく、トークンを多く消費する
• 効率の主な指標はトークン(コスト)とツール呼び出し(手間)。ツール呼び出しが多いのは、エージェントが迷っている兆候でもある

Stripeはブログの中で、Checkoutは780万超の事業者が使っていると書いています。ここで押さえておきたいのは、改修の主体がStripe側であることです。Checkoutの画面はStripeが提供しており、Stripeは、事業者が組み込みを変えなくてもエージェントに対応できるとしています。ただし、次に見るように、UIの種類やセッションの状態によって使えるツールは異なります。

Stripeのドキュメント(エージェント開発者向けの「ブラウザーで WebMCP を使用した Stripe 決済の完了」)には、対象となるUIとして、フルページ、埋め込みフォーム、Elements、オンライン請求書ページの4つが挙げられています。公開されるツールは、決済や請求書のコンテキスト(未払い額や利用可能な決済手段など)の読み取り、決済手段の選択、フォームへの入力、そして送信ボタンをStripeが制御しているUIに限った決済送信の開始です。Elementsのように送信の制御が事業者側にある構成では、決済送信のツールが無い場合がある、と読める書き方です。

状態に応じてツールを出し入れする#

実装の中心になっているのが、Stripeが「progressive tool disclosure」と呼ぶ考え方です。ページは、その時点の状態で意味のあるツールとパラメータだけを公開します。ブログに書かれている簡略化した流れは次のとおりです。

1. エージェントがチェックアウトのセッションと利用可能な決済手段を確認する
2. 決済手段を選ぶと、画面に表示されている入力欄を反映したスキーマを持つフォーム入力ツールが公開される
3. エージェントがそのツールで必要な情報を渡す
4. フォームがそろって検証を通ると、はじめてsubmit_paymentが公開される

状態が変われば、使えるツールも変わります。ブログの例では、エージェントが決済手段をカード以外に変えると、fill_payment_formのパラメータからカード番号が取り除かれます。あらゆる操作を最初からまとめて見せるより、ツール呼び出しが減り、信頼性が上がり、決済の成功が増える、というのがStripeの説明です。

ツールの説明文に「この順番で使うこと」と書いて聞き分けてもらうのではなく、アプリがすでに知っている制約を、見せるツールの範囲でエージェントに伝えるという発想です。業務システムに置き換えれば、承認前の伝票に「確定」ボタンを出さないのと同じ設計を、エージェント向けにも適用していることになります。

エージェント専用の別経路を作らない#

もう一つの方針が、人間向けと同じ土台に乗せることです。Stripeは、エージェント専用の2つ目のチェックアウトを作るのではなく、フロントエンドにすでにあるアクセシビリティのパターンと最適化を多く活用し、共通の基盤を保ったと書いています。WebMCPのツールは、人間向けの決済画面と同じ土台に処理を委ねます。

実装には、WebMCPの2種類のAPIを使い分けています。

• 命令型(Imperative)API: get_order_summaryのように既存の状態から応答を組み立てるツールや、select_payment_methodのように既存の状態遷移を起こす明示的な操作に使った
• 宣言型(Declarative)API: フォーム入力に使った。表示中の入力欄からブラウザが入力スキーマを推論するので、手で複製したフォームのスキーマを別に保守する必要がない。開発者が入力欄を追加すれば、既定でツールにも反映される

「エージェント専用のロジックに分岐させると、人間向けとの食い違いが生まれたり、エンジニアの手間が増えたりする」ことを避けたかった、とStripeは説明しています。エージェント対応を別システムとして作ると、画面を直したのにエージェント側が古いまま、という二重保守が起きがちです。この判断は、自社で同じことを検討するときにも参考になります。

WebMCPとは何か#

ブラウザの中でページがツールを公開する#

Chromeの開発者向けドキュメントでは、WebMCPを「AIエージェント向けの構造化されたツールを作って公開するための、提案中のWeb標準」と説明しています。JavaScriptのAPIと、HTMLのフォーム要素への注釈によって、エージェントがページの機能とどう関わればよいかを正確に伝える仕組みです。

エージェントがWebサイトを操作する従来の方法は、画面を読み取り、ボタンや入力欄の意味を推測し、クリックや文字入力を人間の代わりに再現するものでした。Chromeのドキュメントはこれを「actuation」と呼び、手順が多く、各ステップがエージェントの解釈に委ねられると指摘しています。WebMCPでは、サイト側が「この要素は何のためのものか」を宣言します。ツールはページ上で目に見える形で実行されるので、利用者は作業が期待どおり進んでいることを確かめられる、という説明もあります。

APIは2種類です。

宣言型APIには、Stripeがアクセシビリティ実装を流用できた理由が見えます。Chromeのドキュメントによれば、toolparamdescriptionが無い入力欄では、ブラウザは関連付けられた<label>の内容をパラメータの説明に使い、ラベルが無ければaria-descriptionを参照します。つまり、スクリーンリーダー向けにラベルを正しく付けたフォームは、そのままエージェントにとっても読みやすいツールの材料になります。

送信の扱いも選べます。既定では、エージェントがフォームに値を入れても、送信は利用者が自分で送信ボタンを押す必要があります。toolautosubmit属性を付けると、エージェントの呼び出しで送信まで進みます。送信イベントには、エージェントによる実行かどうかを示すagentInvokedが加わり、エージェント経由のときだけ挙動を変えることもできます。フォームがエージェントに操作されている間は、:tool-form-activeなどのCSS疑似クラスで画面上に示せます。

命令型APIでは、ツールに安全性の性質を示すアノテーションを付けられます。

• readOnlyHint: 情報を読むだけで状態を変えない
• untrustedContentHint: 出力に口コミや外部データなど、ツールの作者から見て信頼できないデータが含まれる
• consequentialHint: 予約や送金、削除のように、重大で取り消しにくい結果を伴う
• debugging: 開発者向けの検査用ツール(Chrome 156から)

仕様ドラフトは、consequentialHintについて、クライアントやエージェントが高リスクなツールの実行前に利用者の確認を必須にできるようにするための合図だと説明しています。あくまで「確認を求められるようにする合図」であり、付ければ自動的に承認画面が出ると保証するものではない点は区別しておきます。

提供状況はまだ試験段階#

2026年9月25日時点で確認できる提供状況は次のとおりです。

Stripeのドキュメントも、WebMCPを「提案されているウェブ標準に基づく実験的なブラウザー機能」と位置づけ、ブラウザの対応状況、ツールの可用性、スキーマは変わる可能性があると書いています。

制約として決まっていること#

Chromeのドキュメントには、使い始める前に知っておくべき制約がまとまっています。

• オリジン分離: WebMCPはオリジン分離されたドキュメントでしか使えない。Origin-Agent-Cluster: ?0ヘッダなどでdocument.domainが有効になっているとAPIは無効になる
• Permissions Policy: toolsというポリシーで制御され、既定値はself。トップレベルと同一オリジンでは登録でき、クロスオリジンのiframeでは無効。iframeで許可するにはallow="tools"属性が要る
• 公開範囲: 命令型APIで登録したツールは、既定では他のサイトやクロスオリジンのiframeから見えない。特定のオリジンに見せる場合はexposedToオプションで信頼できるオリジンだけを列挙する
• ヘッドレス利用: ヘッドレス環境で動かせる可能性はあるが、主に人間が介在するローカルのブラウザでの利用を想定している
• 発見性: エージェントはサイトを実際に開くまで、そのサイトにツールがあるかどうかを知る方法がない

GitHubのExplainerも、目的の一つに「人間が介在するワークフロー」を挙げ、非目的として「ブラウザUIの無い完全自律型エージェント」と「人間向けインターフェースの置き換え」を明記しています。一方で、人間が介在する前提で公開したツールをヘッドレスでのタスク完了にも使えることも、目的の一つに含めています。WebMCPの主な想定は利用者がタブを開いている場面での共同作業ですが、ヘッドレスでの利用も視野に入っています。実際にStripeも、Muse・Instinct・Grokbotのようなエージェントは多くの場合、仮想マシンとブラウザを備えていると説明し、Browserbaseのようなブラウザ自動化ツールを使うエージェントがこれらのツールを直接呼び出せると書いています。

サーバー側MCPとの違い#

名前が似ているため混同されやすいのが、サーバー側のMCP(Model Context Protocol)との関係です。Chromeのドキュメント「When to use WebMCP and MCP」は、WebMCPはMCPの拡張でも置き換えでもないと明言しています。

Chromeのドキュメントは、WebMCPを「MCPに着想を得たAPI群」と表現し、MCPのresourcesのようなサーバー側の概念は含まないと説明しています。WebMCPのツールは、そのタブのセッション・Cookie・DOMの状態をそのまま使って動きます。逆にいえば、ログイン状態や画面の文脈を別のサーバーに複製しなくてよい代わりに、タブが開いていなければ何もできません。Chromeのドキュメントは、中核の業務ロジックとデータ取得はMCPサーバーで、利用者がサイトを開いている場面の操作はWebMCPで、と両方を組み合わせる形を勧めています。Stripe自身も、MCPサーバーを提供しつつ、それとは別にブラウザ経由で使われる決済画面をWebMCPに対応させた形です。

数字の読み方#

Stripeが公表した計測の条件と結果を、ブログに書かれている範囲で並べます。

この数字から言えることと、言えないことを分けておきます。

言えることは、決済のように手順と状態遷移が決まっている画面では、ツールを状態に応じて絞って渡すと、同じタスクをより少ないトークンと手数で終えられる、という方向性です。トークンは入力・出力・キャッシュを合計した値で、エージェントが1件の購買を支援するコストに直結します。ツール呼び出しには、クリックやフォーム入力も含めたエージェントの操作回数が数えられています。どちらの方式でも全件が完了しているので、今回の差は成功率ではなく効率の差です。

一方で、次の点はブログからは読み取れません。

• どの6モデルを使ったか、モデルごとの内訳やばらつき。公開されている図表は平均値の比較で、試行を6モデルに均等に割り振ったと仮定すると、1モデルあたり各条件5回程度の計算になる
• ベースラインのエージェントが、スクリーンショット・DOM・アクセシビリティツリーのどれを主に読んでいたか。ブラウザ操作の作り方しだいで、ベースラインの数字は大きく変わりうる
• 実在の店舗、複数の決済手段、住所入力の揺れ、3Dセキュアのような追加認証を含む流れでの結果

これはStripeが自社の製品で、自社の条件で測った結果であり、第三者による独立した検証ではありません。数字そのものを疑う理由はありませんが、「WebMCPに対応すればトークンが4割減る」と一般化すると、測った条件を落として引用することになります。Stripeの決済画面は、手順が短く、入力項目が定型で、状態遷移がはっきりした、WebMCPの効果が出やすい部類の画面です。自社の画面で同じ割合の効果が出るかは、自社の画面で測ってはじめて分かります。

自社サイト・社内システムの担当者がいま検討すべきこと#

ここからは、自社のWebサイトや社内の業務システムを持つ担当者の立場で考えます。前提として、Stripe Checkoutの決済画面については、Stripeが事業者の組み込みを変えずに対応できるとしています(使えるツールはUIの種類やセッションの状態によって異なります)。自分で手を入れる必要があるのは、決済より前の商品検索・カート・会員登録や、社内の申請フォームなど、自社が作っている画面です。

スクレイピング型エージェントに壊されない画面にする#

WebMCPが広く使えるようになる前から、ブラウザを操作するエージェントはすでに画面を読んで動いています。Stripeがブログで、エージェントのブラウザ利用は既存サービスとやり取りする主要な経路だと述べているとおりです。WebMCPに対応するかどうかとは別に、いま効くのは画面そのものの読みやすさです。

• 入力欄に<label>を正しく関連付ける。宣言型APIでも、ラベルがそのままパラメータの説明になる
• ボタンやリンクの名前を、見た目のアイコンだけに頼らずテキストやアクセシブルネームで付ける
• 状態(選択中・無効・エラー)を、色だけでなく属性やテキストで表す
• 必須項目と入力形式を、画面上とHTMLの両方で示す

これはアクセシビリティ対応そのもので、人間の利用者にも効きます。Stripeがエージェント専用の画面を作らずアクセシビリティ実装を流用したことは、この順番の妥当性を裏付けています。将来WebMCPに対応するときにも、ラベルが整っているフォームなら宣言型APIの属性を足すだけで始められます。

取り消しにくい操作には人間の承認を挟む#

決済・送金・予約の確定・データの削除のように、実行したら取り消しにくい操作は、エージェントに渡すとしても人間の承認を挟む設計にします。WebMCPの仕組みで対応する部分と、アプリ側で担保する部分を分けて考えるのが安全です。

• 宣言型APIのフォームは、toolautosubmitを付けなければ送信は利用者の操作になる。確定系のフォームには付けない
• 命令型APIで確定系のツールを作るなら、consequentialHint: trueを付ける。ただし確認画面を出すかどうかはエージェントやブラウザ側の判断で、アプリ側の承認フローの代わりにはならない
• 承認の要否は、ツールの説明文ではなくサーバー側の業務ロジックで判定する。説明文はエージェントへのお願いにすぎない

Chromeのドキュメント「WebMCP tool security」は、LLMはテキスト・指示・利用者のデータを一続きのトークンとして扱うため間接プロンプトインジェクションを受けやすく、LLMの内部で安全を保証することは不可能だと書いています。口コミや外部データを返すツールにはuntrustedContentHintを付けるよう勧めているのも、この前提があるからです。同じページには、利用者の同意をどう管理するかは議論が続いているとも書かれています。WebMCPを使っても使わなくても、エージェントが悪意ある指示に誘導される可能性を前提に、最後の砦をアプリ側に置くことが基本です。

公開するツールを絞り、ログを取る#

WebMCPに対応する場合も、既存の画面にエージェント操作を許す場合も、渡す操作は必要最小限にします。Stripeのprogressive tool disclosureは効率化の工夫として紹介されていますが、セキュリティの面でも「今この状態で必要な操作しか見せない」ことは攻撃面を小さくします。

• 1つのツールには1つの機能だけを持たせる。Chromeのベストプラクティスも、機能が重なるツールはエージェントを迷わせると注意している
• 読み取り系と書き込み系を分け、読み取り系にはreadOnlyHintを付ける
• クロスオリジンへの公開(exposedTo)は、利用者のデータを直接共有してよい相手に限る
• 入力は、スキーマで緩く、コードで厳しく検証する。Chromeのベストプラクティスは、スキーマの制約は保証されないので、確実に守らせたい条件は関数側で検証し、エージェントが直せるエラーを返すよう勧めている
• エージェント経由の操作かどうかを記録する。宣言型APIなら送信イベントのagentInvoked、命令型APIならツールの実行関数の中で、どのツールがどの入力で呼ばれたかをログに残せる

一方、Stripeのように状態ごとにツールを出し入れする設計は、実装も検証も重くなります。Chromeのベストプラクティスは、ツールはページの状態に応じて登録と解除をするよう勧めつつ、大半のアプリでは静的な登録を既定にして複雑さを抑えるよう書いています。決済のように状態遷移が決まっていて、誤った順序で呼ばれると困る画面では出し入れする価値があり、そうでない画面では固定のツールで始める、という使い分けが現実的です。

まだ待った方がよい部分#

最後に、いま試す範囲と、待った方がよい範囲を分けます。

試してよいのは、手元での検証です。ローカルのChromeでフラグを有効にし、社内の検証環境で問い合わせフォームや検索フォームに宣言型APIの属性を付けて、エージェントからどう見えるかを確かめる程度なら、既存の画面を壊さずに始められます。自社のフォームのラベルがエージェントにどう解釈されるかを見ること自体が、アクセシビリティの点検にもなります。

待った方がよいのは、本番の画面を前提にした作り込みです。理由は次のとおりです。

• 仕様がCommunity Groupのドラフトで、W3Cの標準化トラックに乗っていない。APIの形や属性名は変わりうる
• Chromeはorigin trialの段階で、FirefoxとSafariは標準化ポジションの議論の段階にある
• 利用者の同意をどう管理するかは、Chromeのドキュメント自身が議論中としている
• ツールの説明文や出力の文字数の目安(説明500文字、パラメータ説明150文字、ツール名とパラメータ名30文字、出力1,500文字)も、Chromeのドキュメント上で今後変わりうると注記されている
• エージェントはサイトを開くまでツールの有無を知る方法がなく、どのエージェントがどう使うかがまだ固まっていない

Stripeのドキュメントも、エージェント開発者に向けて、ツール名やスキーマをハードコーディングせず、実行時に検出し、必要なツールが無ければ通常のブラウザ操作へフォールバックするよう求めています。提供する側のStripeでさえ、ツールの形は変わる前提で案内しているということです。

よくある質問#

まとめ#

StripeのCheckoutへのWebMCP組み込みは、エージェントに画面を読ませて推測させるのではなく、状態に応じた関数を渡すという設計を、大規模な決済画面で実際に動かして数字を出した事例です。計測は自社条件のもので、WebMCP自体もまだ提案中の標準です。一方で、ラベルの整ったフォーム、状態に応じて出し入れする操作、取り消しにくい操作の人間承認という土台は、WebMCPが標準になってもならなくても役に立ちます。いま手を付けるならそこからで、本番のWebMCP対応は仕様とブラウザの動きを見てからでも遅くありません。

本記事のStripeの実装方針(progressive tool disclosure、アクセシビリティ実装の流用、命令型と宣言型の使い分け)と計測の条件・結果(6モデル・60回・架空の小売サイト・フルページUI、トークン約180万・ツール呼び出し38.83回・2.5分超のベースライン、42%・38%・39%の削減と60秒の短縮)は、Stripe Developers Blogの2026年9月22日付の記事に基づきます。対象UIとツールの種類、エージェント開発者向けの注意はStripeのドキュメントに基づきます。WebMCPの定義・提供状況・API・アノテーション・オリジン分離とPermissions Policy・公開範囲・サーバー側MCPとの比較・ベストプラクティスはChrome for Developersの各ページ、仕様の位置づけは仕様ドラフト(2026年9月17日版)、目的と非目的およびブラウザ・エージェント別の対応状況はGitHubのExplainerと実装状況ページで、いずれも2026年9月25日時点の記載を確認しました。計測値はStripeの自社計測で、第三者による独立検証ではありません。WebMCPは提案中の標準で、API・提供状況・推奨事項は変わる可能性があるため、導入検討時は最新の公式情報をご確認ください。