MCPでAIエージェントをBigCommerceに接続する：Stripe提携が解決しないこと

問題：3つのパス、どれもB2B見積もりを解決しない

BigCommerceはShopifyやHubSpotとは異なる道を選びました。ShopifyはファーストパーティのStorefront MCPおよびCustomer Accounts MCPサーバーを構築し、Googleと共同でUniversal Commerce Protocolを開発しました。HubSpotはファーストパーティRemote MCP Server（2026年4月13日GA）を公開し、標準CRMオブジェクトをカバーする12のツールを提供しています。BigCommerceはどちらも行いませんでした。代わりに、2025年12月18日、BigCommerceはStripeと提携し、StripeのAgentic Commerce Suiteに参加しました。これはAgentic Commerce Protocol (ACP)上に構築されています — Stripe、OpenAI、Metaが共同作成したオープン標準、Apache 2.0ライセンス。

結果として、AIエージェントをBigCommerceストアに接続する3つの異なるパスが存在し、それぞれカバレッジプロファイルが異なります：

BigCommerceエージェント統合の3つのパスはスタックの異なるレイヤーに接続します：

パス1 — BigCommerceドキュメントMCPサーバー。 BigCommerceは https://docs.bigcommerce.com/_mcp/server にMCPエンドポイントを公開し、AIエージェントがBigCommerceの開発者ドキュメントを検索できるようにします。ドキュメントから情報を引き出して「BigCommerceのcheckout APIはどう動くか」のような質問に答えます。これはドキュメント用のMCPサーバーであり、ストアデータ用ではありません。接続されたエージェントはBigCommerce APIの動作を学習できますが、どのストアの製品、顧客、注文、在庫も読み取れません。これは開発者支援ツールであり、ストア統合パスではありません。

パス2 — StripeのAgentic Commerce Suite、ACP上に構築。 提携発表はこう表現しています：「BigCommerceマーチャントは、既存のカタログ、注文システム、運用プロセスを継続使用しながら、AI駆動の発見とチェックアウトフローをアンロックできる。」マーチャントは製品カタログをStripeに接続し、どのAIエージェントを通じて販売するかを選択し、Stripeが発見、チェックアウト、支払い、不正検出を処理します。StripeのAgentic Commerce Suite記事は代替コストを量化します：なしの場合、企業は「サポートする新AIエージェントごとに最大6ヶ月の統合作業」に直面します。ACPパスはこれを単一の構成可能な統合で置き換えます。

ACPアーキテクチャはコンポーザブルです：agentic checkout（カート管理、フルフィルメントオプション、支払い処理）、cart and feed（製品カタログブラウジング）、Shared Payment Tokensによるデリゲート支払い（SPTs — セラーにスコープされ、時間と金額で境界付けられ、ライフサイクルを通じて観察可能）、OAuth 2.0によるデリゲート認証、およびライフサイクル追跡用のorders and webhooks。Stripe Radarは非人間トラフィックパターンに調整された不正検出を提供します。マーチャントはmerchant-of-recordステータスと顧客関係の管理を維持します。

このパスはコンシューマーエージェントコマースの問題を解決します：買い手がAIエージェントに製品を頼むと、エージェントはStripeのカタログフィードを通じてそれを発見し、Stripe Checkout Sessions APIを通じてチェックアウトし、SPTsを通じて支払います。B2B問題は解決しません。

パス3 — 第三者プロバイダーによるマネージドMCPサーバー。 StackOneは120のアクションを即座に利用できるBigCommerce MCPサーバーを提供します。Trutoは /tools エンドポイントを通じてBigCommerce REST API機能を公開します。オープンソースのisaacgounton/bigcommerce-api-mcpは完全なBigCommerce REST APIサーフェスをラップします。これらのサーバーはエージェントに製品、顧客、注文、在庫への型付きツールアクセスを提供します — REST APIがサポートするCRUD操作です。

問題はこれらのマネージドサーバーが何を badly やっているかではありません。問題は3つのパスのどれもエンコードしていないものです：B2Bセマンティックレイヤー — どの価格がどの顧客に適用されるか、どの在庫が予約可能か、どの注文がどのERPレコードにマップされるかを決定するビジネス意味です。

ACPパスがB2Bでカバーしないもの

