マーケットプレイスがエージェントに開かれるとき：Amazon Seller CentralのAIプラグインと売り手側オペレーションレイヤー

主要ポイント

• Amazonは2026年9月23日、Seller Centralの売り手側APIサーフェスを外部のAIエージェントに開放しました — 在庫、価格、リスティング、販売分析をカバーする、Amazon QuickとAnthropicのClaude向けの米国ベータSelling Partnerプラグインです。
• Amazonの販売パートナーの90%はすでにサードパーティ製AIツールを使用しており、セラーはSeller Assistantの推奨を90%以上の確率で受け入れています — Amazonは、すでに存在するエージェント介在のワークフローへ、セラーに続いて踏み込んでいるのです。
• Amazonが選んだのはオープンプロトコルではなくプラグインの道です — UCP、ACP、AP2、x402は買い手側の標準のままであり、どのアシスタントを接続するかはAmazonが決め、発表の数日前にはMetaのMuseショッピングエージェントを自社ストアからブロックしました。
• 権限モデルこそが評価対象です。スコープされたデータ型、行動ごとの人間の承認、完全な監査証跡 — セラーはプラグインが到達するデータを選び、各行動を実行前に承認します。
• プラグインが接続するのはAmazonのデータとアシスタントであって、セラー自身のスタックではありません — NetSuite、BigCommerce、ShipStationを運用するB2Bセラーには、ティア別価格、マルチチャネル在庫、注文の書き戻しのために、自前のエージェントモジュールレイヤーが依然として必要です。

今年追跡してきたアジェンティックコマースの標準 — UCP、ACP、AP2、x402、Checkout MCP — はすべて買い手側を規定しています。すなわち、エージェントがどのように商品を発見し、価格を交渉し、チェックアウトを完了し、支払うかです。（このスタックはAIエージェント向けコマースプロトコルで整理しました。）2026年9月23日、AmazonはAccelerateセラー会議において、取引のもう片方の側を開放しました。新しいSelling Partnerプラグインにより、最大のマーケットプレイスの売り手側オペレーション — 在庫、価格、リスティング、販売分析 — が米国ベータとしてAmazon QuickとAnthropicのClaudeの中に入ります。この流れは数字で裏付けられます。Amazonの販売パートナーの90%がすでにサードパーティ製AIツールを業務の一部に使っており、それらのセラーがAmazonに支払った手数料は2026年第2四半期に468億ドルに達しました — GeekWireの報道が指摘するように、AWSの収益を上回る規模です。

本稿では、プラグインが実際に何を開放するのか、なぜAmazonがオープンプロトコルではなくエージェントプラグインの道を選んだのか、権限モデルが何を管理するのか、そして何を解決しないのかを整理します。B2Bセラーのオペレーションはマーケットプレイスの境界で終わらないからです。エージェントがAmazon上で調整した価格は、NetSuiteのティア別価格と照合できなければなりません。今まさに変更された在庫水準は、BigCommerceや倉庫と一致していなければなりません。マーケットプレイスが生み出す注文は、依然としてERPに届く必要があります。プラグインは、マーケットプレイス側のエージェントオペレーションへの回答です。その統合のセラー側は、依然として構築が必要です。

Amazonが実際にリリースしたもの

9月23日にリリースされたのは3つで、評価の観点がそれぞれ異なるため、切り分けて考える価値があります。

Seller Assistantのアップグレード。 Seller Central内のAIコンパニオンは、各セラーの価格パターン、在庫サイクル、成長目標の永続的なメモリを保持するようになり、Claudeモデルを載せたAmazon Bedrock上で稼働します。Amazonによれば、販売パートナーの90%以上に展開済みで、アクティブユーザーは数十万人に上り、セラーはその推奨を90%以上の確率で受け入れています。この最後の数字がメモリ機能よりも重要です。Seller Central内で大多数に受け入れられている推奨エンジンこそ、プラグインが拡張する行動の基盤だからです。

Seller Assistantワークフロー。 常時稼働の自動化であり、条件を監視し、許可のもとで行動します — 「トップ10商品のいずれかが評価4つ星を下回ったら警告し、対応計画の草案を作成して」や「主力カテゴリの競合の隙を監視して。見つけたら価格を調整し、リスティングを更新して」といった指示です。セラーは平易な言葉でガードレールを設定し、ワークフローに推奨の提示だけをさせるか、行動まで行わせるかを選びます。すべての行動は完全な監査証跡とともに記録されます。