StripeへのACP製品フィードは製品ごとに1つの価格を運びます — 公開カタログ価格です。BigCommerceの実際のB2B価格構造はCustomer GroupsとPrice Listsにあります。Price ListsはPrice List Assignment APIを通じて、特定のSales Channels上の特定のCustomer Groupsにバリアントレベルの価格オーバーライドを割り当てることを可能にします。エンタープライズ契約、ミッドマーケットボリューム、ホールセール、公開小売の4つの価格ティアを実行するディストリビューターは、1つ以上のチャネルにわたる4つのCustomer Groupsへの4つのPrice Listsのマッピングである4つのPrice List Assignmentsを持ちます。

エンタープライズバイヤーの調達コーディネーターを代表するAIエージェントがACPパスを通じてリクエストを送信すると、エージェントは公開カタログ価格を見ます。顧客はエンタープライズティア価格に対する契約上の権利を持ちます — 潜在的に20-40%低い。ACPフィードはティア構造を運びません。エージェントは間違った価格を提示します。ディストリビューターはマージンを吸収するかキャンセルして販売を失うかのいずれかです。

BigCommerce提携発表はこれを認めています：マーチャントは「BigCommerceの在庫と価格ロジックでエージェントショッピングを情報提供する。」その表現は、マーチャントがBigCommerceで価格ロジックを設定し、Stripeがそれを尊重することを意味します — しかしACPフィードアーキテクチャはカタログを単一の価格サーフェスに平坦化します。B2Bティアインテリジェンスはフィードにありません。

第2のギャップは在庫です。BigCommerceのCatalog Products APIは在庫レベルを報告しますが予約しません。240のライブカウントに対して200単位を引用するエージェントは、発注が到着するまでに間違っている可能性があります。なぜなら、他の3つの見積もりがその間に同じ在庫を消費したからです。RFQエンジンアーキテクチャ — TTL付きの原子的可用性ホールド、キャンセルポリシースナップショット、FXレートロック — はERPと見積もりレイヤーに存在し、EコマースストアフロントにもACPパスにもありません。

第3のギャップはERPライトバックです。ACPパスは受け入れられた注文をwebhooks経由でマーチャントに返します。マーチャントの注文システム — BigCommerce Orders API — がそれを受け取ります。しかしBigCommerceの注文オブジェクトはGLコーディング、子会社、税務ネクサス、またはNetSuite/Brightpearlが正しく注文を転記するために必要なカスタムフィールドをエンコードしません。NetSuite MCPモジュール分析がこれを詳しく扱っています：Eコマース注文とERP注文レコード間のセマンティックギャップは、どのGL勘定、どの子会社、どの税務ネクサス、どのカスタムフィールドが有効な転記を構成するかです。ACPパスはそのギャップを橋渡ししません。

マネージドMCPサーバーがエンコードしないもの

マネージドMCPサーバー（StackOne、Truto、Apideck）は異なる問題を解決します：エージェントに型付きのBigCommerce REST APIアクセスを提供します。StackOneの120アクションは製品、顧客、注文、在庫、ストア管理をカバーします。TrutoはREST APIを統一された /tools エンドポイントの背後にラップします。これらは実際の製品であり、デモではありません — カスタム統合コードなしでBigCommerce APIをAIエージェントにとってレッグ可能にします。

しかし型付きAPIアクセスは型付きビジネス意味と同じではありません。get_products(filters)を公開するマネージドMCPサーバーは、エージェントに製品をクエリする能力を与えます。このストアでは顧客グループ4（"Enterprise Contract"）が"B2B Portal"チャネルでPrice List 7の権利を持ち、そのグループのバイヤーからのリクエストはデフォルトカタログ価格ではなく GET /v3/pricelists/7/records?variant_id={id} を通じて解決されるべきであることをエージェントに伝えません。マネージドサーバーはAPIサーフェスをラップします。どのAPIコールが何を意味するかを決定するビジネスルールをエンコードしません。

これはコネクタシリーズ全体で現れる同じ構造的パターンです。HubSpot分析はHubSpotのファーストパーティサーバーにおける6つの能力ギャップを文書化します — カスタムオブジェクトなし、レビュー可能な書き込み計画なし、接続ごとに1ポータル、システムレベル設計なし、ライブAPIのみのクエリ、機密データ制約。Shopify分析はファーストパーティStorefront MCPがカバーしないB2Bパス — 顧客ティア価格、バルクRFQ見積もり、NetSuiteに対する在庫ホールド、チャネル間の注文帰属 — を文書化します。各ケースで、ベンダーのコネクタは接続問題を解決します。カスタムMCPモジュールはセマンティックレイヤー問題を解決します。

BigCommerceの場合、ベンダーは接続レイヤーのMCPサーバーをまったく構築しませんでした — コンシューマーエージェントコマースをStripeに委託し、ストアデータMCPサーフェスを第三者プロバイダーに残しました。セマンティックレイヤーギャップは同じです。違いは接続レイヤー自体がより断片化されていることです。

認証：ヘッドレスフレンドリーな制約

BigCommerceのAPI認証は X-Auth-Token を使用します — ストア管理画面（Store Setup → API Settings）から生成されるか、マーチャントがアプリをインストールする際のOAuthアプリインストールフローを通じて発行されるストアスコープのベアラートークンです。HubSpotのOAuth 2.1 with PKCE（ブラウザベースの同意と単一使用リフレッシュトークンを必要とする）とは異なり、BigCommerce APIトークンは取り消されない限り期限切れにならず、ブラウザベースのリフレッシュを必要としません。これはHubSpotのファーストパーティMCPサーバーよりヘッドレスフレンドリーです：午前2時に実行されて一晩の注文変更を同期するバックグラウンドエージェントは、人間を介在させずに静的な X-Auth-Token で認証できます。

制約はレート制限であり、認証ではありません：

APIはヘッダー経由でレート制限ステータスを返します：X-Rate-Limit-Requests-Quota、X-Rate-Limit-Requests-Left、X-Rate-Limit-Time-Reset-Ms。リストエンドポイントはページごとに250アイテムを返します。Standardストアに対して30の並行ツールコールを発行するエージェントは、1バーストで150リクエストウィンドウを使い果たし、残りで429を受け取ります。ツールごとのスロットリングを強制しないマネージドMCPサーバーは、その失敗を非構造化エラーとしてエージェントに渡します。

カスタムMCPモジュールはツールごとのレート制限を内部で強制します — 各ツールが制限を宣言し、バックボーンが30秒ウィンドウ内に留まるようリクエストをスロットルし、エージェントはクラッシュではなく X-Rate-Limit-Time-Reset-Ms から導出された Retry-After を持つ構造化された 429 を受け取ります。モジュールはリストクエリのバッチ処理も行います — 250アイテムの各200リクエストをページネーションする代わりに、モジュールはフィルタされたクエリを使用してエージェントが実際に必要なレコードのみをプルし、レートウィンドウ内に留まります。

カスタムMCPモジュールが提供するもの

モジュールパターンはMCP Module Code Standardに従います：各ツールは型付き入力スキーマ、型付き出力スキーマ、レート制限、監査ログ、エラーコントラクトを持ちます。エージェントは生エンドポイントに対する自由形式APIコールではなく、名前と構造化引数でツールを呼び出します。

BigCommerceの場合、カスタムモジュールはACPパスとマネージドMCPサーバーが開いたままにするギャップを埋めます：

顧客グループ価格解決。 モジュールは get_tier_price(customer_id, product_id, channel_id, quantity) を公開します — バイヤーのCustomer Groupを解決し、現在のチャネルでそのグループのPrice List Assignmentを見つけ、要求された数量のバリアントレベル価格を返す型付きツール。エージェントは顧客グループ4がPrice List 7にマップされることを知る必要はありません。モジュールがマッピングをエンコードします。エージェントは get_tier_price を呼び出し、公開カタログ価格ではなく正しい契約価格を受け取ります。

在庫可用性ホールド。 モジュールはBigCommerceの在庫レベルチェックをラップし、予約レイヤーを追加します — ストアがサポートする場合はBigCommerceの在庫に対して、そうでない場合は権威的在庫カウントが存在する上流ERP（NetSuite、Brightpearl）に対して。エージェントは acquire_availability_hold(product_id, quantity, duration_minutes) を呼び出し、RFQエンジンアーキテクチャと一致するTTL付きのホールドトークンを受け取ります。見積もりはライブカウントではなく予約在庫で裏打ちされます。

セマンティックマッピング付きERPライトバック。 モジュールはBigCommerceの注文を受け入れ、ERPの期待形式に変換します — GLコーディング、子会社、税務ネクサス、カスタムフィールド。エージェントは create_erp_order(bigcommerce_order_id) を呼び出し、モジュールが変換、APIサーフェス選択（NetSuite用のSuiteTalk REST、RESTlets、SuiteQL、Brightpearl用のBrightpearl API）、認証、監査ログを処理します。エージェントはOAuth署名を構築したりAPIサーフェスを選択したりしません。

レビュー可能な書き込み計画。 モジュールはマルチステップ変更のための構造化計画を起案します — 「昨日受け入れられた見積もりから15の注文を作成し、それぞれを正しいGLコーディングでNetSuiteに転記し、BigCommerceでフルフィルメントタスクを作成する」 — そして実行前に人間のレビュー担当者にルーティングします。ACPパスとマネージドMCPサーバーは即座に実行します。モジュールは間違ったバッチがERPを歪めるのを防ぐレビューゲートを追加します。