Selling Partnerプラグイン。 新しいサーフェスです。プラグインは、セラーのリスティング登録内容、リアルタイムのパフォーマンス指標、在庫水準、販売分析を外部エージェントに接続します — ローンチ時はAmazon Quick、ベータではClaude — そして外部エージェントは、Seller AssistantがSeller Central内で行うのと同じようにアカウントに対して行動できます。Amazonによれば、Claudeの接続はコーディング不要で約60秒かかり、セラーが既に持つ会計・サプライヤーのデータ接続と並行して機能します。

Amazon自身のVPによる言葉づかいが戦略的な見出しです。「私たちのビジョンは、セラーが二度とSeller Centralにログインする必要がないというものでした」と、Worldwide Selling Partner Experience担当バイスプレジデントのMary Beth WestmorelandはGeekWireのインタビューで語っています。「彼らが働いている場所に、こちらから届けるのです。」

なぜプロトコルではなくプラグインなのか

買い手側のプロトコルは設計上オープンです。UCPには公開仕様と共同開発者がおり、ACPはGitHub上にあり、どの加盟店でもエンドポイントを公開できます。売り手側の開放は正反対の形をしています。Amazonは、自らが選んだアシスタント向けにプラグインを公開します — まず自社のQuick、次にAnthropicのClaude（Amazonが数十億ドルを投資し、そのモデルはすでにSeller Assistantを支えている企業） — そしてさらに多くの統合が続くと述べ、その構築方式は「プラグインを公開し続けられる程度にモジュール化できる」としています。発表の中に、他のプラットフォームが実装できる仕様の記述は一切ありません。

この文脈が対比を際立たせます。Accelerateの数日前、Amazonは消費者向けショッピングエージェントであるMetaのMuseを自社ストアからブロックしました — 外部エージェントは自らを識別し、利用するサイトのルールに従わなければならないというのがAmazonの公式な立場です（GeekWire）。売り手側では、Amazonがホストであり、ルール策定者であり、プラグイン公開者です。売り手側のエージェントサーフェスは、Amazonが存在すると言う場所に存在します。

セラーにとって、これは参加を見送る理由ではありません。能力と同じ厳しさで条件を評価すべき理由です。そのサーフェスは、マーケットプレイスを所有する取引相手によって拡張され、再価格設定され、狭められうるからです。セラー手数料はすでにFTCのAmazonに対する反トラスト訴訟の争点であり、2027年3月に裁判が予定されています（GeekWire）。セラーツールの経済性は中立的な背景ではありません。

下の図は、プラグインを買い手側プロトコルスタックおよび適用される権限ゲートと並べて位置づけたものです。

権限モデルが管理するもの

Amazon自身の安全性の説明は、評価に足る精度を持っています。プラグインのやり取りは「アクセスできる範囲の明確な境界、行動に対する人間の承認、そして完全な監査証跡」によって保護されている、というものです。実際には4つのゲートです。

データスコープ。 セラーは、プラグインが到達できるデータの型を選びます — リスティング、在庫、販売分析、パフォーマンス指標。スコープはデータ型ごとに、セラーが選択します。

意図の可視性。 Quickでは、プラグインを軸に構築されたエージェント — 価格エージェント、リスティングエージェント、補充エージェント — は、実行前に何をするつもりかを表示します。

人間の承認。 行動は、実行される前にセラーの承認を必要とします。これはSeller Assistantワークフローがすでに使っているパターン、すなわち推奨のみ、または承認つき実行に一致します。

監査証跡。 すべての行動が記録されます。Amazonはさらに、セラーのアシスタント内にある他の業務データ — セラーがClaudeに保持する会計・サプライヤー接続 — はAmazonには見えないと述べています。これはAmazon自身の執行に関する声明であり、独立して検証できる性質のものではありません。その前提で扱うべきです。

これは、カスタムMCPモジュールが強制するのと同じ制御パターンです。スコープされたツール、型付きパラメータ、書き込みに対する人間のゲート、監査に耐えるログ。違いはセラーの可視性に不利に働きます。自前のモジュールなら、スコープはチームが読めるコードです。ファーストパーティプラグインでは、スコープをマーケットプレイスが定め、セラーはベンダーの執行を信頼します。どちらが間違っているわけでもありません — しかし異なる信頼の判断であり、後者には、セキュリティチームがあらゆるサードパーティ統合に与えるのと同じ審査に値します。

ギャップ：プラグインが接続するのはAmazonのデータであって、セラーのスタックではない

60秒の接続は、Amazonをアシスタントに結びつけます。B2Bセラーの実際のオペレーションが走っているシステムには、何もしません。

価格。 プラグインは、セラーのガードレール内でAmazonの価格を調整できます。しかし、その前にNetSuiteの顧客ティア別価格表、CPQ内の契約条件、マージンの下限を確認することはできません。Amazonチャネルが直接B2B価格と照合される必要があるセラーにとって、変更を支配する価格ロジックはプラグインの届く範囲の外にあります。