レート制限バッチクエリ。 モジュールはBigCommerceのレート制限を内部で強制します — ツールごとのスロットリング、バッチリストクエリ、および質問ごとのAPIラウンドトリップなしでクロスオブジェクト分析のためにカタログと注文データをローカルストアに同期する管理データレイヤー。エージェントが「過去30日間にEnterprise顧客グループからのNetSuite転記に対応するものがないすべての注文を見せて」と尋ねると、モジュールは30分のページネーションAPIコールではなくローカルレイヤーから答えを返します。

なぜこれが一般化するか

BigCommerceパターン — コンシューマーエージェントパスのために提携するベンダー、REST APIをラップするがビジネス意味をエンコードしないマネージドMCPレイヤー、利用可能なサーフェスのどれもカバーしないB2Bセマンティックレイヤー — はEコマースとERPの風景全体で現れる同じ構造です。ギャップの分布が異なるだけです：

• Shopifyは最も完全なファーストパーティエージェントサーフェス（Storefront MCP、Customer Accounts MCP、UCP）を構築しましたが、B2Bパス — 顧客ティア価格、バルクRFQ見積もり、NetSuiteに対する在庫ホールド — はファーストパーティサーフェスにありません。Shopifyコネクタ分析がこれをカバーします。
• HubSpotは標準CRMオブジェクトをカバーする12のツールを持つファーストパーティMCPサーバーを構築しましたが、カスタムオブジェクト、レビュー可能な書き込み計画、ヘッドレス認証、マルチポータル操作はギャップです。HubSpotコネクタ分析がこれをカバーします。
• NetSuiteはファーストパーティのAI Connector Serviceを持ちますが、自身のFAQで「AIはハルシネーションを起こす可能性があります。常にソースデータに対して結果を検証してください」と警告しています。セマンティックギャップはどのGL勘定が収益を構成するかです。NetSuite MCPモジュール分析がこれをカバーします。

Anthropic 2026 State of AI Agents Report（500+の技術リーダー、Novo Nordisk、Doctolib、L'Oréal、Shopifyでの実世界実装）は、既存システムとの統合をエージェント採用の最大の障壁として特定しています — 46%の組織がそれを引用し、データアクセス（42%）、セキュリティ（40%）、モデルインテリジェンスを上回ります。47%がハイブリッドbuild-and-buyアプローチを使用します：完全にプレビルドではなく、すべてインハウスではなく、カスタムコードで拡張するプラットフォームです。ACPパスはBigCommerceの「買う」半分です。マネージドMCPサーバーはストアデータアクセスの「買う」半分です。カスタムモジュールは「建てる」半分です — エージェントをコンシューマーチェックアウトだけでなくB2B操作に有用にするセマンティックレイヤー。

BigCommerceとStripeの提携は健全な製品決定でした — Stripeは支払いインフラと不正検出をほとんどのEコマースプラットフォームが自力で構築できるよりも良く処理します。しかし提携はコンシューマーパスをカバーします。B2Bパス — バイヤーが交渉された価格を持つ調達コーディネーターであり、在庫は報告ではなく予約されなければならず、注文は正しいGLコーディングと子会社マッピングでERPに届かなければならない — はこのシリーズの他のすべてのコネクタが要求するのと同じカスタムモジュールレイヤーを要求します。MCP Module Code Standardが構造を定義します。BigCommerceコネクタは提携パスケースの参照実装です — ベンダーがコンシューマーエージェントレイヤーを外部委託し、B2Bセマンティックレイヤーを統合チームに残したケースです。

ストアフロントでBigCommerce、ERPにNetSuiteまたはBrightpearl、4つの顧客グループ価格ティアを実行するB2Bディストリビューターは、Price List Assignment APIを通じてバイヤーの契約価格を解決し、ERP在庫カウントに対して原子的可用性ホールドを取得し、見積もり時に商業条件をスナップショットし、正しいGLコーディングと子会社マッピングで受け入れられた注文をERPにライトバックするエージェントを得ます — 各ツールコールはレート制限され、ログに記録され、例外は人間のレビュー担当者にルーティングされます。そのビルドは4ステップメソッドのPhase 2-3であり、通常5-8週間で稼働します。

スコープ付きビルドをリクエスト。 1週間のDiscovery。システムインベントリ、ワークフローマップ、固定スコープを得られます — 私たちとビルドするかどうかに関わらず。