在庫。 プラグインはAmazonの在庫水準を見ます。マルチチャネル在庫 — BigCommerceにある同じSKU、Brightpearlの倉庫にある同じSKU、ShipStationの出荷に割り当てられた同じSKU — は、プラグインが扱わない別個の同期問題です。

注文と書き戻し。 マーケットプレイスの注文には、依然として検証、税と配送のロジック、ERPへの登録が必要です。それが注文管理レイヤーです — 週1,800件の注文を処理する380人の従業員を抱えるディストリビューターが、NetSuite、BigCommerce、ShipStationにわたる型付きスキーマ検証によって、12%の入力エラー率を2%未満に削減したのはまさにこのレイヤーです。

選ばれたアシスタントのパターンは両刃です。 Amazonの提案は、セラーがすでにClaudeを「既存の会計・サプライヤーのデータ接続と並行して」運用している、というものです。Amazonのデータが同じアシスタントに入れば、セラーはAmazonの価格とERPコストの照合、マーケットプレイス在庫と倉庫在庫の突き合わせをアシスタントに頼むでしょう。そのシステム横断の推論こそ、プラグインが提供しない統合そのものです — そしてそれを安全にするのは、セラー自身のエージェントレイヤーです。システムごとの統治されたモジュール、エージェントが読み書きできるものの明示的なハンドル、そしてビジネスがすでに監査しているシステムに記録される監査証跡です。

ベータを有効化する前に評価すべきこと

4つの質問を、順番に。

1. プラグインは読むだけでなく、何を書き込めるのか？ 価格変更、リスティング編集、在庫調整は異なるリスククラスです。Amazonのワークフローは推奨のみと承認つき実行を区別しています — 有効化する前に、各ワークフローを正しいクラスに対応づけてください。
2. 承認はどこに置かれるのか？ 行動ごとか、ワークフローごとか、セッションごとか。価格エージェントでの行動ごとの承認は、セッション全体の許可とは異なる運用モデルです。
3. 監査証跡は何を記録し、どこまで届くのか？ 監査人がNetSuiteやコンプライアンス用データウェアハウスを読むなら、証跡は監査人がすでに読んでいるシステムに届かなければなりません。
4. セラー側には何が必要か？ エージェントが何をしたかを、どのシステム — ERP、ストアフロント、倉庫 — が把握しなければならないのか、そしてそのデータはどのように流れるのか。それがあなたが所有する統合です。

売り手側オペレーションレイヤーは今やエージェントサーフェスです。Amazonはプラグインと権限モデルで自らの手を打ちました。中堅B2Bセラーが実際に所有するのは、プラグインが接続しないすべてです。

関連記事

• Commerce Protocols for AI Agents: UCP, ACP, AP2, and MCP — How the Stack Fits Together — このプラグインが補完する買い手側プロトコルスタック：発見、チェックアウト、支払いマンデート、そしてB2Bセマンティックレイヤーのギャップ
• More RFQs, Fewer Real Opportunities: A Sell-Side Qualification Layer for Agent-Generated Demand — デマンド側の対になる記事：エージェントがインバウンドを生成するとき、サプライヤーの見積もりチームがそれをどう資格審査するか
• Order Management: How an Agent Validates 1,800 B2B Orders a Week and Cuts the Error Rate from 12% to Under 2% — マーケットプレイスの向こう側にある売り手側統合レイヤー：検証、出荷振り分け、ERPへの書き戻し

代表的な構築ビネット

中堅B2Bセラーが、自社のBigCommerceストアフロントとNetSuiteと並行してAmazonを運用しており、オペレーションチームは、あるチャネルのエージェントが行ったことと、他のシステムが信じていることを照合できません。構築は、システムインベントリ（Selling Partnerプラグインがカバーするサーフェス、NetSuiteとBigCommerceが公開しているもの）、ワークフローマップ（価格調整、在庫同期、注文受領）、そして固定スコープから始まります。すなわち、適合するところではファーストパーティプラグイン、NetSuiteとBigCommerce向けのカスタムMCPモジュール、そして書き込みをスコープし、しきい値を超える価格変更には行動ごとの承認を要求し、すべてのエージェントの行動をERPとコンプライアンスワークフローの双方が読める監査ログに記録するオーケストレーションポリシーです。最初の統合フロー — NetSuiteのティア別価格表を確認し、判断の証跡を書き戻すAmazon上の価格変更 — は5〜8週間で稼働します。

スコープを定めた構築をご依頼ください。1週間のディスカバリーで、システムインベントリ、ワークフローマップ、固定スコープが手に入ります — 私たちと一緒に構築するかどうかにかかわらず。